Docker image automatikus deploy és pull Gitlabbal

Virtualizáció

Sziasztok!

A következő munkafolyamatot szeretném megvalósítani, ebben kérném a segítségeteket. Amennyiben az elgondolás hibás, akkor abban is számítok a tanácsaitokra.

Gitlabban tárolt repository-ból naponta egyszer le kellene buildelni egy Docker image-t. Amennyiben az új image tartalmaz biztonsági javítást (egyelőre Ubuntu alapú image-kről van szó), akkor automatikusan új verziószámmal kellene ellátni és felpusholni a Docker Hubra.

Ezután a szervereken automatikusan érvényesíteni kellene az új image-t.
Az egyik járható út lehet, hogy a Gitlabból ssh-val belépve egy szkript letölti az új Docker képfájlt.
A másik (általam jobban preferált), hogy a szerverek minden nap cronból lekérdeznék, hogy van-e új image és ha igen, akkor egy szkript leállítja a futó konténereket, letölti az új képfájlt, elindítja a konténereket, majd státuszt vizsgál: ha minden rendben működik, akkor az előző verziójú image-t eldobja.
Amennyiben nem megfelelő a működés, akkor visszatér a régi verziójú képfájlhoz, elindítja újra a szolgáltatásokat majd erről küld levelet.

Köszönöm a segítséget!

  • 1896 megtekintés

( janoszen v | 2018. 07. 25., sze – 21:50 )

Mint privatban mar mondtam, ha nem akarsz semmilyen orchestration megoldast, erdemes legalabb egy docker-compose-t bele venni a jatekba. Ezen felul nekem kisebb deploymentekre az ansible igen hasznos eszkoznek bizonyult. Ime egy pelda hogy hogyan tudsz ansible-el Dockert deployolni

Hatalmas caveat: a CI rendszerednek igy rootkent kell tudnia SSH-zni. De a root problema akkor is megvan ha a CI rendszered random docker imaget futtathat, ugyanis akkor is root jogot tudsz szerezni. Szal tessek megvedeni a CI rendszert rendesen.

--
Pásztor János

Az a baj, hogy a Docker itt elég köcsög. Gondoltam is rá, hogy forkolom a Docker compose-t. Ugyanis ha swarmot használsz (Docker compose v3.x format), akkor elesel egy csomó lehetőségtől. Pl. nincs CPU limit, memorialimit, ami azért elég hasznos.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Fura, mert mi hasznalunk ilyeneket v3.x formatummal. :) Pelda; 


cadvisor:
    image: google/cadvisor:v0.29.1
    hostname: "{{.Node.ID}} "
    networks:
      - monitoring
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock,readonly
      - /:/rootfs
      - /var/run:/var/run
      - /sys:/sys
      - /var/lib/docker/:/var/lib/docker
    labels:
      - com.docker.ucp.access.label=eltavolitva
    deploy:
      mode: global
      resources:
        limits:
          cpus: '0.30'
          memory: 256M
        reservations:
          cpus: '0.10'
          memory: 32M

----------------------
while (!sleep) sheep++;

Ahhoz, hogy ezek a paraméterek érvényre jussanak, swarm-mal kell a konténereket elindítani:

RESOURCES
Configures resource constraints.

Note: This replaces the older resource constraint options for non swarm mode in Compose files prior to version 3 (cpu_shares, cpu_quota, cpuset, mem_limit, memswap_limit, mem_swappiness), as described in Upgrading version 2.x to 3.x.
Each of these is a single value, analogous to its docker service create counterpart.
In this general example, the redis service is constrained to use no more than 50M of memory and 0.50 (50%) of available processing time (CPU), and has 20M of memory and 0.25 CPU time reserved (as always available to it).

version: '3'
services:
redis:
image: redis:alpine
deploy:
resources:
limits:
cpus: '0.50'
memory: 50M
reservations:
cpus: '0.25'
memory: 20M

The topics below describe available options to set resource constraints on services or containers in a swarm.
Looking for options to set resources on non swarm mode containers?
The options described here are specific to the deploy key and swarm mode. If you want to set resource constraints on non swarm deployments, use Compose file format version 2 CPU, memory, and other resource options. If you have further questions, refer to the discussion on the GitHub issue docker/compose/4513

