बेस-इमेज अपडेट होने पर अपने डॉकटर कंटेनरों को अपने आप अपडेट कैसे करें

Question

कहते हैं कि मेरे पास एक तुच्छ कंटेनर है, जिस पर आधारित है ubuntu:latest। अब एक सुरक्षा अद्यतन है और ubuntu:latestdocker रेपो में अपडेट किया गया है।

1. मुझे कैसे पता चलेगा कि मेरी स्थानीय छवि और उसके कंटेनर पीछे चल रहे हैं?

2. क्या स्वचालित रूप से स्थानीय छवियों और कंटेनरों को अपडेट करने के लिए कुछ बेहतरीन अभ्यास है जो डॉकटर रेपो अपडेट का पालन करते हैं, जो अभ्यास में आपको एक पारंपरिक उबंटू-मशीन पर चल रहे अनअटेंडेड-अपग्रेड होने के समान विकल्प देगा।

Comments

मैं शुरुआत से ही इसका जवाब ढूंढ रहा हूं। यह और भी जटिल है। यदि मैं (उदाहरण के लिए) अपाचे स्थापित करता हूं और जो अपडेट हो जाता है, तो आधार-छवि नहीं बदलती है, क्योंकि मैंने इसे बाद में स्थापित किया है। मैं अभी भी अपाचे के लिए ऑटो-अपडेट करना चाहता हूं। मैंने वास्तव में इसके बारे में IRC में पूछा और एक उत्तर के रूप में "अपस्ट्रीम का पालन करें और अपडेट पर पुनर्निर्माण करें" ...

— मैथियास

खुशी है कि मैं केवल एक ही आश्चर्यचकित नहीं हूं। ऐसा लगता है कि विकास और प्रतिलिपि प्रस्तुत करने योग्य समझदार अपडेट तंत्र की तुलना में docker devs के लिए अधिक महत्वपूर्ण है, जो कि हम वर्षों से हैं।

— hbogert

समस्या यह है कि, डॉकटर कंटेनरों के लिए सिर्फ तकनीक है। मुझे लगता है कि इकोसिस्टम को उस समय के आसपास विकसित होने के लिए कुछ समय चाहिए। अन्य समस्याएं हैं जिन्हें लॉगिंग की तरह संबोधित नहीं किया जाता है।

— मथियास

प्रत्येक उत्तर देने वाले का धन्यवाद। मुझे खेद है कि मैं इनाम को विभाजित नहीं कर सका। हालांकि मेरी समस्या का कोई अंतिम समाधान नहीं था, फिर भी आप सभी से अच्छा इनपुट था।

— मथियास

@ मैथियास के लिए, मेरे द्वारा जोड़े गए समाधान में एक स्क्रिप्ट है जो कंटेनर पोस्ट-पुल में स्थापित पैकेजों के लिए सुरक्षा अपडेट की जांच करेगा। आधार छवि की जाँच के लिए इसकी एक अलग स्क्रिप्ट भी है।

— फमरत

Answer 1

इसे करने के तरीकों में से एक यह आपके CI / CD सिस्टम के माध्यम से ड्राइव करना है। एक बार आपकी पैरेंट इमेज बन जाने के बाद, उस पेरेंट के उपयोग से छवियों के लिए आपके git repos को स्कैन करने के लिए कुछ होता है। यदि पाया जाता है, तो आप छवि के नए संस्करणों को टक्कर देने के लिए एक पुल अनुरोध भेजेंगे। यदि सभी परीक्षण पास हो जाते हैं तो पुल अनुरोध, विलय हो जाएगा और आपके पास अद्यतन माता-पिता के आधार पर एक नई बच्चे की छवि होगी। एक उपकरण का एक उदाहरण जो इस दृष्टिकोण को लेता है, वह यहां पाया जा सकता है: https://engineering.salesforce.com/open-sourcing-dockerfile-image-update-6400121c1a75 ।

यदि आप अपनी मूल छवि को नियंत्रित नहीं करते हैं, जैसा कि आप आधिकारिक ubuntuछवि के आधार पर करते हैं , तो आप कुछ टूलिंग लिख सकते हैं जो मूल छवि टैग या चेकसम में परिवर्तन का पता लगाता है (एक ही चीज़, टैग परस्पर नहीं हैं) और आह्वान बच्चों की छवि तदनुसार बनाता है।

Comments

