Partoprenanto venas al kurso aŭ intensa kurso. Li vidas bonordajn vicojn da teknika subteno, bonorde direktitaj elektraj kabloj, damtabulo enpaĝigo de la prelegejo, brilajn bildojn kaj glitdiagramojn. Parolantoj kun ŝercoj kaj ridetoj donas informojn tiel, ke vi nur havas tempon por kompreni ĝin. La standoj estas starigitaj, praktikaj taskoj simple flugas de viaj fingroj, krom ke foje vi bezonas la helpon de teknika personaro. subteno.
Kaj ankaŭ kafopaŭzoj kun samideanoj, gaja kaj energia etoso, interŝanĝo de spertoj, la plej neatenditaj demandoj por parolantoj. Kaj respondojn kaj informojn, kiujn vi ne trovos en manlibroj, sed nur praktike.
Kiom da tempo, penado kaj nervoj, laŭ vi, necesas por ke ĝi aspektu ĝuste tiel?
Dankon al Volodya Guryanov, atestita Kubernetes-administranto kaj inĝeniero/teamgvidanto ĉe Southbridge, kiu atestis kaj aktive partoprenis la kreadon de multaj Slurm-kursoj de la komenco mem.
Li vidis la subventron kompreneble kreadon—kompleksaĵojn kaj dornajn rastilojn, komprenojn kaj neatenditajn solvojn. Kaj la jam konataj Kubernetes-intensaj, kiel Slurm Basic kaj Slurm Mega. Kaj nova, grandparte reviziita kurso , kiu neeviteble proksimiĝas kaj komenciĝos la 19-an de aŭgusto.
Sed, eble, sufiĉe da la tekstoj, ni transiru al la rakonto mem. Kiel el paro da intensaj temoj tute memsufiĉa kaj multfaceta . Do mi komencos la rakonton pri kiel kursoj estas kreitaj kaj disvolvitaj - same kiel "Antaŭ longa tempo en galaksio malproksime, malproksime..."
Kio estas malantaŭ la scenoj?
Se vi demandas kiel ni faras kursojn kaj kie ĉio komenciĝas, mi simple respondos "Ĉio komenciĝas per ideo."
Kutime la ideo venas de ie - ni ne sidas mankatenitaj en la kelo antaŭ ol ni elpensas: "Pri kiu temo ni faru kurson?" Ideoj venas de ie memstare de eksteraj fontoj. Foje homoj komencas aktive demandi: "Kion vi scias pri tia aŭ tia specifa teknologio?" Aŭ kiel kun Docker estis neeble enigi lin en la tempigon por la intensa kurso - li evidente devis esti prenita eksteren por havi tempon rakonti ion dum la intensa kurso.
Tiel aperas ideo.
Post kiam ĝi estis anoncita, laŭ mi, komenciĝas la plej malfacila momento - por ĝenerale kompreni kion enmeti en ĉi tiu kurso - tio estas tre komparebla al kiel parolantoj estas pretaj por iuj konferencoj.
Estas unu ĉefa doloro kiam vi ŝajnas elekti temon kaj pensas: "Kion mi povas diri pri ĝi? Ĉi tio estas tro simpla, ĉi tio estas evidenta, ankaŭ ĉiuj scias tion."
Sed fakte ĉi tio tute ne estas la kazo. Kaj mi persone multloke diras, ke tio, kio ŝajnas evidenta al vi, al tiuj, kiuj venas por aŭskulti vin aŭ fari kurson, tute ne estas evidenta. Kaj ĉi tie aperas tia granda tavolo de laboro kaj interna konflikto, pri tio, kion inkludi en la kurso. Kiel rezulto, ni ricevas tian liston de ĉapitroj kun tiel vastaj grandaj strekoj, pri kio la kurso temas.
Kaj tiam komenciĝas la simpla rutina laboro:
- Elekto de materialo
- Legu atente la dokumentadon por la nuna versio, ĉar la IT-mondo nun disvolviĝas je ia kosma rapideco. Eĉ se vi laboras kun io kaj faras kurson pri tio, vi devas iri al la dokumentaro kaj vidi kio estas nova tie, kio estas interesa por paroli, kio povus esti speciale utile mencii.
- Kaj aperas certa skeleto de la kurso, kie la plej multaj el la temoj, ĝenerale, jam estas traktataj kaj ŝajnas, ke kio ajn estas tie - registri filmetojn kaj lanĉi ilin en produktadon.
- Sed fakte, ne, tiam komenciĝas la malfacila laboro, sed ne por la aŭtoroj de la kurso, sed por tiuj, kiuj testas. Kutime niaj alfa-testiloj estas teknika subteno, kiu unue provlegas la kursojn por iuj sintaksaj kaj gramatikaj eraroj. Due, ili dolore batas nin per bastonoj kaj ĵuras, kiam estas iuj tute nevideblaj, nekompreneblaj lokoj. Kiam en la tekstoj aperas iuj komplike kunmetitaj subordigitaj frazoj de paro da paĝoj aŭ evidenta sensencaĵo. Ili legas ĉion, atentu ĝin.
- Tiam komenciĝas la praktika testado, kie ankaŭ kelkaj evidentaj nefunkciantaj aferoj estas kaptitaj kaj kelkaj momentoj estas montritaj, kiuj povas aŭ esti plimalfaciligitaj, ĉar ĝi fariĝas ne tre interesa - nur sidado kaj kopiado - kaj estas identigitaj lokoj kie ĝi estas tre. malfacila kaj ni havas multon por fari, kiun ni volas de homoj, kiuj prenos ĉi tiun kurson. Kaj tiam venas rekomendoj: "Knaboj, simpligu ĝin ĉi tie, estos pli facile percepti kaj estos pli da profito de ĝi."
- Post kiam ĉi tiu kvanto da laboro estas farita, la parto kiu rilatas al la video estas skribita, ĉio ŝajnas esti bona. Kaj vi jam povas donaci ĝin por produktado, por reklamado de ĉi tiu kurso. Sed denove, ne, estas tro frue - ĉar lastatempe ni ĉesis iom fidi al ni mem kaj, principe, komencis pli labori kun sugestoj. Ekzistas tia afero kiel beta-testado - jen kiam homoj estas invititaj de eksteruloj, neniel ligitaj kun nia kompanio, kaj por iuj bonaĵoj oni montras al ili ĉiujn partojn de la kurso, filmetojn, tekstojn, praktikajn taskojn, por ke ili taksi la kvaliton de la materialo, la alireblecon de la materialo kaj helpis nin fari la kurson kiel eble plej bona.
- Kaj kiam pluraj tiaj ripetoj trapasas, parolantoj, alfa-testado en formo de teknika subteno, beta-testado, plibonigoj. Kaj tiam ĉio rekomencas - teknika subteno, beta-testado, plibonigoj.
- Kaj en iu momento venas la kompreno, ke aŭ ni estas finitaj kun modifoj, ĉar estas tute nereale certigi, ke ĉiuj ŝatas ĝin, aŭ iuj drastaj decidoj estas faritaj. Kiam multaj komentoj pri certaj lokoj estas kritikaj, refaru ilin tutmonde, ĉar io misfunkciis.
- Tiam venas la tempo por etaj redaktoj - ie la frazo ne estas tre bele formulita, ie iu ne ŝatas la tiparon, 14,5, sed ŝatus 15,7.
- Kiam ĉi tiu speco de komento restas, tiam jen, la kurso pli-malpli malfermiĝas, komenciĝas oficialaj vendoj.
Kaj unuavide, la mallonga kaj simpla tasko krei kurson montriĝas tute ne simpla kaj daŭras nekredeble longan tempon.
Kaj estas alia grava punkto, ke laboro kun la kurso ne finiĝas kiam la kurso estas liberigita. Unue, ni atente legas la komentojn, kiuj restas sur iuj partoj. Kaj eĉ malgraŭ ĉiuj klopodoj kiujn ni faris, iuj mankoj ankoraŭ estas identigitaj, iuj eraroj estas korektitaj kaj plibonigataj survoje, en reala tempo, por ke ĉiu posta uzanto ricevu pli bonan servon.
Ĉiu kurso havas sian propran produktoposedanton, kiu, krom difini la ĝeneralan koncepton, kontrolas la limdatojn, li notas en la marĝenoj, ke kiam venos la tempo por tute reverki la kurson, kaj ĝi nepre venos, ĉar post du jaroj, aŭ eĉ jaron poste, iuj el tio, kion ni rakontas, fariĝos sensignivaj simple ĉar ĝi malnoviĝos morale. La produktposedanto notas en la marĝenoj, ke plej ofte homoj demandas, kiuj punktoj estis neklaraj, kiaj taskoj ŝajnis tre malfacilaj, kaj kiuj ŝajnis, male, tre simplaj. Kaj ĉio ĉi estas konsiderata dum reregistrado de la kurso, dum ia refaktorado, por ke ĉiu ripeto de la tutmonda kurso fariĝu pli bona, pli oportuna kaj komforta.
Tiel aperas kursoj.
Kiel la Docker-kurso naskiĝis
Ĉi tio estas aparta kaj eĉ nekutima temo por ni. Ĉar unuflanke, ni ne planis fari ĝin, ĉar multaj retaj lernejoj proponas ĝin. Aliflanke, li petis esti liberigita kaj trovis logikan lokon en nia koncepto trejni IT-specialistojn en Kubernetes.
Parolante tre tutmonde, komence ĉio komenciĝis per kurso pri Kubernetes, kiam ĝi ĵus komenciĝis, laŭ mi, post la unua Slurm. Ni kolektis komentojn kaj vidis, ke multaj homoj volas legi ion plian pri Docker ie aliloke, kaj ĝenerale multaj venas al la baza kurso pri Kubernetes sen scii kio ĝi estas. .
Tial, por la dua Slurm ili faris kurson – aŭ pli ĝuste, eĉ ne kurson, sed faris kelkajn ĉapitrojn pri Dockers. Kie ili rakontis iujn el la plej bazaj aferoj, por ke homoj, kiuj venas al la intensiva, ne sentu sin senhavaj kaj ĝenerale komprenu kio okazas.
Kaj tiam la eventoj disvolviĝis proksimume tiel. La kvanto da materialo kreskis kaj ĉesis konveni post 3 tagoj. Kaj aperis logika kaj evidenta ideo: kial ne transformi tion, kion ni kovras ĉe Slurm Basic, en ian malgrandan kurson, al kiu vi povus sendi homojn, kiuj volas spekti ion pri Docker antaŭ ol fari intensan kurson pri Kubernetes.
Slurm Junior estas, fakte, kombinaĵo de pluraj tiaj bazaj kursoj. Kiel rezulto, la Docker-kurso iĝis peco de Slurm Junior. Tio estas, ĉi tio estas tia nula paŝo antaŭe и . Kaj tiam estis nur tre bazaj abstraktaĵoj.
Iam homoj komencis demandi: “Knaboj, ĉio ĉi estas bonega, tio sufiĉas por kompreni, pri kio vi parolas ĉe la intensaj kursoj. Kie mi povas legi pli detale pri tio, kion docker povas fari kaj kiel labori kun ĝi, kaj kio ĝi estas?" Do aperis la ideo por rektigi ĝin , por ke, unue, homoj, kiuj venas al Slurm uzante Kubernetes, ankoraŭ povas esti senditaj al ĝi, kaj aliflanke, por tiuj, kiuj eĉ ne interesiĝas pri Kubernetes en ĉi tiu etapo de evoluo. Por ke IT-specialisto venu spekti nian kurson pri Docker kaj komenci sian evoluan vojon simple per pura Docker. Por ke ni havu tian plenrajtan, kompletan kurson - kaj tiam multaj, spektinte ĉi tiun kurson, laborinte dum iom da tempo kun pura Docker, kreskis ĝis la nivelo kie ili bezonas Kubernetes aŭ iun alian orkestradsistemon. Kaj ili precipe venis al ni.
Foje oni faras la demandon: "Kiaj homoj nun eble ne bezonas Kubernetes?" Sed ĉi tiu demando ne temas pri homoj, ĝi estas prefere pri kompanioj. Ĉi tie vi devas kompreni, ke Kubernetes havas iujn kazojn, kie ĝi bone taŭgas kaj taskojn, kiujn ĝi solvas bone, sed male, ekzistas iuj scenaroj por uzi Kubernetes kiam ĝi kaŭzas plian doloron kaj plian suferon. Tial ĝi eĉ ne dependas de homoj, sed de kiaj kompanioj disvolviĝis kaj dum kiom da tempo.
Ekzemple, ia terura Legacy monolito - vi verŝajne ne devus puŝi ĝin en Kubernetes, ĉar ĝi kaŭzos pli da problemoj ol avantaĝoj. Aŭ, ekzemple, se ĉi tio estas malgranda projekto, ĝi havas malgrandan ŝarĝon aŭ, principe, ne multe da mono kaj rimedoj. Ne utilas treni ĝin en Kubernetes.
Kaj ĝenerale, probable, ĝenerale, kiel multaj homoj jam diris, se vi faras la demandon: "Ĉu mi bezonas Kubernetes?", tiam plej verŝajne vi ne bezonas ĝin. Mi ne memoras, kiu unue elpensis ĝin, laŭ mi, Paŝao Selivanov. Mi konsentas kun ĉi tio 100%. Kaj vi devas kreski al Kubernetes - kaj kiam jam evidentiĝos, ke mi bezonas Kubernetes kaj nia kompanio bezonas ĝin, kaj ĝi helpos solvi tiajn kaj tiajn problemojn, tiam verŝajne havas sencon iri lerni kaj ekscii ĝuste kiel agordi. bone, por ke la procezo ŝanĝi al Kubernetes ne estas tre dolora.
Kelkaj malsanoj de infanoj kaj kelkaj simplaj aferoj, kaj eĉ ne tre simplaj, povas esti eksciitaj precipe de ni, kaj ne trapasi vian propran rastilon kaj doloron.
Multaj kompanioj iris ĝuste tiel, ke komence ekzistis nur ia infrastrukturo sen kontenerigo. Tiam ili atingis la punkton, kie fariĝis malfacile administri ĉion, ili ŝanĝis al Docker kaj iam ili kreskis ĝis la punkto, kie ĝi malvastiĝis en la kadro de Docker kaj kion ĝi ofertas. Kaj ili komencis rigardi kio estis ĉirkaŭe, kiaj sistemoj solvas ĉi tiujn problemojn, kaj precipe Kubernetes - ĉi tiu estas unu el tiuj sistemoj, kiuj permesas vin solvi problemojn kiam pura Docker fariĝas plenplena kaj mankas funkcieco, ĉi tio estas vere bona kazo kiam homoj. Ili iras paŝon post paŝo de malsupre supren, komprenas, ke ĉi tiu teknologio ne sufiĉas kaj moviĝas al la sekva nivelo. Ili uzis ion, ĝi denove malabundiĝis — kaj ili pluiras.
Ĉi tio estas konscia elekto - kaj ĝi estas tre mojosa.
Ĝenerale, mi vidas, ke nia sistemo estas tre bele konstruita, ekzemple, , eĉ per videokursoj. Tiam post docker ĝi iras tiam tiam . Ĉio viciĝas logike - homo pasas kaj solida profesio aperas.
Principe, la aro de kursoj permesas vin kovri multajn kazojn, eĉ modernajn. Ankoraŭ estas areoj, kiuj restas griza areo, mi esperas, ke ni baldaŭ kreos kelkajn kursojn, kiuj permesos al ni fermi ĉi tiujn grizajn areojn, precipe, ni elpensos ion pri sekureco. Ĉar ĉi tio fariĝas tre grava.
Resume, ni havas kelkajn grizajn areojn, kiujn estus tre agrable fermi, tiel ke ĝi estus kompleta, kompleta bildo - kaj homoj povus veni, kaj same kiel Kubernetes mem estas kiel Lego-konstruanto, vi povas fari malsamajn aferojn de ĝi kolektas, se ankoraŭ ne sufiĉas - suplemento, same pri niaj kursoj, por ke homoj komprenu, kion ili bezonas el tio, por kunmeti ian enigmon, ian konstruan aron el niaj kursoj;
Se vi demandas al vi ĝenerale ĝustan kaj honestan demandon: "Kiu povus uzi aktivan Docker-kurson nun?", tiam:
- Por studentoj, kiuj ĵus komencas eniri ĝin.
- Testado de fakaj dungitoj.
- Fakte, estas multaj kompanioj, kiuj ankoraŭ, ne nur ne uzas Docker, sed neniu aŭdis pri tia teknologio kaj, principe, ne scias kiel uzi ĝin. Kaj mi konas plurajn grandajn kompaniojn en Peterburgo, kiuj disvolviĝas dum multaj jaroj, kaj ili uzis kelkajn malnovajn teknologiojn, ili moviĝas en ĉi tiu direkto. Precipe, por tiaj kompanioj, por inĝenieroj en tiaj kompanioj, ĉi tiu kurso povas esti tre interesa, ĉar unue ĝi ebligos vin rapide mergi vin en ĉi tiun teknologion, kaj due, tuj kiam aperos pluraj inĝenieroj, kiuj komprenas kiel ĉio. funkcias, ili povas alporti ĝin al la firmao kaj evoluigi ĉi tiun kulturon kaj ĉi tiujn direktojn ene de la firmao.
- Miaopinie, ĉi tiu kurso ankoraŭ povas esti utila al tiuj, kiuj jam laboris kun docker, sed tre malmulte kaj pli en la stilo "faru unufoje, faru dufoje" - kaj nun ili iel interagos kun la sama Kubernetes, kaj ĉi tio. trudas al ili iujn devojn, se vi havas tre supraĵan scion pri kio estas docker, kiel ruli ĝin, sed samtempe vi ne scias kiel ĝi funkcias de interne, vi ne scias, kio estas plej bone fari kun ili. ĝi kaj kio estas pli bone ne fari, Tiam ĉi tiu kurso bone taŭgas por sistemigi kaj profundigi sciojn.
Sed se vi havas scion je la nivelo de: "Mi ne scias kiel ĝuste skribi la samajn Docker-dosierojn, mi povas imagi, kio estas nomspacoj, kiel ujoj funkcias, kiel ili efektive efektiviĝas je la mastruma sistemo" - tiam estas certe ne utilas iri al ni, vi ne lernos ion novan kaj vi estos iom malĝoja pro la mono kaj tempo elspezita.
Se ni formulas kiajn avantaĝojn havas nia kurso, tiam:
- Ni provis fari ĉi tiun kurson kun sufiĉa nombro da praktikaj kazoj, kiuj permesos al vi ne nur kompreni la teorian parton kiu ekzistas, sed ankaŭ kompreni kial vi bezonas ĝin kaj kiel vi uzos ĝin estonte;
- estas pluraj sekcioj, kiuj tre malofte troviĝas ie ajn – kaj ĝenerale ne estas tiom da materialo pri ili. Ili rilatas al la interago de Docker kun la operaciumo, eĉ iomete malsame. Kiajn mekanismojn Docker prenis de la operaciumo por efektivigi la kontenerigsistemon - kaj tio donas tiom pli profundan komprenon pri la tuta afero pri rulado de ujoj ene de la Linukso-operaciumo. Kiel ĝi funkcias, kiel ĝi interagas inter si ene de la operaciumo, ekstere, ktp.
Ĉi tio estas tiel vere profunda rigardo, ke ĝi okazas sufiĉe malofte, kaj samtempe, laŭ mi, ĝi estas tre grava. Se vi volas bone kompreni iun teknologion kaj kompreni kion atendi de ĝi, vi devas almenaŭ havi ĝeneralan ideon pri kiel ĝi funkcias je malalta nivelo.
Nia kurso montras kaj rakontas kiel tio funkcias el la mastruma vidpunkto. Unuflanke, ĉiuj kontenerigsistemoj uzas la samajn operaciumajn mekanismojn. Aliflanke, ili prenas kio estas en la Linukso operaciumo, kiel docker. Aliaj kontenerigaj sistemoj ne elpensis ion novan - ili prenis tion, kio jam estis en Linukso kaj skribis nur oportunan envolvaĵon, kiu ebligas al vi rapide voki ĝin, ruli ĝin aŭ iel interagi kun ĝi. La sama Docker ne estas tre granda tavolo inter la operaciumo kaj la komandlinio, ĝi estas speco de utileco, kiu ebligas al vi ne skribi kilotunojn da komandoj aŭ ian C-kodon por krei ujon, sed fari tion enirante. paro da linioj en terminalo.
Kaj ankoraŭ unu afero, se ni parolas specife pri Docker, kion Docker vere alportis al la IT-mondo estas normoj. Kiel la aplikaĵo devus esti lanĉita, kiel ĝi devus funkcii, kiuj estas la postuloj por protokoloj, kiaj estas la postuloj por grimpi, agordi la aplikaĵon mem.
Multmaniere, docker temas pri normoj.
Normoj ankaŭ moviĝas al Kubernetes - kaj ekzistas ekzakte la samaj normoj se vi scias bone funkcii vian aplikaĵon en Docker, tiam 99% de la tempo ĝi funkcios same bone en Kubernetes;
Se vi interesiĝis ne nur pri kiel la Docker-kurso estis kreita, sed ankaŭ pri aliaj kursoj, sed ankaŭ interesiĝis pri la kurso mem el praktika vidpunkto, tiam
Ni ĝojos vidi vin!
fonto: www.habr.com