🍸 🧕🏼 👩🏽‍🌾 Cómo convertirse en ingeniero de DevOps en seis meses o incluso más rápido. Parte 4. Empaquetado de software 🐨 🧙🏿 👩‍⚕️

Cómo convertirse en ingeniero de DevOps en seis meses o incluso más rápido. Parte 1. Introducción
Cómo convertirse en un ingeniero DevOps en seis meses o incluso más rápido. Parte 2. Configuración
Cómo convertirse en un ingeniero DevOps en seis meses o incluso más rápido. Parte 3. Versiones

Considere cómo empaquetar su código para una fácil implementación y posterior ejecución. Déjame recordarte que estamos aquí ahora:

Independientemente de si está hablando con sus empleadores actuales o futuros, debe poder articular claramente qué es DevOps y por qué es importante.
Proporcione una historia coherente sobre la mejor manera de entregar el código de manera rápida y eficiente desde la computadora portátil del desarrollador al lugar de implementación del producto final con el beneficio adecuado. No estudiamos un montón de herramientas DevOps dispares y de moda, sino un conjunto de habilidades, guiadas por las necesidades del negocio y confiando en herramientas técnicas. Recuerde que estudiar cada etapa de DevOps requiere aproximadamente un mes de capacitación, lo que en total le llevará seis meses.

Tutorial de virtualización

¿Recuerdas los servidores físicos? ¿Los mismos servidores por los que ha estado esperando semanas para la aprobación de la orden de compra, la aprobación del proceso de envío, la aprobación del centro de datos, la conexión de red, la instalación del sistema operativo y los parches? Estos son los servidores que llegaron a nuestras vidas.

Imagine que la única forma de encontrar una casa es construir una casa nueva. Después de todo, ¿necesitas vivir en algún lado? ¡Espere hasta que se construya, no importa cuánto tiempo tarde! Parece genial, porque todos tienen su propio hogar, pero pesado, porque su construcción lleva mucho tiempo. Siguiendo esta analogía, un servidor físico es como un hogar.

Con el tiempo, este proceso se volvió molesto y a las personas realmente inteligentes se les ocurrió la idea de la virtualización. Decidieron ejecutar un montón de máquinas imaginarias en una máquina física e hicieron que cada una de ellas pretendiera ser una máquina real. ¡Ingenioso!

Por lo tanto, si realmente necesita una casa, puede construir la suya y esperar seis semanas. O puede mudarse a un edificio de apartamentos y compartir recursos con otros residentes. Quizás no tan genial, ¡pero lo suficientemente bueno! Y lo más importante, ¡no necesitas esperar nada!

Esto continuó por algún tiempo, y compañías como VMWare obtuvieron un gran capital en esto. Luego, otras personas inteligentes decidieron que empujar un montón de máquinas virtuales en una máquina física no es suficiente: necesita un paquete más compacto de más procesos en menos recursos.

Entonces, una casa o incluso un departamento es demasiado costoso, ¿entonces tal vez intente alquilar una habitación temporalmente? ¡Además, puedo entrar y salir en cualquier momento! Esto es lo que Docker representa esencialmente a partir de diciembre de 2018.

Docker de nacimiento

Docker es una nueva tecnología basada en una idea muy antigua. El sistema operativo FreeBSD contenía el concepto del motor de virtualización de la cárcel, que data del año 2000. En verdad, todo lo nuevo está bien olvidado.

Y luego, y ahora la idea era aislar procesos individuales dentro del mismo sistema operativo basado en la virtualización a nivel del sistema operativo, o "virtualización a nivel del sistema". Tenga en cuenta que esto no es lo mismo que la virtualización completa, o "virtualización completa", que ejecuta máquinas virtuales en paralelo en el mismo host físico.

En la práctica, esto significa que la creciente popularidad de Docker refleja con precisión el crecimiento de los microservicios, un enfoque para el desarrollo de software en el que el software se divide en muchos componentes separados. Y todos estos componentes necesitan su hogar. Implementarlos individualmente como aplicaciones Java independientes o ejecutables binarios es un gran problema: la forma en que controlas una aplicación Java es diferente de la forma en que controlas una aplicación C ++, y esto, a su vez, es diferente de administrar una aplicación Golang .

