Voir aussi :

Conteneurisation d'application avec Docker

Auteur principal :

Jean-Mathieu Chantrein

Bureau H105

jmc [at] info

Page créée en mai 2016

Introduction

La technologie de conteneurisation Docker est utilisé depuis septembre 2015 au département informatique / LERIA. Initialement adopté pour des usages pédagogiques, nous nous servons désormais de cette technologie pour mettre en production certains services/applications dans notre infrastructure.

Il s'agit principalement d'applications/de projet étudiants/enseignants pour lesquels l'équipe technique ne peut assurer la maintenance. La conteneurisation permet d'exploiter ces ressources applicatives tout en déchargeant l'équipe technique de cette maintenance, celle-ci incombant au responsable de l'application.

De plus, certains projets étant plus ou moins expérimentaux, leurs conteneurisations permets une amélioration globale de la sécurité de notre système d'information: par exemple, il y a autant de serveur de base de donnée que d'application conteneurisé, donc l'éventuelle comprommission de la base de donnée d'une application n'a pas d'implication sur les bases de données des autres applications conteneurisé.

Il convient de distinguer 2 types d'usage pour nos conteneurs :

  • Les conteneurs à usage pédagogique
  • Les conteneurs pour la mise en production d'application

Création d'image et de conteneur pour des usages pédagogiques ( salles tp )

Prérequis

  • Connaitre les fondements de la conteneurisation avec docker
  • Savoir rédiger un Dockerfile
  • Maîtriser les fondements de l'administration unix (droits, commandes de base)

Il est tout à fait possible de réaliser une image docker afin que des étudiants puissent l'exploiter en cours. Cependant, il y a une limitation lorsque les étudiants ne sont pas root sur leurs machines, ce qui est le cas pour les étudiants de la L1 à la L3 qui travaillent sur des postes fixes en partage avec l'ensemble des étudiants.

Pour palier à cette limitation, l'équipe technique à développé un wrapper qui permet aux étudiants de pouvoir lancer des conteneurs Docker sur leurs postes de travail. Certes, l'usage de Docker est restreint car le wrapper empêche à l'utilisateur la possibilité d'être root dans son conteneur, mais cela suffit souvent pour obtenir un bénéfice pédagogique important dans le cadre d'un cours.

