El hilo sobre DevOps: automatízame ésta

draz1c

DISCLAIMER

Hilo en proceso de creación. No soy un experto del tema ni mucho menos, mas bien todo lo contrario, así que no tomes nada de lo escrito debajo como algo correcto y definitivo hasta que no haya sido repasado por la gente experta en la materia. Se añadirán las correcciones que haga falta a #1 siempre y cuando se verifique que es información correcta y se haga de forma educada (acepto críticas pero no quiero que se me falte al respeto si me he equivocado en cosas porque esto lo hago con la mejor intención del mundo).


DevOps

header

Imagen 1: Ciclo de vida de la metodología DevOps.

Índice

  1. - ¿Qué es DevOps?
  2. - CI/CD
  3. - Automatizacion
    1. - Ansible
    2. - Terraform
  4. - Recursos útiles
    1. - Canales
    2. - Podcasts
    3. - Videos
    4. - Links
    5. - Certificaciones

1 - ¿Qué es DevOps?

DevOps (del ingés development -desarrollo- y operations -operaciones-) es un conjunto de prácticas, herramientas y una filosofía de trabajo que tiene por objetivo tratar de automatizar, integrar y unir a los equipos del proceso de desarrollo de software (dev) con los equipos de infraestructuras (ITOps) a través de una metodología similar a la "metodología ágil" así como acelerar el ciclo de vida del desarollo de software proporcionando una integración continua (CI) y una entrega continua (CD) (el denominado CI/CD).

La Imagen 1 muestra de manera más visual como es ciclo de vida del desarrollo del software usando la metodología DevOps así como algunas de las herramientas más populares de cada una de las fases.

2 - CI/CD

ci/cd pipeline

Imagen 2: Ciclo de vida de un pipeline CI/CD.

La integración continua (CI) consiste en unir ("merge") el trabajo de los desarrolladores en un "branch" único de un repositorio de código varias veces a lo largo del día para evitar que el código que tenga cada desarrollador difiera demasiado del "main branch" y que al hacer los "merges", o unión de código de todos los desarroladores, sea excesivamente complicado de hacer (el llamado merge hell).

Con la creación de "pipelines CI/CD" se consigue automatizar la ejecución de bancos de pruebas de código, la compilación del código, la realización de tests de integración, su despliegue y posterior monitorización (estos dos últimos pasos corresponderían con la fase de entrega continua o CD) cuando se hagan cambios en el main branch del código. De esta manera los desarrolladores pueden pushear el código al repositorio con una mayor frecuencia y evitar los posibles problemas asociados que se mencionan en el párrafo anterior.

3 - Automatizacion

La automatización es una parte fundamental del rol de DevOps. Se puede (y se debería) automatizar los pasos del ciclo de vida que hemos visto en la Imagen 1: tanto la configuración de las máquinas desplegadas a través de software como puede ser Ansible, Cheff o Puppet así como automatizar el despliegue de infraestructuras en la nube con software de "Infraestructura como código" (IaC por sus siglas en inglés "Infrastructure as Code") con, por ejemplo, Terraform.

En un escenario ideal donde una empresa ha implantado por completo la filosofía DevOps, un ciclo de vida del desarrollo software con todas las fases automatizadas tendría un aspecto similar al siguiente:

  1. - Desarrollador pushea código al repositorio.
  2. - Se realizan pruebas de código y se compila.
  3. - El código compilado se "dockeriza" y se sube a un registro de Docker (público o privado).
  4. - Se despliega el contenedor en una infraestructura que previamente ha sido levantada a través de IaC.
  5. - Se activa la monitorización del aplicativo desplegado.

GitOps aprovecha Git como la única fuente de verdad ("Source of Truth") para definir cada parte de un sistema de la nube. Una vez declarado en Git, un agente de GitOps (Flux o ArgoCD) aplica automáticamente todo el código, la configuración y las políticas en los entornos de desarrollo, testing, preproducción y producción. Con GitOps, cada vez que hay alguna divergencia entre Git y lo que se ejecuta en un clúster, se alerta a los desarrolladores. Según el caso, los operators de Kubernetes conocidos como "reconcilers" actualizan o revierten automáticamente el clúster. Con Git en el centro de los pipelines de entrega, los desarrolladores pueden usar herramientas familiares para realizar pull requests para acelerar y simplificar tanto las implementaciones de aplicaciones como las políticas que rigen la entrega de software de un extremo a otro.

