ugrás a tartalomhoz

Mekkora méreteknél érdemes több docker container-be darabolni az alkalmazást?

inf · 2017. Szep. 4. (H), 00.39
Mekkora méreteknél érdemes több docker container-be darabolni az alkalmazást?
‹ alpine adduser -S - kicsit furcsa... Hová meneküljünk az emberi hülyeség elől? ›
 ■
1

Mit értesz méret alatt? Ahogy

MadBence · 2017. Szep. 4. (H), 12.53
Mit értesz méret alatt? Ahogy én tudom, a mostani trend az az, hogy minden futó processznek lehet adni saját konténert.
3

Találtam egy kis írást a

inf · 2017. Szep. 4. (H), 14.56
Találtam egy kis írást a témában, most olvasom: link. Az világos, hogy van rá lehetőség, hogy minden egyes process külön container-t kapjon. Az a kérdés, hogy mi alapján lehet eldönteni, hogy hány process-nek járjon egy container? Gondolom függhet az alkalmazás működésétől.
5

Miért akarsz processzeket

MadBence · 2017. Szep. 4. (H), 17.34
Miért akarsz processzeket direkt összecsoportosítani?
7

Egyelőre nekem pazarlásnak

inf · 2017. Szep. 5. (K), 06.05
Egyelőre nekem pazarlásnak tűnik nem így tenni. Gondolom az az érv ellene, hogyha elszáll a container valamiért, és újra kell indítani, akkor csak egy process száll el vele, a többi ugyanúgy dolgozhat tovább. Ennek talán nem minden esetben van jelentősége, szóval azt szeretném átgondolni, hogy mikor lehet fontos így szétszedni, és mikor nem. Persze ha tudsz mondani egyéb szempontot, ami hasznos lehet, akkor hallgatlak. Egyelőre nulla a tapasztalatom ezekkel a containerekkel.
8

VM

janoszen · 2017. Szep. 5. (K), 12.02
Ne ugy gondolj a Docker containerre mint egy VM-re. Nem az. Torolj ki a fejedbol mindent amit virtualis gepekrol tudsz, es azt hogy a Dockernek barmi koze lenne a virtualizalashoz.

Egy Docker container eroforrasigenye annyira minimalis, hogy csak nagyon specialis esetben eri meg vele szenvedni hogy kevesebb legyen belole. Ha elo is jon, akkor is inkabb azon fogsz dolgozni, hogy pl. a disk alrendszer legyen gyorsabb, nem fogsz osszetenni tobb alkalmazast egy containerbe.

Itt irtam reszletesen arrol hogy mi van a Docker alatt: https://www.refaktor.hu/nem-kivanatos-alkalmazasok-uzemeltetese-linuxon/
11

Köszi! Elolvasom.

inf · 2017. Szep. 5. (K), 13.13
Köszi! Elolvasom. Egyébként azt mondják, hogy a docker nem sandbox és simán ki tud törni egy hacker belőle. link Ez mennyire igaz?
16

Nem

janoszen · 2017. Szep. 5. (K), 15.13
Alapvetoen nem... feltetlenul igaz. Egyreszt 2014-es a cikk es azota sok minden fejlodott, masreszt a Dockert onmagaban nem szokas hasznalni. Altalaban valami AppArmorral vagy ilyesmivel megtoldva jon. Ehhez hozzajon hogy a best practice altalaban az, hogy a docker image amit futtatsz ne futtassa rootkent a processt, vagy legalabb UID mapingot csinaljon, mert ugye ami root az root. Hacsak nem allitod at.

Ellenben maradjunk annyiban, hogy nem veletlenul van az, hogy a Google Cloudban vagy AWS-en komplett virtgepet berelsz es abban futtatjak neked a containereket, nem pedig osztott infrastrukturan mukodik. Ha third party imageket akarsz futtatni mindenfele ellenorzes nelkul, akkor arra nem a Docker valo. Containeren belul is lehet olyan csunyasagokat csinalni amik ellen nehez vedekezni ertelmesen, pl. fel lehet zabalni a disk IO-t.
18

Nem akarok, inkább az

inf · 2017. Szep. 5. (K), 16.29
Nem akarok, inkább az érdekel, hogyha mondjuk feltörnek egy weboldalt, ami container-ben fut, akkor vajon a teljes szerver kompromittálódik e, vagy csak az adott container. Jobban örülnék az utóbbinak nyilván, ha megoldható. Köszi az info-kat! Beleolvastam a cikkbe, jó anyag, de most el kell ugranom. Később folytatom.
21