En cambio, Docker proporciona una única interfaz de administración que permite a los programadores empaquetar, implementar secuencialmente y ejecutar varias aplicaciones. Esta es una gran victoria, pero hablemos de los pros y los contras de Docker.

Ventajas de Docker

1. Aislamiento de procesos

Docker permite que cada servicio tenga un proceso completamente aislado. El servicio A vive en su propio contenedor pequeño, con todas sus dependencias, el servicio B también vive en su propio contenedor privado con todas sus dependencias, y los dos servicios no entran en conflicto.

Además, si un contenedor falla, solo este contenedor sufrirá.

Los contenedores restantes deberán y deben continuar funcionando. Tal mecanismo es beneficioso para la seguridad. Si el contenedor se ve comprometido, será muy difícil (¡pero no imposible!) Salir de él para romper el sistema operativo base.

Finalmente, si el contenedor se comporta incorrectamente (consume demasiados recursos de procesador o memoria), puede reducir el "radio de explosión" para ese contenedor solo sin afectar el resto del sistema.

2. Despliegue

Piense en cómo se crean las diferentes aplicaciones en la práctica. Si se trata de una aplicación Python, tendrá muchos paquetes Python diferentes. Algunos de ellos se instalarán como módulos pip, otros como paquetes rpm o deb, y otros como simples instalaciones de git-clone. O, si se hace con virtualenv, entonces será un único archivo zip de todas las dependencias en el directorio virtualenv.

Por otro lado, si es una aplicación Java, tendrá un ensamblado Gradle Built, con todas sus dependencias extendidas y dispersas en los lugares apropiados.

¿Ves lo que pasa? Las diferentes aplicaciones, los ensamblados con diferentes idiomas y los diferentes tiempos de ejecución plantean un problema a la hora de implementar estas aplicaciones para productos. Además, el problema se agrava si surgen conflictos. ¿Qué sucede si el servicio A depende de la biblioteca Python v1 y el servicio B depende de la biblioteca Python v2? Aquí hay un conflicto, ya que v1 y v2 no pueden coexistir en la misma máquina.

Y luego Docker entra en juego. Le permite aislar completamente no solo el proceso, sino también las dependencias. Es posible tener varios contenedores trabajando lado a lado en el mismo sistema operativo, cada uno de los cuales contiene sus propias bibliotecas y paquetes que no son compatibles con los demás.

3. Gestión de la ejecución del programa.

Observo que la forma en que gestionamos aplicaciones dispares depende de la aplicación misma. El código Java se escribe de manera diferente en el registro, se ejecuta de manera diferente y se rastrea de manera diferente que el código Python. Y Python es diferente de Golang, etc.

Con Docker, obtenemos una única interfaz de administración unificada que nos permite iniciar, controlar, centralizar registros, detener y reiniciar muchos tipos diferentes de aplicaciones. Esta es una gran ganancia en productividad, que reduce significativamente los costos operativos de los sistemas operativos de producción.

Desde diciembre de 2018, ya no tendrá que elegir entre el lanzamiento rápido de Docker y la seguridad de las máquinas virtuales. Proyecto de plataforma de virtualización ligera de Fireckracker, presentado por Amazon, trató de combinar lo mejor de ambas soluciones. Sin embargo, esta es una nueva tecnología que solo se está acercando a la fase de producción.

Nota: La plataforma Firecracker proporciona herramientas para crear y administrar entornos y servicios aislados creados con un modelo de desarrollo sin servidor. El código del proyecto está escrito en Rust y distribuido bajo la licencia Apache 2.0.

Firecracker ofrece máquinas virtuales livianas llamadas microVM. Para aislarlos por completo, se utilizan tecnologías de virtualización de hardware, pero al mismo tiempo, se proporciona rendimiento y flexibilidad a nivel de contenedores normales. La plataforma se basa en Virtual Machine Monitor (VMM), que utiliza el hipervisor KVM integrado en el kernel de Linux. VMM se basa en la base del proyecto crosvm escrito en Rust , que Google está desarrollando para lanzar Linux en ChromeOS. A finales de 2018, las bases de código crosvm y Firecracker se dividieron, pero Amazon planea enviar correcciones a los componentes prestados para el flujo ascendente.

Sin embargo, no importa cuán bueno sea el Docker, también tiene inconvenientes.

Introducción a lambda

