A cégeteknél használtok Docker konténer-virtualizációs technológiát?

Kérdés

Igen, élesben
14% (40 szavazat)
Igen, de még csak tesztelünk
10% (29 szavazat)
Fontolgatjuk
13% (38 szavazat)
Nem, mert még nem kiforrott
7% (19 szavazat)
Nem, mert nincs szükség rá / felesleges / nem kell
49% (144 szavazat)
Egyéb (Leírom)
8% (22 szavazat)
Összes szavazat: 292

Saját infrastruktúrával mennyire bonyolult beállítani? Legutóbb amikor néztem kb. csak a Google Cloud-jával működött out-of-box módon. Egyébként szimpatikus, viszont most már van Docker Compose, Swarm, Machine, Networking is, szóval lehet egyre kevésbé létezik a probléma amit próbál megoldani.

( ScOut3R | 2015. 07. 19., v – 11:19 )

Hasznalnam, CoreOS alapokon, de sajnos nem rajtam mulik. :)

( nevergone v | 2015. 07. 19., v – 14:10 )

Nagyon jó lenne, ha a Docker Compose menne kb. mindenhol és nem kellene Vagranttot használni.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

( o_O v | 2015. 07. 19., v – 21:32 )

CoreOS + Docker elesben.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

( uid_720 | 2015. 07. 20., h – 10:32 )

Nem dockert, de másikat használunk.

Fuszenecker Róbert

( thxer v | 2015. 07. 20., h – 14:30 )

Nem, mert a kollégák nem értenek hozzá, pedig hasznos lenne.

( csardij v | 2015. 07. 20., h – 14:43 )

Van valakinek valami rövid összefoglalója, hogy ez miért is annyira király?

"Build, Ship, Run" :)
Egy docker enginen kivul nincs masra szukseg es maris fut az alkalmazas
A fejleszto gepen mindegz milyen oprendszer van a cel oprendszerre tud dolgozni
Szabalyozhato a felhasznalt eroforrasok
Mar 1 fizikai vassal tudsz nulla leallassal releaselni
Egy darab build fajlba le tudod irni a telepites teljes folyamatat es azt barhol barhanyszor reprodukalni tudod
Ha ertesz hozza egy rakas penzt lehet vele keresni
Meg meg egy rakas dolog

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - harmadik rész

Nagyon rövid összefoglaló:
Az alkalmazásodat a környezetével együtt terjeszted. Hogy mit értesz pontosan környezetnek, azt te határozod meg (pl. libraryk, beállítások, más alkalmazások, függőségek).
Amikor az alkalmazásodat (a docker image-edet) elindítja valaki (akár több példányban), minden ott lesz egy helyen, nem kell azzal foglalkoznia, hogy honnan szerez pl. libstdc++.so.5-öt egy 100 éves kereskedelmi alkalmazáshoz).

A háttérben LXC, libvirt és hasonló fekete mágiák működnek, tehát a konténerek ugyanazon kernelt használják, és viszonylag olcsónak mondatnak.

Fuszenecker Róbert

Baromira nem újdonság ez, de régebben meg az volt a baj, hogy milyen az már, hogy egy app magával hordozza a függőségeit, milyen undorító, használja a rendszerhez telepítettet, mert hát pazarolja a HDD-t....
Most újracsomagolták ezt az ötletet, implementálták más technológiákkal, adtak neki egy nevet, és voilá, az egész világ rákapott.
De bezzeg egy app ne csomagoljon maga mellé JRE-t vagy QT static libeket, mert fujfujfujfujfuj.

Mi Hadooppos környezetben használjuk előszeretettel, és baromira élvezzük, hogy minden szir-sz@r része konténerbe van zárva, és hozzák magukkal a konfigurációikat, meg mindent, ami kell hogy fusson a cucc.

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - harmadik rész

Akkor jönnek majd a dedup filerendszerek, amelyek alulról oldják meg, hogy a tizensok egyforma libstdc++.so.5 csak egyszer foglalja el a helyet. Ilyen, amikor átgondolás helyett ad-hoc oldunk meg mindent. Amit nem értek, hogy akkor miért nem fordítanak mindent statikusan és hagyják a fenébe a shared libeket?

Ave, Saabi.

A konténerizáció azért annál egy kicsit többröl szól, mint, hogy a függőségeket összecsomagoljuk egy dobozba. Ott van pl, hogy a fejlesztő gépén nem szükséges ugyanazt az oprendszert telepíteni, ugyanolyan környezeti változókat konfigurálni, mint amilyen az alkalmazásé lesz végül (nem beszélve a a QA gépekről, meg CIről stb). Vagy pl gyönyörűen lehet clusterezett környezetet szimulálni akár egy gépen is, lehet tesztelni, de akár éles környezetben meg lehet oldani 2 konténerrel, meg egy LB-el, hogy leállás nélkül lehessen releaselni egy alkalmazást. Vagy pl erőforrásokat lehet szépen szabályozni, pl fogsz egy konténert beállítod, hogy a memória 98%-át használhatja csak, és ha elszáll az app, akkor is marad erőforrás újraindítani az egészet. Vagy ott vannak a különböző eventek, amiket el lehet kapni. Meg tudod csinálni, hogy figyeled a konténerek indítását leállássát, és így tudod valami service discovery rendszerben regisztrálni a futó szolgáltatásokat. De lehet csinálni clustert is, ahol egy gépről tudod vezérelni, hogy adott konténer melyik gépen induljon el stb.

