Un participante viene a un curso o curso intensivo. Ve filas ordenadas de soporte técnico, cables de alimentación cuidadosamente colocados, un diseño de tablero de ajedrez de la sala de conferencias, imágenes brillantes y diagramas de diapositivas. Los oradores con bromas y sonrisas dan información de tal manera que tienes tiempo para entenderla. Las gradas están montadas, las tareas de práctica simplemente se te escapan de los dedos, excepto que a veces necesitas la ayuda del personal técnico. apoyo.
Y también pausas para el café con personas de ideas afines, un ambiente alegre y enérgico, intercambio de experiencias, las preguntas más inesperadas para los ponentes. Tanto respuestas como información que no encontrarás en los manuales, sino sólo en la práctica.
¿Cuánto tiempo, esfuerzo y nervios crees que se necesitaron para que se viera exactamente así?
Gracias a Volodya Guryanov, administrador certificado de Kubernetes e ingeniero/líder de equipo en Southbridge, que ha sido testigo y participado activamente en la creación de muchos cursos de Slurm desde el principio.
Vio la parte más vulnerable de la creación: complejidades y rastrillos espinosos, ideas y soluciones inesperadas. Y los ya familiares intensivos de Kubernetes, como Slurm Basic y Slurm Mega. Y un curso nuevo, en gran medida revisado. , que se acerca inexorablemente y comenzará el 19 de agosto.
Pero, quizás, basta de letra, pasemos a la historia en sí. Cómo a partir de un par de temas intensivos se obtiene una experiencia completamente autosuficiente y multifacética. . Así que comenzaré la historia de cómo se crean y desarrollan los cursos, como "Hace mucho tiempo, en una galaxia muy, muy lejana..."
¿Qué hay detrás de escena?
Si me preguntas cómo hacemos los cursos y dónde comienza todo, simplemente responderé "Todo comienza con una idea".
Por lo general, la idea surge de alguna parte: no nos sentamos esposados en el sótano hasta que se nos ocurre: "¿Sobre qué tema deberíamos hacer un curso?" Las ideas surgen de algún lugar por sí solas, de fuentes externas. A veces la gente comienza a preguntar activamente: "¿Qué sabes sobre tal o cual tecnología específica?" O cómo le pasó a Docker que fue imposible incluirlo en el horario del curso intensivo; obviamente, hubo que sacarlo afuera para tener tiempo de contar algo durante el curso intensivo.
Así aparece una idea.
Después de su anuncio, en mi opinión, comienza el momento más difícil: entender en general qué incluir en este curso; esto es muy comparable a cómo se prepara a los oradores para cualquier conferencia.
Hay un dolor principal cuando parece que has elegido un tema y piensas: “¿Qué puedo contar al respecto? Esto es demasiado simple, esto es obvio, todo el mundo también lo sabe”.
Pero en realidad este no es el caso en absoluto. Y personalmente digo en muchos lugares que lo que a ti te parece obvio, a quien viene a escucharte o a hacer un curso, no lo es en absoluto. Y aquí surge una capa tan grande de trabajo y conflicto interno sobre qué incluir en el curso. Como resultado, obtenemos una lista de capítulos con trazos tan amplios, de qué se tratará el curso.
Y entonces comienza el sencillo trabajo rutinario:
- Selección de materiales
- Lea atentamente la documentación de la versión actual, ya que el mundo de las tecnologías de la información se está desarrollando a una velocidad cósmica. Incluso si trabajas con algo y haces un curso sobre ello, tienes que ir a la documentación y ver qué hay de nuevo allí, qué es interesante de qué hablar, qué podría ser especialmente útil mencionar.
- Y aparece un cierto esqueleto del curso, donde la mayoría de los temas, en general, ya están cubiertos y parece que lo que sea que haya ahí es grabar videos y lanzarlos a producción.
- Pero en realidad no, entonces comienza el trabajo duro, pero no para los autores del curso, sino para los que realizan la prueba. Por lo general, nuestros evaluadores alfa son soporte técnico, que, en primer lugar, revisa los cursos para detectar errores sintácticos y gramaticales. En segundo lugar, nos golpean dolorosamente con palos y maldicen cuando hay lugares completamente no obvios e incomprensibles. Cuando en los textos aparecen algunas oraciones subordinadas de composición compleja que duran un par de páginas o evidentes tonterías. Lo leen todo, estén atentos.
- Luego comienza la etapa de prueba de práctica, donde también se detectan algunas cosas obvias que no funcionan y se muestran algunos momentos que pueden hacerse más difíciles, ya que se vuelve poco interesante - simplemente sentarse y copiar - y se identifican los lugares donde es muy difícil y tenemos mucho que hacer que queremos de las personas que tomarán este curso. Y luego vienen las recomendaciones: "Chicos, háganlo más simple aquí, será más fácil de percibir y obtendrá más beneficios".
- Después de hacer esta cantidad de trabajo, se escribe la parte que se relaciona con el video, todo parece estar bien. Y ya puedes donarlo para producción, para publicidad de este curso. Pero, de nuevo, no, es demasiado pronto, porque últimamente hemos dejado de confiar un poco en nosotros mismos y, en principio, hemos empezado a trabajar más con la retroalimentación. Existe una prueba beta: esto es cuando se invita a personas externas que no están relacionadas de ninguna manera con nuestra empresa y, para obtener algunos beneficios, se les muestran todas las partes del curso, videos, textos y tareas prácticas, para que puedan evaluó la calidad del material, la accesibilidad del material y nos ayudó a que el curso fuera lo mejor posible.
- Y cuando se realicen varias iteraciones de este tipo, oradores, pruebas alfa en forma de soporte técnico, pruebas beta, mejoras. Y luego todo empieza de nuevo: soporte técnico, pruebas beta, mejoras.
- Y en algún momento, llega el entendimiento de que o hemos terminado con las modificaciones, porque es completamente irreal asegurarse de que a todos les guste, o se toman algunas decisiones drásticas. Cuando muchos comentarios sobre determinados lugares sean críticos, rehágalos globalmente, porque algo salió mal.
- Luego llega el momento de realizar modificaciones menores: en algún lugar la oración no está muy bien formulada, en algún lugar a alguien no le gusta la fuente, 14,5, pero le gustaría 15,7.
- Cuando queda este tipo de comentarios pues ya está, más o menos se abre el curso, empiezan las ventas oficiales.
Y a primera vista, la breve y sencilla tarea de crear un curso resulta nada sencilla y lleva un tiempo increíblemente largo.
Y hay otro punto importante: el trabajo con el curso no termina cuando se publica el curso. En primer lugar, leemos atentamente los comentarios que se dejan sobre determinadas partes. E incluso a pesar de todos los esfuerzos que hemos realizado, todavía se identifican algunas fallas, algunos errores se corrigen y mejoran a lo largo del camino, en tiempo real, para que cada usuario posterior reciba un mejor servicio.
Cada curso tiene su propio product Owner, quien además de definir el concepto general, revisa los plazos, anota en los márgenes que cuando llegue el momento de reescribir completamente el curso, y seguro que llegará, porque en dos años, o incluso un año después, parte de lo que contamos se volverá irrelevante simplemente porque quedará moralmente obsoleto. El propietario del producto anota en los márgenes que la mayoría de las veces la gente pregunta qué puntos no estaban claros, qué tareas parecían muy difíciles y cuáles, por el contrario, parecían muy simples. Y todo esto se tiene en cuenta al volver a grabar el curso, durante algún tipo de refactorización, para que cada iteración del curso global sea mejor, más conveniente y cómoda.
Así aparecen los cursos.
Cómo nació el curso Docker
Este es un tema aparte e incluso inusual para nosotros. Porque, por un lado, no teníamos pensado hacerlo, porque muchas escuelas online lo ofrecen. Por otro lado, él mismo pidió libertad y encontró un lugar lógico en nuestro concepto de formar especialistas en TI en Kubernetes.
Hablando de manera muy global, inicialmente todo comenzó con un curso sobre Kubernetes, cuando recién comenzó, en mi opinión, después del primer Slurm. Recopilamos comentarios y vimos que muchas personas quieren leer algo adicional sobre Docker en otro lugar y, en general, muchos llegan al curso básico sobre Kubernetes sin saber qué es. .
Por lo tanto, para el segundo Slurm hicieron un curso, o mejor dicho, ni siquiera un curso, sino un par de capítulos sobre Dockers. Donde contaron algunas de las cosas más básicas, para que las personas que vengan al intensivo no se sientan privadas y en general entiendan lo que está pasando.
Y luego los acontecimientos se desarrollaron más o menos así. La cantidad de material creció y dejó de encajar en 3 días. Y surgió una idea lógica y obvia: ¿por qué no convertir lo que cubrimos en Slurm Basic en una especie de pequeño curso al que enviar a las personas que quieran ver algo sobre Docker antes de tomar un curso intensivo sobre Kubernetes?
Slurm Junior es, de hecho, una combinación de varios cursos básicos de este tipo. Como resultado, el curso Docker se convirtió en una parte de Slurm Junior. Es decir, este es un paso cero antes и . Y luego estaban las abstracciones muy básicas.
En algún momento, la gente empezó a preguntar: “Chicos, todo esto es genial, esto es suficiente para entender de qué están hablando en los cursos intensivos. ¿Dónde puedo leer con más detalle qué puede hacer Docker, cómo trabajar con él y qué es? Entonces surgió la idea de aclarar las cosas. , para que, por un lado, las personas que vengan a Slurm usando Kubernetes todavía puedan ser enviadas a él, y por otro lado, para aquellos que ni siquiera estén interesados en Kubernetes en esta etapa de desarrollo. Para que un especialista en TI pueda venir a ver nuestro curso sobre Docker y comenzar su camino evolutivo simplemente con Docker puro. De modo que tenemos un curso tan completo y completo, y luego muchos, después de haber visto este curso, haber trabajado durante algún tiempo con Docker puro, han crecido hasta el nivel en el que necesitan Kubernetes o algún otro sistema de orquestación. Y vinieron a nosotros en particular.
A veces surge la pregunta: "¿Qué tipo de personas ahora podrían no necesitar Kubernetes?" Pero esta cuestión no es sobre personas, sino más bien sobre empresas. Aquí debe comprender que Kubernetes tiene ciertos casos en los que es adecuado y tareas que resuelve bien, pero por el contrario, hay algunos escenarios de uso de Kubernetes cuando causa dolor y sufrimiento adicionales. Por tanto, ni siquiera depende de las personas, sino de qué empresas llevan desarrollándose y desde hace cuánto tiempo.
Por ejemplo, algún terrible monolito heredado: probablemente no deberías incluirlo en Kubernetes, porque causará más problemas que beneficios. O, por ejemplo, si se trata de un proyecto pequeño, tiene poca carga o, en principio, poco dinero y recursos. No tiene sentido arrastrarlo a Kubernetes.
Y en general, probablemente, como ya han dicho muchas personas, si se hace la pregunta: "¿Necesito Kubernetes?", Lo más probable es que no lo necesite. No recuerdo a quién se le ocurrió por primera vez, en mi opinión, Pasha Selivanov. Estoy de acuerdo con esto al 100%. Y es necesario adaptarse a Kubernetes, y cuando ya esté claro que necesito Kubernetes y nuestra empresa lo necesita, y que ayudará a resolver tales o cuales problemas, entonces probablemente tenga sentido aprender y descubrir exactamente cómo configurarlo. bien, para que el proceso de cambio a Kubernetes no sea muy doloroso.
Algunas dolencias de los niños y algunas cosas sencillas, e incluso no muy sencillas, las puedes aprender especialmente de nosotros, y no pasar por tu propio rastrillo y dolor.
Muchas empresas han seguido exactamente el camino que al principio solo existía algún tipo de infraestructura sin contenerización. Luego llegaron al punto en el que se volvió difícil administrarlo todo, cambiaron a Docker y en algún momento crecieron hasta el punto en que se volvió estrecho dentro del marco de Docker y lo que ofrece. Y comenzaron a mirar lo que había alrededor, qué sistemas resuelven estos problemas y, en particular, Kubernetes: este es uno de esos sistemas que le permite resolver problemas cuando Docker puro se llena y carece de funcionalidad, este es un caso realmente bueno cuando las personas Van paso a paso de abajo hacia arriba, comprenden que esta tecnología no es suficiente y pasan al siguiente nivel. Usaron algo, volvió a escasear y siguieron adelante.
Esta es una elección consciente y es genial.
En general, veo que nuestro sistema está muy bien construido, por ejemplo, , incluso a través de cursos en vídeo. Luego, después de la ventana acoplable, va entonces entonces . Todo se alinea lógicamente: pasa una persona y surge una profesión sólida.
En principio, el conjunto de cursos permite abarcar muchos casos, incluso los más modernos. Todavía hay áreas que siguen siendo un área gris, espero que pronto creemos algunos cursos que nos permitan cerrar estas áreas grises, en particular, se nos ocurrirá algo sobre seguridad. Porque esto se está volviendo muy relevante.
En resumen, tenemos algunas áreas grises que sería muy bueno cerrar, para que fuera una imagen completa, completa, y la gente podría venir, y al igual que Kubernetes es como un constructor de Lego, puedes hacer cosas diferentes a partir de recoger, si aún no hay suficiente, complementar, lo mismo con nuestros cursos, para que la gente pueda entender lo que necesitan de esto, necesitan armar una especie de rompecabezas, una especie de juego de construcción de nuestros cursos.
Si se hace una pregunta generalmente correcta y honesta: "¿A quién le vendría bien un curso activo de Docker ahora?", entonces:
- Para estudiantes que recién comienzan a introducirse en esto.
- Empleados del departamento de pruebas.
- De hecho, hay muchas empresas que todavía, no sólo no utilizan Docker, sino que nadie ha oído hablar de dicha tecnología y, en principio, no sabe cómo utilizarla. Y conozco varias empresas grandes en San Petersburgo que se han estado desarrollando durante muchos años y que utilizaron algunas tecnologías antiguas y se están moviendo en esta dirección. En particular, para este tipo de empresas, para los ingenieros de dichas empresas, este curso puede resultar muy interesante, ya que, en primer lugar, les permitirá sumergirse rápidamente en esta tecnología y, en segundo lugar, tan pronto como aparezcan varios ingenieros que entiendan cómo funciona todo. funciona, pueden llevarlo a la empresa y desarrollar esta cultura y estas direcciones dentro de la empresa.
- En mi opinión, este curso aún puede ser útil para aquellos que ya han trabajado con Docker, pero muy poco y más en el estilo "hacer una vez, hacer dos veces", y ahora de alguna manera van a interactuar con el mismo Kubernetes, y esto les impone ciertas obligaciones, si tienes un conocimiento muy superficial de qué es Docker, cómo ejecutarlo, pero al mismo tiempo no sabes cómo funciona desde adentro, no sabes qué es mejor hacer con eso y qué es mejor no hacer, entonces este curso es muy adecuado para sistematizar y profundizar conocimientos.
Pero si tiene conocimientos del nivel: "No sé cómo escribir correctamente los mismos archivos Docker, puedo imaginar qué son los espacios de nombres, cómo funcionan los contenedores, cómo se implementan realmente a nivel del sistema operativo", entonces hay Definitivamente no tiene sentido acudir a nosotros, no aprenderás nada nuevo y estarás un poco triste por el dinero y el tiempo invertido.
Si formulamos qué ventajas tiene nuestro curso, entonces:
- Intentamos realizar este curso con una cantidad suficiente de casos prácticos que te permitirán no solo entender la parte teórica que existe, sino también entender por qué la necesitas y cómo la utilizarás en el futuro;
- Hay varias secciones que rara vez se encuentran en ningún lugar y, en general, no hay mucho material sobre ellas. Se relacionan con la interacción de Docker con el sistema operativo, aunque sea un poco diferente. ¿Qué mecanismos tomó Docker del sistema operativo para implementar el sistema de contenedorización? Esto brinda una comprensión más profunda de todo el tema de la ejecución de contenedores dentro del sistema operativo Linux. Cómo funciona, cómo interactúan entre sí dentro y fuera del sistema operativo, etc.
Esta es una mirada tan verdaderamente profunda que ocurre muy raramente y, al mismo tiempo, en mi opinión, es muy importante. Si desea comprender bien cualquier tecnología y qué esperar de ella, debe al menos tener una idea general de cómo funciona a bajo nivel.
Nuestro curso muestra y cuenta cómo funciona esto desde el punto de vista del sistema operativo. Por un lado, todos los sistemas de contenedorización utilizan los mismos mecanismos del sistema operativo. Por otro lado, toman lo que hay en el sistema operativo Linux, como Docker. A otros sistemas de contenedores no se les ocurrió nada nuevo: tomaron lo que ya estaba en Linux y escribieron solo un contenedor conveniente que le permite llamarlo, ejecutarlo o interactuar de alguna manera con él rápidamente. El mismo Docker no es una capa muy grande entre el sistema operativo y la línea de comandos, es una especie de utilidad que te permite no escribir kilotones de comandos o algún tipo de código C para crear un contenedor, sino hacerlo ingresando un par de líneas en la terminal.
Y una cosa más, si hablamos específicamente de Docker, lo que Docker realmente aportó al mundo TI son estándares. Cómo se debe iniciar la aplicación, cómo debería funcionar, cuáles son los requisitos para los registros, cuáles son los requisitos para escalar y configurar la aplicación en sí.
En muchos sentidos, Docker se trata de estándares.
Los estándares también se están trasladando a Kubernetes, y existen exactamente los mismos estándares; si sabe cómo ejecutar bien su aplicación en Docker, el 99% de las veces funcionará igual de bien dentro de Kubernetes.
Si se encuentra interesado no solo en cómo se creó el curso Docker, sino también en otros cursos, sino también en el curso en sí desde un punto de vista práctico, entonces
¡Estaremos encantados de verte!
Fuente: habr.com