3.1 - Ansible

Ansible es solo una de las alternativas que hay para la gestión del software, provisionamiento y despliegue de aplicaciones. Entraría dentro de la categoría de Infraestructura como código (IaC). Para funcionar sobre máquinas Linux sólo es necesario que Python esté instalado en dichas máquinas (está instalado por defecto en el 99% de las máquinas Linux).

Ansible funciona a través de archivos (manifestos) de lenguaje declarativo escritos en YAML.

Ejemplo básico de un playbook de Ansible en el que se asegura que se está ejecutando la última versión de Apache:

playbook.yml

---
  - name: Playbook
    hosts: webservers
    become: yes
    become_user: root
    tasks:
      - name: ensure apache is at the latest version
        yum:
          name: httpd
          state: latest
      - name: ensure apache is running
        service:
          name: httpd
          state: started

Este código lo puedes ejecutar simultáneamente en cuantas máquinas haya definidas en el fichero de inventario asociado. Ejemplo de un fichero de inventario Ansible:

inventory.ini

[servidores]
servidor-1
servidor-2
...
servidor-n

La forma de ejecutar el código sería la siguiente:

$ ansible-playbook playbook.yml -i inventory.ini

3.1.1 - Instalación y uso más avanzado de Ansible

spoiler

De manera introductoria yo recomendaría la serie de videos en Youtube de Jeff Geerling: Ansible 101 y su respectivo repositorio de GitHub para seguir el curso con ejemplos.

3.2 - Terraform

A diferencia de Ansible que se centra en la configuración de servidores una vez están desplegados a través de código (aunque puede ser usado también para desplegar infraestructuras en cloud o máquinas virtuales), Terraform se centra en el despliegue de infraestructuras, principalmente en la nube, en proveedores como Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, etc... Puedes encontrar todos los providers soportados por Terraform en Terraform Registry.

Terraform, desarrollado por Hashicorp y escrito en GO, utiliza su propio lenguaje HashiCorp Configuration Language (HCL).

Ejemplo de un simple despliegue de una instancia EC2 't2.micro' en AWS con Terraform:

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "4.35.0"
    }
  }
}
provider "aws" {
  region     = "eu-west-2"
  access_key = "my-access-key"
  secret_key = "my-secret-key"
}

resource "aws_instance" "example" {
  ami           = "<codigo-ami>"
  instance_type = "t2.micro"
}

Un buen recurso para conocer y profundizar más sobre Terraform es el curso: "HashiCorp Terraform Associate Certification Course" - 13 horas de duración y completamente gratuito en Youtube.

4 Recursos útiles

4.1 - Canales:

4.2 - PodCasts

4.3 - Videos:

4.4 - Links:

4.5 - Certificaciones

TODO

5 - Microservicios

Docker

Hilo en mediavida

k8s

GitOps (y NixOPS / NixOS?)

ArgoCD

Cloud (AWS, GCP, Azure)

Monitorizacion

Prometheus + Grafana

Site Reliability Engineering (SRE)

Keywords

devops, integración continua, entrega continua, CI/CD, automatización, git, github, gitlab, ansible, puppet, cheff, terraform, iac, infraestructura como código, aws, azure, gcp, microservicios, contenedor, contenedores, docker, kubernetes, k8s, monitorización, prometheus, grafana, gitops, argocd


Fuentes:

50
draz1c

Cosas pendientes:

08/01/2023:

  • La sección TODO (obviamente xd)
  • Repasar el texto de CI/CD, creo que estoy mezclando cosas y lo cuento de manera erronea.
  • Repasar el texto en general (al ser de ciencias nunca he escrito mucho y a lo mejor hay cosas que se podrian escribir mejor.)

