CoreOS tapasztalatok

Linux-haladó

Használ valaki CoreOS-t szervernek? Milyenek a tapasztalatok? Miben jobb mint egy hagyományos Linux disztribúció?

  • 2833 megtekintés

( o_O v | 2015. 11. 06., p – 00:45 )

Ha Dockert hasznalsz van ertelme ha nem akkor nincs. De gyere el vday-re lesz ezzel kapcsolatban eloadas.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

( Mandrake | 2015. 11. 06., p – 18:51 )

"Miben jobb mint egy hagyományos Linux disztribúció?"
Mire tetszik gondolni kis kegyed?
Aki lusta annak Centos7 javallott, aki nem lusta annak Debian.

( sj | 2015. 11. 06., p – 20:58 )

ahogy fentebb irtak, ez egy a docker okoszisztemahoz kifejleszett disztribucio, a szokasos os-ekkel erkezo sallangok nelkul, azaz vekony, csak a docker futtatasahoz elengedhetetlen cuccok vannak benne.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Google fogta a ChromeOS-t kivette a desktoppal és böngészéssel kapcsolatos elemeit és szerver OS-t csinált belőle. Csomagkezelés nem része a rendszernek így kézenfekvő megoldásként jött a Docker és a Google saját megoldása, a Rocket.
Személyes tapasztalatokra lennék kíváncsi. Kényelmesebb például CoreOS-sel megoldani szokásos szerverfeladatokat?
Webserver, cms, samba, asterisk, SQL.
Biztonsági frissítésekkel hogyan áll egy ilyen Dockert használó rendszer. Mennyire vannak karbantartott Rocket csomagok?

a szokasos szerverfeladatokat nem a coreos-sel oldod meg, hanem a futtatott kontenerekkel. A Rocket-rol nem tudok nyilatkozni, nem ismerem, de a coreos-hez rendszeresen jonnek ki az update-ek. Maga a host ssh-n kulccsal erheto el, konzolrol pl. nem (bar a grub menut megberhelheted, hogy beengedjen, amig par dolgot beallitasz install utan)

