docker konténerek hogyan?

Virtualizáció

Üdvözletem,

A docker technológiát ismerőkhöz lenne pár kérdésem, mert ahogy túrom az internetet, egyre jobban összekuszál. :) Tehát: Ha jól tudom, a docker lényege, hogy konténerekre bontunk (lehetőleg állapotmentes) service-eket, így szétosztogatva, "horizontálisan" skálázhatóvá téve őket. Legjellemzőbben webes kiszolgálók "párhuzamosításával" látom kapcsolatban, nagyon sok leírás ezt taglalja. Vagyis egy tipikus LAMP stack ebben az esetben úgy néz ki hogy van egy konténer az apache-nak, egy a php-nek, egy az adatbázisnak(?) egy volume az adatoknak. Ebből az adatbázis esetleg nem dockerben van, vagy nem rdbms hanem pl. mongodb, vagy van memcached, hol így hol úgy. A lényeg, hogy egy weboldal működéséhez ezek szerint kell mondjuk 4 konténer? A kérdésem az, hogy ha van mondjuk 30 weboldal, az 120 konténer?Példa:

weboldal 1:
-apache 2.1 konténer
-php 5.2 konténer
-mysql 5.1 konténer
-data volume 1

weboldal 2:
-apache 2.1 konténer
-php 5.6 konténer
-mysql 5.2 konténer
-data volume 2

weboldal 3:
-apache 2.2 konténer
-php 7 konténer
-mongodb konténer
-data volume 3

stb..

Ez így működik, vagy máshogyan szervezik össze? Pl.: nincs minden oldalnak külön php-je, van egy php5-ös konténer, "arról megy" minden php5-ös oldal, van egy php7-es, arról a neki megfelelőek, stb., ugyanez apache-okkal, db-vel? És hogy valósul így meg a szeparáció? Vagy teljesen másképp kell elképzelni, fordítva ülök a tv előtt? :)

A másik kérdésem a sok konténer (már ha tényleg így van) erőforrásigénye. Fut pl.: egy fejlesztői szerveren egy db indián virtualdocumentroot-al szétdobva a különböző könyvtárakat mondjuk portonként, egy db mariadb egy schema/oldal, egy php mondjuk modulban és egy másik verziójú fpm-es php. Akkor ez mondjuk 3-4 service minden egyes oldalra, jól leterhelve. Ehhez képest ha minden oldal kap egy külön docker-t a fenti megvalósításban, akkor elképzelhető hogy a 120 konténer nem eszi meg az összes erőforrást, hanem hasonló teljesítménnyel üzemelnek az oldalak? Csak mert a ha a sok weboldalból pl. csak 3-at használnak per pillanat, attól a többihez tartozó docker processzek még futnak, memória, CPU, stb., ez nem okoz gondot?

Remélem érthető valamennyire mi nem világos. :)

  • 4281 megtekintés

( szegecs | 2017. 03. 04., szo – 07:41 )

csak annyi hogy ahova ezt csinálod oda dobd már át a mailcímem hogy holnapután amikor a dokkercancer már divatjamúlt/corrupted/crashed lesz, tudjanak kihez fordulni rendes technológiáért

thx

lxc, lxd, BSD jails, Solaris zones, rkt

A Docker azert lett nepszeru, mert kezdo-barat a tooling, viszont teny, hogy tele van buggal. Az oke, hogy elinditasz egy kontenert, es fut -- de az eles setupok eseten biztos, hogy elokerul az, hogy
- milyen CoW UFS-t hasznalsz? AUFS nem jo, ha sokat irsz. overlay2 -- tok jo, lassan kikerul a betabol.. ZFS on Linux .. ize, production-ben inkabb hagyjuk. btrfs detto. loop devicemapper lassu. DM on LVM -- ez talan oke, marmint jelenleg.
- milyen halozatot hasznalsz? VXLAN? weavemesh? Weave net? Siman host networking? VXLAN (meg egyeb overlay) eseten kell egy clustered KV store, ami normal esetben minimum 3 extra gepet jelent. A networking tele van buggal, bizonyos esetekben nem tud a kontener racsatlakozni a networkre, amig nem restartolod a docker daemont (ami egyenlo azzal, hogy az osszes kontenert restartolod)
- hogy menedzseled a kontenereket? Ansible/Puppet/Chef? Tok jo, csak ugye akkor vegulis egy csomo elonyet elveszted a kontenerezesnek. Kubernetes? Jo, de bele kell tanulni. Swarm? Bugos mint az allat. Mesos? Megintcsak jo, de bele kell tanulni.

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

Komolyan végre valaki, aki kb ugyanúgy látja a docker körüli dolgokat mint én. Környezetemben mindenki az egekig hype-olja és nem akarják megérteni, hogy miért utálom.