Par exemple, les étudiants peuvent faire du dévellopement php sans avoir à installé un serveur web. Qui plus est, l'équipe technique n'a pas besoin non plus de s'occuper d'un serveur web dédié cet apprentissage des étudiants. On peut utiliser le même raisonnement pour de nombreux cours: android(SDK), java EE(tomcat), c++(EDI configuré selon le souhait de l'enseignant), Php/MySql, PhP/PostgreSql, …)

De plus, le mécanisme de wrapper permet aux étudiants de se servir de Docker sans même qu'ils ne sachent comment fonctionne docker. Un système d'alias permet de ne pas avoir à connaître une seule commande docker.

Exemple: la commande suivante permet de lancer un serveur lamp localisé sur la machine de l'étudiant avec mot de passe généré aléatoirement et montage d'un répertoire pour les sources php dans son home pour la persistance des données.
@php-dev

Toutes les informations de connexions sont affichés sur la sortie standard:

Lancement du conteneur serveur_php_mysql, veuillez patientier quelques instant ...

Vos fichiers de développement(html, php) se trouve dans /home/php_dev/Mes_projets_web du conteneur ET EN MEME TEMP dans le repertoire Mes_projets_web de votre home de Janus.

Attention, vos bases de données seront SUPPRIMEES lors de l'arrêt de ce conteneur.

Vous pouvez sauvegarder vos bases de données depuis l'interface de phpmyadmin (http://localhost/phpmyadmin) avec la fonction "exporter".

Vos pages web se trouvent sur http://localhost/Mes_projets_web/ .

Plus d'informations sur la configuration de ce serveur: http://localhost/phpinfo.php .


 * Starting web server apache2                                                   * 
  

  MySQL authentification (valable pour ce conteneur uniquement, retrouvable dans /home/php_dev/php_dev_passwd.txt): 

   	 User: root 		Mdp: aCeBEG
	 User: phpmyadmin 	Mdp: Avdnil

Enfin, les images sont accessibles publiquement, et les étudiants peuvent ainsi avoir chez eux, le même environnement logiciel de travail qu'à l'université, et cela, quelque soit leurs systèmes d'exploitation.

Voici la liste des images Docker à usage pédagogique qui sont déjà disponible:

  • android-dev
  • ccp-dev
  • php-dev

Si vous êtes enseignant et que souhaitez réaliser une image docker dans la cadre de votre enseignement, c'est par ici (authentification obligatoire).

Si vous êtes étudiants et que vous souhaitez de l'aide sur l'utilisation de docker au département informatique, c'est par .

Création d'image et de conteneur pour la mise en production d'application au département informatique/LERIA

Introduction

Les projets étudiants/enseignants destinés à être mis en production doivent être isolé dans des conteneurs docker. Il est à la charge des étudiants/enseignants de fournir les dockerfile et docker-compose permettant l'installation/la mise à jour des conteneurs en production, ou bien d'effectuer la mise jour de leurs conteneurs directement via un accès ssh sur ceux-ci (voir procédure de mises à jour ). Cette section est un guide pour les étudiants/enseignants souhaitant conteuriser leurs applications.

Si vous souhaitez mettre en production une application web, nous avons conçu un projet fournissant un template pour la création de l'image docker qui contiendra votre application. Nous décrivons ici la prise en main du projet compose_ssh_lampp_jre.

Pour des raisons d'homogénéité et de mutualisation de ressources, nous souhaitons que tous les conteneurs fonctionnent avec le même principe d'instanciation et à partir de la même image de base: si notre template ne permet pas de fournir les fonctionnalitées dont vous avez besoin, merci de prendre contact avec l'équipe technique afin que nous puissions les mettres en oeuvre dans notre template, ou bien, le cas échéant et sous certaines conditions, dans la création d'un nouveau template.

Pour toute application non web que vous souhaiteriez mettre en production, merci de prendre contact avec l'équipe technique.

Toute application conteneurisé ne faisant pas appel à nos templates d'images, ou n'ayant pas été fait en concertation avec l'équipe technique, pourrait se voir refuser sa mise en production dans notre infrastructure.

Présentation générale du projet compose-ssh-lampp-jre

Compose-ssh-lampp-jre est un projet permettant de provisionner facilement un ecosystème de type serveur web dans un conteneur Docker. L'objectif de ce projet est double:

  1. Permettre à des néophites en administration système de pouvoir disposer localement, facilement et sans effet de bord sur son installation originelle d'un environnement de développement web
  2. Permettre à des administrateurs systèmes la mise en production d'applications web complètement isolé chacune les unes des autres, mais toutes déployées à partir de la même image (rationalisation du stockage et de l'environnement fourni) et avec la même procédure (grâce à docker-compose) et dans le même environnement (structure/organisation de fichier imposé).

Le projet crée et exploite une image docker permettant de provisionner un conteneur fournissant les services suivant:

  • Apache
  • MySql ou Postgresql
  • openSSH
  • Java Runtime Environnement (pour un usage éventuelle de Talend).

Cette liste peut-être amener à évouler en fonction des besoins à venir des utilisateurs.

