Get best of the week

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

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
Cómo convertirse en un ingeniero DevOps en seis meses o incluso más rápido. Parte 4. Empaquetado de software



Actualizar la memoria


La imagen de arriba muestra cómo debería ser un despliegue de código típico. Permítame recordarle dónde estamos ahora de acuerdo con la hoja de ruta:



si pasó un mes en el estudio de cada sección, ahora tiene 4 meses. En este momento, ya debe saber cómo proporcionar la infraestructura que funcionará con su software, cómo administrar adecuadamente las versiones de software y cómo empaquetarlas para su futura implementación. En este artículo, discutiremos cómo implementar correctamente su código.

Implementación de código


¿Te diste cuenta de que dije "cómo" y no "qué fácil"? No es solo eso. Desafortunadamente, la implementación correcta del código del entorno de desarrollo al entorno de producción sigue siendo un proceso doloroso, lleno de errores y bloqueos. Hay muchas razones para esto, pero, en mi opinión, se reduce principalmente a las diferencias entre el entorno en el que se crea el código y el entorno en el que se ejecuta.

Minimizar estas diferencias es lo mejor que puede hacer no solo durante el proceso de implementación, sino también durante su ejecución después de la implementación. Entonces, ¿cómo reducimos y / o eliminamos las diferencias entre nuestros entornos prod y no prod?

¡Y funciona en mi auto!


Si su infraestructura de desarrollo se ve así:



Y la infraestructura de producción se ve así :



considere su problema. Si usa la infraestructura como un código y no configura las cosas manualmente, puede resolverla en un 90%. Si no, no te desesperes, no estás solo. Destaque la tarde, determine qué vacíos tiene (capacitación, cultura, personas, procesos, etc.) y colóquelos metódicamente uno por uno.

La conclusión es que no logrará administrar una pila de tecnología moderna si todavía está configurando cosas manualmente. Este es un axioma. Lo primero que debe hacer es asegurarse de que todo lo relacionado con prod sea el artefacto versionado implementado por su servidor de implementación.

Suponiendo que se haya hecho todo esto, me tomaré la libertad de afirmar que la mejor manera de implementar el código es no implementarlo en absoluto.

Enfoque moderno de implementación


Es cierto que la implementación de código en máquinas es un eco de la década de 1990. El mayor problema al implementar código en un conjunto de máquinas de producción es que, por definición, sus servidores de producción (en los que se ejecuta el código) son diferentes de sus servidores de desarrollo (donde se escribe este código). No es sorprendente que inmediatamente después del despliegue haya muchos problemas que nunca antes se habían notado, ¡porque ahora las condiciones han cambiado!

Por lo tanto, antes de implementar, debe asegurarse de que su artefacto de implementación sea todo el tiempo de ejecución, no parte del código. En otras palabras, implemente su código una vez en el entorno de desarrollo, clone toda la máquina en la que se está ejecutando su código y luego cópielo donde debería estar.



Esto se llama "implementación inmutable" y es una plantilla muy poderosa que le ahorrará muchas horas de dolor de cabeza después de la implementación. Por supuesto, si ejecuta contenedores, se aplica la misma idea: implementa el mismo contenedor en todas partes. Puedes decir: “¡para! ¡Mi producción es diferente de la de desarrollo! ". ¡Y eso es correcto, porque los nombres de usuario / contraseñas de la base de datos, las cadenas de conexión, las ubicaciones del bucket S3 son cosas diferentes! Sí, son cosas muy diferentes.

La forma de resolver este problema es utilizar el principio de configuración de la aplicación de 12 factores. Una aplicación de doce factores almacena la configuración en variables de entorno o variables de entorno env. Las variables de entorno se pueden cambiar fácilmente entre implementaciones sin cambiar el código. A diferencia de los archivos de configuración, es menos probable que los guarde accidentalmente en un repositorio de código y, a diferencia de los archivos de configuración personalizados u otros mecanismos de configuración, como las Propiedades del sistema Java, son un estándar independiente del idioma y del sistema operativo. Por lo tanto, toda su configuración debe externalizarse y transferirse como variables de entorno a su computadora.

Por ejemplo, si está en AWS, use SSM como un depósito externo de parámetros: se integra perfectamente con CloudFormation. También es muy fácil establecer variables de entorno directamente desde los comandos de AWS ssm cli. Por supuesto, otros proveedores de la nube tienen mecanismos similares.

Además, resista el impulso de "arreglar" sus máquinas de producción cuando algo sale mal. Las máquinas deben ser inmutables, lo que significa que todas las correcciones que realice deben provenir de dev. Su objetivo debe ser evitar el acceso a las máquinas de producción. Ni ssh, ni scp, ni acceso a productos, nunca a nadie, ni a sí mismo, ni a los piratas informáticos novatos.