De ez akkor már swarm, ha jól látom. Amivel nincs gond, amennyiben nem kever be, hogy egyelőre csak egyetlen példány lenne minden konténerből. Amúgy máshol használunk swarmot, jó dolog.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Nem javasolt? Oke, de ha valaki tud kontenert inditani, az elvileg megtehetne, hogy felmountolja. Ez a lenyeg. (sudo accessel sem javasolt az rm -rf / )

Ezert irtak fent, hogy ha nem-root user tud tetszoleges kontenert inditani, akkor annak lenyegeben sudo-ja van.

----------------------
while (!sleep) sheep++;

Viszont ha az a user, aki nevében beesshztok, bármi konténert elindíthat, akkor semmi nem tartja viszza egy

docker run ubuntu -v /:/hostroot rm -rf /hostroot (vagy add_me_to_sudoers.sh)

futtatásától, szóval effektív root joga van a usernek, akkor is, ha "csak a docker groupban van benne"

( nevergone v | 2018. 07. 26., cs – 07:40 )

Az image buildeléshez van ötletetek?

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

belősz rá egy Jenkins-t. Van jó sok leírás a neten. (pl)
ha vagy annyira elborult, mint pl. én akkor magát a Jenkins-et is lehet docker konténerként futtatni, ha pedig átadod neki a /var/run/docker.sock-ot akkor az alatta lévő host docker daemon-ját is lehet használni image build-elésre.
< insert Inception We have to go deeper meme here >

a build-et triggerelni sokféle módon lehet, akár cron-ból, akár github hook-al (tetszőleges eventre)

Nem vagyok Gitlab mágus (inkább a Dockerhez értek), de az látszik, hogy a Gitlab CI lefedi az igényeinket, ahogy eddig is tette. Ha nem kötelező, nem vonnék be még egy szolgáltatást csak ezért, amit aztán valakinek felügyelni és kezelni kell, erőforrásokat kell rendelni hozzá stb.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

( kallaics | 2018. 07. 26., cs – 08:39 )

Őszintén szólva neked nem segítség kell ebben a fázisban, hanem el kell kezdened olvasni a témában. Például hogyan működik a docker, az automata deployment és CI/CD úgy általában. Ehhez vannak jó könyvek és videó anyagok. Utána lehet segítséget kérni és utána fogod látni, hogy mennyivel jobb úgy,hogy érted az alapokat és ha valami elromlik később érted mit csináltál és meg tudod javítani. Amíg az alapok nincsenek meg addig mindenféle segítség hasztalan.

Ezt a folyamatot, meg kell tervezni le kell dokumentálni szépen, mert ez már nem egy pár soros bash script és ha valami nem úgy megy,ahogy kitaláltad, akkor 1 év múlva már nem fogod tudni mit miért csináltál.

Például esetedben ez is mutatja,hogy nincs elég tapasztalatod még a Docker-rel sem.
"Az egyik járható út lehet, hogy a Gitlabból ssh-val belépve egy szkript letölti az új Docker képfájlt.
A másik (általam jobban preferált), hogy a szerverek minden nap cronból lekérdeznék, hogy van-e új image és ha igen, akkor egy szkript leállítja a futó konténereket, letölti az új képfájlt, elindítja a konténereket, majd státuszt vizsgál: ha minden rendben működik, akkor az előző verziójú image-t eldobja."

Mondok hozzá neked egy lehetséges megoldást:
Image build-elés után az image felkerül a docker hub-ra privát repoba (asszem fizetős a privát repó) és onnan tudod frissíteni a rendszert. Alternatív megoldásként építhetsz saját docker registry-t,ahová az image-ket tárolod. A lényeg,hogy egy registry-ben kell tárolni a build-elt docker image-ket.

A fentihez hasonló lehetőségek vizsgálatát minden egyes tervezett lépésnél meg kell ejtened. Ehhez tanulmányoznod kell a GitLab milyen lehetőségeket ad a Te elvárásaidhoz. Például van-e benne docker registry opció vagy külső tároló kell majd.