Fonctionnalitées, caractéristiques:

  • Il n'est pas obligatoire d'utiliser un serveur de base de donnée, mais on ne peut pas se servir de MySql et de PostgreSql en même temps, l'idée étant de ne pas pouvoir proposer plus d'une application par conteneur.
  • Un utilisateur courant et les bases de données sont créé/importé au premier lancement du conteneur si nécéssaire: il y a une persistance des données de MySql, PostgreSql et de la home de l'utilisateurs dans des répertoires montés en tant que volume, si ces volumes sont déjà existant et contiennent déjà des données, les données sont réexploité.
  • Un script de sauvegarde exécuté quotidiennement permet de conserver n différences entre sauvegarde des bases de données, des sources de l'application et du repertoire home des utilisateurs. Cela permet de pouvoir récupérer les données en cas de système compromis ou de pouvoir remonter à une configuration de l'application jusqu'à n changements. Pour une utilisation en production, il est tout de même recommandé de sauvegarder ces backups depuis un autre serveur afin de garantir une meilleure sécurité des donnée en isolant les sauvegardes sur une autre machine physique.
  • Les processus éxécutés au démarrage du conteneur sont gérés par supervisor: si un processus vient à mourir, supervisor tente de le remettre en route.

Spécificité:

Afin de fournir à l'utilisateur final (celui qui se connectera en ssh dans son conteneur) un environnement proche de celui qu'il a l'habitude de cotoyer (serveur classique), nous avons fait le choix d'exécuter plusieurs processus sur le même conteneur, ce qui, pour certains, ne respecte pas “LA” philosophie docker qui consisterait, et cela fait toujours débat, à ne faire tourner qu'un processus par conteneur. On considére qu'il n'y a pas “UNE” mais “DES” philosophies docker, et qu'il suffit d'adopter/créer l'approche la plus pertinente pour son besoin. La gestion de ces processus multiple est géré via supervisor comme conseillé par la documentation officiel de docker.

Prérequis

Installations de:

Si vous faites une installation sur macOs ou Windows, vous installerez Docker ToolBox, pensez à ce que la case Docker Compose soit bien coché à l'installation.
Pour ne pas avoir a utiliser sudo à chaque commande docker depuis son login “username”:
usermod -aG docker username
  • docker-compose sous linux (installé via docker ToolBox pour les autres distributions):
# Version 1.7.1 (voir si il en existe une plus récente)
# En root
curl -L https://github.com/docker/compose/releases/download/1.7.1/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
git clone https://leria49@bitbucket.org/leria49/compose_ssh_lampp_jre.git name_of_your_app
cd name_of_your_app
chmod +x init.sh
./init.sh

Avant de construire votre image docker, il vous faut :

  • importer vos sources dans le répertoire ./src (obligatoire)
  • modifier le fichier ./.env afin que celui-ci corresponde à vos besoins (obligatoire)
  • modifier le fichier ./etc/apache2/sites-available/apache_default afin que celui-ci corresponde à votre application web (obligatoire)
  • placer la base de donnée au format .sql à importer dans le repertoire ./database2import (facultatif)
  • importer votre documentation dans le répertoire ./documentation (facultatif)

Construction de l'image:

docker-compose build

Lancer votre application web dans un conteneur

docker-compose up -d 
# -d permer de détacher l'exécution du conteneur du shell
Les sources présentent dans le répertoire ./src sur l'hote et dans le repertoire /home/username/public_html ou /var/www/html dans le conteneur (voir persistance des données pour plus d'informations) sont modifiable et les modifications sont prises en compte en temps réel(i.e.: sans avoir à relancer le conteneur).

C'est fini ! Vous disposez d'un serveur web exécutant le code présent dans ./src et disposant d'une sauvegarde automatique journalière (à 22h22) si nécéssaire (i.e.: si modification du contenu entre deux sauvegardes) de vos fichiers sources, de votre base de donnée et de votre home. Ces sauvegardes sont disponible dans le répertoire backup_name_of_your_app de votre arborescence.

Quelques commandes docker, docker-compose utiles

Les commandes docker-compose doivent être faites à la racine de votre projet, la ou se situe le fichier docker-compose.yaml
  • Pour se connecter en tant que utilisateur root sur le conteneur:
docker-compose web_app /bin/bash
  • Pour supprimer le conteneur (ainsi que les changements effectués en dehors des répertoires persistant):
docker-compose down
  • Pour démarrer/arrêter le conteneur:
docker-compose start/stop
  • Pour voir les logs du conteneur lorsque celui-ci est détaché:
    docker logs name_of_your_app
  • Pour reconstruire et lancer le conteneur
docker-compose up --build
# ou bien reconstruire entièrement l'image
docker-compose build --no-cache
Vous pourriez obtenir un message de ce type:
Building web_app
Traceback (most recent call last):
File "<string>", line 3, in <module>
File "compose/cli/main.py", line 58, in main
File "compose/cli/main.py", line 109, in perform_command
File "compose/cli/main.py", line 734, in up
File "compose/project.py", line 380, in up
File "compose/service.py", line 283, in ensure_image_exists
File "compose/service.py", line 718, in build
File ".tox/py27/lib/python2.7/site-packages/docker/api/build.py", line 54, in build
File ".tox/py27/lib/python2.7/site-packages/docker/utils/utils.py", line 103, in tar
File "tarfile.py", line 2013, in add
IOError: [Errno 13] Permission denied: '/home/username/my_wordpress/data_mysql/ib_logfile0'
docker-compose returned -1

Au quel cas il vous faut supprimer les répertoires suivants (Attention, vous perdrez toutes les modifications faites depuis la dernière sauvegarde présente dans ./backup_name_of_your_app. Attention à ne pas écrire /home):

sudo rm -rf data_mysql/ data_pgsql/ home/

Exemple de déploiment avec une application wordpress

git clone https://leria49@bitbucket.org/leria49/compose_ssh_lampp_jre.git my_wordpress
cd my_wordpress
chmod +x init.sh
./init.sh
git clone https://github.com/WordPress/WordPress.git src

Modification dans le fichier ./env des variables suivantes:

APP_NAME=my_wordpress
USER_NAME=username
USER_PASSWORD=password
MYSQL_DATABASE_NAME=wordpress
MYSQL_PASSWORD=password
MYSQL_USER_NAME=username

Construction de l'image et premier lancement du conteneur:

docker-compose up --build
Building web_app
[...] # Processus de construction de l'image
Successfully built e0709dd9b922
Creating my_wordpress
Attaching to my_wordpress
my_wordpress | => Premier lancement du conteneur
my_wordpress | => Création de l'utilisateur test ...
my_wordpress | => Le mot de passe de test est disponible dans /root/user_authentification.txt
my_wordpress | => Installation des bases de données si nécéssaire ...
my_wordpress | => Le répertoire /var/lib/mysql utilisé par MySql n'a pas été initialisé
my_wordpress | => Initialisation de MySQL ...
my_wordpress | => MySql a bien été initialisé
my_wordpress | ==> Attente de confirmation du démarrage de mysql ...
my_wordpress | ===> Tentative d'importation de la base de donnée wordpress.sql si celle-ci n'est pas déjà importé
my_wordpress | ===> La base de donnée wordpress n'est pas déjà importé
my_wordpress | ===> Création de la base ...
my_wordpress | ===> Il n'y a pas de base de donnée disponible à l'importation
my_wordpress | ===> La base de donnée wordpress a été crée et est vide.
my_wordpress | ==> Création de l'utilisateur wordpress
my_wordpress | ==> Sauvegarde du mot de passe de admin dans /root/mysql_authentification.txt
my_wordpress | ==> L'authentification de wordpress est disponible dans /root/mysql_authentification.txt
my_wordpress | 
my_wordpress | ===============================================================================
my_wordpress | L'utilisateur MySql wordpress a été créé.
my_wordpress | 
my_wordpress | L'utilisateur MySQL 'root' n'a pas de mot de passe mais seul les 
my_wordpress | connexions locales sont acceptés.
my_wordpress | 
my_wordpress | Vous pouvez trouvez le  détails des authenfications des utilisateurs MySql
my_wordpress | dans le fichier /root/mysql_authentification.txt
my_wordpress | 
my_wordpress | Si vous souhaitez un accès distant sur les bases de donnée, 
my_wordpress | vous devriez instancier la variable d'environnement EXPOSE_DATABASE à true
my_wordpress | dans votre Dockerfile et/ou dans votre docker-compose.yaml et relancer la 
my_wordpress | procédure de construction ( docker-compose up --build )
my_wordpress | ===============================================================================
my_wordpress | 
my_wordpress | L'adresse ip de votre conteneur est : 127.0.0.1
my_wordpress | => Vous pouvez accéder à vos pages web sur http://127.0.0.1:80
my_wordpress | => L'accès ssh se fait via l'utilisateur test sur le port 22
my_wordpress | 
my_wordpress | => Lancement de supervisor ...
my_wordpress | 
my_wordpress | 2016-06-07 14:29:32,246 CRIT Supervisor running as root (no user in config file)
my_wordpress | 2016-06-07 14:29:32,252 INFO supervisord started with pid 1
my_wordpress | 2016-06-07 14:29:33,256 INFO spawned: 'sshd' with pid 469
my_wordpress | 2016-06-07 14:29:33,260 INFO spawned: 'mysqld' with pid 470
my_wordpress | 2016-06-07 14:29:33,263 INFO spawned: 'crond' with pid 471
my_wordpress | 2016-06-07 14:29:33,267 INFO spawned: 'apache2' with pid 472
my_wordpress | 2016-06-07 14:29:33,268 CRIT reaped unknown pid 75)
my_wordpress | 2016-06-07 14:29:34,553 INFO success: sshd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
my_wordpress | 2016-06-07 14:29:34,554 INFO success: mysqld entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
my_wordpress | 2016-06-07 14:29:34,554 INFO success: crond entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
my_wordpress | 2016-06-07 14:29:34,554 INFO success: apache2 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

Connectez vous en ssh dans votre conteneur:

ssh username@localhost
vim public_html/wp-config.php

Rendez vous sur la page http://localhost, et suivez les instructions, forcez l'écriture du fichier wp-config.php et cliquez sur Install.

C'est fini ! Vous disposez d'un serveur local avec wordpress et disposant d'une sauvegarde automatique journalière (à 22h22) si nécéssaire (i.e.: si modification) de vos fichiers sources, de votre base de donnée et de votre home. Ces sauvegardes sont disponible dans le répertoire backup_my_wordpress de votre arborescence.

Persistance des données

Si l'on reprend à la fin de l'exemple précédent et que l'on fait:

# On supprime le conteneur
docker-compose down
# On le relance
docker compose up --build -d
# On attends un instant et on vérifie que tout est en ordre dans la sortie suivante
docker logs taxe_app

Notez bien que la base de donnée n'est pas importé puisque celle-ci à persisté dans le répertoire data_mysql et cela malgré le processus de destruction et de reconstruction du conteneur. Voici la liste des repertoires persistants et donc indépendant de la création/suppression de conteneurs:

“./” dans le chemin sur l'hôte représente la racine du projet sur l'hôte(i.e.: la ou se trouve le fichier docker-compose.yaml)
Chemin sur l'hote Chemin dans le conteneur (par défaut) Mode de lecture Variable correspondante dans /root/docker_app/taxe_app/.env
./backup_taxe_app /root/backup rw PATH_CONTAINER_BACKUP
./database2import /root/database2import ro PATH_CONTAINER_IMPORT
./data_mysql /var/lib/mysql rw PATH_MYSQL_DATABASE
./data_pgsql /var/lib/postgresql rw PATH_PGSQL_DATABASE
./home /home rw
./src /var/www/html + ln -s /var/www/html /home/$USER_NAME/public_html rw PATH_CONTAINER_SRC
./scripts /root/scripts rw

Mise en production

