Paquetes y gestores de paquetes para k8s

Todos usamos algún tipo de gestores de paquetes, incluida la señora de la limpieza Tía Galya, que ahora tiene un iPhone en su bolsillo actualizado. Pero no hay un acuerdo general sobre las funciones de los gestores de paquetes, y los sistemas operativos y sistemas de rpm y dpkg estándar se denominan gestores de paquetes. Ofrecemos reflexionar sobre el tema de sus funciones: qué es y por qué se necesitan en el mundo moderno. Y luego exploraremos hacia Kubernetes y consideraremos cuidadosamente a Helm en términos de estas funciones.


Entenderemos por qué en este diagrama solo la función de plantilla se resalta en verde, y cuáles son los problemas con el ensamblaje y el embalaje, la automatización del entorno y más. Pero no te preocupes, el artículo no termina con el hecho de que todo está mal. La comunidad no pudo llegar a un acuerdo con esto y ofrece herramientas y soluciones alternativas; nos ocuparemos de ellas.

Ivan Glushkov ( gli ) nos ayudó con esto con su informe sobre RIT ++, una versión en video y texto de esta presentación detallada y detallada a continuación.

Los videos de este y otros discursos de DevOps en RIT ++ se publican y abren para su visualización gratuita en nuestro canal de YouTube ; busque respuestas a sus preguntas de trabajo.

Sobre el orador: Ivan Glushkov ha estado desarrollando software durante 15 años. Logré trabajar en MZ, en Echo en una plataforma para comentarios, participar en el desarrollo de compiladores para el procesador Elbrus en MCST. Actualmente está involucrado en proyectos de infraestructura en Postmates. Ivan es uno de los podcasts líderes de DevZen en el que hablan sobre nuestras conferencias: aquí se trata de RIT ++, y aquí sobre HighLoad ++.

Gerentes de paquete

Aunque todos usan algún tipo de gestores de paquetes, no existe un acuerdo único sobre lo que es. Hay un entendimiento común, y cada uno tiene el suyo.

Recordemos qué tipos de gestores de paquetes vienen a la mente primero:

• Gestores de paquetes estándar de todos los sistemas operativos: rpm, dpkg, portage , ...
• Gestores de paquetes para diferentes lenguajes de programación: carga, cabal, rebar3, mix , ...

Su función principal es ejecutar comandos para instalar un paquete, actualizar un paquete, desinstalar un paquete y administrar dependencias. En los gestores de paquetes dentro de los lenguajes de programación, las cosas son un poco más complicadas. Por ejemplo, hay comandos como "lanzar un paquete" o "crear una versión" (compilar / ejecutar / liberar). Resulta que este ya es un sistema de compilación, aunque también lo llamamos administrador de paquetes.


Todo esto solo se debe al hecho de que no puedes tomarlo y ... dejar que los amantes de Haskell perdonen esta comparación. Puede ejecutar el archivo binario, pero no puede ejecutar el programa en Haskell o C, primero debe prepararlo de alguna manera. Y esta preparación es bastante complicada, y los usuarios quieren que todo se haga automáticamente.

Desarrollo

El que trabajó con GNU libtool, que fue hecho para un gran proyecto que consta de una gran cantidad de componentes, no se ríe del circo. Esto es realmente muy difícil, y algunos casos no pueden resolverse en principio, sino que solo pueden evitarse.

En comparación, los gestores de idiomas de paquetes modernos como Cargo for Rust son mucho más convenientes: presionas el botón y todo funciona. Aunque, de hecho, bajo el capó, se resuelven una gran cantidad de problemas. Además, todas estas nuevas funciones requieren algo adicional, en particular, una base de datos. Aunque en el administrador de paquetes en sí se puede llamar como se quiera, lo llamo una base de datos, porque allí se almacenan datos: sobre paquetes instalados, sobre sus versiones, repositorios conectados, versiones en estos repositorios. Todo esto debe almacenarse en algún lugar, por lo que hay una base de datos interna.

Desarrollo en este lenguaje de programación, pruebas para este lenguaje de programación, lanzamientos: todo esto está incorporado y ubicado dentro, el trabajo se vuelve muy conveniente . La mayoría de los idiomas modernos han apoyado este enfoque. Incluso aquellos que no apoyaron comienzan a apoyar, porque la comunidad presiona y dice que en el mundo moderno es imposible sin ella.

Pero cualquier solución siempre tiene no solo ventajas, sino también desventajas . La desventaja aquí es que necesita envoltorios, utilidades adicionales y una "base de datos" incorporada.

