Docker adds an intrusive layer of complexity which makes development, troubleshooting and debugging frustratingly difficult, often creating more problems than it solves. It doesn’t have any benefits over deployment, because you still need to utilise snapshots to achieve responsive auto scaling. Even worse, if you’re not using snapshots then your production environment scaling is dependant on the stability of Docker Hub.
2 Likes
Si eu care speram ca Docker sa fie ceva mai rasarit decat Vagrant (nu sunt chiar acelasi lucru si clar au fost construinte cu scopuri diferite dar au si destul functionalitati comune).
Cel mai mare plus din punctul meu de vedere era posibilitatea de a implementa rolling updates in productie, dar niciodata nu m-am simtit destul de confortabil cu Docker incat sa si incerc o implementare cap-coada. Aparent am fost inspirat.
1 Like
Dacă aș fi în locul tău, aș încerca orice unealtă ce promite că-mi face viața mai ușoară. Dacă stai să te gândești puțin, absolut orice tool are criticii personali.
Poate pentru Cal a fost mult mai mult/puțin decât avea nevoie de fapt și a simțit că nu este potrivit 
Chiar daca este categori si dur, indica multe puncte nevralgice are plaformei in sine. Docker e o chestie foarte misto pe hartie, in realitate mai au multe de rezolvat (si aici nu ma refer neaparat la Docker in sine, cat si la tehnologiile pe care se bazeaza in spate care nu sunt toate neaparat mature).
Una peste alta pot sa imi fac treaba destul de usor si cu OpenVZ si Amazon Beanstalk (vendor lockin, asta este).
Uite aici de ce este preferat Docker în cazul Discourse:
E destul de greu să-l iei pe tipul ăsta prea în serios la cât de agresiv scrie. Ținând cont că pare că are destule cunoștințe de “containerisation” nu pot decât să presupun că unele din criticile lui sunt valide. Cu toate astea, până și mie, care sunt relativ nou în domeniu, îmi e evident că unele argumente sunt complet neadevărate:
If you’re not using snapshots then your production environment scaling is dependant on the stability of Docker Hub
Fals. Docker Hub e doar un provider ca mulți alții (inclusiv unul recent lansat de Google: Google Container Registry folosit in special împreună cu Google Compute Engine). Sau dacă te îngrijorează prea tare stabilitatea lui poți să-l hostezi singur.
Hypervisor performance is almost as fast as bare metal and, interestingly, faster in some cases
Building multiple images of a single repo is not possible
Implementat în Docker 1.5
În concluzie nu m-aș avânta să trag concluzia că nu merită să încerci Docker doar pentru că un tip de pe net zice că e “an absolute shit show of abysmal performance”. Cu atât mai puțin cu cât Google se pare că investește masiv în direcția asta în ultimul timp (exemple: Container Optimized Images, Container Engine, Kubernetes, etc)
1 Like
Questions:
De ce ai folosi linked containers - de exemplu mysql, nginx, centos - in locul unei imagini de OS cu serviciile instalate? - care sunt avantajele si dezavantajele celor 2 setup-uri.
Cum tii setarile legate de servicii (nginx hosts and configs), cum tii bazele de date, fisierele cu cod - folosesti mappare prin data volumes /fisierconfig, /folderapplication, /folderdatabases?
Mă gândesc că este vorba de o eventuală scalare. Se abstractizează mașina ce conține toate serverele în mașini complet independente, ce le poți schimba/scala după bunul plac.
În cazul unui trafic uriaș, vei putea muta containerul cu sql pe o mașină, containerul cu nginx pe o altă mașină șamd.
Adică un fel de Single Responsability Principle.
1 Like
Câteva motive ar fi:
- Scalare. Cum a zis si @iamntz, ca să poți să scalezi individual fiecare serviciu (web, db, workers, etc)
- Dependency hell. Fiecare container are librăriile proprii ceea ce face mult mai ușor să instalezi programe cu “conflicting versions of shared libraries”.
- Startup times. Un container pornește în sub o secundă în timp ce un un OS durează minim câteva secunde.
Recomandarea e să folosești environment variables cu care configurezi containerul în momentul în care îl pornești cu docker run -e HELLO=world my_container.
Altă variantă e ca fiecare container să se conecteze la un key-value store de unde să-și ia singur configurația (etcd e un “distributed key-value store” destul de popular pentru chestia asta).
De exemplu vulcand e un reverse proxy/load balancer care fix asta face. Avantajul lui față de nginx e că poți să-l reconfigurezi live (fără restart) doar modificând valorile din etcd și modificările se aplică instant. Impresia mea e că o să apară o gramađa de servicii/servere care o să funcționeze similar pe viitor.
Cum ai spus și tu, folosind mapare prin data volumes. Mai concret pe AWS/GCE dacă ai vrea să ai un server PostgreSQL ai putea face asta în felul următor.
Creezi un “persistent disk” (numit postgres) pe care îl atasezi unei instanțe și il montezi pe host la /var/postgresql_data. În momentul în care pornești containerul de PostgreSQL montezi din host:/var/postgresql_data în container:/var/lib/postgresql/data. Atunci containerul o să salveze datele in /var/lib/postgresql/data care defapt le salvează pe host în /var/postgresql_data care de fapt se salvează pe diskul postgres.
Asta înseamnă că datele rămân în siguranță și după resetarea/terminarea instanței ceea ce se pliază bine cu conceptul de “immutable infrastructure”.
Codul de obicei se salvează in imaginea de container când o construiești cu: docker build ...
Codul ar trebui scris conform principiilor Twelve-Factor app astfel încât să nu conțina chestii private (credentials, tokens, etc) pentru că alea vor fi specificate în momentul în care se pornește containerul (prin environment variables).
2 Likes
Multumesc pentru raspunsuri. Acum caut solutie pentru home server Cheap home server
Ce parere aveti de Sistem Raspberry Pi 2 ca server LAMP
Salut, deși postarea este veche, am și eu de adăugat câte ceva legat de docker 
Am lucrat foarte mult ca sysadmin “clasic” (unix/linux), în enterprise. Unul dintre lucrurile cele mai importante (în afară de backup, evident), este automatizarea. Ca și sysadmin, trebuie să automatizezi totul, de la instalarea windoze-ului pe o stație, până la instalarea și configurarea ultimului serviciu pe servere. Să stăm numai pe partea de servere: în mediul clasic, folosești o grămadă de tools, ansible, chef sau, preferatul meu, saltstack. Cu toate acestea, orchestrarea și scalarea serviciilor este greoaie, complexă și necesită multă experiență.
Cu docker, lucrurile se schimbă. Toate astea dispar și se simplifică mult. Chiar și logurile, multe chiar nu ne interesează. Trebuie să vă imaginați docker ca și “building-blocks” pentru soluția aleasă, un fel de cutii negre, care asamblează soluția finală definind legături între ele, iar orice “cutie” se poate strica și înlocui oricând cu alta, din mers.
O soluție finală (am să vă dau un exemplu de instalare owncloud) necesită mai multe servicii care “cooperează” între ele. Doar priviți cum se instalează “de mână” owncloud: trebuie să înstalezi mysql, trebuie să instalezi dependințele (php etc), trebuie să instalezi nginx sau altă soluție de proxy și load-balancing (poți și fără load-balancer, dar renunți la scalare). Pentru toate astea, trebuie să faci configurațiile în softul de automatizare, de obicei destul de personalizate, că nu ai timp să le faci generice, să fie utile oriunde. Să nu mai vorbim de cei care vin din lumea windows, unde instalarea unui soft se face cu un dublu click și apoi next-next. Dacă vor să testeze ceva pe linux, pentru ei este dificil să ducă până la capăt o instalare de bază.
Cum schimbă docker asta: fiecare serviciu care alcătuiește soluția finală este o imagine docker, care se configurează folosind variabile de environment, pentru a coopera cu celelalte servicii. Putem porni imaginile pe o singură mașină, pasând variabilele necesare, putem apela la docker-compose, pentru a defini un sistem complet sau putem folosi un mediu de orchestrare ca și kubernetes, rancher, swarm etc pentru a rula imaginile.
În loc de instalarea fiecărui serviciu în parte, luați un fișier docker-compose.yml, rulați docker-compose up și gata, toate softurile se instalează iar orchestrarea se face prin api-ul pus la dispoziție de Docker.
Un exemplu de fișier compose: https://github.com/mihaics/docker-owncloud/blob/master/docker-compose.yml
Și acum să revin la ce am spus mai sus: REST API pentru orchestrare. După mine, cel mai mare avantaj, un api permite definirea soft a arhitecturii dorite. Adio puppet și alte prostii, e totul inclus
Un exemplu, care instalează până la capăt owncloud, cu nginx, certificate letsencrypt etc, testat de mine pe servere scaleway cu imaginea lor de docker găsiți aici:
https://mihaics.github.io/docker-owncloud/
Ar mai fi multe de spus despre coordonarea imaginilor aflate pe servere diferite, managementul volumelor de date (am lucrat cu ceph și kubernetes pentru asta), dar poate, dacă mai sunt persoane interesate să continuăm discuția.
Evident, docker nu este un panaceu universal, este util când vrei să folosești aplicații cloud, care trebuie să scaleze de la sute de utilizatori la milioane de utilizatori și sunt scrise de la început pentru asta, ca și micro-servicii.
Din întâmplare, docker merge bine și cu unele aplicații mai “clasice”, owncloud de exemplu poate fi fentat să scaleze, cu volume ceph și clustere de baze de date master-master (galera pentru mysql) deși nu are o arhitectură gândită de la început pentru un astfel de deployment. Și când spun scalare, în exemplul de mai sus, puteți cu $docker-compose scale owncloud=2 să mai porniți o instanță de owncloud, nginx o va detecta automat și va face load-balancing (trebuie să văd cum accesează două instanțe de owncloud același repo, fără conflict, dar până nu încercă să scrie în același fișier simultan - condiție la care nu prea ar trebui să se ajungă, cred că va rula ok).
5 Likes
Unikernels, anyone?