Deltageren ankommer til kurset eller intensivforløbet. Han ser de velordnede rækker af supportpersonale, pænt installerede strømkabler, den skaklignende opstilling i foredragssalen, farverige billeder og slideskemaer. Talere præsenterer information med humor og smil, så man kun skal følge med. Standene er indstillet, opgaverne løses med lethed, dog er der engang imellem behov for hjælp fra supportteamet.
Og så er der kaffepauser med ligesindede, en energisk og livlig atmosfære, erfaringsudveksling, de mest uventede spørgsmål til talerne. Og svarene, samt information, som ikke findes i manualerne, men kun i praksis.
Hvad tænker du, hvor lang tid, kræfter og nerver der gik til, at det ser præcis sådan her ud?
Tak til Volodya Guryanov, certificeret administrator af Kubernetes og ingeniør/teamleder i Southbridge, som fra starten har været vidne og en aktiv deltager i skabelsen af mange Slorm-kurser.
Han har set bagsiden af kursusskabelsen - udfordringerne og de tårede faldgruber, indsigterne og de uventede løsninger. Og de allerede velkendte intensivforløb om Kubernetes, såsom Slorm Basic og Slorm Mega. Og et nyt, i mange henseender omarbejdet kursus. , som uundgåeligt nærmer sig og starter den 19. august.
Men måske er det nok med lyrik, lad os gå videre til historien. Hvordan et par emner fra intensivforløbet gradvist voksede til et helt selvstændigt og mangfoldigt . Så jeg vil begynde fortællingen om, hvordan kurser skabes og udvikles - nærmest "For længe siden i en galakse langt, langt væk..."
Hvad sker der bag kulisserne?
Hvis du spørger, hvordan vi laver kurser, og hvor det hele begynder, vil jeg svare enkelt: "Alt starter med en idé."
Normalt kommer idéen fra et eller andet sted - vi sidder ikke fastlåst i kæder i kælderen, indtil vi finder på: 'Hvilket emne skal vi lave kursus i?'. Idéer kommer af sig selv fra eksterne kilder. Nogle gange begynder folk at spørge aktivt: "Hvad ved I om denne bestemte teknologi?". Eller som med Docker, der ikke kunne blive plads til i intensivens tidsramme - det var tydeligt, at det måtte tages uden for, for at der kunne fortælles noget inden for rammerne af intensivforløbet.
Det er præcis sådan, idéen opstår.
Efter at idéen er dukkede op, begynder, efter min mening, det sværeste øjeblik - overhovedet at forstå, hvad der skal inkluderes i dette kursus - det er meget sammenligneligt med, hvordan talere forberedes til forskellige konferencer.
Der er én hovedsvaghed, når man har valgt et emne og tænker: „Hvad skal jeg fortælle om det? Dette er for simpelt, det er åbenlyst, det ved alle også."
Men i virkeligheden er det slet ikke sådan. Jeg har personligt talt mange steder om, at det, der virker åbenlyst for dig, ikke nødvendigvis er det for dem, der kommer for at lytte til dig eller tage kurset. Her opstår der et stort arbejde og interne konflikter om, hvad der skal inkluderes i kurset. Resultatet er en liste over kapitler med nogle brede penselstræk om, hvad kurset vil handle om.
Og så begynder det enkle rutinearbejde:
- Udvælgelse af materiale
- Omhyggelig læsning af dokumentationen for den aktuelle version, da IT-verdenen udvikler sig med ufattelige hastigheder. Selv hvis du arbejder med noget og laver et kursus omkring det, skal du ind i dokumentationen og se, hvad der er nyt, hvad der er interessant at fortælle om, og hvad der kan være særligt nyttigt at nævne.
- Og der opstår en form for skelet til kurset, hvor størstedelen af emnerne generelt er beskrevet, og det ser ud til, at det bare er at optage videoer og sætte dem i produktion.
- Men i virkeligheden er det ikke sådan; det er her, det hårde arbejde begynder, men allerede ikke for kursusforfatterne, men for dem, der tester. Normalt fungerer teknisk support som alpha-testere, som for det første gennemgår kurserne for grammatiske og syntaktiske fejl. For det andet slår de os hårdt og klager, når der er nogle helt uventede, uforståelige steder. Når der opstår komplekse sætninger, der strækker sig over flere sider, eller åbenlyst nonsens. De gennemgår alt dette og holder øje med det.
- Så begynder testfasen, hvor også nogle åbenlyse ikke-fungerende ting bliver fanget og visse punkter bliver påpeget, som kan gøres mere komplekse, da det bliver mindre interessant at sidde og bare kopiere — og der bliver identificeret steder, hvor vi har meget høje forventninger til dem, der skal gennemføre dette kursus. Og så kommer anbefalingerne: „Gør det, venner, her lidt enklere; det vil være lettere at forstå, og der vil være større nytte af det."
- Når dette arbejde er udført, er den del, der vedrører videoen, skrevet, og det ser ud til at være i orden. Vi kan snart sende det til offentliggørelse og reklamere for dette kursus. Men igen, vi er ikke helt klar – da vi på det seneste er blevet lidt mere skeptiske over for os selv og er begyndt at arbejde mere med feedback. Der er opstået noget, der hedder beta-testning – det er, når vi inviterer helt uafhængige personer, som ikke har noget at gøre med vores virksomhed, til at se hele kurset, videoer, tekster og praktiske opgaver for at vurdere kvaliteten af materialet, tilgængeligheden af materialet og hjælpe os med at gøre kurset så godt som muligt.
- Og når flere sådanne iterationer, med talere, alpha-testning i form af teknisk support, beta-testning, og forbedringer er gennemgået, så begynder alt forfra – teknisk support, beta-testning, forbedringer.
- Og på et bestemt tidspunkt kommer erkendelsen, at enten stopper vi med forbedringerne, fordi det er helt urealistisk at gøre det på en måde, der tilfredsstiller alle, eller der træffes nogle drastiske beslutninger. Når mange bemærkninger om specifikke dele er kritiske – kræver de globale ændringer, fordi noget gik galt.
- Derefter kommer tiden til mindre justeringer – hvor et eller andet forslag ikke er særlig pænt formuleret, og et eller andet ikke har den ønskede skrifttype, 14,5, men man ville helst have 15,7.
- Når der kun er sådanne bemærkninger tilbage, så er kurset mere eller mindre klar, og de officielle salg kan begynde.
Og ved første øjekast ser det ud til at være en kort og enkel opgave at lave et kursus, men det viser sig at være alt andet end enkelt og tager en utrolig mængde tid.
Og der er også et vigtigt punkt, at arbejdet med kurset ikke slutter, når kurset er udgivet. For det første læser vi omhyggeligt de kommentarer, der efterlades til de forskellige dele. Og selv med alle de kræfter, vi har lagt i det, opdages der stadig nogle fejl og mangler, som løbende rettes og forbedres, så hver efterfølgende bruger får en bedre service.
Hver kursus har sin egen produkt ejer, som udover at definere den overordnede koncept, også kontrollerer tidsrammerne. Han laver noter i margen, så når tiden kommer til fuldstændigt at genoptage kurset - og det vil helt sikkert komme, for om to år, måske endda et år, vil dele af det, vi fortæller, blive forældet, simpelthen fordi det vil være moralsk forældet. Produkt ejeren noterer ofte, hvad folk spørger om, hvilke punkter der var uklare, hvilke opgaver der virkede meget svære, og hvilke der omvendt virkede meget enkle. Og alt dette tages i betragtning ved genoptagelsen af kurset, ved en eller anden form for refactoring, så hver global iteration af kurset bliver bedre, mere bekvemt og komfortabelt.
Sådan opstår kurser.
Hvordan kurset om Docker blev til
Dette er et separat og endda usædvanligt emne for os. For på den ene side planlagde vi ikke at lave det, fordi mange online-skoler tilbyder det. På den anden side bad det om at blive frigivet og fik en logisk plads i vores koncept for uddannelse af IT-specialister i Kubernetes.
Hvis vi taler meget generelt, så startede det hele oprindeligt med kurset om Kubernetes, da det lige var begyndt, tror jeg, efter den første Slyrm. Vi indsamlede feedback og så, at mange ønskede at læse mere om Docker, og at mange kom på det grundlæggende kursus i Kubernetes uden at vide, hvad det var. .
Så til den anden Slyrm lavede vi et kursus - mere specifikt ikke et kursus, men vi lavede et par kapitler om Docker. Hvor vi fortalte om nogle af de mest grundlæggende ting, så folk, der deltager i intensiven, ikke følte sig udeladt og overhovedet forstod, hvad der skete.
Og så udviklede begivenhederne sig, cirka sådan. Mængden af materiale voksede og kunne ikke længere være plads til på 3 dage. Og en logisk og åbenlys idé kom op: hvorfor ikke lave noget ud af det, vi fortæller på Slyrm Basis, til et sådant lille kursus, som vi kunne sende folk til, der vil se noget om Docker før intensiven i Kubernetes.
Slyrm Junior er reelt en samling af flere sådanne grundlæggende kurser. Derfor blev kurset om Docker en del af Slyrm Junior. Det vil sige, det er en slags nultrins for og . Og så var der virkelig helt grundlæggende abstraktioner.
På et tidspunkt begyndte folk at spørge: "Hey, det er alt sammen fint, men hvor kan jeg læse mere om, hvad Docker kan, hvordan man arbejder med det, og hvad det egentlig er?". Så kom ideen om at lave det til en , så vi dels kunne henvise folk, der kommer til Slurm om Kubernetes, men også for dem, der ikke er interesseret i Kubernetes på nuværende tidspunkt. Så IT-specialister kan komme for at se vores kursus om Docker og starte deres evolutionære rejse lige fra ren Docker. Vi ønsker at have et sådant fuldgyldigt kursus — og mange vil derefter, efter at have set dette kursus og arbejdet et stykke tid med ren Docker, vokse til det niveau, hvor de har brug for Kubernetes eller et andet orkestreringssystem. Og de kommer faktisk til os.
Nogle gange stilles spørgsmålet: "Hvilke mennesker har ikke brug for Kubernetes lige nu?" Men det spørgsmål handler ikke om mennesker, det handler mere om virksomheder. Her skal man forstå, at Kubernetes har bestemte tilfælde, hvor det passer godt og opgaver, som det løser effektivt, men der er også scenarier, hvor Kubernetes skaber flere problemer og ekstra besvær. Derfor afhænger det ikke så meget af folk, men af, hvad virksomhederne udvikler, og hvordan de gør det.
For eksempel, hvis der er en forfærdelig monolitisk Legacy — så er det sandsynligvis ikke værd at presse det ind i Kubernetes, fordi det vil skabe flere problemer end fordele. Eller hvis det er et lille projekt — med små belastninger eller generelt ikke meget penge og ressourcer. Så giver det ingen mening at trække det ind i Kubernetes.
Og generelt, som mange allerede har sagt, hvis du spørger dig selv: "Har jeg brug for Kubernetes?", så har du sandsynligvis ikke brug for det. Jeg kan ikke huske, hvem der fandt på det først, måske var det Pasha Selivanov. Jeg er 100 % enig i det. Man skal vokse til Kubernetes — og når man så har forståelsen af, at man netop har brug for Kubernetes, og at det kan hjælpe med at løse visse spørgsmål, så er det nok meningsfuldt at gå hen og lære, hvordan man konkret konfigurerer det godt, så overgangen til Kubernetes ikke bliver for smertefuld.
Der er nogle børnesygdomme og nogle ret simple ting, og endda ikke så enkle, som man kan finde ud af hos os, i stedet for at gå gennem sine egne forhindringer og smerter.
Mange virksomheder har først haft en simpel infrastruktur uden containerisering. Derefter, da det begyndte at blive svært at administrere alt dette, gik de over til Docker, og på et tidspunkt voksede de sig til det punkt, hvor det, som Docker tilbyder, blev for begrænsende. De begyndte at se på, hvad der er derude, hvilke systemer der løser disse problemer, og specielt Kubernetes – det er et af de systemer, der tillader at løse problemer, når man i ren Docker begynder at føle sig trængt og mangler funktionalitet. Det er virkelig et godt eksempel, hvor folk går trinvis opad fra bunden og forstår, at denne teknologi ikke er tilstrækkelig, og de går videre til det næste niveau. De har brugt noget, det blev igen for lidt – og de går videre.
Dette er et bevidst valg - og det er rigtig godt.
Jeg ser generelt, at vores system bliver meget smukt opbygget, for eksempel, , selv ved videokurser. Derefter efter Docker kommer , derefter , derefter . Det hele hænger logisk sammen - en person gennemgår det, og det bliver til en hel profession.
I princippet giver kursusudvalget mulighed for at dække mange moderne cases. Der er stadig områder, der forbliver grå zoner, og jeg håber, at vi snart vil lave nogle kurser, der kan dække disse grå områder, især om sikkerhed. Fordi det bliver meget aktuelt.
Kort sagt har vi nogle grå områder, som ville være rigtig gode at dække, så det ville være et helt klart billede - og folk kunne komme og forstå, ligesom Kubernetes repræsenterer et Lego-sæt, hvor man kan samle forskellige ting, hvis der stadig mangler noget - så også ved vores kurser, så folk kan forstå, hvad de har brug for, samle et puslespil, et konstruktionssæt fra vores kurser.
Hvis man stiller sig selv det rigtige og ærlige spørgsmål: "Hvem har nu brug for et aktivt Docker-kursus?", så:
- Studerende, der lige begynder at forstå.
- Medarbejdere i testafdelingen.
- Der er faktisk mange virksomheder, hvor man stadig ikke bare ikke bruger Docker, men hvor ingen har hørt om teknologien overhovedet og ikke ved, hvordan man bruger den. Jeg kender faktisk flere store virksomheder i Sankt Petersborg, der har arbejdet med udvikling i mange år, og de er stadig fastlåst i gamle teknologier. For sådanne virksomheder, for ingeniører i disse firmaer, kan dette kursus være meget interessant, da det i første omgang vil gøre det muligt hurtigt at dykke ned i teknologien, og for det andet, så snart der er nogle ingeniører, der forstår, hvordan det hele fungerer, kan de bringe det ind i virksomheden og internt udvikle denne kultur og disse retninger.
- Efter min mening kan dette kursus også være nyttigt for dem, der allerede har arbejdet lidt med Docker, men kun i begrænset omfang og mere i stil med 'gør det én gang, gør det to gange' — og nu planlægger de at interagere med Kubernetes, hvilket pålægger dem visse forpligtelser. Hvis de kun har overfladisk viden om, hvad Docker er, hvordan man kører det, men ikke ved, hvordan det fungerer indeni, eller hvad man bedst skal gøre med det, og hvad man skal undgå, så vil dette kursus være godt til at systematisere og uddybe deres viden.
Men hvis dit kendskab er på niveauet: 'Jeg ved ikke, hvordan man korrekt skriver Docker-filer, jeg har en ide om, hvad namespaces er, hvordan containere fungerer, og hvordan de faktisk er implementeret på operativsystemniveau' — så giver det bestemt ikke mening at komme til os, du vil ikke lære noget nyt, og det vil være lidt trist at have brugt penge og tid.
Hvis vi skal formulere, hvilke fordele vores kursus har, så:
- har vi forsøgt at gøre dette kursus med et tilstrækkeligt antal praktiske tilfælde, som ikke kun vil hjælpe dig med at forstå den teoretiske del, der findes, men også forstå, hvorfor dette er vigtigt for dig, og hvordan du vil bruge det fremover;
- Der er nogle sektioner, som sjældent findes andre steder — der er generelt ikke meget materiale om dem. De handler om interaktionen mellem Docker og operativsystemet, dog ikke helt på den måde. Hvilke mekanismer Docker har taget fra operativsystemet for at implementere containerisering — og dette giver en dybere forståelse af hele spørgsmålet om lancering af containere inden for operativsystemet Linux. Hvordan det fungerer, hvordan det interagerer indbyrdes inden for operativsystemet, udenfor og så videre.
Dette er en dybdegående analyse, der sjældent ses, og det er efter min mening meget vigtigt. Hvis du vil forstå en hvilken som helst teknologi ordentligt og vide, hvad du kan forvente af den, bør du have en generel forståelse af, hvordan den fungerer på lavt niveau.
Vores kursus viser og forklarer, hvordan det fungerer fra operativsystemets perspektiv. På den ene side bruger alle containeriseringssystemer de samme mekanismer fra operativsystemet. På den anden side anvender de de eksisterende funktioner i Linux, som Docker. Andre containeriseringssystemer har ikke opfundet noget nyt — de har hentet, hvad der allerede findes i Linux, og skrevet en praktisk wrapper, der gør det muligt hurtigt at kalde, starte eller interagere med det. Selve Docker er ikke et stort mellemled mellem operativsystemet og kommandolinjen; det er et værktøj, der gør det muligt at undgå at skrive tonsvis af kommandoer eller noget C-kode for at oprette en container, og i stedet gøre det ved at indtaste et par linjer i terminalen.
Og desuden, hvis vi taler specifikt om Docker, så er det, hvad Docker reelt har bidraget med til IT-verdenen — standarder. Hvordan en applikation skal startes, hvordan den skal fungere, hvilke krav der er til logs, hvilke krav der er til skalering og konfiguration af selve applikationen.
I høj grad handler Docker om standarder.
Standarderne overføres også til Kubernetes — og de samme standarder gælder; hvis du kan starte din applikation godt i Docker, vil den sandsynligvis også fungere godt inden for Kubernetes 99% af tiden.
Hvis du er interesseret i, hvordan kurset Docker blev skabt, samt andre kurser, og også er nysgerrig efter selve kurset fra et praktisk synspunkt, så
Vi vil være glade for at se dig!
Kilde: habr.com
