Get best of the week

Kubernetes, Microservicios, CI / CD y Dockers para Retrogrades: consejos de aprendizaje

Parece que el tema "por qué necesitamos Kubernetes" ya es molesto. Quiero decir: "todos los que lo necesitan lo han entendido por mucho tiempo", pero dividiría a los trabajadores técnicos (y casi técnicos) en aquellos que "entendieron y saben cómo usar", y aquellos que "entendieron, pero quieren saber cómo hacer que el conocimiento sea relevante ".

Tal vez usted es un gerente que ha estado trabajando en la misma pila durante los últimos 10 años; Puede ser un desarrollador que admita la solución anterior o escriba en un lenguaje familiar en un entorno familiar. Quizás acaba de pasar de la gestión técnica a la gestión organizativa y de repente descubrió que todo lo que sabía ya no era relevante, y quiero entender si hay un escenario relativamente simple de cómo esto puede ponerse al día. Intentaré dar consejos basados ​​en mi propia experiencia: de una persona que se dio cuenta de que estar en la gestión organizacional pronto se expresará con las palabras "Kubernetes es una tecnología efectiva, debemos esforzarnos por su aplicación", sin comprender completamente lo que hay detrás con estas palabras y detrás de toda la cultura técnica que se ha desarrollado recientemente.

¿Por qué me parece importante poder cambiar el paradigma del pensamiento tecnológico?

Lo más difícil para quienes han estado trabajando en tecnología durante mucho tiempo es aceptar que la nueva tendencia se ha vuelto permanente. Durante 20 años de trabajo, vi cómo las diferentes tecnologías iban y venían, y algunas de ellas fueron "súper relevantes" durante varios meses.

Leí a Joel Spolsky acerca de cómo Microsoft inventa sistemáticamente una nueva pila para desarrolladores con el fin de evitar que generalmente vean algo más. Al igual que SRE, tenía doble miedo a cada nueva tecnología: todo lo nuevo es crudo, todo lo crudo es inestable. Bueno, todo lo inestable conducirá a problemas en la producción, y la estabilidad de la producción es lo principal.

Como programador y emprendedor, quería crear un producto más rápido: necesito aprender todas las cosas nuevas, cambiar los enfoques habituales, lo que significa, implementar las funciones más lentamente. Si algunas nuevas tecnologías se adoptaron rápidamente, entonces todo lo relacionado con el desarrollo orientado a microservicios (llamémoslo la pila moderna completa) tenía que ser enseñado. Y cada año para aprender más; es mucho más fácil escribir de la manera familiar y entregar el producto más rápido.

Pero el hecho permanece: a veces las nuevas tecnologías permanecen y cambian todo el paradigma por completo. Y aquí surge una opción: permanecer en el viejo paradigma o pasar a uno nuevo. Los programadores de Cobol aún pueden conseguir un trabajo, los desarrolladores de Perl recuerdan sobre la reserva, pero las formas alternativas para estas personas son cada vez menos. Y luego "retrógrado" en nombre de la estabilidad se convierte en una limitación. Con todo el stack moderno, si no quieres limitarte, no es el momento, pero ya estamos atrasados. Y, si no queremos quedarnos atrapados en Perl, tenemos que aprender. Toma mucho tiempo. Intentaré contar mi experiencia paso a paso en el aprendizaje.

Direcciones de buceo


Comprenda cómo ejecutar aplicaciones en Docker. En primer lugar, los veteranos deben comprender que la forma de "almacenar" y "lanzar" aplicaciones ha cambiado para siempre. Lo más probable es que un desarrollador que ha aprendido a desarrollar en los últimos años no tenga idea de cómo ejecutar una aplicación en producción sin un docker. La cabeza de tal desarrollador probablemente no tiene el concepto de "almacenar archivos localmente", excepto en casos excepcionales de almacenamiento compartido, pero lo principal que un "veterano" necesita entender es: docker es un nuevo exe. El formato exe puede tener sus inconvenientes, pero nadie realmente piensa en ello.