Tobbnyire nem

janoszen · 2017. Szep. 5. (K), 16.36
Tobbnyire nem, mert akkor en is szarban lennek, de ha lehet akkor ne rootkent fusson a PHP-FPM a containerben.
2

Hogyan?

Hidvégi Gábor · 2017. Szep. 4. (H), 13.27
Hogyan és miért merült fel a kérdés?
4

Követelmény

janoszen · 2017. Szep. 4. (H), 17.28
Ez nagyon sokrétű kérdés. Az alapfelállás az, hogy mindent darabolj külön containerbe hogy önállóan lehessen skálázni és mozgatni. Viszont van néhány kivétel:

- Ha a szoftvered működéséhez kell egy másik szoftver. Ilyen pl. a PHP-FPM mellé pakolt nullmailer ha olyan a PHP szoftvered.
- Ha valamilyen erőforrásra van szükséged a gazdagépről és agresszív cachelést állítasz be (ez esetben a külön containerek nem biztos hogy látják a módosításokat). Ezzel óvatosan, a mountolás szívásokhoz tud vezetni.
- Ha nem akarsz FastCGI-n loadbalance-olni vagy service discoveryvel foglalkozni pl. nginx és PHP-FPM között. (De ez esetben nagyon szeretnéd megnézni a docker swarmot. Nagyon nagyon. Mert jó.)

Ha ezen akarsz spórolni rossz úton jársz, mi több tucat containert futtatunk egy gépen minden probléma nélkül.
6

Nem riaszt vissza a sok

inf · 2017. Szep. 5. (K), 05.59
Nem riaszt vissza a sok container, a kérdés inkább az, hogy egy alkalmazáshoz mennyi kell, hogy tartozzon, és hogy mi mentén érdemes darabolni. De ha az a válasz, hogy minden process kapjon külön container-t, akkor nagyon érdekel, hogy miért éri meg mindez az ezzel járó plusz költség ellenére.
9

Szivas

janoszen · 2017. Szep. 5. (K), 12.03
Minel jobban szet tudod darabolni, minel jobban fuggetleni tudod egymastol a komponenseidet, annal boldogabb ember leszel. Ugyanaz mint a kodnal. Laza kapcsolatokat akarsz a komponenseid kozott.
10

Oké, ez így világos, viszont

inf · 2017. Szep. 5. (K), 13.12
Oké, ez így világos, viszont ha nagyon szét van darabolva valami, akkor írhatok egy rakás docker scriptet, hogy fellője az egész alkalmazást, esetleg a deploy-hoz is írni kell valamit, hogyha csak az alkalmazás egy része módosult, akkor csak azt indítsa újra. Egy csomó plusz idő és energia lehet mindezt menedzselni.
15

S

janoszen · 2017. Szep. 5. (K), 15.10
Nem akarlak elszomoritani, a Docker onmagaban nagyon keves a boldogsaghoz, valamilyen orchestration layerre (Docker Swarm, Kubernetes, Amazon ECS) szukseged lesz ha nem csak egy containert akarsz futtatni. Viszont ezek kezdetlegesek, sokat kell reszelni mire jo lesz. Talan a Docker Swarm all a legkozelebb a keszhez, de az tudja a legkevesebbet.
19

Én is ettől tartottam. Ha

inf · 2017. Szep. 5. (K), 16.31
Én is ettől tartottam. Ha csak node-ot nézem, még a pm2 sem túl kiforrott, legalábbis régebben nehéz volt megoldani, hogy ne root-ként fusson a node. A docker-el hasonló lehet a helyzet, maga a tool jó, de valahogy menedzselni kell, biztonságossá tenni, és így tovább. Sajnos ez még nem out of the box jön, az még lesz egy pár év...
22

Swarm

janoszen · 2017. Szep. 5. (K), 16.37
Nekem a Swarm es az Amazon ECS van productionben. Nem mondom hogy teljesen hands-off, de sikerult ugyfelnek 3-4 ora alatt osszerakni egy kornyzetet amiben hostolhatja az oldalait es nem szivja meg ha az egyiket felnyomjak.
12

Még mindig nem értem, hogy

