Participant arrives at the course or intensive. They see neatly lined technical support, carefully laid power cables, an orderly lecture hall, bright images, and diagrams on slides. Speakers deliver information with jokes and smiles, making it so engaging that you can hardly keep up. The stands are set up, practical tasks fly off the fingers, though sometimes help from tech support is needed.
And there are coffee breaks with like-minded individuals, a lively and energetic atmosphere, the exchange of experiences, and the most unexpected questions for the speakers. Plus answers, and information that you won’t find in manuals, but only in practice.
How long do you think it took, in terms of time, effort, and nerves, to make it look exactly like this?
Thanks to Volodya Guryanov, a certified Kubernetes administrator and engineer/team lead at Southbridge, who has been a witness and an active participant in the creation of many Slerma courses from the very beginning.
He has seen the behind-the-scenes of course creation — the challenges and hidden pitfalls, insights and unexpected solutions. And the already established intensives on Kubernetes, such as Slerm Basic and Slerm Mega. And a new, largely revamped course. , which is relentlessly approaching and will start on August 19.
But perhaps enough of the lyrical, let’s move on to the story itself. How from a couple of topics of the intensive, a fully self-sufficient and multifaceted gradually emerged. So I will start telling how courses are created and developed — just like "A long time ago in a galaxy far, far away…"
And what goes on behind the scenes?
If you ask how we create courses and where it all starts, I would simply say, "Everything starts with an idea."
Usually, an idea comes from somewhere — we are not sitting handcuffed in a basement waiting to think, "What topic should we make a course on?" Ideas come from external sources. Sometimes people start actively asking: "What do you know about this specific technology?". Or, as with Docker, it turned out that it couldn’t fit into the timing of the intensive — it needed to be clearly taken outside to make space to discuss something within the intensive.
This is exactly how an idea emerges.
After it appears, the most challenging moment begins — figuring out what to include in this course — this is very comparable to how speakers prepare for various conferences.
Există o durere principală atunci când alegi un subiect și te gândești: „Ce să spun despre el? Asta e prea simplu, e evident, toată lumea știe asta.”
Dar, de fapt, nu este deloc așa. Și eu personal spun foarte des, că ceea ce ție ți se pare evident, pentru cei care vor veni să te asculte sau să participe la curs, nu este deloc evident. Aici apare un mare volum de muncă și un conflict intern, iar ce să includ în curs. Rezultatul este o listă de capitole schițate cu linii mari, despre ceea ce va fi cursul.
Și apoi începe munca obișnuită simplă:
- Selectarea materialului
- Citirea atentă a documentației pentru versiunea curentă, deoarece lumea IT-ului se dezvoltă acum cu viteze uluitoare. Chiar dacă lucrezi cu ceva și faci un curs pe acest subiect, trebuie să consulți documentația și să vezi ce este nou, despre ce este interesant să vorbești, despre ce ar trebui să menționezi în mod special.
- Și astfel apare un fel de schelet al cursului, unde deja o mare parte din subiecte este, în general, detaliată și pare că ar trebui să înregistrezi videoclipurile și să le lansezi în producție.
- Dar, de fapt, nu, apoi începe munca grea, dar nu pentru autorii cursului, ci pentru cei care testează. De obicei, alpha-testerii noștri sunt suportul tehnic, care, pe de o parte, corectează cursurile pentru a găsi diverse erori de sintaxă și gramatică. Pe de altă parte, ne sancționează sever și se plâng când există locuri cu adevărat obscure și neclare. Când în texte apar propoziții complicate de două pagini sau pur și simplu prostii evidente. Ei corectează și observă toate acestea.
- Apoi începe etapa de testare practică, unde se identifică și lucruri evidente care nu funcționează și se indică anumite momente care pot fi fie complicate, deoarece devin neinteresante - doar stai și copiezi - și se descoperă locuri unde cerem foarte multe de la persoanele care vor participa la acest curs. Și atunci vin recomandările: „Faceți, băieți, să fie mai simplu, va fi mai ușor de înțeles și va fi mai multă utilitate din asta.”
- După ce a fost realizat acest volum de lucru, partea referitoare la video a fost scrisă, părea că totul este bine. Și putea fi deja predată pentru lansare, pentru promovarea acestui curs. Dar, din nou, nu, este prea devreme — deoarece, în ultima vreme, am început să avem mai puțin încredere în noi înșine și, în principiu, am început să lucrăm mai mult cu feedback-ul. A apărut o idee, numită testare beta — aceasta este atunci când sunt invitați oameni deloc conectați la compania noastră și pentru anumite beneficii li se arată toate părțile cursului, video, text, sarcini practice, pentru a evalua calitatea materialului, accesibilitatea materialului și a ne ajuta să facem cursul cât mai bun posibil.
- Și când trec câteva astfel de iterații, cu speakerii, testarea alpha sub forma suportului tehnic, testarea beta, îmbunătățirile. Și apoi totul începe din nou — suport tehnic, testare beta, îmbunătățiri.
- Și într-un anumit moment vine înțelegerea că fie ne oprim cu îmbunătățirile, deoarece a face ceva care să placă tuturor – este complet nerealist, fie se iau anumite decizii radicale. Când foarte multe observații referitoare la anumite părți sunt critice — trebuie refăcute global, pentru că ceva nu a mers bine.
- Apoi vine timpul modificărilor minore — unde o anumită propoziție nu este formulată foarte frumos, unde cuiva nu-i place fontul, 14,5, iar el ar dori 15,7.
- Atunci când rămân observații de acest tip, cursul este mai mult sau mai puțin deschis, încep vânzările oficiale.
Și la prima vedere, sarcina scurtă și simplă de a crea un curs se dovedește a fi de fapt deloc simplă și necesită o cantitate incredibilă de timp.
Și mai există un aspect important, că munca la curs nu se termină odată cu lansarea acestuia. În primul rând, citim cu atenție comentariile lăsate la diferitele părți. Și chiar și în ciuda tuturor eforturilor pe care le-am depus, tot se identifică anumite neajunsuri, anumite greșeli, care sunt corectate în timp real, sunt îmbunătățite, astfel încât fiecare utilizator următor să primească un serviciu de mai bună calitate.
Fiecare curs are propriul său product owner, care, pe lângă stabilirea conceptului general și verificarea termenelor, își face note în margine, că atunci când va veni vremea să rescrie complet cursul, acel moment va veni cu siguranță, deoarece peste un an sau doi, o parte din ceea ce explicăm va deveni învechit din cauza moralității sale. Product owner-ul face notițe în margine despre ce întrebări au avut oamenii, ce aspecte au fost neclare, ce sarcini au părut foarte dificile și ce au părut, dimpotrivă, foarte simple. Toate acestea sunt luate în considerare la rescrierea cursului, la un anumit refactoring, astfel încât fiecare iterație globală a cursului să devină mai bună, mai ușor de utilizat și mai confortabilă.
Așa apar cursurile.
Cum a apărut cursul de Docker
Aceasta este un subiect separat și chiar neobișnuit pentru noi. Pentru că, pe de o parte, nu ne-am planificat să-l facem, deoarece multe școli online îl oferă. Pe de altă parte, el s-a cerut singur și a găsit un loc logic în concepția noastră de formare a specialiștilor IT în Kubernetes.
Dacă ne gândim foarte generat, totul a început cu cursul de Kubernetes, când a început doar, cred, după primul Slurm. Am adunat feedback și am observat că foarte mulți dintre ei doresc să citească suplimentar ceva despre Docker și în general, mulți vin la cursul de bază în Kubernetes fără a ști ce este. .
De aceea, pentru al doilea Slurm am făcut un curs - mai exact, nu un curs, ci am făcut câteva capitole despre Docker. Acolo am explicat cele mai elementare lucruri, astfel încât persoanele care vin la intensificare să nu se simtă dezavantajate și să înțeleagă ce se întâmplă.
Apoi, evenimentele s-au desfășurat, cam așa. Cantitatea de material a crescut și nu a mai încăput în 3 zile. A apărut o idee logică și evidentă: de ce să nu facem din ceea ce explicăm în Slurm Bază un fel de mic curs, la care să putem trimite oamenii care vor să se uite la ceva despre Docker înainte de intensificarea în Kubernetes.
Slurm Junior - este, de fapt, o combinație a mai multor astfel de cursuri de bază. Ca rezultat, cursul de Docker a devenit o parte a Slurm Junior. Așa că acesta este un prim pas înainte. și . Apoi, acolo au fost niște abstracții foarte de bază.
La un moment dat, oamenii au început să întrebe: „Băieți, e minunat tot ceea ce oferiți, este suficient pentru a înțelege ceea ce explicați în ateliere. Dar unde pot citi mai multe despre ce poate face Docker și cum să lucrez cu el, și ce reprezintă acesta?”. Așa a apărut ideea de a-l transforma într-un , astfel încât, pe de o parte, să putem trimite acolo persoanele care vin la Scrum despre Kubernetes, iar pe de altă parte, pentru cei pentru care Kubernetes nu este interesant în acest stadiu. Ca un specialist IT să poată veni să vizioneze cursul nostru de Docker și să își înceapă drumul evolutiv chiar de la Docker curat. Să avem un astfel de curs complet finalizat — și mulți, după ce vor viziona acest curs, lucrând pentru o vreme cu Docker curat, vor ajunge la un nivel în care vor necesita deja Kubernetes sau un alt sistem de orchestration. Și au venit în mod special la noi.
Întrebările sunt uneori: „Pentru ce persoane ar putea fi acum inutil Kubernetes?”. Dar această întrebare nu se referă la oameni, ci mai degrabă la companii. Trebuie să înțelegem că Kubernetes are anumite cazuri în care se potrivește bine și problemele pe care le rezolvă bine, iar pe de altă parte, există anumite scenarii în care utilizarea Kubernetes poate produce dureri și suferințe suplimentare. Prin urmare, nu depinde de oameni, ci de ceea ce și cum dezvoltă companiile.
De exemplu, un monolit legacy teribil — probabil că nu ar trebui să-l introduci în Kubernetes, deoarece acest lucru ar cauza mai multe probleme decât avantaje. Sau, de exemplu, dacă este un proiect mic — are o încărcare ușoară sau nu dispune în general de mulți bani și resurse. Atunci, a-l aduce în Kubernetes nu are niciun sens.
Și în general, probabil că, așa cum a spus deja multă lume, dacă te întrebi: „Am nevoie de Kubernetes?”, atunci cel mai probabil nu ai nevoie de el. Nu-mi amintesc cine a spus prima dată asta, cred că Pasha Selivanov. Sunt complet de acord. Trebuie să crești până la Kubernetes — și atunci când apare deja înțelegerea că ai nevoie de Kubernetes și compania ta are nevoie de el, că acesta va ajuta să soluționezi anumite întrebări, atunci probabil că are sens să te duci să înveți și să înțelegi cum să-l configurezi bine, astfel încât procesul de tranziție la Kubernetes să nu fie foarte dureros.
Există unele probleme comune și lucruri simple, dar chiar și cele nu foarte simple, pe care le poți descoperi la noi, fără a trece prin propriile greșeli și suferințe.
Multe companii au urmat calea de a construi mai întâi o infrastructură simplă, fără containerizare. Apoi, când a devenit greu să gestioneze totul, au trecut la Docker și, într-un anumit moment, au ajuns în situația în care ceea ce oferă Docker devine insuficient. Au început să caute soluții externe, iar Kubernetes este una dintre sistemele care ajută la rezolvarea problemelor atunci când în Docker devine strâmt și funcționalitatea nu este suficientă; acesta este un caz bun de dezvoltare treptată, în care oamenii își dau seama că tehnologia nu este suficientă și trec la nivelul următor. Au folosit ceva, iar când devine insuficient, continuă să exploreze.
Este o alegere conștientă — și este foarte mișto.
Eu observ că sistemul nostru se organizează foarte frumos, de exemplu, , chiar și în cadrul cursurilor video. Apoi, după Docker, urmează , apoi , apoi . Totul se structurează logic — o persoană urmează și rezultatul este o profesie completă.
În principiu, setul de cursuri permite acoperirea multor cazuri moderne. Există încă zone care rămân neexplorate, sper că în curând vom dezvolta cursuri care să abordeze aceste domenii gri, în special legate de securitate. Deoarece acest lucru devine foarte relevant.
Pe scurt, există unele zone gri pe care ar fi foarte bine să le acoperim, astfel încât să avem o imagine completă — și oamenii să poată veni, exact cum Kubernetes reprezintă un constructor Lego, din care pot fi asamblate diferite componente; dacă mai lipsește ceva, se poate completa, la fel și cu cursurile noastre, astfel încât oamenii să înțeleagă ce le este necesar din acestea, să construiască un anumit puzzle, un constructor din cursurile noastre.
Dacă ne punem o întrebare corectă și onestă: "Cui îi va fi util un curs activ de Docker acum?", atunci:
- Studenților care abia încep să înțeleagă.
- Angajaților din departamentul de testare.
- În realitate, există multe companii care, până în prezent, nu doar că nu folosesc containere Docker, dar nimeni nu a auzit de această tehnologie și nu știu cum să o utilizeze. Știu câteva mari companii din același Sankt Petersburg, care se ocupă de dezvoltare de mulți ani și care continuă să folosească tehnologii vechi. Pentru aceste companii și inginerii lor, acest curs poate fi foarte interesant, deoarece, pe de o parte, va permite o imersie rapidă în această tehnologie, iar pe de altă parte, imediat ce apar câțiva ingineri care înțeleg cum funcționează, ei pot aduce această cultură în companie și deja dezvolta aceste direcții în cadrul organizației.
- Din punctul meu de vedere, acest curs poate fi de ajutor și pentru cei care au lucrat puțin cu Docker, dar mai mult în stilul „fă odată, fă de două ori” — și acum, într-un fel sau altul, intenționează să colaboreze cu Kubernetes, iar aceasta le impune niște obligații. Dacă au cunoștințe foarte superficiale despre ce este Docker, cum să îl ruleze, dar nu știu cum funcționează intern, nu știu ce să facă mai bine cu el și ce ar fi mai bine să evite, atunci acest curs este potrivit pentru sistematizarea și aprofundarea cunoștințelor.
Dar dacă cunoștințele tale sunt la nivelul: „Nu știu cum să scriu corect fișiere Docker, știu ce sunt namespaces, cum funcționează containerele, cum sunt acestea realmente implementate la nivelul sistemului de operare” — atunci nu are sens să veniți la noi, nu veți învăța nimic nou și veți fi puțin trist pentru banii și timpul irosite.
Dacă ar trebui să formulăm care sunt avantajele cursului nostru, atunci:
- am încercat să realizăm acest curs cu un număr suficient de cazuri practice care vă vor permite nu doar să înțelegeți partea teoretică, ci și să înțelegeți de ce aveți nevoie de aceasta și cum o veți folosi în continuare;
- Există câteva secțiuni care sunt foarte rar întâlnite — și de fapt nu există multe materiale despre ele. Acestea se referă la interacțiunea Docker cu sistemul de operare, chiar și puțin diferit. Ce mecanisme a împrumutat Docker de la sistemul de operare pentru a realiza sistemul de containerizare — și acest lucru oferă o înțelegere mai profundă a întregii probleme legate de lansarea containerelor în cadrul sistemului de operare Linux. Cum funcționează, cum interacționează între ele în interiorul sistemului de operare, în exterior și așa mai departe.
Este o privire profundă, care apare destul de rar, și consider că este foarte importantă. Dacă doriți să înțelegeți bine orice tehnologie și să știți la ce să vă așteptați de la ea, trebuie să aveți o idee generală despre cum funcționează la un nivel foarte de bază.
Cursul nostru arată și explică cum este organizat totul din perspectiva sistemului de operare. Pe de o parte, toate sistemele de containerizare folosesc aceleași mecanisme ale sistemului de operare. Pe de altă parte, ele împrumută ceea ce există în sistemul de operare Linux, cum ar fi Docker. Alte sisteme de containerizare nu au inventat nimic nou — ele au luat ceea ce există deja în Linux și au scris o simplă interfață care permite să le apelați rapid, să le lansați sau să interacționați cu ele. Ușurința oferită de Docker constă în faptul că este o barieră mică între sistemul de operare și linia de comandă, o unealtă care permite să nu scrieți o mulțime de comenzi sau cod în C pentru a crea un container, ci să faceți acest lucru prin introducerea a câteva linii în terminal.
În plus, dacă vorbim despre Docker, ceea ce a adus cu adevărat Docker în lumea IT este standardele. Cum ar trebui să fie lansată o aplicație, cum ar trebui să funcționeze, ce cerințe există pentru loguri, ce cerințe sunt pentru scalare și configurarea aplicației în sine.
În mare parte, Docker este despre standarde.
Standardele sunt transferate în Kubernetes — și acolo sunt exact aceleași standarde; dacă știți cum să lansați aplicația dvs. bine în Docker, atunci cu 99% certitudine va funcționa la fel de bine și în cadrul Kubernetes.
Dacă v-a atras interesul nu doar modul în care a fost creat cursul Docker, dar și alte cursuri, ci și cursul în sine din punct de vedere practic, atunci
Ne face plăcere să vă vedem!
Sursa: habr.com