Annyit finomítanék csak rajta, hogy: AUFS - nemcsak akkor rossz ha sokat írsz, ez úgy hangzik, mintha csak teljesítményprobléma lenne vele. Konkrétan kernel panic-okat tud okozni a hoston. (Ez nyilván inkább az AUFS hibája, szigorúan véve nem a dockeré). A devicemapper-es megoldások (főleg a loop) meg hajlamosak leakelni diszk helyet, amit csak teljes kiürítéssel lehet helyrehozni. LVM-es devicemapper - ez az egyetlen production környezetben is használható megoldás, de itt meg sok szerencsét a snapshot thinpool debugoláshoz, ki sem tudod listázni a snapshot id-ket, külön metadata dump analyzer tool kell hozzá. Szóval nincs egy épkézláb storage backend docker alá.
A másik meg a security (illetve annak hiánya). Ugye az még mindig megvan, hogy a docker konténert indítani képes user számára dokumentált módszer van root szerzésre a hoston. Meg úgy általában a 'volume' feature (hülye elnevezés, a volume alatt kb mindenhol block storage-et szoktak érteni, de a dockernél ez egy filesystem bind mount) tele van security problémákkal, pl uid-k megosztása a konténeren kívül és belül.
És akkor a registry végeláthatalan problémáiról még nem is beszéltem.

Szóval igen, kb arra jó, hogy fejlesztők életét könnyűvé tegye, de production használatra szerintem eléggé problémás.
---
Régóta vágyok én, az androidok mezonkincsére már!

Varj, azert nem egeszen ertunk egyet :) En / mi production-ben is hasznaljuk ezerrel, es nagyon megvan a helye, a lenyeg, hogy
1) ez nem egy VM
2) oda kell figyelni

> a volume alatt kb mindenhol block storage-et szoktak érteni, de a dockernél ez egy filesystem bind mount

Vagy igen, vagy nem. Felhoben (pl. Azure) hasznalhatsz sajat volume drivert, ami nem bind mount.

Mi peldaul azert hasznaljuk mindenhol, mert 100% remote dev team van, tehat mindenki otthonrol dolgozik. Kepzeld el, hogy hogyan tudnal otthon egy laptopon egy tucat szolgaltatasbol es tobb adatbazisbol allo rendszeren integracios teszteket futtatni kontenerek nelkul. (Meg lehetne oldani, de nagyon-nagyon maceras.) Raadasul nalunk nincs kb. semmi eloiras arra nezve, hogy milyen OS-t hasznalj, vannak Linuxos, OSX-es, Windowsos kollegak, es ha mondjuk hozzaadunk egy uj komponenst a rendszerhez, akkor egy git pull utan mindenkinel ott van, es ami helyben megy, az jo esellyel menni fog prodban is.

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

( sj | 2017. 03. 04., szo – 08:40 )

lényeg, hogy egy weboldal működéséhez ezek szerint kell mondjuk 4 konténer? A kérdésem az, hogy ha van mondjuk 30 weboldal, az 120 konténer?

gondolom, nalad a "weboldal" az egy website, egy virtualhost. Ha csak keves site-od van, akkor lehet minden site-nak sajat kontenere(i), de egy hataron tul - szerintem - ez nem lesz jo.

A minden service sajat kontenerbe egy lehetseges megoldas, de mindig merlegelni kell az adott korulmenyt, hogy jobb osszerakni a cuccot. Ami az adatbazist illeti, megoszlanak a velemenyek, van aki szerint az nem igazan jo dockerben. A te esetedben (meg ha vegul docker-be is teszed a mysql-t) en nem futtatnek site-onkent egy sql kontenert, hanem lenne egy HA mysql setup, es azt hasznalnak a kontenerek.

A webszervert egy kontenerbe tennem a php-val. Sot, nagyon elgondolkoznek, hogy apache helyett inkabb nginx legyen, mert kisebb a footprint-je.

A data volume is atgondolando, nem kell hozza ujabb kontener, ha az adatok a futtato host-on vannak.

Es akkor arrol meg nem is beszeltel, hogy milyen porton fognak futni a webszerverek?

Konténerben simán lehet adatbázis -- UFS-en nem ajánlott adatokat tárolni, magát az adatbáziskezelőt nyilván lehet (a neten egy csomó marhaságot beszélnek erről).

> A webszervert egy kontenerbe tennem a php-val.

Abszolut nem foglalkoztam PHP-val, de egyaltalan lehet ezt maskepp? A PHP Apache modulkent fut, es nem szeparalt processz, tehat nyilvanvaloan ugyanabban a kontenerben kell lennie.

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

linuxon nem annyira elterjedt az ufs, imho (ha mar docker-rol beszelunk).

Abszolut nem foglalkoztam PHP-val, de egyaltalan lehet ezt maskepp?

azt latom :-) A php-fpm tud socket-en hallgatozni, igy teheted masik gepre is, aztan a webszerver meg siman eleri.