वाह यह एक बड़ा हथौड़ा है, जिसने कहा: जब से मैंने यह सवाल पूछा है, मुझे यह भी पता चला है कि बिल्ड सर्वर इस समस्या से निपटने का स्थान है। मुझे कुछ टूलींग देखकर खुशी हुई। यदि आप जेनेरिक अवधारणाओं में अपने दृष्टिकोण की व्याख्या करते हैं (और आपके सटीक उपकरण / कार्यान्वयन नहीं) और इसे उत्तर में शामिल करें तो मैं संभवतः इसे स्वीकार करूंगा।

— hbogert

धन्यवाद @hbogert मैंने उपरोक्त संपादित किया और इसमें एक विचार भी शामिल है कि अगर आप सार्वजनिक चित्रों के साथ काम कर रहे हैं तो क्या करना है

— Ma3oxuct

Answer 2

हम एक स्क्रिप्ट का उपयोग करते हैं जो यह जांचता है कि क्या चल रहे कंटेनर को नवीनतम छवि के साथ शुरू किया गया है। हम docker image को शुरू करने के लिए upstart init स्क्रिप्ट का भी उपयोग करते हैं।

#!/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

और इनिट लग रहा है

docker run -t -i --name $NAME $im /bin/bash

Comments

इस बहुमूल्य योगदान के लिए बहुत बहुत धन्यवाद। यह बेस इमेज अपडेट करने का एक अच्छा तरीका लगता है। शेष प्रश्न यह है कि आप एक एप्लिकेशन (जैसे अपाचे) को कैसे अपडेट करते हैं जो डॉकटरफाइल में वितरण द्वारा स्थापित किया गया था? या क्या आप केवल तैयार आधार छवियों का उपयोग करते हैं जिन्हें केवल आपके आवेदन कोड (वेबसाइट की तरह) की आवश्यकता होती है?

— मैथियास

हम अपनी छवियों को कॉन्फ़िगर करने के लिए पैकर और कठपुतली का उपयोग करते हैं। हमारी छवियां उनके निर्माण के बाद उत्पादन में जाने के लिए तैयार हैं

— bsuttor

@ मैथियास, मेरे संपादित उत्तर को देखें मेरे पास एक छोटा सा टूल डॉकर है जिसे मैं सभी रनिंग कंटेनरों में लिनक्स (वर्तमान में डेबियन / उबंटू) पैकेज को अपडेट करने के लिए उपयोग कर रहा हूं।

— iTech

यदि किसी छवि का कंटेनर (उदा redis) के समान नाम है , LATEST=`docker inspect --format "{{.Id}}" $IMAGE`तो कंटेनर जानकारी प्राप्त होगी। --type imageइसे ठीक करने के लिए जोड़ें ।

— पैट्रिक फिशर

आपकी पोस्ट के लिए धन्यवाद। मैंने इसे डॉक से चित्र प्राप्त करने के लिए एक लूप के अंदर पूरी चीज़ को लपेटने के लिए संशोधित किया: for IMAGE in $(docker ps --format {{.Image}} -q | sort -u)

— आर्मंड

Answer 3

डॉकटर हब स्वचालित बिल्ड का उपयोग करने के लिए एक 'docker way' होगा । भंडार लिंक जब एक नदी के ऊपर कंटेनर पुनर्निर्माण किया गया है सुविधा अपने कंटेनर के पुनर्निर्माण होगा, और Webhooks सुविधा आपको एक सूचना भेजेंगे।

ऐसा लगता है कि webhooks HTTP POST कॉल तक सीमित हैं। आपको उन्हें पकड़ने के लिए एक सेवा स्थापित करने की आवश्यकता होगी, या हो सकता है कि POST में से किसी एक का उपयोग ईमेल सेवाओं के लिए किया जाए।

मैंने इस पर ध्यान नहीं दिया है, लेकिन नए डॉकटर यूनिवर्सल कंट्रोल प्लेन में अद्यतन कंटेनरों का पता लगाने और फिर से तैनाती के लिए एक सुविधा हो सकती है।

Comments

मुझे AMQP सेवा के लिए एक webhook का निर्माण करना था: github.com/goliatone/rabbithook

— goliatone

अफसोस की बात है कि अपस्ट्रीम ट्रिगर्स अब उपलब्ध नहीं हैं: github.com/docker/hub-feedback/issues/1717 ।

— जुलिएन चास्टांग

Answer 4

