Een deelnemer komt naar een cursus of intensieve cursus. Hij ziet overzichtelijke rijen technische ondersteuning, keurig aangelegde stroomkabels, een schaakbordindeling van de collegezaal, heldere foto's en diadiagrammen. Sprekers met grappen en glimlachen geven informatie op zo'n manier door dat je net de tijd hebt om het te begrijpen. De stands zijn opgezet, oefentaken vliegen je zo uit de vingers, alleen heb je soms de hulp van technisch personeel nodig. steun.
En ook koffiepauzes met gelijkgestemden, een vrolijke en energieke sfeer, uitwisseling van ervaringen, de meest onverwachte vragen voor sprekers. Zowel antwoorden als informatie die je niet in handleidingen, maar alleen in de praktijk zult vinden.
Hoeveel tijd, moeite en zenuwen denk je dat het gekost heeft om het er precies zo uit te laten zien?
Met dank aan Volodya Guryanov, een gecertificeerde Kubernetes-beheerder en ingenieur/teamleider bij Southbridge, die vanaf het allereerste begin getuige is geweest van en actief heeft deelgenomen aan de creatie van vele Slurm-cursussen.
Hij zag natuurlijk de onderbuik van de schepping: complexiteiten en netelige harken, inzichten en onverwachte oplossingen. En de al bekende Kubernetes intensives, zoals Slurm Basic en Slurm Mega. En een nieuwe, grotendeels herziene koers , die onverbiddelijk nadert en op 19 augustus begint.
Maar misschien genoeg tekst, laten we verder gaan met het verhaal zelf. Hoe je van een paar intensieve onderwerpen een volledig zelfvoorzienend en veelzijdig kunt maken . Dus ik begin met het verhaal over hoe cursussen worden gemaakt en ontwikkeld - net als "Een lange tijd geleden in een sterrenstelsel ver, ver weg..."
Wat is er achter de schermen?
Als je vraagt hoe we cursussen maken en waar het allemaal begint, antwoord ik eenvoudig: “Het begint allemaal met een idee.”
Meestal komt het idee ergens vandaan: we zitten niet geboeid in de kelder totdat we bedenken: “Over welk onderwerp moeten we een cursus maken?” Ideeën komen ergens vandaan, uit externe bronnen. Soms beginnen mensen zich actief af te vragen: “Wat weet jij over die en die specifieke technologie?” Of hoe het bij Docker was dat het onmogelijk was hem in te passen in de timing van de intensieve cursus - hij moest uiteraard naar buiten om tijd te hebben om tijdens de intensieve cursus iets te vertellen.
Zo ontstaat een idee.
Nadat het was aangekondigd, begint naar mijn mening het moeilijkste moment - om in het algemeen te begrijpen wat je in deze cursus moet opnemen - dit is zeer vergelijkbaar met hoe sprekers worden voorbereid op welke conferentie dan ook.
Er is één grote pijn als je een onderwerp lijkt te hebben gekozen en denkt: “Wat kan ik erover vertellen? Dit is te simpel, dit is duidelijk, dit weet iedereen ook.”
Maar in feite is dit helemaal niet het geval. En ik zeg persoonlijk op veel plaatsen dat wat voor jou vanzelfsprekend lijkt, voor degenen die naar je komen luisteren of een cursus volgen, helemaal niet vanzelfsprekend is. En hier ontstaat zo'n grote laag werk en intern conflict over wat er in de cursus moet worden opgenomen. Het resultaat is dat we zo'n lijst met hoofdstukken krijgen met zulke ingrijpende grote lijnen, waar de cursus over zal gaan.
En dan begint het eenvoudige routinewerk:
- Materiaal selectie
- Lees aandachtig de documentatie voor de huidige versie, aangezien de IT-wereld zich nu met een soort kosmische snelheid ontwikkelt. Zelfs als je ergens mee werkt en er een cursus over maakt, moet je naar de documentatie gaan en kijken wat daar nieuw is, wat interessant is om over te praten, wat vooral nuttig kan zijn om te vermelden.
- En er verschijnt een bepaald skelet van de cursus, waar de meeste onderwerpen in het algemeen al aan bod komen en het lijkt erop dat wat er ook is, video's opneemt en ze in productie brengt.
- Maar in feite, nee, dan begint het harde werk, maar niet voor de auteurs van de cursus, maar voor degenen die testen. Meestal zijn onze alfatesters de technische ondersteuning, die eerst de cursussen proefleest op eventuele syntactische en grammaticale fouten. Ten tweede slaan ze ons pijnlijk met stokken en vloeken als er een aantal volkomen onduidelijke, onbegrijpelijke plaatsen zijn. Wanneer er ingewikkeld samengestelde ondergeschikte zinnen van een paar pagina's of duidelijke onzin in de teksten voorkomen. Ze lezen het allemaal, let er op.
- Dan begint de oefentestfase, waar ook enkele voor de hand liggende niet-werkende dingen worden opgevangen en enkele momenten worden getoond die moeilijker kunnen worden gemaakt, omdat het niet erg interessant wordt - alleen maar zitten en kopiëren - en er plaatsen worden geïdentificeerd waar het erg moeilijk is. moeilijk en we hebben veel te doen wat we willen van mensen die deze cursus gaan volgen. En dan komen er aanbevelingen: “Jongens, maak het hier eenvoudiger, het zal gemakkelijker waar te nemen zijn en er zal meer voordeel uit voortkomen.”
- Nadat deze hoeveelheid werk is gedaan en het deel dat betrekking heeft op de video is geschreven, lijkt alles in orde te zijn. En je kunt het al doneren voor productie, voor reclame voor deze cursus. Maar nogmaals, nee, het is te vroeg - omdat we de laatste tijd niet meer een beetje op onszelf vertrouwen en in principe meer met feedback zijn gaan werken. Er bestaat zoiets als bètatesten - dit is wanneer mensen worden uitgenodigd door buitenstaanders, die op geen enkele manier verbonden zijn met ons bedrijf, en voor sommige goodies krijgen ze alle delen van de cursus, video's, tekst en praktische taken te zien, zodat ze evalueerde de kwaliteit van het materiaal, de toegankelijkheid van het materiaal en hielp ons de cursus zo goed mogelijk te maken.
- En wanneer er meerdere van dergelijke iteraties plaatsvinden, sprekers, alfatesten in de vorm van technische ondersteuning, bètatesten, verbeteringen. En dan begint alles opnieuw: technische ondersteuning, bètatests, verbeteringen.
- En op een gegeven moment komt het besef dat we óf klaar zijn met de aanpassingen, omdat het volkomen onrealistisch is om ervoor te zorgen dat iedereen het leuk vindt, óf dat er drastische beslissingen worden genomen. Als veel opmerkingen op bepaalde plaatsen van cruciaal belang zijn, herhaal ze dan globaal, omdat er iets mis is gegaan.
- Dan is het tijd voor kleine aanpassingen - ergens is de zin niet zo mooi geformuleerd, ergens vindt iemand het lettertype niet mooi, 14,5, maar zou graag 15,7 willen.
- Als dit soort opmerkingen blijven bestaan, dan is het zo, de cursus gaat min of meer open, de officiële verkoop begint.
En op het eerste gezicht blijkt de korte en eenvoudige taak van het maken van een cursus helemaal niet eenvoudig te zijn en ongelooflijk lang te duren.
En er is nog een belangrijk punt: het werken met de cursus eindigt niet wanneer de cursus wordt vrijgegeven. Allereerst lezen we aandachtig de commentaren die op bepaalde onderdelen zijn achtergelaten. En ondanks alle inspanningen die we hebben geleverd, worden er nog steeds enkele tekortkomingen geïdentificeerd, sommige fouten worden gaandeweg in realtime gecorrigeerd en verbeterd, zodat elke volgende gebruiker een betere service krijgt.
Elke cursus heeft zijn eigen producteigenaar, die naast het definiëren van het algemene concept ook de deadlines controleert, in de kantlijn aantekeningen maakt dat wanneer het tijd is om de cursus volledig te herschrijven, en dat zal zeker gebeuren, want over twee jaar of zelfs een jaar later zal een deel van wat we vertellen irrelevant worden, simpelweg omdat het moreel achterhaald zal zijn. De producteigenaar maakt in de kantlijn aantekeningen dat mensen meestal vragen welke punten onduidelijk waren, welke taken erg moeilijk leken en welke juist heel eenvoudig leken. En met dit alles wordt rekening gehouden bij het opnieuw opnemen van de cursus, tijdens een soort refactoring, zodat elke iteratie van de globale koers beter, handiger en comfortabeler wordt.
Zo verschijnen cursussen.
Hoe de Docker-cursus werd geboren
Dit is een apart en zelfs ongebruikelijk onderwerp voor ons. Omdat we enerzijds niet van plan waren het te doen, omdat veel online scholen het aanbieden. Aan de andere kant vroeg hij zelf om vrijheid en vond hij een logische plek in ons concept om IT-specialisten op te leiden in Kubernetes.
Heel globaal gesproken: in eerste instantie begon het allemaal met een cursus Kubernetes, terwijl het naar mijn mening net begon na de eerste Slurm. We verzamelden feedback en zagen dat veel mensen ergens anders iets aanvullends over Docker willen lezen, en over het algemeen komen velen naar de basiscursus Kubernetes zonder te weten wat het is .
Daarom maakten ze voor de tweede Slurm een cursus - of beter gezegd, niet eens een cursus, maar maakten ze een paar hoofdstukken over Dockers. Waar ze enkele van de meest fundamentele dingen vertelden, zodat mensen die naar de intensive komen zich niet achtergesteld zouden voelen en over het algemeen zouden begrijpen wat er gebeurde.
En toen ontwikkelden de gebeurtenissen zich ongeveer zo. De hoeveelheid materiaal groeide en stopte binnen 3 dagen met passen. En er ontstond een logisch en voor de hand liggend idee: waarom zouden we wat we bij Slurm Basic behandelen niet omzetten in een soort kleine cursus waar je mensen naartoe kunt sturen die iets over Docker willen zien voordat ze een intensieve cursus Kubernetes volgen.
Slurm Junior is in feite een combinatie van meerdere van dit soort basiscursussen. Hierdoor werd de Dockercursus een stukje Slurm Junior. Dat wil zeggen, dit is zo'n nulstap eerder и . En dan waren er nog maar heel basale abstracties.
Op een gegeven moment begonnen mensen te vragen: “Jongens, dit is allemaal geweldig, dit is genoeg om te begrijpen waar je het over hebt tijdens de intensieve cursussen. Waar kan ik meer in detail lezen over wat docker kan doen, hoe ik ermee kan werken en wat het is?” Zo ontstond het idee om het recht te zetten , zodat in de eerste plaats mensen die met Kubernetes naar Slurm komen er nog steeds naartoe kunnen worden gestuurd, en aan de andere kant voor degenen die in deze ontwikkelingsfase niet eens geïnteresseerd zijn in Kubernetes. Zodat een IT-specialist onze cursus Docker kan komen bekijken en zijn evolutionaire pad eenvoudig met pure Docker kan beginnen. Zodat we zo'n volwaardige, complete cursus hebben - en velen, die deze cursus hebben bekeken en een tijdje met pure Docker hebben gewerkt, zijn gegroeid naar het niveau waarop ze Kubernetes of een ander orkestratiesysteem nodig hebben. En zij kwamen speciaal naar ons toe.
Soms wordt de vraag gesteld: “Wat voor soort mensen hebben Kubernetes nu misschien niet nodig?” Maar deze vraag gaat niet over mensen, het gaat eerder over bedrijven. Hier moet je begrijpen dat Kubernetes bepaalde gevallen kent waarin het zeer geschikt is en taken die het goed oplost, maar integendeel: er zijn enkele scenario's voor het gebruik van Kubernetes wanneer het extra pijn en extra lijden veroorzaakt. Daarom hangt het niet eens van mensen af, maar van wat bedrijven aan het ontwikkelen zijn en voor hoe lang.
Bijvoorbeeld een vreselijke Legacy-monoliet - je moet deze waarschijnlijk niet in Kubernetes duwen, omdat dit meer problemen dan voordelen zal veroorzaken. Of als dit bijvoorbeeld een klein project is, heeft het een kleine last of, in principe, niet veel geld en middelen. Het heeft geen zin om het naar Kubernetes te slepen.
En in het algemeen, waarschijnlijk, zoals veel mensen al hebben gezegd, als je de vraag stelt: "Heb ik Kubernetes nodig?", Dan heb je het hoogstwaarschijnlijk niet nodig. Ik weet niet meer wie het naar mijn mening als eerste bedacht heeft: Pasha Selivanov. Ik ben het hier 100% mee eens. En je moet opgroeien tot Kubernetes - en als het al duidelijk wordt dat ik Kubernetes nodig heb en ons bedrijf het nodig heeft, en het zal helpen om bepaalde problemen op te lossen, dan is het waarschijnlijk zinvol om te gaan leren en uit te zoeken hoe je precies moet instellen het goed op, zodat het proces van overstappen naar Kubernetes niet erg pijnlijk is.
Sommige kinderkwalen en sommige eenvoudige dingen, en zelfs niet erg eenvoudige, kun je vooral bij ons ontdekken, en niet door je eigen hark en pijn gaan.
Veel bedrijven zijn precies dezelfde kant op gegaan dat er aanvankelijk alleen maar een soort infrastructuur was zonder containerisatie. Toen kwamen ze op het punt waarop het moeilijk werd om alles te beheren, ze schakelden over op Docker en op een gegeven moment groeiden ze zo ver dat het krap werd binnen het raamwerk van Docker en wat het te bieden heeft. En ze begonnen te kijken naar wat er in de buurt was, welke systemen deze problemen oplossen, en in het bijzonder Kubernetes - dit is een van die systemen waarmee je problemen kunt oplossen wanneer pure Docker druk wordt en functionaliteit mist, dit is echt een goed geval als mensen Ze gaan stap voor stap van onder naar boven, begrijpen dat deze technologie niet genoeg is en gaan naar het volgende niveau. Ze gebruikten iets, het werd weer schaars en ze trokken verder.
Dit is een bewuste keuze – en het is erg cool.
Over het algemeen zie ik dat ons systeem heel mooi gebouwd is, bijvoorbeeld , zelfs via videocursussen. Dan gaat het na docker dan dan . Alles komt logisch op één lijn: een persoon gaat voorbij en er ontstaat een solide beroep.
Met de reeks cursussen kun je in principe veel gevallen behandelen, zelfs moderne. Er zijn nog steeds gebieden die een grijs gebied blijven, ik hoop dat we binnenkort een aantal cursussen zullen creëren waarmee we deze grijze gebieden kunnen sluiten, in het bijzonder zullen we iets bedenken over veiligheid. Want dit wordt heel relevant.
Kortom, we hebben een aantal grijze gebieden die heel mooi zouden zijn om te sluiten, zodat het een compleet, compleet beeld zou zijn – en mensen zouden kunnen komen, en net zoals Kubernetes zelf een Lego-constructeur is, kun je er verschillende dingen van maken. het verzamelt, als er nog niet genoeg is, een aanvulling op hetzelfde met onze cursussen, zodat mensen kunnen begrijpen wat ze hieruit nodig hebben; ze moeten een soort puzzel in elkaar zetten, een soort bouwset uit onze cursussen.
Als je jezelf een over het algemeen correcte en eerlijke vraag stelt: “Wie kan er nu wel een actieve Docker-cursus gebruiken?”, dan:
- Voor studenten die er net mee beginnen.
- Medewerkers van de afdeling testen.
- Er zijn zelfs veel bedrijven die nog steeds Docker niet gebruiken, maar niemand heeft van dergelijke technologie gehoord en weet in principe niet hoe ze deze moeten gebruiken. En ik ken verschillende grote bedrijven in Sint-Petersburg die zich al vele jaren ontwikkelen, en die een aantal oude technologieën gebruikten, ze gaan deze kant op. In het bijzonder voor dergelijke bedrijven, voor ingenieurs in dergelijke bedrijven, kan deze cursus erg interessant zijn, omdat je in de eerste plaats jezelf snel in deze technologie kunt onderdompelen, en ten tweede, zodra er verschillende ingenieurs verschijnen die begrijpen hoe het allemaal werkt. werkt, kunnen ze het naar het bedrijf brengen en deze cultuur en deze richtingen binnen het bedrijf ontwikkelen.
- Naar mijn mening kan deze cursus nog steeds nuttig zijn voor degenen die al met docker hebben gewerkt, maar heel weinig en meer in de stijl van "een keer doen, twee keer doen" - en nu gaan ze op de een of andere manier communiceren met dezelfde Kubernetes, en dit legt hen bepaalde verplichtingen op, als je een zeer oppervlakkige kennis hebt van wat docker is, hoe je het moet uitvoeren, maar tegelijkertijd niet weet hoe het van binnenuit werkt, weet je niet wat je er het beste mee kunt doen en wat kun je beter niet doen? Dan is deze cursus zeer geschikt voor het systematiseren en verdiepen van kennis.
Maar als je kennis hebt op het niveau van: "Ik weet niet hoe ik dezelfde Docker-bestanden correct moet schrijven, ik kan me voorstellen wat naamruimten zijn, hoe containers werken, hoe ze daadwerkelijk worden geïmplementeerd op besturingssysteemniveau" - dan is er het heeft absoluut geen zin om naar ons toe te gaan, je leert niets nieuws en je zult een beetje verdrietig zijn over het geld en de tijd die je besteedt.
Als we formuleren welke voordelen onze cursus heeft, dan:
- We hebben geprobeerd deze cursus te maken met een voldoende aantal praktische cases waarmee u niet alleen het bestaande theoretische deel kunt begrijpen, maar ook kunt begrijpen waarom u het nodig heeft en hoe u het in de toekomst zult gebruiken;
- er zijn verschillende secties die je zelden ergens tegenkomt - en over het algemeen staat er niet zoveel materiaal op. Ze hebben betrekking op de interactie van Docker met het besturingssysteem, zelfs een beetje anders. Welke mechanismen heeft Docker uit het besturingssysteem overgenomen om het containerisatiesysteem te implementeren - en dit geeft zo'n dieper inzicht in de hele kwestie van het draaien van containers binnen het Linux-besturingssysteem. Hoe het werkt, hoe het met elkaar omgaat binnen het besturingssysteem, daarbuiten, enzovoort.
Dit is zo'n echt diepgaande blik dat het vrij zelden voorkomt, en tegelijkertijd is het naar mijn mening erg belangrijk. Als je welke technologie dan ook goed wilt begrijpen en wilt begrijpen wat je ervan kunt verwachten, moet je op zijn minst op een laag niveau een algemeen idee hebben van hoe deze werkt.
Onze cursus laat zien en vertelt hoe dit werkt vanuit het oogpunt van het besturingssysteem. Enerzijds gebruiken alle containerisatiesystemen dezelfde besturingssysteemmechanismen. Aan de andere kant nemen ze wat er in het Linux-besturingssysteem zit, zoals docker. Andere containerisatiesystemen hebben niets nieuws bedacht - ze namen wat al in Linux zat en schreven slechts een handige verpakking waarmee je het snel kunt oproepen, uitvoeren of er op de een of andere manier mee kunt communiceren. Dezelfde Docker is geen erg grote laag tussen het besturingssysteem en de opdrachtregel, het is een soort hulpprogramma waarmee je geen kiloton aan opdrachten of een soort C-code kunt schrijven om een container te maken, maar dit kunt doen door dit in te voeren een paar regels in terminal.
En nog iets: als we het specifiek over Docker hebben, zijn wat Docker echt in de IT-wereld heeft gebracht standaarden. Hoe de applicatie gelanceerd moet worden, hoe deze moet werken, wat zijn de vereisten voor logs, wat zijn de vereisten voor het schalen, het configureren van de applicatie zelf.
In veel opzichten gaat Docker over standaarden.
Standaarden verschuiven ook naar Kubernetes - en er zijn precies dezelfde standaarden; als je weet hoe je je applicatie goed moet draaien in Docker, dan zal het 99% van de tijd net zo goed werken binnen Kubernetes.
Als je niet alleen geïnteresseerd bent in hoe de Docker-cursus tot stand is gekomen, maar ook in andere cursussen, maar ook geïnteresseerd bent in de cursus zelf vanuit praktisch oogpunt, dan
We zullen blij zijn je te zien!
Bron: www.habr.com