Docker

¿Crees que Docker es un administrador de paquetes o no?

No importa cómo, pero esencialmente sí. No conozco una utilidad más correcta para unir completamente la aplicación con todas las dependencias y hacer que funcione con solo hacer clic en un botón. ¿Qué es esto si no es un administrador de paquetes? ¡Este es un excelente administrador de paquetes!

Maxim Lapshin ya ha dicho que con Docker se ha vuelto mucho más fácil, y esto es así. Docker tiene un sistema de compilación incorporado, todas estas bases de datos, enlaces y utilidades.

¿Cuál es el precio de todos los beneficios? Quienes trabajan con Docker piensan poco en las aplicaciones industriales. Tengo tal experiencia, y el precio es realmente muy alto:

• La cantidad de información (tamaño de imagen) que debe almacenarse en la imagen de Docker. Necesita todas las dependencias, partes de utilidades, bibliotecas para empaquetar, la imagen es grande y necesita poder trabajar con ella.
• Es mucho más complicado que se esté produciendo un cambio de paradigma .

Por ejemplo, tuve la tarea de transferir un programa para usar Docker. El programa fue desarrollado a lo largo de los años por un equipo. Vengo, hacemos todo lo que está escrito en los libros: pintamos historias de usuarios, roles, vemos qué y cómo lo hacen, sus rutinas estándar.

Yo digo:

- Docker puede resolver todos tus problemas. Mira cómo se hace esto.

- Todo estará en el botón - ¡genial! Pero queremos que SSH lo haga dentro de los contenedores de Kubernetes.

- Espera, no hay SSH en ningún lado.

- Sí, sí, todo está bien ... ¿Pero es posible SSH?

Para convertir la percepción de los usuarios en una nueva dirección, lleva mucho tiempo, requiere trabajo educativo y mucho esfuerzo.

Otro factor de precio es que el registro Docker es un repositorio externo para imágenes, necesita ser instalado y controlado de alguna manera. Tiene sus propios problemas, un recolector de basura, etc., y a menudo puede caerse si no lo sigue, pero todo está resuelto.

Kubernetes

Finalmente llegamos a Kubernetes. Este es un excelente sistema de administración de aplicaciones OpenSource que es activamente apoyado por la comunidad. Aunque originalmente dejó una compañía, Kubernetes ahora tiene una gran comunidad, y es imposible mantenerse al día, prácticamente no hay alternativas.

Curiosamente, todos los nodos de Kubernetes funcionan en Kubernetes a través de contenedores, y todas las aplicaciones externas funcionan a través de contenedores, ¡ todo funciona a través de contenedores ! Esto es tanto un plus como un menos.

Kubernetes tiene una gran cantidad de funcionalidades y propiedades útiles: distribución, tolerancia a fallas, la capacidad de trabajar con diferentes servicios en la nube y orientación hacia la arquitectura de microservicios. Todo esto es interesante y genial, pero ¿cómo instalar la aplicación en Kubernetes?

¿Cómo instalar la aplicación?

Instale la imagen Docker en el registro Docker.

Detrás de esta frase yace un abismo. Imagínese: tiene una aplicación escrita, por ejemplo, en Ruby, y debe colocar la imagen de Docker en el registro de Docker. Esto significa que debes:

• Prepare una imagen de Docker
• entender cómo va, en qué versiones se basa;
• ser capaz de probarlo;
• recopilar, complete el registro de Docker, que, por cierto, instaló antes.

De hecho, este es un gran dolor en una línea.

Además, aún necesita describir el manifiesto de la aplicación en términos (recursos) de k8s. La opción más fácil:

• describe despliegue + pod, servicio + ingreso (posiblemente);
• ejecute el comando kubectl apply -f resources.yaml y transfiera todos los recursos a este comando.

Gandhi frota sus manos en la diapositiva, parece que encontré el administrador de paquetes en Kubernetes. Pero kubectl no es un administrador de paquetes. Simplemente dice que quiero ver un estado tan final del sistema. Esto no es instalar un paquete, no funciona con dependencias, no se construye, es solo "Quiero ver este estado final".

Timón

Finalmente llegamos a Helm. Helm es una utilidad multipropósito. Ahora consideraremos qué áreas de desarrollo de Helm y trabajaremos con él.

Motor de plantillas

En primer lugar, Helm es un motor de plantillas. Discutimos qué recursos deben prepararse, y el problema es escribir en términos de Kubernetes (y no solo en yaml). Lo más interesante es que estos son archivos estáticos para su aplicación específica en este entorno en particular.