आप वॉचटावर का उपयोग उस छवि के अपडेट के लिए देखने के लिए कर सकते हैं , जिससे कंटेनर तुरंत चालू हो और स्वचालित रूप से अपडेट खींचे और अपडेट की गई छवि का उपयोग करके कंटेनर को पुनरारंभ करें। हालाँकि, अपनी स्वयं की कस्टम छवियों के पुनर्निर्माण की समस्या को हल नहीं करता है जब इसके ऊपर आधारित अपस्ट्रीम छवि में बदलाव होता है। आप इसे दो-भाग की समस्या के रूप में देख सकते हैं: (1) यह जानते हुए कि जब एक अपस्ट्रीम छवि अपडेट की गई है, और (2) वास्तविक छवि पुनर्निर्माण कर रही है। (1) काफी आसानी से हल किया जा सकता है, लेकिन (2) आपके स्थानीय बिल्ड वातावरण / प्रथाओं पर बहुत कुछ निर्भर करता है, इसलिए इसके लिए एक सामान्यीकृत समाधान बनाना शायद बहुत कठिन है।

यदि आप डॉकर हब के स्वचालित बिल्ड का उपयोग करने में सक्षम हैं , तो रिपॉजिटरी लिंक सुविधा का उपयोग करके पूरी समस्या को अपेक्षाकृत सफाई से हल किया जा सकता है , जो आपको लिंक किए गए रिपॉजिटरी (शायद एक अपस्ट्रीम एक) को अपडेट करने पर स्वचालित रूप से पुन: ट्रिगर करने देता है। स्वचालित निर्माण होने पर आपको सूचित करने के लिए आप एक webhook भी कॉन्फ़िगर कर सकते हैं । यदि आप एक ईमेल या एसएमएस सूचना चाहते हैं, तो आप वेब को IFTTT मेकर से जोड़ सकते हैं । मुझे IFTTT उपयोगकर्ता इंटरफ़ेस भ्रामक लगता है, लेकिन आप Docker webhook को https://maker.ifttt.com/trigger/docker_xyz_image_built / with / key / पर पोस्ट करने के लिए कॉन्फ़िगर करेंगे your_key।

यदि आपको स्थानीय रूप से निर्माण करने की आवश्यकता है, तो आप कम से कम सूचनाओं की समस्या को हल कर सकते हैं जब एक अपस्ट्रीम छवि को आपके रेपो (एस) से जुड़े डॉकटर हब में एक डमी रेपो बनाकर अपडेट किया जाता है। डमी रेपो का एकमात्र उद्देश्य एक वेबहुक को ट्रिगर करना होगा जब इसे फिर से बनाया जाता है (जिसका अर्थ है कि इसके लिंक किए गए रिपोज में से एक को अपडेट किया गया था)। यदि आप इस वेबहुक को प्राप्त करने में सक्षम हैं, तो आप इसका उपयोग अपने पक्ष में पुनर्निर्माण के लिए भी कर सकते हैं।

Comments

वॉचटावर हालांकि डॉक सॉकेट का उपयोग करता है। एक सुरक्षा दृष्टिकोण से जो मेजबान मशीन को रूट एक्सेस दे रहा है।

— जोजी

इसके अलावा, वॉचटावर डॉकर हब के अलावा निजी रिपॉजिटरी से छवियों को अपडेट करने में सक्षम नहीं लगती है। हमारे लिए एक बुमेर जो Azure का उपयोग करता है।

— थॉमस आइड

आप निजी चरनों का उपयोग करके REPO_USERऔर REPO_PASSपर्यावरण चर का उपयोग कर सकते हैं । अधिक जानकारी के लिए वॉचटावर से readme.md पर एक नज़र डालें: github.com/v2tec/watchtower#usage

— एलेजांद्रो नॉर्ट्स

वॉर्निंग ऑफ वॉच, वॉचटावर को उसके अनुरक्षक द्वारा छोड़ दिया गया है, और डॉकहर्ब में छवि गितुब में एक के साथ भी अद्यतित नहीं है।

— XanderStrike

गुम्मट रेपो लगता है कि regrrr / गुम्मट के लिए चले गए हैं । और Dockerhub पर लिंक किए गए स्वचालित बिल्ड के साथ कुछ समस्याएँ हैं, जैसा कि इसी तरह के प्रश्न पर इस उत्तर द्वारा बताया गया है ।

— चरखी

Answer 5

मेरे पास एक ही मुद्दा था और सोचा था कि इसे unattended-upgradeरोज़ाना कॉल करने वाली क्रोन नौकरी से हल किया जा सकता है ।

मेरा इरादा इसे एक स्वचालित और त्वरित समाधान के रूप में रखना है ताकि यह सुनिश्चित हो सके कि उत्पादन कंटेनर सुरक्षित और अद्यतन है क्योंकि यह मुझे अपनी छवियों को अपडेट करने और नवीनतम सुरक्षा अपडेट के साथ एक नया डॉकटर छवि तैनात करने में कुछ समय ले सकता है।

गितुब हुक के साथ छवि निर्माण और तैनाती को स्वचालित करना भी संभव है

