A résztvevő megérkezik a kurzusra vagy intenzív programra. Látja a technikai támogató csapat végtelen sorait, a gondosan elhelyezett áramellátó kábeleket, az előadóterem sakktáblaszerű elrendezését, a fényes képeket és diákat. A szónokok tréfákkal és mosollyal adják át az információt, hogy csak kapkodni lehessen a fejünket. Az állványok be vannak állítva, a gyakorlati feladatok könnyedén repkednek az ujjak között, hacsak néha szükség nem támad a technikai támogatás segítségére.
És emellett szünetek, ahol az érdeklődőkkel lehet találkozni, pezsgő és energikus légkör, tapasztalatcsere, a legváratlanabb kérdések a szónokokhoz. Itt az információ, amelyet nem találhatsz meg a használati utasításokban, csakis a gyakorlatban.
Hány időre, energiára és idegességre volt szükség ahhoz, hogy mindez így nézzen ki, szerinted?
Köszönet Vologya Guryanovnak, a Kubernetes tanúsított adminisztrátorának és mérnökének/csapatszintjének a Southbridge-nél, aki a kezdetektől tanúja és aktív résztvevője volt számos Slurm kurzus létrehozásának.
Látta a kurzusok létrehozásának hátterét – a nehézségeket és a tüskés akadályokat, a betekintéseket és a váratlan megoldásokat. És a már megszokott intenzív kurzusokat a Kubernetesről, mint a Slurm Alap és a Slurm Mega. Valamint az új, nagyrészt átdolgozott kurzust. , amely már elkerülhetetlenül közeledik és augusztus 19-én kezdődik.
De valószínűleg elég a lírából, térjünk át a történetre. Hogyan nőtt fokozatosan ki a pár téma az intenzív programból egy önálló és sokoldalú Tehát elkezdem mesélni, hogyan jönnek létre és fejlődnek a kurzusok – mintha "Réges-régen, egy messzi-messzi galaxisban...".
De mi rejlik a színfalak mögött?
Ha megkérdezed, hogyan készítjük a kurzusokat és mivel kezdődik minden, egyszerűen azt válaszolom: "Minden egy ötlettel kezdődik".
Általában az ötlet valahonnan érkezik – nem ülünk megkötözve a pincében, amíg nem találunk ki egy témát: "Milyen témában csináljunk kurzust?". Az ötletek maguktól jönnek, külső forrásokból. Néha az emberek aktívan érdeklődnek: "Tudtok valamit erről a konkrét technológiáról?". Vagy mint a Dockernél, ami nem fért bele az intenzív program idejébe – azt nyilvánvalóan kint kellett kezelni, hogy a program keretein belül valamit tudjunk mondani.
Így születik meg az ötlet.
Miután megjelent, megkezdődik, véleményem szerint, a legnehezebb pillanat – igazából megérteni, hogy mi mindent kellene tartalmaznia ennek a kurzusnak – nagyon hasonló ahhoz, ahogyan a szónokokat készítik a különféle konferenciákra.
Van egy fő fájdalom, amikor már választottál egy témát, és gondolkozol: „Miről meséljek róla? Ez túl egyszerű, ez nyilvánvaló, ezt mindenki tudja.”
De valójában ez egyáltalán nem így van. Személyesen sok helyen mondom, hogy ami számodra nyilvánvalónak tűnik, az azoknak, akik meghallgatnak téged vagy végigcsinálják a kurzust, egyáltalán nem nyilvánvaló. Itt jön létre egy nagy terület a munkára és a belső konfliktusra, hogy mit is kellene beletenni a kurzusba. Ennek eredményeként születik egy listája a fejezeteknek, amelyeket nagy vonalakban felvázoltunk, hogy miről szól a kurzus.
Aztán elkezdődik a szokásos rutinfeladat:
- Anyaggyűjtés
- A legcurrentabb verzió dokumentációjának alapos átnézése, mivel az IT-világ jelenleg űrhajós sebességgel fejlődik. Még ha valamivel is dolgozol és kurzust készítesz róla, akkor is a dokumentációba kell menned, és meg kell nézned, mi a legújabb, miről érdemes beszélni, mi lehet különösen hasznos megemlíteni.
- És egyfajta ív alakul ki a kurzus körül, ahol már egy nagy része a témáknak ki van dolgozva, és úgy tűnik, hogy csak annyit kell tenni, hogy rögzítsd a videókat, és elindítsd a produkciót.
- De valójában nem, itt kezdődik a nehéz munka, de már nem a kurzus szerzői számára, hanem azok számára, akik tesztelnek. Általában az alfa-tesztelőink a műszaki támogatás munkatársai, akik egyrészt átnézik a kurzusokat különféle szintaktikai és grammatikai hibák miatt. Másrészt pedig keményen kritizálnak minket, amikor vannak olyan teljesen nem nyilvánvaló, érthetetlen helyek. Amikor a szövegekben bonyolult, alárendelt mondatok jelentkeznek több oldalon keresztül, vagy nyilvánvaló blődség. Ők mindezt átnézik, kiszúrják.
- Aztán következik a gyakorlati tesztelés szakasza, ahol szintén észlelnek egyes nyilvánvalóan működésképtelen dolgokat, és rámutatnak azokra a pontokra, amelyeket esetleg éppen ellenkezőleg meg kellene nehezíteni, mivel unalmas lenne csak ülni és másolni — és kimutatják azokat a helyeket, ahol igen sokat várunk azoktól, akik részt fognak venni ebben a kurzusban. Ekkor jönnek a javaslatok: „Csináljatok, srácok, itt könnyebben, így jobban feldolgozható lesz, és ebből több haszon származik.”
- Miután elvégeztük ezt a munkát, megírtuk a videóhoz kapcsolódó részt, úgy tűnik, minden rendben van. Már elérhetővé lehetne tenni ezt a kurzust a hirdetések számára. De megint csak úgy tűnik, hogy korai – mivel az utóbbi időben elkezdtük kevésbé megbízni magunkban, és általában több visszajelzéssel dolgoztunk. Megjelent egy új dolog, a bétatesztelés – amikor külső embereket hívunk meg, akik nincsenek kapcsolatban a cégünkkel, és valamilyen előnyökért bemutatjuk nekik a kurzus minden részét, videókat, szöveget, gyakorlati feladatokat, hogy értékeljék a tartalom minőségét, elérhetőségét, és segítsenek nekünk abban, hogy a kurzus a lehető legjobban készüljön el.
- És amikor több ilyen iteráción vagyunk túl, előadók, alpha-tesztelés a technikai támogatás keretein belül, bétatesztelés, fejlesztések. Aztán minden kezdődik elölről — műszaki támogatás, bétatesztelés, módosítások.
- És egy bizonyos pillanatban felmerül a megértés, hogy vagy felhagynunk a fejlesztésekkel, mert lehetetlen úgy megoldani, hogy mindenkinek tetszen, vagy valamilyen radikális döntéseket kell hozni. Amikor nagyon sok megjegyzés bizonyos helyekről kritikus — globálisan át kell dolgozni őket, mert valami nem működik.
- Ezután elérkezik az apró javítások ideje — ahol egy mondat nem túl szépen van megfogalmazva, vagy valakinek a betűtípus nem tetszik, 14,5, de jobban szeretné a 15,7-et.
- Amikor ilyen típusú megjegyzések maradnak, akkor minden, a kurzus többé-kevésbé megnyílik, megkezdődnek a hivatalos értékesítések.
Első pillantásra a kurzuszás egyszerű feladatnak tűnik, de valójában korántsem az, és hihetetlenül sok időt vesz igénybe.
És van még egy fontos szempont, hogy a kurzussal való munka nem ér véget, amikor a kurzust kiadják. Először is figyelmesen olvassuk a hozzászólásokat, amelyeket a különböző részekhez fűznek. És még az összes erőfeszítés ellenére, amit tettünk, még mindig előkerülnek bizonyos hibák, bizonyos problémák, amelyeket menet közben, valós időben javítunk, fejlesztünk, hogy minden következő felhasználó jobb minőségű szolgáltatást kapjon.
Minden kurzusnak van saját terméktulajdonosa, aki nemcsak a fő koncepciót határozza meg, hanem ellenőrzi a határidőket is, és a margókon jegyzeteket készít arról, hogy amikor eljön az idő a kurzus teljes átdolgozására – ami biztosan el fog jönni, hiszen két év múlva, vagy akár egy év múlva, az, amit tanítunk, elavulttá válik, mert morálisan elöregszik. A terméktulajdonos jegyzeteivel figyelemmel kíséri, hogy az emberek leggyakrabban mely kérdéseket teszik fel, mely pontok tűntek homályosnak, mely feladatok tűntek nagyon nehéznek, míg mások éppen ellenkezőleg, nagyon könnyűnek. Mindez figyelembevételre kerül a kurzus újraírásakor, valamilyen refaktorálás keretében, hogy minden globális iteráció egyre jobb, kényelmesebb és kellemesebb legyen.
Így születnek a kurzusok.
Hogyan született meg a Docker kurzus
Ez egy különálló, sőt, számunkra szokatlan téma. Mert egyrészt nem terveztük megcsinálni, mert sok online iskola kínálja. Másrészt pedig a téma magától kérte, hogy megvalósítsák, és logikus helyet talált a Kubernetes IT-szakemberek képzésének koncepciójában.
Ha általánosságban beszélünk, akkor minden azzal kezdődött, hogy létrehoztuk a Kubernetes kurzust, amikor azt először elindították, azt hiszem, az első Slőrmt követően. Visszajelzést gyűjtöttünk, és láttuk, hogy nagyon sokan szeretnének még valahol olvasni a dockerről, és sokan érkeznek alapképzésre Kuberneteshez anélkül, hogy tudnák mi az. .
Ezért a második Slörmnél létrehoztunk egy kurzust — inkább nem is kurzust, hanem készítettünk pár fejezetet a dockerről. A legalapvetőbb dolgokat mondtuk el, hogy azok, akik az intenzív képzésre jönnek, ne érezzék magukat elhanyagoltnak, és egyáltalán értsék, hogy mi történik.
Aztán az események körülbelül így alakultak. Az anyag mennyisége nőtt, és már nem fért bele a 3 napba. És megszületett egy logikus és nyilvánvaló ötlet: miért ne csinálnánk abból, amit a Slörm Alapkurzuson tanítunk, egy kis kurzust, ahová el lehetne küldeni azokat, akik az intenzív Kubernetes képzés előtt szeretnének valamit látni a Dockerről.
A Slörm Junior lényegében több ilyen alapkurzus egyesítése. Végül a docker kurzus a Slörm Junior egy részévé vált. Vagyis ez egy olyan nulladik fokozat a előtt. és . Aztán ott voltak egészen alapvető absztrakciók.
Egy idő után az emberek elkezdtek kérdezni: „Hé, ez nagyszerű, elegendő ahhoz, hogy megértsük, miről beszéltek az intenzív kurzusokon. De hol olvashatunk bővebben arról, hogy mit tud a Docker, hogyan kell vele dolgozni és hogy egyáltalán mit is képvisel?”. Így született meg az ötlet, hogy egy teljes , hogy egyrészt azokat az embereket is tudjuk küldeni, akik a Kubernetesre érkeznek hozott érdeklődőként, másrészt azoknak, akiket egyelőre nem érdekel a Kubernetes. Hogy az IT szakemberek eljöjjenek, megnézzék a Docker kurzusunkat, és elkezdjék az evolúciós útjukat egyszerűen a tiszta Dockerrel. Hogy legyen egy ilyen teljes, befejezett kurzusunk — és sokan, miután megnézték ezt a kurzust és egy ideig dolgoztak a tiszta Dockerrel, eljutottak arra a szintre, ahol már szükségük van a Kubernetesre vagy valamilyen más orchesztrációs rendszerre. És kifejezetten hozzánk jöttek.
Néha felmerül a kérdés: "De kinek nem szükséges most a Kubernetes?" De ez a kérdés nem az emberekről szól, hanem inkább a cégekről. Itt meg kell érteni, hogy a Kubernetesnek vannak bizonyos esetek, ahol jól alkalmazható, és olyan feladatok, amelyeket jól megold, de vannak éppen ellenkezőleg olyan forgatókönyvek, amikor a Kubernetes több problémát okozhat, mint amennyi előnyöket nyújt. Szóval itt inkább nem is az emberektől függ, hanem attól, hogy a cégek mit és hogyan fejlesztenek.
Például, ha van egy régi, szörnyű monolitikus örökség — talán nem érdemes beletuszkolni a Kubernetesbe, mert több problémát fog okozni, mint amennyi előnyt ad. Vagy ha ez egy kis projekt — kicsi terhelésekkel vagy alapvetően nem sok pénzzel és erőforrással. Akkor annak a Kubernetesbe való áthozatala semmi értelmet nem hordoz.
És egyáltalán, talán, ahogy már sokan mondták, ha azon gondolkodik: „Szükségem van a Kubernetesre?”, akkor valószínűleg nincs szüksége rá. Nem tudom, ki találta ezt ki először, szerintem Pasha Selivanov. Ezzel 100%-ig egyetértek. A Kuberneteshez fel kell nőni — és amikor már megjelenik a megértés, hogy nekem tényleg szükségem van a Kubernetesre, és a cégemnek is szüksége van rá, akkor segíthet bizonyos kérdések megoldásában, akkor talán érdemes elmenni tanulni és kideríteni, hogyan lehet jól beállítva használni, hogy a Kubernetesre való átállás ne legyen túl fájdalmas.
Vannak olyan gyerekbetegségek és viszonylag egyszerű, sőt nem is annyira egyszerű dolgok, amelyeket különösen nálunk megtudhat, anélkül, hogy a saját csapdáikon és fájdalmukon kellene átmenniük.
Sok vállalat úgy kezdte, hogy először volt egyfajta infrastruktúra konténerizálás nélkül. Aztán amikor nehézkessé vált a kezelés, áttértek a Docker használatára, és egy idő után eljutottak arra a pontra, hogy a Docker által nyújtott lehetőségek már nem elégségesek. Elkezdtek körülnézni, hogy milyen rendszerek oldják meg ezeket a problémákat, és különösen a Kubernetes egyike azoknak a rendszereknek, amelyek megoldást nyújtanak, amikor a tiszta Dockerben már szűkös a hely és hiányzik a funkcionalitás. Ez egy jó példa arra, amikor az emberek fokozatosan, alulról felfelé haladnak, látják, hogy ennek a technológiának már nem elég és áttérnek a következő szintre. Kipróbálnak valamit, aztán az újra kevésnek bizonyul — és tovább lépnek.
Ez egy tudatos választás — és ez nagyon klassz.
Én úgy látom, hogy nálunk nagyon szép rendszer épül fel például, , sőt videóképzések is. A Docker után következik a , aztán , aztán . Minden logikusan felépül — az ember végigmegy rajta, és így egy teljes szakmát kap.
Alapvetően a kurzusok együttese sok modern esetre megoldást nyújt. Még vannak olyan területek, amelyek szürke foltként maradtak, remélem, hogy hamarosan létrehozunk olyan kurzusokat, amelyek lefedik ezeket a szürke területeket, különösen a biztonságról fogunk kitalálni valamit. Mert ez nagyon aktuálissá válik.
Röviden, van néhány szürke terület, amelyet nagyon jól lenne lefedni, hogy egy igazán teljes képet kapjunk — és az emberek be tudjanak jönni, és a Kubernetes úgy működik, mint egy Lego-készlet, amiből különböző dolgokat lehet összerakni; ha még mindig hiányzik valami — azt kiegészíteni, épp így van a kurzusainkkal is, hogy az emberek megértsék, mire van szükségük ebből, hogy egyfajta kirakós, egyfajta építőkészlet álljon össze a kurzusainkból.
Ha felteszem magamnak a helyes és őszinte kérdést: "Kinek lesz hasznos egy aktív Docker kurzus mostanában?", akkor:
- Olyan diákoknak, akik most kezdik el megérteni.
- A tesztelő részleg munkatársainak.
- Valójában sok olyan cég létezik, ahol még mindig nemcsak a docker alkalmazásokat nem használják, hanem a technológiáról sem hallottak, és egyáltalán nem tudják, hogyan kell azt használni. Tudok olyan nagy cégekről is Péterváron, amelyek már éveken át foglalkoznak fejlesztéssel, és a régi technológiákat használják, amit továbbra is követnek. Különösen ezeknek a cégeknek az mérnökei számára ez a kurzus nagyon érdekes lehet, mivel egyrészt lehetővé teszi számukra, hogy gyorsan belemerüljenek ebbe a technológiába, másrészt, amint néhány mérnök megérti, hogyan működik, be tudják hozni azt a cégbe, és ott belül fejleszteni tudják ezt a kultúrát és irányvonalat.
- Szerintem ez a kurzus hasznos lehet azok számára is, akik már dolgoztak dockerrel, de csak egy kicsit, inkább úgy, hogy „csináld ezt, csináld azt”, és most valamilyen módon kapcsolódni kívánnak a Kuberneteshez, aminek bizonyos kötelezettségei vannak, ha nagyon felületes ismereteik vannak arról, hogy mi az a docker, hogyan kell elindítani, de nem tudják, hogyan működik belülről, és hogy mit érdemes vele csinálni, és mit érdemes elkerülni, akkor ez a kurzus jól megfelel a tudás rendszerezésének és elmélyítésének.
De ha az ön ismeretei a következő szinten vannak: „Nem tudom, hogyan kell helyesen megírni a docker fájlokat, van egy elképzelésem arról, mik azok a namespaces, hogyan működnek a konténerek, hogyan valósulnak meg ténylegesen az operációs rendszer szintjén” - akkor nincs értelme eljönni hozzánk, újat nem fog tudni megismerni, és kicsit szomorú lesz a költött pénz és idő miatt.
Ha meg kellene fogalmazni, hogy milyen előnyei vannak a kurzusunknak, akkor:
- Ezt a kurzust olyan gyakorlati esetekkel próbáltuk meg létrehozni, amelyek lehetővé teszik, hogy necsak a meglévő elméleti részt értsék meg, hanem azt is, hogy mire van szükségük, és hogyan fogják ezt a jövőben használni;
- Néhány olyan szakasz található itt, amely nagyon ritkán fordul elő máshol, és egyáltalán nem sok anyag érhető el róluk. Ezek a Docker és az operációs rendszer közötti interakcióval kapcsolatosak, kissé más nézőpontból. Milyen mechanizmusokat vett át a Docker az operációs rendszertől a konténerizálási rendszer megvalósításához - és ez mélyebb megértést ad az operációs rendszer keretein belüli konténerek indításának kérdéséről. Hogyan működik ez, hogyan lép kapcsolatba a rendszeren belül és kívül stb.
Ez egy mélyreható nézőpont, amely viszonylag ritka, és szerintem nagyon fontos. Ha jól szeretne megérteni bármely technológiát, és tudni, mit várhat tőle, legalább nagy vonalakban tisztában kell lennie azzal, hogyan működik alacsony szinten.
Tanfolyamunk bemutatja és elmagyarázza, hogyan működik ez az operációs rendszer szempontjából. Egyrészt minden konténerizálási rendszer ugyanazokat a mechanizmusokat használja, mint az operációs rendszer. Másrészt, ami Linux operációs rendszerben van, azt a Docker is felhasználja. Más konténerizáló rendszerek nem találtak ki semmi újat - csak átvették azt, ami már létezik a Linuxban, és írtak egy kényelmes burkot, amely lehetővé teszi a gyors hívást, indítást vagy a rendszerrel való interakciót. Maga a Docker nem egy nagy réteg az operációs rendszer és a parancssor között, hanem egy olyan eszköz, amely lehetővé teszi, hogy ne írjon meg rengeteg parancsot vagy C-kódot a konténer létrehozásához, hanem mindezt néhány sor terminálba írásával végezze el.
Ráadásul, ha kifejezetten a Dockerről beszélünk, akkor ami valóban hozzájárult az IT világához, az a szabványok. Hogyan kell egy alkalmazást indítani, hogyan kell működnie, mik a logok követelményei, mik a méretezési, a konfigurálási követelmények az alkalmazásra vonatkozóan.
A Docker sok szempontból a szabványokról szól.
A szabványok a Kubernetesbe is átköltöznek - és ugyanezek a szabványok vannak ott is, ha jól tudja indítani az alkalmazását Dockerben, akkor 99%-ban ugyanolyan jól fog működni a Kubernetes keretein belül is.
Ha érdekli nemcsak az, hogyan készült a Docker tanfolyam, és más tanfolyamok is, hanem a tanfolyam gyakorlati szempontja is, akkor
Örömmel látunk téged!
Forrás: habr.com