Én az alábbi lépéseket csinálnám nagy vonalakban:
- Hook ha a kódban változás van (definiálni kell mi az a változás, amire indul a build)
- Kellene kód ellenőrzés és tesztelés,hogy kód rendben van-e (kulcsszavad: validation, smoke test)
- Build docker image
- Betárolni registry-be.
(- image tesztelése docker alatt teszt konfiggal mielőtt élesbe megy)
- Docker konténer alatti image cseréje (ennek is több módja van igénytől függően. Zero downtime kell-e stb.)

Utána jöhet egy step by step guide, ami alapján már össze tudod rakni Gitlab alatt az egészet.
Nem egész 1 perc guglizással találtam: https://hackernoon.com/setting-up-ci-cd-on-gitlab-step-by-step-guide-pa…

Mint látod ez nem egy 2 perces történet és sok ismeret és tapasztalat kell ahhoz, hogy jól megtervezz és átláss egy ilyen rendszert!

A fentieket nem azért írtam, hogy elvegyem a kedved, hanem,hogy megértsd, hogy ehhez meg kell tanulnod az alapokat, hogy egy jól összerakott rendszert le tudj tenni az asztalra.

A Dockert elég jól ismerem, mert régóta használjuk változatos környezetben és nekem kell piszkálgatnom. A Gitlab CI részét nem ismerem túl mélyen, ez tény.
Köszönöm a választ, de kicsit félrementél vele, egyelőre ugyanis nem akarok ebben kódot ellenőrizni (az még kérdéses, hogyan lesz megoldva). A kérdés egyelőre a Docker image készítése és pusholása, illetve a konténerek oldalán az automatikus pullozása jelenti. A vizsgálat részre egyelőre bőven elég, ha a Docker konténer healtly-nak jelzi magát. Akár az is lehet, hogy a sikeres image build után a Gitlab meghív egy megfelelően védett URL-t, ami elindítja a konténerek oldalán a folyamatot.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ez igaz, erre nem is gondoltam, pedig a napokban beszéltünk róla. Akkor ami a kritikus része, hogy csak akkor készüljön publikált image, ha van biztonsági frissítés (minden szirszarért ne indítgassuk újra a szolgáltatást), illetve ezt valahogy érvényre kellene juttatni a konténerek oldalán rollback lehetőséggel.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Az image build nem egy nagy was-is-das, legyen docker a runneren, s legyen éjszakánként build futtatva, ha nem változott semmi, a hash ugyanaz lesz, s nem lesz újra feltöltve.

A szervereken meg én cronból nézném van-e frissebb, kell-e restart. Vagy a docker pull eredménye alapján, vagy a docker inspectből próbálnám meg kitúrni a build időpontot.
Esetleg ha nem stimmel a futó konténer image hashe a latestjével...

Sry, ha nem követhető mindenhol, telefonról voltam.

Igen, ha más nem sikerül, akkor ez az irány lesz. Azért ragaszkodnék a security update-hez, hogy minden apróságért ne kelljen a konténereket újraindítgatni. Ha mondjuk biztonsági javítás van a PHP-hez, az menjen ki mihamarabb, de ha csak azért frissül a csomag, mert valamit átírtak a doksiban, az bőven ráér kikerülni a következő biztonsági frissítéssel.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

"A szervereken meg én cronból nézném van-e frissebb, kell-e restart. Vagy a docker pull eredménye alapján, vagy a docker inspectből próbálnám meg kitúrni a build időpontot.
Esetleg ha nem stimmel a futó konténer image hashe a latestjével..."

Szerintem ha compose-t egy megfelelően mozgó tagra állítod (latest), akkor egy docker-compose up nem fogja basztatni, amit nem kell.

Még gondoltam is, hogy beleírom, hogy latest, haha, vagy ilyesmi. :) Mi pl ahol ilyet (ilyesmit) csinálunk, ott olyanok vannak, hogy v1-latest, v1.1-latest meg v1.1.18, v1.2.1 és az első kettő olyan mozgó célpont, amit megfelelő explicit verziók megjelenésekor szintén frissítünk.

