Projets-2015-2016-IaaS Docker - Revision history

Donsez: /* Monitoring with cAdvisor */

2016-09-14T09:13:43Z

Monitoring with cAdvisor

← Older revision		Revision as of 09:13, 14 September 2016
Line 310:		Line 310:
	There is no need to use the other scripts the archive contains.		There is no need to use the other scripts the archive contains.

	= Monitoring with cAdvisor=		= Monitoring with [[cAdvisor]]=


	We were looking for a light and efficient tool to monitor the instances running on provider side. We first used Shinken but we found this tool way to heavy for what we wanted to do. Then we found cAdvisor.		We were looking for a light and efficient tool to monitor the instances running on provider side. We first used Shinken but we found this tool way to heavy for what we wanted to do. Then we found [[cAdvisor]].

	Google first created cAdvisor to monitor their own lmctfy containers and added Docker container support (those that use the default lib container execdriver). cAdvisor is short for Container Advisor. You can use cAdvisor to get a detailed look into the resource usage and the various performance characteristics of your running containers. cAdvisor includes a simple UI to view the live data, a simple API to retrieve the data programmatically, and the ability to store the data in an external InfluxDB.		Google first created cAdvisor to monitor their own lmctfy containers and added [[Docker]] container support (those that use the default lib container execdriver). cAdvisor is short for Container Advisor. You can use cAdvisor to get a detailed look into the resource usage and the various performance characteristics of your running containers. [[cAdvisor]] includes a simple UI to view the live data, a simple API to retrieve the data programmatically, and the ability to store the data in an external InfluxDB.

	If you want to monitor all of the containers you have running on a host, you can deploy the cAdvisor image as a container in that same host. It will then have access to the resource usage and performance characteristics of your other containers in that host.		If you want to monitor all of the containers you have running on a host, you can deploy the cAdvisor image as a container in that same host. It will then have access to the resource usage and performance characteristics of your other containers in that host.

Alan.Damotte: /* How to use the scripts? */

2016-03-16T10:13:30Z

How to use the scripts?

← Older revision		Revision as of 10:13, 16 March 2016
Line 299:		Line 299:
	* If you need to update coordinator or shinken image:		* If you need to update coordinator or shinken image:

	** Update coordinator image		:* Update coordinator image
	./coordinatorBuild.sh update coordinator		./coordinatorBuild.sh update coordinator

	** Update shinken image (this is not necessary anymore since we use cAdvisor)		:* Update shinken image (this is not necessary anymore since we use cAdvisor)
	./coordinatorBuild.sh update shinken		./coordinatorBuild.sh update shinken

	** Update both coordinator and shinken image		:* Update both coordinator and shinken image
	./coordinatorBuild.sh update all		./coordinatorBuild.sh update all

Alan.Damotte: /* How to use the scripts? */

2016-03-16T10:13:09Z

How to use the scripts?

← Older revision		Revision as of 10:13, 16 March 2016
Line 299:		Line 299:
	* If you need to update coordinator or shinken image:		* If you need to update coordinator or shinken image:

	*Update coordinator image		** Update coordinator image
	./coordinatorBuild.sh update coordinator		./coordinatorBuild.sh update coordinator

	*Update shinken image (this is not necessary anymore since we use cAdvisor)		** Update shinken image (this is not necessary anymore since we use cAdvisor)
	./coordinatorBuild.sh update shinken		./coordinatorBuild.sh update shinken

	*Update both coordinator and shinken image		** Update both coordinator and shinken image
	./coordinatorBuild.sh update all		./coordinatorBuild.sh update all

Alan.Damotte: /* How to use the scripts? */

2016-03-16T10:12:49Z

How to use the scripts?

← Older revision		Revision as of 10:12, 16 March 2016
Line 299:		Line 299:
	* If you need to update coordinator or shinken image:		* If you need to update coordinator or shinken image:

	** Update coordinator image		*Update coordinator image
	./coordinatorBuild.sh update coordinator		./coordinatorBuild.sh update coordinator

	** Update shinken image (this is not necessary anymore since we use cAdvisor)		*Update shinken image (this is not necessary anymore since we use cAdvisor)
	./coordinatorBuild.sh update shinken		./coordinatorBuild.sh update shinken

	**Update both coordinator and shinken image		*Update both coordinator and shinken image
	./coordinatorBuild.sh update all		./coordinatorBuild.sh update all

Alan.Damotte: /* Containers' automatic deployment */

2016-03-16T10:11:23Z

Containers' automatic deployment

← Older revision		Revision as of 10:11, 16 March 2016
Line 270:		Line 270:

	'''Bandwidth:''' Since all the containers run on the same Docker network, we are able to use Wondershaper and to set a limit for bandwidth usage. Then, Docker takes care to divide equitably the available bandwidth to each container.		'''Bandwidth:''' Since all the containers run on the same Docker network, we are able to use Wondershaper and to set a limit for bandwidth usage. Then, Docker takes care to divide equitably the available bandwidth to each container.

			== Archive content ==

			*Scripts:
			** coordinatorBuild: used to build coordinator and shinken images
			** coordinatorStart: used to start coordinator and shinken images
			** coordinatorStop: used to stop coordinator and shinken images
			** userAdd: add iaas user to host
			** startProvider: main script that create iaas user, build all images, and start coordinator and monitoring containers

			*Folders:
			** containerManagment: contains all the scripts which are copied to iaas user home and will be used to manage containers
			** coordinator: contains Dockerfile and script to initialize coordinator image
			** docker_shinken: contains Dockerfiles and scripts to initialize monitoring image (note: we now use cAdvisor to monitor our containers)
			** images: contains Dockerfiles and scripts to initialize main images (ubuntu, debian, centos)

			== How to use the scripts? ==

			* To initialize and start coordinator and monitoring containers:
			./startProvider.sh

			* To start coordinator and monitoring containers (will have no effect if they are already started, not necessary if startProvider script is used):
			./coordinatorStart.sh

			* To stop coordinator and monitoring containers:
			./coordinatorStop.sh

			* If you need to update coordinator or shinken image:

			** Update coordinator image
			./coordinatorBuild.sh update coordinator

			** Update shinken image (this is not necessary anymore since we use cAdvisor)
			./coordinatorBuild.sh update shinken

			**Update both coordinator and shinken image
			./coordinatorBuild.sh update all

			There is no need to use the other scripts the archive contains.

	= Monitoring with cAdvisor=		= Monitoring with cAdvisor=