Sin embargo, si trabaja con varios entornos y no solo tiene producción, sino también etapas, pruebas, desarrollo y diferentes entornos para diferentes equipos, debe tener varios manifiestos similares. Por ejemplo, porque en uno de ellos hay varios servidores, y necesita tener una gran cantidad de réplicas, y en el otro, solo una réplica. No hay base de datos, acceso a RDS, y necesita instalar PostgreSQL dentro. Y aquí tenemos la versión anterior, y necesitamos reescribir todo un poco.

Toda esta diversidad lleva al hecho de que tienes que tomar tu manifiesto para Kubernetes, copiarlo en todas partes y arreglarlo en todas partes: aquí reemplaza un dígito, aquí hay algo más. Esto se está volviendo muy incómodo.

La solución es simple: debe ingresar plantillas . Es decir, forma un manifiesto, define variables en él y luego envía las variables definidas externamente como un archivo. La plantilla crea el manifiesto final. Resulta reutilizar el mismo manifiesto para todos los entornos, lo cual es mucho más conveniente.

Por ejemplo, el manifiesto para Helm.

• La parte más importante de Helm es Chart.yaml , que describe qué tipo de manifiesto es, qué versiones y cómo funciona.
• Las plantillas son solo plantillas de recursos de Kubernetes que contienen algún tipo de variables dentro de sí mismas. Estas variables deben definirse en un archivo externo o en la línea de comando, pero siempre externamente.
• values.yaml es el nombre estándar del archivo con variables para estas plantillas.

El comando de inicio más simple para instalar el gráfico es helm install ./wordpress (carpeta). Para redefinir algunos parámetros, decimos: "Quiero redefinir precisamente estos parámetros y establecer tales o cuales valores".

Helm hace frente a esta tarea, por lo que en el diagrama lo marcamos en verde.


Es cierto, los contras aparecen:

• Verbosidad Los recursos se definen completamente en términos de Kubernetes, no se introducen conceptos de niveles adicionales de abstracción: simplemente escribimos todo lo que nos gustaría escribir para Kubernetes y reemplazamos las variables allí.
• No te repitas, no aplica. A menudo es necesario repetir lo mismo. Si tiene dos servicios similares con nombres diferentes, debe copiar completamente la carpeta completa (la mayoría de las veces lo hacen) y cambiar los archivos necesarios.

Antes de sumergirnos en la dirección de Helm, un administrador de paquetes, para lo cual te cuento todo esto, veamos cómo funciona Helm con las dependencias.

Trabajar con dependencias

Helm es difícil de trabajar con dependencias. En primer lugar, hay un archivo require.yaml que se ajusta a lo que dependemos. Mientras trabaja con los requisitos, realizaquisits.lock: este es el estado actual (pepita) de todas las dependencias. Después de eso, los descarga en una carpeta llamada / gráficos.

Hay herramientas para administrar: a quién, cómo, dónde conectarse: etiquetas y condiciones , con las cuales se determina en qué entorno, según qué parámetros externos, conectar o no conectar algunas dependencias.

Supongamos que tiene PostgreSQL para el entorno de ensayo (o RDS para producción o NoSQL para pruebas). Al instalar este paquete en Producción, no instalará PostgreSQL, porque no es necesario allí, solo usando etiquetas y condiciones.

¿Qué es interesante aquí?

• Helm mezcla todos los recursos de todas las dependencias y aplicaciones;
• ordenar -> instalar / actualizar

Después de que hayamos descargado todas las dependencias en / charts (estas dependencias pueden ser, por ejemplo, 100), Helm toma y copia todos los recursos que contiene. Después de procesar las plantillas, recopila todos los recursos en un solo lugar y los ordena en algún tipo de orden. No puedes influir en este orden. Debe determinar por sí mismo de qué depende su paquete, y si el paquete tiene dependencias transitivas, entonces debe incluirlos todos en la descripción en require.yaml. Esto debe tenerse en cuenta.

Administrador de paquetes

Helm instala aplicaciones y dependencias, y puede decirle a Helm install, e instalará el paquete. Entonces este es un administrador de paquetes.

Al mismo tiempo, si tiene un repositorio externo donde carga el paquete, puede acceder a él no como una carpeta local, sino simplemente decir: "Desde este repositorio, tome este paquete, instálelo con tal o cual parámetro".