MadBence · 2017. Szep. 5. (K), 13.52
Még mindig nem értem, hogy miért akarsz egy konkrét számot meghatározni. Annyi konténer kell, amennyire az alkalmazásnak szüksége van. Egy nagyon minimál node-os alkalmazásnál én csinálnék a node-nak egy konténert, az adatbázisnak egy másikat, meg elé egy nginx-es reverse proxy-t. ez kb bármilyen termék esetén jó kiindulópont (ennél a tech stacknél).
13

Nem konkrét számra, hanem

inf · 2017. Szep. 5. (K), 13.57
Nem konkrét számra, hanem ilyesmi receptre vagyok kíváncsi, mint amit írtál. Tegyük fel, hogy megvan ez az alap, és nődögél a node-os alkalmazás. A méret függvényében mikor érdemes bevezetni újabb container-eket?

A redbird-öt nézted már? Talán production ready lehet már az is, legalábbis már 3 éve fejlesztik folyamatosan. Elvileg hasonló a teljesítménye az nginx-hez képest.
14

Hát ha már ott tartasz, hogy

MadBence · 2017. Szep. 5. (K), 14.19
Hát ha már ott tartasz, hogy nem bírsz vertikálisan skálázódni, akkor indítasz annyi node konténert amennyi kell ahhoz, hogy stabilan fusson az app, és bekonfiguálod az nginx-et loadbalancingra.

redbird-öt nem használtam még, biztosan jó, de amíg az nginx mindent tud, amire nekem szükségem van, addig nem fogok váltani rá.
20

Nem mondtam, hogy válts, csak

inf · 2017. Szep. 5. (K), 16.32
Nem mondtam, hogy válts, csak hogy próbáld ki, ha van egy kis szabad időd.
17

Recept

janoszen · 2017. Szep. 5. (K), 15.16
A recept az, hogy a Docker alapvetoen egy init processt indit el a container indulasakor. Ha egynel tobb szolgaltatast csomagolsz egybe, akkor szukseged lesz olyasmire mint a supervisord ami az egyik szolgaltatas leallasa eseten lelovi a masikat is. Ellenkezo esetben elofordul, hogy mondjuk a PHP-FPM lerohad, de a nullmailer miatt tovabb fut a container es az orchestration service is ugy latja hogy minden OK. Szoval minel jobban szet tudod szabdalni, annal kisebb a valoszinusege annak, hogy beleszaladsz ilyen reszlegesen futo containerekbe. Ha mindent egybe csomagolsz, akkor erolkodni kell az init szoftver confolasan, memoriat eszik, es tobb a mozgo alkatresz.
23

Ha jól értem, akkor most az a

inf · 2017. Szep. 5. (K), 16.40
Ha jól értem, akkor most az a divat, hogyha lerohad az app a container-ben, akkor újraindul a container, a többi container-ben futó cucc, ami tőle függ, meg vár az újraindításra pl egy adatbázis esetén. Nem kell ennél bonyolultabb kód föléjük, mondjuk ami több container-ben indítja el ugyanazt, és ha az egyik lehal, akkor átadja a kéréseit egy másiknak?
24

Nem

janoszen · 2017. Szep. 5. (K), 19.18
Jol erted, ez a divat. Ha az alkalmazas hulyeseget csinal, akkor lesz szives fejbe loni magat, vagy a HEALTHCHECK parancs lesz kedves megmondani hogy az alkalmazas nem viselkedik megfeleloen, es akkor kidobjuk a containert.

A tobb container tipus (service) egyuttmukodese ugy van megoldva, hogy a) egy container tipusbol mindig tobb fut, igy egy ujraindulas nem okoz szolgaltatas kiesest b) a HEALTHCHECK kepes megmondani hogy a container nem indult el normalisan, hogy az orchestration agent ne folytassa a rolloutot c) van monitorozas d) esetleg van autoscaling, hogy ha no a terheles.
25

darabolási kérdés, konkrét környezetben

mind1 valami név · 2020. Jún. 29. (H), 16.27
Ti hogyan építenétek fel ezt a környezetet?

Kell egy syslog szerver, ami mysql-be gyűjti a logokat.
Minden további app/konténer ebbe a log szerverbe küldi a logjait, tehát ő mindenkinek kell majd.

Kell egy DNS (dnsmasq), aki a helyi neveket feloldja.
A legtöbb konténernek rá is szüksége lehet.

Web szerver, flaskre (ez egy pythonos microframework webes alkalmazásokhoz) épülő alkalmazásokkal, részben saját adatbázissal, részben a syslog szerverével dolgozik.
----
+ pár olyan app, aminek a syslog + opcionálisan a dns szolgáltatásra szüksége van.

