Comment mettre à jour automatiquement vos conteneurs de menu fixe, si les images de base sont mises à jour
Supposons que j'ai un conteneur trivial basé sur le ubuntu:latest. Il existe maintenant une mise à jour de sécurité et ubuntu:latest est mis à jour dans le référentiel de docker.
Comment pourrais-je connaître mon image locale et ses conteneurs courent derrière?
Existe-t-il des pratiques recommandées pour la mise à jour automatique des images et des conteneurs locaux afin de suivre les mises à jour de docker repo, ce qui, dans la pratique, vous donnerait les mêmes avantages que de disposer de mises à niveau sans surveillance exécutées sur une machine ubuntu classique
Une des façons de le faire est de gérer cela via vos systèmes CI/CD. Une fois que votre image parent est construite, effectuez quelque chose qui analyse votre dépôt git pour les images utilisant ce parent. Si vous le trouvez, vous envoyez alors une demande d'extraction afin de passer aux nouvelles versions de l'image. Si tous les tests réussissent, la demande d'extraction sera fusionnée et vous obtiendrez une nouvelle image enfant basée sur le parent mis à jour. Un exemple d’outil qui adopte cette approche est disponible à l’adresse suivante: https://engineering.salesforce.com/open-sourcing-dockerfile-image-update-6400121c1a75 .
Si vous ne contrôlez pas votre image parent, comme ce serait le cas si vous dépendiez de l'image ubuntu officielle, vous pouvez écrire un outil qui détecte les modifications apportées à la balise d'image parent et invoque les constructions d'images enfants en conséquence.
Nous utilisons un script qui vérifie si un conteneur en cours d'exécution est démarré avec la dernière image. Nous utilisons également des scripts d'initialisation pour le démarrage de l'image du menu fixe.
#!/usr/bin/env bash
set -e
BASE_IMAGE="registry"
REGISTRY="registry.hub.docker.com"
IMAGE="$REGISTRY/$BASE_IMAGE"
CID=$(docker ps | grep $IMAGE | awk '{print $1}')
docker pull $IMAGE
for im in $CID
do
LATEST=`docker inspect --format "{{.Id}}" $IMAGE`
RUNNING=`docker inspect --format "{{.Image}}" $im`
NAME=`docker inspect --format '{{.Name}}' $im | sed "s/\///g"`
echo "Latest:" $LATEST
echo "Running:" $RUNNING
if [ "$RUNNING" != "$LATEST" ];then
echo "upgrading $NAME"
stop docker-$NAME
docker rm -f $NAME
start docker-$NAME
else
echo "$NAME up to date"
fi
done
Et init ressemble à
docker run -t -i --name $NAME $im /bin/bash
Une solution serait d'utiliser docker hubbuilds automatisés . La fonctionnalité Liens de référentiel reconstruira votre conteneur lorsqu'un conteneur en amont est reconstruit, et la fonctionnalité Webhooks vous enverra une notification.
Il semble que les Webhooks soient limités aux appels HTTP POST. Vous devez configurer un service pour les intercepter, ou peut-être utiliser l'un des POST pour envoyer des services de messagerie.
Je n'ai pas examiné la question, mais le nouveau Docker Universal Control Plane pourrait avoir une fonctionnalité permettant de détecter les conteneurs mis à jour et de les redéployer.
Vous pouvez utiliser Watchtower _ pour surveiller les mises à jour de l'image à partir de laquelle un conteneur est instancié, extraire automatiquement la mise à jour et redémarrer le conteneur à l'aide de l'image mise à jour. Cependant, cela ne résout pas le problème de la reconstruction de vos propres images personnalisées en cas de modification de l'image en amont sur laquelle elle est basée. Vous pouvez voir cela comme un problème en deux parties: (1) savoir quand une image en amont a été mise à jour et (2) effectuer la reconstruction de l'image. (1) peut être résolu assez facilement, mais (2) dépend beaucoup de votre environnement de construction local/de vos pratiques. Il est donc probablement beaucoup plus difficile de créer une solution généralisée à cette fin.
Si vous pouvez utiliser constructions automatisées de Docker Hub, le problème tout entier peut être résolu de manière relativement propre à l'aide de la fonction liens de référentiel , qui vous permet de déclencher une reconstruction automatique lorsqu'un référentiel lié ( probablement en amont) est mis à jour. Vous pouvez également configurer un webhook pour vous avertir de la création automatique. Si vous souhaitez un courrier électronique ou une notification SMS, vous pouvez connecter le WebHook à IFTTT Maker . J'ai trouvé l'interface utilisateur IFTTT un peu déroutante, mais vous configureriez le Webhook Docker pour publier sur https://maker.ifttt.com/trigger/ } _docker_xyz_image_built/with/key/your_key.
Si vous avez besoin de construire localement, vous pouvez au moins résoudre le problème d'obtention de notifications lorsqu'une image en amont est mise à jour en créant un référentiel factice dans Docker Hub lié à votre/vos référentiel (s) d'intérêt. Le seul but du repo factice serait de déclencher un Webhook lorsqu’il sera reconstruit (ce qui implique que l’un de ses repo liés a été mis à jour). Si vous êtes en mesure de recevoir ce lien Web, vous pouvez même l'utiliser pour déclencher une reconstruction de votre côté.
J'avais le même problème et je pensais qu'il pouvait être résolu simplement par un travail cron appelant unattended-upgrade tous les jours.
Mon intention est de disposer de cette solution automatique et rapide pour garantir la sécurité et la mise à jour du conteneur de production, car il peut parfois me falloir mettre à jour mes images et déployer une nouvelle image du menu fixe avec les dernières mises à jour de sécurité.
Il est également possible d'automatiser la construction et le déploiement de l'image avec hooks Github
J'ai créé une image de base de docker qui vérifie et installe automatiquement les mises à jour de sécurité quotidiennement (peut être exécutée directement par docker run itech/docker-unattended-upgrade).
Je suis également tombé sur une autre approche différente - pour vérifier si le conteneur nécessite une mise à jour.
Ma mise en œuvre complète:
Dockerfile
FROM ubuntu:14.04
RUN apt-get update \
&& apt-get install -y supervisor unattended-upgrades \
&& rm -rf /var/lib/apt/lists/*
COPY install /install
RUN chmod 755 install
RUN /install
COPY start /start
RUN chmod 755 /start
Scripts d'aide
installer
#!/bin/bash
set -e
cat > /etc/supervisor/conf.d/cron.conf <<EOF
[program:cron]
priority=20
directory=/tmp
command=/usr/sbin/cron -f
user=root
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/%(program_name)s.log
stderr_logfile=/var/log/supervisor/%(program_name)s.log
EOF
rm -rf /var/lib/apt/lists/*
ENTRYPOINT ["/start"]
commencer
#!/bin/bash
set -e
echo "Adding crontab for unattended-upgrade ..."
echo "0 0 * * * root /usr/bin/unattended-upgrade" >> /etc/crontab
# can also use @daily syntax or use /etc/cron.daily
echo "Starting supervisord ..."
exec /usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf
Modifier
J'ai développé un petit outil docker-run qui s'exécute en tant que conteneur docker et peut être utilisé pour mettre à jour des packages à l'intérieur de tous les conteneurs en cours d'exécution ou sélectionnés, il peut également être utilisé pour exécuter des commandes arbitraires.
Peut être facilement testé avec la commande suivante:
docker run --rm -v /var/run/docker.sock:/tmp/docker.sock itech/docker-run exec
qui, par défaut, exécutera la commande date dans tous les conteneurs en cours d’exécution et affichera les résultats. Si vous passez update au lieu de exec, il exécutera apt-get update suivi de apt-get upgrade -y dans tous les conteneurs en cours d'exécution.
Vous ne sauriez pas que votre conteneur est derrière sans exécuter docker pull . Ensuite, vous devez reconstruire ou recomposer votre image.
docker pull image:tag
docker-compose -f docker-compose.yml -f production.yml up -d --build
Les commandes peuvent être placées dans un script avec tout autre élément nécessaire pour effectuer la mise à niveau, bien qu'un conteneur approprié n'ait besoin de rien de plus.
La gestion des dépendances pour les images Docker est un réel problème. Je fais partie d'une équipe qui a créé un outil, MicroBadger , pour aider à cela en surveillant les images de conteneurs et en inspectant les métadonnées. L’une de ses fonctionnalités est de vous permettre de configurer un Webhook de notification qui est appelé lorsqu’une image qui vous intéresse (par exemple une image de base) change.
Une autre approche pourrait être de supposer que votre image de base prend du retard assez rapidement (et cela risque fort de se produire), de forcer une nouvelle génération d'image de votre application périodiquement (par exemple, chaque semaine), puis de la redéployer si elle a changé.
Autant que je sache, les images de base populaires telles que Debian ou Java officielle mettent à jour leurs balises pour prendre en charge les correctifs de sécurité. Les balises ne sont donc pas immuables (si vous voulez une garantie plus forte, vous devez utiliser la référence [image: @digest ], disponible dans les versions plus récentes de Docker). Par conséquent, si vous construisez votre image avec docker build --pull, votre application doit alors obtenir la dernière et la plus grande des balises d'image de base que vous référencez.
Étant donné que les balises mutables peuvent être source de confusion, il est préférable d’incrémenter le numéro de version de votre application chaque fois que vous effectuez cette opération, de manière à ce que les choses soient au moins plus propres de votre côté.
Je ne suis donc pas sûr que le script suggéré dans l'une des réponses précédentes fasse l'affaire, car il ne reconstruit pas l'image de votre application; il met simplement à jour la balise d'image de base, puis redémarre le conteneur, mais le nouveau conteneur fait toujours référence à l'ancien hash de l'image de base.
Je ne recommanderais pas d'exécuter des tâches de type cron dans des conteneurs (ou tout autre processus, sauf si cela est vraiment nécessaire), car cela va à l'encontre du mantra qui consiste à n'exécuter qu'un processus par conteneur (il y a différents arguments pour expliquer pourquoi c'est mieux, alors je ' je ne vais pas y aller ici).
Prémisse à ma réponse:
- Les conteneurs sont exécutés avec des balises.
- La même balise peut être dirigée vers une autre image UUID à notre guise.
- Les mises à jour effectuées sur une image peuvent être validées sur un nouveau calque d'image.
Approche
- Construisez tous les conteneurs en premier lieu avec un script de mise à jour du correctif de sécurité
- Construisez un processus automatisé pour le suivant
- Exécuter une image existante sur un nouveau conteneur avec le script de correctif de sécurité comme commande
- Valider les modifications apportées à l'image en tant que
- balise existante -> suivie du redémarrage des conteneurs un à un
- nouvelle version tag -> remplacer quelques conteneurs par un nouveau tag -> valider -> déplacer tous les conteneurs vers un nouveau tag
De plus, l'image de base peut être mise à niveau/le conteneur avec une nouvelle image de base complète peut être construit à intervalles réguliers, si le responsable le juge nécessaire.
Avantages
- Nous préservons l'ancienne version de l'image lors de la création de la nouvelle image avec correctif de sécurité. Nous pouvons donc revenir à l'image précédente si nécessaire.
- Nous préservons le cache de docker, donc moins de transfert de réseau (seule la couche modifiée obtient sur le fil)
- Le processus de mise à niveau peut être validé dans la mise en scène avant de passer à prod
- Cela peut être un processus contrôlé, par conséquent, les correctifs de sécurité ne peuvent être appliqués que lorsque cela est nécessaire/jugé important.
Il y a beaucoup de réponses ici, mais aucune d'entre elles ne répondait à mes besoins. Je voulais une réponse réelle à la question n ° 1 du demandeur. Comment savoir quand une image est mise à jour sur hub.docker.com?
Le script ci-dessous peut être exécuté quotidiennement. À la première exécution, il obtient une référence des balises et des dates de mise à jour à partir du registre HUB et les enregistre localement. À partir de là, chaque fois qu'il est exécuté, il vérifie dans le registre les nouvelles balises et les dates de mise à jour. Comme cela change à chaque fois qu'une nouvelle image existe, cela nous indique si l'image de base a changé. Voici le script:
#!/bin/bash
DATAPATH='/data/docker/updater/data'
if [ ! -d "${DATAPATH}" ]; then
mkdir "${DATAPATH}";
fi
IMAGES=$(docker ps --format "{{.Image}}")
for IMAGE in $IMAGES; do
ORIGIMAGE=${IMAGE}
if [[ "$IMAGE" != *\/* ]]; then
IMAGE=library/${IMAGE}
fi
IMAGE=${IMAGE%%:*}
echo "Checking ${IMAGE}"
PARSED=${IMAGE//\//.}
if [ ! -f "${DATAPATH}/${PARSED}" ]; then
# File doesn't exist yet, make baseline
echo "Setting baseline for ${IMAGE}"
curl -s "https://registry.hub.docker.com/v2/repositories/${IMAGE}/tags/" > "${DATAPATH}/${PARSED}"
else
# File does exist, do a compare
NEW=$(curl -s "https://registry.hub.docker.com/v2/repositories/${IMAGE}/tags/")
OLD=$(cat "${DATAPATH}/${PARSED}")
if [[ "${VAR1}" == "${VAR2}" ]]; then
echo "Image ${IMAGE} is up to date";
else
echo ${NEW} > "${DATAPATH}/${PARSED}"
echo "Image ${IMAGE} needs to be updated";
H=`hostname`
ssh -i /data/keys/<KEYFILE> <USER>@<REMOTEHOST>.com "{ echo \"MAIL FROM: root@${H}\"; echo \"RCPT TO: <USER>@<EMAILHOST>.com\"; echo \"DATA\"; echo \"Subject: ${H} - ${IMAGE} needs update\"; echo \"\"; echo -e \"\n${IMAGE} needs update.\n\ndocker pull ${ORIGIMAGE}\"; echo \"\"; echo \".\"; echo \"quit\"; sleep 1; } | telnet <SMTPHOST> 25"
fi
fi
done;
Vous voudrez modifier la variable DATAPATH en haut et la commande de notification par courrier électronique à la fin pour l'adapter à vos besoins. Pour moi, je l’ai en SSH sur un serveur d’un autre réseau où se trouve mon SMTP. Mais vous pouvez aussi facilement utiliser la commande mail.
Désormais, vous souhaitez également rechercher les packages mis à jour dans les conteneurs eux-mêmes. C’est en fait probablement plus efficace que de tirer une fois que vos conteneurs fonctionnent. Voici le script pour retirer cela:
#!/bin/bash
function needsUpdates() {
RESULT=$(docker exec ${1} bash -c ' \
if [[ -f /etc/apt/sources.list ]]; then \
grep security /etc/apt/sources.list > /tmp/security.list; \
apt-get update > /dev/null; \
apt-get upgrade -oDir::Etc::Sourcelist=/tmp/security.list -s; \
fi; \
')
RESULT=$(echo $RESULT)
GOODRESULT="Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded."
if [[ "${RESULT}" != "" ]] && [[ "${RESULT}" != "${GOODRESULT}" ]]; then
return 0
else
return 1
fi
}
function sendEmail() {
echo "Container ${1} needs security updates";
H=`hostname`
ssh -i /data/keys/<KEYFILE> <USRER>@<REMOTEHOST>.com "{ echo \"MAIL FROM: root@${H}\"; echo \"RCPT TO: <USER>@<EMAILHOST>.com\"; echo \"DATA\"; echo \"Subject: ${H} - ${1} container needs security update\"; echo \"\"; echo -e \"\n${1} container needs update.\n\n\"; echo -e \"docker exec ${1} bash -c 'grep security /etc/apt/sources.list > /tmp/security.list; apt-get update > /dev/null; apt-get upgrade -oDir::Etc::Sourcelist=/tmp/security.list -s'\n\n\"; echo \"Remove the -s to run the update\"; echo \"\"; echo \".\"; echo \"quit\"; sleep 1; } | telnet <SMTPHOST> 25"
}
CONTAINERS=$(docker ps --format "{{.Names}}")
for CONTAINER in $CONTAINERS; do
echo "Checking ${CONTAINER}"
if needsUpdates $CONTAINER; then
sendEmail $CONTAINER
fi
done
Les réponses ci-dessus sont également correctes
Il y a deux approches
- Utiliser des Webhooks
- Exécutez le script pour chaque minute spécifique pour obtenir une nouvelle image des images de docker
Je ne fais que partager un script qui pourrait vous être utile! Vous pouvez l’utiliser avec cronjob, j’ai essayé avec succès sous OSX.
#!/bin/bash
##You can use below commented line for setting cron tab for running cron job and to store its O/P in one .txt file
#* * * * * /usr/bin/Sudo -u admin -i bash -c /Users/Swapnil/Documents/checkimg.sh > /Users/Swapnil/Documents/cron_output.log 2>&1
# Example for the Docker Hub V2 API
# Returns all images and tags associated with a Docker Hub organization account.
# Requires 'jq': https://stedolan.github.io/jq/
# set username, password, and organization
# Filepath where your docker-compose file is present
FILEPATH="/Users/Swapnil/Documents/lamp-Alpine"
# Your Docker hub user name
UNAME="ur username"
# Your Docker hub user password
UPASS="ur pwd"
# e.g organisation_name/image_name:image_tag
ORG="ur org name"
IMGNAME="ur img name"
IMGTAG="ur img tag"
# Container name
CONTNAME="ur container name"
# Expected built mins
BUILDMINS="5"
#Generally cronjob frequency
CHECKTIME="5"
NETWORKNAME="${IMGNAME}_private-network"
#After Image pulling, need to bring up all docker services?
DO_DOCKER_COMPOSE_UP=true
# -------
echo "Eecuting Script @ date and time in YmdHMS: $(date +%Y%m%d%H%M%S)"
set -e
PIDFILE=/Users/Swapnil/Documents/$IMGNAME/forever.pid
if [ -f $PIDFILE ]
then
PID=$(cat $PIDFILE)
ps -p $PID > /dev/null 2>&1
if [ $? -eq 0 ]
then
echo "Process already running"
exit 1
else
## Process not found assume not running
echo $$
echo $$ > $PIDFILE
if [ $? -ne 0 ]
then
echo "Could not create PID file"
exit 1
fi
fi
else
echo $$ > $PIDFILE
if [ $? -ne 0 ]
then
echo "Could not create PID file"
exit 1
fi
fi
# Check Docker is running or not; If not runing then exit
if docker info|grep Containers ; then
echo "Docker is running"
else
echo "Docker is not running"
rm $PIDFILE
exit 1
fi
# Check Container is running or not; and set variable
CONT_INFO=$(docker ps -f "name=$CONTNAME" --format "{{.Names}}")
if [ "$CONT_INFO" = "$CONTNAME" ]; then
echo "Container is running"
IS_CONTAINER_RUNNING=true
else
echo "Container is not running"
IS_CONTAINER_RUNNING=false
fi
# get token
echo "Retrieving token ..."
TOKEN=$(curl -s -H "Content-Type: application/json" -X POST -d '{"username": "'${UNAME}'", "password": "'${UPASS}'"}' https://hub.docker.com/v2/users/login/ | jq -r .token)
# get list of repositories
echo "Retrieving repository list ..."
REPO_LIST=$(curl -s -H "Authorization: JWT ${TOKEN}" https://hub.docker.com/v2/repositories/${ORG}/?page_size=100 | jq -r '.results|.[]|.name')
# output images & tags
echo "Images and tags for organization: ${ORG}"
echo
for i in ${REPO_LIST}
do
echo "${i}:"
# tags
IMAGE_TAGS=$(curl -s -H "Authorization: JWT ${TOKEN}" https://hub.docker.com/v2/repositories/${ORG}/${i}/tags/?page_size=100 | jq -r '.results|.[]|.name')
for j in ${IMAGE_TAGS}
do
echo " - ${j}"
done
#echo
done
# Check Perticular image is the latest or not
#imm=$(curl -s -H "Authorization: JWT ${TOKEN}" https://hub.docker.com/v2/repositories/${ORG}/${IMGNAME}/tags/?page_size=100)
echo "-----------------"
echo "Last built date details about Image ${IMGNAME} : ${IMGTAG} for organization: ${ORG}"
IMAGE_UPDATED_DATE=$(curl -s -H "Authorization: JWT ${TOKEN}" https://hub.docker.com/v2/repositories/${ORG}/${IMGNAME}/tags/?page_size=100 | jq -r '.results|.[]|select(.name | contains("'${IMGTAG}'")).last_updated')
echo "On Docker Hub IMAGE_UPDATED_DATE---$IMAGE_UPDATED_DATE"
echo "-----------------"
IMAGE_CREATED_DATE=$(docker image inspect ${ORG}/${IMGNAME}:${IMGTAG} | jq -r '.[]|.Created')
echo "Locally IMAGE_CREATED_DATE---$IMAGE_CREATED_DATE"
updatedDate=$(date -jf '%Y-%m-%dT%H:%M' "${IMAGE_UPDATED_DATE:0:16}" +%Y%m%d%H%M%S)
createdDate=$(date -jf '%Y-%m-%dT%H:%M' "${IMAGE_CREATED_DATE:0:16}" +%Y%m%d%H%M%S)
currentDate=$(date +%Y%m%d%H%M%S)
start_date=$(date -jf "%Y%m%d%H%M%S" "$currentDate" "+%s")
end_date=$(date -jf "%Y%m%d%H%M%S" "$updatedDate" "+%s")
updiffMins=$(( ($start_date - $end_date) / (60) ))
if [[ "$updiffMins" -lt $(($CHECKTIME+1)) ]]; then
if [ ! -d "${FILEPATH}" ]; then
mkdir "${FILEPATH}";
fi
cd "${FILEPATH}"
pwd
echo "updatedDate---$updatedDate" > "ScriptOutput_${currentDate}.txt"
echo "createdDate---$createdDate" >> "ScriptOutput_${currentDate}.txt"
echo "currentDate---$currentDate" >> "ScriptOutput_${currentDate}.txt"
echo "Found after regular checking time -> Docker hub's latest updated image is new; Diff ${updiffMins} mins" >> "ScriptOutput_${currentDate}.txt"
echo "Script is checking for latest updates after every ${CHECKTIME} mins" >> "ScriptOutput_${currentDate}.txt"
echo "Fetching all new"
echo "---------------------------"
if $IS_CONTAINER_RUNNING ; then
echo "Container is running"
else
docker-compose down
echo "Container stopped and removed; Network removed" >> "ScriptOutput_${currentDate}.txt"
fi
echo "Image_Created_Date=$currentDate" > ".env"
echo "ORG=$ORG" >> ".env"
echo "IMGNAME=$IMGNAME" >> ".env"
echo "IMGTAG=$IMGTAG" >> ".env"
echo "CONTNAME=$CONTNAME" >> ".env"
echo "NETWORKNAME=$NETWORKNAME" >> ".env"
docker-compose build --no-cache
echo "Docker Compose built" >> "ScriptOutput_${currentDate}.txt"
if $DO_DOCKER_COMPOSE_UP ; then
docker-compose up -d
echo "Docker services are up now, checked in" >> "ScriptOutput_${currentDate}.txt"
else
echo "Docker services are down, checked in" >> "ScriptOutput_${currentDate}.txt"
fi
Elif [[ "$updatedDate" -gt "$createdDate" ]]; then
echo "Updated is latest"
start_date=$(date -jf "%Y%m%d%H%M%S" "$updatedDate" "+%s")
end_date=$(date -jf "%Y%m%d%H%M%S" "$createdDate" "+%s")
diffMins=$(( ($start_date - $end_date) / (60) ))
if [[ "$BUILDMINS" -lt "$diffMins" ]]; then
if [ ! -d "${FILEPATH}" ]; then
mkdir "${FILEPATH}";
fi
cd "${FILEPATH}"
pwd
echo "updatedDate---$updatedDate" > "ScriptOutput_${currentDate}.txt"
echo "createdDate---$createdDate" >> "ScriptOutput_${currentDate}.txt"
echo "currentDate---$currentDate" >> "ScriptOutput_${currentDate}.txt"
echo "Found after comparing times -> Docker hub's latest updated image is new; Diff ${diffMins} mins" >> "ScriptOutput_${currentDate}.txt"
echo "Actual image built time is less i.e. ${diffMins} mins than MAX expexted BUILD TIME i.e. ${BUILDMINS} mins" >> "ScriptOutput_${currentDate}.txt"
echo "Fetching all new" >> "ScriptOutput_${currentDate}.txt"
echo "-----------------------------"
if $IS_CONTAINER_RUNNING ; then
echo "Container is running"
else
docker-compose down
echo "Container stopped and removed; Network removed" >> "ScriptOutput_${currentDate}.txt"
fi
echo "Image_Created_Date=$currentDate" > ".env"
echo "ORG=$ORG" >> ".env"
echo "IMGNAME=$IMGNAME" >> ".env"
echo "IMGTAG=$IMGTAG" >> ".env"
echo "CONTNAME=$CONTNAME" >> ".env"
echo "NETWORKNAME=$NETWORKNAME" >> ".env"
docker-compose build --no-cache
echo "Docker Compose built" >> "ScriptOutput_${currentDate}.txt"
if $DO_DOCKER_COMPOSE_UP ; then
docker-compose up -d
echo "Docker services are up now" >> "ScriptOutput_${currentDate}.txt"
else
echo "Docker services are down" >> "ScriptOutput_${currentDate}.txt"
fi
Elif [[ "$BUILDMINS" -gt "$diffMins" ]]; then
echo "Docker hub's latest updated image is NOT new; Diff ${diffMins} mins"
echo "Docker images not fetched"
else
echo "Docker hub's latest updated image is NOT new; Diff ${diffMins} mins"
echo "Docker images not fetched"
fi
Elif [[ "$createdDate" -gt "$updatedDate" ]]; then
echo "Created is latest"
start_date=$(date -jf "%Y%m%d%H%M%S" "$createdDate" "+%s")
end_date=$(date -jf "%Y%m%d%H%M%S" "$updatedDate" "+%s")
echo "Docker hub has older docker image than local; Older than $(( ($start_date - $end_date) / (60) ))mins"
fi
echo
echo "------------end---------------"
rm $PIDFILE
Voici mon fichier docker-compose
version: "3.2"
services:
lamp-Alpine:
build:
context: .
container_name: "${CONTNAME}"
image: "${ORG}/${IMGNAME}:${IMGTAG}"
ports:
- "127.0.0.1:80:80"
networks:
- private-network
networks:
private-network:
driver: bridge
BLUF: le défi consiste à trouver le bon point d'insertion pour surveiller les modifications apportées à un conteneur. Ce serait formidable si DockerHub résoudrait ce problème. (Des liens de référentiel ont été mentionnés, mais notez-les lors de leur configuration sur DockerHub - "Déclenchez une construction dans ce référentiel chaque fois que l'image de base est mise à jour sur Docker Hub. Ne fonctionne que pour les images non officielles.")
En essayant de résoudre ce problème moi-même, j'ai lu plusieurs recommandations concernant les Webhooks. Je souhaitais donc développer quelques-unes des solutions que j'ai utilisées.
Utilisez microbadger.com pour suivre les modifications dans un conteneur et utilisez sa fonctionnalité Notification webhook pour déclencher une action. J'ai configuré cela .__ avec zapier.com (mais vous pouvez utiliser n’importe quel service Webhook personnalisable) Pour créer un nouveau problème dans mon référentiel github qui utilise Alpine comme image de base
- Avantages: Vous pouvez consulter les modifications signalées par microbadger dans github avant de prendre des mesures.
- Inconvénients: Microbadger ne vous permet pas de suivre une balise spécifique. On dirait que seuls les derniers titres sont enregistrés.
Suivre le flux RSS pour les commits git dans un conteneur en amont. ex. https://github.com/gliderlabs/docker-Alpine/commits/rootfs/library-3.8/x86_64 . J'ai utilisé zapier.com pour surveiller ce flux et pour déclencher la construction automatique de mon conteneur dans Travis-CI chaque fois que quelque chose est commis. C'est un peu extrême mais vous pouvez changer le déclencheur pour faire d'autres choses, comme ouvrir un problème dans votre dépôt git pour une intervention manuelle.
- Avantages: plus proche d'une pipline automatisée. La génération Travis-CI vérifie simplement si votre conteneur a des problèmes avec ce qui a été commis dans le référentiel d'images de base. C’est à vous de décider si votre service CI prend des mesures supplémentaires.
- Inconvénients: le suivi du flux de validation n'est pas parfait. De nombreuses choses engagées dans le référentiel n'affectent pas la construction de l'image de base. Ne prend pas en compte les problèmes de fréquence/nombre de commits et de limitation des API.
avez-vous essayé ceci: https://github.com/v2tec/watchtower . C'est un outil simple fonctionnant dans un conteneur Docker et surveillant les autres conteneurs; si leur image de base change, elle sera extraite et redéployée.
Une solution simple et géniale est berger
Voici un moyen simple de mettre à jour automatiquement le conteneur docker
Mettez le travail via $ crontab -e:
0 * * * * sh ~/.docker/cron.sh
Créez le répertoire ~/.docker avec le fichier cron.sh:
#!/bin/sh
if grep -Fqe "Image is up to date" << EOF
`docker pull ubuntu:latest`
EOF
then
echo "no update, just do cleaning"
docker system Prune --force
else
echo "newest exist, recompose!"
cd /path/to/your/compose/file
docker-compose down --volumes
docker-compose up -d
fi