मैंने एक बुनियादी डॉकटर छवि बनाई है, जो रोज़ाना सुरक्षा अपडेट की स्वचालित रूप से जाँच और स्थापना करता है (सीधे द्वारा चला सकता है docker run itech/docker-unattended-upgrade)।

मुझे यह जांचने के लिए एक और अलग दृष्टिकोण भी आया कि क्या कंटेनर को अपडेट की आवश्यकता है।

मेरा पूरा कार्यान्वयन:

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

सहायक स्क्रिप्ट

इंस्टॉल

#!/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"]

शुरू

#!/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

संपादित करें

मैंने एक छोटा टूल डॉक-रन विकसित किया जो डॉक कंटेनर के रूप में चलता है और इसे सभी या चयनित रनिंग कंटेनरों के अंदर पैकेज को अपडेट करने के लिए इस्तेमाल किया जा सकता है, इसका उपयोग किसी भी मनमाने कमांड को चलाने के लिए भी किया जा सकता है।

निम्नलिखित कमांड के साथ आसानी से परीक्षण किया जा सकता है:

docker run --rm -v /var/run/docker.sock:/tmp/docker.sock itech/docker-run exec

जो डिफ़ॉल्ट रूप से dateसभी चल रहे कंटेनरों में कमांड निष्पादित करेगा और परिणाम प्रदर्शित करेगा। यदि आप updateइसके बजाय से गुजरते हैं, execतो सभी चलने वाले कंटेनरों में इसका apt-get updateपालन ​​किया जाएगाapt-get upgrade -y

Comments

अनअटेंडेड-अपग्रेड के लिए मेरा संदर्भ केवल गैर-docker वातावरण में सादृश्य दिखाने के लिए था। मेरा इरादा इस डॉकटर तरीके को हल करना है (यदि यह महासागर मौजूद है।) एक कंटेनर में एक अतिरिक्त प्रक्रिया होने से डूडल का उद्देश्य समाप्त हो जाता है। यह अपस्ट्रीम के बीच देरी की समस्या को उनकी छवि को अपडेट करता है और आप, उपयोगकर्ता, वास्तव में इसे आपके वर्तमान कंटेनर के ऊपर दर्शाते हैं। यद्यपि यह 1 दिन का समय ले सकता है और साथ ही अनअटेंडेड-अपग्रेड भी कर सकता है, इसलिए .. इसके अलावा जीथब का संदर्भ गैर-संतोषजनक है, क्योंकि अपडेट तंत्र अब होस्ट ओएस पर बहुत अधिक निर्भर है।

— hbogert

"डॉकटर तरीका" आपको उसी कंटेनर पर अन्य प्रक्रियाओं को चलाने से नहीं रोकता है यदि वे कसकर संबंधित हैं और स्केलेबिलिटी अड़चन पैदा नहीं करेंगे। और यह विशेष उपयोग का मामला एक अच्छा उदाहरण है जब आप किसी अन्य चल रही प्रक्रिया के साथ एक कंटेनर रख सकते हैं। (उदाहरण के लिए gitlab के लिए छवि देखें क्योंकि यह एक ही कंटेनर पर कई अनिवार्य प्रक्रियाएं चलाता है )।

— iTech

मैं अपडेट तंत्र को किसी छवि के मुख्य कार्य से संबंधित नहीं कहूंगा। यह समाधान एक पारंपरिक मशीन पर प्रत्येक एप्लिकेशन को एक पैकेज मैनेजर पर बोझ रखने के बजाय अपने स्वयं के अपडेट तंत्र को देने जैसा है। हालांकि यह एक समाधान है, यह मेरे सवाल का जवाब नहीं देता है, जो स्वचालित रूप से स्थानीय छवियों को अपडेट कर रहा है और फिर, कंटेनरों को फिर से होना चाहिए। कंटेनरों में खुद को अपडेट करने के साथ हम फिर से बहुत सारी स्थिति का परिचय दे रहे हैं, जिसका हमें कोई अंदाजा नहीं है, जो कि docker way (फिर से नकल) के खिलाफ है।

— hbogert

आपको डॉकटर की तुलना में कुछ उच्च-स्तर की आवश्यकता हो सकती है जैसे कि Kubernetesबड़े बुनियादी ढांचे की तैनाती के लिए उपयोगी है, लेकिन यह अभी भी Google द्वारा भारी विकास के अधीन है। फिलहाल, आप इसे काफी सरल तरीके से एंज़िबल जैसे प्रावधान टूल के साथ स्वचालित कर सकते हैं।

— iTech

