Un participante chega a un curso ou curso intensivo. Ve filas ordenadas de soporte técnico, cables de alimentación ben enrutados, un deseño de taboleiro de xadrez da aula, imaxes brillantes e diagramas de diapositivas. Os oradores con bromas e sorrisos dan información de tal xeito que só tes tempo para entendela. As bancadas están montadas, as tarefas de práctica simplemente che voan dos dedos, agás que ás veces necesitas a axuda de persoal técnico. apoiar.
E tamén pausas café con xente afín, ambiente alegre e enérxico, intercambio de experiencias, preguntas máis inesperadas para os relatores. Tanto respostas como información que non atoparás nos manuais, senón só na práctica.
Canto tempo, esforzo e nervios cres que levou para que se vexa exactamente así?
Grazas a Volodya Guryanov, administrador certificado de Kubernetes e enxeñeiro/xefe de equipo en Southbridge, que foi testemuña e participou activamente na creación de moitos cursos Slurm desde o primeiro momento.
Viu a parte inferior da creación do curso: complexidades e rastrillos espiñentos, ideas e solucións inesperadas. E os xa coñecidos intensivos de Kubernetes, como Slurm Basic e Slurm Mega. E un curso novo, en gran parte revisado , que se achega inexorablemente e comezará o 19 de agosto.
Pero, quizais, abonda coa letra, pasemos á propia historia. Como a partir dun par de temas intensivos un completamente autosuficiente e polifacético . Entón, comezarei a historia de como se crean e desenvolven os cursos, como "Hai moito tempo nunha galaxia moi, moi lonxe...".
Que hai detrás das escenas?
Se preguntas como facemos os cursos e onde comeza todo, simplemente responderei "Todo comeza cunha idea".
Normalmente a idea vén dalgún lugar: non nos quedamos esposados no soto ata que chegamos a dicir: "Sobre que tema debemos facer un curso?" As ideas veñen dalgún lugar por si soas de fontes externas. Ás veces, a xente comeza a preguntar activamente: "Que sabes sobre tal ou tal tecnoloxía específica?" Ou como foi con Docker que foi imposible encaixar no tempo para o curso intensivo - obviamente tiña que ser levado fóra para ter tempo para contar algo durante o curso intensivo.
Así aparece unha idea.
Despois de que se anunciara, na miña opinión, comeza o momento máis difícil -para entender xeralmente o que hai que incluír neste curso-, isto é moi comparable coa forma en que os relatores están preparados para calquera conferencia.
Hai unha dor principal cando pareces que escolliches un tema e pensas: "Que podo dicir sobre iso? Isto é demasiado sinxelo, isto é obvio, todo o mundo tamén o sabe".
Pero en realidade non é o caso en absoluto. E eu persoalmente digo en moitos sitios que o que che parece obvio, aos que veñen escoitarte ou facer un curso, non é nada evidente. E aquí xorde unha capa tan grande de traballo e conflito interno, sobre o que incluír no curso. Como resultado, obtemos unha lista de capítulos con trazos tan grandes, sobre o que vai tratar o curso.
E entón comeza o traballo rutineiro sinxelo:
- Selección de material
- Lea atentamente a documentación da versión actual, xa que o mundo das TI está a desenvolverse a unha velocidade cósmica. Aínda que traballes con algo e fas un curso sobre iso, tes que ir á documentación e ver que hai de novo, que é interesante falar, que pode ser especialmente útil mencionar.
- E aparece un certo esqueleto do curso, onde a maioría dos temas, en xeral, xa están tratados e parece que hai o que haxa: gravar vídeos e lanzaros á produción.
- Pero de feito, non, entón comeza o duro traballo, pero non para os autores do curso, senón para os que proban. Normalmente os nosos probadores alfa son soporte técnico, que, en primeiro lugar, revisa os cursos para detectar erros sintácticos e gramaticais. En segundo lugar, pégannos dolorosamente con paus e xuran cando hai lugares completamente pouco obvios, incomprensibles. Cando aparecen nos textos unhas oracións subordinadas complexas de un par de páxinas ou un disparate evidente. Lérono todo, ollo.
- Despois comeza a fase de probas prácticas, onde tamén se captan algunhas cousas obvias que non funcionan e móstranse algúns momentos que ou ben se poden facer máis difíciles, xa que se fai pouco interesante -só sentarse e copiar- e se identifican lugares onde é moi. difícil e temos moito que facer que queremos da xente que vai facer este curso. E despois veñen as recomendacións: "Rapaces, facémolo máis sinxelo aquí, será máis fácil de percibir e haberá máis beneficios".
- Despois de facer esta cantidade de traballo, escribe a parte que se relaciona co vídeo, todo parece estar ben. E xa o podes doar para a produción, para a publicidade deste curso. Pero, de novo, non, é demasiado cedo, porque recentemente deixamos de confiar un pouco en nós mesmos e, en principio, comezamos a traballar máis cos comentarios. Hai algo como as probas beta: é cando se convidan persoas de fóra, que non están conectadas coa nosa empresa de ningún xeito, e para algunhas golosinas móstranse todas as partes do curso, vídeos, texto, tarefas prácticas, para que avaliar a calidade do material, a accesibilidade do material e axudounos a facer o curso o mellor posible.
- E cando pasan varias iteracións deste tipo, altofalantes, probas alfa en forma de soporte técnico, probas beta, melloras. E entón todo comeza de novo: soporte técnico, probas beta, melloras.
- E nalgún momento, chega a entender que ou acabamos coas modificacións, porque é totalmente irreal asegurarnos de que gusta a todos, ou se toman algunhas decisións drásticas. Cando moitos comentarios sobre determinados lugares sexan críticos, volve facelos globalmente, porque algo saíu mal.
- Entón chega o momento das modificacións menores: nalgún lugar a frase non está moi ben formulada, nalgún lugar a alguén non lle gusta o tipo de letra, 14,5, pero querería 15,7.
- Cando queda este tipo de comentarios, xa está, máis ou menos ábrese o curso, comezan as vendas oficiais.
E a primeira vista, a tarefa curta e sinxela de crear un curso resulta que non é nada sinxela e leva un tempo incriblemente longo.
E hai outro punto importante que o traballo co curso non remata cando o curso é lanzado. En primeiro lugar, lemos atentamente os comentarios que se deixan en determinadas partes. E aínda a pesar de todos os esforzos que fixemos, aínda están identificados algúns fallos, algúns erros están sendo corrixidos e mellorando no camiño, en tempo real, para que cada usuario posterior reciba un mellor servizo.
Cada curso ten o seu propio produtor, que ademais de definir o concepto xeral, comproba os prazos, fai anotacións nas marxes que cando chegue o momento de reescribir o curso por completo, e definitivamente chegará, porque dentro de dous anos, ou mesmo un ano despois, algo do que contamos pasará a ser irrelevante simplemente porque quedará moralmente obsoleto. O propietario do produto fai notas nas marxes que a maioría das veces a xente pregunta que puntos estaban pouco claros, que tarefas parecían moi difíciles e cales parecían, pola contra, moi sinxelas. E todo isto tense en conta á hora de volver a gravar o curso, durante algún tipo de refactorización, para que cada iteración do curso global sexa mellor, máis cómoda e cómoda.
Así aparecen os cursos.
Como naceu o curso Docker
Este é un tema separado e mesmo inusual para nós. Porque por unha banda, non pensamos facelo, porque moitas escolas en liña o ofrecen. Por outra banda, el mesmo pediu liberdade e atopou un lugar lóxico no noso concepto de formación de especialistas informáticos en Kubernetes.
Falando de xeito moi global, inicialmente todo comezou cun curso sobre Kubernetes, cando só comezou, na miña opinión, despois do primeiro Slurm. Recollemos comentarios e vimos que moita xente quere ler algo adicional sobre Docker noutro lugar e, en xeral, moitos chegan ao curso básico sobre Kubernetes sen saber o que é .
Polo tanto, para o segundo Slurm fixeron un curso, ou mellor dito, nin sequera un curso, senón que fixeron un par de capítulos sobre Dockers. Onde contaron algunhas das cousas máis básicas, para que a xente que acuda ao intensivo non se sinta privada e entenda en xeral o que pasaba.
E entón os acontecementos desenvolveron máis ou menos así. A cantidade de material creceu e deixou de encaixar en 3 días. E apareceu unha idea lóxica e obvia: por que non converter o que tratamos en Slurm Basic nunha especie de pequeno curso ao que poderías enviar a xente que queira ver algo sobre Docker antes de facer un curso intensivo de Kubernetes.
Slurm Junior é, de feito, unha combinación de varios cursos básicos deste tipo. Como resultado, o curso Docker converteuse nunha peza de Slurm Junior. É dicir, este é un paso cero antes и . E despois só había abstraccións moi básicas.
Nalgún momento, a xente comezou a preguntar: “Rapaces, todo isto é xenial, abonda para entender do que falades nos cursos intensivos. Onde podo ler con máis detalle o que pode facer docker e como traballar con el, e que é?" Entón xurdiu a idea de facelo ben claro , para que, en primeiro lugar, as persoas que veñan a Slurm usando Kubernetes aínda poidan ser enviadas a el e, por outra banda, para aqueles que nin sequera estean interesados en Kubernetes nesta fase de desenvolvemento. Para que un especialista en TI poida vir ver o noso curso sobre Docker e comezar o seu camiño evolutivo simplemente con Docker puro. Para que teñamos un curso completo e completo, e despois moitos, despois de ver este curso, de traballar durante algún tempo con Docker puro, chegaron ao nivel no que necesitan Kubernetes ou algún outro sistema de orquestración. E viñeron a nós en particular.
Ás veces faise a pregunta: "Que tipo de persoas agora poden non necesitar Kubernetes?" Pero esta pregunta non é sobre persoas, é máis ben unha pregunta sobre empresas. Aquí cómpre entender que Kubernetes ten certos casos nos que se adapta ben e tarefas que resolve ben, pero, pola contra, hai algúns escenarios para usar Kubernetes cando provoca dor adicional e sufrimento adicional. Polo tanto, nin sequera depende das persoas, senón de que empresas veñen desenvolvendo e durante canto tempo.
Por exemplo, un monólito Legacy terrible: probablemente non deberías introducilo en Kubernetes, porque causará máis problemas que beneficios. Ou, por exemplo, se se trata dun proxecto pequeno, ten unha pequena carga ou, en principio, poucos cartos e recursos. Non ten sentido arrastralo a Kubernetes.
E en xeral, probablemente, en xeral, como xa dixo moita xente, se estás facendo a pregunta: "Necesito Kubernetes?", entón o máis probable é que non o necesites. Non lembro quen o inventou primeiro, na miña opinión, Pasha Selivanov. Estou de acordo con isto ao 100%. E cómpre crecer ata Kubernetes, e cando xa quede claro que necesito Kubernetes e a nosa empresa necesítao, e iso axudará a resolver tales ou tales problemas, probablemente teña sentido ir aprender e descubrir exactamente como configurar. ben, para que o proceso de cambio a Kubernetes non sexa moi doloroso.
Algunhas doenzas dos nenos e algunhas cousas sinxelas, e mesmo non moi sinxelas, pódense descubrir en particular por nós, e non pasar pola túa propia dor.
Moitas empresas seguiron exactamente o camiño que nun principio só había algún tipo de infraestrutura sen contenerización. Despois chegaron ao punto no que se fixo difícil xestionalo todo, cambiaron a Docker e nalgún momento creceron ata o punto de que se abarrou no marco de Docker e o que ofrece. E comezaron a mirar o que había ao redor, que sistemas resolven estes problemas e, en particular, Kubernetes: este é un deses sistemas que che permiten resolver problemas cando o Docker puro se abarrota e carece de funcionalidade, este é un bo caso cando a xente Van paso a paso de abaixo cara arriba, entenden que esta tecnoloxía non é suficiente e pasan ao seguinte nivel. Usaron algo, volveu escasear e seguiron adiante.
Esta é unha elección consciente e é moi xenial.
En xeral, vexo que o noso sistema está moi ben construído, por exemplo, , incluso a través de cursos de vídeo. Despois, despois do docker vai entón entón . Todo se alinea loxicamente: unha persoa pasa e xorde unha profesión sólida.
En principio, o conxunto de cursos permite cubrir moitos casos, incluso modernos. Aínda quedan zonas que seguen sendo unha zona gris, espero que en breve creemos algúns cursos que nos permitan pechar estas zonas grises, en concreto, sairemos algo de seguridade. Porque isto está a ser moi relevante.
En resumo, temos algunhas zonas grises que sería moi agradable pechar, para que fose unha imaxe completa e completa, e a xente podería vir, e do mesmo xeito que o propio Kubernetes é como un construtor de Lego, podes facer cousas diferentes de recolle, se aínda non hai suficiente, suplemento, o mesmo cos nosos cursos, para que a xente poida entender o que precisa disto, precisan montar unha especie de puzzle, unha especie de conxunto de construción dos nosos cursos.
Se che fai unha pregunta xeralmente correcta e honesta: "Quen podería usar un curso de Docker activo agora?", entón:
- Para os estudantes que están empezando a entrar.
- Empregados do departamento de probas.
- De feito, hai moitas empresas que aínda, non só non usan Docker, senón que ninguén escoitou falar desta tecnoloxía e, en principio, non saben como usala. E coñezo varias grandes empresas en San Petersburgo que levan moitos anos desenvolvendo, e empregaron algunhas tecnoloxías antigas, están a moverse nesta dirección. En particular, para tales empresas, para enxeñeiros destas empresas, este curso pode ser moi interesante, xa que, en primeiro lugar, permitirache mergullarche rapidamente nesta tecnoloxía e, en segundo lugar, en canto aparezan varios enxeñeiros que entendan como todo. funciona, poden achegalo á empresa e desenvolver esta cultura e estas direccións dentro da empresa.
- Na miña opinión, este curso aínda pode ser útil para aqueles que xa traballaron con Docker, pero moi pouco e máis no estilo "facer unha vez, facer dúas veces" - e agora van interactuar dalgún xeito co mesmo Kubernetes, e isto impónlles certas obrigas, se tes un coñecemento moi superficial do que é o docker, de como executalo, pero ao mesmo tempo non sabes como funciona dende dentro, non sabes que é mellor facer con el. el e o que é mellor non facer, Entón este curso é moi axeitado para sistematizar e afondar no coñecemento.
Pero se tes coñecementos a nivel de: "Non sei como escribir correctamente os mesmos ficheiros Docker, podo imaxinar cales son os espazos de nomes, como funcionan os contedores, como se implementan realmente a nivel de sistema operativo" - entón hai definitivamente non ten sentido acudir a nós, non aprenderás nada novo e estarás un pouco triste polo diñeiro e o tempo gastado.
Se formulamos que vantaxes ten o noso curso, entón:
- Intentamos facer este curso cun número suficiente de casos prácticos que che permitan non só comprender a parte teórica que existe, senón tamén comprender por que o necesitas e como o utilizarás no futuro;
- hai varias seccións que moi raramente se atopan en calquera lugar e, en xeral, non hai tanto material sobre elas. Relacionanse coa interacción de Docker co sistema operativo, aínda que sexa un pouco diferente. Que mecanismos tomou Docker do sistema operativo para implementar o sistema de contenedores? Como funciona, como interactúa entre si dentro do sistema operativo, fóra, etc.
Esta é unha mirada tan profunda que ocorre en poucas ocasións e, ao mesmo tempo, na miña opinión, é moi importante. Se queres comprender ben calquera tecnoloxía e comprender o que esperar dela, debes ter polo menos unha idea xeral de como funciona a un nivel baixo.
O noso curso mostra e conta como funciona isto desde o punto de vista do sistema operativo. Por unha banda, todos os sistemas de contenerización utilizan os mesmos mecanismos do sistema operativo. Por outra banda, levan o que hai no sistema operativo Linux, como docker. Outros sistemas de contenedores non presentaron nada novo: tomaron o que xa estaba en Linux e escribiron só un envoltorio cómodo que che permite chamalo, executalo ou interactuar dalgún xeito con el. O mesmo Docker non é unha capa moi grande entre o sistema operativo e a liña de comandos, é unha especie de utilidade que permite non escribir quilotóns de comandos ou algún tipo de código C para crear un contenedor, senón para facelo ingresando un par de liñas no terminal.
E unha cousa máis, se falamos específicamente de Docker, o que realmente trouxo Docker ao mundo das TI son os estándares. Como se debe iniciar a aplicación, como debe funcionar, cales son os requisitos para os rexistros, cales son os requisitos para a escala, a configuración da propia aplicación.
En moitos sentidos, docker trata de estándares.
Os estándares tamén se están mudando a Kubernetes, e hai exactamente os mesmos estándares; se sabes como executar ben a túa aplicación en Docker, o 99 % das veces funcionará igual de ben en Kubernetes.
Se che interesou non só como se creou o curso Docker, senón tamén noutros cursos, senón tamén polo propio curso desde un punto de vista práctico, entón
Estaremos encantados de verte!
Fonte: www.habr.com