10/01/2023:

  • Añadir principales certificaciones. - 20/01/2023
  • Añadir #7 a la seccion Ansible - 20/01/2023
  • Añadir Kustomize a la generación de YAML #43
  • Añadir canales y videos y https://roadmap.sh/devops/ (by Diskun) - 20/01/2023
  • Reescribir que es GitOps - 20/01/2023

10/09/2023:

  • Creada subsección de Podcasts y añadidos links a la seccion.

Y ya lo se: utilizar la wikipedia como fuentes es XD

willy_chaos

a favoritos, justo hace unos meses me toco pelearme con puppet y ahora mi idea es instalarme foreman para gestionar con puppet + ansible y obtener el compliance

Apo_powa

A favs! Soy meganoob pero estoy muy interesado en esto, entré a un curro donde estaban un poco en la edad de la piedra y empecé copiando y pegando más que de costumbre.

Por si a alguien le sirve cositas que estoy tocando:

  • Justo acabo de poner a funcionar un pipeline de CI/CD para desplegar el código que tenemos (GitLab), faltará migrar todo, desarrollar tests balblalblalba (va a ser divertacular).

  • En la próxima semana espero poder ser capaz de desplegarme un nodo de Elasticsearch desde Ansible (mi propósito es ir iterando hasta poder hacer un despliegue multinode del stack entero, pero por ahora ando batallando con poder configurar todo de manera dinámica, no hardcodeandome una template).

Si alguien curra con Ansible, que lo diga ajajja

1 2 respuestas
aren-pulid0

#4 tienes roles ya hechos de elasticsearch, utilízalos y te quitas el 90% del curro

1
r2d2rigo

Vengo a decir que estoy hasta el pito de YAML y que ya podrian haber consensuado un sistema menos mierda para montar pipelines.

6 3 respuestas
willy_chaos

#4 yo estoy empezando a usarlo en el curro tanto Ansible como Puppet

#1 añade esto si quieres, que lo tengo yo en mi documentación personal, pero hago cp + paste aqui

#1 aquí te lo dejo lo que me pides en #45 https://pastebin.com/x6k6pAaH

spoiler
3 2 respuestas
Starshow

#6 tienes Azure DevOps con el classic builder, quizás te sientas mas cómodo con el.

Gracias #1 por el hilo, espero una sección con repos buenos y con pipelines interesantes, a ver si entre todos montamos una buena base de conocimiento en el post 🤩

1 1 respuesta
r2d2rigo

#8 es lo que he usado siempre pero desde que añadieron soporte de YAML lo están deprecando poco a poco y miedo me da el día en que lo quiten :|

JuAn4k4

Echo en falta algo más para las pipelines de despliegues como Spinnaker, con análisis, tests, estrategias de deployment, rollbacks etc.

También algo de la cultura devops, que es que cada equipo se gestione sus apps.

En monitoring, SLAs, SLOs, 4 Golden Signals

1 respuesta
Kartalon

#6 Yo sólo venía a este hilo para meter mierda sobre yaml pero veo que te has adelantado :(

1 1 respuesta
PiPePiTo

#6 #11 Coincido, años luchando para huir del XML para cuando quieres meter zarpa y ayudar al devops encontrarte con YAML xDDD

ME CAGO EN DIOS YA.

2
r2d2rigo

Para traer un poco de positividad al hilo, vengo a decir que hace 10 a;os ni me imaginaba el panorama que tenemos hoy en dia. El codigo en su repo en el cloud que puedes acceder desde cualquier sitio en el mundo, con cuatro clicks te montas una pipeline sencillita y a cada push compilas la app para una o varias plataformas y ademas la mandas a publicar a las stores o a la distribucion privada que quieras. The dream.

3
Gigi_men

Como propuesta para indicar en #1, haría un ¨DevOps vs SRE vs Platform Engineer¨. Ahora mismo hay mucha duda respecto a las diferencias entre esos términos.

2 respuestas
B

#14 Realmente esa comparación no tiene sentido porque devops es una filosofía y no un puesto. Pero entiendo que muchos recruiters buscan devops de forma errónea.

1 respuesta
Kaledros

Vengo a suscribirme a este boletín.

Gigi_men