A PHP Apache modulkent fut

lehet igy is, meg mashogy is, es akkor nem kell feltetlen ugyanabban a kontenerben lennie.

Ahogy írják is, a php-fpm nem az apacheban van, hanem egy külön socketen lesi a kéréseket. Illetve, csavarosan: van az apache-ban egy php modul, (5.6) és figyel a szerveren egy php-fpm (7.1), így aminek 7-es kell, annak a virtualhost konfigban meg van mondva, hogy a php fájlok a php-fpm-en menjenek át, aminek meg a "régi", annak meg nincs, az marad 5-ös.

Erre nincs feltetlenul szukseg. Alapesetben a szerver kontenerek sajat alhalozaton uldogelnek a sajat kis IP-cimuk mogott, tehat siman expozalhatjak pl. a 80-as portot, nem zavarjak egymast. Elejuk rakhatsz egy reverse proxyt, peldaul. Szoval ha mar Dockeren belul maradsz, akkor megcsinalhatod azt, hogy futtatsz egy ilyet:
https://github.com/jwilder/nginx-proxy

Ez annyit csinal, hogy indit egy nginx-et, es ha a hoston elinditasz egy masik X kontenert (pl. Apache+PHP kombot), akkor X inditasakor specifikalsz egy doment (foo.huptudomany.hu, peldaul), es az nginx-proxy kontener automatikusan general egy reverse proxy konfiguraciot hozza.

Magyarul: semmi mas dolgod nincs, csak felloni ujabb es ujabb Apache+PHP kontenereket, es elerhetove valnak a megfelelo domainen. Ezt meg lehet kombinalni ezzel https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion, ami meg megfejeli a fenti setupot azzal, hogy automatan ker neked egy SSL certet a Letsencrypt-tol.

Production-ben nem feltetlen hasznalnam, de jatszani jo - par perc alatt fellohetsz egy tucatnyi webszervert ugy, hogy mindegyik valid SSL certtel rendelkezik, satobbi.

Mi ezt arra hasznaljuk, hogy a Bitbuckethez csinaltunk nehany apro beepulo modult, es a BB OAuth folyamathoz HTTPS callback URL kell. Tehat ezek az apro modulok egy ilyen nginx+letsencrypt megoldas mogott ulnek, nem kell foglalkozni azzal, hogy mikor jar le a cert, etc. Ez persze mind fejleszteshez hasznalt utility, es nem lenne oriasi gaz, ha valami miatt nem mukodne egy par oraig.

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

Ha egy ip és egy port mögött kell kiszolgálni több domaint, akkor hogy kerülod el a SPOF-t? Na pont ugyanazt itt is megcsinalhatod. Nem értem a problematokat (vagy ti nem értitek, hogy mit akartam illusztrálni).

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

( sz332 v | 2017. 03. 04., szo – 09:09 )

Első körben a docker in practice könyvet javasolnám olvasásra (én most ezt olvasom), google a barátunk, a http://pepa.holla.cz - on kezdenék körülnézni ;)

( Aadaam v | 2017. 03. 04., szo – 11:49 )

Figyu, marha egyszerű szerintem: a docker egy lightweight VM.

Akkor használod ha valamiből sok ugyanolyan instance kell. Ilyen lehet akár egy PHP-apache futtató (master DB környezet nélkül), MySQL slave-ek, egy reddis vagy memcached vagy egyéb cache layer...

Megoldja neked az amazon is, persze, felpörget egy komplett VM-et, saját processor core-ral, mindennel, kérdés, mennyi idő alatt és mennyi pénzért.

én csak UI-t tervezek, te is tudod, a docker-t nekem csak annyira kellett értenem hogy tudjam hogy mi az a komponens ami nagy terhelést fog kapni (mert mondjuk kitaláltam egy autocomplete-et), azaz mi az ami a rendszerben potenciálisan bottleneck, meg mi lehet független mitől és mi nem, mert ezt meg a devops-osok nem fogják kitalálni maguktól.

( Saboteur v | 2017. 03. 04., szo – 13:01 )

Már régóta tervezek egy posztot a honlapomra erről, szóval itt a remek alkalom, hogy megírjam a vázlatot.

Én minden projektnek külön containert adok, ha csak ideiglenesen használom (le kell húzni, hogy lokálisan változtassak valamit, aztán mehet vissza), akkor egy docker-compose down -d fel is takarít utána.

Az ügyfeleknek szánt fejlesztői szerveremen egy webserver (php:7.0-apache), egy adatbázis (mysql:5.7) és egy phpmyadmin fut, az alábbi konfig szerint:

/home/username
- repo
- server
- www

  • a repo a bare git repo-k helye.
  • a www a tényleges fájlok helye (/var/www, ezen belül lesznek a konyvtárak, hostnevenként)
  • server pedig a Docker konfig fájlok helye

