Každá firma, ktorá stavia na DevOps a cloude, by mala mať vo svojom technologickom stacku nejaký nástroj na containerizáciu. Najpopulárnejším je Docker. Docker odstraňuje problémy s prenášaním aplikácie medzi prostrediami, operačnými systémami a strojmi tak, že okolo aplikácie vytvorí obal s preddefinovanými inštrukciami, ako sa má aplikácia spúšťať. Je to štandard, takže sa ľahko integruje s množstvom ďalších služieb, ako sú Kubernetes alebo Docker Swarm. Pozrime sa na základy a poďme implementovať Docker do DevOps pipeline.
Základy Dockera
Aby ste Docker efektívne zapojili do svojej pipeline, potrebujete:
- Dockerfile - recept na to, ako vytvoriť Docker image
- Docker registry - úložisko pre Docker images (Nexus, GitLab Registry, ...)
- Stroj s bežiacim Docker daemonom - miesto, kde sa Docker images spúšťajú
- Pipeline - odporúčané miesto na vytváranie Docker images
Dockerfile zrýchľuje a optimalizuje deployment aplikácie. Keď je Docker image raz vytvorený, dá sa nasadiť na akomkoľvek stroji kompatibilnom s Dockerom. Základný Dockerfile (blueprint), ktorý spúšťa Python skript, vyzerá takto:
FROM ubuntu:22.04
COPY . /app
CMD python /app/app.py
Docker najprv stiahne base image Ubuntu, ktorý slúži ako základná vrstva. Skopíruje obsah vašej aplikácie do filesystemu na cestu /app a nastaví štartovací príkaz, ktorý sa vykoná pri spustení Docker image-u. Zakaždým, keď image spustíte a vytvoríte Docker container, vykoná sa kód z CMD (alebo ENTRYPOINT).
Majte na pamäti, že zatiaľ čo tú istú Docker registry môžete použiť pre rôzne aplikácie, pri Dockerfile to neplatí: rôzne aplikácie majú najčastejšie rôzne Dockerfiles.
Pozor na najčastejšiu chybu
Pri stavaní najlepšieho a najoptimálnejšieho Docker image-u číha veľa nástrah, my sa však pozrieme na tú najčastejšiu: zbytočne veľký Docker image.
Udržujte Dockerfile taký minimalistický, aký len musí byť. Často narazíme na obrovský Dockerfile, ktorý aktualizuje base image, sťahuje viacero knižníc vo viacerých samostatných RUN príkazoch a k tomu ešte builduje artefakty aplikácie. Čo je na tom zlé?
- Aktualizácia base image-u. Zvoľte si aktuálny base image alebo si pripravte vlastný, aby ste knižnice nemuseli aktualizovať až po deploymente.
- Reťazte RUN príkazy. Každý RUN príkaz pridáva do image-u novú vrstvu a ďalej nafukuje jeho veľkosť. Jediným RUN príkazom vytvoríte jedinú vrstvu, a tým veľkosť znížite.
- Build artefaktov vnútri Dockerfile. Artefakty vždy buildujte mimo Dockerfile. Aplikácia nebeží z kódu, ktorý píšete, ale z vybuildovanej aplikácie (.exe, .war a podobne).
Jednoduché kroky, ako je build artefaktov mimo definície Dockerfile a ich vytváranie v CI/CD pipeline, vám dokážu ušetriť aj 90 percent úložiska.
Ako to zapojiť do pipeline
Minimalistická pipeline pre akúkoľvek aplikáciu by mala mať tri kroky, ktoré sa v CI/CD pipeline nazývajú aj stages:
- Build aplikácie
- Build a push image-u
- Deployment aplikácie
Tieto kroky kopírujú jednoduchý workflow, ako keby ste aplikáciu spúšťali na svojom lokálnom stroji. Najprv aplikáciu vybuildujete. JavaScript vývojár tento výstup pozná ako priečinok dist/, v ktorom sú uložené artefakty. Potom cez spomínaný Dockerfile vytvoríte Docker image. Ten okolo aplikácie vytvorí obal a urobí ju nezávislou od platformy. Ďalším krokom je push image-u do vzdialenej registry, aby ho mohli použiť kolegovia alebo aby sa dal nasadiť na servery.
V takejto pipeline je build stage vytiahnutý z Docker stage a stojí ako samostatný krok. Docker image sa builduje len z artefaktov aplikácie a následne sa pushne do privátnej Elastic Container Registry. Keďže nechceme, aby sa aplikácia nasadzovala vždy automaticky, pridali sme manuálny krok, v ktorom deployment spúšťa používateľ. EKS (Kubernetes na AWS) má prístup do ECR, stiahne image z registry a spustí aplikáciu bez akýchkoľvek manuálnych krokov navyše, okrem spustenia samotného jobu.
Aké sú teda prínosy?
Sila Dockera a containerizácie v DevOps nie je v samotnej technológii, ale v neobmedzených možnostiach a integráciách, ktoré môžeme využiť, keď ju raz zapojíme do svojho workflowu. Pozrime sa napríklad na škálovanie aplikácie na infraštruktúre bez akejkoľvek containerizácie a porovnajme ho s Kubernetes infraštruktúrou, ktorá má Docker ako základný engine.
Na infraštruktúre bez Dockera by sme pri škálovaní aplikácie (vytvorení ďalších replík) museli aplikáciu manuálne skopírovať na cieľový stroj, ktorý repliku obsluhuje. Pri škálovaní smerom nadol by sme sa na ten istý stroj museli znova pripojiť a aplikáciu z neho vymazať. Pri update by sme museli manuálne aktualizovať kód na každom cieľovom virtuálnom stroji, čo býva zdĺhavý proces.