आपका उद्धृत "भिन्न दृष्टिकोण" वह हो सकता है जो मैं खोज रहा था। आपका अपना योगदान "वसा कंटेनर" के लिए एक व्यवहार्य विकल्प की तरह दिखता है। मैं निश्चित रूप से थोड़ा और आगे देखूंगा, आपके उत्तर के लिए धन्यवाद।

— मथियास

Answer 6

आपको नहीं पता होगा कि आपका कंटेनर बिना डॉक पुल को चलाने के पीछे है । तो फिर तुम नहीं करनी पुनर्निर्माण या संयोजित अपनी छवि।

docker pull image:tag
docker-compose -f docker-compose.yml -f production.yml up -d --build

कमांड को एक स्क्रिप्ट में अपग्रेड को पूरा करने के लिए आवश्यक कुछ और के साथ रखा जा सकता है, हालांकि एक उचित कंटेनर को अतिरिक्त कुछ की आवश्यकता नहीं होगी।

Comments

1: ठीक है, लेकिन फिर मुझे अपने सभी स्थानीय चित्रों को देखना होगा, उनके आधार चित्र प्राप्त करने होंगे, उन्हें खींचना होगा। फिर उन छवियों का पुनर्निर्माण करें जिनके आधार चित्र बदल गए हैं। फिर उन कंटेनरों को रोकें जिनकी छवि बदली हुई है और कंटेनरों को run डॉक रन ’और आवश्यक मापदंडों के साथ फिर से बनाना है। यह पीढ़ी मैनुअल लगता है। लेकिन अगर यह यथास्थिति है, तो मैं जवाब स्वीकार करूंगा।

— hbogert

कृपया स्वीकार करने से पहले प्रतीक्षा करें। शायद वहाँ कुछ है। मैं 6 महीने के लिए docker का उपयोग कर रहा हूं, लेकिन नवीनतम घटनाओं के साथ नहीं रहा है।

— श्मनक्ल

किसी तरह, आंतरिक रूप से, डॉकर अपनी 'कैशिंग' क्षमता का प्रदर्शन करने के लिए छवियों की तुलना करने में सक्षम है। शायद आप THAT का लाभ उठाने का एक तरीका पा सकते हैं। दूसरे शब्दों में, यह देखने के लिए जांचें कि क्या अंतर्निहित छवियां (आधार के लिए सभी तरह से) बदल गई हैं और फिर पुनर्निर्माण के लिए एक प्रक्रिया को ट्रिगर करें। दुर्भाग्य से, कैशिंग उस मामले में आपकी मदद नहीं करेगा: पूरी छवि को फिर से बनाया जाएगा क्योंकि आधार छवि बदल गई है।

— थॉमस पार्किन

Answer 7

डॉकर छवियों के लिए निर्भरता प्रबंधन एक वास्तविक समस्या है। मैं एक टीम का हिस्सा हूं जिसने कंटेनर छवियों की निगरानी और मेटाडेटा का निरीक्षण करके इसकी सहायता के लिए एक उपकरण, माइक्रोबैगर बनाया है । इसकी एक विशेषता यह है कि आपको एक अधिसूचना वेबहूक सेट करने की सुविधा मिलती है, जिसे तब कॉल किया जाता है जब आप जिस छवि में रुचि रखते हैं (उदाहरण के लिए आधार छवि) को बदलते हैं।

Answer 8

यहां बहुत सारे उत्तर हैं, लेकिन उनमें से कोई भी मेरी जरूरतों के अनुकूल नहीं है। मैं प्रश्नकर्ता के # 1 प्रश्न का वास्तविक उत्तर चाहता था। मुझे कैसे पता चलेगा जब एक छवि हबडॉकर.कॉम पर अपडेट की जाती है?

नीचे दी गई स्क्रिप्ट को प्रतिदिन चलाया जा सकता है। पहली बार चलाने पर, यह टैग्स की आधार रेखा प्राप्त करता है और एचयूबी रजिस्ट्री से तारीखों को अद्यतन करता है और उन्हें स्थानीय रूप से बचाता है। तब से, हर बार इसे चलाने के बाद यह नए टैग और अद्यतन तिथियों के लिए रजिस्ट्री की जांच करता है। चूंकि यह परिवर्तन हर बार एक नई छवि मौजूद है, यह हमें बताता है कि क्या आधार छवि बदल गई है। यहाँ स्क्रिप्ट है:

#!/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;

आप DATAPATHशीर्ष पर चर को बदलना चाहेंगे , और अपनी आवश्यकताओं के अनुरूप ईमेल अधिसूचना कमांड को अंत में बदल देंगे। मेरे लिए, मेरे पास एक अन्य नेटवर्क पर सर्वर में एसएसएच है जहां मेरा एसएमटीपी स्थित है। लेकिन आप आसानी से mailकमांड का उपयोग कर सकते हैं ।

