Dockeri alused

Loogika

Docker aitab panna rakenduse koos käivituskeskkonnaga ühte korratavasse pakki.

Kõige tähtsam mõttejärjekord on:

1. vali või ehita image
2. käivita sellest konteiner
3. jaga vajadusel port või kaust hostmasinaga
4. vaata logisid ja käivita käske konteineri sees
5. kui teenuseid on mitu, kirjelda need compose.yaml failis

Git ja venv ei kao Dockeri tõttu ära. Tavaliselt elab lähtekood hostmasina Git-repos, Docker annab sellele koodile ühtse jooksutuskeskkonna.

Kiire orientiir

Tüüpilised algaja vead

• aetakse segi image ja konteiner
• arvatakse, et konteineri sees käsitsi muudetud failid jäävad alati alles
• kasutatakse docker exec konteineri käivitamiseks, kuigi see töötab ainult juba jooksvas konteineris
• eeldatakse, et depends_on tähendab andmebaasi täielikku valmisolekut
• pannakse konteinerisse venv ainult harjumusest, kuigi konteiner ise juba isoleerib keskkonda
• kustutatakse docker compose down -v käsuga kogemata andmebaasi volume

Kas Docker töötab

Enne esimese näite tegemist kontrolli, kas Docker on masinas olemas ja teenus töötab.

docker --version
docker compose version
docker run --rm hello-world

hello-world on väike test-image. Esimesel käivitamisel võib Docker selle internetist alla laadida.

macOS-is ja Windowsis tähendab Docker tavaliselt Docker Desktopi või muud taustal töötavat virtuaalmasina kihti. Kui käsk ütleb, et Docker daemon ei tööta, ava Docker Desktop ja proovi uuesti.

Image ja konteiner

image on valmis käivitusmall. konteiner on sellest mallist käivitatud konkreetne eksemplar.

Ühest image'ist võib korraga töötada mitu konteinerit:

docker run --rm alpine echo tere
docker run --rm alpine uname -a

Siin:

• alpine on image
• echo tere või uname -a on käsk, mis käivitatakse konteineri sees
• --rm kustutab konteineri pärast lõpetamist

Oluline algaja kaitsepiire: konteiner on vahetatav. Kui tahad andmeid säilitada, hoia need hostmasina kaustas, named volume'is või Git-repos.

venv vs Docker

venv ja Docker lahendavad eri probleemi.

Dockeri sees ei ole eraldi venv enamasti vajalik. Kui üks konteiner jooksutab üht rakendust, on konteiner ise eralduskiht.

Esimene väike Dockerfile

Kõige selgem esimene näide on väike programm, mille image ise käivitab.

mkdir -p ~/tmp/docker-naide
cd ~/tmp/docker-naide

app.py

print("Tere konteinerist")

Dockerfile

FROM python:3.13-slim
WORKDIR /app
COPY app.py .
CMD ["python", "app.py"]

Siin:

• FROM python:3.13-slim valib Pythoni baaskeskkonna
• WORKDIR /app määrab töökausta konteineri sees
• COPY app.py . kopeerib faili image'isse
• CMD ["python", "app.py"] ütleb vaikimisi käivitatava käsu

Ehita ja käivita:

docker build -t tere-rakendus .
docker run --rm tere-rakendus

Tulemus peaks olema:

Tere konteinerist

Punkt . käsu lõpus tähendab build context'i: kausta, mille sisu Docker buildi ajal näeb.

.dockerignore

Build context ei peaks sisaldama kõike, mis projektikaustas on.

Tüüpiline .dockerignore:

.git
.venv
__pycache__/
dist/
*.log

See teeb buildi kiiremaks ja vähendab riski, et image'isse satub juhuslikke kohalikke faile.

docker run: käsk, port ja nimi

docker run loob uue konteineri ja käivitab selle.

docker run --rm python:3.13-slim python --version

Kui konteineri sees jookseb server, tuleb port hostmasinasse siduda.

docker run --rm -d --name pyweb -p 8000:8000 python:3.13-slim python -m http.server 8000

Siin:

• -d paneb konteineri taustale
• --name pyweb annab konteinerile nime
• -p 8000:8000 seob hosti pordi 8000 konteineri pordiga 8000

Kontroll:

docker ps
docker logs pyweb
docker stop pyweb

Brauseris peaks teenus olema aadressil:

http://localhost:8000

Kui port on juba kasutusel, vali vasakul pool teine hosti port, näiteks -p 8080:8000.

logs ja exec

Kui konteiner on juba käimas, alusta veaotsingut logidest.

docker logs pyweb
docker logs -f pyweb

-f jälgib logi jooksvalt.

Käsk konteineri sees:

docker exec pyweb pwd
docker exec -it pyweb sh

docker exec ei loo uut konteinerit. See käivitab käsu olemasolevas töötavas konteineris.

Praktiline märkus: paljudes väikestes image'ites ei ole bash paigaldatud. sh töötab sagedamini.

Bind mount: hosti kaust konteinerisse

Builditud image sobib valmis rakenduse proovimiseks. Arenduses tahad sageli, et konteiner näeks sinu praegust projektikausta kohe.

docker run --rm -it --mount type=bind,src="$PWD",dst=/app -w /app python:3.13-slim sh

Sama lühem, vanem ja väga levinud kuju on:

docker run --rm -it -v "$PWD":/app -w /app python:3.13-slim sh

Siin:

• src="$PWD" või "$PWD" on sinu praegune kaust hostmasinas
• dst=/app või /app on sama kaust konteineri sees
• -w /app teeb sellest töökausta

Konteineri sees saad näiteks käivitada:

python app.py
python -m pip install -r requirements.txt
pytest

