Un partecipante viene ad un corso o ad un corso intensivo. Vede file ordinate di supporto tecnico, cavi di alimentazione ben disposti, una disposizione a scacchiera dell'aula magna, immagini luminose e diagrammi di diapositive. Gli oratori con battute e sorrisi danno informazioni in modo tale che tu abbia appena il tempo di capirle. Gli spalti sono allestiti, le esercitazioni ti volano via dalle dita, tranne che a volte hai bisogno dell'aiuto dello staff tecnico. supporto.
E anche pause caffè con persone che la pensano allo stesso modo, un'atmosfera allegra ed energica, scambio di esperienze, le domande più inaspettate per i relatori. Sia risposte che informazioni che non troverai nei manuali, ma solo nella pratica.
Quanto tempo, impegno e nervi pensi che ci siano voluti per farlo sembrare esattamente così?
Grazie a Volodya Guryanov, amministratore Kubernetes certificato e ingegnere/team leader presso Southbridge, che ha assistito e partecipato attivamente alla creazione di molti corsi Slurm fin dall'inizio.
Vide il ventre della creazione: complessità e spinosi, intuizioni e soluzioni inaspettate. E i già familiari programmi intensivi di Kubernetes, come Slurm Basic e Slurm Mega. E un corso nuovo, ampiamente rivisto , che si avvicina inesorabilmente e avrà inizio il 19 agosto.
Ma forse basta con i testi, passiamo alla storia in sé. Come da un paio di argomenti intensivi a uno completamente autosufficiente e sfaccettato . Quindi inizierò la storia di come vengono creati e sviluppati i corsi, proprio come "Tanto tempo fa, in una galassia lontana lontana..."
Cosa c'è dietro le quinte?
Se mi chiedi come realizziamo i corsi e da dove tutto inizia, risponderò semplicemente “Tutto inizia con un’idea”.
Di solito l'idea viene da qualche parte: non ci sediamo ammanettati nel seminterrato finché non ci viene in mente: "Su quale argomento dovremmo fare un corso?" Le idee provengono da qualche parte da fonti esterne. A volte le persone iniziano a chiedere attivamente: "Cosa sai di questa o quella tecnologia specifica?" O come nel caso di Docker fosse impossibile inserirlo nei tempi del corso intensivo: ovviamente doveva essere portato fuori per avere il tempo di raccontare qualcosa durante il corso intensivo.
Ecco come appare un'idea.
Dopo l'annuncio, secondo me, inizia il momento più difficile - capire in generale cosa includere in questo corso - questo è molto paragonabile al modo in cui vengono preparati i relatori per qualsiasi conferenza.
C'è un dolore principale quando sembra che tu abbia scelto un argomento e pensi: “Cosa posso dire al riguardo? Questo è troppo semplice, questo è ovvio, anche questo lo sanno tutti”.
Ma in realtà non è affatto così. E personalmente dico in molti luoghi che quello che sembra ovvio a te, a chi viene ad ascoltarti o a fare un corso, non lo è affatto. E qui sorge uno strato così ampio di lavoro e conflitto interno su cosa includere nel corso. Di conseguenza, otteniamo un elenco di capitoli con tratti così ampi, di cosa parlerà il corso.
E poi inizia il semplice lavoro di routine:
- Selezione del materiale
- Leggi attentamente la documentazione per la versione attuale, poiché il mondo IT si sta sviluppando a una sorta di velocità cosmica. Anche se lavori con qualcosa e fai un corso al riguardo, devi andare alla documentazione e vedere cosa c’è di nuovo, cosa è interessante di cui parlare, cosa potrebbe essere particolarmente utile menzionare.
- E appare un certo scheletro del corso, dove la maggior parte degli argomenti, in generale, sono già trattati e sembra che qualunque cosa ci sia: registra video e lanciali in produzione.
- Ma in effetti no, poi inizia il duro lavoro, ma non per gli autori del corso, ma per chi testa. Di solito i nostri alpha tester sono il supporto tecnico, che, in primo luogo, corregge le bozze dei corsi per eventuali errori sintattici e grammaticali. In secondo luogo, ci picchiano dolorosamente con bastoni e imprecano quando ci sono luoghi completamente non ovvi e incomprensibili. Quando nei testi compaiono alcune frasi subordinate composte in modo complesso di un paio di pagine o ovvie sciocchezze. Lo leggono tutto, fate attenzione.
- Poi inizia la fase di prova pratica, in cui vengono colte anche alcune cose ovvie che non funzionano e vengono mostrati alcuni momenti che possono essere resi più difficili, poiché diventa poco interessante - semplicemente sedersi e copiare - e vengono individuati i luoghi in cui è molto difficile e abbiamo molto da fare e vogliamo dalle persone che seguiranno questo corso. E poi arrivano le raccomandazioni: "Ragazzi, rendetelo più semplice qui, sarà più facile da percepire e ne trarranno maggiori benefici".
- Una volta terminata questa mole di lavoro, viene scritta la parte relativa al video, sembra che tutto vada bene. E puoi già donarlo per la produzione, per pubblicizzare questo corso. Ma ancora una volta no, è troppo presto, perché recentemente abbiamo smesso di fidarci un po' di noi stessi e, in linea di principio, abbiamo iniziato a lavorare di più con il feedback. Esiste il beta testing: questo avviene quando le persone vengono invitate da persone esterne, non collegate in alcun modo alla nostra azienda, e per alcuni gadget vengono mostrate loro tutte le parti del corso, video, testi, attività pratiche, in modo che possano valutare la qualità del materiale, l'accessibilità del materiale e ci ha aiutato a rendere il corso il migliore possibile.
- E quando vengono eseguite diverse iterazioni di questo tipo, relatori, test alfa sotto forma di supporto tecnico, test beta, miglioramenti. E poi tutto ricomincia da capo: supporto tecnico, beta testing, miglioramenti.
- E ad un certo punto si capisce che o abbiamo finito con le modifiche, perché è del tutto irrealistico assicurarsi che piaccia a tutti, o che vengono prese alcune decisioni drastiche. Quando molti commenti su determinati luoghi sono critici, rifarli a livello globale, perché qualcosa è andato storto.
- Poi arriva il momento delle piccole modifiche: da qualche parte la frase non è formulata molto bene, da qualche parte a qualcuno non piace il carattere 14,5, ma vorrebbe 15,7.
- Quando rimane questo tipo di commento, allora basta, il corso più o meno si apre, iniziano le vendite ufficiali.
E a prima vista, il compito breve e semplice di creare un corso risulta non essere affatto semplice e richiede un tempo incredibilmente lungo.
E c'è un altro punto importante: il lavoro con il corso non termina con la pubblicazione del corso. Innanzitutto leggiamo attentamente i commenti lasciati su alcune parti. E nonostante tutti gli sforzi che abbiamo fatto, alcuni difetti vengono ancora identificati, alcuni errori vengono corretti e migliorati lungo il percorso, in tempo reale, in modo che ogni utente successivo riceva un servizio migliore.
Ogni corso ha un proprio product Owner, che oltre a definire il concept generale, controlla le scadenze, prende appunti a margine che quando arriverà il momento di riscrivere completamente il corso, e arriverà sicuramente, perché tra due anni, o anche un anno dopo, parte di ciò che raccontiamo diventerà irrilevante semplicemente perché diventerà moralmente obsoleto. Il proprietario del prodotto prende nota a margine che molto spesso le persone chiedono quali punti non erano chiari, quali compiti sembravano molto difficili e quali, al contrario, sembravano molto semplici. E tutto ciò viene preso in considerazione quando si registra nuovamente il corso, durante una sorta di refactoring, in modo che ogni iterazione del corso globale diventi migliore, più conveniente e confortevole.
Ecco come appaiono i corsi.
Come è nato il corso Docker
Questo è un argomento separato e persino insolito per noi. Perché da un lato non avevamo intenzione di farlo, perché molte scuole online lo offrono. D'altra parte, ha chiesto di essere rilasciato e ha trovato un posto logico nel nostro concetto di formazione di specialisti IT in Kubernetes.
Parlando in modo molto globale, inizialmente tutto è iniziato con un corso su Kubernetes, quando secondo me era appena iniziato dopo il primo Slurm. Abbiamo raccolto feedback e abbiamo visto che molte persone vogliono leggere qualcosa in più su Docker da qualche altra parte, e in generale molti arrivano al corso base su Kubernetes senza sapere di cosa si tratta .
Pertanto, per il secondo Slurm hanno realizzato un corso - o meglio, nemmeno un corso, ma hanno realizzato un paio di capitoli su Dockers. Dove hanno raccontato alcune delle cose più elementari, in modo che le persone che vengono all'intensivo non si sentano private e capiscano generalmente cosa sta succedendo.
E poi gli eventi si sono sviluppati più o meno così. La quantità di materiale è cresciuta e ha smesso di adattarsi in 3 giorni. Ed è apparsa un'idea logica e ovvia: perché non trasformare ciò che trattiamo a Slurm Basic in una sorta di piccolo corso a cui inviare le persone che vogliono vedere qualcosa su Docker prima di seguire un corso intensivo su Kubernetes.
Slurm Junior è, infatti, una combinazione di diversi corsi base di questo tipo. Di conseguenza, il corso Docker è diventato una parte di Slurm Junior. Cioè, questo è un passo zero prima и . E poi c'erano solo astrazioni molto elementari.
Ad un certo punto la gente ha cominciato a chiedersi: “Ragazzi, è tutto fantastico, basta questo per capire di cosa si parla ai corsi intensivi. Dove posso leggere più in dettaglio cosa può fare Docker, come lavorarci e di cosa si tratta?" Quindi è venuta l'idea di mettere le cose in chiaro , in modo che, in primo luogo, le persone che arrivano a Slurm utilizzando Kubernetes possano ancora essere inviate ad esso e, dall'altro, per coloro che non sono nemmeno interessati a Kubernetes in questa fase di sviluppo. Perché uno specialista IT possa venire a vedere il nostro corso su Docker e iniziare il suo percorso evolutivo semplicemente con Docker puro. In modo da avere un corso così completo e completo - e poi molti, dopo aver guardato questo corso, avendo lavorato per un po 'con Docker puro, sono cresciuti al livello in cui hanno bisogno di Kubernetes o di qualche altro sistema di orchestrazione. E sono venuti da noi in particolare.
A volte viene posta la domanda: “Che tipo di persone oggi potrebbero non aver bisogno di Kubernetes?” Ma questa domanda non riguarda le persone, bensì le aziende. Qui devi capire che Kubernetes ha alcuni casi in cui è adatto e compiti che risolve bene, ma al contrario, ci sono alcuni scenari per l'utilizzo di Kubernetes quando provoca ulteriore dolore e ulteriore sofferenza. Quindi non dipende nemmeno dalle persone, ma da cosa le aziende stanno sviluppando e da quanto tempo.
Ad esempio, qualche terribile monolite Legacy: probabilmente non dovresti inserirlo in Kubernetes, perché causerà più problemi che benefici. Oppure, ad esempio, se si tratta di un piccolo progetto, ha un carico limitato o, in linea di principio, non molti soldi e risorse. Non ha senso trascinarlo in Kubernetes.
E in generale, probabilmente, in generale, come molti hanno già detto, se ti poni la domanda: "Ho bisogno di Kubernetes?", molto probabilmente non ne hai bisogno. Non ricordo chi l'ha inventato per primo, secondo me, Pasha Selivanov. Sono d'accordo con questo al 100%. E devi crescere con Kubernetes - e quando diventa già chiaro che ho bisogno di Kubernetes e la nostra azienda ne ha bisogno, e aiuterà a risolvere questi e quei problemi, allora probabilmente ha senso imparare e capire esattamente come impostare tutto bene, in modo che il processo di passaggio a Kubernetes non sia molto doloroso.
Alcuni disturbi dei bambini e alcune cose semplici, anche non molto semplici, possono essere scoperti soprattutto da noi, e non passare attraverso la propria durezza e sofferenza.
Molte aziende hanno seguito esattamente la strada che all’inizio esisteva solo una sorta di infrastruttura senza containerizzazione. Poi sono arrivati al punto in cui è diventato difficile gestire tutto, sono passati a Docker e ad un certo punto sono cresciuti fino al punto in cui è diventato angusto nell’ambito di Docker e di ciò che offre. E hanno iniziato a guardare cosa c'era intorno, quali sistemi risolvono questi problemi, e in particolare Kubernetes - questo è uno di quei sistemi che ti permette di risolvere problemi quando Docker puro diventa affollato e privo di funzionalità, questo è davvero un buon caso quando le persone Procedono passo dopo passo dal basso verso l’alto, capiscono che questa tecnologia non è sufficiente e passano al livello successivo. Hanno usato qualcosa, è diventato di nuovo scarso e se ne vanno.
Questa è una scelta consapevole ed è molto interessante.
In generale, vedo che il nostro sistema è costruito molto bene, ad esempio, , anche attraverso videocorsi. Quindi dopo la finestra mobile va , quindi , quindi . Tutto si allinea logicamente: una persona passa ed emerge una solida professione.
In linea di principio, l'insieme dei corsi consente di coprire molti casi, anche moderni. Ci sono ancora delle zone che restano grigie, spero che presto creeremo dei corsi che ci permettano di chiudere queste zone grigie, in particolare ci inventeremo qualcosa riguardo alla sicurezza. Perché questo sta diventando molto rilevante.
In breve, abbiamo alcune aree grigie che sarebbe molto bello chiudere, in modo che ci fosse un quadro completo, completo - e le persone potrebbero venire, e proprio come lo stesso Kubernetes è come un costruttore Lego, puoi creare cose diverse da raccoglie, se ancora non ce n'è abbastanza - integra, lo stesso con i nostri corsi, in modo che le persone possano capire di cosa hanno bisogno da questo, devono assemblare una sorta di puzzle, una sorta di set di costruzioni dai nostri corsi;
Se ti poni una domanda generalmente corretta e onesta: “Chi potrebbe utilizzare un corso Docker attivo adesso?”, allora:
- Per gli studenti che stanno appena iniziando ad avvicinarsi.
- Dipendenti del reparto test.
- Sono infatti molte le aziende che ancora non solo non utilizzano Docker, ma nessuno ha mai sentito parlare di tale tecnologia e, in linea di principio, non sa come utilizzarla. E conosco diverse grandi aziende a San Pietroburgo che si stanno sviluppando da molti anni e hanno utilizzato alcune vecchie tecnologie, si stanno muovendo in questa direzione. In particolare, per tali aziende, per gli ingegneri di tali aziende, questo corso può essere molto interessante, poiché, in primo luogo, ti consentirà di immergerti rapidamente in questa tecnologia e, in secondo luogo, non appena compaiono diversi ingegneri che capiscono come tutto ciò funziona, possono portarlo in azienda e sviluppare questa cultura e queste direzioni all'interno dell'azienda.
- Secondo me, questo corso potrebbe essere ancora utile a coloro che hanno già lavorato con docker, ma molto poco e più nello stile "fai una volta, fai due volte" - e ora interagiranno in qualche modo con lo stesso Kubernetes, e questo impone loro determinati obblighi, se hai una conoscenza molto superficiale di cosa sia docker, come eseguirlo, ma allo stesso tempo non sai come funziona dall'interno, non sai cosa è meglio farne e cosa è meglio non fare, allora questo corso è adatto per sistematizzare e approfondire la conoscenza.
Ma se hai una conoscenza a livello di: "Non so come scrivere correttamente gli stessi file Docker, posso immaginare cosa sono gli spazi dei nomi, come funzionano i contenitori, come sono effettivamente implementati a livello di sistema operativo" - allora c'è sicuramente non ha senso venire da noi, non imparerai nulla di nuovo e sarai un po’ triste per i soldi e il tempo spesi.
Se formuliamo quali vantaggi ha il nostro corso, allora:
- Abbiamo cercato di realizzare questo corso con un numero sufficiente di casi pratici che ti permetteranno non solo di comprendere la parte teorica che esiste, ma anche di capire perché ne hai bisogno e come la utilizzerai in futuro;
- ci sono diverse sezioni che molto raramente si trovano da nessuna parte - e in generale non c'è molto materiale su di esse. Si riferiscono all'interazione di Docker con il sistema operativo, anche in modo leggermente diverso. Quali meccanismi ha preso Docker dal sistema operativo per implementare il sistema di containerizzazione - e questo fornisce una comprensione così più profonda dell'intera questione dell'esecuzione dei container all'interno del sistema operativo Linux. Come funziona, come interagisce tra loro all'interno del sistema operativo, all'esterno e così via.
Questo è uno sguardo davvero profondo che accade abbastanza raramente e allo stesso tempo, secondo me, è molto importante. Se vuoi comprendere bene qualsiasi tecnologia e capire cosa aspettarti da essa, devi avere almeno un'idea generale di come funziona a basso livello.
Il nostro corso mostra e racconta come funziona dal punto di vista del sistema operativo. Da un lato, tutti i sistemi di containerizzazione utilizzano gli stessi meccanismi del sistema operativo. D'altra parte, prendono ciò che è presente nel sistema operativo Linux, come docker. Altri sistemi di containerizzazione non hanno inventato nulla di nuovo: hanno preso ciò che era già in Linux e hanno scritto solo un comodo wrapper che ti consente di chiamarlo, eseguirlo o interagire in qualche modo con esso rapidamente. Lo stesso Docker non è uno strato molto ampio tra il sistema operativo e la riga di comando, è una sorta di utility che consente di non scrivere kilotoni di comandi o qualche tipo di codice C per creare un contenitore, ma di farlo inserendo un paio di righe nel terminale.
E ancora una cosa, se parliamo specificamente di Docker, ciò che Docker ha realmente portato nel mondo IT sono gli standard. Come dovrebbe essere avviata l'applicazione, come dovrebbe funzionare, quali sono i requisiti per i log, quali sono i requisiti per la scalabilità, configurazione dell'applicazione stessa.
In molti modi, Docker riguarda gli standard.
Anche gli standard si stanno spostando su Kubernetes e ci sono esattamente gli stessi standard; se sai come eseguire bene la tua applicazione in Docker, il 99% delle volte funzionerà altrettanto bene all'interno di Kubernetes.
Se ti sei trovato interessato non solo a come è stato realizzato il corso Docker, ma anche ad altri corsi, ma interessato anche al corso stesso dal punto di vista pratico, allora
Saremo lieti di vederti!
Fonte: habr.com