Udeleženec pride na teÄaj ali intenzivni teÄaj. Vidi urejene vrste tehniÄne podpore, lepo napeljane elektriÄne kable, Å”ahovnico v predavalnici, svetle slike in diagrame. Govorci s Å”alami in nasmehi podajajo informacije tako, da jih imate le Äas razumeti. Stojala so postavljena, vadbene naloge kar letijo od prstov, le da vÄasih potrebujete pomoÄ tehniÄnega osebja. podporo.
In tudi odmori za kavo s podobno misleÄimi ljudmi, veselo in energiÄno vzduÅ”je, izmenjava izkuÅ”enj, najbolj nepriÄakovana vpraÅ”anja za govornike. Tako odgovore kot informacije, ki jih ne boste naÅ”li v priroÄnikih, ampak le v praksi.
Kaj mislite, koliko Äasa, truda in živcev je bilo potrebnih, da je izgledalo toÄno tako?

ZahvaljujoÄ Volodji Guryanovu, certificiranemu skrbniku Kubernetes in vodji inženirja/ekipe pri Southbridgeu, ki je bil priÄa in je aktivno sodeloval pri ustvarjanju Å”tevilnih teÄajev Slurm od samega zaÄetka.
Videl je podzemlje ustvarjanja ā zapletenosti in trnove grablje, vpoglede in nepriÄakovane reÅ”itve. In že znani intenzivi Kubernetes, kot sta Slurm Basic in Slurm Mega. In nov, v veliki meri spremenjen teÄaj , ki se nezadržno bliža in se bo zaÄela 19. avgusta.

Ampak, morda dovolj besedila, preidimo na samo zgodbo. Kako iz par intenzivnih tem povsem samozadosten in veÄplasten . Zato bom zaÄel zgodbo o tem, kako teÄaji nastanejo in se razvijajo - tako kot "Pred davnimi Äasi v galaksiji daleÄ, daleÄ stran ..."
Kaj je v zakulisju?
Äe vpraÅ”ate, kako pripravljamo teÄaje in kje se vse zaÄne, vam bom preprosto odgovoril: Ā»Vse se zaÄne z idejoĀ«.
Ponavadi ideja pride od nekje - ne sedimo vklenjeni v kleti, dokler se ne domislimo: "O kateri temi naj naredimo teÄaj?" Ideje prihajajo od nekje same od sebe iz zunanjih virov. VÄasih se ljudje zaÄnejo aktivno spraÅ”evati: "Kaj veste o takÅ”ni in drugaÄni tehnologiji?" Ali pa kako je bilo z Dockerjem, da ga ni bilo mogoÄe umestiti v tajming za intenzivni teÄaj - oÄitno so ga morali peljati ven, da je imel Äas kaj povedati med intenzivnim teÄajem.