#15 A eso me refiero. Hay mucha confusión respecto a esto buscando DevOps Engineers. Si alguien nuevo en el mundo IT llega a este hilo, que le sirva para ver cual es la diferencia entre esos conceptos.

1
fehnd

A favs! un hilo sobre mi trabajo es bien xD

Zh3RoX

Y una persona que es DevOps Engineer, o como se llame, a qué se dedica? A aplicar esta filosofía y prácticas a un proyecto en concreto? No entiendo muy bien el sentido de que haya una persona que se dedique a ello exclusivamente cuando es, como dice la definición, un conjunto de práctica o una filosofía de trabajo.

1 respuesta
Gigi_men

#19 Ahí es donde viene el problema. Al ser algo abstracto, lo que ha terminado pasando es que cada empresa entiendo DevOps como le da la gana y tienen un perfil DevOps Engineer que se dedica a ser un SysAdmin pero que define la infraestructura como código.

En muchos casos, lo que se hace es que en cada equipo, hay embebido un DevOps Engineer que es el que se encarga de preparar el pipeline y la infraestructura para los equipos de desarrollo, de esta manera los miembros de los equipos de desarrollo no tienen que aprender nuevas tecnologías y pueden centrarse en ofrecer valor a negocio (que es lo que da dinero).

Cuestión... que el concepto de DevOps se ha pervertido con el paso de los años y a cada uno que le preguntes, te dará una respuesta distinta. Especialmente si son cargos de gestion o de RRHH en empresas con muchos servicios Legacy.

A todo esto, YAML FTW!! Si queréis, os podéis quedar con vuestros queridos JSON. xD

7
DelToro

Buenas!
Yo estoy con la certificación de Azure devops (az400), soy sysadmin con 7 certificaciones de Azure,y luego mirare Terraform..algún consejo?

3 respuestas
Gigi_men

#21 La de Terraform es bastante asequible si has trabajado con el. Tendrás que estudiar si no has trabajado con ello, la parte de Terraform Enterprise que hacen bastante énfasis en ello.

Si tienes acceso a los recursos de Udemy, mirate el curso de preparación para la certificación y con eso lo sacas de calle.

1
Hanzou

Trabajo cada día con Ansible y AWX. Si alguien necesita saber por donde empezar o alguna cosa que lo pida ;)

3 2 respuestas
Starshow

#21 go CKA y Terraform, con esas y las de Azure gordas ( Architect, DevOps y Security ) vas patinando

1
Apo_powa

#7 y #23 me apunto vuestras matrículas ajjaja

Btw YAML está muy bien si no os metéis en harina, el otro día me empezó a subir la temperatura de la cabeza cuando empecé a cascarle dentro syntax de Jinja2 (el lenguaje que usa Ansible para hacer templates) y la verdad que se me hizo mega engorroso picarmelo y luego poder debuguear el YAML, me pareció muy feo, potente pero feo ajajaj

3 respuestas
pantocreitor

#25 A mi me pasa eso, cuando tienes un YAML cortito y al pie pues está muy bien, pero cuando por lo que sea empieza a tener mas contenido de la cuenta, ya sean scripts o código de lo sea que se tenga que ejecutar, es cuando estás fucked.

Yo no soy DevOps pero he trabajado bastante con AWS (lo mas related EKS), jenkins y alguna cosilla mas.

hda

Yo literalmente he llorado de frustración con YAML viniendo de novato. Mi docker-compose va por las 713 líneas.

1 respuesta
Gigi_men

#25 Entonces el problema no lo tienes con YAML, lo tienes con Jinja2, que es la herramienta de templating de Python.

#27 debes tener un buen monstruito de compose....

Para simplificar YAML (y digo YAML y no Templates) os recomiendo la utilización de anchors. Os puede dejar llegar a dejar un fichero muy simple.

3 respuestas
willy_chaos

#28 tienes algun ejemplo?

doogie780

#28

https://www.linode.com/docs/guides/yaml-anchors-aliases-overrides-extensions/

Son funciones y alias que te permiten repetir código sin poner todo el bloque una y otra vez.

2 1 respuesta