Proposition d'infrastructure réseaux

  • Les conteneurs sont accessible depuis l'extérieur du réseau local (par défaut, uniquement sur le port 80)
    • Il faut être dans le réseau local pour accéder aux autres ports éventuellement ouvert (ssh, mysql, …)
  • Les adresses d'accès aux conteneurs sont les adresses d'un sous réseaux spécifiques
    • Chacune de ces adresses est attribuée à une interface réseau virtuelle spécifique
    • 1 seul machine virtuelle gère tous les conteneurs ainsi que toutes les adresses associées
  • Les conteneurs sont dans leurs propres sous réseaux (172.17/16 , mode bridge de docker), il y a un mapping des ports explicitement exposées entre les addreses d'accès aux conteneurs et les adresses des conteneurs
  • On n'utilise que un seul reverse proxy, le même que pour le reste de l'infrastructure

Orchestration des conteneurs par lots

Pour effectuer une commande sur tous les conteneurs, il suffit de se servir de ce script:

all_container_do
#!/bin/bash
 
#
# all_container_do
# jmc
#
# Ce script permet de lancer une commande sur les tous conteneurs de toutes les applications conteneurisées présente dans /path/to/your/docker/app
#
 
set -e
 
# FONCTIONS
 
usage()
{
	echo
	echo "Lance une commande sur tous les conteneurs de toutes les applications conteneurisées présente dans /path/to/your/docker/app"
	echo "Les commandes possibles sont les mêmes que celles de docker-compose et utilisent les mêmes options:"
	echo
	echo -e "\tLes commandes préfixé par \"*\" sont les commandes dont vous pourriez avoir besoin de vous servir dans le cadre de ce script"
	echo -e "\tLes commandes préfixé par \"!\" sont les commandes qu'il faut utiliser avec attention (pertes possibles de données non encore sauvegardé, suppression de sauvegarde, ...)"
	echo
	echo -e "\t * build			  Build or rebuild services "
	echo -e "\t config			  Validate and view the compose file "
	echo -e "\t create			  Create services "
	echo -e "\t !* down			  Stop and remove containers, networks, images, and volumes "
	echo -e "\t events			  Receive real time events from containers "
	echo -e "\t !* exec web_app               Execute a command in a running container "
	echo -e "\t help			  Get help on a command "
	echo -e "\t kill			  Kill containers "
	echo -e "\t * logs			  View output from containers "
	echo -e "\t * pause			  Pause services "
	echo -e "\t * port			  Print the public port for a port binding "
	echo -e "\t * ps			  List containers "
	echo -e "\t pull			  Pulls service images "
	echo -e "\t * restart			  Restart services "
	echo -e "\t !* rm			  Remove stopped containers "
	echo -e "\t * run			  Run a one-off command \!\!Merci d'utiliser systématiquement et de n'utiliser que l'option -d\!\! "
	echo -e "\t scale			  Set number of containers for a service "
	echo -e "\t * start			  Start services "
	echo -e "\t * stop			  Stop services "
	echo -e "\t * unpause			  Unpause services "
	echo -e "\t * up			  Create and start containers, \!\!Pensez à l'option -d\!\! "
	echo -e "\t version			  Show the Docker-Compose version information "
	echo
	echo "Pour plus d'informations sur les options possible sur une commande, tapez docker-compose commande -h"
	echo
}
 
 
# VARIABLES GLOBALES
readonly PATH2DOCKER_APP=/path/to/your/docker/app
 