अब, आप स्वयं कंटेनरों के अंदर अद्यतन पैकेजों के लिए भी जाँच करना चाहते हैं। जब आपके कंटेनर काम कर रहे हों तो यह वास्तव में "पुल" करने की तुलना में अधिक प्रभावी है। यहाँ स्क्रिप्ट है कि बंद खींचने के लिए:

#!/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

Comments

पहली स्क्रिप्ट में mkdir शायद होना चाहिए: mkdir -p इसके अलावा, पहली स्क्रिप्ट VAR2 के विरुद्ध VAR2 से तुलना करती है, मान लें कि नए के खिलाफ OLD की तुलना करनी चाहिए। यदि सही है, तो इसका मतलब है कि यह स्क्रिप्ट वास्तव में वह नहीं करेगी जो ओपी चाहता है, क्योंकि यह पहली बार स्थापित होने के समय चलाया गया था। यही है, यह वास्तव में कुछ भी निर्धारित नहीं कर रहा है कि क्या स्थापित किया गया है, अगर परिणाम पिछले रनों से अलग है ...

— जोजी

Answer 9

एक अन्य दृष्टिकोण यह मान सकता है कि आपकी आधार छवि बहुत जल्दी (और ऐसा होने की संभावना है) के पीछे हो जाती है, और समय-समय पर आपके आवेदन की एक और छवि निर्माण को बाध्य करती है (जैसे कि हर सप्ताह) और फिर इसे फिर से तैनात करें यदि यह बदल गया है।