A ---- utániak mehetnek önállóan? És mi van a ---- előttiekkel?? Miket célszerű közös konténerbe tenni? Mi az, amit a compose segítségével érdemes/kell összefogni? Mi az, ami mehet egyedül is?
26

A hipszter módi

vbence · 2020. Jún. 29. (H), 19.56
Általában egy process egy konténer (hacsak nincs valami komoly constraint). Kivétel mini célszoftverek mint pl Containerpilot.

Loggolásra nem szoktak relációs adatbázist, ma az ELK stack a divatos.

DNS-re Consul (konténeren belül és kívül is működőképes).

A webszolgáltatások elé jöhet egy nginx TLS terminálásra, cachelésre.
27

Az egy konténer-egy processz

mind1 valami név · 2020. Jún. 29. (H), 20.22
Az egy konténer-egy processz nálam ott bukik, hogy a web+app szervert amennyire látom, nem tudom függetleníteni egymástól, mert amíg IPC-n(?) kommunikál, addig elfogadható a sebesség, ha TCP/IP megy közéjük, akkor már gyalázatos.

Lognál tekintsünk el picit attól, hogy én logolásra használom. Inkább az a kérdés, hogy van A konténer, aki ír egy B konténer adatbázisába, de ezt az adatbázist egy az A-hoz csak lazán kapcsolódó alkalmazás is olvasgatná, a C konténerből.

C nem futhat, ha A+B nem működik, de pusztán ezért figjam őket össze a composer(?)rel? Mert ilyen alapon az összes többit is be kellene tenni és az egészet egyetlen egységként kezelni... Szabad ilyet?
28

Pont itt a helye

vbence · 2020. Jún. 29. (H), 20.59
A docker-compose az a réteg ahol "orkesztrálod" az alkalmazásodat. Tipikusan lesz egy gráfod a DB szervereel, web szerverrel meg még a minimummal ahhoz hogy felálljon az alkamazás.
A loggoláshoz már lehet egy másik gráf.

Így tudod elérni, hogy idális esetben minimális plusz munkával fellőssz egy második, mondjuk QA clustert az egész alkalmazásodból. Vagy ott próbálod ki az új imaget (az új kódoddal) mielőtt kimenne élesbe.

Vagy így lőheti fel minden fejlesztő a saját gépén miniben az egész szolgáltatást.

Pythonra van embedded szerver is, mi az előnye külön választani?
29

"Don't use in production

mind1 valami név · 2020. Jún. 29. (H), 21.18
"Don't use in production environment" - ha ugyanarra a webszerverre gondolunk.
30

Általában szolgáltatásonként

Pepita · 2020. Jún. 30. (K), 11.48
Általában szolgáltatásonként egy konténer, nem szeretem erre a process szót használni, mert pl az egyetlen msql szervereden is futhat több egyidejű process.

Minél jobban szét tudod választani a különböző service-eket, annál jobban / könnyebben lesz skálázható.

Pl a db szerver egy konténer, web szerver a másik, python (vagy más futtatókörnyezet) a harmadik, stb. Ha a webszervernek kell egy külön db, akkor az célszerű, hogy szintén külön konténer legyen.
Php "vonalon" szokott olyan felállás lenni, hogy web - mysql - php-fpm (+ külön a cli-knek, web kapcsolat nélkül) - pl memcached - pl xy szolgáltatás még.
Ekkor mondjuk web-ből elég egy, ha nagy a terhelés, akkor php-ból könnyen lehet több, legszebb, mikor a mysql kevés, és azt kéne replikálni.. :)
31

Kicsit elbeszélünk egymás

mind1 valami név · 2020. Jún. 30. (K), 13.12
Kicsit elbeszélünk egymás mellett.
O.K., hogy egy szolgáltatás/konténer, de mit nevezzünk szolgáltatásnak, mondjuk egy nginx-uwsgi-flask-python app négyesnél, ha az adatbázis szervert önállóan kezeljük?

És ha compose-t használok, akkor mi az, amit egy csoportban kell kezelni? Lásd syslog+mysql a tetején, de sok olyanom van, aminek ezek nélkül nem szabad elindulnia, mert a syslog mindnek kell, épp úgy, ahogy az alkalmazásomnak az nginx,uwsgi, adatbázis.
Mert egyelőre úgy fest, hogy ha van valami olyanom, ami mindenhez is kell, akkor az összes létező konténert be kell tenni vele egy "csoportba". Részben a függőség, részben a hálózati kapcsolatok miatt. Nem?
32

