Mivel már többen linkelték, mint a Docker haszontalanságának bizonyitékát, elolvastam a cikket.
Olvassunk egy kicsit a sorok között:
- Adott egy cég, ami sok pénzt mozgat, feltételezem, hogy nekik is van rendesen budgetjük
- Elkezdik bevezetni a Dockert, de nem vesznek supportot (legalábbis mélyen hallgatnak róla)
- Meglepődnek, hogy az open-source verzió nem örökké + 1 napig supportált, hanem kb. a bleeding edge van kirakva
- Debian Jessie-n akarnak Dockert futtatni, amit nem erre terveztek
- Később rájönnek, hogy a Docker az csak egy konténer runtime + API, semmi más funkcionalitást nem nyújt (ki igért ilyet?)
- Miután leoltották (gondolom, nem volt időm/kedvem végigolvasni) a kommentekben, updateli a cikket, hogy ja, van itt egy CoreOS nevű dolog, amit direkt arra terveztek, amit mi akarunk csinálni, de nem próbáltuk
- Ugyanezt Kubernetes-szel
- És végül, hogy teljes legyen a kép, leírja azt is, hogy van ez a Google Container Engine, ami Kubernetes és Docker felett fut, és azt tudja stabilan, amit ő nem tudott összerakni
Akkor ezért most a Docker a hibás?
Ez nekem ahhoz hasonlít, mint amikor tavaly az Uber körbehaknizta a sajtót, hogy ők most visszaváltanak Mysql-re Postgres-ről, mert ilyen-olyan gondjaik vannak Postgres-szel. Aztán a sorok között olvasva (illetve meghallgatva a kampány "arcát" a SW Engineering Daily podcaston), azért árnyalódott a kép:
- nem kellőképpen tesztelt séma updatek miatt "némi" problémába ütköztek a szoftver updateknél
- valakinek eszébe jutott, hogy a Postgresnél a séma update is rollbackelhető, ha gond van (egyébként ez király feature, én is nagyon szeretem)
- nosza váltsunk Postgres-re
- USA két partja között csináltak eddig automata replikálást Mysql-lel (ahol ez logikai = SQL statement szintű), de sebaj összelőjjük Postgres default verziót (WAL replikálás)
- Csodálkoznak, hogy a két megoldásnak mások a trade-offjai, pl. teljesítmény-karakterisztikában
- Nem hívnak egy hozzáértőt (esetleg vezetnek be logikai replikálást Postgres felett), hanem inkább vissza Mysql-re (meg építenek saját "schemaless" megoldást Mysql fölé, juhé!)
Akkor ezért most a Postgres (vagy korábban a Mysql) volt a hibás?
És halkan megkérdezném, hogy hol van mindkét történetben a CTO, aki ezeket a döntéseket jóváhagyta?
A Docker-t nem csodaszer, egy alacsony szintű API a (mostmár elvileg cserélhető) OS konténer runtime-ok felett.
Sőt a Docker Inc. féle implementációval erős fenntartásaim vannak, de maga az irány (lightweight, egyfeladatos OS konténerek) szerintem jó.
Production konténer alapú rendszert én Kubernetesre (ill valamelyik kereskedelmileg támogatott disztribúciójára pl. Google Cloud Engine, RH OpenShift) építenék. És Kubernetesen belül is nagyon meg kell válogatni, hogy melyik feature-t használod, és miért.
Érdemes meghallgatni Bryan Cantrill előadását, hogy ők a Joyent-nél SmartOS / Triton felett, hogyan építettek automatikusan skálázódó Docker runtime-ot (nem a Docker Inc. implementációval), milyen architektúrát használnak és miért (és emiatt miért nem támogatnak bizonyos Docker funkciókat): https://www.joyent.com/blog/docker-and-the-future-of-containers-in-prod…
Gyakorlatilag a teljes Triton cluster egy db óriási Docker hostnak tűnik, a konténerek menedzsmentjét / ütemezését megoldja a Triton.
Mi a cégen belül év végéig át akarunk állni egy Kubernetes alapú infrastruktúrára a mostani Proxmox alapúról.