Kako samodejno znova zagnati Dockerjev vsebnik, ko se preneha odzivati

Prepričan sem, da se vam je to že zgodilo: imate delujočo storitev Docker ki se iz skrivnostnih razlogov zatakne vsakih nekaj dni. Kako samodejno znova zagnati Dockerjev vsebnik, ko se preneha odzivati? Frustrirajoče je poskušati optimizirati kodo ali konfiguracije in nič ne deluje, le da nato ugotoviš, da preprost ročni ponovni zagon reši težavo in ohrani vse v teku še en teden. Namesto nenehnega preverjanja časa je idealna rešitev nastavitev sistema, ki to umazano delo opravi namesto tebe.

Upravljanje razpoložljivosti vsebnikov vključuje več kot le zagotavljanje njihovega samodejnega zagona ob vklopu strežnika. poskrbite, da se pravilno odzovejo na zahteve. Včasih se zdi, da je vsebnik Dockerju "živ", vendar se aplikacija v njem ne odziva, zaradi česar smo prisiljeni iskati rešitve, od osnovnih parametrov demona do ustvarjanja kompleksnih storitev v operacijskem sistemu.

Pravilniki o izvornem ponovnem zagonu Dockerja

Najenostavnejši način za samodejni ponovni zagon Dockerjevega vsebnika je z uporabo zastavice --restart pri zagonu vsebnika ali uporabi ukaza docker update Če je vsebnik že ustvarjen, Docker ponuja več možnosti, odvisno od vaših potreb. Na primer, pravilnik vedno Zaradi tega se bo vsebnik vedno znova zagnal, ne glede na to, ali se je proces končal z napako ali pa se je znova zagnal sam Dockerjev demon.

Če imate raje kaj bolj kirurškega, razen če je ustavljeno To je za mnoge najboljša izbira. Ta konfiguracija je enaka prejšnji, le da če ročno ustavite vsebnik zaradi vzdrževanja, Docker ga ne bo poskušal vklopiti. samodejno po ponovnem zagonu strežnika, pri čemer se upošteva vaša ročna odločitev.

Za tiste, ki želijo ukrepati le kot odziv na kritične napake, obstaja ob okvariTa pravilnik sproži ponovni zagon le, če se vsebnik zaključi z izhodno kodo, ki ni enaka nič. To lahko celo omejite z dodajanjem največjega števila ponovnih poskusov, s čimer preprečite, da bi sistem vstopil v neskončno zanko ponovnega zagona, če je napaka trajna in kritična.

Avtomatizacija za "nezdrave" posode

Tu postanejo stvari zanimive. Včasih je posoda še vedno prikazana kot »Vklopljena« (»Up«), vendar je njeno stanje nezdravo ker ne opravi notranjih preverjanj. Prejšnje politike so tukaj neučinkovite, saj postopek tehnično ni mrtev. Da bi to rešili, lahko izvedemo direktivo PREGLED ZDRAVJA v datoteki Dockerfile ali v datoteki Docker Compose, ki definira ukaz (kot je curl na določena vrata), da preverite, ali se aplikacija odziva.

Ko imamo nastavljen pregled stanja, lahko ustvarimo Bash skripta ki se izvaja vsakih nekaj minut z uporabo crontab iz Linuxa. Ta skripta bi morala filtrirati vsebnike, ki so v stanju unhealthy ali tisti, ki so zapustili program s kodo napake 128 in zagnali docker restart o njih.

Da bi to delovalo nemoteno in se samodejno znova zagnal Dockerjev vsebnik, je bistveno, da ima uporabnik, ki izvaja opravilo cron, potrebna dovoljenja. dovoljenja, potrebna v skupini dockerNa ta način sistem spremlja okolje vsakih 5 ali 10 minut in aktivira vse storitve, ki so postale "zombi", kar zagotavlja skoraj popolno razpoložljivost brez človeškega posredovanja.

Napredna integracija s systemd

Pri delu v bolj profesionalnih okoljih boste morda želeli, da se vaši kontejnerji obnašajo tako, kot izvorne storitve LinuxaIntegriraj Docker Systemd vam omogoča upravljanje kompleksnih odvisnosti, na primer zagotavljanje, da se baza podatkov zažene pred spletno aplikacijo. To dosežete z ustvarjanjem datotek .service na poti /etc/systemd/system/.

Lahko oblikujemo zaporedje vklopa in izklopa Nadzorovano. Z uporabo skriptov po meri, povezanih s systemd, je mogoče zaustaviti vsebnike v obratnem vrstnem redu njihovih odvisnosti, da se prepreči poškodba podatkov. Z uporabo tipa oneshot in konfiguriranje targets primerno (kot npr. multi-user.target o shutdown.target), strežnik upravlja celoten življenjski cikel vsebnika.

Druga zmogljiva možnost za samodejni ponovni zagon Dockerjevega vsebnika, ko se preneha odzivati, je uporaba zastavice --rm v kombinaciji s systemd. To omogoča, da se vsebnik ob zaustavitvi odstrani, ob zagonu pa se iz osnovne slike ustvari nov, kar zagotavlja, da Stanje posode mora biti vedno čisto in nespremenjeno.delegiranje vztrajnosti podatkov izključno na zunanje nosilce podatkov.

Zunanja orodja in sodobne alternative

Če se ne želite ukvarjati s pisanjem Bash skriptov, so na voljo orodja drugih ponudnikov. Obstajajo odprtokodne aplikacije, posebej zasnovane za ponovni zagon vsebnikov na podlagi ustaljen urnikTo je zelo uporabno za ponavljajoča se opravila, kot je obnavljanje SSL-certifikatov. Prav tako orodja, kot so Čas delovanja Kuma Omogočajo vam spremljanje zdravja storitev prek vizualne nadzorne plošče in pošiljanje obvestil v Telegram ali Gotify, če gre kaj narobe. Vsi so zelo uporabni za samodejni ponovni zagon Dockerjevega vsebnika, ko se ta preneha odzivati.

Za tiste, ki iščejo lažjo ali domačo alternativo, Podman To je odlična možnost. Zaradi svoje arhitekture brez demonov in funkcionalnosti KvadletOmogoča vam ustvarjanje preprostih deklarativnih datotek, ki jih systemd samodejno pretvori v optimizirane storitve, kar ponuja veliko bolj organsko integracijo kot tradicionalni Docker.

Popoln nadzor nad življenjskim ciklom vaših storitev vključuje kombiniranje uporabe pravilnike za ponovni zagon, stalen nadzor skozi zdravstveni pregledi in v bolj zapletenih primerih podporo systemd ali orodja za spremljanje tako da je vaša infrastruktura robustna in ni odvisna od tega, ali se nekdo vsak teden spomni ročno znova zagnati strežnik.