Aktualizácia kontajnerov bez výpadku

Aktualizácia kontajnera nie je „stiahni nový image“, ale „nahraď bežiacu verziu novou a vedz sa vrátiť späť“. Rozdiel sa ukáže presne raz: keď nová verzia nenaskočí.

Postup, ktorý funguje

cd /opt/myapp
docker compose pull
docker compose up -d
docker compose ps
docker compose logs -f --tail 100

Compose znovu vytvorí len tie služby, ktorým sa zmenil image, a ostatné nechá na pokoji. Výpadok trvá len pár sekúnd, kým sa kontajner reštartuje.

Ale než to urobíš, splň dve podmienky.

Prvá: verzie sú pripnuté. V súbore musí byť postgres:17.2, nie postgres:latest. Inak ti pull jedného dňa prinesie major verziu, ktorá prepíše formát dát, a návrat späť už nebude možný.

Druhá: záloha je čerstvá. Aktualizácia, ktorá rozbije databázu, ju rozbije nezvratne. Pred zmenou major verzie sprav dump — pozri čo zálohovať.

Výmena bez medzery

Pri webovej službe za reverzným proxy klesne výpadok takmer na nulu, ak má kontajner health check: proxy začne posielať požiadavky až na pripravenú inštanciu.

services:
  app:
    image: ghcr.io/example/app:1.5.0
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://localhost:8080/health"]
      interval: 5s
      timeout: 3s
      retries: 6
      start_period: 20s

docker inspect -f '{{.State.Health.Status}}' <container>

Bez health checku považuje Compose kontajner za pripravený hneď, ako sa spustí proces — kým aplikácia ešte len číta nastavenia a vykonáva migrácie.

Starý image neodstraňuj, kým nová verzia nebeží aspoň hodinu. Návrat späť znamená obnoviť image: ...:1.4.2 a spustiť docker compose up -d, ale len dovtedy, kým je starý image ešte na disku. docker image prune -a hneď po aktualizácii ti tú možnosť vezme.

Návrat späť

sed -i 's|app:1.5.0|app:1.4.2|' compose.yaml
docker compose up -d app
docker compose logs -f --tail 50 app

Ak nová verzia už zmenila schému databázy, vrátiť späť samotný image nestačí — budeš musieť obnoviť zo zálohy. Preto sa major aktualizácie robia v čase pokoja a s overenou zálohou: pozri skúšobné obnovenie.

Automatizácia: opatrne

Watchtower vie aktualizovať kontajnery sám. Pre domáce služby je to pohodlné; pre produkciu je to riziko: aktualizácia príde v noci, rozbije databázu a nikto si to nevšimne. Rozumný kompromis sú len notifikácie:

services:
  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --monitor-only --schedule "0 0 6 * * *"

Dozvieš sa, že vyšla nová verzia, a aktualizuješ ručne v čase, ktorý ti vyhovuje.

Reboot stroja

Systémové balíčky sa aktualizujú oddelene od kontajnerov. Po aktualizácii jadra treba reboot a kontajnery s restart: unless-stopped naskočia samy. Vyskúšaj si to vopred — cez sudo reboot v čase pokoja, nie počas incidentu. Soft reboot z ovládacieho panela funguje, pokiaľ je v systéme nainštalovaný qemu-guest-agent.

Časté chyby

• pull bez up -d. Nový image sa stiahne, ale starý kontajner stále beží.
• Disk zapchatý starými imageami. Raz za mesiac spusti docker image prune — ale nie hneď po aktualizácii. Pozri miesto na disku.
• Aktualizoval si všetko naraz. Niečo sa pokazí — a nevieš, čo. Aktualizuj jednu službu po druhej.
• Nečítal si poznámky k vydaniu. Nekompatibilný konfiguračný súbor je najčastejšia príčina zlyhania po zmene major verzie; rozbor nájdeš v časté problémy s Dockerom.