Tako se pojavi ideja.
Po objavi se po mojem mnenju zaÄne najtežji trenutek - na sploÅ”no razumeti, kaj vkljuÄiti v ta teÄaj - to je zelo primerljivo s tem, kako so govorci pripravljeni na katere koli konference.
Obstaja ena glavna boleÄina, ko se zdi, da ste izbrali temo in pomislite: Ā»Kaj naj povem o tem? To je preveÄ preprosto, to je oÄitno, tudi to vsi vedo.ā
A v resnici temu sploh ni tako. In osebno marsikje povem, da tisto, kar se zdi samoumevno tebi, tistim, ki te pridejo posluÅ”at ali hoditi na teÄaj, sploh ni oÄitno. In tu nastane tako velika plast dela in notranjega konflikta, kaj vkljuÄiti v teÄaj. Kot rezultat dobimo takÅ”en seznam poglavij s tako Å”irokimi velikimi potezami, o Äem bo govoril teÄaj.
In potem se zaÄne preprosto rutinsko delo:
- Izbira materiala
- Pazljivo preberite dokumentacijo za trenutno razliÄico, saj se IT svet zdaj razvija z nekakÅ”no kozmiÄno hitrostjo. Tudi Äe delaÅ” z neÄim in narediÅ” teÄaj o tem, moraÅ” iti v dokumentacijo in videti, kaj je tam novega, o Äem je zanimivega za pogovor, kaj bi bilo morda Å”e posebej koristno omeniti.
- In pojavi se doloÄeno okostje teÄaja, kjer je veÄina tem na sploÅ”no že zajeta in zdi se, da karkoli je tam - posnemite videe in jih lansirajte v produkcijo.
- Toda v resnici ne, potem se zaÄne trdo delo, vendar ne za avtorje teÄaja, ampak za tiste, ki testirajo. ObiÄajno so naÅ”i alfa preizkuÅ”evalci tehniÄna podpora, ki najprej lektorira teÄaje za morebitne sintaktiÄne in slovniÄne napake. DrugiÄ, boleÄe nas tepejo s palicami in preklinjajo, ko so neka povsem neoÄitna, nerazumljiva mesta. Ko se v besedilih pojavijo nekaj zapleteno sestavljenih podrednih stavkov, dolgih nekaj strani, ali oÄitne neumnosti. Vse preberejo, pazijo na to.
- Nato se zaÄne faza praktiÄnega testiranja, kjer se ujamejo tudi nekatere oÄitne nedelujoÄe stvari in pokažejo se nekateri trenutki, ki jih je mogoÄe otežiti, saj postane ne preveÄ zanimivo - samo sedenje in kopiranje - in identificirana so mesta, kjer je zelo težko in imamo veliko dela, ki ga želimo od ljudi, ki bodo obiskovali ta teÄaj. In potem pridejo priporoÄila: "Fantje, poenostavite tukaj, lažje bo zaznati in bo od tega veÄ koristi."
- Ko je ta koliÄina dela opravljena, del, ki se nanaÅ”a na video, je napisan, vse se zdi v redu. In že lahko podarite za produkcijo, za oglaÅ”evanje tega teÄaja. Ampak spet ne, prezgodaj je - ker smo v zadnjem Äasu malo nehali zaupati vase in smo naÄeloma zaÄeli bolj delati s povratnimi informacijami. Obstaja nekaj takega, kot je beta testiranje - to je, ko so povabljeni ljudje od zunaj, ki niso na noben naÄin povezani z naÅ”im podjetjem, in za nekatere dobrote so jim prikazani vsi deli teÄaja, videi, besedilo, praktiÄne naloge, tako da ovrednotili kakovost gradiva, dostopnost gradiva in nam pomagali narediti teÄaj Äim boljÅ”i.
- In ko gre skozi veÄ takih iteracij, zvoÄniki, alfa testiranje v obliki tehniÄne podpore, beta testiranje, izboljÅ”ave. In potem se vse zaÄne znova - tehniÄna podpora, beta testiranje, izboljÅ”ave.
- In na neki toÄki pride do razumevanja, ali smo konÄali s spremembami, ker je popolnoma nerealno zagotoviti, da bo vsem vÅ”eÄ, ali pa so sprejete nekatere drastiÄne odloÄitve. Ko je veliko komentarjev na doloÄenih mestih kritiÄnih, jih ponovite globalno, ker je Å”lo nekaj narobe.
- Potem pride Äas za manjÅ”e popravke - nekje stavek ni lepo formuliran, nekje nekomu ni vÅ”eÄ pisava, 14,5, pa bi rad 15,7.
- Ko ta vrsta komentarja ostane, potem je to to, teÄaj se bolj ali manj odpre, zaÄne se uradna prodaja.
In na prvi pogled se kratka in enostavna naloga izdelave teÄaja izkaže za prav niÄ enostavna in traja neverjetno dolgo.
In Å”e ena pomembna toÄka je, da se delo s teÄajem ne konÄa, ko je teÄaj izdan. Najprej natanÄno preberemo komentarje, ki so puÅ”Äeni na doloÄenih delih. In kljub vsemu trudu, ki smo ga vložili, se nekatere pomanjkljivosti Å”e vedno odkrijejo, nekatere napake sproti popravljamo in izboljÅ”ujemo, tako da je vsak naslednji uporabnik deležen boljÅ”e storitve.

