( golgota | 2017. 12. 21., cs – 22:06 )

Van amire jo a kontenerizacio es van amire nem. Ugye a "run'n'drop"-ra es a "stateless"-re lett kitalalva es nem "long-running services"-re. Szoval ha stateless egy "szolgaltats"(sime progi), akkor mehet a kontenerbe. Ha annal tobbet kell tudnia, akkor mar kerdeses, hogy erdemes e hasznalni. Itt szoba jovet a kernel kontext switching es az altala okozott tul magas syscpu usage, stb, stb. A jol megvalaszott FS is szamit. Az AUFS, LVM, overlayFS1-2, mind masra jo. Belefuthatsz jo nagy I/O problemaba, vagy hogy elfogynak az inode-ok, stb, stb.

Ha a cel az, hogy a szolgalatatsok konfiguracioja mindig azonos legyen, akkor celszeru inkabb valamilyen IaaS megoldast hasznalni, pl. Ansible. Azt GIT-ben tarolni.

A docker eseteben a konfigvaltozas eseten buildelhetsz egy uj image-t minden alkalommal. Megint oda jutunk, hogy ezt csak akkor erdemes csinalnod, ha stateless szolgaltatasokat futtatsz.

Szoval en a kevert megoldasra szavaznrk. Divat mindent kontenerizalni, csak van amit nem erdemes. Es tobb problemat okoz, mint amennyi elonye van. :D