En primer lugar, ejecutar Docker sigue funcionando en servidores que deben prepararse, parchearse, etc. En segundo lugar, Docker no es 100% seguro. Al menos no es tan seguro como una máquina virtual. Hay una razón por la cual las grandes compañías que trabajan con contenedores alojados hacen esto dentro de máquinas virtuales, y no en metal desnudo. ¡Necesitan tiempos rápidos de lanzamiento de contenedores y seguridad de máquina virtual!

En tercer lugar, nadie controla realmente el Docker como tal. En cambio, casi siempre se implementa como parte de una estructura compleja de orquestación de contenedores como Kubernetes, ECS, docker-swarm o Nomad. Estas son plataformas bastante complejas que requieren personal especial para trabajar (discutiré estas soluciones con más detalle más adelante).

Sin embargo, si solo soy un desarrollador, solo quiero escribir código y pedirle a alguien que lo ejecute por mí. Docker, Kubernetes y otros tipos de jazz: ¿realmente tengo que aprender todo esto? Diré esto: todo depende de las circunstancias. Para las personas que solo quieren que alguien más ejecute su código, el almacenamiento en la nube de AWS Lambda y cosas similares es una gran opción.

AWS Lambda le permite ejecutar código sin aprovisionamiento y administración del servidor. Paga solo por el tiempo de computación que consume, y cuando su código no funciona, no hay ningún cargo.
Si ha oído hablar del almacenamiento sin servidor, este es el lugar. ¡No más servidores de lanzamiento o contenedores de administración! ¡Simplemente escriba su código, empaquételo en un archivo zip, cárguelo en Amazon y déjelos lidiar con su dolor de cabeza! Además, dado que las "lambdas" son de corta duración, no hay nada que las rompa; las "lambdas" son bastante seguras en su diseño. ¿Realmente grandioso?

Pero también hay puntos negativos. En primer lugar, las lambdas solo pueden funcionar durante un máximo de 15 minutos (a partir de noviembre de 2018). Esto significa que los procesos de larga duración, como Kafka o las aplicaciones para descifrar números, no pueden funcionar en Lambda.

En segundo lugar, las "lambdas" son funciones como servicio (funciones como servicio). Esto significa que su aplicación debe descomponerse completamente en microservicios y sincronizarse con otros servicios complejos de PaaS como AWS Step Functions . Sin embargo, no todas las empresas se encuentran en este nivel de arquitectura de microservicios.

Tercero, solucionar problemas de lambdas es muy difícil. Son tiempos de ejecución en la nube y todas las correcciones de errores se producen en el ecosistema de Amazon. Esto es a menudo bastante complejo y poco intuitivo. En resumen, no hay almuerzo gratis aquí.

Observo que a finales de 2018 también hay soluciones de contenedor en la nube sin servidor, como AWS Fargate. Su mecánica es muy similar a la de Lambda. Si recién está comenzando a aprender estos servicios, le recomiendo probar Fargate, que es una forma increíblemente fácil de hacer que los contenedores funcionen "correctamente". Además, el 13 de enero de 2019, los servicios en la nube de AWS anunciaron una reducción significativa en el precio de Fargate, por lo que es una opción muy atractiva para lanzar contenedores sin servidor.

Resumen

Docker y Lambda son los dos enfoques modernos más populares basados en la nube para empaquetar, ejecutar y administrar aplicaciones. A menudo son gratuitos, ambos adecuados para varios casos de uso y aplicaciones.

Sea como fuere, el ingeniero de DevOps moderno debe estar bien versado en ambos. Por lo tanto, entrenar a Docker y Lambda son buenos objetivos a corto y mediano plazo.
Observo que hasta ahora hemos tratado temas que los ingenieros de nivel medio e intermedio de DevOps deberían conocer. En las siguientes secciones, comenzaremos a analizar los métodos que son más adecuados para los ingenieros DevOps de nivel medio y superior. ¡Como siempre, no hay formas fáciles de adquirir conocimiento!

Continuará muy pronto ...

Un poco de publicidad :)

Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos, VPS en la nube para desarrolladores desde $ 4.99 , un análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps desde $ 19 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? ¡Solo tenemos 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre Cómo construir un edificio de infraestructura. clase c con servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?

Cómo convertirse en ingeniero de DevOps en seis meses o incluso más rápido. Parte 4. Empaquetado de software