Vsak teÄaj ima svojega produktnega lastnika, ki poleg definiranja sploÅ”nega koncepta preverja termine, si na robu beleži, da ko bo Äas za popolno prepisovanje teÄaja, in zagotovo bo priÅ”el, kajti Äez dve leti, ali celo leto kasneje bo nekaj od tega, kar povemo, postalo nepomembno preprosto zato, ker bo postalo moralno zastarelo. Lastnik izdelka ob robovih zapiÅ”e, da ljudje najpogosteje spraÅ”ujejo, katere toÄke so bile nejasne, katere naloge so se zdele zelo težke in katere so se zdele, nasprotno, zelo preproste. In vse to se upoÅ”teva pri ponovnem snemanju teÄaja, med nekakÅ”nim refactoringom, tako da vsaka ponovitev globalnega teÄaja postane boljÅ”a, bolj priroÄna in udobna.
Tako se pojavijo teÄaji.
Kako se je rodil teÄaj Docker
To je za nas loÄena in celo nenavadna tema. Ker po eni strani tega nismo naÄrtovali, saj to ponuja veliko spletnih Å”ol. Po drugi strani pa je sam prosil za svobodo in naÅ”el logiÄno mesto v naÅ”em konceptu usposabljanja informatikov v Kubernetesu.
Gledano zelo globalno, sprva se je vse zaÄelo s teÄajem o Kubernetesu, ko se je Å”ele zaÄelo, po mojem mnenju po prvem Slurmu. Zbrali smo povratne informacije in videli, da veliko ljudi želi prebrati nekaj dodatnega o Dockerju kje drugje, na sploÅ”no pa mnogi pridejo na osnovni teÄaj o Kubernetesu, ne da bi vedeli, kaj to je .
Zato so za drugi Slurm naredili teÄaj - bolje reÄeno, niti teÄaj, ampak so naredili nekaj poglavij o Dockerjih. Kjer so povedali nekaj najbolj osnovnih stvari, da se ljudje, ki pridejo na intenzivno, ne bi poÄutili prikrajÅ”ane in bi na sploÅ”no razumeli, kaj se dogaja.

In potem so se dogodki razvijali približno tako. KoliÄina materiala je narasla in v 3 dneh ni veÄ ustrezala. In pojavila se je logiÄna in oÄitna ideja: zakaj ne bi tega, kar pokrivamo na Slurm Basic, spremenili v nekakÅ”en majhen teÄaj, na katerega bi lahko poslali ljudi, ki si želijo ogledati nekaj o Dockerju, preden se udeležijo intenzivnega teÄaja o Kubernetesu.
Slurm Junior je pravzaprav kombinacija veÄ takih osnovnih teÄajev. PoslediÄno je teÄaj Docker postal del Slurm Junior. Se pravi, to je tako niÄelni korak prej Šø . In potem so bile samo zelo osnovne abstrakcije.

