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

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

Refresca tu memoria rápidamente


En la primera parte, sostuve que el trabajo del ingeniero DevOps es crear tuberías digitales totalmente automatizadas que muevan el código de la máquina del desarrollador a la producción. Hacer este trabajo de manera efectiva requiere una comprensión de los conceptos básicos, que son el sistema operativo, un lenguaje de programación y un servicio de almacenamiento en la nube, así como una buena comprensión de las herramientas y habilidades basadas en esto.

Permíteme recordarte que tu objetivo es estudiar primero las cosas azules de izquierda a derecha, y luego también estudiar las cosas moradas de izquierda a derecha. Ahora veremos el primero de los 6 meses de capacitación dedicados a la configuración.



¿Qué sucede en la etapa de configuración? Dado que el código que creamos necesita máquinas para ejecutarse, la fase de configuración realmente crea la infraestructura que ejecuta nuestro código.

En el pasado, la creación de infraestructura de soporte era una prueba larga, lenta y propensa a errores. Ahora que tenemos nuestra increíble nube, todos los preparativos se pueden hacer con el clic de un botón. O al menos unos toques. Sin embargo, resulta que presionar botones para completar estas tareas es una mala idea porque significa:
  • propensión a cometer errores (y las personas cometen errores);
  • ignorar versiones (los clics de los botones no se pueden almacenar en el repositorio de Git);
  • irreproducibilidad y no repetibilidad (más autos = más clics);
  • ( , ).




Por ejemplo, piense en todo el trabajo necesario para proporcionar su entorno de desarrollo ... luego un entorno int ... luego QA ... luego puesta en escena ... luego pinchar en los Estados Unidos ... luego pinchar en la UE ... rápidamente se volverá bastante tedioso y molesto. Por lo tanto, en lugar de clics mecánicos del botón del mouse, se usa un nuevo método llamado "infraestructura como código", y esto es lo que se discutirá en esta etapa de la configuración de su sistema. "Infraestructura como código" significa configurar un sistema utilizando archivos de configuración, en lugar de editar manualmente las configuraciones en los servidores o interactivamente. Este método puede ser una descripción declarativa o programada de la infraestructura. De acuerdo con las mejores prácticas de DevOps, la "infraestructura como código" requiere que cualquier trabajo necesario para proporcionar recursos informáticos,realizado solo con código. Por "recursos informáticos" me refiero a todo lo necesario para que la aplicación se ejecute correctamente en productos: sus propios recursos informáticos, almacenamiento, red, bases de datos, etc. De ahí el nombre: "infraestructura como código".

Además, esto significa que, en lugar de "encajar" nuestro camino a través del despliegue mecánico de infraestructura, haremos lo siguiente:

  • Describir el estado deseado de la infraestructura en Terraform.
  • guárdelo en nuestro sistema de control de versiones de control de código fuente;
  • pasar por el proceso formal de solicitud de extracción para recibir comentarios;
  • prueba de rendimiento;
  • realice la configuración para garantizar el funcionamiento del sistema con todos los recursos necesarios.

¿Por qué es esto y no eso?


La pregunta obvia es: “¿Por qué Terraform? ¿Por qué no Chef, Puppet, Ansible, CFEngine, Salt o CloudFormation? ” ¡Buena pregunta! Durante su discusión, se derramaron barriles enteros de tinta virtual. Creo que deberías aprender Terraform porque:

  • está muy de moda, por lo que tendrá muchas oportunidades de empleo;
  • es más fácil de digerir;
  • Es un producto multiplataforma.

Por supuesto, puede elegir cualquier otra opción y también tener éxito. Pero tengo que tener en cuenta lo siguiente. Esta industria se está desarrollando rápidamente y de manera bastante aleatoria, pero veo ese desarrollo: tradicionalmente, se usaban cosas como Terraform y CloudFormation para proporcionar infraestructura, mientras que Ansible y sistemas similares se usaban para configurarla.



Por lo tanto, puede considerar Terraform como una herramienta de base y Ansible como una grúa para construir una casa sobre esta base, con el despliegue posterior de la aplicación como techo (el despliegue también se puede hacer usando Ansible).
En otras palabras, crea sus máquinas virtuales con Terraform y luego usa Ansible para configurar los servidores y desplegar sus aplicaciones. Tradicionalmente, estas cosas se usan de esta manera.