A kontenerekben futo cuccok frissitesei pedig rajtad allnak. Jellemzoen eldobod az x alkalmazas konteneret, majd deploy-olod belole a friss verziot, es kesz. Mivel az emlitett peldaidban perzisztens adatok is vannak, azokat a konteneren kivul lehet tarolni. Ill. nehany a kontenernek szukseges valtozo, konfig(?) a coreos etcd-jeben (elosztott key-value tarolo) is tarthato.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Ez azert eros tulzas tartalmaz ChromeOS-bol dolgokat de igazabol Gentoo-ra. ( https://coreos.com/os/docs/latest/sdk-tips-and-tricks.html )

Az okoszisztema nem arra van kitalalva ,hogy samba-t meg hasonlo dolgokat uzmeltes benne lehet csak nem erdemes.

CoreOS kepes leallas nelkul firssiteni onmagat amennyiben a kovetkezo releasben ki jon egy javitas telepitesre kerul ( https://coreos.com/os/docs/latest/update-strategies.html )

Docker amennyiben ujra buildeled a docker imaget es tartalmazza a megfelelo parancsokat ( pl. apt-get update , apt-get upgrade ) ez esetben tartalmazni fogja biztonsagi frissiteseket is.

Amennyiben ezeket szeretned webserver,cms,samba,astersik,SQL-t szeretnel uzemeltetni Docker-be nem ajanlom. Docker nem arra talaltak ki sokan probaljak erre a celra hasznalni de nem erdemes.

A CoreOS egy nagyon jo alap ha pl van egy microservices architekturad mert van service discovery es egyeb dolgok.

De ha tapasztalat erdekel nekem van production kornyezetben CoreOS clusterem AWS-n fut.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Mire optimális a Docker szerinted CoreOS-sel? Te mire használod?
Hagyományos, előbb felsorolt szerverfeladatoknál, eddig olyan előnyökről olvastam, hogy kényelmesen és biztonságosan lehet különböző ügyfelek például CMS portálműködtetési igényét kielégíteni, virtualizációnál kisebb overheaddel. De a biztonsági frissítések naprakészsége és általában a karbantartás a Docker csomag karbantartójából függ, ami szerintem jelenleg eléggé zavaros. Leginkább a 2000-es évek shareware világára emlékeztet.

Pálya-szélről bekiabálás, régebben nézegettem a Docker-t, nekem nagyon nem volt bejövős, nem üzemeltetek olyat, ahol ki tudnám használni és nem csak plusz réteg szívás lenne.

Ahogy fentebb is írta o_O, ha az alkalmazásodat alapból úgy készítetted, hogy microservice-kkel van teli (kis, pontosan egy dolgot csináló, jó esetben dinamikus skálázható [pl. amikor az auth microservice-det sokan használják, mert egyszerre sokan jelentkeznek ki/be, indítasz belőle még néhány példányt] szolgáltatások) és fel van készítve a konténerben futásra (pl. lehetőleg nem tartassz perzisztens adatot), akkor jó lehet.

Nézz rá erre a szálra és az ott linkelt leírásra: http://hup.hu/node/143755?comments_per_page=9999 (az írásban sokat anyáznak a NAT miatt, na pl. amiatt bár shell scriptes taknyolással és a DNS abuzálásával megoldható, hogy egy Samba-t elfuttass benne, messze nem jó rá...).

Az ügyfelek CMS/portálműködtetési/Samba/levelezés/... igény inkább egy OS-szintű konténerizáció lenne jó (OpenVZ, LXC stb.), ott gyakorlatilag minden ügyfélhez tudsz rendelni egy virtuális OS-t (ami teljes értékű OS lesz, mindennel együtt, csak a kernel közös), ott nem annyira élesen van meg az erőforrás-szeparáció, ezért kisebb az overhead. (az adminisztratív overhead meg egyszerűen ott jöhet vissza, hogy a host-ról bármelyik guest-ben tudsz bármit futtatni, tehát ha pl. tényleges web hosting szolgáltatást adsz az ÜF-nek és nem VPS-t, akkor simán az összes konténerben végigfuttatos az [apt-get/yum/zypper/pacman/...] update-t, ha kijön egy biztonsági frissítés)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ha nincs ra igeny, akkor nem kell eroltetni a docker hasznalatat, de szerintem ajanlott megismerni. Ettol nem lesz meno egy szolgaltatas sem.

A konteneres vilag egy nagyon mas szemlelet modot kovetel meg, ha az ember probalja jol hasznalni.
Pl.:
"...akkor simán az összes konténerben végigfuttatos az [apt-get/yum/zypper/pacman/...] update-t, ha kijön egy biztonsági frissítés"
Nem. A kontenert eldobod, mikor keszen all az uj image. Van par szaz kontenered es mindenhol updatelnel?
Docker youtube csatornajan azt hiszem van video, ahol demonstralnak egy microservice verziovaltast.

Docker is lxc-t hasznal.

Ezekkel tisztában voltam, csak őszintén szólva jogosnak érzem azt a kritikát, amit a linkelt topicban linkelt írásban fogalmaznak meg. (a frissítés: azt a fél mondatot kihagytam belőle, hogy "és nem kell várnod, hogy az image készítője frissítsen")

Pont a Samba volt az, ahol feladtam az egészet. A Samba DC kb. ideális jelölt lenne ilyen dinamikusan skálázott konténerbeli futtatásra (nincs ill. egész minimális példány specifikus perzisztens adat, minden más a replikált címtárból jön). De a Docker alkalmatlan rá, mert erőltetik a NAT-ot. És igen, van egy undorító script, ami azzal kezd, hogy indításkor a külső címmel frissítetti a DNS-t, hogy legalább a DC se tudja önmagáról, hogy kicsoda.

Értem, hogy van létjogosultsága (belsős elosztott rendszer függőségekre darabolt elosztása? nem tudom), de az az érzésem, hogy túl nagy mögötte a hype, és sokan csak azért kezdik használni, hogy legyen, pedig a legtöbb esetben több problémát szül, mint amit megold.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A Docker erdemes kiegesziteni, ha a NAT-olas es port mapping gondot jelent: Weave (+Swarm es Compose, hogy a skalazodas kenyelmes legyen) vagy akar Kubernetes. A Docker akkor egyszerusit, ha a szemleletmod is igazodik. Van letjogosultsaga, de nem szabad a regi jol megszokott dolgokat eroltetni, mert nem arra valo.

A szemléletmód igazításra...

Tudom, hogy ez egy sima promó anyag, messze eltúlozva, de azért lássuk be, az IT-re eléggé jellemző ez a fajta felesleges, a tényleges igényekkel nem foglalkozó overengineering és utána a hype, ami miatt jön a sima CRUD app 12 microservice-re vágása.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> ami miatt jön a sima CRUD app 12 microservice-re vágása.

Ezt en nem ertem miert problema. Tenyleg nem.

Ez tok poenosan osszefoglalja:
"""
So I just need to split my simple CRUD app into 12 microservices, each with their own APIs which call each others’ APIs but handle failure resiliently, put them into Docker containers, launch a fleet of 8 machines which are Docker hosts running CoreOS, “orchestrate” them using a small Kubernetes cluster running etcd, figure out the “open questions” of networking and storage, and then I continuously deliver multiple redundant copies of each microservice to my fleet. Is that it?
"""

En a fenti osszeallitast teljesen vallalhatonak gondolom:)

Remelem megvan, hogy a szatirajukra ok maguk irtak am egy valaszt is:
http://blog.circleci.com/it-really-is-the-future/

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ezt en nem ertem miert problema. Tenyleg nem.

Olyan szintű premature optimization, ami ugyan nagy terhelésnél visszajön, de az alatt csak 1) plusz fejlesztői erőforrásokat köt le, 2) plusz IT erőforrásokat használ és - új projektnél - 3) növeli a time-to-marketet. A cikkben írt példánál maradva (authentication/authorization): a különbség aközött, hogy processen belül hívsz egy függvényt vagy hogy akár másik gépen futó mikroszolgáltatást, több nagyságrend. A plusz fejlesztői erőforrás ill. ttm meg egyértelmű (még ha nem is feltétlenül sok, ha megfelelően sok absztrakciós réteget használsz), persze ebből visszajön valamennyi, ha több projekt között meg tudod osztani a megírt microserviceeket.