docker-compose.yml a /home/username/server-ben:

version: '2'
services:
webserver:
build:
context: .
dockerfile: Dockerfile_webserver
container_name: webserver
links:
- database
ports:
- 80:80
working_dir: /home/username/www/
volumes:
- ../www/:/var/www/
depends_on:
- database
restart: always
database:
image: mysql:5.7
container_name: database
ports:
- 3306:3306
environment:
- MYSQL_DATABASE=staging
- MYSQL_ROOT_PASSWORD=wWfAJ26exbjCUfRU
- MYSQL_USER=webmenedzser_YXFyDoGuh4PHATQ
- MYSQL_PASSWORD=NdYEbRGJxouyKHimDhkFnUyxwq1omG8KNLOHafdl
restart: always
phpmyadmin:
image: phpmyadmin/phpmyadmin
container_name: phpmyadmin
ports:
- 2999:80
volumes:
- /sessions
links:
- database:db
restart: always
volumes:
db:

Dockerfile_webserver a /home/saboteur/server-ben:

FROM php:7.0-apache

RUN apt-get update && apt-get install -y \
libfreetype6-dev \
libjpeg62-turbo-dev \
libjpeg-dev \
libmcrypt-dev \
libpng12-dev \
&& docker-php-ext-install -j$(nproc) iconv mcrypt \
&& docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ --with-png-dir=/usr/include --with-jpeg-dir=/usr/include \
&& docker-php-ext-install -j$(nproc) gd mysqli

RUN a2enmod rewrite expires

#VOLUME /home/saboteur/www/
ADD sites.conf /etc/apache2/sites-enabled/000-default.conf

CMD ["apache2-foreground"]

sites.conf a server-ben:

ServerName dev.domain.hu
ServerAdmin root@domain.hu
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

DocumentRoot /var/www/aldomain1.domain.hu
ServerName aldomain1.domain
ServerAlias www.aldomain1.domain

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

DocumentRoot /var/www/aldomain2.domain.hu
ServerName aldomain2.domain.hu
ServerAlias www.aldomain2.domain.hu

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

Ha új vhost kell, akkor veszek ide fel egyet, és nyomok egy docker-compose up --build -d-t. Ezzel megvan az apache restart is, újraépült a container, és máris elérhető az odairányított domain tartalma.

Köszi, de szerintem meg van:

Ez így működik, vagy máshogyan szervezik össze? Pl.: nincs minden oldalnak külön php-je, van egy php5-ös konténer, "arról megy" minden php5-ös oldal, van egy php7-es, arról a neki megfelelőek, stb., ugyanez apache-okkal, db-vel? És hogy valósul így meg a szeparáció? Vagy teljesen másképp kell elképzelni, fordítva ülök a tv előtt? :)

...

A másik kérdésem a sok konténer (már ha tényleg így van) erőforrásigénye. Fut pl.: egy fejlesztői szerveren egy db indián virtualdocumentroot-al szétdobva a különböző könyvtárakat mondjuk portonként, egy db mariadb egy schema/oldal, egy php mondjuk modulban és egy másik verziójú fpm-es php. Akkor ez mondjuk 3-4 service minden egyes oldalra, jól leterhelve. Ehhez képest ha minden oldal kap egy külön docker-t a fenti megvalósításban, akkor elképzelhető hogy a 120 konténer nem eszi meg az összes erőforrást, hanem hasonló teljesítménnyel üzemelnek az oldalak? Csak mert a ha a sok weboldalból pl. csak 3-at használnak per pillanat, attól a többihez tartozó docker processzek még futnak, memória, CPU, stb., ez nem okoz gondot?

( mortein79 | 2017. 03. 04., szo – 21:37 )

Köszönöm a sok értékes információt, valamit oszlott a köd, illetve örülök hogy közben olyan "járulékos" hozzászólások is születtek, amik szintén hasznosnak fognak bizonyulni.

Arra gondoltam, hogy a minden-service-egy-kontener helyett úgy építem majd fel, hogy:
-mysql marad natívan, adataival együtt, egy darab
-fájlrendszer szintén marad a helyén, és be lesznek az egyes könyvtárak csatolgatva a konténerek alá
-konténerbe a webszerver és a modulba rakott php kerül, website-onként a megfelelő verziók

A mysql szerver "konténerizálásán" még gondolkodom, de lehet nem sokat jelentene, úgyis mindenkinek külön user/port van.

A fájlrendszer azért is praktikus így, mert a vcs is különösebb gond nélkül hozzá fog férni amihez akar, illetve az elérés (phpstorm ssh-n) sem kell külön variálni. Az mondjuk lehet megérne egy próbát, hogy a konténerbe belekerülhetne pluszban egy sshd meg egy git, de ez valószínűleg már felesleges.