Na neki toÄki so ljudje zaÄeli spraÅ”evati: Ā»Fantje, to je vse super, to je dovolj, da razumemo, o Äem govorite na intenzivnih teÄajih. Kje lahko preberem podrobneje o tem, kaj lahko poÄne docker in kako delati z njim ter kaj je?Ā« Tako se je porodila ideja, da bi bilo naravnost , tako da se lahko, prviÄ, ljudje, ki pridejo v Slurm z uporabo Kubernetesa, Å”e vedno poÅ”iljajo vanj, po drugi strani pa za tiste, ki jih Kubernetes na tej stopnji razvoja niti ne zanima. Tako da lahko strokovnjak za IT pride pogledat naÅ” teÄaj o Dockerju in zaÄne svojo evolucijsko pot preprosto s Äistim Dockerjem. Tako da imamo tako polnopraven, popoln teÄaj - in potem so mnogi, ki so gledali ta teÄaj in nekaj Äasa delali s Äistim Dockerjem, zrasli na raven, ko potrebujejo Kubernetes ali kakÅ”en drug sistem orkestracije. In k nam so priÅ”li Å”e posebej.
VÄasih se postavlja vpraÅ”anje: "KakÅ”ni ljudje zdaj morda ne potrebujejo Kubernetesa?" Vendar to vpraÅ”anje ne zadeva ljudi, temveÄ vpraÅ”anje podjetij. Tukaj morate razumeti, da ima Kubernetes doloÄene primere, v katerih je zelo primeren, in naloge, ki jih dobro reÅ”uje, nasprotno pa obstaja nekaj scenarijev za uporabo Kubernetesa, ko povzroÄa dodatno boleÄino in dodatno trpljenje. Zato niti ni odvisno od ljudi, ampak od tega, katera podjetja se razvijajo in kako dolgo.
Na primer, kakÅ”en grozen Legacy monolit - verjetno ga ne bi smeli potisniti v Kubernetes, ker bo povzroÄil veÄ težav kot koristi. Ali pa na primer, Äe je to majhen projekt, ima majhno obremenitev ali naÄeloma ni veliko denarja in sredstev. Nima smisla ga vleÄi v Kubernetes.
In na sploÅ”no, verjetno, na sploÅ”no, kot je že veliko ljudi povedalo, Äe postavljate vpraÅ”anje: "Ali potrebujem Kubernetes?", Potem ga najverjetneje ne potrebujete. Ne spomnim se, kdo se je tega prvi domislil, po mojem mnenju Pasha Selivanov. Strinjam se s tem 100%. In do Kubernetesa moraÅ” odrasti - in ko že postane jasno, da jaz potrebujem Kubernetes in ga potrebuje naÅ”e podjetje ter da bo pomagal reÅ”iti takÅ”na in drugaÄna vpraÅ”anja, potem je verjetno smiselno, da se uÄiÅ” in natanÄno ugotoviÅ”, kako nastaviti tako, da postopek prehoda na Kubernetes ni zelo boleÄ.
Nekatere otroÅ”ke tegobe in nekatere preproste stvari, pa tudi ne zelo preproste, lahko izveste predvsem pri nas in ne greste skozi lastne grablje in boleÄine.
Mnoga podjetja so Å”la prav po tej poti, da je sprva obstajala samo nekakÅ”na infrastruktura brez kontejnerizacije. Potem so priÅ”li do toÄke, ko je postalo težko vse to obvladati, so preÅ”li na Docker in na neki toÄki zrasli do te mere, da je postalo utesnjeno v okviru Dockerja in tega, kar ponuja. In zaÄeli so gledati, kaj je naokoli, kateri sistemi reÅ”ujejo te težave, zlasti Kubernetes ā to je eden tistih sistemov, ki vam omogoÄa reÅ”evanje težav, ko Äisti Docker postane prenatrpan in nima funkcionalnosti, to je res dober primer, ko ljudje Gredo korak za korakom od spodaj navzgor, razumejo, da ta tehnologija ni dovolj in preidejo na naslednjo raven. Nekaj āāso porabili, tega je spet zmanjkalo in so Å”li naprej.
To je zavestna izbira - in je zelo kul.
Na sploÅ”no vidim, da je naÅ” sistem zelo lepo zgrajen, npr. , tudi prek video teÄajev. Potem gre za dockerjem torej torej . Vse se vrsti logiÄno - Älovek mine in nastane trden poklic.
NaÄeloma vam nabor teÄajev omogoÄa, da pokrijete veliko primerov, tudi sodobnih. Å e vedno so podroÄja, ki ostajajo siva obmoÄja, upam, da bomo kmalu ustvarili nekaj teÄajev, ki nam bodo omogoÄili, da zapremo te sive cone, predvsem bomo izmislili nekaj o varnosti. Ker to postaja zelo aktualno.
Skratka, imamo nekaj sivih lis, ki bi jih bilo zelo lepo zapreti, da bi bila celostna, popolna slika ā in ljudje bi lahko priÅ”li in tako kot je sam Kubernetes kot lego konstruktor, lahko narediÅ” razliÄne stvari iz zbira, Äe Å”e vedno ni dovolj - dopolnjuje, enako je z naÅ”imi teÄaji, da ljudje razumejo, kaj od tega potrebujejo, iz naÅ”ih teÄajev morajo sestaviti nekakÅ”no sestavljanko, nekakÅ”en konstrukcijski set.