Pero, ¿qué sucede si necesito registros para solucionar el problema? Lo has adivinado: tus revistas también deben externalizarse, idealmente enviarse a otra ubicación, ya sea utilizando la pila ElasticSearch / Logstash / Kibana (ELK), o utilizando software comercial como SumoLogic o Datadog.

Hagas lo que hagas, tus máquinas de producción son un "ganado de trabajo" que se reemplaza a la menor señal de mala salud. No son "mascotas" que deben ser atendidas para curarse pasando horas resolviendo problemas.

Sé que esta analogía se usa con demasiada frecuencia, y escucho de personas que realmente se preocupan por el ganado que esto no es del todo cierto, pero la esencia es la misma: no "reparen" sus máquinas de producción, solo arreglen su desarrollo y vuelvan a implementarlo .

Mecánica de implementación de código


Entonces, sabes qué hacer, pero no sabes cómo. Desafortunadamente, aquí es donde aparece Jenkins. Si no lo sabe, Jenkins es uno de los servidores de automatización de implementación de código abierto más populares.



Digo "desafortunadamente" porque Jenkins (y su predecesor Hudson) han estado cerca de nosotros durante casi diez años, y esto es notable. Es complicado de configurar y aún más difícil de mantener. Viene con millones de complementos de dudosa calidad. Estos complementos, por regla general, se rompen en el momento más inoportuno, dejando todo lo demás detrás de ellos. De hecho, realmente estables, los talleres de Jenkins son raros y generalmente solo se ven en las organizaciones más grandes.

¿Por qué te recomiendo que comiences con Jenkins? Porque, a pesar de todas sus deficiencias, sigue siendo extremadamente popular y ampliamente utilizado en el campo de TI. Conocer a Jenkins, en particular cómo está estructurado el Jenkinsfile , es una gran ventaja para las perspectivas laborales y no se puede pasar por alto. Al explorar Jenkins, asegúrese de adoptar el nuevo plugin Pipeline BlueOcean y no el obsoleto pipeline de trabajos de Jenkins. Esto es crítico si desea que su canalización de CI / CD viva dentro de su código de repositorio GitHub / GitLab. Por lo tanto, la tubería en sí es un código versionado.



De hecho, es tan importante que vale la pena repetirlo de nuevo: ¡todo es código! Su aplicación, cómo se implementa, cómo se realiza el seguimiento, cómo se configura, etc., son fragmentos de código con versiones apropiadas almacenadas en GitHub / GitLab / Anywhere. El objetivo de esto es crear un entorno libre de inconsistencias para los principales desarrolladores (ingenieros de software que escriben código funcional).

Por ejemplo, debería poder:

  • escribe tu propio pequeño microservicio;
  • agrego las pruebas que considero necesarias;
  • Añadir Jenkinsfile
  • agregar configuración de monitoreo como código;
  • especifique mis parámetros en el archivo env.yaml;
  • guarde todo esto en un repositorio;
  • hacer que Jenkins detecte automáticamente el repositorio especificado;
  • construye tu microservicio;
  • Pruébalo;
  • Expandir (usando el método Canario o Azul-Verde);
  • ¡arregle el envío de un mensaje a su correo electrónico cuando haya terminado!

Este es el objetivo, cuyo logro es la esencia de la misión central de los ingenieros de DevOps.

Alternativas a Jenkins


Como dije antes, Jenkins ha existido durante siglos, y hoy hay otras, en mi opinión, las mejores, aunque menos alternativas populares. Uno de ellos es AWS CodeDeploy . Tiene limitaciones, pero los desarrolladores han realizado mejoras significativas durante el año pasado, y si trabaja en AWS, le insto a que pruebe CodeDeploy.

La segunda alternativa es el módulo de integración continua GitLab CI. Si su organización está ejecutando GitLab, probablemente debería comenzar a trabajar con él, ya que está bastante bien integrado con el resto de GitLab.

Finalmente, GitHub ha anunciado su propia herramienta para implementar aplicaciones de Actions , que es compatible con su propia automatización.

De hecho, no creo que las herramientas sean tan importantes aquí. Es importante saber que todo, incluidas las canalizaciones de implementación de código, son artefactos versionados, y nada se produce a menos que provenga de dev.

De todos modos, si comienza con Jenkins, intente configurarlo como un contenedor. No es muy difícil y será una excelente oportunidad para aprender cómo implementar un servidor contenedor Jenkins con nodos de trabajo expandibles Jenkins. De hecho, puede comenzar sin ninguna orquestación de contenedores, que es el tema del próximo artículo.

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?

More articles:


All Articles