Si vous aviez déjà créé le conteneur Portainer, vous pouvez le relancer en faisant docker start portainer, sinon créez-le comme suit :
docker volume create portainer_data
docker run --detach --name portainer \
-p 9000:9000 \
-v portainer_data:/data \
-v /var/run/docker.sock:/var/run/docker.sock \
portainer/portainer-ce
/tmp/data de l’hôte au dossier /data sur le conteneur :docker run -it -v /tmp/data:/data ubuntu /bin/bash
cd /data/
touch testfile
exitexit
ls /tmp/data/
Le fichier testfile a été crée par le conteneur au dossier que l’on avait connecté grâce à -v /tmp/data:/data
moby-counter, Redis et les volumesPour ne pas interférer avec la deuxième partie du TP :
docker stop ou avec Portainer.docker container prunedocker volume prune pour faire le ménage de volume éventuellement créés dans les TPs précédentdocker network prune pour nettoyer les réseaux inutilisésPassons à l’exploration des volumes:
moby-network et les conteneurs redis et moby-counter à l’intérieur :docker network create moby-network
docker run -d --name redis --network moby-network redis
docker run -d --name moby-counter --network moby-network -p 8000:80 russmckendrick/moby-counter
supprimez le conteneur redis : docker stop redis puis docker rm redis
Visitez votre application dans le navigateur. Elle est maintenant déconnectée de son backend.
Avons-nous vraiment perdu les données de notre conteneur précédent ? Non ! Le Dockerfile pour l’image officielle Redis ressemble à ça :
FROM alpine:3.5
RUN addgroup -S redis && adduser -S -G redis redis
RUN apk add --no-cache 'su-exec>=0.2'
ENV REDIS_VERSION 3.0.7
ENV REDIS_DOWNLOAD_URL http://download.redis.io/releases/redis-3.0.7.tar.gz
ENV REDIS_DOWNLOAD_SHA e56b4b7e033ae8dbf311f9191cf6fdf3ae974d1c
RUN set -x \
&& apk add --no-cache --virtual .build-deps \
gcc \
linux-headers \
make \
musl-dev \
tar \
&& wget -O redis.tar.gz "$REDIS_DOWNLOAD_URL" \
&& echo "$REDIS_DOWNLOAD_SHA *redis.tar.gz" | sha1sum -c - \
&& mkdir -p /usr/src/redis \
&& tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 \
&& rm redis.tar.gz \
&& make -C /usr/src/redis \
&& make -C /usr/src/redis install \
&& rm -r /usr/src/redis \
&& apk del .build-deps
RUN mkdir /data && chown redis:redis /data
VOLUME /data
WORKDIR /data
COPY docker-entrypoint.sh /usr/local/bin/
RUN ln -s usr/local/bin/docker-entrypoint.sh /entrypoint.sh # backwards compat
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 6379
CMD [ "redis-server" ]Notez que, vers la fin du fichier, il y a une instruction VOLUME ; cela signifie que lorque notre conteneur a été lancé, un volume “caché” a effectivement été créé par Docker.
Beaucoup de conteneurs Docker sont des applications stateful, c’est-à-dire qui stockent des données. Automatiquement ces conteneurs créent des volument anonymes en arrière plan qu’il faut ensuite supprimer manuellement (avec rm ou prune).
Inspectez la liste des volumes (par exemple avec Portainer) pour retrouver l’identifiant du volume caché. Normalement il devrait y avoir un volume portainer_data (si vous utilisez Portainer) et un volume anonyme avec un hash.
Créez un nouveau conteneur redis en le rattachant au volume redis “caché” que vous avez retrouvé (en copiant l’id du volume anonyme) :
docker container run -d --name redis -v <volume_id>:/data --network moby-network redis:alpine
Visitez la page de l’application. Normalement un motif de logos moby d’une précédente session devrait s’afficher (après un délai pouvant aller jusqu’à plusieurs minutes)
Affichez le contenu du volume avec la commande : docker exec redis ls -lha /data
Finalement, nous allons recréer un conteneur avec un volume qui n’est pas anonyme.
En effet, la bonne façon de créer des volumes consiste à les créer manuellement (volumes nommés) : docker volume create redis_data.
redis puis créez un nouveau conteneur attaché à ce volume nommé : docker container run -d --name redis -v redis_data:/data --network moby-network redis:alpineLorsqu’un répertoire hôte spécifique est utilisé dans un volume (la syntaxe -v HOST_DIR:CONTAINER_DIR), elle est souvent appelée bind mounting.
C’est quelque peu trompeur, car tous les volumes sont techniquement “bind mounted”. La différence, c’est que le point de montage est explicite plutôt que caché dans un répertoire géré par Docker.
docker volume inspect redis_data.Pour nettoyer tout ce travail, arrêtez d’abord les différents conteneurs redis et moby-counter.
Lancez la fonction prune pour les conteneurs d’abord, puis pour les réseaux, et enfin pour les volumes.
Comme les réseaux et volumes n’étaient plus attachés à des conteneurs en fonctionnement, ils ont été supprimés.
Généralement, il faut faire beaucoup plus attention au prune de volumes (données à perdre) qu’au prune de conteneurs (rien à perdre car immutable et en général dans le registry).
VOLUME avec microblogRendez-vous dans votre répertoire racine en tapant cd.
Après être entré·e dans le repo microblog grâce à cd microblog, récupérez une version déjà dockerisée de l’app en chargeant le contenu de la branche Git tp2-dockerfile en faisant git checkout tp2-dockerfile -- Dockerfile.
Si vous n’aviez pas encore le repo microblog :
git clone https://github.com/uptime-formation/microblog/
cd microblog
git checkout tp2-dockerfile
Dockerfile de l’application microblog.Un volume Docker apparaît comme un dossier à l’intérieur du conteneur.
Nous allons faire apparaître le volume Docker comme un dossier à l’emplacement /data sur le conteneur.
Dockerfile une variable d’environnement DATABASE_URL ainsi (cette variable est lue par le programme Python) :ENV DATABASE_URL=sqlite:////data/app.db
Dockerfile une instruction VOLUME pour stocker la base de données SQLite de l’application.microblog_db, et lancez un conteneur l’utilisant, créez un compte et écrivez un message.microblog utilisant le même volume nommé.Vous possédez tous les ingrédients pour packager l’app de votre choix désormais ! Récupérez une image de base, basez-vous sur un Dockerfile existant s’il vous inspire, et lancez-vous !