Bind mount'i puhul muutub hosti fail päriselt. See on arenduses mugav, aga tähendab ka, et konteineris tehtud muudatus võib muuta sinu töökausta.

Named volume

Bind mount seob konteineri konkreetse hosti kaustaga. Named volume on Dockeri hallatav püsiv andmeala.

Kõige tavalisem kasutus on andmebaasi andmed:

volumes:
  pgdata:

Compose'i teenuses:

services:
  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data

Pea meeles:

• docker compose down peatab ja eemaldab teenuste konteinerid ning võrgu
• docker compose down -v eemaldab ka named volume'id
• andmebaasi volume'i kustutamine tähendab sageli andmete kustutamist

Arenduse tööjaotus

Hea algaja tööjaotus on:

Väldi olulise koodi kirjutamist ainult konteineri sisemisse failisüsteemi. Kui konteiner kustub, võib see töö kaduda.

Kui rakendus vajab pakette

Pythoni projektis on sõltuvused sageli failis requirements.txt.

requirements.txt

requests==2.32.3

Dockerfile

FROM python:3.13-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py .
CMD ["python", "app.py"]

Siin on oluline järjekord:

• sõltuvuste fail kopeeritakse enne rakenduse koodi
• RUN pip install ... jääb võimalusel build cache'i
• COPY app.py . tuleb hiljem, sest rakenduse kood muutub sagedamini

docker compose: mitu teenust korraga

Kui projekt vajab rakendust ja andmebaasi, muutub üks pikk docker run käsk ebamugavaks. Siis kirjelda teenused failis compose.yaml.

services:
  app:
    image: python:3.13-slim
    working_dir: /app
    volumes:
      - .:/app
    command: python -m http.server 8000
    ports:
      - "8000:8000"

  db:
    image: postgres:16
    environment:
      POSTGRES_DB: opik
      POSTGRES_USER: opik
      POSTGRES_PASSWORD: opikpass
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Tüüpilised käsud:

docker compose up
docker compose up -d
docker compose logs -f app
docker compose exec app sh
docker compose down

Tähendused:

• up käivitab teenused ja näitab logisid
• up -d käivitab teenused taustal
• logs -f app jälgib ühe teenuse logi
• exec app sh avab käsu töötavas teenusekonteineris
• down peatab ja eemaldab selle compose-projekti konteinerid ning võrgu

Uues Dockeris kasutatakse kuju docker compose. Vanemates juhendites võid näha kuju docker-compose.

depends_on ei ole valmisolekukontroll

Compose'is näed sageli:

depends_on:
  - db

See aitab käivitusjärjekorraga, kuid ei tähenda automaatselt, et andmebaas on juba ühendusteks valmis.

Päris projektis võib vaja minna:

• rakenduse enda retry-loogikat
• andmebaasi healthcheck'i
• käivitusskripti, mis ootab teenuse valmidust

Algaja jaoks piisab esialgu teadmisest: kui app ütleb käivitumisel, et andmebaas pole valmis, vaata esmalt docker compose logs db ja proovi pärast hetke uuesti.

Millal valida run, build või compose

See valik vähendab segadust: ära tee compose'i ainult selleks, et käivitada üht lühikest käsku, ja ära kirjuta üht hiiglaslikku docker run käsku, kui projektis on mitu teenust.

Ohutus ja privaatsus

Konteiner ei ole maagiline turvasein.

Ole ettevaatlik, kui:

• image on tundmatust allikast
• annad konteinerile hosti kaustu bind mount'iga
• paned keskkonnamuutujatesse paroole või võtmeid
• näed juhendit, mis mount'ib Docker socket'i, näiteks /var/run/docker.sock
• käsk kasutab --privileged

Algaja hea reegel: ära käivita võõrast image'it koos oma kodukataloogi või salajaste failide mount'iga.

Kettaruumi kontroll ja koristamine

Docker võib aja jooksul koguda image'eid, peatunud konteinereid ja build cache'i.

Ohutu vaatamine:

docker system df
docker ps -a
docker images

Koristuskäske kasuta alles siis, kui saad aru, mida need kustutavad:

docker container prune
docker image prune

Need ei ole esimesed õppimiskäsud. Need on hilisemaks, kui Docker on juba igapäevases kasutuses.

Seos arenduskonteineritega

Arenduskonteiner ehk devcontainer on Dockeri peale ehitatud IDE-töövoog.

Tavaliselt toimub nii:

• Docker käivitab konteineri
• IDE ühendub konteineri sisse
• projektikaust mount'itakse tööruumina
• terminal, testid ja keele tööriistad jooksevad konteineris

Arenduskonteiner ei asenda Dockeri põhimõtteid. Ta teeb sama loogika mugavamaks, eriti siis, kui projekt vajab keerulisemat keskkonda.

Praktiline õppimisjärjekord

Õpi Dockerit selles järjekorras:

1. docker run --rm alpine echo tere
2. image ja konteineri vahe
3. väike Dockerfile
4. docker build -t nimi .
5. port, logid ja exec
6. bind mount arenduseks
7. docker compose mitme teenuse jaoks
8. volume'id ja andmete püsivus

Nii on igal sammul selge, kas sa käivitad valmispilti, ehitad uut image'it, jagad faile või juhid teenuste komplekti.

Minitest

1. Mis vahe on image'il ja konteineril?
2. Miks on --rm kasulik lühikeste katsete puhul?
3. Mida teeb -p 8000:8000?
4. Mis vahe on bind mount'il ja named volume'il?
5. Millal valid docker compose tavalise docker run asemel?
6. Miks ei tasu docker compose down -v käsu tähendust arvamata käivitada?

Lisalugemine

Selle teema usaldusväärsemad viited leiad lisast Lisa E: usaldusväärsed viited ja lisalugemine.