Sí, el enfoque de microservicio se ha convertido en el estándar. Como una vez, OOP pareció facilitar que los equipos grandes escriban software grande; ahora los microservicios se han convertido en el mismo estándar. Incluso son cultivados por las mismas personas (ver Fowler) Esto es razonable: si la API de la aplicación está versionada, es más fácil para los equipos individuales escribir aplicaciones independientes que una grande. Se puede argumentar por qué escribir microservicios de aplicaciones pequeñas, pero en algún momento todos comenzaron a escribirlas en el estilo OOP, tan familiar (ver arriba sobre exe). Hay mucho para argumentar que la comunicación entre procesos (especialmente la construida en la pila TCP) tiene un millón de fallas de rendimiento (un servicio irá al otro a través de TCP en lugar de simplemente hacer una llamada de ensamblador; puede imaginar cuál es la diferencia en productividad?), pero el hecho es que los microservicios tienen las ventajas de desarrollar proyectos medianos y grandes, y también se han convertido en el estándar. Comprender cómo interactúan los microservicios entre sí (HTTP API, grpc,interacción asíncrona a través de la cola (un millón de formas), como beneficio adicional, comprenda qué es una malla de servicio. (Un momento de humor enojado: Dios, muchachos, se les ocurrió la idea de compartir la aplicación, y resultó que la comunicación entre las aplicaciones divididas es una broma difícil, por lo que agregaron otra capa para facilitar el horror entre procesos, ¿qué es esto para nosotros?)

, .Entonces, reconciliamos que ahora estamos lanzando las aplicaciones en la ventana acoplable y que compartimos la aplicación en microservicios. Ahora tenemos que gestionar de alguna manera los estibadores en ejecución. Puede hacerlo usted mismo en servidores dedicados (y dirigir, por ejemplo, Docker Swarm, o construir Kubernetes), o puede usar los servicios que proporcionan las nubes: servicios de contenedores de AWS o Kubernetes. Hay una gran ventaja al usar nubes. De hecho, dejas de pensar en la capa que se ejecuta debajo del administrador de contenedores (SRE ahora se ríe, pero admitámoslo: cuando todo está estable, no subimos a los nodos GKE en la mayoría de los casos). Por lo tanto, de hecho, el administrador de contenedores, cuyo Kubernetes estándar se ha convertido, se está convirtiendo en un sistema operativo. Tiene gestores de paquetes, puede "instalar software" en él, puede ejecutar "exe-shniki" en él - acopladores,Tiene kronjoby. Kubernetes es un nuevo sistema operativo.

Comprenda cómo se deberán entregar los contenedores acoplables. El diseño de un sitio simple ahora lleva 5 minutos, y la gente lo considera la norma. Necesitamos recolectar la ventana acoplable, probarla, ponerla en el registro y ponerla en el administrador de la ventana acoplable (hablemos más sobre Kubernetes). Este es el salvajismo (?) Al que todos están acostumbrados, está optimizado y este es el estándar. Los sistemas de CI / CD se han convertido en el diseño estándar y deben ser tratados. Al igual que con GitOps.

Comprenda que el alojamiento local para la mayoría de las aplicaciones será cosa del pasado (en Occidente, ya desaparecido).Érase una vez, era la norma comprar servidores, ensamblarlos, llevarlos a DC, colocarlos y cambiarlos. Incluso para un pequeño proyecto. Luego vinieron los servidores dedicados. ¿Cuántas personas ahora están pensando en atormentar, comprar y recolectar hierro en proyectos pequeños y medianos? Dedicado - en Occidente ahora, y en la Federación de Rusia pronto - será reemplazado por nubes. Se ha hablado de esto durante cien años, he estado usando AWS desde 2008 y tiene problemas, pero cuando hablamos del servicio que se hace cargo de la administración de Kubernetes (EKS, GKE, Kubernetes de Yandex o Selectel), no entiendo por qué administrar Kubernetes y Dediks mismos, si otros chicos lo hacen? Ya no cambio refrigeradores en Dediks ... La cuestión de la prevalencia de las distribuciones de Kubernetes en las instalaciones en la Federación de Rusia es una cuestión del tipo de cambio del dólar,la ley sobre persdans y "juventud" del alojamiento en la nube de Rusia. Tarde o temprano, esto se decidirá y en las instalaciones se convertirá en la locura que desean las empresas y los grandes proyectos cargados. Con bases iguales. Si hablamos de la mayoría de las aplicaciones que no requieren una carga súper alta o un ajuste súper potente, PostreSQL / MongoDB / MySQL basado en la nube ofrece una gran cantidad de ventajas. No es necesario pensar en el ajuste, no es necesario pensar en las copias de seguridad. Cree un servidor de desarrollo desde un servidor de producción: un par de comandos en la consola de la nube. Entiendo que toda esta idea puede causar enojo en el administrador: muchachos, yo mismo soy el administrador, pero para la mayoría de las tareas no malas, la administración de la base de datos, sin embargo, no es necesaria. Quizás AWS y GKE son caros e inaccesibles para nosotros debido a la ley persa, pero esto es solo un tiempo adicional para retrasarnos: tarde o temprano, Yandex o Selectel tendrán las mismas características,y el paradigma cambiará.

Comprenda qué infraestructura está ahora escrita. No me gustaba IaaC cuando era Chef y Puppet, pero, gracias a Dios, fueron reemplazados por Terraform y Pulumi más adecuados para describir lo que quieres criar en el grupo, y Ansible para trabajar dentro. Entra y pon algo en el caparazón, ahora salvajismo absoluto. Sí, es más rápido y más conveniente, pero en el nuevo paradigma es salvaje: piense en exe.

Curso de buceo profundo


¿Cómo veo una forma técnica específica para entender cómo trabajar con una pila moderna?

1) Haga una cuenta de prueba en el alojamiento en la nube. Todos los proveedores de hosting los proporcionan. Comencé con GKE, pero puedes, por ejemplo, tener una cuenta en los servicios de alojamiento de Rusia, si esperas que trabajarás, muy probablemente, en este territorio.
Si Terraform / Pulumi admite su nube, describa la infraestructura que desea crear en ellos. Si tiene habilidades de programación, le recomiendo Pulumi: en lugar de su propio SDL Terraform, puede escribir en lenguajes y construcciones familiares.

