En deltager kommer til et kursus eller intensivt kursus. Han ser ordnede rækker af teknisk support, sirligt trukket strømkabler, et skakternet layout af foredragssalen, lyse billeder og diasdiagrammer. Højttalere med vittigheder og smil giver information ud på en sådan måde, at du lige har tid til at forstå det. Standene er sat op, øvelsesopgaver flyver simpelthen af fingrene, bortset fra at man nogle gange har brug for hjælp fra teknisk personale. support.
Og også kaffepauser med ligesindede, en munter og energisk atmosfære, udveksling af erfaringer, de mest uventede spørgsmål til oplægsholdere. Både svar og information, som du ikke finder i manualer, men kun i praksis.
Hvor meget tid, kræfter og nerver tror du, det tog at få det til at se præcis sådan ud?
Tak til Volodya Guryanov, en certificeret Kubernetes-administrator og ingeniør/teamleder hos Southbridge, som har været vidne til og aktivt deltaget i oprettelsen af mange Slurm-kurser lige fra begyndelsen.
Han så underlivet naturligvis skabelsen – kompleksiteter og tornede river, indsigter og uventede løsninger. Og de allerede velkendte Kubernetes-intensiver, såsom Slurm Basic og Slurm Mega. Og et nyt, stort set revideret kursus , som ubønhørligt nærmer sig og begynder den 19. august.
Men måske nok af teksterne, lad os gå videre til selve historien. Hvordan fra et par intensive emner en fuldstændig selvforsynende og mangefacetteret . Så jeg starter historien om, hvordan kurser skabes og udvikles - ligesom "For lang tid siden i en galakse langt, langt væk..."
Hvad er der bag kulisserne?
Hvis du spørger, hvordan vi laver kurser, og hvor det hele begynder, vil jeg blot svare "Det hele starter med en idé."
Normalt kommer ideen et sted fra - vi sidder ikke i håndjern i kælderen, før vi kommer med: "Hvilket emne skal vi lave et kursus om?" Idéer kommer fra et sted alene fra eksterne kilder. Nogle gange begynder folk aktivt at spørge: "Hvad ved du om sådan og sådan en specifik teknologi?" Eller hvordan det var med Docker, at det var umuligt at passe ham ind i timingen for intensivkurset – han skulle åbenbart tages udenfor for at kunne nå at fortælle noget under intensivkurset.
Sådan fremstår en idé.
Efter at det blev annonceret, begynder efter min mening det sværeste øjeblik - generelt at forstå, hvad der skal inkluderes i dette kursus - dette er meget sammenligneligt med, hvordan oplægsholdere er forberedt til enhver konference.
Der er én hovedpine, når du ser ud til at have valgt et emne og tænker: "Hvad kan jeg fortælle om det? Det er for simpelt, det er indlysende, det ved alle også."
Men faktisk er det slet ikke tilfældet. Og jeg siger personligt mange steder, at det, der virker indlysende for dig, for dem, der kommer for at lytte til dig eller tage et kursus, slet ikke er oplagt. Og her opstår så stort et lag af arbejde og intern konflikt, om hvad man skal have med i forløbet. Som et resultat får vi sådan en liste over kapitler med så fejende store streger, hvad kurset kommer til at handle om.
Og så begynder det simple rutinearbejde:
- Materialevalg
- Læs omhyggeligt dokumentationen til den aktuelle version, da IT-verdenen nu udvikler sig med en slags kosmisk hastighed. Selvom du arbejder med noget og laver et kursus om det, skal du gå til dokumentationen og se, hvad der er nyt der, hvad der er interessant at tale om, hvad der kan være særligt nyttigt at nævne.
- Og et bestemt skelet af kurset dukker op, hvor de fleste af emnerne generelt er allerede dækket, og det ser ud til, at uanset hvad der er - optag videoer og start dem i produktion.
- Men faktisk nej, så begynder det hårde arbejde, men ikke for forfatterne af kurset, men for dem, der tester. Normalt er vores alfa-testere teknisk support, som for det første korrekturlæser kurserne for eventuelle syntaktiske og grammatiske fejl. For det andet slår de os smerteligt med stokke og bander, når der er nogle helt uoplagte, uforståelige steder. Når nogle komplekst sammensatte underordnede sætninger på et par sider eller åbenlyst nonsens dukker op i teksterne. De læser det hele, hold øje med det.
- Derefter starter øvelsestestfasen, hvor der også fanges nogle tydelige ikke-fungerende ting, og der vises nogle øjeblikke, som enten kan gøres sværere, da det ikke bliver særlig interessant - bare at sidde og kopiere - og steder identificeres, hvor det er meget svært, og vi har meget at gøre, vi ønsker fra folk, der vil tage dette kursus. Og så kommer anbefalingerne: "Gunner, gør det nemmere her, det bliver lettere at opfatte, og der vil være mere udbytte af det."
- Efter denne mængde arbejde er udført, er den del, der vedrører videoen, skrevet, alt ser ud til at være i orden. Og du kan allerede donere det til produktion, for at reklamere for dette kursus. Men igen, nej, det er for tidligt - for på det seneste er vi holdt op med at stole lidt på os selv og er i princippet begyndt at arbejde mere med feedback. Der er sådan noget som beta-test - det er når folk inviteres fra udenforstående, der ikke er forbundet med vores virksomhed på nogen måde, og for nogle lækkerier bliver de vist alle dele af kurset, videoer, tekst, praktiske opgaver, så de vurderet kvaliteten af materialet, tilgængeligheden af materialet og hjulpet os med at gøre kurset så godt som muligt.
- Og når flere sådanne iterationer går igennem, højttalere, alfa-test i form af teknisk support, beta-test, forbedringer. Og så starter alt forfra - teknisk support, betatestning, forbedringer.
- Og på et eller andet tidspunkt kommer forståelsen af, at enten er vi færdige med modifikationer, fordi det er fuldstændig urealistisk at sikre sig, at alle kan lide det, eller også bliver der taget nogle drastiske beslutninger. Når mange kommentarer på bestemte steder er kritiske, så gentag dem globalt, fordi noget gik galt.
- Så kommer tiden til mindre redigeringer - et eller andet sted er sætningen ikke formuleret særlig pænt, et eller andet sted kan nogen ikke lide skrifttypen, 14,5, men gerne vil have 15,7.
- Når denne type kommentarer forbliver, så er det det, kurset åbner mere eller mindre, det officielle salg begynder.
Og ved første øjekast viser den korte og enkle opgave at lave et kursus sig slet ikke at være enkel og tager utrolig lang tid.
Og der er en anden vigtig pointe, at arbejdet med forløbet ikke slutter, når forløbet frigives. For det første læser vi omhyggeligt de kommentarer, der er tilbage på visse dele. Og selv på trods af alle de anstrengelser, vi har gjort, er nogle mangler stadig identificeret, nogle fejl bliver rettet og forbedret undervejs, i realtid, så hver efterfølgende bruger får en bedre service.
Hvert kursus har sin egen produktejer, som udover at definere det generelle koncept, tjekker deadlines, noterer han i margenen, at når tiden er inde til helt at omskrive kurset, og det kommer helt sikkert, for om to år, eller endda et år senere, vil noget af det, vi fortæller, blive irrelevant, blot fordi det bliver moralsk forældet. Produktejeren noterer i margenen, at folk oftest spørger, hvilke punkter der var uklare, hvilke opgaver der virkede meget svære, og hvilke virkede tværtimod meget enkle. Og alt dette tages i betragtning, når kurset genoptages under en form for refactoring, så hver iteration af det globale kursus bliver bedre, mere bekvemt og behageligt.
Sådan fremstår kurser.
Hvordan Docker-kurset blev født
Dette er et særskilt og endda usædvanligt emne for os. For på den ene side havde vi ikke tænkt os at gøre det, fordi mange netskoler tilbyder det. Til gengæld bad han selv om frihed og fandt en logisk plads i vores koncept med at uddanne it-specialister i Kubernetes.
Når vi taler meget globalt, startede det i første omgang med et kursus om Kubernetes, da det efter min mening lige startede efter den første slurm. Vi indsamlede feedback og så, at mange gerne vil læse noget ekstra om Docker et andet sted, og generelt kommer mange til grundkurset på Kubernetes uden at vide, hvad det er. .
Derfor lavede de til den anden Slurm et kursus - eller rettere sagt, ikke engang et kursus, men lavede et par kapitler om Dockers. Hvor de fortalte noget af det mest basale, så folk, der kommer på intensiven, ikke ville føle sig frataget og generelt ville forstå, hvad der skete.
Og så udviklede begivenhederne sig nogenlunde sådan her. Mængden af materiale voksede og holdt op med at passe på 3 dage. Og en logisk og indlysende idé dukkede op: hvorfor ikke forvandle det, vi dækker på Slurm Basic, til en slags lille kursus, hvortil man kunne sende folk, der gerne vil se noget om Docker, før de tager et intensivt kursus i Kubernetes.
Slurm Junior er i virkeligheden en kombination af flere sådanne grundforløb. Som et resultat blev Docker-kurset et stykke Slurm Junior. Det vil sige, at dette er sådan et nultrin før и . Og så var der bare helt basale abstraktioner.
På et tidspunkt begyndte folk at spørge: ”Drenge, det her er fantastisk, det her er nok til at forstå, hvad I snakker om på de intensive kurser. Hvor kan jeg læse mere detaljeret om, hvad docker kan, og hvordan man arbejder med det, og hvad det er?” Så ideen kom op at gøre det lige , så for det første kan folk, der kommer til Slurm ved hjælp af Kubernetes, stadig sendes til det, og på den anden side for dem, der ikke engang er interesseret i Kubernetes på dette udviklingstrin. Så en it-specialist kan komme og se vores kursus om Docker og starte sin evolutionære vej ganske enkelt med ren Docker. Så vi har sådan et fuldgyldigt, komplet kursus - og så er mange, der har set dette kursus, efter at have arbejdet i nogen tid med ren Docker, vokset til det niveau, hvor de har brug for Kubernetes eller et andet orkestreringssystem. Og de kom især til os.
Nogle gange stilles spørgsmålet: "Hvilken slags mennesker har måske ikke brug for Kubernetes nu?" Men dette spørgsmål handler ikke om mennesker, det er snarere et spørgsmål om virksomheder. Her skal du forstå, at Kubernetes har visse tilfælde, hvor det er velegnet og opgaver, som det løser godt, men tværtimod er der nogle scenarier for at bruge Kubernetes, når det forårsager yderligere smerte og yderligere lidelse. Derfor afhænger det ikke engang af mennesker, men af hvilke virksomheder, der har udviklet sig og hvor længe.
For eksempel en forfærdelig Legacy-monolit - du skal nok ikke skubbe den ind i Kubernetes, fordi den vil forårsage flere problemer end fordele. Eller hvis det for eksempel er et lille projekt, har det en lille belastning eller i princippet ikke mange penge og ressourcer. Det nytter ikke at trække det ind i Kubernetes.
Og generelt, sandsynligvis generelt, som mange mennesker allerede har sagt, hvis du stiller spørgsmålet: "Har jeg brug for Kubernetes?", så har du højst sandsynligt ikke brug for det. Jeg kan ikke huske, hvem der først fandt på det, efter min mening, Pasha Selivanov. Det er jeg 100% enig i. Og du skal vokse op til Kubernetes - og når det allerede står klart, at jeg har brug for Kubernetes, og vores virksomhed har brug for det, og det vil hjælpe med at løse sådanne og sådanne problemer, så giver det nok mening at gå og lære og finde ud af, hvordan man præcist skal indstille det op godt, så processen med at skifte til Kubernetes er ikke særlig smertefuld.
Nogle børns lidelser og nogle simple ting, og endda ikke helt simple, kan man især finde ud af hos os, og ikke gå igennem din egen rive og smerte.
Mange virksomheder er gået præcis den vej, at der først bare var en form for infrastruktur uden containerisering. Så kom de til det punkt, hvor det blev svært at styre det hele, de skiftede til Docker og på et tidspunkt voksede de til det punkt, hvor det blev trangt inden for rammerne af Docker og hvad det tilbyder. Og de begyndte at se på, hvad der var omkring, hvilke systemer der løser disse problemer, og i særdeleshed Kubernetes - dette er et af de systemer, der giver dig mulighed for at løse problemer, når ren Docker bliver overfyldt og mangler funktionalitet, dette er en rigtig god sag, når folk De går trin for trin nedefra og op, forstår, at denne teknologi ikke er nok og bevæger sig til næste niveau. De brugte noget, det blev knapt igen, og de kom videre.
Dette er et bevidst valg - og det er meget fedt.
Generelt ser jeg, at vores system er meget smukt bygget, f.eks. , selv gennem videokurser. Så efter docker går det , så , så . Alt stiller sig logisk – en person består og et solidt erhverv opstår.
I princippet giver sættet af kurser dig mulighed for at dække en masse sager, også moderne. Der er stadig områder, der forbliver en gråzone, jeg håber, at vi snart vil lave nogle kurser, der giver os mulighed for at lukke disse gråzoner, især vil vi finde på noget om sikkerhed. For det er ved at blive meget relevant.
Kort sagt har vi nogle gråzoner, som det ville være meget rart at lukke, så det bliver et komplet, komplet billede - og der kunne komme folk, og ligesom Kubernetes selv er som en Lego-konstruktør, kan man lave forskellige ting fra det indsamler, hvis der stadig ikke er nok - supplere, det samme med vores kurser, så folk kan forstå, hvad de har brug for af dette, de skal samle et slags puslespil, et slags byggesæt fra vores kurser.
Hvis du stiller dig selv et generelt korrekt og ærligt spørgsmål: "Hvem kunne bruge et aktivt Docker-kursus nu?", så:
- For elever, der lige er begyndt at sætte sig ind i det.
- Testafdelingens medarbejdere.
- Faktisk er der mange virksomheder, der stadig ikke kun ikke bruger Docker, men ingen har hørt om sådan teknologi og i princippet ikke ved, hvordan man bruger den. Og jeg kender flere store virksomheder i St. Petersborg, der har udviklet sig i mange år, og de brugte nogle gamle teknologier, de bevæger sig i denne retning. Især for sådanne virksomheder, for ingeniører i sådanne virksomheder kan dette kursus være meget interessant, da det for det første giver dig mulighed for hurtigt at fordybe dig i denne teknologi, og for det andet, så snart flere ingeniører dukker op, som forstår, hvordan det hele fungerer, kan de bringe det til virksomheden og udvikle denne kultur og disse retninger i virksomheden.
- Efter min mening kan dette kursus stadig være nyttigt for dem, der allerede har arbejdet med docker, men meget lidt og mere i "gør én gang, gør to gange"-stilen - og nu vil de på en eller anden måde interagere med de samme Kubernetes, og dette pålægger dem visse forpligtelser, hvis man har meget overfladisk viden om hvad docker er, hvordan man kører det, men samtidig ved man ikke hvordan det fungerer indefra, ved man ikke hvad der er bedst at gøre med det og hvad er bedre ikke at gøre, Så er dette kursus velegnet til at systematisere og uddybe viden.
Men hvis du har viden på niveau med: "Jeg ved ikke, hvordan man skriver de samme Docker-filer korrekt, jeg kan forestille mig, hvad navneområder er, hvordan containere fungerer, hvordan de faktisk implementeres på operativsystemniveau" - så er der bestemt ingen mening i at gå til os, du lærer ikke noget nyt, og du vil være lidt ked af de penge og den tid, du bruger.
Hvis vi formulerer, hvilke fordele vores kursus har, så:
- Vi forsøgte at lave dette kursus med et tilstrækkeligt antal praktiske cases, der giver dig mulighed for ikke kun at forstå den teoretiske del, der eksisterer, men også at forstå, hvorfor du har brug for det, og hvordan du vil bruge det i fremtiden;
- der er flere sektioner, der meget sjældent findes nogen steder - og generelt er der ikke så meget materiale om dem. De relaterer til Dockers interaktion med operativsystemet, endda lidt anderledes. Hvilke mekanismer tog Docker fra operativsystemet for at implementere containeriseringssystemet - og dette giver en så dybere forståelse af hele spørgsmålet om at køre containere i Linux-operativsystemet. Hvordan det fungerer, hvordan det interagerer med hinanden inde i operativsystemet, udenfor og så videre.
Dette er så virkelig et dybt blik, at det sker ret sjældent, og samtidig er det efter min mening meget vigtigt. Hvis du vil forstå enhver teknologi godt og forstå, hvad du kan forvente af den, skal du i det mindste have en generel idé om, hvordan den fungerer på et lavt niveau.
Vores kursus viser og fortæller, hvordan dette fungerer set fra styresystemets synspunkt. På den ene side bruger alle containeriseringssystemer de samme operativsystemmekanismer. På den anden side tager de, hvad der er i Linux-operativsystemet, som docker. Andre containeriseringssystemer kom ikke med noget nyt - de tog det, der allerede var i Linux og skrev bare en praktisk indpakning, der giver dig mulighed for hurtigt at kalde det, køre det eller på en eller anden måde interagere med det. Den samme Docker er ikke et meget stort lag mellem operativsystemet og kommandolinjen, det er en slags værktøj, der tillader dig ikke at skrive kilotons af kommandoer eller en slags C-kode for at oprette en container, men at gøre dette ved at indtaste et par linjer i terminalen.
Og en ting mere, hvis vi taler specifikt om Docker, hvad Docker virkelig bragte til IT-verdenen er standarder. Hvordan skal applikationen startes, hvordan skal den fungere, hvad er kravene til logs, hvad er kravene til skalering, konfiguration af selve applikationen.
På mange måder handler docker om standarder.
Standarder flytter også til Kubernetes - og der er nøjagtig de samme standarder; hvis du ved, hvordan du kører din applikation godt i Docker, så vil det 99% af tiden fungere lige så godt i Kubernetes.
Hvis du ikke kun var interesseret i, hvordan Docker-kurset blev oprettet, men også i andre kurser, men også interesseret i selve kurset fra et praktisk synspunkt, så
Vi vil være glade for at se dig!
Kilde: www.habr.com