Lehet.. :)

Pepita · 2020. Júl. 1. (Sze), 08.51
- nginx-uwsgi-flask-python app:
az nginx "biztosan" önálló, mert - tekintve, hogy webszerver - kiszolgál kvázi statikus tartalmat is (js, css, képek, stb), amihez nem kell a futtató környezet. Nyilván így a statikus fájlokat be kell mountolni ide is. Futtatókörnyezet általában külön, szintén mountolva a szükséges forráskód.
Itt találtam egy példát, nem mysql db van benne, de az most mindegy szerintem. A python-hoz viszont nem tudok jobban hozzászólni, nem használom, de lehet rá sok példát találni.
Olyat is, amikor egyetlen konténerben van nginx-el, tokkal - vonóval, ez szerintem nem annyira szerencsés, mert mi lesz, ha pl 2 vagy több "darab" app-konténert szeretnél majd üzemeltetni, és nginx-ből egy is elég lenne?

És ha compose-t használok, akkor mi az, amit egy csoportban kell kezelni?
Ezt nem értem, docker-compose szerintem nem kezel csoportokat, vagy nem tudom, hogyan.

sok olyanom van, aminek ezek nélkül nem szabad elindulnia, mert a syslog mindnek kell, épp úgy, ahogy az alkalmazásomnak az nginx,uwsgi, adatbázis
Kulcsszó: "depends_on".
Mondjuk a linkelt példából egy kicsit hiányolom a network beállítását, úgy tűnik, hogy default network-ön "mindenki mindenkit" lát, ami felesleges. Pl nginx - db kapcsolat nem kell.

ha van valami olyanom, ami mindenhez is kell, akkor az összes létező konténert be kell tenni vele egy "csoportba". Részben a függőség, részben a hálózati kapcsolatok miatt. Nem?
Igen is meg nem is, fentebb említettem a default network-öt, az ennyi:
networks:
  default:
    driver: bridge
Ezt le se kell írnod, lévén default, viszont ez azt is jelenti, hogy minden egyes konténer rajta a hálózaton, a beállított portokon figyel és válaszol! Célszerűbb csak azokat "összelinkelni", amiknek látni is kell egymást, ezt úgy tudod, hogy (különböző) néven nevezed a network-öket, az adott szolgáltatáshoz pedig azt network "példányt" kötöd be, ami neki kell. Ilyet viszont nagyon rég csináltam, nem vagyok uptodate, docker fórumon érdemes érdeklődni / nézelődni.

Remélem így már tudtam segíteni.
33

Compose esetében jobb híján

mind1 valami név · 2020. Júl. 1. (Sze), 09.48
Compose esetében jobb híján használtam a csoport szót.
Ott ugye van egy konfig fájl, abban mondom meg, hogy mely konténerek tartoznak szorosan össze, állitok be hozzájuk privát hálózatot, ha jól értem. Nem ismerem igazán.

Ui: bocs, napok óta fáj a derekam, tele vagyok gyógyszerekkel, a szokásosnál is lassúbb lettem tőle ;)
34

Igen igen,

Pepita · 2020. Júl. 1. (Sze), 17.44
"config" fájl péda (valódi neve általában docker-compose.yaml):
version: '3'

services:

  apache-php:
    build:
      context: ./docker/apache_php
      dockerfile: Dockerfile
      args:
        APACHE_DOCUMENT_ROOT: "/var/www/public"
    container_name: apache-php
    ports:
      - 80:80
    environment:
      APP_ENV: "dev"
    volumes:
      - ./:/var/www/
      - ./log:/var/log/
      # this takes advantage of the feature in Docker that a new anonymous
      # volume (which is what we're creating here) will be initialized with the
      # existing content of the image at the same location

  db:
    image: mysql:5.5
    ports:
      - 3306:3306
    container_name: mysql-db
    environment:
      MYSQL_ROOT_PASSWORD: "neked megfelelő jelszó"
    volumes:
      - ./db_data:/var/lib/mysql
    restart: always

  memcached:
    image: memcached
    ports:
      - "11211:11211"
    container_name: memcached

networks:
  default:
    driver: bridge