जहां तक ​​मैं बता सकता हूं, आधिकारिक डेबियन या जावा जैसी लोकप्रिय आधार छवियां सुरक्षा सुधारों को पूरा करने के लिए अपने टैग को अपडेट करती हैं, इसलिए टैग अपरिवर्तनीय नहीं हैं (यदि आप उस की एक मजबूत गारंटी चाहते हैं तो आपको संदर्भ का उपयोग करने की आवश्यकता है [छवि: @digest ], हाल के डॉकटर संस्करणों में उपलब्ध है। इसलिए, यदि आप अपनी छवि का निर्माण करने वाले थे docker build --pull, तो आपके आवेदन को आपके द्वारा संदर्भित की जा रही आधार छवि टैग का नवीनतम और महानतम होना चाहिए।

चूँकि उत्परिवर्तित टैग भ्रमित कर सकते हैं, इसलिए जब भी आप ऐसा करते हैं तो हर बार आपके आवेदन के संस्करण की संख्या बढ़ाना सबसे अच्छा होता है ताकि कम से कम आपकी तरफ की चीजें साफ हों।

इसलिए मुझे यकीन नहीं है कि पिछले उत्तरों में से एक में सुझाई गई स्क्रिप्ट काम करती है, क्योंकि यह आपके आवेदन की छवि को फिर से नहीं बनाता है - यह सिर्फ आधार छवि टैग को अपडेट करता है और फिर यह कंटेनर को पुनरारंभ करता है, लेकिन नया कंटेनर अभी भी संदर्भित करता है पुरानी आधार छवि हैश।

मैं कंटेनर में क्रोन-प्रकार की नौकरियों (या किसी अन्य प्रक्रिया को चलाने के लिए, जब तक कि वास्तव में आवश्यक न हो) की वकालत नहीं करूंगा क्योंकि यह प्रति कंटेनर केवल एक प्रक्रिया को चलाने के मंत्र के खिलाफ जाता है (इस बारे में विभिन्न तर्क हैं कि यह बेहतर क्यों है, इसलिए मैं ' मैं यहाँ नहीं जा रहा हूँ)।

Answer 10

मैं पूरे सवाल में नहीं जा रहा हूं कि आप उत्पादन में अपडेट नहीं करना चाहते हैं या नहीं (मुझे नहीं लगता)। मैं इसे यहाँ संदर्भ के लिए छोड़ रहा हूँ अगर कोई इसे उपयोगी पाता है। अपने टर्मिनल में निम्नलिखित कमांड के साथ नवीनतम संस्करण के लिए अपने सभी डॉकटर छवियों को अपडेट करें:

# docker images | awk '(NR>1) && ($2!~/none/) {print $1":"$2}' | xargs -L1 docker pull

Comments

आदेश सभी छवियों को अपडेट करने के लिए उपयोगी है, लेकिन यह उत्पादन में चल रहे कुछ भी नहीं बदलता है। कंटेनर अभी भी पुरानी छवियों से उपजी हैं, जो अब अप्रकाशित हैं।

— कोई नहीं

सच। और यहाँ किताबों के लिए एक और है ... # docker system prune -a --volumes -fपुरानी (झूलने वाली) छवियों, संस्करणों आदि को साफ करने के लिए उपयोग करें

— मेफ़रदती

Answer 11

अद्यतन: डिपेंडैबोट का उपयोग करें - https://dependabot.com/docker/

BLUF: कंटेनर में परिवर्तन की निगरानी के लिए सही प्रविष्टि बिंदु खोजना चुनौती है। यह बहुत अच्छा होगा अगर डॉकरहब इसका समाधान करेगा। (रिपॉजिटरी लिंक्स का उल्लेख किया गया है, लेकिन उन्हें डॉकहर्ब पर सेट करते समय ध्यान दें - "ट्रिगर इस बिल्ड में एक रिपॉजिटरी है, जब भी डॉकर हब पर बेस इमेज अपडेट होती है। केवल गैर-आधिकारिक इमेज के लिए काम करता है।" )

अपने आप को हल करने की कोशिश करते हुए, मैंने वेबहूक के लिए कई सिफारिशें देखीं, इसलिए मैं उन कुछ समाधानों पर विस्तार से जानना चाहता था जिनका मैंने उपयोग किया है।

1. एक कंटेनर में परिवर्तनों को ट्रैक करने के लिए microbadger.com का उपयोग करें और एक कार्रवाई को ट्रिगर करने के लिए नोटिफिकेशन वेबहुक सुविधा का उपयोग करें। मैंने zapier.com के साथ इसे स्थापित किया (लेकिन आप किसी भी अनुकूलन योग्य वेबहूक सेवा का उपयोग कर सकते हैं) मेरी गितुब रिपॉजिटरी में एक नया मुद्दा बनाने के लिए जो अल्पाइन को आधार छवि के रूप में उपयोग करता है।

   • पेशेवरों: आप कार्रवाई करने से पहले जीथब में माइक्रोबैगर द्वारा रिपोर्ट किए गए परिवर्तनों की समीक्षा कर सकते हैं।
   • विपक्ष: माइक्रोबैगर आपको एक विशेष टैग को ट्रैक करने की अनुमति नहीं देता है। ऐसा लगता है कि यह केवल 'नवीनतम' को ट्रैक करता है।

2. ट्रैक अप के लिए आरएसएस फ़ीड ट्रैक एक अपस्ट्रीम कंटेनर को करता है। पूर्व। https://github.com/gliderlabs/docker-alpine/commits/rootfs/library-3.8/x86_64 । मैंने इस फ़ीड की निगरानी करने और ट्रैविस-सीआई में अपने कंटेनर के एक स्वचालित निर्माण को ट्रिगर करने के लिए कभी भी कुछ भी प्रतिबद्ध होने के लिए zapier.com का उपयोग किया। यह थोड़ा चरम है लेकिन आप अन्य चीजों को करने के लिए ट्रिगर को बदल सकते हैं जैसे कि मैनुअल हस्तक्षेप के लिए अपने गिट रिपॉजिटरी में एक मुद्दा खोलें।

   • पेशेवरों: एक स्वचालित पाइपलाइन के करीब। ट्रैविस-सीआई सिर्फ यह जांचने के लिए निर्माण करता है कि आपके कंटेनर में बेस इमेज रिपॉजिटरी के लिए जो कुछ भी था उसके साथ समस्या है। यदि आपकी सीआई सेवा आगे कोई कार्रवाई करती है तो यह आपके ऊपर है।
   • विपक्ष: प्रतिबद्ध फ़ीड पर नज़र रखना सही नहीं है। बहुत सारी चीजें रिपॉजिटरी के लिए प्रतिबद्ध हैं जो आधार छवि के निर्माण को प्रभावित नहीं करती हैं। आवृत्ति / कमिट की संख्या और किसी भी एपीआई थ्रॉटलिंग के साथ किसी भी मुद्दे को ध्यान में नहीं रखता है।

Answer 12

मेरे उत्तर का संकलन:

1. कंटेनर टैग के साथ चलाए जाते हैं।
2. एक ही टैग को अलग-अलग छवि UUID को इंगित किया जा सकता है, जैसा कि हम कृपया / उपयुक्त महसूस करते हैं।
3. एक छवि के लिए किए गए अद्यतन एक नई छवि परत के लिए प्रतिबद्ध हो सकते हैं

पहुंच

1. सुरक्षा-पैच अपडेट स्क्रिप्ट के साथ पहले सभी कंटेनरों का निर्माण करें
2. निम्नलिखित के लिए एक स्वचालित प्रक्रिया बनाएँ
   • कमांड के रूप में सुरक्षा पैच स्क्रिप्ट के साथ नए कंटेनर में एक मौजूदा छवि चलाएँ
   • के रूप में छवि के लिए प्रतिबद्ध परिवर्तन
     • मौजूदा टैग -> एक के बाद एक कंटेनरों को पुनः आरंभ करने के बाद
     • नया संस्करण टैग -> कुछ कंटेनरों को नए टैग के साथ बदलें -> मान्य करें -> सभी कंटेनरों को नए टैग में ले जाएं

इसके अतिरिक्त, आधार छवि को उन्नत किया जा सकता है / कंटेनर को एक पूर्ण नई आधार छवि के साथ नियमित अंतराल पर बनाया जा सकता है, क्योंकि अनुरक्षण आवश्यक लगता है

लाभ

1. हम नई सुरक्षा पैच छवि बनाते समय छवि के पुराने संस्करण को संरक्षित कर रहे हैं, इसलिए यदि आवश्यक हो तो हम पिछली चलने वाली छवि को रोलबैक कर सकते हैं
2. हम डॉकटर कैश को संरक्षित कर रहे हैं, इसलिए कम नेटवर्क ट्रांसफर (केवल परिवर्तित परत तार पर मिलती है)
3. अपग्रेड प्रक्रिया को ठेस लगने से पहले स्टेजिंग में मान्य किया जा सकता है
4. यह एक नियंत्रित प्रक्रिया हो सकती है, इसलिए सुरक्षा पैच तभी आवश्यक / आवश्यक समझा जा सकता है जब धकेल दिया जाए।

Comments

एक उत्पादन वातावरण पर, हालांकि वे सुरक्षा अद्यतन हैं, मुझे संदेह है कि आप अप्राप्य अद्यतन करना चाहते हैं! यदि अप्राप्य अद्यतन होना आवश्यक है, तो प्रक्रिया को नियमित अंतराल पर (उचित रूप में) क्रोन जॉब के रूप में चलाया जा सकता है।

— फणी

मेरा आधार यह है कि सुरक्षा अद्यतन अपस्ट्रीम / बेस इमेज से आने चाहिए।

— hbogert

@hbogert मैं यह कहूंगा कि सिद्धांत और व्यवहार के बीच भेदभाव की एक अच्छी रेखा है। जब चीजें व्यवहार में आती हैं, तो कई बाहरी पहलुओं को ध्यान में रखना होगा, जैसे: लागत (न केवल डॉलर मूल्य, बल्कि समय भी) कार्यान्वयन के साथ जुड़ा हुआ है।

— फणी

Answer 13

उपरोक्त उत्तर भी सही हैं

दो दृष्टिकोण हैं

1. Webhooks का प्रयोग करें
2. हर विशिष्ट मिनट के लिए स्क्रिप्ट चलाएँ, डॉक छवियों की ताज़ा पुल पाने के लिए

मैं सिर्फ स्क्रिप्ट साझा कर रहा हूं हो सकता है कि यह आपके लिए उपयोगी हो! आप इसे क्रोनजोब के साथ उपयोग कर सकते हैं, मैंने ओएसएक्स पर सफलतापूर्वक प्रयास किया

#!/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

यहाँ मेरे docker- रचना फ़ाइल है

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

Answer 14

यहां डॉकटर कंटेनर को स्वचालित रूप से अपडेट करने का सबसे सरल तरीका है

के माध्यम से काम रखो $ crontab -e:

0 * * * * sh ~/.docker/cron.sh

~/.dockerफ़ाइल के साथ dir बनाएँ 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

Answer 15

: यदि आप इस की कोशिश की है https://github.com/v2tec/watchtower । यह एक साधारण उपकरण है जो डॉकटर कंटेनर में चल रहा है जो अन्य कंटेनरों को देख रहा है, यदि उनकी आधार छवि बदल गई है, तो यह पुल और रीडेपल हो जाएगा।

Answer 16

एक सरल और महान समाधान चरवाहा है

Comments

iiuc, यह सामान्य अर्थों में मदद नहीं करता है, क्योंकि यह झुंड के लिए युग्मित है और केवल अपस्ट्रीम को पुनरारंभ करता है, जबकि हम अपस्ट्रीम परिवर्तनों पर प्रतिक्रिया करना, पुनर्निर्माण करना चाहते हैं, और बस पुनः आरंभ नहीं करते हैं।

— 8

ऐसा लगता है कि आपको सीआई पाइपलाइन में कुछ करना चाहिए

— user672009