Alan.Damotte: /* Containers' automatic deployment */

2016-03-16T09:49:18Z

Containers' automatic deployment

← Older revision		Revision as of 09:49, 16 March 2016
Line 270:		Line 270:

	'''Bandwidth:''' Since all the containers run on the same Docker network, we are able to use Wondershaper and to set a limit for bandwidth usage. Then, Docker takes care to divide equitably the available bandwidth to each container.		'''Bandwidth:''' Since all the containers run on the same Docker network, we are able to use Wondershaper and to set a limit for bandwidth usage. Then, Docker takes care to divide equitably the available bandwidth to each container.

			= Monitoring with cAdvisor=


			We were looking for a light and efficient tool to monitor the instances running on provider side. We first used Shinken but we found this tool way to heavy for what we wanted to do. Then we found cAdvisor.

			Google first created cAdvisor to monitor their own lmctfy containers and added Docker container support (those that use the default lib container execdriver). cAdvisor is short for Container Advisor. You can use cAdvisor to get a detailed look into the resource usage and the various performance characteristics of your running containers. cAdvisor includes a simple UI to view the live data, a simple API to retrieve the data programmatically, and the ability to store the data in an external InfluxDB.

			If you want to monitor all of the containers you have running on a host, you can deploy the cAdvisor image as a container in that same host. It will then have access to the resource usage and performance characteristics of your other containers in that host.

			You can check cAdvisor is running by pointing your browser to the host’s IP or hostname and port 8080. If running locally, try http://localhost:8080. This will bring up the built-in Web UI.

			[[File:cAdvisor.png\|center\|thumb\|500px\|cAdvisor]]

	= Useful links =		= Useful links =

Alan.Damotte: /* Planning */

2016-03-15T08:45:52Z

Planning

← Older revision		Revision as of 08:45, 15 March 2016
Line 101:		Line 101:
	* Establish rabbitmq on both front-end side and provider side		* Establish rabbitmq on both front-end side and provider side

	=== Week 6: February 29th - ~~Mars~~ 6th ===		=== Week 6: February 29th - March 6th ===
	* Container's deployment:		* Container's deployment:
	** Modify coordinator Dockerfile to install nodejs		** Modify coordinator Dockerfile to install nodejs
Line 127:		Line 127:
	=> The main development phase is finished since we have a working base. We still need to improve some things, eventually develop some advanced functionalities during the last two weeks.		=> The main development phase is finished since we have a working base. We still need to improve some things, eventually develop some advanced functionalities during the last two weeks.

	=== Week 7: ~~Mars~~ 7th - ~~Mars~~ 13th ===		=== Week 7: March 7th - March 13th ===
	* Finish creating the flyer		* Finish creating the flyer
	* Write report for our last MPI course		* Write report for our last MPI course
Line 141:		Line 141:
	* Start preparing the presentation		* Start preparing the presentation

	=== Week 8: ~~Mars~~ 14th - ~~Mars~~ ~~18th~~ ===		=== Week 8: March 14th - March 17th ===
	* Finish presentation preparation		* Finish presentation preparation
	* Fix some bugs:		* Fix some bugs:

Robin.Eudes: /* Week 8: Mars 14th - Mars 18th */

2016-03-15T08:41:36Z

Week 8: Mars 14th - Mars 18th

← Older revision		Revision as of 08:41, 15 March 2016
Line 146:		Line 146:
	** Start instances if they already exist		** Start instances if they already exist
	** Stop instances and no longer remove them in order to be reused/started again		** Stop instances and no longer remove them in order to be reused/started again
			** Really remove client instances running on provider when he choose to not be available
			** Others minor fixes

	=What is Docker?=		=What is Docker?=

Alan.Damotte: /* System Architecture */

2016-03-14T14:00:54Z

System Architecture

← Older revision		Revision as of 14:00, 14 March 2016
Line 226:		Line 226:

	[[File:Coordinator.png]][[File:Frontend.png]]		[[File:Coordinator.png]][[File:Frontend.png]]

			== Database schema ==

			[[File:Database.jpg\|center\|thumb\|1000px\|Database diagram]]

	= Containers' automatic deployment =		= Containers' automatic deployment =

Alan.Damotte: /* Week 8: Mars 14th - Mars 18th */

2016-03-14T13:43:41Z

Week 8: Mars 14th - Mars 18th

← Older revision		Revision as of 13:43, 14 March 2016
Line 142:		Line 142:

	=== Week 8: Mars 14th - Mars 18th ===		=== Week 8: Mars 14th - Mars 18th ===
			* Finish presentation preparation
			* Fix some bugs:
			** Start instances if they already exist
			** Stop instances and no longer remove them in order to be reused/started again

	=What is Docker?=		=What is Docker?=