Egy résztvevő tanfolyamra vagy intenzív tanfolyamra érkezik. Látja a technikai támogatás rendezett sorait, szépen elvezetett tápkábeleket, az előadóterem sakktáblás elrendezését, fényes képeket és diadiagramokat. A tréfás és mosolygós beszélők úgy adnak ki információkat, hogy csak legyen ideje megérteni. Az állványok fel vannak állítva, a gyakorlati feladatok egyszerűen elrepülnek az ujjakról, kivéve, hogy néha szükség van a technikai személyzet segítségére. támogatás.
Illetve kávészünetek hasonló gondolkodású emberekkel, vidám és lendületes légkör, tapasztalatcsere, a legváratlanabb kérdések az előadókhoz. Mind a válaszokat, mind az információkat, amelyeket nem talál meg a kézikönyvekben, de csak a gyakorlatban.
Mit gondol, mennyi időbe, erőfeszítésbe és idegbajba került, hogy pontosan így nézzen ki?
Köszönet Volodya Guryanovnak, a Southbridge okleveles Kubernetes rendszergazdájának és mérnökének/csapatvezetőjének, aki a kezdetektől szemtanúja volt és aktívan részt vett számos Slurm tanfolyam létrehozásában.
Látta az alkotás hátterét – bonyolultságokat és tüskés gereblyéket, meglátásokat és váratlan megoldásokat. És a már megszokott Kubernetes intenzívek, mint a Slurm Basic és a Slurm Mega. És egy új, nagyrészt átdolgozott tanfolyam , ami menthetetlenül közeleg és augusztus 19-én kezdődik.
De talán elég a szövegből, térjünk rá magára a történetre. Hogy pár intenzív témából egy teljesen önellátó és sokrétű . Tehát elkezdem a kurzusok létrehozásának és fejlesztésének történetét – akárcsak „Régen régen egy messzi-messzi galaxisban...”
Mi van a színfalak mögött?
Ha azt kérdezi, hogyan készítünk tanfolyamokat, és hol kezdődik az egész, egyszerűen azt válaszolom: „Minden egy ötlettel kezdődik”.
Általában valahonnan jön az ötlet – addig nem ülünk megbilincselve a pincében, amíg ki nem jön: „Milyen témáról készítsünk tanfolyamot?” Az ötletek valahonnan maguktól származnak külső forrásból. Néha az emberek aktívan kérdezik: „Mit tud az ilyen és ehhez hasonló technológiáról?” Vagy hogy volt Dockerrel, hogy nem lehetett beilleszteni az intenzív tanfolyam időzítésébe – nyilván ki kellett vinni, hogy legyen ideje elmondani valamit az intenzív tanfolyamon.
Így jelenik meg egy ötlet.
Véleményem szerint a bejelentés után kezdődik a legnehezebb pillanat - hogy általában megértsük, mit is kell belefoglalni ebbe a kurzusba -, ez nagyon hasonlít ahhoz, ahogyan az előadók felkészülnek bármilyen konferenciára.
Van egy fő fájdalom, amikor úgy tűnik, hogy kiválasztott egy témát, és azt gondolja: „Mit mondjak róla? Ez túl egyszerű, ez nyilvánvaló, ezt is mindenki tudja."
De a valóságban ez egyáltalán nem így van. És én személy szerint sok helyen mondom, hogy ami magától értetődőnek tűnik számodra, azoknak, akik eljönnek hallgatni vagy tanfolyamra járni, az egyáltalán nem nyilvánvaló. És itt akkora munkaréteg és belső konfliktus keletkezik, hogy mi kerüljön be a tanfolyamba. Ebből kifolyólag olyan elsöprő nagy vonásokkal olyan fejezetlistát kapunk, hogy miről is fog szólni a tanfolyam.
És akkor kezdődik az egyszerű rutinmunka:
- Anyagválasztás
- Olvassa el figyelmesen az aktuális verzió dokumentációját, mert az IT világ most valamiféle kozmikus sebességgel fejlődik. Még ha dolgozol is valamivel, és készítesz róla tanfolyamot, akkor is rá kell menned a dokumentációra, és meg kell nézned, mi az újdonság, mi az, amiről érdekes beszélni, mi az, amit különösen hasznos lehet megemlíteni.
- És megjelenik a kurzus egy bizonyos váza, ahol a legtöbb témát általában már lefedték, és úgy tűnik, bármi is van - rögzítsen videókat és indítsa el őket gyártásba.
- De valójában nem, akkor kezdődik a kemény munka, de nem a tanfolyam készítőinek, hanem a tesztelőknek. Alfatesztelőink általában technikai támogatást nyújtanak, amely először lektorálja a kurzusokat az esetleges szintaktikai és nyelvtani hibák miatt. Másodszor, fájdalmasan ütnek minket botokkal és káromkodnak, ha vannak teljesen átláthatatlan, érthetetlen helyek. Amikor néhány bonyolultan megkomponált, pár oldalas alárendelt mondat vagy nyilvánvaló értelmetlenség jelenik meg a szövegekben. Mindent elolvasnak, vigyáznak rá.
- Ezután kezdődik a gyakorló tesztelési szakasz, ahol néhány nyilvánvalóan nem működő dolgot is elkapnak, és megmutatnak néhány olyan momentumot, amelyet vagy megnehezíthet, mert nem lesz túl érdekes - csak ülni és másolni -, és azonosítják azokat a helyeket, ahol nagyon nehéz, és sok tennivalónk van azoktól, akik részt vesznek ezen a tanfolyamon. És akkor jönnek az ajánlások: "Srácok, egyszerűsítsétek, könnyebb lesz észlelni, és több haszna lesz."
- Ennyi munka elvégzése után megírják a videóhoz kapcsolódó részt, úgy tűnik, minden rendben van. És máris adományozhatod gyártásra, ennek a tanfolyamnak a reklámozására. De még egyszer mondom, nem, még túl korai – mert az utóbbi időben egy kicsit már nem bíztunk magunkban, és elvileg többet kezdtünk a visszajelzésekkel dolgozni. Létezik olyan, hogy béta tesztelés – ilyenkor külső, cégünkkel semmilyen kapcsolatban nem álló embereket hívnak meg, és néhány nyalánkságért megmutatják nekik a tanfolyam minden részét, videókat, szövegeket, gyakorlati feladatokat, hogy értékelte az anyag minőségét, az anyag hozzáférhetőségét, és segített abban, hogy a tanfolyamot a lehető legjobban tegyük.
- És ha több ilyen iteráció megy keresztül, hangszórók, alfatesztelés technikai támogatás formájában, béta tesztelés, fejlesztések. És akkor minden kezdődik elölről – technikai támogatás, béta tesztelés, fejlesztések.
- És egy bizonyos ponton jön a megértés, hogy vagy készen vagyunk a módosításokkal, mert teljesen irreális megbizonyosodni arról, hogy mindenkinek tetszik, vagy drasztikus döntések születnek. Ha bizonyos helyeken sok megjegyzés kritikus, ismételje meg őket globálisan, mert valami elromlott.
- Aztán eljön a kisebb szerkesztések ideje - valahol nem túl szépen van megfogalmazva a mondat, valahol valakinek nem tetszik a betűtípus, a 14,5, de szeretné a 15,7-et.
- Ha marad ez a fajta komment, akkor ennyi, többé-kevésbé kinyílik a pálya, kezdődik a hivatalos értékesítés.
És első pillantásra a tanfolyam létrehozásának rövid és egyszerű feladatáról kiderül, hogy egyáltalán nem egyszerű, és hihetetlenül sokáig tart.
És van még egy fontos pont, hogy a kurzussal végzett munka nem ér véget a kurzus kiadásával. Először is figyelmesen olvassuk el az egyes részeknél hagyott megjegyzéseket. És még minden erőfeszítésünk ellenére is azonosítottak bizonyos hibákat, bizonyos hibákat kijavítanak és javítanak az út során, valós időben, hogy minden következő felhasználó jobb szolgáltatást kapjon.
Minden tanfolyamnak megvan a maga terméktulajdonosa, aki az általános koncepció definiálása mellett ellenőrzi a határidőket, a margóra feljegyzi, hogy ha eljön az ideje a tanfolyam teljes átírásának, és biztosan eljön, mert két év múlva, vagy akár egy év elteltével néhány elmondott dolog irrelevánssá válik egyszerűen azért, mert erkölcsileg elavulttá válik. A terméktulajdonos a margóra feljegyzi, hogy az emberek leggyakrabban azt kérdezik, mely pontok voltak tisztázatlanok, mely feladatok tűntek nagyon nehéznek, és melyek éppen ellenkezőleg, nagyon egyszerűek. És mindezt figyelembe veszik a pálya újrarögzítésekor, valamilyen átalakítás során, hogy a globális pálya minden egyes iterációja jobb, kényelmesebb és kényelmesebb legyen.
Így jelennek meg a tanfolyamok.
Hogyan született meg a Docker tanfolyam
Ez egy különálló, sőt szokatlan téma számunkra. Mert egyrészt nem terveztük, hogy megcsináljuk, mert sok online iskola kínálja. Másrészt ő maga is szabadságot kért, és logikus helyet talált a Kubernetes informatikusok képzéséről szóló koncepciónkban.
Ha globálisan beszélünk, kezdetben az egész egy Kubernetes tanfolyammal kezdődött, amikor véleményem szerint az első Slurm után kezdődött. Visszajelzéseket gyűjtöttünk, és azt láttuk, hogy sokan szeretnének valami továbbit olvasni a Dockerről valahol máshol, és általában sokan úgy jönnek el a Kubernetes alaptanfolyamára, hogy nem tudják, mi az. .
Ezért a második Slurm-ra csináltak egy tanfolyamot – vagy inkább nem is tanfolyamot, hanem készítettek pár fejezetet a Dockerekről. Ahol elmondták a legalapvetőbb dolgokat, hogy az intenzívre érkezők ne érezzék magukat nélkülözve, és általában megértsék, mi történik.
Aztán az események nagyjából így alakultak. Az anyag mennyisége megnőtt, és 3 nap alatt megállt. És megjelent egy logikus és kézenfekvő ötlet: miért ne alakíthatnánk át azt, amit a Slurm Basic-en tárgyalunk, valamiféle kis kurzussá, ahová elküldhetnénk azokat, akik szeretnének valamit a Dockerről nézni, mielőtt egy intenzív Kubernetes tanfolyamra mennének.
A Slurm Junior valójában több ilyen alaptanfolyam kombinációja. Ennek eredményeként a Docker pálya a Slurm Junior darabja lett. Vagyis ez egy olyan nulla lépés előtte и . És akkor csak nagyon alapvető absztrakciók voltak.
Valamikor az emberek elkezdték kérdezni: „Srácok, ez nagyszerű, ennyi elég ahhoz, hogy megértsd, miről beszélsz az intenzív kurzusokon. Hol olvashatok részletesebben arról, hogy mit tud a docker és hogyan kell vele dolgozni, és mi az?” Így jött az ötlet, hogy tisztázzuk , hogy egyrészt a Slurm-ba Kubernetes használatával érkezőket továbbra is rá lehessen küldeni, másrészt pedig azokat, akiket a fejlesztés ezen szakaszában még nem is érdekel a Kubernetes. Annak érdekében, hogy egy informatikai szakember eljöhessen megnézni a Docker-tanfolyamunkat, és elindulhasson evolúciós útján egyszerűen a tiszta Dockerrel. Így van egy ilyen teljes értékű, teljes tanfolyamunk - aztán sokan, miután megnézték ezt a tanfolyamot, egy ideig a tiszta Dockerrel dolgoztak, arra a szintre nőttek, hogy Kubernetesre vagy más hangszerelési rendszerre van szükségük. És különösen hozzánk jöttek.
Néha felteszik a kérdést: "Miféle embereknek nincs szüksége Kubernetesre?" De ez a kérdés nem az emberekről szól, hanem inkább a cégekről. Itt meg kell értenie, hogy a Kubernetesnek vannak bizonyos esetei, amikor jól használható, és vannak olyan feladatai, amelyeket jól old meg, de éppen ellenkezőleg, van néhány forgatókönyv a Kubernetes használatára, amikor további fájdalmat és szenvedést okoz. Ezért nem is az embereken múlik, hanem azon, hogy milyen cégeket fejlesztenek és meddig.
Például valami szörnyű Legacy monolit - valószínűleg nem kellene a Kubernetesbe betolni, mert több problémát okoz, mint hasznot. Vagy például ha ez egy kis projekt, akkor kicsi a terhelése, vagy elvileg nem sok pénz és erőforrás. Nincs értelme belerángatni a Kubernetesbe.
És általában, valószínűleg, általában, amint azt már sokan mondták, ha felteszi a kérdést: „Szükségem van Kubernetesre?”, akkor valószínűleg nincs szüksége rá. Nem emlékszem, ki találta ki először, véleményem szerint Selivanov pasa. Ezzel 100%-ban egyetértek. És fel kell nőni a Kuberneteshez - és amikor már világossá válik, hogy nekem Kubernetesre van szükségem, és a cégünknek szüksége van rá, és ez segít megoldani az ilyen és ehhez hasonló problémákat, akkor valószínűleg van értelme tanulni és kitalálni, hogyan kell pontosan beállítani. jól fel, hogy a Kubernetesre való váltás ne legyen túl fájdalmas.
Egyes gyermekbetegségek és néhány egyszerű, sőt nem túl egyszerű dolog különösen tőlünk tudható meg, és nem megy át a saját fájdalmán.
Sok cég pontosan azt az utat járta be, hogy eleinte csak valamiféle infrastruktúra létezett konténerezés nélkül. Aztán eljutottak odáig, hogy nehéz lett az egészet kezelni, áttértek a Dockerre és valamikor odáig nőttek, hogy a Docker és az általa kínált keretek között szűkössé vált. És elkezdték nézni, hogy mi van a környéken, milyen rendszerek oldják meg ezeket a problémákat, és különösen a Kubernetes - ez az egyik olyan rendszer, amely lehetővé teszi a problémák megoldását, amikor a tiszta Docker zsúfolttá válik és hiányzik a funkcionalitás. Ez egy nagyon jó eset, amikor az emberek Lépésről lépésre alulról felfelé haladnak, megértik, hogy ez a technológia nem elég, és a következő szintre lépnek. Használtak valamit, megint kevés lett, és továbbmentek.
Ez tudatos választás – és nagyon klassz.
Általában azt látom, hogy a rendszerünk nagyon szépen fel van építve, pl. , akár videó tanfolyamokon keresztül is. Aztán docker után megy , akkor , akkor . Minden logikusan felsorakozik - az ember átmegy, és szilárd szakma alakul ki.
A kurzuskészlet elvileg nagyon sok, akár modern esetet is lehetővé tesz. Vannak még olyan területek, amelyek továbbra is szürke zónák maradnak, remélem, hamarosan létrehozunk néhány tanfolyamot, amely lehetővé teszi, hogy ezeket a szürke területeket bezárjuk, különösen a biztonsággal kapcsolatban. Mert ez kezd nagyon aktuális lenni.
Egyszóval van néhány szürke területünk, amit nagyon jó lenne bezárni, hogy teljes, teljes kép legyen – és jöhetnek az emberek, és ahogy maga a Kubernetes is olyan, mint egy Lego konstruktor, abból is lehet különböző dolgokat készíteni. összegyűjti, ha még mindig nem elég - kiegészíti, ugyanezt a tanfolyamainkkal is, hogy az emberek megértsék, mire van szükségük ebből, egyfajta puzzle-t, egyfajta építőkészletet kell összeállítaniuk a tanfolyamainkból.
Ha feltesz magadnak egy általánosan helyes és őszinte kérdést: „Ki tud most egy aktív Docker tanfolyamot használni?”, akkor:
- Olyan diákoknak, akik most kezdenek belejönni.
- A vizsgálati osztály dolgozói.
- Valójában sok olyan cég van, amely még mindig nem csak nem használja a Dockert, de senki sem hallott ilyen technológiáról, és elvileg nem is tudja, hogyan kell használni. És ismerek több nagy szentpétervári céget, amelyek hosszú évek óta fejlődnek, és néhány régi technológiát használtak, ebbe az irányba haladnak. Különösen az ilyen cégek számára, az ilyen cégek mérnökei számára lehet nagyon érdekes ez a tanfolyam, mivel egyrészt lehetővé teszi, hogy gyorsan elmerüljön ebben a technológiában, másrészt amint megjelenik több mérnök, akik megértik, hogyan működik, el tudják vinni a céghez, és fejleszteni tudják ezt a kultúrát és ezeket az irányokat a vállalaton belül.
- Véleményem szerint ez a kurzus még mindig hasznos lehet azoknak, akik már dolgoztak dockerrel, de nagyon keveset és többet „csináld egyszer, csináld kétszer” stílusban - és most valahogy kapcsolatba fognak lépni ugyanazzal a Kubernetestel, és ez bizonyos kötelezettségeket ró rájuk, ha nagyon felületes ismeretekkel rendelkezik arról, hogy mi az a docker, hogyan kell futtatni, de ugyanakkor nem tudja, hogyan működik belülről, nem tudja, mi a legjobb vele. azt és mit jobb nem csinálni, Akkor ez a tanfolyam kiválóan alkalmas az ismeretek rendszerezésére, elmélyítésére.
De ha rendelkezik a következő szintű ismeretekkel: „Nem tudom, hogyan kell helyesen írni ugyanazokat a Docker-fájlokat, el tudom képzelni, mik azok a névterek, hogyan működnek a konténerek, hogyan valósítják meg őket az operációs rendszer szintjén” - akkor ott van semmi értelme hozzánk járni, nem tanulsz semmi újat, és egy kicsit szomorú leszel a ráfordított pénz és idő miatt.
Ha megfogalmazzuk, hogy milyen előnyei vannak a tanfolyamunknak, akkor:
- Megpróbáltuk ezt a kurzust megfelelő számú gyakorlati esettel elkészíteni, amely lehetővé teszi, hogy ne csak a létező elméleti részt megértse, hanem megértse, miért van rá szüksége, és hogyan fogja használni a jövőben;
- van több olyan rész, ami nagyon ritkán található meg sehol - és általában nincs is róluk annyi anyag. Ezek a Docker és az operációs rendszer interakciójára vonatkoznak, méghozzá egy kicsit másképp. Milyen mechanizmusokat vett át a Docker az operációs rendszerből a konténerezési rendszer megvalósításához – és ez mélyebben megérti a konténerek Linux operációs rendszeren belüli futtatásának egész kérdését. Hogyan működik, hogyan kölcsönhatásba lép egymással az operációs rendszeren belül, azon kívül stb.
Ez olyan igazán mély pillantás, hogy elég ritkán fordul elő, ugyanakkor véleményem szerint nagyon fontos. Ha jól meg akar érteni bármely technológiát, és meg akarja érteni, hogy mit várhat el tőle, legalább általános elképzeléssel kell rendelkeznie arról, hogyan működik alacsony szinten.
Tanfolyamunk bemutatja és elmondja, hogyan működik ez az operációs rendszer szemszögéből. Egyrészt minden konténerrendszer ugyanazokat az operációs rendszer mechanizmusokat használja. Másrészt azt veszik, ami a Linux operációs rendszerben van, mint például a docker. Más konténerrendszerek nem hoztak semmi újat - átvették azt, ami már a Linuxban volt, és csak egy kényelmes wrappert írtak, amely lehetővé teszi a gyors meghívást, futtatást vagy valamilyen interakciót vele. Ugyanaz a Docker nem túl nagy réteg az operációs rendszer és a parancssor között, ez egyfajta segédprogram, amely lehetővé teszi, hogy ne írjon kilotonnákat parancsokat vagy valamilyen C kódot egy konténer létrehozásához, hanem ezt a néhány sor a terminálban.
És még valami, ha konkrétan a Dockerről beszélünk, amit a Docker valóban hozott az IT-világba, az a szabvány. Hogyan kell elindítani az alkalmazást, hogyan kell működnie, milyen követelmények vonatkoznak a naplókra, milyen követelmények vonatkoznak a méretezésre, magának az alkalmazásnak a konfigurálására.
A docker sok szempontból a szabványokról szól.
A szabványok is átkerülnek a Kubernetesre – és pontosan ugyanazok a szabványok; ha tudja, hogyan kell jól futtatni az alkalmazást a Dockerben, akkor az esetek 99%-ában a Kubernetesen belül is ugyanolyan jól fog működni.
Ha azon kapta magát, hogy nem csak a Docker kurzus létrejötte, hanem más kurzusok is érdekelt, hanem maga a tanfolyam gyakorlati szempontból is, akkor
Örömmel látunk!
Forrás: will.com