Hay repositorios abiertos con muchos paquetes. Por ejemplo, puede ejecutar: helm install -f prod / values.yaml stable / wordpress

Desde el repositorio estable, tomará WordPress y lo instalará usted mismo. Puedes hacer todo: buscar / actualizar / eliminar. Resulta que, en realidad, Helm es un administrador de paquetes.

Pero hay inconvenientes: todas las dependencias transitivas deben incluirse dentro. Este es un gran problema cuando las dependencias transitivas son aplicaciones independientes y desea trabajar con ellas por separado para pruebas y desarrollo.

Otra desventaja es la configuración de extremo a extremo . Cuando tiene una base de datos y su nombre debe transferirse a todos los paquetes, esto puede ser, pero es difícil de hacer.



La mayoría de las veces, ha instalado un paquete pequeño y funciona. El mundo es complejo: la aplicación depende de la aplicación, que a su vez también depende de la aplicación; debe configurarlos de alguna manera inteligente. Helm no sabe cómo apoyar esto, o lo soporta con grandes problemas, y a veces tienes que bailar mucho con una pandereta para que funcione. Esto es malo, por lo que el "administrador de paquetes" en el diagrama está resaltado en rojo.

Ensamblaje y embalaje

"No se puede obtener y ejecutar" la aplicación en Kubernetes. Debe ensamblarlo, es decir, hacer una imagen de Docker, escribirla en el registro de Docker, etc. Aunque toda la definición del paquete en Helm es. Determinamos qué es el paquete, qué funciones y campos deberían estar allí, firmas y autenticación (el sistema de seguridad de su empresa estará muy contento). Por lo tanto, por un lado, el ensamblaje y el empaque parecen ser compatibles, y por otro lado, el trabajo con imágenes Docker no está configurado.

Helm no le permite ejecutar la aplicación sin una imagen de Docker. Al mismo tiempo, Helm no está configurado para ensamblar y empaquetar, es decir, no sabe cómo trabajar con imágenes de Docker.

Esto es lo mismo que si, para realizar una instalación de actualización para una biblioteca pequeña, se le enviara a una carpeta distante para ejecutar el compilador.

Por lo tanto, decimos que Helm no sabe cómo trabajar con imágenes.

Desarrollo

El próximo dolor de cabeza es el desarrollo. En desarrollo, queremos cambiar rápida y convenientemente nuestro código. Ha pasado el tiempo cuando perforaste las tarjetas perforadas, y el resultado se obtuvo después de 5 días. Todos están acostumbrados a reemplazar una letra con otra en el editor, presionar la compilación, y el programa ya modificado funciona.

Resulta que al cambiar el código, se necesitan muchas acciones adicionales: preparar un archivo Docker; Ejecute Docker para que construya la imagen; empujarlo a alguna parte; implementar en el clúster de Kubernetes. Y solo entonces obtendrá lo que desea en Producción, y podrá verificar el código.

Todavía hay inconvenientes debido a la actualización destructiva helm upgrade. Miraste cómo funciona todo, a través de kubectl exec miraste dentro del contenedor, todo está bien. En este punto, comienza la actualización, se descarga una nueva imagen, se inician nuevos recursos y se eliminan los antiguos; debe comenzar todo desde el principio.

El mayor dolor son las grandes imágenes . La mayoría de las empresas no trabajan con aplicaciones pequeñas. A menudo, si no es un supermonolito, entonces al menos un pequeño monolítico. Con el tiempo, los anillos anuales crecen, la base del código aumenta y gradualmente la aplicación se vuelve bastante grande. En repetidas ocasiones me encontré con imágenes de Docker de más de 2 GB. Imagine ahora que está realizando un cambio en un byte en su programa, presione un botón y una imagen Docker de dos gigabytes comienza a ensamblarse. Luego presiona el botón Siguiente y comienza la transferencia de 2 GB al servidor.

Docker le permite trabajar con capas, es decir comprueba si hay una capa u otra y envía la que falta. Pero el mundo es tal que la mayoría de las veces será una gran capa. Mientras que 2 GB irán al servidor, mientras que irán a Kubernetes con el registro Docker, se implementarán de todas las formas, hasta que finalmente comience, puede beber té con seguridad.

Helm no ofrece ninguna ayuda con imágenes Docker grandes. Creo que esto no debería ser así, pero los desarrolladores de Helm lo saben mejor que todos los usuarios, y Steve Jobs le sonríe.



El bloque con el desarrollo también se volvió rojo.

Automatización Ambiental