Egy szó mint száz csomó mindenre való a Docker, persze csomó mindenre nem, és ha megfelelően van használva, akkor remek eszköze lehet a fejlesztőnek.

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - harmadik rész

"Ott van pl, hogy a fejlesztő gépén nem szükséges ugyanazt az oprendszert telepíteni, ugyanolyan környezeti változókat konfigurálni, mint amilyen az alkalmazásé lesz végül (nem beszélve a a QA gépekről, meg CIről stb). " És ez mondjuk egy JVM esetén is igaz.
"Meg tudod csinálni, hogy figyeled a konténerek indítását leállássát, és így tudod valami service discovery rendszerben regisztrálni a futó szolgáltatásokat. " Régóta része a Java EE-nek az ilyen dolog.

Ezek baromira nem új dolgok, csak újracsomagolva eladják a világnak a hűdenagy ötletet.

"És ez mondjuk egy JVM esetén is igaz" az a magic benne, hogy ez nem csak jvm-el működik.

"Régóta része a Java EE-nek az ilyen dolog" az a magic benne, hogy ez nem csak Javaval működik.

"Ezek baromira nem új dolgok, csak újracsomagolva eladják a világnak a hűdenagy ötletet." Ebből látszik, hogy baromira nem érted mi az értelme ennek az egésznek.

Mondj egy megoldást, ami tudaj mindazt, amit a docker, és nem 4 különböző megoldást kell összedrótozni, plusz "platform függetlenül" működik, azaz egy Java-s vagy egy Go-s projekttel is ugyanúgy kell használni, ami lehetővé teszi a gép erőforrásainak managelését, amit lehet clusterezni, és terheltség alapján telepíteni az alkalmazásokat egyes node-okra, ami garantálja, hogy a fejlesztő a fejéesztői környezetében pontosan ugyanazt a környezetet használja, mint élesben, ami magában hordozza az alkalmazás konfigurációját, anélül, hogy a fejlesztőnek a saját gépén kéne bármit is módosítani (pl hogyan oldod meg, hogy az ubuntus CI szervered centos környezetben futtassa az alkalmazást és rajta a teszteket?), ami másodpercek alatt tudja mindenzt, ami atomi műveletként támogatja az alkalmazás teljes snapshotjának elkészítését, meg még száz dolgot mondhatnék, amire/amiért jó konténerbe zárni.

Megkérdezhetem nettó mennyi időt töltöttél a docker használatával, és kb mire használtad?

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - harmadik rész

És akkor még ott vannak az olyan apróságok, mint pl. a Docker Compose. Azért a Docker többről szól, mint egy konténer. Az itt inkább az LXC lenne.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

a fejlesztő gépén nem szükséges ugyanazt az oprendszert telepíteni

Windowson fog HP-UX alá fejleszteni? Vagy nem kell ugyanaz az oprendszer, ha mindkettő Linux? o.O

A többit HP-UX-on 10-15 éve meg lehetett oldani, de gondolom más, ésszel tervezetett operációs rendszernél is. Erőforrás management, cluster. Most komolyan, ezek döbbenetes feature-k? Legfeljebb annak, aki most tanulja a számítástechnikát.

Ave, Saabi.

"Windowson fog HP-UX alá fejleszteni? Vagy nem kell ugyanaz az oprendszer, ha mindkettő Linux? o.O" ezt hivjak kukacoskodasnak. Azert nem fejtettem ki mit ertek oprendszer alatt, mert aki egy kicsit foglalkozik dockerrel, az tudja, hogy jelenleg ez egy Linux kontenerizacios technologia, de jatszhatod nyugodtan a hulyet.

"Most komolyan, ezek döbbenetes feature-k?" nem a featurek a dobbenetesek, hanem, hogy ezt out of the box egymagaban tudja. De tudod, hogy van, ha nem tetszik nem kotelezo hasznalni.

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - harmadik rész

( zoner | 2015. 07. 22., sze – 11:45 )

Ezt csinaltam:

https://github.com/czettnersandor/vagrant-docker-lamp

Vagrantfile es dev folder megy minden uj projektbe es testreszabom, ha kell (pl apt csomagok, config file).

A fejlesztok szeretik, mert csak egy "vagrant up" a fejlesztoi kornyezet letrehozasa es gzorsabb, mint a Virtualbox-os Vagrant, mivel Docker megy alatta.