And we need to do it not because it’s shiny, or because it’s some mythical best practices, but because people like Amazon and Netflix and Google have put 15 years of sweat and blood and industry experience into working this shit out and telling us how to build systems at real scale.

Az Amazon, a Netflix és a Google pár száz nagyságrenddel több userrel rendelkezik, mint egy _átlagos_ szolgáltatás, és nem feltétlenül éri meg minden úgy csinálni, ahogy ők. A Pistike Bt. Webshopja alkalmazás pl. valszeg önmagában csődöt kellene, hogy jelentsen [az elmaradt, késedelmes, ... rendelések miatt], ha kapna hirtelen egy olyan terhelést, ami miatt megérte nekik lényegesen nagyobb eszközparkkal, több mérnökórában előállított elosztott rendszeren futó alkalmazást megépíteni.

És akkor a probléma: mindenki fel fog ülni a hype trainre. Mindenki microservicekkel fog szórakozni. Ami pl. egy wordpress.com-nál teljesen belefér, van akkora terhelésük. De onnantól kezdve, hogy a sima wordpress nem egy csomag lesz, hanem 12 microservice, Jóskának, aki heti 1 posztban a saját blogján felír magának meg a másik öt olvasójának valami emlékeztetőt, szintén egy teljes clustert kell üzemeltetnie, de legalábbis 12 mikroszolgáltatást. Nála is lesz értelme? Jóska esetében egy valós igényt szolgáltat ki, amikor szemléletet és architektúrát váltottak?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

evrol evre gyorsabb a hardvert. Megis mire lojuk el a felesleges eroforrast?:)

Egyebkent amikor "mikroservice-t" irsz, akkor eljuthatsz odaig, hogy keszrejelentesz egy programot. Tenyleg.
Van egy kepatmeretezo kontenerem. Egyszeru rest api-ja van.
Keszen van, teszi a dolgat. Biztonsagi restol nem kell tartani (persze mindig kell), mert van kb. 5 parancs kiexportalva, masra nem reagal a szerver. Ez igy 10 evig elketyegne.

