- A Docker natív újraindítási szabályzatainak használata a rendszerhibák kezelésére.
- Egyéni szkriptek és cron implementálása nem megfelelő állapotú konténerekhez.
- Fejlett integráció a systemd-vel az indítási és leállítási sorrend vezérléséhez.
- Külső monitorozási alternatívák és eszközök, mint például a Podman Quadlet.
Biztos vagyok benne, hogy veled is megtörtént már ez: fut egy szolgáltatásod Dokkmunkás ami rejtélyes okokból néhány naponta elakad. Hogyan lehet automatikusan újraindítani egy Docker konténert, ha az nem válaszol? Frusztráló lehet kódot vagy konfigurációkat optimalizálni, és semmi sem működik, majd rájönni, hogy egy egyszerű manuális újraindítás megoldja a problémát, és minden egy hétig fut. Az állandó időellenőrzés helyett az ideális megoldás egy olyan rendszer beállítása, amely elvégzi helyetted ezt a piszkos munkát.
A konténerek elérhetőségének kezelése többet jelent annál, mint hogy biztosítsuk azok automatikus elindulását a szerver bekapcsolásakor. ügyeljenek arra, hogy helyesen reagáljanak a kérésekhez. Előfordul, hogy a konténer „élőnek” tűnik a Docker számára, de a benne lévő alkalmazás nem reagál, így megoldásokat kell keresnünk az alapvető démonparaméterektől kezdve az operációs rendszerben létrehozott összetett szolgáltatásokig.
Docker natív újraindítási szabályzatok
A Docker konténer automatikus újraindításának legegyszerűbb módja a jelző használata. --restart konténer indításakor vagy parancs használatakor docker update Ha a konténer már létre van hozva, a Docker számos lehetőséget kínál az igényeidtől függően. Például a szabályzat mindig Ez azt eredményezi, hogy a konténer mindig újraindul, függetlenül attól, hogy a folyamat hibával végződött-e, vagy maga a Docker démon indult újra.
Ha valami sebészetibbre vágysz, hacsak meg nem állítják Sokak számára ez a legjobb választás. Ez a konfiguráció megegyezik az előzővel, azzal a különbséggel, hogy ha karbantartás céljából manuálisan leállítja a konténert, A Docker nem próbálja meg bekapcsolni. automatikusan a szerver újraindítása után, tiszteletben tartva a manuális döntésedet.
Azok számára, akik csak kritikus hibákra reagálva akarnak cselekedni, ott van meghibásodás eseténEz a szabályzat csak akkor indít újraindítást, ha a konténer nem nulla kilépési kóddal fejeződik be. Ezt korlátozhatja is az újrapróbálkozások maximális számának megadásával, megakadályozva, hogy a rendszer végtelen újraindítási ciklusba kerüljön, ha a hiba tartós és kritikus.
Automatizálás „nem megfelelő” konténerek esetén
Itt kezdenek érdekessé válni a dolgok. Előfordul, hogy egy konténer továbbra is „Fel” (be) jelzéssel jelenik meg, de az állapota egészségtelen mert nem felel meg a belső ellenőrzéseknek. A korábbi szabályzatok itt hatástalanok, mivel a folyamat technikailag nem halott. Ennek megoldására végrehajthatjuk az irányelvet ÁLLAPOTFELMÉRÉS a Dockerfile-ban vagy a Docker Compose fájlban egy parancs definiálása (például egy curl egy adott porthoz) annak ellenőrzésére, hogy az alkalmazás válaszol-e.
Miután beállítottuk az állapotfelmérést, létrehozhatunk egy Bash szkript ami néhány percenként lefut a crontab Linuxból. Ennek a szkriptnek kiszűrnie kell azokat a konténereket, amelyek állapota unhealthy vagy azok, akik 128-as hibakóddal léptek ki és futtattak egy docker restart róluk.
Ahhoz, hogy ez zökkenőmentesen működjön, és automatikusan újrainduljon egy Docker konténer, elengedhetetlen, hogy a cron feladatot futtató felhasználó rendelkezzen a szükséges jogosultságokkal. a Docker csoportban szükséges engedélyekIly módon a rendszer 5-10 percenként figyeli a környezetet, és aktivál minden olyan szolgáltatást, amely „zombivá” vált, garantálva a szinte teljes rendelkezésre állást emberi beavatkozás nélkül.
Speciális integráció a systemd-vel
Professzionálisabb környezetben dolgozva érdemes lehet a konténereket a következőképpen használni: natív Linux szolgáltatásokIntegrálás Dokkmunkás A Systemd lehetővé teszi az összetett függőségek kezelését, például annak biztosítását, hogy az adatbázis a webalkalmazás előtt induljon el. Ez fájlok létrehozásával érhető el. .service az útvonalon /etc/systemd/system/.
Tervezhetünk egy ki- és bekapcsolás sorrend Szabályozott. A systemd-hez kapcsolt egyéni szkriptek használatával a konténerek a függőségeik fordított sorrendjében állíthatók le az adatvesztés megelőzése érdekében. A típus használatával oneshot és a konfigurálása targets alkalmas (például multi-user.target o shutdown.target), a szerver kezeli a konténer teljes életciklusát.
Egy másik hatékony lehetőség a Docker konténer automatikus újraindítására, amikor az nem reagál, a jelző használata. --rm a systemd-vel kombinálva. Ez lehetővé teszi a konténer eltávolítását leállításkor, és egy új létrehozását az alapképből indításkor, biztosítva, hogy a A tartály állapotának mindig tisztának és változatlannak kell lennie.az adatmegőrzés kizárólag külső kötetekre való delegálása.
Külső eszközök és modern alternatívák
Ha nem akarsz bajlódni Bash szkriptek írásával, akkor harmadik féltől származó eszközök is elérhetők. Léteznek nyílt forráskódú alkalmazások, amelyeket kifejezetten a konténerek újraindítására terveztek egy megállapított ütemtervEz nagyon hasznos az olyan ismétlődő feladatokhoz, mint az SSL-tanúsítványok megújítása. Hasonlóképpen, olyan eszközök, mint a Üzemidő Kuma Lehetővé teszik a szolgáltatások állapotának vizuális dashboardon történő monitorozását, és értesítéseket küldhetnek a Telegramnak vagy a Gotify-nak, ha valami rosszul megy. Mindegyik nagyon hasznos a Docker-konténer automatikus újraindításához, ha az nem reagál.
Azoknak, akik könnyebb vagy natív alternatívát keresnek, Podman Kiváló választás. Démonmentes architektúrájának és funkcionalitásának köszönhetően NégyesLehetővé teszi egyszerű deklaratív fájlok létrehozását, amelyeket a systemd automatikusan optimalizált szolgáltatásokká alakít, sokkal organikusabb integrációt kínálva, mint a hagyományos Docker.
A szolgáltatások életciklusa feletti teljes kontroll megléte magában foglalja a következők használatának kombinálását újraindítási szabályzatok, állandó megfigyelésen keresztül egészségügyi ellenőrzések és bonyolultabb esetekben a következők támogatása systemd vagy monitorozó eszközök így az infrastruktúra robusztus, és nem függ attól, hogy valaki minden héten manuálisan újraindítsa a szervert.
Technológiára és internetes kérdésekre szakosodott szerkesztő, több mint tíz éves tapasztalattal a különböző digitális médiában. Szerkesztőként és tartalomkészítőként dolgoztam e-kereskedelmi, kommunikációs, online marketing és reklámcégeknél. Írtam közgazdasági, pénzügyi és egyéb ágazati weboldalakra is. A munkám egyben a szenvedélyem is. Most a cikkeimen keresztül Tecnobits, Igyekszem minden újdonságot és új lehetőséget feltárni, amit a technológia világa kínál nekünk nap mint nap életünk javítása érdekében.