Äe si zastavite na sploÅ”no pravilno in poÅ”teno vpraÅ”anje: "Kdo bi zdaj lahko uporabljal aktivni teÄaj Docker?", potem:
- Za Å”tudente, ki se Å”ele zaÄenjajo s tem ukvarjati.
- Zaposleni v oddelku za testiranje.
- Pravzaprav obstaja veliko podjetij, ki Å”e vedno ne le ne uporabljajo Dockerja, ampak nihÄe ni sliÅ”al za takÅ”no tehnologijo in je naÄeloma ne znajo uporabljati. In poznam veÄ velikih podjetij v Sankt Peterburgu, ki so se razvijala veÄ let in so uporabljala nekatere stare tehnologije, gredo v to smer. Zlasti za takÅ”na podjetja, za inženirje v takÅ”nih podjetjih, je ta teÄaj lahko zelo zanimiv, saj vam bo, prviÄ, omogoÄil, da se hitro potopite v to tehnologijo, in drugiÄ, takoj ko se pojavi veÄ inženirjev, ki razumejo, kako vse to dela, lahko to prinesejo v podjetje in razvijejo to kulturo in te usmeritve znotraj podjetja.
- Po mojem mnenju je ta teÄaj lahko Å”e vedno uporaben za tiste, ki so že delali z dockerjem, vendar zelo malo in bolj v slogu "naredi enkrat, naredi dvakrat" - in zdaj bodo nekako sodelovali z istim Kubernetesom in tem jim nalaga doloÄene obveznosti, Äe imaÅ” zelo povrÅ”no znanje o tem, kaj je docker, kako ga poganjaÅ”, hkrati pa ne veÅ”, kako deluje od znotraj, ne veÅ”, kaj je najbolje poÄeti z in Äesa je bolje ne poÄeti, potem je ta teÄaj zelo primeren za sistematizacijo in poglabljanje znanja.
Ampak, Äe imate znanje na ravni: "Ne vem, kako pravilno napisati iste datoteke Docker, lahko si predstavljam, kaj so imenski prostori, kako vsebniki delujejo, kako so dejansko implementirani na ravni operacijskega sistema" - potem je tu vsekakor nima smisla hoditi k nam, ne boste izvedeli niÄ novega in boste malo žalostni zaradi porabljenega denarja in Äasa.
Äe formuliramo, katere prednosti ima naÅ” teÄaj, potem:
- PoskuÅ”ali smo narediti ta teÄaj z zadostnim Å”tevilom praktiÄnih primerov, ki vam bodo omogoÄili ne samo razumevanje teoretiÄnega dela, ki obstaja, ampak tudi razumevanje, zakaj ga potrebujete in kako ga boste uporabljali v prihodnosti;
- obstaja veÄ razdelkov, ki jih zelo redko kje najdemo - in na sploÅ”no ni toliko gradiva o njih. Povezani so z interakcijo Dockerja z operacijskim sistemom, celo nekoliko drugaÄe. Katere mehanizme je Docker vzel iz operacijskega sistema za implementacijo sistema kontejnerizacije - in to daje tako globlje razumevanje celotne problematike izvajanja vsebnikov v operacijskem sistemu Linux. Kako deluje, kako medsebojno deluje znotraj operacijskega sistema, zunaj itd.
To je tako resniÄno globok pogled, da se zgodi zelo redko, hkrati pa je po mojem mnenju zelo pomemben. Äe želite dobro razumeti katero koli tehnologijo in razumeti, kaj lahko priÄakujete od nje, morate imeti vsaj sploÅ”no predstavo o tem, kako deluje na nizki ravni.
NaÅ” teÄaj prikazuje in pove, kako to deluje z vidika operacijskega sistema. Po eni strani vsi kontejnerski sistemi uporabljajo iste mehanizme operacijskega sistema. Po drugi strani pa vzamejo tisto, kar je v operacijskem sistemu Linux, na primer docker. Drugi sistemi za kontejnerizacijo niso prinesli niÄ novega - vzeli so tisto, kar je že bilo v Linuxu, in napisali le priroÄen ovoj, ki vam omogoÄa, da ga hitro pokliÄete, zaženete ali nekako komunicirate z njim. Isti Docker ni zelo velik sloj med operacijskim sistemom in ukazno vrstico, je nekakÅ”en pripomoÄek, ki vam omogoÄa, da ne piÅ”ete kilotonov ukazov ali neke vrste kode C za ustvarjanje vsebnika, ampak da to storite tako, da vnesete nekaj vrstic v terminalu.
In Å”e nekaj, Äe govorimo konkretno o Dockerju, tisto, kar je Docker res prinesel v IT svet, so standardi. Kako naj se aplikacija zažene, kako naj deluje, kakÅ”ne so zahteve za dnevnike, kakÅ”ne so zahteve za skaliranje, konfiguracija same aplikacije.
V mnogih pogledih se docker nanaŔa na standarde.
Standardi se selijo tudi v Kubernetes - in tam so povsem enaki standardi; Äe znate svojo aplikacijo dobro izvajati v Dockerju, bo 99 % Äasa delovala prav tako dobro v Kubernetesu.
Äe vas ne zanima le, kako je bil ustvarjen teÄaj Docker, ampak tudi drugi teÄaji, ampak vas teÄaj sam zanima tudi s praktiÄnega vidika, potem
Veseli vas bomo!
Vir: www.habr.com