Korabban sose volt egyik programom se keszen. Nekem ez a konteneresdi egy megvaltas.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szerintem ez eleg szubjektiv. En speciel orulok a Dockernek, intenziven hasznalom es fogom is hasznalni a jovoben, mert vannak olyan igenyeim, amiket ki tudok vele elegiteni, lenyegesen jobban, mint a korabbi eszkozeimmel. De ez tenyleg teljesen szubjektiv, ugyhogy nem is akarok belole flame wart csinalni. Amit irtam azt a NAT-olasi gondot miatt tettem, mert nem tudtam, hogy mennyire vagy kepben a Docker okoszisztemaval es abszolut aterzem ezt a problemat.

Igazabol nat elkerulhetetlen a rendszerben ha hasznalod akkor megerted. Amugy sincs szukseg fix ip-re egy ilyen kornyezetben ha CoreOS-t hasznalsz van etcd de hasznalhatsz consuel is mindegy. Amikor elinditod a geped akkor beregisztralod a konert. A DNS problemara pedig hasznal https://github.com/skynetservices/skydns-t. Szerintem megtudod csinalni vele amikor akarsz. A geped kulso ipjere pedig raksz egy TCP proxy-t ami kepes ETCD vagy Consult backendenk hasznalni. ( https://github.com/totem/yoda-proxy ). Ez problema valszeg nem megoldhatlan csak kerdes szukseged van erre az egeszre.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

> Te mire használod?

Ugyan nem en lettem megszolitva, de azert leirom.

Ami programot irok, azt mind docker kontenerbe teszem.
Van build szkriptem, ami docker konterbe forditja le a programomat.
Regi programjaimat is portolom dockerbe.

Egy docker kontener szigoruan egy program. A programok egymas kozott websocket-tel (ha kell progressbar), vagy poll-ozassal kommunikalnak.

A regi programjaim ele (pl. csinaltam batch resize python programot) csinalok egy node.js webszervert, ami kommunikal a tobbi kontenerrel, es *inditja*
var demonka = require('child_process').spawn(

sorral a tenyleges programot.
Van par ilyen programom mar: kep atmeretezese, pdf generalasa, kep beforgatasa 3D-ben, zip-be tomorites, zipbol kitomorites, stb, stb.

Barhova tehetek egy ilyen "worker"-t, ahol van docker. Lenyegeben megkotes nelkul. Automatan megtalalja a fonokot, es kommunikal vele.
Tervbe van veve nehany programom raspberry pi-ra portolasa.

Osszefoglalva: egy program (vagy egy feladat) per kontener.
Ez amolyan alapelv nalam.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A cegunk microservices architektura epitette fel az alkalmazasat jelenleg kozel 20 db szervizunk van ami hetente no kb. 2 db uj szervizzel. Nalunk minden szerviz egy feladatot vegez es latt el HTTP-n vagy Message queue-n keresztul kommunikalnak. Ennek az egesznek a lenyege ha bar melyik komponest skalazni kell akkor nem szukseges a teljes rendszert csak az adott szervizt skalazni( pl ha feltorlodnak az emailek akkor csak message servicet kell skalazni). Gondolj erre mint egy legora csak az egyik elemebol kell tobb akkor nem kell egy uj varat epitened. A rendszer masik lenyege ,hogy van service discovery ( etcd ) es van hozza egy fleet nevu eszkoz ami manageli a szervizeket. Igy igazabol bar mekkora rendszert feltudunk huzni anelkul ,hogy ez problemat okozzon. Mivel fontos nalunk az automatizacio ertsd nincs szukseg devops,sysadminra ahhoz ,hogy deployolni lehessen mivel a Content Delivery teljesen ki van epitve. Irtunk egy sajat deployert a CoreOS szolgaltatasait hasznalva ami kepes leallas nelkul deployolni ( Zero downtime deploy ). Persze hasznalunk meg jo par tool-t bar blog bejegyzest megtudnek tolteni a temaval :).

De ahhoz ,hogy ez az egesz letre jojon a kovetkezok kellenek:
1. Olyan fejlesztok akik ertik es tudjak mi az a microservices
2. Tudnak teszteket irni es akarnak is.
3. Mindenki reszerol orasi szemelet valtas kell mert itt egy csomo dolog nem ugy mukodik.

A temaban amugy en fogok eloadni majd a prezit ide is be posztolom.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer