Um participante vem para um curso ou curso intensivo. Ele vê fileiras ordenadas de suporte técnico, cabos de energia bem posicionados, um layout xadrez da sala de aula, imagens brilhantes e diagramas de slides. Palestrantes com piadas e sorrisos divulgam informações de tal forma que você só tem tempo de entendê-las. Os estandes estão montados, as tarefas práticas simplesmente escapam dos seus dedos, só que às vezes você precisa da ajuda da equipe técnica. apoiar.
E também coffee breaks com pessoas afins, ambiente alegre e energético, troca de experiências, as perguntas mais inesperadas para os palestrantes. Tanto respostas quanto informações que você não encontrará em manuais, mas apenas na prática.
Quanto tempo, esforço e nervosismo você acha que foram necessários para que ficasse exatamente assim?
Obrigado a Volodya Guryanov, administrador certificado do Kubernetes e engenheiro/líder de equipe em Southbridge, que testemunhou e participou ativamente na criação de muitos cursos Slurm desde o início.
Ele viu o ponto fraco da criação do curso – complexidades e ancinhos espinhosos, insights e soluções inesperadas. E os já familiares intensivos do Kubernetes, como Slurm Basic e Slurm Mega. E um curso novo e amplamente revisado , que se aproxima inexoravelmente e terá início no dia 19 de agosto.
Mas, talvez, chega de letras, vamos passar para a história em si. Como a partir de alguns tópicos intensivos um ambiente completamente autossuficiente e multifacetado . Então vou começar a história de como os cursos são criados e desenvolvidos - assim como “Há muito tempo atrás, em uma galáxia muito, muito distante...”
O que há nos bastidores?
Se você perguntar como fazemos cursos e onde tudo começa, responderei simplesmente “Tudo começa com uma ideia”.
Normalmente a ideia vem de algum lugar - não ficamos algemados no porão até que pensemos: “Sobre qual assunto devemos fazer um curso?” As ideias vêm de algum lugar por conta própria, de fontes externas. Às vezes as pessoas começam a perguntar ativamente: “O que você sabe sobre tal ou tal tecnologia específica?” Ou como foi com Docker que foi impossível encaixá-lo no horário do curso intensivo - ele obviamente teve que ser levado para fora para ter tempo de contar alguma coisa durante o curso intensivo.
É assim que surge uma ideia.
Depois de anunciado, na minha opinião, começa o momento mais difícil - entender de forma geral o que incluir neste curso - isso é muito comparável à forma como os palestrantes são preparados para qualquer conferência.
Há uma dor principal quando você parece ter escolhido um tema e pensa: “O que posso dizer sobre isso? Isso é muito simples, isso é óbvio, todo mundo sabe disso também.”
Mas, na verdade, este não é o caso. E eu pessoalmente digo em muitos lugares que o que parece óbvio para você, para quem vem te ouvir ou fazer um curso, não é nada óbvio. E aqui surge uma camada tão grande de trabalho e conflito interno sobre o que incluir no curso. Como resultado, obtemos uma lista de capítulos com traços tão abrangentes, sobre o que tratará o curso.
E então começa o simples trabalho de rotina:
- Seleção de materiais
- Leia atentamente a documentação da versão atual, pois o mundo da TI está se desenvolvendo a uma velocidade cósmica. Mesmo que você trabalhe com algo e faça um curso sobre isso, você tem que ir até a documentação e ver o que há de novo lá, o que há de interessante para falar, o que pode ser especialmente útil mencionar.
- E surge um certo esqueleto do curso, onde a maior parte dos temas, em geral, já estão abordados e parece que o que quer que esteja aí - gravar vídeos e colocá-los em produção.
- Mas na verdade não, aí começa o trabalho duro, mas não para os autores do curso, mas para quem testa. Normalmente nossos testadores alfa são suporte técnico, que, em primeiro lugar, revisa os cursos em busca de erros sintáticos e gramaticais. Em segundo lugar, eles nos batem dolorosamente com paus e xingam quando há lugares completamente desconhecidos e incompreensíveis. Quando algumas frases subordinadas compostas de forma complexa com duração de algumas páginas ou absurdos óbvios aparecem nos textos. Eles lêem tudo, ficam atentos.
- Começa então a fase de testes práticos, onde também são detectadas algumas coisas óbvias que não funcionam e são mostrados alguns pontos que podem ser dificultados, uma vez que se torna pouco interessante - apenas sentar e copiar - e são identificados locais onde é muito difícil e temos muito o que fazer que queremos das pessoas que farão esse curso. E aí vêm as recomendações: “Gente, simplifique aqui, vai ficar mais fácil de perceber e vai ter mais benefício com isso”.
- Depois de feito esse trabalho, a parte que diz respeito ao vídeo está escrita, tudo parece estar bem. E você já pode doar para produção, para divulgação desse curso. Mas, novamente, não, é muito cedo - porque recentemente deixamos de confiar um pouco em nós mesmos e, em princípio, começamos a trabalhar mais com feedback. Existe o teste beta - é quando pessoas de fora, que não têm nenhuma ligação com a nossa empresa, são convidadas de forma alguma, e para algumas guloseimas são mostradas todas as partes do curso, vídeos, textos, tarefas práticas, para que eles avaliou a qualidade do material, a acessibilidade do material e nos ajudou a tornar o curso o melhor possível.
- E quando várias dessas iterações passam, palestrantes, testes alfa na forma de suporte técnico, testes beta, melhorias. E então tudo começa de novo - suporte técnico, testes beta, melhorias.
- E a certa altura chega-se ao entendimento de que ou terminamos as modificações, porque é completamente irrealista garantir que todos gostem, ou algumas decisões drásticas são tomadas. Quando muitos comentários sobre determinados locais forem críticos, refaça-os globalmente, porque algo deu errado.
- Então chega a hora de pequenas edições - em algum lugar a frase não está muito bem formulada, em algum lugar alguém não gosta da fonte, 14,5, mas gostaria de 15,7.
- Quando esse tipo de comentário permanece, então é isso, o curso abre mais ou menos, começam as vendas oficiais.
E à primeira vista, a tarefa curta e simples de criar um curso acaba não sendo nada simples e leva um tempo incrivelmente longo.
E tem outro ponto importante que o trabalho com o curso não termina quando o curso é lançado. Em primeiro lugar, lemos atentamente os comentários deixados sobre determinadas partes. E mesmo apesar de todos os esforços que temos feito, algumas falhas ainda são identificadas, alguns erros vão sendo corrigidos e melhorados ao longo do caminho, em tempo real, para que cada utilizador subsequente receba um melhor serviço.
Cada curso tem seu próprio product owner, que além de definir o conceito geral, verifica os prazos, anota nas margens que quando chegar a hora de reescrever completamente o curso, com certeza virá, pois daqui a dois anos, ou mesmo um ano depois, parte do que dizemos tornar-se-á irrelevante simplesmente porque se tornará moralmente obsoleto. O product Owner anota nas margens que na maioria das vezes as pessoas perguntam quais pontos não estavam claros, quais tarefas pareciam muito difíceis e quais pareciam, pelo contrário, muito simples. E tudo isso é levado em consideração na hora de regravar o curso, durante algum tipo de refatoração, para que cada iteração do curso global se torne melhor, mais conveniente e confortável.
É assim que os cursos aparecem.
Como nasceu o curso Docker
Este é um tópico separado e até incomum para nós. Porque por um lado não planeámos fazê-lo, porque muitas escolas online oferecem. Por outro lado, ele próprio pediu liberdade e encontrou um lugar lógico no nosso conceito de formação de especialistas em TI em Kubernetes.
Falando de forma muito global, inicialmente tudo começou com um curso de Kubernetes, quando só começou, na minha opinião, depois do primeiro Slurm. Coletamos feedback e vimos que muitas pessoas querem ler algo adicional sobre Docker em outro lugar e, em geral, muitas chegam ao curso básico de Kubernetes sem saber o que é .
Portanto, para o segundo Slurm eles fizeram um curso - ou melhor, nem mesmo um curso, mas fizeram alguns capítulos sobre Dockers. Onde contaram algumas das coisas mais básicas, para que as pessoas que vêm para o intensivo não se sentissem privadas e em geral entendessem o que estava acontecendo.
E então os eventos se desenvolveram mais ou menos assim. A quantidade de material cresceu e parou de caber em 3 dias. E surgiu uma ideia lógica e óbvia: por que não transformar o que abordamos no Slurm Basic em uma espécie de pequeno curso para o qual você poderia enviar pessoas que desejam assistir algo sobre Docker antes de fazer um curso intensivo sobre Kubernetes.
Slurm Junior é, na verdade, uma combinação de vários desses cursos básicos. Como resultado, o curso Docker tornou-se parte do Slurm Junior. Ou seja, este é um passo zero antes и . E então havia apenas abstrações muito básicas.
A certa altura, as pessoas começaram a perguntar: “Gente, isso tudo é ótimo, basta isso para entender o que vocês estão falando nos cursos intensivos. Onde posso ler com mais detalhes sobre o que o docker pode fazer e como trabalhar com ele, e o que é?” Então surgiu a ideia de esclarecer , para que, em primeiro lugar, as pessoas que vierem ao Slurm usando o Kubernetes ainda possam ser encaminhadas para ele e, por outro lado, para quem nem se interessa pelo Kubernetes nesta fase de desenvolvimento. Para que um especialista em TI possa vir assistir nosso curso sobre Docker e iniciar seu caminho evolutivo simplesmente com Docker puro. Para que tenhamos um curso completo e completo - e então muitos, tendo assistido a este curso, tendo trabalhado por algum tempo com Docker puro, cresceram ao nível em que precisam de Kubernetes ou algum outro sistema de orquestração. E eles vieram até nós em particular.
Às vezes, surge a pergunta: “Que tipo de pessoa agora pode não precisar do Kubernetes?” Mas esta questão não é sobre pessoas, é antes uma questão sobre empresas. Aqui você precisa entender que o Kubernetes tem certos casos em que é adequado e tarefas que resolve bem, mas, pelo contrário, existem alguns cenários para usar o Kubernetes quando causa dor e sofrimento adicionais. Portanto, não depende nem de pessoas, mas sim do que as empresas vêm desenvolvendo e há quanto tempo.
Por exemplo, algum terrível monólito legado - você provavelmente não deveria empurrá-lo para o Kubernetes, porque causará mais problemas do que benefícios. Ou, por exemplo, se for um projeto pequeno, tem uma carga pequena ou, em princípio, não tem muito dinheiro e recursos. Não faz sentido arrastá-lo para o Kubernetes.
E em geral, provavelmente, em geral, como muitas pessoas já disseram, se você está fazendo a pergunta: “Eu preciso do Kubernetes?”, então provavelmente você não precisa dele. Não me lembro quem inventou isso primeiro, na minha opinião, Pasha Selivanov. Eu concordo com isso 100%. E você precisa crescer para o Kubernetes - e quando já ficar claro que eu preciso do Kubernetes e nossa empresa precisa dele, e isso ajudará a resolver tais e tais problemas, então provavelmente faz sentido aprender e descobrir exatamente como definir tudo bem, para que o processo de mudança para o Kubernetes não seja muito doloroso.
Algumas doenças infantis e algumas coisas simples, e mesmo não muito simples, podem ser descobertas principalmente conosco, e não passar por suas próprias angústias e dores.
Muitas empresas seguiram exatamente o caminho que inicialmente era apenas algum tipo de infraestrutura sem conteinerização. Aí chegaram ao ponto em que ficou difícil gerenciar tudo, mudaram para o Docker e em algum momento cresceram a ponto de ficarem restritos à estrutura do Docker e ao que ele oferece. E eles começaram a olhar o que estava por aí, quais sistemas resolvem esses problemas, e em particular o Kubernetes - este é um daqueles sistemas que permite resolver problemas quando o Docker puro fica lotado e sem funcionalidade, este é um caso muito bom quando as pessoas Eles vão passo a passo de baixo para cima, entendem que essa tecnologia não é suficiente e passam para o próximo nível. Eles usaram alguma coisa, tornou-se escassa novamente e seguiram em frente.
Esta é uma escolha consciente – e é muito legal.
Em geral, vejo que nosso sistema é muito bem construído, por exemplo, , mesmo por meio de cursos em vídeo. Então, depois do docker, ele vai então então . Tudo se alinha logicamente - passa uma pessoa e surge uma profissão sólida.
Em princípio, o conjunto de cursos permite abranger muitos casos, mesmo os modernos. Ainda há zonas que continuam a ser uma zona cinzenta, espero que em breve criemos alguns cursos que nos permitam fechar essas zonas cinzentas, em particular, vamos chegar a algo sobre segurança. Porque isso está se tornando muito relevante.
Resumindo, temos algumas áreas cinzentas que seria muito bom fechar, para que fosse uma imagem completa e completa - e as pessoas poderiam vir, e assim como o próprio Kubernetes é como um construtor de Lego, você pode fazer coisas diferentes de é coletar, se ainda não sobrar - complementar, o mesmo com os nossos cursos, para que as pessoas possam entender o que precisam disso, precisam montar uma espécie de quebra-cabeça, uma espécie de conjunto de construção dos nossos cursos.
Se você se fizer uma pergunta geralmente correta e honesta: “Quem poderia usar um curso Docker ativo agora?”, então:
- Para estudantes que estão começando a se aprofundar no assunto.
- Testando funcionários do departamento.
- Na verdade, existem muitas empresas que ainda não só não utilizam o Docker, como ninguém ouviu falar dessa tecnologia e, a princípio, não sabem como utilizá-la. E conheço várias grandes empresas em São Petersburgo que vêm se desenvolvendo há muitos anos e usaram algumas tecnologias antigas, estão caminhando nessa direção. Em particular, para essas empresas, para os engenheiros dessas empresas, este curso pode ser muito interessante, pois, em primeiro lugar, permitirá que você mergulhe rapidamente nesta tecnologia e, em segundo lugar, assim que aparecerem vários engenheiros que entendem como tudo isso funciona, eles podem trazer isso para a empresa e desenvolver essa cultura e esses rumos dentro da empresa.
- Na minha opinião, este curso ainda pode ser útil para quem já trabalhou com docker, mas muito pouco e mais no estilo “faça uma vez, faça duas vezes” - e agora eles vão interagir de alguma forma com o mesmo Kubernetes, e isso impõe certas obrigações a eles, se você tem um conhecimento muito superficial do que é o docker, como executá-lo, mas ao mesmo tempo não sabe como funciona por dentro, não sabe o que é melhor fazer com isso e o que é melhor não fazer, então este curso é adequado para sistematizar e aprofundar conhecimentos.
Mas se você tiver conhecimento no nível de: “Não sei como escrever os mesmos arquivos Docker corretamente, posso imaginar o que são namespaces, como funcionam os contêineres, como eles são realmente implementados no nível do sistema operacional” - então há definitivamente não adianta vir até nós, você não aprenderá nada novo e ficará um pouco triste pelo dinheiro e tempo gasto.
Se formularmos quais vantagens nosso curso tem, então:
- Procurámos fazer este curso com um número suficiente de casos práticos que lhe permitirão não só compreender a parte teórica que existe, mas também compreender porque necessita dela e como a utilizará no futuro;
- há várias seções que raramente são encontradas em qualquer lugar - e em geral não há muito material sobre elas. Eles se relacionam com a interação do Docker com o sistema operacional, até mesmo de maneira um pouco diferente. Quais mecanismos o Docker tirou do sistema operacional para implementar o sistema de conteinerização - e isso dá uma compreensão mais profunda de toda a questão da execução de contêineres no sistema operacional Linux. Como funciona, como interage entre si dentro do sistema operacional, fora dele e assim por diante.
Este é um olhar tão profundo que raramente acontece e, ao mesmo tempo, na minha opinião, é muito importante. Se você quer entender bem qualquer tecnologia e entender o que esperar dela, você precisa pelo menos ter uma ideia geral de como ela funciona em um nível baixo.
Nosso curso mostra e conta como isso funciona do ponto de vista do sistema operacional. Por um lado, todos os sistemas de conteinerização utilizam os mesmos mecanismos de sistema operacional. Por outro lado, eles pegam o que está no sistema operacional Linux, como o docker. Outros sistemas de conteinerização não criaram nada de novo - eles pegaram o que já estava no Linux e escreveram apenas um wrapper conveniente que permite chamá-lo, executá-lo ou interagir de alguma forma com ele rapidamente. O mesmo Docker não é uma camada muito grande entre o sistema operacional e a linha de comando, é um tipo de utilitário que permite não escrever quilotons de comandos ou algum tipo de código C para criar um contêiner, mas fazer isso digitando algumas linhas no terminal.
E mais uma coisa, se estamos falando especificamente do Docker, o que o Docker realmente trouxe para o mundo da TI foram os padrões. Como a aplicação deve ser lançada, como deve funcionar, quais os requisitos de logs, quais os requisitos de escalonamento, configuração da própria aplicação.
De muitas maneiras, o docker trata de padrões.
Os padrões também estão migrando para o Kubernetes - e existem exatamente os mesmos padrões; se você souber como executar bem seu aplicativo no Docker, 99% das vezes ele funcionará tão bem no Kubernetes.
Se você se interessou não apenas em como o curso Docker foi criado, mas também em outros cursos, mas também no curso em si do ponto de vista prático, então
Teremos o maior prazer em ver você!
Fonte: habr.com