La última dirección, la automatización del medio ambiente, es un área interesante. Antes del mundo de Docker (y Kubernetes, como modelo relacionado), no había forma de decir: "¡Quiero instalar mi aplicación en este servidor o en estos servidores para que haya n réplicas, 50 dependencias, y todo funciona automáticamente!" Tal, se podría decir, ¡qué fue, pero no fue!

Kubernetes proporciona esto y es lógico usarlo de alguna manera, por ejemplo, para decir: "Estoy implementando un nuevo entorno aquí y quiero que todos los equipos de desarrollo que han preparado sus aplicaciones puedan hacer clic en un botón y todas estas aplicaciones se instalarán automáticamente en el nuevo entorno" . Teóricamente, Helm debería ayudar en esto, de modo que la configuración se pueda tomar de una fuente de datos externa, S3, GitHub, desde cualquier lugar.

Es recomendable que haya un botón especial en Helm "¡Hazme el bien, finalmente!" - e inmediatamente se volvería bueno. Kubernetes te permite hacer esto.

Esto es especialmente conveniente porque Kubernetes se puede ejecutar en cualquier lugar y funciona a través de la API. Al iniciar minikube localmente, ya sea en AWS o en Google Cloud Engine, obtienes Kubernetes de inmediato y funciona igual en todas partes: presiona un botón y todo está bien de inmediato.

Parece que, naturalmente, Helm te permite hacer esto. Porque de lo contrario, ¿qué sentido tenía crear Helm en general?

Pero resulta que no!


No hay automatización del medio ambiente.

Alternativas

Cuando hay una aplicación de Kubernetes que todos usan (ahora es de hecho la solución número 1), pero Helm tiene los problemas discutidos anteriormente, la comunidad no pudo evitar responder. Comenzó a crear herramientas y soluciones alternativas.

Motores de plantillas

Parecería que, como motor de plantillas, Helm resolvió todos los problemas, pero aún así la comunidad crea alternativas. Permíteme recordarte los problemas del motor de plantillas: verbosidad y reutilización de código.

Un buen representante aquí es Ksonnet. Utiliza un modelo de datos y conceptos fundamentalmente diferente, y no funciona con los recursos de Kubernetes, sino con sus propias definiciones:
prototipo (params) -> componente -> aplicación -> entornos.


Hay partes que componen el prototipo. El prototipo está parametrizado por datos externos y aparece el componente. Varios componentes componen una aplicación que puede ejecutar. Se ejecuta en diferentes entornos. Aquí hay algunos enlaces claros a los recursos de Kubernetes, pero puede que no haya una analogía directa.

El objetivo principal de Ksonnet era, por supuesto, reutilizar recursos . Querían asegurarse de que una vez que escribiste el código, pudieras usarlo en cualquier lugar, lo que aumenta la velocidad de desarrollo. Si crea una gran biblioteca externa, las personas pueden publicar constantemente sus recursos allí, y toda la comunidad podrá reutilizarlos.

Teóricamente, esto es conveniente. .

, — , , . Ksonnet . Ksonnet Helm , , .. , , , .


, , , , . . , , , 0.1. , .


, — KubePack , .

Desarrollo

:

1. Helm;
   
2. Helm;
   
3. , ;
   
4. , .
   

1. Helm

— Draft . — , , . Draft — Heroku-style:

• (pack);
• , , Python «Hello, world!»;
• , Docker- ( );
• , , docker-registry, ;
• .

, , .

Helm, Draft Helm-, production ready, , Draft Helm-, . .

, Draft , Helm-. Draft — .

2. Helm

Helm Charts Kubernetes-, Helm Charts. :

• GitKube;
• Skaffold;
• Forge.

Helm, . , , command line interface, Chart , git push .

, docker build, docker push kubectl rollout. , Helm, . .

3.

— . — Metaparticle . , Python, Python , .

, , , sysconfig .. .

, , , - Kubernetes-.

: , ; , ; ..


, , , - , Python- Kubernetes-. ?

- , . . , , preinstall , - . Kubernetes-, Metaparticle, .

, , Kubernetes- . , , Metaparticle.



Metaparticle, Helm . , .

Telepresence/Ksync — . , , Helm-, . , - , - , , . , Production-, Production - .

Kubernetes , Docker, registry, Kubernetes. . , .

, , , Development . : , , , , — , , , Helm, , .

, .

4. Kubernetes Kubernetes

, Kubernetes Kubernetes. , Helm- , . , . , Docker-compose .