Nagyjából a részei:
- docker-compose verzió, ettől függ, hogy mit hogyan fog értelmezni, itt pl már tiltva van (vagy deprecated?) a konténeren belüli links: -el történő direkt összekötés.
- szolgáltatások, ezen belül:
- apache-php: elég csúnya megoldás így, de egy meglévő dev-szervert akartam "lemásolni", ezért lett egy konténer. Benne:
- context: megmondja, hol található az image, amit fel kell építeni
- dockerfile: Dockerfile saját image-leíró fájlneve
- APACHE_DOCUMENT_ROOT: image-en belül van szerepe, a "hivatalos" apache-php konténerben erre állítja át a docrootot
- ports: megmondjuk, hogy a gazdagép melyik portja felel meg a konténer melyik portjának (sokan nem a 80-ast használják a gazdagépen fejlesztésre, pedig lehet)
- volumes: mount-ok a gazdagépről, itt ez hibás, mert a log kétszer kerül be és nem lehetne egyszerre két helyen...

- kövi service, mysql:
- itt standard "hivatalos" image-et használunk, megmondjuk a pontos verzióját, de nem kell build szekció, mert nem nyúlunk bele.
- MYSQL_ROOT_PASSWORD: értelemszerűen a root user pwd-je lesz erre állítva az adott db szerveren.
- itt is be van mountolva a teljes data könyvtára, így törlés/újrabuildelés után is megmarad a db összes adata
- restart: asszem docker-compose up parancsnál van szerepe, hogy mindenképp felálljon.

- memcached: mert volt a "másolt" dev-szerveren is, viszont könnyedén külön konténerbe tehető "gyári" image-el

- networks: (NEM service!): fentebb már írtam, így nem is kellene megadni.

Hozzáteszem, hogy ez egy több, mint 1 éves példa, van is benne hiba, a v3 - nál biztosan van újabb, de sajnos nem követtem, mert még mindig nem használhatjuk... :(
Az egyes konténereken belül (pl apache-php -ben, a php kódban) így "keresztbe linkelve mindent" az egyes service-ek nevével lehet hivatkozni rájuk, pl a php a mysql szervert így éri el (config részlet):
'hostname' => 'db'

abban mondom meg, hogy mely konténerek tartoznak szorosan össze, állitok be hozzájuk privát hálózatot
Igen, a networks: részen állítod be (nem a példa szerint, hanem többfélét) magukat a hálózatokat, és az egyes service-eken belül azt, hogy "ő" melyik hálózatot / hálózatokat használhatja. Ezt a részét én se vágom nagyon... :)

UI: ezért ne kérj bocsánatot, én is csak akkor reagálok, amikor van időm - türelmem - egészségem, és tudom is, hogy a derékfájás milyen... ;)
35

Lassúság: nem a válaszidőre,

mind1 valami név · 2020. Júl. 1. (Sze), 18.15
Lassúság: nem a válaszidőre, a felfogóképességemre vonatkozik ;)
36

az mind1

Pepita · 2020. Júl. 3. (P), 13.44
Mindenesetre jobbulást kívánok, ez fentebb kimaradt.
37

Köszi, úgy négy és fél órát

mind1 valami név · 2020. Júl. 3. (P), 14.33
Köszi, úgy négy és fél órát késtél... :)
(pontban tíz órakor, a boltban sétálva a helyére ugrott a problémás csigolyám - mondjuk ez most egész jó, ahhoz képest, hogy szinte napra pontosan kilenc éve úgy kiakadt, hogy utána úgy nyolc-tíz hónapot ágyban töltöttem... :( )

Már csak azt kell majd megértenem, hogy a WSGI mit csinál a flask és az nginx között :)
38

layerek?

mind1 valami név · 2020. Júl. 5. (V), 12.13
Van annak jelentősége, hogy egy image-hez hány layer tartozik? Az a napokban tűnt fel, hogy minden egyes RUN, COPY új layert gyárt a build során. Érdemes foglalkozni azzal, hogy minél kevesebb legyen belőlük? Vagy az a néhány, ami egy akár nagyobb build során létrejöhet, nem számít?
39

Best practice

vbence · 2020. Júl. 6. (H), 23.31
Célszerű minimalizálni, de nem kell túlzásba vinni. Csak kövesd a best practice-eket. (Például ha eltávolítasz fájlokat azt ugyanabban a RUN-ban teszed mint amiben felraktad a csomagot amivel a fájlok jöttek). Gyári imagek tanulmányozásából sokat lehet tenulni.
41