# MAIN
if [ $# -eq 0 ] ;then
	usage
	exit 0
else
	readonly CMD=${@}
	echo "Tentive d'execution de la commande docker-compose ${CMD} pour les conteneurs des applications conteneurisées présentent dans ${PATH2DOCKER_APP}"
fi
 
 
cd ${PATH2DOCKER_APP}
 
echo "Parcours de toutes les applications présentent dans ${PATH2DOCKER_APP}"
for APP in $(ls -1);
do
	if [ -d ${APP} ]; then
		cd ${APP}
		if [ -e docker-compose.y?ml ]; then
			echo "Exécution de la commande docker-compose ${CMD} pour l'application ${APP}"
			/usr/local/bin/docker-compose ${CMD}
		else
			echo "Il n'y a pas de fichier docker-compose.yaml (ou .yml) dans le répertoire ${PWD}"
			echo "La commande ${CMD} a échoué sur l'application ${APP}"
		fi
	fi
	cd ${PATH2DOCKER_APP}
done

Pour avoir une information quotidienne pour savoir si vos conteneurs sont actif ou inactif, il suffit d'éditer votre crontab et de rajouter:

45 11 * * * root /path/to/all_container_do ps 2>/dev/null | mail -s "[DOCKER] Conteneurs actif/inactif" you@greatLab.com

Mise à jour

Il n'est pas pensable que chaque conteneur effectue sa mise à jour chacun de son coté:

  • Il y a autant de mise à jour que de conteneur
    • Gourmand en espace disque
    • Gourmand en bande passante
  • Difficile à orchestrer

Comme chaque conteneur partage la même image de base (leria/ssh_lamp_jre), il suffit de mettre à jour cette image lorsque des mises à jour sont disponibles et de relancer tout les conteneurs sur la base de cette nouvelle image mise à jour:

  • Une seul mise à jour
    • Peu d'espace disque sollicité
    • Peu de bande passante sollicité
  • Facile à orchestrer car entièrement automatisé. U
  • Une sauvegarde des 2 anciennes versions de l'image de base est quand même effectué au cas ou …
Comment ?

maj_images_docker
#!/bin/bash
 
set -e
 
# VARIABLE GLOBALE
 
readonly ALL_CONTAINER_DO=/root/scripts/all_container_do
readonly NB_MAJ=$(/usr/bin/docker run --rm leria/ssh_lampp_jre apt-get update 2&>/dev/null; apt-get -s upgrade | /bin/grep upgraded | /usr/bin/cut -d " " -f 1)
readonly DATE=`date +%y_%m_%d`
readonly IMAGE_TO_SAVE=leria/ssh_lampp_jre
readonly IMAGE=ssh_lampp_jre
readonly PATH_BACKUP=/path/to/your/backup
readonly FILE_TO_SAVE_IMAGE=${PATH_BACKUP}/${IMAGE}_${DATE}.tar
readonly NB_IMAGE_ALREADY_SAVE=$(/bin/ls -1 ${PATH_BACKUP}/${IMAGE}*.tar)
readonly NB_IMAGE_TO_SAVE=2
 
# MAIN
 
echo
echo "Il y a ${NB_MAJ} mises à jour disponible"
echo
 
if [ ${NB_MAJ} -gt 0 ] ; then
	echo "Sauvegarde de l'image actuelle dans ${FILE_TO_SAVE_IMAGE}"
	echo
	/usr/bin/docker save ${IMAGE_TO_SAVE} -o ${FILE_TO_SAVE_IMAGE} 
	echo
	if [ ${NB_IMAGE_ALREADY_SAVE} -gt ${NB_IMAGE_TO_SAVE} ]; then
		echo "Supression des plus anciennes sauvegarde, on ne conserve que les 2 dernières sauvegardes"
		echo
		readonly OLD_SAVE_TO_ERASE=$(/bin/ls -1t ${PATH_BACKUP}/${IMAGE}*.tar | tail -1)
		echo "Suppression du fichier ${PATH_BACKUP}/${OLD_SAVE_TO_ERASE} "
		echo
		rm ${PATH_BACKUP}/${OLD_SAVE_TO_ERASE}
	else
		echo "Pas de suppression d'anciennes sauvegarde"
		echo
	fi
	echo "Reconstruction de l'image ssh_lampp_jre sur dockerhub ..."
	echo
	/usr/bin/curl -H "Content-Type: application/json" --data '{"build": true}' -X POST https://registry.hub.docker.com/u/leria/ssh_lampp_jre/trigger/#Token fourni par votre hub, sinon, si vous utilisez notre dépot, notre image est mise à jour dès qu'une mise à jour est disponible grâce à ce script ;-) #/
	/bin/sleep 3600
 
	echo "Pull de l'image fraichement reconstruite avec ses mises à jour et constructions des nouveaux conteneurs ... "
	echo
	${ALL_CONTAINER_DO} build --force-rm --no-cache --pull
 
	if [ $? -eq 0 ]; then
		echo "Arret/suppression des images/conteneurs existant ..."
		echo
		${ALL_CONTAINER_DO} down
 
		echo "Lancement des nouveaux conteneurs ..."
		echo
		${ALL_CONTAINER_DO} up -d
 
		echo "Suppression des orphelins ..."
		echo
		/usr/bin/docker rmi `docker images --quiet --filter dangling=true`
	else
		echo "La commande \" ${ALL_CONTAINER_DO} build --force-rm --no-cache --pull \" a échoué"
		echo "Echec de la mise à jour des conteneurs"
		echo
		exit 1
	fi
else
	echo "Je n'ai donc rien à faire aujourd'hui. Un café ?"
	echo
fi

Enfin rajouter à votre crontab:

# Recherche de mise à jour image ssh_lampp_jre et mise à jour des images et conteneurs si besoin
# Rappel, Les backup des conteneurs se font à 22h22
23 23 * * * root /path/to/maj_images_docker

Fondements de la technologie Docker

Quelques définitions

Comment faire pour ...

... récupérer de l'espace disque ?

Supprimer les images orphelines

A force de changement des Dockerfile, les processus de reconstructions d'image peuvent créer de nombreuses images dite orphelines (même si le terme ne convient car elles ont des images parentes … Elles sont orphelines dans le sens où elle ne servent plus et sont donc à l'abandon). Les images orphelines sont des images qui ne sont pas identifié (“<none>”) et qui ne sont parent d'aucune image(i.e.: ce ne sont pas des images intermédiaires). Pour les supprimer, il suffit d'exécuter la commande suivante:

