'n Deelnemer kom na 'n kursus of intensiewe kursus. Hy sien ordelike rye tegniese ondersteuning, netjies aangelegde kragkabels, 'n skaakborduitleg van die lesingsaal, helder prentjies en skyfiediagramme. Sprekers met grappies en glimlagte gee inligting op so 'n manier uit dat jy net tyd het om dit te verstaan. Die staanplekke is opgestel, oefentake vlieg sommer van jou vingers af, behalwe dat jy soms die hulp van tegniese personeel nodig het. ondersteun.
En ook koffiepouses met eendersdenkende mense, ’n vrolike en energieke atmosfeer, uitruil van ervarings, die mees onverwagte vrae vir sprekers. Beide antwoorde en inligting wat jy nie in handleidings sal vind nie, maar slegs in die praktyk.
Hoeveel tyd, moeite en senuwees dink jy het dit geneem om dit presies so te laat lyk?
Dankie aan Volodya Guryanov, 'n gesertifiseerde Kubernetes-administrateur en ingenieur/spanleier by Southbridge, wat van die begin af aan die skepping van baie Slurm-kursusse gesien en aktief daaraan deelgeneem het.
Hy het die onderbuik natuurlik die skepping gesien—kompleksiteite en netelige harke, insigte en onverwagte oplossings. En die reeds bekende Kubernetes intensiewe, soos Slurm Basic en Slurm Mega. En 'n nuwe, grootliks hersiene kursus , wat onverbiddelik nader kom en op 19 Augustus sal begin.
Maar, miskien, genoeg van die lirieke, kom ons gaan aan na die storie self. Hoe uit 'n paar intensiewe onderwerpe 'n heeltemal selfversorgend en veelvlakkig . So ek sal die storie begin van hoe kursusse geskep en ontwikkel word - net soos "'n lang tyd gelede in 'n sterrestelsel ver, ver weg ..."
Wat is agter die skerms?
As jy vra hoe ons kursusse maak en waar dit alles begin, sal ek eenvoudig antwoord "Dit begin alles met 'n idee."
Gewoonlik kom die idee van iewers - ons sit nie geboei in die kelder totdat ons vorendag kom met: "Oor watter onderwerp moet ons 'n kursus maak?" Idees kom van iewers op hul eie uit eksterne bronne. Soms begin mense aktief vra: "Wat weet jy van so en so 'n spesifieke tegnologie?" Of hoe dit met Docker was dat dit onmoontlik was om hom by die tydsberekening vir die intensiewe kursus in te pas – hy moes natuurlik na buite geneem word om tyd te hê om iets tydens die intensiewe kursus te vertel.
Dit is hoe 'n idee verskyn.
Nadat dit aangekondig is, begin na my mening die moeilikste oomblik – om oor die algemeen te verstaan wat om by hierdie kursus in te sluit – dit is baie vergelykbaar met hoe sprekers voorberei word vir enige konferensies.
Daar is een hoofpyn wanneer jy blykbaar 'n onderwerp gekies het en dink: “Wat kan ek daaroor vertel? Dit is te eenvoudig, dit is voor die hand liggend, almal weet dit ook.”
Maar in werklikheid is dit glad nie die geval nie. En ek sê persoonlik op baie plekke dat wat vir jou vanselfsprekend lyk, vir diegene wat na jou kom luister of ’n kursus volg, glad nie voor die hand liggend is nie. En hier ontstaan so 'n groot laag werk en interne konflik, oor wat om by die kursus in te sluit. Gevolglik kry ons so 'n lys hoofstukke met sulke vee groot houe, waaroor die kursus gaan handel.
En dan begin die eenvoudige roetine werk:
- Keuse van materiaal
- Lees noukeurig die dokumentasie vir die huidige weergawe, aangesien die IT-wêreld nou teen 'n soort kosmiese spoed ontwikkel. Selfs al werk jy met iets en maak ’n kursus daaroor, moet jy na die dokumentasie gaan en kyk wat is nuut daar, wat interessant is om oor te praat, wat dalk veral nuttig kan wees om op te noem.
- En 'n sekere skelet van die kursus verskyn, waar die meeste van die onderwerpe in die algemeen reeds gedek is en dit blyk dat wat ook al daar is - video's opneem en dit in produksie begin.
- Maar eintlik, nee, dan begin die harde werk, maar nie vir die skrywers van die kursus nie, maar vir diegene wat toets. Gewoonlik is ons alfatoetsers tegniese ondersteuning, wat eerstens die kursusse proeflees vir enige sintaktiese en grammatikale foute. Tweedens slaan hulle ons pynlik met stokke en vloek wanneer daar 'n paar heeltemal onopvallende, onverstaanbare plekke is. Wanneer 'n paar kompleks saamgestelde ondergeskikte sinne van 'n paar bladsye of ooglopende onsin in die tekste verskyn. Hulle lees dit alles, kyk uit daarvoor.
- Dan begin die oefentoetsfase, waar 'n paar ooglopende dinge wat nie werk nie, ook vasgevang word en 'n paar oomblikke gewys word wat óf moeiliker gemaak kan word, aangesien dit nie baie interessant word nie - net sit en kopieer - en plekke word geïdentifiseer waar dit baie is moeilik en ons het baie om te doen wat ons wil hê van mense wat hierdie kursus gaan volg. En dan kom aanbevelings: "Manne, maak dit eenvoudiger hier, dit sal makliker wees om waar te neem en daar sal meer voordeel daaruit wees."
- Nadat hierdie hoeveelheid werk gedoen is, is die deel wat met die video verband hou geskryf, alles blyk in orde te wees. En jy kan dit reeds skenk vir produksie, om hierdie kursus te adverteer. Maar weereens, nee, dit is te vroeg - want onlangs het ons opgehou om onsself 'n bietjie te vertrou en het ons in beginsel meer met terugvoer begin werk. Daar is iets soos beta-toetsing - dit is wanneer mense van buitestaanders genooi word, wat nie op enige manier met ons maatskappy verbind is nie, en vir 'n paar lekkernye word hulle alle dele van die kursus gewys, video's, teks, praktiese take, sodat hulle die kwaliteit van die materiaal, die toeganklikheid van die materiaal te evalueer en ons gehelp om die kursus so goed moontlik te maak.
- En wanneer verskeie sulke iterasies deurgaan, sprekers, alfa-toetsing in die vorm van tegniese ondersteuning, beta-toetsing, verbeterings. En dan begin alles weer van voor af – tegniese ondersteuning, beta-toetsing, verbeterings.
- En op 'n sekere punt kom die begrip dat óf ons klaar is met wysigings, want dit is heeltemal onrealisties om seker te maak dat almal daarvan hou, óf 'n paar drastiese besluite word geneem. Wanneer baie opmerkings oor sekere plekke krities is, herhaal dit wêreldwyd, want iets het verkeerd geloop.
- Dan kom die tyd vir klein wysigings - iewers is die sin nie baie mooi geformuleer nie, iewers hou iemand nie van die lettertipe, 14,5 nie, maar wil graag 15,7 hê.
- Wanneer hierdie tipe kommentaar oorbly, dan is dit dit, die kursus maak min of meer oop, amptelike verkope begin.
En met die eerste oogopslag blyk die kort en eenvoudige taak om 'n kursus te skep glad nie eenvoudig te wees nie en neem ongelooflik lank.
En daar is nog 'n belangrike punt dat werk met die kursus nie eindig wanneer die kursus vrygestel word nie. Eerstens lees ons die opmerkings wat op sekere dele gelaat word sorgvuldig. En selfs ten spyte van al die pogings wat ons aangewend het, word sommige foute steeds geïdentifiseer, sommige foute word reggestel en verbeter langs die pad, in reële tyd, sodat elke daaropvolgende gebruiker 'n beter diens ontvang.
Elke kursus het sy eie produkeienaar, wat, benewens die definisie van die algemene konsep, die sperdatums nagaan, maak hy aantekeninge in die kantlyn dat wanneer die tyd aanbreek om die kursus heeltemal te herskryf, en dit beslis sal kom, want oor twee jaar, of selfs 'n jaar later sal sommige van wat ons vertel irrelevant raak bloot omdat dit moreel uitgedien sal word. Die produkeienaar maak aantekeninge in die kantlyn dat mense meestal vra watter punte onduidelik was, watter take baie moeilik gelyk het en wat, inteendeel, baie eenvoudig gelyk het. En dit alles word in ag geneem wanneer die kursus heropgeneem word, tydens 'n soort herfaktorering, sodat elke iterasie van die globale kursus beter, geriefliker en gemakliker word.
Dit is hoe kursusse verskyn.
Hoe die Docker-kursus gebore is
Hierdie is 'n aparte en selfs ongewone onderwerp vir ons. Want aan die een kant het ons nie beplan om dit te doen nie, want baie aanlynskole bied dit aan. Aan die ander kant het hy self vir vryheid gevra en 'n logiese plek gevind in ons konsep van opleiding van IT-spesialiste in Kubernetes.
As ons baie globaal praat, het dit aanvanklik alles begin met 'n kursus oor Kubernetes, toe dit na my mening net begin het na die eerste Slurm. Ons het terugvoer ingesamel en gesien dat baie mense iewers anders iets bykomend oor Docker wil lees, en oor die algemeen kom baie na die basiese kursus oor Kubernetes sonder om te weet wat dit is .
Daarom het hulle vir die tweede Slurm 'n kursus gemaak - of liewer, nie eers 'n kursus nie, maar 'n paar hoofstukke oor Dockers gemaak. Waar hulle van die mees basiese dinge vertel het, sodat mense wat na die intensiewe kom nie ontneem sal voel nie en oor die algemeen sal verstaan wat aan die gebeur is.
En toe ontwikkel gebeure omtrent so. Die hoeveelheid materiaal het gegroei en het binne 3 dae ophou pas. En 'n logiese en voor die hand liggende idee het verskyn: waarom nie wat ons by Slurm Basic dek, verander in 'n soort klein kursus waarheen ons mense kan stuur wat iets oor Docker wil kyk voordat hulle 'n intensiewe kursus oor Kubernetes neem nie.
Slurm Junior is in werklikheid 'n kombinasie van verskeie sulke basiese kursusse. Gevolglik het die Docker-kursus 'n stuk van Slurm Junior geword. Dit wil sê, dit is so 'n nul-stap voor и . En dan was daar net baie basiese abstraksies.
Op 'n stadium het mense begin vra: “Ouens, dit is alles wonderlik, dit is genoeg om te verstaan waarvan julle praat by die intensiewe kursusse. Waar kan ek in meer besonderhede lees oor wat docker kan doen en hoe om daarmee te werk, en wat dit is?” So het die idee ontstaan om dit reg te maak , sodat, eerstens, mense wat na Slurm kom met Kubernetes, steeds daarheen gestuur kan word, en aan die ander kant, vir diegene wat op hierdie stadium van ontwikkeling nie eers in Kubernetes belangstel nie. Sodat 'n IT-spesialis ons kursus oor Docker kan kom kyk en sy evolusionêre pad eenvoudig met pure Docker kan begin. Sodat ons so 'n volwaardige, volledige kursus het - en dan het baie, wat hierdie kursus gekyk het, wat 'n geruime tyd met pure Docker gewerk het, gegroei tot die vlak waar hulle Kubernetes of 'n ander orkestrasiestelsel nodig het. En hulle het veral na ons toe gekom.
Soms word die vraag gevra: “Watter soort mense het dalk nou nie Kubernetes nodig nie?” Maar hierdie vraag gaan nie oor mense nie, dit is eerder 'n vraag oor maatskappye. Hier moet jy verstaan dat Kubernetes sekere gevalle het waar dit goed geskik is en take wat dit goed oplos, maar inteendeel, daar is 'n paar scenario's vir die gebruik van Kubernetes wanneer dit bykomende pyn en bykomende lyding veroorsaak. Daarom hang dit nie eers van mense af nie, maar van watter maatskappye besig is om te ontwikkel en vir hoe lank.
Byvoorbeeld, een of ander verskriklike Legacy-monoliet - jy moet dit waarskynlik nie in Kubernetes druk nie, want dit sal meer probleme as voordele veroorsaak. Of, byvoorbeeld, as dit 'n klein projek is, het dit 'n klein vrag of, in beginsel, nie baie geld en hulpbronne nie. Daar is geen sin om dit in Kubernetes in te sleep nie.
En in die algemeen, waarskynlik in die algemeen, soos baie mense reeds gesê het, as jy die vraag vra: "Het ek Kubernetes nodig?", dan het jy dit waarskynlik nie nodig nie. Ek onthou nie wie eerste daarmee vorendag gekom het nie, na my mening, Pasha Selivanov. Ek stem 100% hiermee saam. En jy moet grootword met Kubernetes - en wanneer dit reeds duidelik word dat ek Kubernetes nodig het en ons maatskappy het dit nodig, en dit sal help om sulke en sulke probleme op te los, dan maak dit waarskynlik sin om te gaan leer en uit te vind presies hoe om te stel dit goed op, sodat die proses om na Kubernetes oor te skakel nie baie pynlik is nie.
Sommige kinders se kwale en sommige eenvoudige dinge, en selfs nie baie eenvoudiges nie, kan veral by ons uitgevind word, en gaan nie deur jou eie hark en pyn nie.
Baie maatskappye het presies so gegaan dat daar aanvanklik net een of ander soort infrastruktuur was sonder containerisering. Toe kom hulle by die punt waar dit moeilik geword het om dit alles te bestuur, hulle het oorgeskakel na Docker en op 'n stadium het hulle gegroei tot die punt waar dit beknop geraak het binne die raamwerk van Docker en wat dit bied. En hulle het begin kyk na wat om is, watter stelsels hierdie probleme oplos, en veral Kubernetes - dit is een van daardie stelsels wat jou toelaat om probleme op te los wanneer pure Docker oorvol raak en nie funksionaliteit het nie, dit is 'n baie goeie geval wanneer mense Hulle gaan stap vir stap van onder af, verstaan dat hierdie tegnologie nie genoeg is nie en beweeg na die volgende vlak. Hulle het iets gebruik, dit het weer skaars geword, en hulle het aanbeweeg.
Dit is 'n bewuste keuse - en dit is baie cool.
Oor die algemeen sien ek dat ons stelsel baie mooi gebou is, bv. , selfs deur videokursusse. Dan na docker gaan dit , dan , dan . Alles is logies in lyn - 'n mens slaag en 'n stewige beroep kom na vore.
In beginsel laat die stel kursusse jou toe om baie gevalle te dek, selfs moderne. Daar is nog gebiede wat 'n grys gebied bly, ek hoop dat ons binnekort 'n paar kursusse sal skep wat ons sal toelaat om hierdie grys gebiede toe te maak, veral, ons sal met iets oor sekuriteit vorendag kom. Want dit raak baie relevant.
Kortom, ons het 'n paar grys areas wat dit baie lekker sal wees om toe te maak, sodat dit 'n volledige, volledige prentjie sal wees - en mense kan kom, en net soos Kubernetes self soos 'n Lego-konstruktor is, kan jy verskillende dinge maak van dit versamel, as daar nog nie genoeg is nie - aanvulling, dieselfde met ons kursusse, sodat mense kan verstaan wat hulle nodig het hieruit; hulle moet 'n soort legkaart bymekaarmaak, 'n soort konstruksiestel uit ons kursusse.
As jy jouself 'n algemeen korrekte en eerlike vraag vra: "Wie kan nou 'n aktiewe Docker-kursus gebruik?", dan:
- Vir studente wat net begin om dit te kry.
- Toets departement werknemers.
- Trouens, daar is baie maatskappye wat steeds nie net nie Docker gebruik nie, maar niemand het van sulke tegnologie gehoor nie en in beginsel nie weet hoe om dit te gebruik nie. En ek ken verskeie groot maatskappye in St. Petersburg wat al baie jare ontwikkel, en hulle het 'n paar ou tegnologieë gebruik, hulle beweeg in hierdie rigting. In die besonder, vir sulke maatskappye, vir ingenieurs in sulke maatskappye, kan hierdie kursus baie interessant wees, aangesien dit eerstens jou in staat sal stel om jouself vinnig in hierdie tegnologie te verdiep, en tweedens, sodra verskeie ingenieurs verskyn wat verstaan hoe dit alles werk, kan hulle dit na die maatskappy bring en hierdie kultuur en hierdie rigtings binne die maatskappy ontwikkel.
- Na my mening kan hierdie kursus steeds nuttig wees vir diegene wat reeds met docker gewerk het, maar baie min en meer in die "doen een keer, doen twee keer" styl - en nou gaan hulle op een of ander manier met dieselfde Kubernetes interaksie hê, en dit lê sekere verpligtinge op hulle op, as jy baie oppervlakkige kennis het van wat docker is, hoe om dit te bestuur, maar terselfdertyd weet jy nie hoe dit van binne werk nie, weet jy nie wat die beste is om mee te doen nie. dit en wat is beter om nie te doen nie, Dan is hierdie kursus goed geskik vir sistematisering en verdieping van kennis.
Maar as jy kennis het op die vlak van: "Ek weet nie hoe om dieselfde Docker-lêers korrek te skryf nie, ek kan my voorstel wat naamruimtes is, hoe houers werk, hoe hulle werklik op die bedryfstelselvlak geïmplementeer word" - dan is daar beslis geen sin om na ons toe te gaan nie, jy sal niks nuuts leer nie en jy sal 'n bietjie hartseer wees vir die geld en tyd wat jy spandeer.
As ons formuleer watter voordele ons kursus het, dan:
- Ons het probeer om hierdie kursus te maak met 'n voldoende aantal praktiese gevalle wat jou sal toelaat om nie net die teoretiese deel wat bestaan te verstaan nie, maar ook om te verstaan hoekom jy dit nodig het en hoe jy dit in die toekoms gaan gebruik;
- daar is verskeie afdelings wat baie selde oral gevind word - en oor die algemeen is daar nie soveel materiaal daaroor nie. Hulle hou verband met die interaksie van Docker met die bedryfstelsel, selfs 'n bietjie anders. Watter meganismes het Docker van die bedryfstelsel geneem om die houerstelsel te implementeer - en dit gee so 'n dieper begrip van die hele kwessie van die bestuur van houers binne die Linux-bedryfstelsel. Hoe dit werk, hoe dit met mekaar in wisselwerking is binne die bedryfstelsel, buite, ensovoorts.
Dit is so 'n werklik diep kyk dat dit nogal selde gebeur, en terselfdertyd, na my mening, is dit baie belangrik. As jy enige tegnologie goed wil verstaan en verstaan wat om daarvan te verwag, moet jy ten minste 'n algemene idee hê van hoe dit op 'n lae vlak werk.
Ons kursus wys en vertel hoe dit werk vanuit die bedryfstelsel-oogpunt. Aan die een kant gebruik alle houerstelsels dieselfde bedryfstelselmeganismes. Aan die ander kant neem hulle wat in die Linux-bedryfstelsel is, soos docker. Ander houerstelsels het nie met iets nuuts vorendag gekom nie - hulle het geneem wat reeds in Linux was en net 'n gerieflike omhulsel geskryf wat jou toelaat om dit vinnig te noem, dit uit te voer of op een of ander manier daarmee te kommunikeer. Dieselfde Docker is nie 'n baie groot laag tussen die bedryfstelsel en die opdragreël nie, dit is 'n soort hulpmiddel wat jou toelaat om nie kilotons opdragte of 'n soort C-kode te skryf om 'n houer te skep nie, maar om dit te doen deur in te voer 'n paar lyne in terminaal.
En nog een ding, as ons spesifiek oor Docker praat, wat Docker werklik na die IT-wêreld gebring het, is standaarde. Hoe die toepassing bekendgestel moet word, hoe dit moet werk, wat is die vereistes vir logs, wat is die vereistes vir skaal, die opstel van die toepassing self.
In baie opsigte gaan docker oor standaarde.
Standaarde beweeg ook na Kubernetes - en daar is presies dieselfde standaarde; as jy weet hoe om jou toepassing goed in Docker te laat loop, dan sal dit 99% van die tyd net so goed werk binne Kubernetes.
As jy nie net belangstel in hoe die Docker-kursus geskep is nie, maar ook in ander kursusse, maar ook geïnteresseerd in die kursus self vanuit 'n praktiese oogpunt, dan
Ons sal bly wees om jou te sien!
Bron: will.com