2) Busque la aplicación y empaquétela en la ventana acoplable. Qué hay para empacar: la elección es suya. De repente descubrí por mí mismo cómo NodeJS se generalizó y decidí estudiar a fondo su funcionamiento, por lo que continúo trabajando con el nodo. Aquí, por ejemplo, hay un blog sobre NodeJS , que puede plantearse, pero en general todo queda a su discreción.

3) Maneje las construcciones básicas (para, implementación, servicio) de K8S e implemente la aplicación con sus manos en el clúster K8S.

4) Trate con Helm, escriba un gráfico de Helm, implemente una aplicación Helm.
Tome un plan gratuito en CircleCI como CI-ke, que no necesita ser configurado, y configúrelo: las configuraciones serán similares a otros sistemas.

5) Repare la aplicación a través de CI-ku.
CI separado (lo que construye la aplicación) y CD. Haga un CD de GitOps (vea, por ejemplo, ArgoCD).

Que sigue


En algún lugar a partir de ahora, usted, en principio, conocerá las bases principales de la pila moderna.
¿Dónde puedo ir a cavar más?

  • Si está buscando un trabajo / quiere trabajar en Occidente, puede obtener un conocimiento más profundo de la computación en la nube: envíe un certificado de Google o equivalente de AWS a Cloud Architect ( recientemente recibimos 3 de estos certificados en ITSumma ). Esto le dará una idea de las características que ofrece Cloud y los ayudará a navegar. Buen curso sobre linuxacademy .
  • Entregue a CKA: este es un tema difícil, pero vale la pena. La preparación para el examen proporcionará un gran paquete de conocimientos.
  • Aprende a programar si no sabes cómo. Ahora fui a estudiar el frente y estoy asombrado de cómo ha cambiado todo. Mi conocimiento terminó en algún lugar en 2012 o incluso antes, en jQuery, la gente se ríe. El frente ahora se ha vuelto más complicado que el backend, hay una gran cantidad de lógica de aplicación y, al mismo tiempo, paradigmas que son completamente inusuales para mí. ¡Muy interesante!

Y soy un poco más regular que el blog aquí, mantengo mi canal de telegramas y suscribo :-)

More articles:


All Articles