Docker-compose , , , , Docker, Kubernetes, Docker-compose, . , . , Docker. .

minikube , Docker-compose, . , , Docker-compose — 10 . , .


Docker-compose, , .

, — Helm, , , Helm - . CI/CD, , . — Helm, ? , , .

CI/CD, , docker', set-, , — .

CI/CD — , .

Resumen

5 Helm . , . , , . , , , .

Helm

, , Helm . , Helm , . , , , Helm.

, Road Map. Kuberneres Helm community , , Helm V3 .

Tiller, cli

, . Helm :

1. , (cmd ..).
   
2. Tiller — , Kubernetes.
   

Tiller , Command Line Interface. : « Chart» — Helm , , Tiller', : «, - ! , Kubernetes-» — .

Helm, Tiller , . , , , , Tiller' — namespace . Tiller namespace, , . , .

V3 Tiller .


? , , Command Line Interface, , Kubernetes. , Kubernetes , Tiller. kubectl cli .

Tiller . , Kubernetes Command Line Interface : , , , pre- post-. .

Lua- Chart

, — , lua- . Chart lua-, . . , . , , , .


Lua , , , - , , .

, , . , . Kubernetes, - , , , , . Veamos que pasa.

Release- + secret

, , Release- , Release . , Release-, , , CRD, , .

namespace

Release- namespace, , - Tiller' namespace — , .

CRD: controller

, CRD-controller Helm , push-. .

, .


, Helm . , , , . , , . Helm — - Kubernetes. - , , .

, CI/CD , . Slack, tenemos un bot que informa cuando una nueva compilación pasó en master, y que todas las pruebas fueron exitosas. Usted le dice: "Quiero instalar esto en la puesta en escena", y él instala, usted dice: "¡Quiero ejecutar una prueba allí!" - Y él comienza. Bastante comodo

Para el desarrollo, use Docker-compose o Telepresence.

Varias versiones de un servicio.

Al final, analizaremos la situación cuando hay dos aplicaciones A y B, que dependen de C, pero C de diferentes versiones. Necesito resolver este problema:

• para el desarrollo, porque de hecho tenemos que desarrollar lo mismo, pero dos versiones diferentes;
• para liberar;
• para un conflicto de nombres, porque en todos los administradores de paquetes estándar, instalar dos paquetes de versiones diferentes puede causar problemas.

De hecho, Kubernetes decide todo por nosotros, solo necesita usarlo correctamente.



Aconsejaría crear 4 Gráficos en términos de Helm, 3 repositorios (para el repositorio C, esto solo serán dos ramas diferentes). Lo que es más interesante, todas las instalaciones para v1 y para v2 deben contener información sobre la versión o para qué servicio se creó. Una solución en la diapositiva, apéndice C; el nombre de la versión indica que esta es la versión v1 para el servicio A; El nombre del servicio también contiene la versión. Este es el ejemplo más simple, puede hacerlo de manera completamente diferente. Pero lo más importante es que los nombres son únicos.

El segundo son las dependencias transitivas, y aquí es más complicado.


Por ejemplo, está desarrollando una cadena de servicios y desea probar A. Para esto, debe transferir todas las dependencias de las que depende A, incluida la transitiva, a la definición Helm de su paquete. Pero al mismo tiempo, desea desarrollar B y también probarlo: cómo hacerlo es incomprensible, porque también necesita poner todas las dependencias transitivas en él.

Por lo tanto, le aconsejo que no agregue todas las dependencias dentro de cada paquete, sino que las haga independientes y desde el exterior controlen lo que se está ejecutando. Esto es inconveniente, pero es el menor de dos males.

Enlaces utiles

• Borrador

• GitKube

• Timón

• Ksonnet

• Pegatinas de Telegram: una , dos

• Sig-Apps

• KubePack

• Metapartículas

• Skaffold

• Helm v3

• Docker-componer

• Ksync

• telepresencia

• Drone

• fragua

Perfil del orador Ivan Glushkov en GitHub , en twitter , en Habr .

Buenas noticias

En nuestro canal de YouTube, abrimos un video de todos los informes sobre DevOps del festival RIT ++ . Esta es una lista de reproducción separada, pero en la lista completa de videos hay muchas cosas útiles de otras conferencias.

Mejor aún, suscríbase al canal y al boletín , porque en el próximo año veremos muchos devops : en mayo, el marco de RIT ++; en primavera, verano y otoño como una sección de HighLoad ++, y un otoño independiente DevOpsConf Rusia .