En deltaker kommer på kurs eller intensivkurs. Han ser ordnede rekker med teknisk støtte, pent trukket strømkabler, sjakkbrettoppsett av forelesningssalen, lyse bilder og lysbildediagrammer. Høyttalere med vitser og smil gir ut informasjon på en slik måte at du bare har tid til å forstå den. Standene er satt opp, øvingsoppgaver flyr rett og slett av fingrene, bortsett fra at noen ganger trenger man hjelp fra teknisk personell. Brukerstøtte.
Og også kaffepauser med likesinnede, en munter og energisk atmosfære, erfaringsutveksling, de mest uventede spørsmålene til foredragsholdere. Både svar og informasjon som du ikke finner i manualer, men bare i praksis.
Hvor mye tid, krefter og nerver tror du det tok å få det til å se akkurat slik ut?
Takk til Volodya Guryanov, en sertifisert Kubernetes-administrator og ingeniør/teamleder ved Southbridge, som har vært vitne til og aktivt deltatt i opprettelsen av mange Slurm-kurs helt fra begynnelsen.
Han så underlivet selvfølgelig skapelsen - kompleksiteter og tornete raker, innsikt og uventede løsninger. Og de allerede kjente Kubernetes-intensivene, som Slurm Basic og Slurm Mega. Og et nytt, stort sett revidert kurs , som ubønnhørlig nærmer seg og vil begynne 19. august.
Men, kanskje, nok av tekstene, la oss gå videre til selve historien. Hvordan fra et par intensive emner en helt selvforsynt og mangefasettert . Så jeg starter historien om hvordan kurs skapes og utvikles - akkurat som "For lenge siden i en galakse langt, langt borte ..."
Hva er bak kulissene?
Hvis du spør hvordan vi lager kurs og hvor det hele begynner, vil jeg ganske enkelt svare "Det hele starter med en idé."
Vanligvis kommer ideen fra et sted - vi sitter ikke i håndjern i kjelleren før vi kommer på: "Hvilket tema skal vi lage et kurs om?" Ideer kommer fra et sted på egen hånd fra eksterne kilder. Noen ganger begynner folk aktivt å spørre: "Hva vet du om slik og en slik spesifikk teknologi?" Eller hvordan det var med Docker at det var umulig å passe ham inn i timingen for intensivkurset – han måtte selvsagt tas ut for å få tid til å fortelle noe under intensivkurset.
Slik fremstår en idé.
Etter at det ble annonsert, begynner etter min mening det vanskeligste øyeblikket - å generelt forstå hva som skal inkluderes i dette kurset - dette er veldig sammenlignbart med hvordan foredragsholdere er forberedt på eventuelle konferanser.
Det er én hovedpine når du ser ut til å ha valgt et tema og tenker: «Hva kan jeg fortelle om det? Dette er for enkelt, dette er åpenbart, alle vet dette også.»
Men faktisk er dette ikke tilfelle i det hele tatt. Og jeg personlig sier mange steder at det som virker opplagt for deg, for de som kommer for å høre på deg eller går på kurs, slett ikke er opplagt. Og her oppstår et så stort lag med arbeid og intern konflikt, om hva som skal inkluderes i kurset. Som et resultat får vi en slik liste over kapitler med så feiende store slag, hva kurset skal handle om.
Og så begynner det enkle rutinearbeidet:
- Valg av materiale
- Les nøye dokumentasjonen for gjeldende versjon, siden IT-verdenen nå utvikler seg i en slags kosmisk hastighet. Selv om du jobber med noe og lager et kurs om det, må du gå til dokumentasjonen og se hva som er nytt der, hva som er interessant å snakke om, hva som kan være spesielt nyttig å nevne.
- Og et visst skjelett av kurset dukker opp, der de fleste av emnene generelt er allerede dekket, og det ser ut til at uansett hva som er der - ta opp videoer og sett dem i produksjon.
- Men faktisk, nei, da begynner det harde arbeidet, men ikke for forfatterne av kurset, men for de som tester. Vanligvis er alfa-testerne våre teknisk støtte, som for det første korrekturleser kursene for eventuelle syntaktiske og grammatiske feil. For det andre slår de oss smertefullt med pinner og banner når det er noen helt uopplagte, uforståelige steder. Når det dukker opp noen komplekst sammensatte underordnede setninger på et par sider eller åpenbart tull i tekstene. De leser alt, se etter det.
- Deretter starter øvingsteststadiet, hvor det også fanges opp noen åpenbare ting som ikke fungerer og det vises noen punkter som enten kan gjøres vanskeligere, siden det blir lite interessant - bare å sitte og kopiere - og steder identifiseres hvor det er veldig vanskelig og vi har mye å gjøre vi ønsker av folk som skal ta dette kurset. Og så kommer anbefalinger: "Gutter, gjør det enklere her, det vil være lettere å oppfatte og det vil være mer utbytte av det."
- Etter at denne mengden arbeid er gjort, er delen som er relatert til videoen skrevet, alt ser ut til å være i orden. Og du kan allerede donere det til produksjon, for å annonsere for dette kurset. Men igjen, nei, det er for tidlig - for nylig har vi sluttet å stole litt på oss selv og har i prinsippet begynt å jobbe mer med tilbakemeldinger. Det er noe slikt som beta-testing - dette er når folk inviteres fra utenforstående, som ikke er knyttet til selskapet vårt på noen måte, og for noen godbiter blir de vist alle deler av kurset, videoer, tekst, praktiske oppgaver, slik at de vurdere kvaliteten på materialet, tilgjengeligheten til materialet og hjalp oss med å gjøre kurset så bra som mulig.
- Og når flere slike iterasjoner går gjennom, høyttalere, alfa-testing i form av teknisk support, betatesting, forbedringer. Og så begynner alt på nytt - teknisk støtte, betatesting, forbedringer.
- Og på et visst tidspunkt kommer forståelsen at enten er vi ferdige med modifikasjoner, fordi det er helt urealistisk å sørge for at alle liker det, eller så blir det tatt noen drastiske beslutninger. Når mange kommentarer på visse steder er kritiske, gjør dem om globalt, fordi noe gikk galt.
- Så er tiden inne for mindre redigeringer - et sted er setningen ikke veldig pent formulert, et sted er det noen som ikke liker skrifttypen, 14,5, men vil ha 15,7.
- Når denne typen kommentarer gjenstår, så er det det, kurset åpner mer eller mindre, offisielt salg begynner.
Og ved første øyekast viser den korte og enkle oppgaven med å lage et kurs seg å være slett ikke enkel og tar utrolig lang tid.
Og det er et annet viktig poeng at arbeidet med kurset ikke avsluttes når kurset slippes. For det første leser vi nøye kommentarene som er igjen på enkelte deler. Og selv til tross for all innsatsen vi har gjort, er noen feil fortsatt identifisert, noen feil blir rettet og forbedret underveis, i sanntid, slik at hver påfølgende bruker får en bedre service.
Hvert kurs har sin egen produkteier, som i tillegg til å definere det generelle konseptet, sjekker fristene, noterer han i margen at når tiden er inne for å skrive om kurset fullstendig, og det vil definitivt komme, for om to år, eller til og med et år senere, vil noe av det vi forteller bli irrelevant bare fordi det vil bli moralsk foreldet. Produkteieren noterer i margen at folk oftest spør hvilke punkter som var uklare, hvilke oppgaver som virket veldig vanskelige, og som virket tvert imot veldig enkle. Og alt dette blir tatt i betraktning når du registrerer kurset på nytt, under en slags refaktorering, slik at hver iterasjon av det globale kurset blir bedre, mer praktisk og komfortabelt.
Slik fremstår kurs.
Hvordan Docker-kurset ble født
Dette er et eget og til og med uvanlig tema for oss. For på den ene siden planla vi ikke å gjøre det, fordi mange nettskoler tilbyr det. På den annen side ba han selv om frihet og fant en logisk plass i konseptet vårt med opplæring av IT-spesialister i Kubernetes.
Når vi snakker veldig globalt, startet det i utgangspunktet med et kurs om Kubernetes, da det etter min mening nettopp startet etter den første slurmen. Vi samlet inn tilbakemeldinger og så at mange ønsker å lese noe ekstra om Docker et annet sted, og generelt kommer mange til grunnkurset på Kubernetes uten å vite hva det er. .
Derfor laget de for den andre Slurm et kurs - eller rettere sagt, ikke engang et kurs, men laget et par kapitler om Dockers. Der de fortalte noe av det mest grunnleggende, slik at folk som kommer på intensiven ikke skulle føle seg fratatt og generelt forstå hva som skjedde.
Og så utviklet hendelser seg omtrent slik. Mengden materiale vokste og sluttet å passe på 3 dager. Og en logisk og åpenbar idé dukket opp: hvorfor ikke gjøre det vi dekker på Slurm Basic til et slags lite kurs som du kan sende folk til som vil se noe om Docker før du tar et intensivkurs på Kubernetes.
Slurm Junior er nemlig en kombinasjon av flere slike grunnkurs. Som et resultat ble Docker-kurset en del av Slurm Junior. Det vil si at dette er et sånt nullsteg før и . Og så var det bare helt grunnleggende abstraksjoner.
På et tidspunkt begynte folk å spørre: «Gutter, dette er kjempebra, dette er nok til å forstå hva dere snakker om på intensivkursene. Hvor kan jeg lese mer detaljert om hva docker kan gjøre og hvordan man jobber med det, og hva det er?» Så ideen kom opp om å gjøre det rett , slik at for det første kan folk som kommer til Slurm ved hjelp av Kubernetes fortsatt sendes til det, og på den annen side for de som ikke engang er interessert i Kubernetes på dette stadiet av utviklingen. Slik at en IT-spesialist kan komme og se kurset vårt om Docker og starte sin evolusjonære vei ganske enkelt med ren Docker. Slik at vi har et så fullverdig, komplett kurs - og så har mange, etter å ha sett dette kurset, etter å ha jobbet en stund med ren Docker, vokst til det nivået hvor de trenger Kubernetes eller et annet orkestreringssystem. Og de kom spesielt til oss.
Noen ganger stilles spørsmålet: "Hva slags mennesker trenger kanskje ikke Kubernetes nå?" Men dette spørsmålet handler ikke om mennesker, det er snarere et spørsmål om selskaper. Her må du forstå at Kubernetes har visse tilfeller der det er godt egnet og oppgaver som det løser godt, men tvert imot er det noen scenarier for bruk av Kubernetes når det forårsaker ytterligere smerte og ytterligere lidelse. Derfor avhenger det ikke engang av mennesker, men av hvilke selskaper som har utviklet seg og hvor lenge.
For eksempel en forferdelig Legacy-monolit - du bør sannsynligvis ikke presse den inn i Kubernetes, fordi den vil forårsake flere problemer enn fordeler. Eller hvis dette for eksempel er et lite prosjekt, har det en liten belastning eller i prinsippet ikke mye penger og ressurser. Det er ingen vits i å dra den inn i Kubernetes.
Og generelt, sannsynligvis generelt, som mange allerede har sagt, hvis du stiller spørsmålet: "Trenger jeg Kubernetes?", så trenger du mest sannsynlig ikke det. Jeg husker ikke hvem som først kom opp med det, etter min mening, Pasha Selivanov. Jeg er 100% enig i dette. Og du må vokse opp til Kubernetes - og når det allerede blir klart at jeg trenger Kubernetes og selskapet vårt trenger det, og det vil bidra til å løse slike og slike problemer, så er det sannsynligvis fornuftig å gå å lære og finne ut nøyaktig hvordan du skal sette det opp godt, slik at prosessen med å bytte til Kubernetes ikke er veldig smertefull.
Noen barneplager og noen enkle ting, og til og med ikke helt enkle, kan man finne ut spesielt hos oss, og ikke gå gjennom din egen rake og smerte.
Mange selskaper har gått akkurat den veien at det først bare var en slags infrastruktur uten containerisering. Så kom de til det punktet hvor det ble vanskelig å klare det hele, de byttet til Docker og på et tidspunkt vokste de til det punktet hvor det ble trangt innenfor rammene av Docker og hva det tilbyr. Og de begynte å se på hva som var rundt, hvilke systemer som løser disse problemene, og spesielt Kubernetes - dette er et av de systemene som lar deg løse problemer når ren Docker blir overfylt og mangler funksjonalitet, dette er en veldig god sak når folk De går steg for steg fra bunnen og opp, forstår at denne teknologien ikke er nok og går videre til neste nivå. De brukte noe, det ble knapt igjen, og de gikk videre.
Dette er et bevisst valg - og det er veldig kult.
Generelt ser jeg at systemet vårt er veldig vakkert bygget, f.eks. , selv gjennom videokurs. Så etter docker går det , deretter , deretter . Alt stiller seg logisk – en person består og et solid yrke dukker opp.
I prinsippet lar settet med kurs deg dekke mange saker, også moderne. Det er fortsatt områder som forblir en gråsone, jeg håper at vi snart lager noen kurs som gjør at vi kan stenge disse gråsonene, spesielt skal vi finne på noe om sikkerhet. For dette begynner å bli veldig aktuelt.
Kort oppsummert har vi noen gråsoner som det ville vært veldig fint å lukke, slik at det skulle bli et komplett, komplett bilde – og folk kunne komme, og akkurat som Kubernetes selv er som en Lego-konstruktør, kan du lage forskjellige ting fra det samler, hvis det fortsatt ikke er nok - supplement, det samme med våre kurs, slik at folk kan forstå hva de trenger av dette, de trenger å sette sammen et slags puslespill, et slags byggesett fra kursene våre.
Hvis du stiller deg selv et generelt korrekt og ærlig spørsmål: "Hvem kan bruke et aktivt Docker-kurs nå?", så:
- For studenter som så vidt begynner å sette seg inn i det.
- Ansatte i testavdelingen.
- Faktisk er det mange selskaper som fortsatt ikke bare ikke bruker Docker, men ingen har hørt om slik teknologi og i prinsippet ikke vet hvordan de skal bruke den. Og jeg kjenner flere store selskaper i St. Petersburg som har utviklet seg i mange år, og de brukte noen gamle teknologier, de beveger seg i denne retningen. Spesielt for slike selskaper, for ingeniører i slike selskaper, kan dette kurset være veldig interessant, siden det for det første lar deg raskt fordype deg i denne teknologien, og for det andre så snart flere ingeniører dukker opp som forstår hvordan det hele fungerer, kan de bringe det til selskapet og utvikle denne kulturen og disse retningene i selskapet.
- Etter min mening kan dette kurset fortsatt være nyttig for de som allerede har jobbet med docker, men veldig lite og mer i "gjør én gang, gjør to ganger"-stilen - og nå skal de på en eller annen måte samhandle med de samme Kubernetes, og dette pålegger dem visse forpliktelser, hvis du har veldig overfladisk kunnskap om hva docker er, hvordan du driver det, men samtidig vet du ikke hvordan det fungerer fra innsiden, vet du ikke hva som er best å gjøre med det og hva er bedre å ikke gjøre, Da egner dette kurset seg godt for å systematisere og utdype kunnskap.
Men hvis du har kunnskap på nivået: "Jeg vet ikke hvordan jeg skal skrive de samme Docker-filene riktig, jeg kan forestille meg hva navnerom er, hvordan containere fungerer, hvordan de faktisk implementeres på operativsystemnivå" - så er det definitivt ingen vits i å gå til oss, du vil ikke lære noe nytt og du vil være litt trist for pengene og tiden du bruker.
Hvis vi formulerer hvilke fordeler kurset vårt har, så:
- Vi prøvde å lage dette kurset med et tilstrekkelig antall praktiske tilfeller som lar deg ikke bare forstå den teoretiske delen som finnes, men også forstå hvorfor du trenger det og hvordan du vil bruke det i fremtiden;
- det er flere seksjoner som svært sjelden finnes noe sted - og generelt er det ikke så mye materiale på dem. De forholder seg til interaksjonen mellom Docker og operativsystemet, til og med litt annerledes. Hvilke mekanismer tok Docker fra operativsystemet for å implementere containeriseringssystemet - og dette gir en så dypere forståelse av hele problemet med å kjøre containere i Linux-operativsystemet. Hvordan det fungerer, hvordan det samhandler med hverandre inne i operativsystemet, utenfor, og så videre.
Dette er et så virkelig dypt blikk at det skjer ganske sjelden, og samtidig er det etter min mening veldig viktig. Hvis du vil forstå hvilken som helst teknologi godt og forstå hva du kan forvente av den, må du i det minste ha en generell ide om hvordan den fungerer på et lavt nivå.
Kurset vårt viser og forteller hvordan dette fungerer fra operativsystemets synspunkt. På den ene siden bruker alle containeriseringssystemer de samme operativsystemmekanismene. På den annen side tar de det som er i Linux-operativsystemet, som docker. Andre containeriseringssystemer kom ikke med noe nytt - de tok det som allerede var i Linux og skrev bare en praktisk innpakning som lar deg raskt ringe det, kjøre det eller på en eller annen måte samhandle med det. Den samme Docker er ikke et veldig stort lag mellom operativsystemet og kommandolinjen, det er et slags verktøy som lar deg ikke skrive kilotonn med kommandoer eller en slags C-kode for å lage en container, men å gjøre dette ved å skrive inn et par linjer i terminalen.
Og en ting til, hvis vi snakker spesifikt om Docker, det Docker virkelig brakte til IT-verdenen er standarder. Hvordan applikasjonen skal lanseres, hvordan den skal fungere, hva er kravene til logger, hva er kravene til skalering, konfigurering av selve applikasjonen.
På mange måter handler docker om standarder.
Standarder flyttes også til Kubernetes - og det er nøyaktig de samme standardene; hvis du vet hvordan du kjører applikasjonen din godt i Docker, vil den 99 % av tiden fungere like bra i Kubernetes.
Hvis du fant deg selv interessert ikke bare i hvordan Docker-kurset ble opprettet, men også i andre kurs, men også interessert i selve kurset fra et praktisk synspunkt, så
Vi vil gjerne se deg!
Kilde: www.habr.com