docker rmi `docker images --quiet --filter dangling=true`
  • docker images liste les images qui ne sont pas des parents, lorsque celle-ci sont taggées(identifiées), elles correspondent à l'image finale qui servira à instancier le conteneur.
  • L'option –quiet permet de n'afficher que les identifiants des images
  • L'option –filter dangling=true permet de n'afficher que les images orphelines (dangling = ballant, qui pendouille)
  • `docker images –quiet –filter dangling=true` ou $(docker images –quiet –filter dangling=true) renvoit donc les identifiants des images orphelines
  • docker rmi supprime les images associées à ses identifiants
Ne soyez pas surpris si pendant l'éxécution de cette commande, vous voyez apparaitre la suppression de beaucoup plus d'images que ce que vous pensiez, il s'agit en fait de la destruction des images intermédiaires qui servaient à la construction de l'image orpheline que vous détruisez et qui du coup deviennent orpheline à leur tour.

Supprimer toutes les images

docker rmi `docker images -q`

Supprimer tout les conteneurs

docker rm [-f] `docker ps -aq`
  • docker ps liste les conteneurs actif
  • L'option -a permet de lister tous les conteneurs
  • L'option -q permet de n'afficher que les identifiants des conteneurs
  • `docker ps -aq` ou $(docker ps -aq) renvoie donc les identifiants de tous les conteneurs
  • docker rm supprime les conteneurs associés à ces identifiants.
  • L'ajout de l'option -f permet de forcer la suppression du conteneur en toute circonstance
aide/docker.txt · Dernière modification: 19/01/2017 10:08 par De Germain Frantz
CC Attribution-Noncommercial-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0