Docker compose és a tűzfal

Modul 9: Docker és docker compose · Olvasási idő: 12 perc

Tanulási cél: A lecke végére Ön szolgáltatásokat tud leírni egy compose-fájlban, el tudja indítani, frissíteni és leállítani őket, és el tudja magyarázni, miért kerülik meg a Docker közzétett portjai az ufw-t, és hogyan előzheti ezt meg.

Kulcsfogalmak: compose.yaml, services, image, ports, volumes, environment, .env, restart, networks, depends_on, healthcheck, docker compose up -d, pull, logs, down, elavult version:, Docker és ufw, DOCKER-USER, közzététel a 127.0.0.1 címen, titkok, docker.sock

Miért compose?

A docker run paranccsal (lecke 9.2) egyetlen konténert indít el, egy hosszú, opciókkal teli sorral. Egy valódi alkalmazás azonban gyakran több konténerből áll: egy programból, egy adatbázisból és egy reverse proxyból. Ha ezeket a sorokat fejben kell tartania, és újraindítás vagy frissítés után újra be kell gépelnie, egyszer biztosan hiba csúszik be.

A Docker Compose egy alkalmazás összes konténerét egyetlen fájlban írja le: compose.yaml. Ezt a fájlt egy saját mappába teszi, például /srv/status/compose.yaml, és mindent a docker compose paranccsal kezel. A fájl egyben a dokumentációja is: mi fut, melyik image, mely portok, hol vannak az adatok. Vegye fel ezt a mappát a biztonsági mentésébe (lecke 8.1), és az alkalmazást néhány perc alatt visszaállíthatja egy új szerveren.

A bővítmény neve docker compose (szóközzel, 2-es verzió). A régi, különálló docker-compose programot (kötőjellel) leváltották; régi útmutatókban még találkozhat vele. A régi fájlok tetején szereplő version: "3.8" mező is elavult: a Compose mindig a legújabb sémát használja, és a version: esetén csak figyelmeztetést ad.

Egy compose-fájl olvasása

Egy példa egy programmal és egy PostgreSQL-adatbázissal:

# /srv/notities/compose.yaml
services:
  app:
    image: ghcr.io/example/notities:1.4
    restart: unless-stopped
    ports:
      - "127.0.0.1:8081:8080"
    environment:
      DB_HOST: db
      DB_USER: notities
      DB_PASSWORD: ${DB_PASSWORD}
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_USER: notities
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U notities"]
      interval: 10s
      retries: 5

volumes:
  db-data:

Lépésről lépésre:

• services: minden szolgáltatásból egy konténer lesz. A név (app, db) egyben az a hosztnév is, amelyen a konténerek megtalálják egymást. A Compose saját hálózatot hoz létre az alkalmazásnak, így a app a db:5432 címen kapcsolódik az adatbázishoz.
• image: mindig verziócímkével (lecke 9.1).
• restart: mit tegyen a Docker, ha a konténer leáll vagy a szerver újraindul. A unless-stopped újra elindítja, kivéve, ha Ön szándékosan állította le. Újraindítási szabály nélkül az alkalmazása egy újraindítás után (lecke 4.2) nem indul el újra.
• ports: csak az alkalmazás tesz közzé portot, és csak a 127.0.0.1 címen. Az adatbázis semmit nem tesz közzé: az alkalmazás a belső hálózaton éri el. Egy ports: - "5432:5432" beállítású adatbázis az egyik leggyakoribb hiba (lásd lent).
• environment: a program beállításai. A jelszó nem szó szerint szerepel benne, hanem ${DB_PASSWORD} formában.
• volumes: a db-data nevű kötet megőrzi az adatbázist, amikor a konténert lecserélik.
• depends_on a healthcheck mellett: az alkalmazás csak akkor indul el, amikor az adatbázis valóban készen áll, nem csupán elindult.

Titkok egy .env-fájlban

A Compose az olyan változókat, mint a ${DB_PASSWORD}, egy ugyanabban a mappában lévő .env fájlból olvassa be:

# /srv/notities/.env
DB_PASSWORD=Kies-hier-een-lang-willekeurig-wachtwoord

anna@web1:/srv/notities$ sudo chmod 600 .env

Így a jelszó nem kerül bele abba a compose-fájlba, amelyet esetleg Gitben tárol, vagy egy fórumra másol be, hogy segítséget kérjen. Vegye fel a .env fájlt a .gitignore fájlba. A jelszót jelszókezelővel vagy a openssl rand -base64 24 paranccsal hozza létre.

Mindennapi használat

Minden parancsot a compose-fájlt tartalmazó mappában futtasson:

anna@web1:/srv/notities$ sudo docker compose config     # a fájl ellenőrzése, a változók behelyettesítve
anna@web1:/srv/notities$ sudo docker compose up -d      # minden indítása (vagy frissítése a fájl szerint)
anna@web1:/srv/notities$ sudo docker compose ps         # állapot szolgáltatásonként
anna@web1:/srv/notities$ sudo docker compose logs -f app
anna@web1:/srv/notities$ sudo docker compose pull       # új image-ek letöltése
anna@web1:/srv/notities$ sudo docker compose up -d      # a konténerek cseréje az új image-ekre
anna@web1:/srv/notities$ sudo docker compose down       # leállítás és a konténerek törlése

A down meghagyja a köteteket. A down -v az alkalmazás köteteit is törli, és velük együtt az adatbázisát is. Ezt csak akkor gépelje be, ha valóban elölről akarja kezdeni.