Sin embargo, Ansible puede hacer mucho de lo que (si no todo) Terraform puede hacer, pero lo contrario también es cierto. No dejes que esto te moleste. Solo sepa que Terraform es una de las herramientas de infraestructura como código líderes de la industria, por lo que le recomiendo que comience con ella.



De hecho, la experiencia con Terraform + AWS es una de las habilidades de ingeniería más buscadas de DevOps. Pero incluso si va a donar Ansible a Terraform, aún necesita saber cómo configurar mediante programación una gran cantidad de servidores, ¿verdad? ¡Resulta que esto no es necesario!

Despliegue inmutable


Predigo que las herramientas de administración de configuración como Ansible perderán su importancia, mientras que las herramientas de aprovisionamiento de infraestructura como Terraform o CloudFormation lo aumentarán. Y todo esto debido a lo que se llama "despliegue inmutable". En pocas palabras, esto significa la práctica de nunca cambiar la infraestructura implementada, es decir, su unidad de implementación es una máquina virtual o un contenedor Docker, no una pieza de código.

En este caso, no implementa el código en un conjunto de máquinas virtuales estáticas, sino que implementa las máquinas virtuales completas junto con el código incorporado en ellas. No cambia la forma en que configura las máquinas virtuales, sino que implementa nuevas máquinas virtuales con la configuración deseada. No está arreglando máquinas de producción; está implementando máquinas nuevas ya arregladas.

No inicias un conjunto de máquinas virtuales en dev, y otro conjunto de máquinas en prod, son todos iguales. De hecho, puede deshabilitar completamente todo el acceso SSH a todas las máquinas de producción, porque no hay nada que hacer allí: no hay configuraciones que cambiar, no hay registros para ver (hablaré más sobre los registros más adelante). Cuando se usa correctamente, esta es una plantilla muy poderosa que recomiendo usar.

Las implementaciones inmutables requieren que la configuración esté separada de su código. Lea el manifiesto de la aplicación The Twelve-Factor , que detalla esto (¡y otras ideas increíbles!) Con gran detalle. Esta es una lectura obligada para practicar DevOps.

Desconectar el código de la configuración es muy importante, ya que no desea volver a implementar toda la pila de aplicaciones cada vez que "engaña" las contraseñas de su base de datos. En su lugar, asegúrese de que las aplicaciones lo recuperen de un almacén de configuración externo (SSM / Consul / etc.). Además, puede ver fácilmente cómo con la llegada de implementaciones inmutables, herramientas como Ansible comienzan a desempeñar un papel menos destacado. La razón es que solo necesita configurar un servidor e implementarlo muchas veces como parte de su grupo de escalado automático.

Si crea contenedores, entonces, por definición, necesita implementaciones inmutables. No desea que su contenedor de desarrollo sea diferente del contenedor de control de calidad, que también será diferente del contenedor de productos. Necesita exactamente el mismo contenedor en todos los entornos, ya que esto evita el sesgo de configuración y simplifica la reversión en caso de problemas.

Además de los contenedores, para aquellos que recién comienzan, preparar su infraestructura de AWS utilizando Terraform es un buen modelo de capacitación de DevOps y lo que realmente necesita aprender.

Pero espere ... ¿y si necesita mirar los registros para solucionar el problema? En este caso, no necesita ingresar a las máquinas para ver los registros; solo mire la infraestructura de registro centralizada para todos sus registros. Algún tipo ya ha publicado un artículo detallado sobre este recurso sobre cómo implementar la pila ELK en AWS ECS, puede leerlo para descubrir cómo se hace esto en la práctica. Una vez más, puede desactivar completamente el acceso remoto y sentirse mucho más seguro que la mayoría de las personas allí.

Para resumir, podemos decir que nuestro viaje totalmente automatizado "DevOps" comienza con la preparación de los recursos informáticos necesarios para completar la fase de configuración del código. Y la mejor manera de lograr esto es usar implementaciones inmutables. Si está interesado en dónde comenzar, ¡tome la combinación Terraform + AWS como punto de partida!

Eso es todo para la fase de configuración, en el próximo artículo consideraremos la segunda fase: la versión.

Cómo convertirse en ingeniero de DevOps en seis meses o incluso más rápido. Parte 3. Versiones

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?

All Articles