Gitlabban CDhez vannak environmentek, meg manual stepek, scheduleök, meg ilyesmik, még talán kubernetes support is újabban. Valamit olvastam a canary deployment supportról is, ha elég nagy a cuccod, az se lehet rossz. Sajna hands-on tapasztalatom még nincs, de olvasgasd meg kicsit a gitlab CI/CD doksit, 1-2 óra alatt szerintem átlátod, hogy miket tud, aztán abból lehet főzni.

Ami kérdés, hogy azt honnan tervezed megtudni, hogy van-e benne security para, mert azt magától nem fogja tudni kitalálni. A legegyszerűbb nyilván, ha az upstream distronak csak a secu csatornájából frissítesz alapvetően (a sajátodról meg nyilván tudod, hogy secut javítasz. Ha nem ilyen egyszerű -- és gondolom nem -- akkor el kell kezdeni fejvakarni, de kb két irány van: vagy minden sourcenál kiszaszerolod, hogy hogy lehet csak a secut updatelni, vagy valami elkészült containert inspectelő szolgáltatást használsz.

Illetve nyilván van egy harmadik is (és hosszú távon ezzel jársz talán a legjobban), átszabod úgy a prod infrát, hogy ne fájjon a restart, körbebástyázod a kódot tesztekkel, hogy eléggé elhidd, hogy észreveszik, ha baj van, aztán válogatás nélkül tolod ki a frissítéseket continuous módon. (Nyilván for a certain definition of continuous, lehet az valóban azonnal, napi 2-3, naponta, hetente, ahogy érzed.)

Nagyon jókat mondtál, mi is azzal próbálkozunk, hogy a frissítések egyelőre csak a security csatornából menjenek az image-hez. Segítene, ha a Docker parancsoknak lenne --dry-run paramétere, de nincs.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Esetleg egy olyat hákolnél, hogy:
- `docker image inspect base`
- kikapom, milyen layerek vannak az így buildelt image-ben
- `docker image inspect általam legutoljára buildelt`
- ha a layerek stimmelnek, nem kell buildelni :)

De szerintem ezt sokkal, sokkal szarabb lesz karbantartani, mint hagyni a néhány gépet este pörgetni egy buildet.

( nevergone v | 2018. 07. 26., cs – 15:00 )

Miközben gyalogoltam haza az ebédből, azt hiszem megtaláltam a megfelelő megoldást. Nem egyszerű, de sokkal egyszerűbb, mint amire eredetileg számítottam.

Szóval felhasználhatom azt a csomagtárolót, ahonnan veszik a Linux disztribúciók a biztonsági frissítések csomagjait. Naponta egyszer a build szkript megnézi, hogy a tárolóban van-e új csomag és összeveti a telepítettekkel. Amennyiben szükséges, akkor elindítja a buildelést, mert van elérhető biztonsági frissítés. A buildben argumentummal lehet szabályozni, hogy minden frissítést feltegyen-e, vagy csak a biztonsági frissítéseket. Ha sikeresen lefutott, akkor megfelelő verziószámmal feltölti a Docker imaget.

A konténerek oldalán felhasználhatom, hogy a Docker Hub-on (gondolom valamilyen eszközzel a Gitlab privát tárolóból is) lekérdezhető, hogy mikori a legfrissebb image. Amennyiben van friss, akkor a jelenleg használtnak elmenti a verziószámát, leállítja az érintett szolgáltatásokat, majd letölti a friss image-t, elindítja a konténereket és ellenőrzi a státuszt. Ha jól működik, akkor eldobja a régi image verziót és értesít. Ha gond van, akkor az előző verzióval elindítja a szolgáltatásokat és értesít.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

elméletileg működhet, de én tényleg nem szenvednék ennyit néhány build megspórólásáért - a felesleges konténer újraindítást meg sokkal könnyebben ki tudod védeni.

két kérdés:
- meddig tart a build?
- vannak olyan frissítések a base imageben, ami nem security fix?

> A konténerek oldalán felhasználhatom, hogy a Docker Hub-on (gondolom valamilyen eszközzel a Gitlab privát tárolóból is) lekérdezhető, hogy mikori a legfrissebb image.
A Gitlabos registryt nem tudod rendesen kérdezgetni APIn, legalábbis nekem sosem sikerült.
Nekem ezt túrta ki egyszer egy kollégám, de sosem próbáltam: https://github.com/travisghansen/docker-registry-curl