A docker compose config a nginx -t és a sshd -t megfelelője: megmutatja, hogyan értelmezi a Compose a fájlját, az összes változóval behelyettesítve, mielőtt bármit elindítana. Ügyeljen arra, hogy a kimenetet ne másolja be sehova, mert a jelszavak is benne vannak.

A Docker megkerüli az ufw-t

Most jön a modul legfontosabb biztonsági pontja. A lecke 5.2 során az ufw-t "minden tiltása, kivéve SSH, 80 és 443" beállításra tette. Azt várná, hogy egy ports: - "5432:5432" beállítású konténer ekkor nem érhető el. Ez nem így van.

A Docker dokumentációja szó szerint kimondja: a Docker és az ufw olyan módon használja a tűzfalszabályokat, amely nem fér össze egymással. Ha Ön közzétesz egy portot, a Docker maga ír szabályokat a kernel tűzfalába. Ezek a szabályok a forgalmat a konténerhez irányítják (címfordítás, DNAT), még mielőtt az ufw szabályai érvényesülnének. A csomag tehát megkerüli az ufw-t. A ufw status semmi különöset nem mutat, miközben a port az egész internetről elérhető. Ugyanez érvényes a firewalld-re is.

Ráadásul a Docker cím megadása nélkül a 0.0.0.0 és a [::] címen tesz közzé, vagyis IPv4-en és IPv6-on is (lecke 9.1).

Három módja van, hogyan csinálja jól, az egyszerűtől a bonyolultig:

1. Ne tegyen közzé semmit, aminek nem kell nyilvánosnak lennie. Az adatbázisok, gyorsítótárak és belső szolgáltatások nem kapnak ports: beállítást. Az ugyanabban a compose-alkalmazásban lévő konténerek a belső hálózaton érik el egymást.
2. Tegye közzé a loopback címen. "127.0.0.1:8081:8080". Ekkor csak maga a szerver fér hozzá, és elé egy reverse proxyt állít (nginx vagy Caddy, modul 7), amely a 443-as porton figyel. Ezt a Docker alapértelmezésként is megkaphatja: egy démonbeállítással minden cím nélkül közzétett port a 127.0.0.1 címre kerül.
3. Szabályok a DOCKER-USER láncban. A Docker létrehoz egy üres DOCKER-USER láncot, amelyen a saját szabályai előtt halad át a forgalom. Ide saját szabályokat írhat, például "csak ez az IP-cím érheti el a közzétett portokat". Ez haladó munka iptables-szel vagy nftables-szel, és könnyű elrontani. A legtöbb kis szervernél az 1. és a 2. pont elegendő.

Mindig kívülről ellenőrizzen, ahogyan a lecke 5.1 során: nc -vz -w 3 <ip> 5432 a laptopjáról, vagy a Z5.1 és Z10.4 feladat tanfolyami ellenőrzésével.

Még két dolog, amit ne tegyen

• Ne csatolja a /var/run/docker.sock fájlt egy konténerbe, hacsak nem tudja pontosan, miért. Egy konténer, amely hozzáfér a Docker-sockethez, maga is indíthat konténereket, akár olyat is, amely a gazdagép teljes lemezét látja (lecke 9.2). Egyes segédprogramok (irányítópultok, automatikus frissítők) kérik ezt; ez gyakorlatilag root jogot ad az adott programnak.
• Ne használjon privileged: true vagy network_mode: host beállítást csak azért, mert egy útmutató ezt írja. Mindkettő nagyrészt megszünteti a konténer elszigetelését. Csak akkor használja, ha a készítő elmagyarázza, miért szükséges.

Összefoglalás

• Egy compose-fájl (compose.yaml) egy alkalmazás összes konténerét leírja; egyben dokumentáció is, és a biztonsági mentésben a helye.
• Használjon verziócímkéket, újraindítási szabályt, elnevezett köteteket, ahol lehet healthchecket, a titkokat pedig egy 600-as jogosultságú .env fájlban tartsa.
• docker compose config, up -d, ps, logs, pull, down; a down -v a köteteket is törli.
• A közzétett portok megkerülik az ufw-t és a firewalld-t. Csak azt tegye közzé, aminek nyilvánosnak kell lennie, minden mást a 127.0.0.1 címen, elé állított reverse proxyval.
• Nyomós ok nélkül se docker.sock, se privileged, se network_mode: host.

Kvíz

Feladat

Feladat Z9.3: Egy compose-fájl ellenőrzése. A compose-nakijken.txt mintafájlban (szöveges fájlként) egy kis webáruház compose-fájlja található, egy alkalmazással, egy adatbázissal, egy gyorsítótárral és egy adminisztrációs eszközzel. Hat hiba van benne, amelyekről ebben a leckében vagy a lecke 9.1 és 9.2 során volt szó. Minden számozott sorblokknál adja meg, hogy helyes vagy hibás, és minden hibánál válassza ki a megfelelő javítást. A program egy rögzített megoldókulccsal veti össze a válaszait. Ha van saját compose-fájlja, utána nézze át ugyanezen szempontok szerint.

További olvasnivaló

• Docker dokumentáció, How Compose works (compose.yaml): https://docs.docker.com/compose/intro/compose-application-model/
• Docker dokumentáció, Version and name top-level elements: https://docs.docker.com/reference/compose-file/version-and-name/
• Docker dokumentáció, Packet filtering and firewalls (Docker and ufw): https://docs.docker.com/engine/network/packet-filtering-firewalls/
• Docker dokumentáció, Port publishing and mapping: https://docs.docker.com/engine/network/port-publishing/
• Docker dokumentáció, Interpolation (változók és .env): https://docs.docker.com/reference/compose-file/interpolation/