Gyári, mint Official?

mind1 valami név · 2020. Júl. 7. (K), 16.56
Gyári, mint Official?

Jé... én emlékszem rosszul, vagy az új feature, hogy azt a kommentet, amire már válaszoltak, nem lehet szerkeszteni? :o


A layerek számának redukálásához szerintem bőven elég, ha a RUN egyetlen parancsot futtat (az ADD, COPY parancsokkal nem lehet mit tenni)
44

Régi

Pepita · 2020. Júl. 8. (Sze), 08.49
azt a kommentet, amire már válaszoltak, nem lehet szerkeszteni?
Ez régi feature (itt), és ha jól tudom, Drupalban default így van.
Szerintem egy "közösségi oldalon" így is kell(ene) lennie.
Pl valaki ír egy szakmai butaságot, válaszolok neki, kifejtve, hogy az miért butaság, ezután ő szerkeszti az eredeti kommentet, hogy már ne legyen butaság -> máris én tűnök hülyének.
Persze a faszbúk és társai direkt megengedik, mert "ettől izgalmasabb", mit sem törődve a konkrétan társadalom- és kommunikációromboló hatásával... (Amikor személyeskedés, sértés van a dologban, sokkal gázosabb ez a szerkesztés - törlés utólag feature.)
40

+1

Pepita · 2020. Júl. 7. (K), 16.52
Nyilván minél kevesebb köztes image jön létre, annál kevésbé erőforrásigényes a build, és tényleg nem kell ronggyá optimalizálni.

Gyári image-ek itt
42

A build erőforrásigénye nem

mind1 valami név · 2020. Júl. 7. (K), 19.34
A build erőforrásigénye nem izgat annyira, de futtatás közben nincs belőle gond, ha tíz-húsz layer kerül még az eredeti image alá/fölé?

Apropó layer: linuxon a jq nevű toolt ismeritek? (docker inspect image-neve | jq ... - szépen lehet szűrni a JSON eredményeket:) )
43

Nincs

Pepita · 2020. Júl. 8. (Sze), 08.42
futtatás közben nincs belőle gond, ha tíz-húsz layer kerül még az eredeti image alá/fölé?
Nincs, mert futtatás közben csak a kész konténer üzemel, az előző, köztes image-ek csak a gyártáshoz kellettek. Ha csak elindítod / leállítod a kész konténert, "rá se néz" a köztes image-ekre.
Még érdekes lehet, hogy by default a köztes image-eket is megtartja (tehát fájlba mentve meg vannak), így ha törlöd is a kész image-et és / vagy kiadsz egy
docker-compose up -d --build parancsot (itt a --build az érdekes, vagy ha törölted), akkor ezeket a meglévő köztes image-eket újra felhasználja -> jóval gyorsabb lesz a build, mint elsőre.
Viszont ez jelentős háttértár-helyet fogyaszt, ha pl egy viszonylag kisebb SSD-d van, azon "meglátszik".
Fentebb ami apache-php -s példát írtam, abból az apache-php image kb 700 MB, és közel ekkorák a köztes image-ek is, emiatt máris kicsit célszerű a darabszámukkal spórolni.
Persze le is lehet törölni a köztes image-eket - mert semmi közük a konténer futtatásához -, de a következő alkalommal, amikor újra kell buildelni, akkor lassabb lesz, mert létre kell hoznia.
Kb úgy néz ki, hogy ahány RUN parancs, annyi köztes image.
linuxon a jq nevű toolt ismeritek?
Nem, lehet azért, mert "megrögzött" windowsos vagyok. :)
45

layerek - olvasnivaló

mind1 valami név · 2020. Júl. 8. (Sze), 12.50
-- na ez hogy lett dupla?? Na mindegy, átírom másra --

Szóval találtam egy kis olvasnivalót a layerekkel és egyéb hasonlókkal kapcsolatban: https://docs.docker.com/storage/storagedriver/

--- ez egyre jobb: nem fogom újra írni, volt itt egy duplikált hozzászólás, ahogy a másodikat átszerkesztettem, eltűnt az első... Nem sérült meg az adatbázis? ---
46

Nem

vbence · 2020. Júl. 8. (Sze), 23.47
Bocs csak láttam, hogy dupla és töröltem a régebbit. Sorry.
47

Azért ez nem semmi időzítés

mind1 valami név · 2020. Júl. 9. (Cs), 00.06
Azért ez nem semmi időzítés volt :)
Ugyanis megnyitottam a témát, láttam, hogy a valójában egyszer beküldött komment két példányban van benn, az újabbat átírtam és mire beküldtem már nem volt meg a régi sem. :)
Ez saccra lehetett úgy 20-30sec.

Egyébként tényleg van valami gubanc a szoftverrel (vagy a mobilommal), mert már sokadszor fordult elő, hogy a "Spamrobot vagy?" captcha valami ocsmány hibaüzenetet dob vissza és nem tudok beküldeni egy kommentet vagy javítást. Ez a duplikátum is úgy jött létre, hogy a captcha-n problémázott, a végén meguntam, kimásoltam a szöveget, majd bemásoltam újként.
48

dnsmasq dockerben

mind1 valami név · 2020. Júl. 12. (V), 17.59
Hátha hasznos lesz másnak is.
Saját dns-t használok régóta, most szántam rá magam, hogy kivegyem a virtuális gépből és áttegyem konténerbe.
Belefutottam pár buktatóba, mert nem olvasok, nem gondolkodok... :(

1. Hiába publikálom az 53-as portot, nem lehet elérni. A konténerben futó tcpdump sem látja.
docker run ... -p IP-cím:53:53/udp ... formában kell ugyanis megadni, mert a /udp nélkül tcp portot publikál.

2. A nálam futó docker valami irreleváns, totál fals hibát dob, ha hiszünk a helpnek, hogy csak az egyik portot kell megadni, ha meg akarom mondani, melyik IP-hez kapcsolódjon és a publikus és a belső port azonos. Látszólag elég a -p 127.1.1.53:53, de valójában kell a második :53 is, plusz a /udp, mert nem minden dns kliens képes tcp-n társalogni.

3. Ha a dnsmasq-ot -d kapcsolóval indítom, akkor is előtérben marad, de ez csak debugra való. Így pl. nem vált usert, rootként fut, bármit csinálsz. Ha meg démonként indítod, akkor ugye elmegy háttérbe, a docker meg leállítja a konténert. (Mire erre rájöttem megint...) Szóval kell neki a -k kapcsoló (keep-in-foreground)

4. Ha -k kapcsolóval indul a dnsmasq, akkor elsikkasztja a logokat. Ahhoz, hogy a stderr-re menjen és a docker logs meg tudja mutatni, kell egy --log-facility="-".

5. Docker run parancsban felül lehet írni az entrypointot, de a paramétereket a konténer neve után kell írni, míg az --entrypoint=parancs kapcsolót elé.

... Valami kimaradt, de nem jut eszembe ...

+1: ha arra valaki tud magyarázatot, hogy a dnsmasq miért csinálja, hogy hol a jelenlegi lokális dnst használja, hol az ISP-től kapottat...a lokális a facebook.com-ra 0.0.0.0 címet ad vissza, a szolgáltatóé meg a valódit (nekem a 0.0.0.0 a jó ;) )
49

darabolás, de nem méret, hanem közös adat kapcsán

mind1 valami név · 2020. Júl. 15. (Sze), 15.47
Előrebocsátom, ez csak próbálgatás, példa, nem akarom feltétlenül meghagyni a syslog-ng-t.

Syslog-ng menne konténerbe, de elfelejtettem, hogy szorosan kapcsolódik hozzá a logrotate funkció(*) is.
Elvileg a syslog-ng konténere kapna egy volume-ot, ami a host egyik könyvtárára mutat.
De ugyanezen a könyvtáron tud dolgozni clusterezés nélkül egy másik konténer vagy a host saját szoftverei?

Plusz az is gond, hogy a logrotate újraindítja a syslog szervert, szóval ha konténerből futtatnám, akkor azt hogy??

Saját elképzelés:
1. Syslog-ng mellé telepítem a logrotate-t is és remélem, hogy egy crontabot is tudok onnan működtetni.
2. A syslog-ng konténer használja a host könyvtárat, de a logrotate a host crontabból fut és nem a syslog demont inditja újra a rotálás után, hanem a konténert.

Valamelyik jó?

* = úgy emlékszem, a logrotate egy önálló csomag, nem része a syslog csomagoknak.


Update: tapasztalati úton úgy tűnik, a volume-ok használata elfogadhatóan működik akkor is, ha több konténer vagy a host+konténer használja.