Infra2 TeoriaPG Final
Infra2 TeoriaPG Final
Infra2 TeoriaPG Final
2
CloudFormation ................................................................................................................................. 17
¿Cómo usarla? ................................................................................................................................ 17
¿Dónde la usamos? ........................................................................................................................ 19
¿Quién la usa? ................................................................................................................................ 20
Resumen de la Semana .................................................................................................................... 20
Ansible................................................................................................................................................ 21
¿Cómo usarla? ................................................................................................................................ 21
¿Dónde la usamos? ....................................................................................................................... 24
¿Quién la usa? ................................................................................................................................ 24
Terraform ...........................................................................................................................................25
¿Cómo usarla? ............................................................................................................................... 26
¿Quién la usa? ................................................................................................................................ 28
Los plugins de Terraform (Clase 10) ............................................................................................ 29
Domain Specific Language (Clase 10) ........................................................................................... 31
Terraform HCL (Clase 10) .............................................................................................................. 31
Ambiente Productivo (Clase 10) .................................................................................................. 34
Resumen de la semana .................................................................................................................... 40
CloudFormation vs Ansible vs Terraform........................................................................................ 40
Resumen de la Semana ..................................................................................................................... 41
Módulo 3: Pipelines .............................................................................................................................. 42
Pipelines ¿qué son y para qué sirven?.............................................................................................. 42
¿Qué tecnologías existen? ................................................................................................................ 44
Jenkins .............................................................................................................................................. 45
Características .............................................................................................................................. 45
Instalación..................................................................................................................................... 45
Configuración ............................................................................................................................... 45
Distributivo ................................................................................................................................... 45
Plugins ........................................................................................................................................... 46
Jenkinsfile ..................................................................................................................................... 46
Conociendo Jenkins a través del Jenkinsfile ............................................................................... 47
El proceso de build ........................................................................................................................... 48
Proceso de compilación usando Jenkins .................................................................................... 48
Continuous integration .................................................................................................................... 50
Características .............................................................................................................................. 50
¿Qué son los triggers?.................................................................................................................... 51
Artefacto ............................................................................................................................................52
3
Navegando entre artefactos ........................................................................................................52
Administración...............................................................................................................................52
Metadata........................................................................................................................................52
Almacenamiento .......................................................................................................................... 53
Accediendo a nuestros artefactos............................................................................................... 53
Todo alrededor de una filosofía .................................................................................................. 53
Conclusión..................................................................................................................................... 53
Pasos para el desarrollo de Software .......................................................................................... 54
El principio de inmutabilidad ........................................................................................................... 54
Resumen de la Semana .................................................................................................................... 55
CD: Despliegue continuo .................................................................................................................. 55
Continuous Delivery vs Continuous Deployment ........................................................................... 56
¡Una diferencia clave! ................................................................................................................... 56
Examinemos ambos procesos ......................................................................................................57
Pipelines: CI/CD ..................................................................................................................................57
Combinamos Deployments.............................................................................................................. 59
¿Cómo hacer un pipeline de CI/CD exitoso? ..................................................................................... 61
Resumen de la semana .................................................................................................................... 62
Módulo 4: Monitoreo ........................................................................................................................... 62
¿Qué significa monitorear?............................................................................................................... 62
¿Qué buscamos monitorear? ........................................................................................................... 64
Beneficios del monitoreo ............................................................................................................. 64
Monitoreo de infraestructura y de aplicaciones............................................................................. 65
Herramientas para monitorear .................................................................................................... 65
La importancia de las métricas ........................................................................................................ 66
¿Qué es medir? .............................................................................................................................. 66
¿Qué son los indicadores? ............................................................................................................ 67
Métricas y degradación ................................................................................................................ 67
Tipos de métricas ......................................................................................................................... 67
Monitorear infraestructura .............................................................................................................. 68
Amazon CloudWatch.................................................................................................................... 68
Autoescalado y Elasticidad ............................................................................................................... 71
Resumen de la semana .....................................................................................................................72
4
Clase 1: Bienvenidos a Infraestructura II
Módulo 1: Inmersión
Ejes de la materia
Infraestructura como código
La infraestructura como código es la gestión de la infraestructura en un modelo descriptivo
utilizando las mismas herramientas de versionado que un equipo utiliza para su código fuente. Así
como el mismo código fuente genera el mismo código binario, un modelo de infraestructura como
código debe generar el mismo entorno cada vez que se aplica. La infraestructura como código, en
conjunto con los pipelines de despliegue continuo, permite automatizar los despliegues de
infraestructura haciéndolos más rápidos y menos propensos a errores, además nos evita depender
de un equipo de infraestructura.
Pipelines de CI/CD
La integración continua (CI) es una práctica de desarrollo que consiste en integrar el código a un
repositorio compartido de manera frecuente, idealmente varias veces al día. Cada integración es
verificada por un proceso automatizado permitiendo a los equipos detectar problemas
rápidamente.
Estas dos prácticas se llevan a cabo mediante pipelines de CI o CD respectivamente, que son
procesos automatizados por los que pasa el código (código fuente o binarios) hasta llegar a su
destino final, que puede ser un entorno de pruebas o entorno de producción.
Monitoreo
El monitoreo se divide en dos grandes ramas:
Back End I
Maven: Esta herramienta de Back End I se puede utilizar manualmente y embebida dentro
de nuestros procesos automatizados de build y release, también conocidos como pipelines.
5
compilación como durante el proceso de liberación para verificar el correcto
funcionamiento de la misma. Los procesos modernos de infraestructura son la amalgama
de todas estas actividades.
REST APIs: Las APIs son contratos entre nuestros sistemas, formas estandarizadas de
intercambiar información, ejecutar acciones y tomar decisiones utilizando mensajes
protocolizados. Cuando interactuamos con un proveedor de nube, ya sea por medio de
herramientas de scripting o por herramientas de infraestructura como código, lo que está
sucediendo por debajo es que estamos consumiendo una o un conjunto de APIs.
Testing I
Api testing: Las pruebas de APIs pueden realizarse de forma automatizada como pasos
dentro de un pipeline de CI/CD, facilitando de esa manera su ejecución reiterada (por
ejemplo, en cada build).
DevOps
¿Qué es y cómo surge DevOps?
Las empresas de software durante muchos años mantuvieron la cultura de trabajo donde los
distintos departamentos involucrados en el desarrollo de un producto estaban aislados y separados
uno de los otros, desarrollo, operaciones, control de calidad, herramientas, infraestructura,
plataforma, seguridad, entrega. Todos incomunicados avanzando a ciegas pasándose el bastón al
siguiente departamento como ocurre en una carrera de relevos hasta llegar a la meta final: la
entrega del producto. Esta división e incomunicación hacía de los errores el común denominador
generando grandes fricciones, mayores tiempos de desarrollo y por ende altos costos para la
empresa. Es por esto que, con el tiempo, ante la necesidad de ser más ágiles, nace DevOps.
En la cultura DevOps, los equipos de desarrollo (Dev) y operaciones (Ops) no trabajan por separado,
sino que se comunican de forma constante. A veces los equipos se fusionan en un único equipo que
6
trabaja en el ciclo de vida completo de la aplicación, desde el desarrollo y las pruebas hasta el
despliegue y la operación. En algunos casos, la calidad y la seguridad también se integran con el
desarrollo y las operaciones.
Estos equipos hacen foco en automatizar procesos que históricamente fueron manuales y lentos.
Para eso utilizan un stack de tecnologías y herramientas que los ayuda a operar y evolucionar
aplicaciones de forma rápida y confiable. Además, colaboran a que una sola persona pueda realizar
tareas que normalmente requerirían de una combinación de varias personas, como desplegar
código o aprovisionar infraestructura.
DevOps significa que el equipo de desarrollo es responsable del código en todas las etapas, desde el
desarrollo hasta la producción minimizando la fricción entre el desarrollo de nuevas
funcionalidades y la operación de software actualmente en producción, reduciendo el tiempo de
entrega de una feature y aumentando la frecuencia de los despliegues creando un entorno propicio
para experimentar de una manera segura, dándole más agilidad a la organización y permitiéndole
ponerse por delante de sus competidores.
7
Herramientas de DevOps
Implementar una cultura DevOps en una organización requiere del uso de herramientas
fundamentales para automatizar procesos, monitorear recursos y lograr la agilidad que se persigue.
GESTIÓN DE CONFIGURACIÓN : Es un proceso que lleva registro de las distintas configuraciones que un
sistema adopta a lo largo de su ciclo de vida.
INTEGRACIÓN CONTINUA (CI). Es una práctica de desarrollo qué consiste en integrar el código a un
repositorio compartido lo más frecuentemente posible idealmente varias veces al día. Cada
iteración es verificada por un proceso automatizado permitiéndole a los equipos detectar
problemas rápidamente.
DESPLIEGUE CONTINUO (CD): Es la habilidad de poner en producción, es decir, poner en manos de los
usuarios cambios de cualquier tipo de manera segura y sostenible. Esto se logra asegurándonos de
que el código siempre se encuentre en un estado desplegable incluso cuando se están haciendo
cambios constantemente.
8
Aunque el uso de esta y otras herramientas es clave para automatizar y monitorear todos los
procesos debemos tener en cuenta que DevOps no consiste en sólo utilizar herramientas, el uso de
estas da el soporte a las prácticas que se implementan a nivel cultural dentro de una organización
y la agilidad viene de utilizar estas herramientas para hacer realidad esas prácticas.
ANALISTAS DE CALIDAD (QA): Son quienes verifican y validan la aplicación. En un entorno DevOps es
importante que también se concentren en automatizar pruebas para hacerlas repetibles y
confiables.
ANALISTA DE REDES : Son quienes implementan la infraestructura sobre la cual se ejecutarán las
aplicaciones y las bases de datos. También se ocupan del mantenimiento y la evolución de esta
infraestructura. Buena parte de las prácticas de DevOps recaen sobre ellos, en especial la
comunicación con quienes desarrollan la aplicación. Dado que muchas veces la infraestructura
existe en la nube, también se los suele llamar analistas clouds o analistas de nube.
ANALISTAS DE CI/CD: Son quienes mantienen los pipelines de integración y despliegue continuos. En
aplicaciones simples es común que esta persona sea la misma que ocupa el rol de analista de
infraestructura, pero en aplicaciones más complejas es necesario diferenciar roles.
ARQUITECTOS DE N UBE: Definen la arquitectura del entorno en la nube: la estructura que tendrán los
servidores, cómo se interconectan y varios aspectos de seguridad relacionados. También definen
quiénes tendrán acceso a los distintos entornos. En organizaciones pequeñas no hay una persona
dedicada de forma exclusiva a esto y la función recae sobre el analista de infraestructura.
INGENIEROS DE CONFIABILIDAD DE SITIO (SRE): Son los encargados de diseñar y monitorear el sistema
para minimizar las suspensiones de servicio y el tiempo de recuperación de los servicios. Trabaja
tanto de forma proactiva como reactiva, respondiendo a incidentes, pero también intentando que
no ocurran o vuelvan a ocurrir.
9
GERENTES DE ENTREGA : En algunos casos no es posible realizar despliegue continuo, por limitaciones
del mercado o por la naturaleza del producto —por ejemplo, cada despliegue significa
inevitablemente una suspensión temporal del servicio o cada cliente requiere una versión distinta
del producto—. En estos casos, el gerente de entregas se ocupa de coordinar la entrega de nuevas
versiones del producto a los clientes, llevar registro de qué cliente tiene qué versión del producto
y orientar los esfuerzos del equipo hacia la satisfacción de los clientes.
La cultura de DevOps está basada en la automatización, esto implica disminuir los procesos
manuales aumentando la velocidad con la que se ejecutan y reduciendo así el esfuerzo necesario
para llevarlos a cabo. Esta automatización es responsabilidad de cada una de las personas que
trabajan en el equipo.
Una de las claves de la cultura de DevOps es la toma y el análisis de métricas. Estas métricas surgen
de monitorear las aplicaciones, la infraestructura y los procesos. Algunas de las métricas más
importantes pueden ser reducir tiempos promedio de recuperación de fallos, reducir tasa de
errores, reducir tiempos promedios de puesta en producción de funcionalidades, incrementar
tiempos promedios entre fallos.
Dentro de una organización la fricción es la fuerza que se opone al progreso de nuestro objetivo y
en el caso de DevOps nuestro objetivo es poner software de calidad en las manos de las personas
usuarias finales. Algunos elementos que introducen fricción son la necesidad de proceso manuales,
la ocurrencia frecuente de errores o, las incompatibilidades entre distintos procesos. La
automatización es una forma reducir la fricción, pero también se reduce la fricción simplificando los
procesos al mínimo y asegurándonos de que todos sean compatibles entre sí. Por ejemplo, que los
entornos de prueba y producción sean idénticos para permitir una transición sin errores de uno al
otro.
Trabajar en un entorno DevOps significa que diferentes perfiles, que típicamente pertenecían a
diferentes áreas, ahora trabajan en conjunto. Esta colaboración se da gracias a una comunicación
fluida y constante entre las personas responsables de todas las actividades. Un equipo de DevOps
tiene la capacidad técnica para ocuparse de todas las etapas de la solución que están construyendo,
incluyendo el desarrollo, la gestión de calidad, la seguridad, el despliegue y la operación de la
solución en un entorno de producción.
10
Aquí no existe la frase “eso no es mi trabajo”, la solución es responsabilidad de la totalidad del
equipo. Al final de cuentas la cultura de DevOps es sostenida por todo el equipo de trabajo por eso
es importante que todos podamos asumir la responsabilidad de hacer del equipo un verdadero
equipo de DevOps.
Resumen de la Semana
Ejes de la materia
INFRAESTRUCTURA COMO CÓDIGO: Gestionar la infraestructura como un modelo escrito en código y
versionado.
CI/CD
MONITOREO
¿Qué es DevOps?
DevOps es la combinación de filosofías, prácticas y herramientas que incrementan la velocidad a la
que una organización entrega aplicaciones y servicios.
Perfiles de DevOps
Desarrollador
Analista de calidad
Analista de infraestructura
Analista de redes
Analista de seguridad
Analista de CI/CD
Arquitecto de nube
Ingeniero de confiabilidad de sitio (SRE)
Gerente de entregas
Expectativas de DevOps
Automatizar
Medir y monitorear
Reducir la fricción
Aumentar la comunicación
Ser dueños de la solución
11
De esta forma vamos a poder automatizar los procesos manuales que se requieren para lograr el
objetivo final que buscamos.
Así como cada vez que ejecutamos el código de nuestra aplicación obtenemos el mismo resultado,
lo mismo ocurre con la infraestructura: vamos a obtener el mismo resultado de infraestructura
desde nuestra IaC. Este concepto es muy importante para implementar la metodología DevOps en
nuestra vida profesional, ya que nos permitirá crear un ambiente mucho más rápido y seguro para
nuestras aplicaciones.
Por lo general el procedimiento de la infraestructura como código implica los siguientes tres pasos:
1. Definir y describir las especificaciones de las infraestructuras para que pueda ejecutar la
aplicación o base de datos.
2. Los archivos que se crean se envían un repositorio de código o de almacenamiento de
archivos.
3. La plataforma de IaC toma todas las acciones necesarias para crear y configurar los recursos
de infraestructuras.
12
6. Lanzar el servidor
La IaC es una práctica esencial de DevOps indispensable para un ciclo de vida de entrega de
software a ritmo competitivo, permite a los equipos crear y versionar rápidamente la
infraestructura de la misma manera en que versionan el código fuente y hacer un seguimiento de
estas versiones para evitar inconsistencias que puedan conducir a graves problemas durante el
despliegue.
Al momento de realizar los análisis para implementar una infraestructura para nuestra aplicación,
lo primero a definir es la arquitectura que necesitamos: qué servidor es el adecuado o qué base de
datos necesitamos. Una vez seleccionado el tipo de servidor, avanzamos en la configuración e
instalación de aquello que nuestro sistema operativo requiere para estar operativo.
Paso a paso:
Mejoras y soluciones
Aunque este proceso se encuentre bien documentado, siempre vamos a encontrar obstáculos: el
tiempo que nos ocupa la tarea, posibles incompatibilidades, o inconsistencias en la documentación.
La metodología de infraestructura como código nos ofrece una solución a todo esto.
Este proceso que se realiza manualmente comienza a agilizarse ante el vertiginoso avance
tecnológico, dando lugar a la automatización de la infraestructura. Como consecuencia, los ciclos
de desarrollo poseen mejores tiempos de respuesta ante la mayor disponibilidad y flexibilidad de
los ambientes de desarrollo de software.
La infraestructura como código irrumpe para aumentar la calidad y la eficiencia de los equipos de
desarrollo.
13
4. Al ejecutar las tareas más rápido, vamos a poder ayudar a otros equipos a que también
trabajen en menos tiempo y de manera más eficiente.
7. TESTEOS: La infraestructura como código permite que los equipos de infraestructura puedan
realizar pruebas de las aplicaciones en cualquier entorno (incluso producción) al principio del
ciclo de desarrollo.
11. MÁS RAPIDEZ SIN DESCUIDAR LA SEGURIDAD: Al momento de mejorar nuestra infraestructura,
nunca hay que dejar de pensar en la seguridad que la compone. Al momento de estandarizar
la ejecución de la infraestructura, también podemos estandarizar los grupos de seguridad
con los permisos mínimos, pero necesarios para que todos los equipos puedan trabajar y
evitar tareas manuales por parte de los equipos de seguridad.
14
Paradigma Imperativo
Utilizamos el paradigma imperativo cuando al escribir nuestro código
nos enfocamos en cómo se va a ejecutar a través de diversas
operaciones y el flujo de trabajo que va a realizar. Vamos a definir
variables constantes y definir decisiones. Las más conocidas son:
IF
ELSE
ELIF (en otros lenguajes se conoce como ELSE IF)
FOR y FOREACH
WHILE y DO WHILE
SWITCH (no existe en todos los lenguajes)
Manejo de errores con excepciones (TRY/CATCH/FINALLY)
Paradigma Declarativo
Al utilizar el paradigma declarativo, vamos a trabajar sobre la lógica de
qué se va a ejecutar, sin indicar los detalles de cómo lo va a hacer. Al
utilizar este método, nuestro código va a estar compuesto por un
conjunto de funciones que van a realizar la tarea que definamos. Es muy
importante tener test automatizados para probar nuestro código. Al
ejecutarlos y ver los resultados vamos a tener la posibilidad de identificar
errores en la lógica de nuestro código. Podemos decir que el enfoque
declarativo define el estado final de nuestra infraestructura.
El principio de Idempotencia
La propiedad de obtener siempre un mismo resultado sin importar las veces que ejecutemos una
operación es lo que se denomina principio de idempotencia. El principio de idempotencia, dentro
del ámbito de infraestructura como código, es la propiedad de poder ejecutar nuestro código las
veces que sea necesario siempre obteniendo el mismo resultado. Para que nuestra infraestructura
siempre sea idempotente utilizaremos herramientas para ese fin como pueden ser, Ansible,
Terraform o CloudFormation.
2. PROCESO: Son las operaciones que realizan las herramientas de IaC en base al archivo origen
Al aplicar el principio de impotencia en estas tres etapas vamos a tener distintos beneficios como,
por ejemplo, la capacidad de que sí necesitamos modificar algo de nuestra infraestructura sólo
debemos modificar el archivo de origen luego, ejecutaremos el proceso de ese archivo de
15
configuración con la herramienta que estemos utilizando y obtendremos el estado final según las
modificaciones que apliquemos.
Es fácilmente documentable ya que no tenemos que revisar nuestra infraestructura para revisar
cómo está compuesta o documentar todo después de hacerlo. Tenemos nuestro archivo de
configuración con toda la información y, si es necesario, sólo hay que agregar documentación
complementaria.
Se pueden aplicar prácticas de desarrollo de software al área de infraestructura algo, que hasta
hace poco era muy lejano, como por ejemplo versionar los archivos de configuración para volver a
una versión anterior sin trabajo extra y es fácilmente compartible con el resto del equipo.
Todo esto nos permite que el proceso sea totalmente automatizable. Conocer el principio
idempotencia y los beneficios en su aplicación es fundamental ya que esta es la base teórica de la
automatización que permite la IaC.
¿Por qué hacemos estas distinciones? ¡Porque podemos elegir para nuestra infraestructura la
herramienta que nos brinda la mayor eficiencia posible!
Terraform
Terraform es un software de código libre desarrollado por HashiCrop. Es una herramienta
declarativa de aprovisionamiento y orquestación de infraestructura que permite automatizar el
aprovisionamiento de todos los aspectos de la infraestructura, tanto para la nube como la
infraestructura on-premise (en los mismos datacenter). Tiene algunas características interesantes,
como comprobar el estado de la infraestructura antes de aplicar los cambios. Es la herramienta más
popular porque es compatible con todos los proveedores de nube sin realizar modificaciones en
nuestros templates.
AWS CloudFormation
AWS CloudFormation es la solución nativa de AWS para aprovisionar recursos en esta nube. En este
caso se pueden definir templates en formato JSON o YAML. Se pueden utilizar para crear, actualizar
y eliminar recursos las veces que sea necesario. Una ventaja de CloudFormation es que, al ser un
servicio propio de Amazon, tiene una integración completa con los demás servicios de AWS, por lo
que es nuestra mejor opción si solo utilizamos este proveedor de nube.
16
Ansible
Ansible es una herramienta de automatización de infraestructuras creada por Red Hat. Ansible
modela nuestra infraestructura describiendo cómo se relacionan sus componentes y el sistema
entre sí, en lugar de gestionar los sistemas de forma independiente.
CloudFormation
CloudFormation es una herramienta nativa de Amazon Web Services (más conocido como AWS).
Pero… ¿por qué es una herramienta tan popular? Porque nos brinda la posibilidad de implementar
prácticas de infraestructura como código (IaC) de forma nativa dentro de AWS.
Cloud Formation (CF) nos brinda la posibilidad implementar prácticas de infraestructura como
código de forma nativa dentro de AWS, esta herramienta se va a encargar de crear y configurar la
infraestructura que definimos previamente en una planilla o template con los requisitos que
necesitamos. Esta herramienta nos ofrece algunas ventajas, como crear repositorios con nuestros
templates para que sean accesibles o que se puedan realizar entregas rápidas de los recursos de
infraestructura.
Por ejemplo, en una plantilla se puede definir la creación de una instancia Amazon EC2 con todas
sus características. Dentro de las particularidades más notables de CF se encuentran:
Permite el uso de rollbacks que nos da automáticamente una vuelta para atrás,
destruyendo lo que se haya producido en el caso de que falle alguno de los pasos de la
creación de recursos de infraestructura.
El uso de Cloud Formation es totalmente gratuito lo cual hace que el precio sea otra cosa
interesante.
CF es una herramienta integral que nos permite administrar nuestra infraestructura en un entorno
controlado y predecible, reduciendo los tiempos de despliegue y, agilizando así, la entrega de
recursos.
¿Cómo usarla?
Para introducirnos en el funcionamiento de la herramienta, vamos a tener en cuenta tres conceptos
importantes:
PILAS: es una unidad que genera CloudFormation para la creación ordenada de los recursos.
17
CAMBIOS: es un resumen de los cambios que se proponen para anticiparnos al resultado
final.
Para el ejemplo, nuestro template va a contener una instancia EC2 para alojar nuestro web server y
la aplicación WordPress, una base de datos en el servicio de Amazon RDS, un balanceador de carga,
una VPC y subnets con dos zonas de disponibilidad distinta, servicios de grupos de seguridad.
Lo primero que vamos a crear es la descripción para que quienes lo reciban sepan a grandes rasgos
qué componentes posee seguimos con los parámetros, estos reciben nombres lógicos como ID que
presentan recursos.
Los parámetros se componen de un tipo lógico y de tres componentes asociados a este tipo de
recurso. Tomemos VPC como ejemplo:
VpcId es el nombre lógico para definir una virtual Private Cloud donde vamos a encontrar tres
componentes asociados:
Type que es el tipo de recurso dentro de AWS, en este caso, una VPC para una instancia EC2.
Continuamos con Mappings, una clase de mapeo de cadenas literales que puede recibir como tipo
de dato un string o un list con el formato clave valor. En el caso de nuestro ejemplo vamos a mapear
la creación de distintas instancias EC2 a un tipo de ami que es la HVM64.
Luego crearemos los distintos recursos que necesitamos como el balanceador de carga para tener
distintas réplicas de nuestra aplicación y de la base de datos. En este ejemplo crearemos el recurso
ELB (ElasticLoadBalancing) haciendo referencia a la subnets de nuestra red privada.
18
En resources vamos a poder crear nuestros grupos de seguridad para resguardar la aplicación y la
base de datos.
Para finalizar los templetes se usan Outputs con el objetivo de declarar cuál va a ser el mensaje final
que va a visualizar el ejecutor del template. En este ejemplo va a visualizar la ruta expuesta a
internet de nuestra aplicación. Como está automatizado genera la ruta a través de los nombres de
los distintos recursos que fue creando.
Datos Curiosos
Con CloudFormation podemos delegar las tareas y controlar los accesos con IAM desde
AWS
¿Dónde la usamos?
CloudFormation se puede utilizar en distintos ámbitos:
19
Podemos hacerlo por línea de comando desde nuestros equipos.
¿Quién la usa?
Las plantillas de CloudFormation posibilitan que los analistas de infraestructura deleguen tareas de
creación de recursos a otras áreas, a través del control del mismo código de las automatizaciones.
Pero ¿cualquier tipo de usuario puede ejecutarlas?
Consideraciones que hay que tener en cuenta al momento de autorizar usuarios que se encuentran
por fuera del área de infraestructura.
Analista de infraestructura Ssr o Sr para escribir templates propios y ejecutarlos desde cualquier
entorno
Desarrollador de cualquier seniority para ejecutar los templates dados desde la consola web
Líder técnico o desarrollador avanzado para ejecutar un template de CF (con los permisos
necesarios de AWS) desde AWS CLI o la consola web.
Resumen de la Semana
Durante esta semana nos introducimos en el concepto de infraestructura como código y cuáles son
las tres herramientas que tenemos que conocer sí o sí, ya que son las más importantes del mercado.
También pusimos manos a la obra con la primera de ellas, CloudFormation.
Para el mercado de trabajo, las certificaciones de AWS van desde la certificación inicial hasta la ruta
de aprendizaje de arquitecto cloud.
Podemos delegar el uso de los templates a través de los roles de permisos IAM.
REUTILIZACIÓN: Podemos elegir un template dado por AWS o crear una versión propia para cubrir
nuestros requisitos.
20
Clase 7: Infraestructura como código – Ansible
Ansible
Ansible es un proyecto comunitario open source diseñado para ayudar a las organizaciones a
automatizar el aprovisionamiento de infraestructura, la gestión de configuración y el despliegue de
aplicaciones.
Ansible fue desarrollada por Michael DeHann, el co-autor de Cobbler (aplicación para aprovisionar
servidores) y co-autor del framework Fedora Unified Network Controller para administración
remota. Ansible se distingue de Chef y Puppet, quienes dominan el mercado en este momento, por
ser más simple aprender y Agentless, esto implica que no necesita instalar un agente en un nodo
para administrarlo, sino que utiliza SSH en Linux o Unix o, WinRM y PowerShell en Windows para
ejecutar comandos dentro de los nodos.
Con Ansible se crean archivos de configuración llamados playbooks, escritos en YAML, que se
utilizan para especificar el estado requerido de la infraestructura. Al ejecutarlos, Ansible se ocupa
de aprovisionar la infraestructura necesaria para alcanzar el estado descrito. Esto quiere decir que
se puede, por ejemplo, crear una máquina virtual en el proveedor de infraestructura -como una
instancia EC2 dentro de AWS- aplicando metodologías de infraestructura como código.
Ansible no nace originalmente como una herramienta infraestructura como código es la propia
comunidad que, ante la necesidad de gestionar la infraestructura en distintos proveedores de Cloud
de forma simple y repetible, desarrolla los módulos necesarios para implementar la guía C.
3. SEGURIDAD: Ansible no instala agentes en nodos, solo requiere que un nodo tenga instalado
OpenSSH y Phyton.
5. MÍNIMO APRENDIZAJE REQUERIDO: Los playbooks utilizan un lenguaje fácil y descriptivo basado
en YAML y templates de Jinja.
Un dato relevante a mencionar es que vamos a poder parametrizar templates de Ansible con Jinja,
una tecnología basada en Python que nos va a permitir crear templates de Script en powershell o
base scripting, posibilitando el uso de condiciones propias de programación como condicionales y
bucles.
Ansible es una herramienta muy potente que permite gestionar configuraciones, desplegar
aplicaciones y manejar infraestructura como código.
¿Cómo usarla?
Ansible es una herramienta que permite gestionar las configuraciones de tu infraestructura. Sus
principales ventajas al momento de usarla son:
21
No necesita instalación de agentes.
Veamos cómo podemos ejecutar Ansible dentro de nuestra computadora e impactar los resultados
en nuestra cuenta de AWS.
Lo primero que debemos hacer es ejecutar el comando Ansible-playbook seguido del archivo .yml
que tiene nuestro código. Este tipo de archivos es legible y, para el caso de Ansible, su extensión es
menor ya que la mayor parte del código son invocaciones a módulos publicados para toda la
comunidad.
Tasks. Es una palabra reservada para indicar que vamos a ejecutar tareas.
Name. Acá es donde vamos a indicar lo que vamos a ejecutar, es muy útil porque nos obliga
a documentar.
Nombre módulo. Indicamos el nombre del módulo, los más comunes para AWS son: ec2,
ec2_ami, ec2_elb, ec2_tag o ecs_ecr.
Para nuestro ejemplo el playbook que queremos ejecutar quedaría de la siguiente manera:
empezamos indicando que el host es localhost, es decir, que lo implementamos en nuestra PC.
Seguimos con las tareas, tasks, luego con el nombre de nuestra primera tarea, el contenido es con
el objetivo de documentar que es lo que estamos haciendo. Despues del name tenemos que indicar
que módulo vamos usar, siempre se ejecuta un módulo. Finalmente vamos a ingresar los
parámetros para el módulo de ec2: la región de AWS donde trabajaremos, el tipo de instancia, el id
de imagen ami -que referencia a un template interno que tiene AWS -, para completarlo tenemos
que averiguar cual nos corresponde de acuerdo al tipo de instancia y de región y, para eso, hay que
chequearlo en AWS console.
Wait es recomensable con el valor yes, para esperar a que termine toda la ejecución y luego nos de
el ok. Wait_timeout es el tiempo en segundos que esperaremos si no responde AWS. Volumes es
un parámetro que utilizaremos si le asignamos un disco a nuestra instancia. Vpc_subnet_id es un
parámetro que debe estar creado previamente. Lo podemos averiguar dentro del servicio vpc en
la opción subnet. Y por último tenemos el parámetro assing_public_ip que servirá para asignarle
una IP pública a una instancia.
22
Nuestra implementación en la consola de AWS quedaría de la siguiente manera:
Donde vamos a poder revisar que estos parámetros coinciden con nuestro playbook de Ansible.
El uso de Ansible como herramienta de IaC es más fácil para aquellas personas familiarizadas con
Linux ya que hay que ejecutar líneas de comando.
Como gran ventaja, el código Ansible es de muy poca extensión, ya que la habilidad del analista es
saber qué módulos tiene que utilizar y conectarse a los recursos necesarios para que impacte lo
que está declarado en el código.
Módulos de Ansible1
Podemos extender el uso de Ansible para automatizar más servicios de AWS.
1
https://docs.ansible.com/ansible/latest/collections/community/aws/index.html#
23
El corazón de Ansible es la ejecución de archivos de playbooks con las instrucciones necesarias para
lograr la infraestructura que queremos, para no tener que escribir la lógica repetidamente para
cada caso de uso, y que nuestro código utilice el paradigma declarativo. Para todo eso tenemos a
nuestra disposición módulos con problemas comunes ya resueltos.
¿Sabías qué?
Ansible es una herramienta mantenida por Red Hat, una empresa multinacional dedicada a
la distribución de software de código abierto. Su producto más conocido es el sistema
operativo Red Hat Enterprise Linux.
Ansible tiene centenares de módulos que resuelven problemas comunes y son muy útiles.
Por ejemplo, la automatización de infraestructura en la nube. La lista de módulos se
encuentra en su documentación.
Existe Ansible Galaxy, una comunidad que permite la distribución de módulos hechos por
los usuarios.
Usar Jinja2 dentro de Ansible nos permite realizar templates de scripts de powershell y bash
scripting usando técnicas de programación existentes en Python
Podemos ejecutar “roles” dentro de nuestros playbooks para crear mini módulos con
código que utilizamos habitualmente.
¿Dónde la usamos?
La flexibilidad de Ansible permite hacerlo en diferentes espacios:
En tu computadora.
En el proyecto de código abierto AWX que podés instalar y usar para administrar tus
playbooks.
Esta última opción te brinda una gran ventaja: podés administrar tus automatizaciones y delegar a
áreas operativas sin conocimientos en Ansible para que puedan ejecutar tus playbooks según sea
necesario. ¡Únicamente te va a preocupar seguir automatizando!
¿Quién la usa?
Ansible es una herramienta muy flexible que nos permite gestionar nuestra infraestructura. Pero,
¿qué conocimientos básicos necesitamos para utilizar esta herramienta?
Utilizas Ansible para todo. Al ser una herramienta muy versátil, si la sabes manejar bien, podes
sacarle el jugo a todas sus posibilidades.
Utilizas YAML. Ansible utiliza YAML como lenguaje para sus playbooks.
Te gusta el software open source. El gran motivo por el que Ansible es lo que es hoy en día es por
su comunidad open source. Si elegís Ansible, probablemente te guste el software de código abierto
y las comunidades que se forman alrededor de estos.
24
Pensas de forma descriptiva. Te gusta describir el estado final de la infraestructura y que tu
herramienta se ocupe de los pasos necesarios para llegar ahí.
Terraform
Terraform es una herramienta de código abierto creada por HashiCorp en 2017 y programada con
el lenguaje Golang más conocido como Go. Para el desarrollo de sus archivos de configuración
utiliza el paradigma de programación declarativo, gracias a su lenguaje nativo llamado HCL
(HashiCorp Configuration Lenguage), con el objetivo de describir el estado final de la
infraestructura que deseamos crear.
Con Terraform vamos a poder elaborar un plan para alcanzar este estado final y ejecutarlo para
suministrar la infraestructura. Debido a la sencilla sintaxis de sus archivos de configuración, es la
herramienta más popular de IaC en múltiples nubes y también de infraestructura local más conocida
como On Premise por lo que, para el agitado ambiente tecnológico que cambia constantemente y
ante la necesidad de migrar de un tipo de infraestructura a otra, para lograr la mejor performance
para los usuarios, Terraform se convierte en la mejor solución para brindar los ambientes de
desarrollo y producción.
La VELOCIDAD que aporta para soluciones rápidas por sus automatizaciones y código
declarativo.
Su CÓDIGO ES ABIERTO , al ser una herramienta Open source nos garantiza una gran
comunidad que la mantiene actualizada como herramienta
Al igual que Ansible, Terraform posee módulos que son pequeños recursos con código reutilizable
para problemas comunes donde la comunicación es entre módulos, es decir, cada módulo está
escrito sobre otro módulo que extiende su uso llamados módulos hijos. Estos módulos son
reutilizables ya que se pueden llamar desde distintos archivos y configuraciones para realizar la
misma acción.
Terraform Se puede instalar en nuestras computadoras como los tres proveedores de nube más
populares: AWS, Azure, GCP. También ofrece Terraform Cloud que es la venta de una plataforma
para ejecutar Terraform.
25
Terraform es la herramienta más popular para implementar IaC por la gran cantidad de ventajas
que nos ofrece siendo la más destacable su independencia de proveedores de infraestructura.
¿Cómo usarla?2
Recorramos juntos un archivo de configuración estándar de Terraform para crear una instancia con
todos los recursos que necesita para funcionar completamente automatizado.
El tipo de desarrollo en Terraform es declarativo porque se utilizan módulos y sólo nos vamos a
enfocar en el estado final que deseamos para nuestra estructura. En el caso de nuestro ejemplo, el
código completo se verá de la siguiente manera:
En el primer bloque indicamos que proveedor de infraestructura vamos a utilizar, en este caso, es
AWS. Dentro de ese provider, señalamos donde están las credenciales de nuestra cuenta y qué
región de AWS vamos a usar.
En el segundo bloque, vamos a ejecutar el módulo vpc. El mismo ya contiene la lógica de cómo crear
una red, sólo le tenemos que pasar lo que es particular de nuestra cuenta. En source indicamos la
2
https://registry.terraform.io/providers/hashicorp/aws/latest/docs
26
dirección del módulo, en name escribimos el nombre que va a tener nuestra red vpc y que
direcciones IP va a utilizar. También elegimos entre dos zonas de disponibilidad, azs, luego
señalamos las IPs privadas y las IPs públicas que vamos utilizar y el último parámetro habilita que
nuestro servidor está expuesto en internet.
Seguimos con el segundo módulo al cual le ponemos el nombre EC2, ya que vamos a crear ese tipo
de instancia nuestra cuenta. Lo primero es indicar el módulo, luego su versión. Después el nombre
de nuestro servidor y la cantidad. Definimos el ami, que es un ID único para el tipo de EC2 que
queremos crear, este depende de la región y el tipo de instancia.
En el tipo de instancia para crear usamos T2.micro porque es de uso gratuito y no genera gasto en
la cuenta y, por último, hacemos referencia al grupo de seguridad creado arriba.
Luego vamos a configurar otro módulo para acceder al servidor. SSH es el protocolo utilizado para
conectarse remotamente a servidores con sistemas operativos basados en Linux. Primero
indicamos que módulo de Terraform vamos a usar, luego la versión del módulo. Señalamos que el
recurso a crear se llama ssh-server, le agregamos la descripción a modo de documentación,
hacemos referencia a que va a usar la VPC creada arriba y, al final, escribimos el rango de IPs que va
a utilizar nuestro servidor. Tiene que coincidir con el cidr nuestra vpc.
Una vez que tenemos todo nuestro código, en nuestro caso en un archivo que se llama mi_ec2.tf,
tenemos que iniciar Terraform con el comando terraform init. Al ejecutar este comando, no va a
descargar todos los módulos que declaramos.
27
Ahora podemos aplicar los cambios en nuestra cuenta, se pueden hacer con Terraform apply
habilitándonos un largo detalle de lo que va a crear y al final nos hace un resumen de la cantidad
total, que en este caso serían 125 recursos. Para finalizar ingresamos yes para confirmar que
queremos realizar esta acción y nos va a mostrar la creación de los recursos en tiempo real.
En nuestra cuenta de aws ya podemos ver que hay una máquina virtual nueva, llamada como
indicamos en el código, y que está en estado de comprobación, inicializando.
Cuando terminamos la creación en Terraform nos va a mostrar un resumen que coincide con el que
mostró al ingresar yes y si echamos un vistazo a nuestra cuenta AWS vamos a ver también que todo
está funcionando correctamente.
¿Sabías que?
Terraform ofrece una plataforma para que podamos ejecutar nuestras automatizaciones.
Se llama Terraform Cloud.
Al igual que en Ansible, podemos crear nuestros propios módulos con las automatizaciones
que usamos habitualmente, pero en distintos escenarios.
¿Quién la usa?
Terraform es una herramienta que se caracteriza por el apoyo de su comunidad. Además, es una
herramienta adaptable, ya que se puede utilizar en cualquier proveedor de infraestructura que
utilicemos.
Amante de los resultados. Terraform se caracteriza por ser una herramienta que se enfoca en el
estado final de la infraestructura sacándole todo el jugo a los módulos.
Te gusta ser parte de una gran comunidad. Terraform es una herramienta con una gran comunidad
y totalmente open source.
28
Sos analista de infraestructura. Terraform no es una herramienta para todo, está enfocado
únicamente en el aprovisionamiento de recursos de infraestructura y hay que tener conocimiento
profundo en la materia.
Disaster Recovery. Terraform es muy útil para los equipos que deben cumplir con este proceso.
Pero, ¿cómo trabaja este componente realmente? ¿Cómo se comunica con nuestro proveedor de
Cloud? ¿Cómo se configura?
Arquitectura
El núcleo de TF está compuesto por varias partes móviles que:
Si pudiéramos hacer una radiografía de este componente y cómo maneja su flujo de datos,
podríamos ver algo similar a lo siguiente:
PLUGINS: Es una aplicación complementaria, generalmente pequeña, que sirve para agregar una
funcionalidad extra o adicional (muy específica) a algo ya existente. Los plugins que se utilizan
están divididos en: Providers y Provisioners.
El uso del término “específico” refiere a que existen varios providers, por ejemplo: un provider
para AWS, otro para GCP, para Azure, Kubernetes, etc.
Nota: de igual manera, Hashicorp, empresa dueña del producto Terraform, recomienda el uso
de provisioners solo en casos extremos.
3
https://registry.terraform.io/browse/providers
29
Para esta tarea, existen herramientas de “Configuration Management”, como por ejemplo
Ansible o Puppet. Si por alguna razón no se pudiese hacer uso de estas herramientas,
Terraform nos ofrece la posibilidad de utilizar este método en su código programable.
En esta pieza o “snippet”, podemos ver al método “remote-exec” usado para ejecutar
comandos remotos
Del lado de la nube, existe una API especialmente diseñada para saber interpretar los comandos
provenientes desde nuestra computadora. Es decir, está a la escucha de nuestras peticiones.
Si el “provider” no existiera, entonces no habría comunicación entre ambas partes. Al ejecutar, por
ejemplo, el comando “Terraform plan”, este binario va a buscar al “Provider” que le hemos definido
en nuestro módulo de Terraform:
Aquí podemos ver que la sentencia “required_provisioners” está seteada a “aws”, es decir, no me
interesa trabajar con Google o con Microsoft, sino, con AWS específicamente.
La API que AWS nos ofrece para contactarse con nuestros plugins utiliza las operaciones básicas
CRUD (create, read, update, delete). Este modelo es tomado por las operaciones HTTP REST.
CONCLUYENDO
30
Domain Specific Language (Clase 10)
HCL es el lenguaje de configuración estructurado que nos permite interactuar con los servicios de
infraestructura cloud. Fue creado por Hashicorp para ser amigable para el ser humano y, a su vez,
ser interpretado velozmente por una computadora.
Resource: Este bloque iniciará el diálogo con nuestro proveedor cloud. Específicamente estamos
diciendo: todo lo que continúa y con lo que voy a trabajar es con un recurso.
aws_vpc: Acá estamos declarando el recurso específico de AWS a utilizar. En este caso, un VPC.
mi_vpc: ¿Cómo lo voy a llamar? ¿De qué forma voy a referenciar si quiero invocar este elemento
desde otro módulo?
cidr_block: Un valor definido por HCL. Depende del recurso que declaramos. En este caso, de
“aws_vpc”.
10.0.0.0/16: Representa un valor asociado al identificador. Por ejemplo: región = “us-east-1”, donde
“us-east-1” es el valor.
Semántica y estructura
La sintaxis y estructura del lenguaje HCL de Terraform consta de unos pocos elementos básicos:
El lenguaje de expresión, usado para expresar valores de atributo, ya sea como literales o
como derivaciones de otros valores.
31
En líneas generales estos sublenguajes se usan juntos dentro de los archivos de configuración para
describir una configuración general, con el lenguaje estructural.
Tipo de bloque
Tomemos el snippet anterior y veamos detenidamente cada uno de sus componentes:
Lo primero que necesitamos indicarle es el tipo de bloque que vamos a usar. Los tipos de bloques
más comunes que suelen utilizarse son: RESOURCE, VARIABLE y DATA, aunque también existen
otros.
Estos bloques “declaran” qué recurso de nuestro proveedor Cloud vamos a usar. Por ejemplo, al
escribir:
Argumentos
Seguidamente encontramos los argumentos que asignan un valor a un nombre y aparecen dentro
de bloques:
Es el “contenido” del “block body”. Son los valores y/o funciones que se leen durante el tiempo de
ejecución del código y es donde asignamos los valores que queremos para nuestros elementos de
infraestructura.
32
Es importante destacar que los argumentos que Terraform acepta no son arbitrarios, sino que está
programado para recibir ciertas palabras específicas.
Existen, también, argumentos que son mandatarios, es decir, que deben existir en nuestro código
y otros que no. Por ejemplo, “cidr_block” es un argumento requerido porque nuestro VPC requiere
que nosotros le digamos en qué red vamos a crearlo.
Variables
HCL usa variables de entrada que sirven como parámetros para un módulo de Terraform.
En nuestro caso, “image_id” y que debe ser “único” entre todas las variables ya definidas.
El nombre de una variable puede ser cualquier identificador válido excepto las siguientes: source,
version, providers, count, for_each, lifecycle, depends_on, locals que son los denominados meta-
argumentos, que no se cubrirán en este curso, pero recomendamos navegarlos.
Ahora bien, ¿qué estamos diciendo cuando introducimos la palabra “type”? Básicamente, que el
contenido va a ser de tipo “string” ya que puede haber casos en los que en lugar de datos de tipo
string, podremos tener: number, bool, list, map, tuple, etc.
Supongamos que no queremos que el valor neto de nuestra subnet aparezca “hardcodeado”. Lo
que podemos hacer es crear una variable con el dato en sí, y luego, desde, este código, referenciar
a esa variable. En nuestro ejemplo inicial:
De esta forma, estamos personalizando aspectos del módulo sin alterar el código fuente del propio
módulo.
33
Otra forma más práctica es definiendo un archivo con el nombre: variables.tf donde declaramos
una o más variables logrando modularizar nuestro código.
Nota: es importante que este archivo de variables esté ubicado en el mismo directorio en el que se
encuentra nuestro módulo primario.
Sintaxis
PALABRAS RESERVADAS
La mayoría de los lenguajes de programación contienen palabras que no se pueden utilizar como
variables de asignación. Dichas palabras se hacen llamar “reservadas” debido a que son utilizadas
por el lenguaje para funciones específicas. En el caso de HCL, Terraform no dispone de palabras
reservadas a nivel global.
COMENTARIOS
El estilo de comentario # de una sola línea es el estilo de comentario predeterminado y debe usarse
en la mayoría de los casos.
No es necesario conocer todos los detalles de la sintaxis HCL para utilizar Terraform. De hecho, solo
con comprender su estructura y qué es lo que se quiere lograr ya estamos en condiciones de crear
módulos más complejos. El resto consiste en acudir a la documentación oficial para buscar que tipo
de recursos preciso, qué argumentos lleva y ¡un poco de imaginación!
Paso 1
Antes de comenzar a levantar infraestructura debemos tener bien en claro los requerimientos,
comprender cuales son los recursos que queremos utilizar. En nuestro caso queremos focalizarnos
en la estructura base que soportará los componentes esenciales de red donde nuestras
aplicaciones serán montadas.
Pensar de entrada en estos elementos también nos lleva a determinar qué variables vamos a
necesitar. Por ejemplo, cómo vamos a requerir un vpc, es normal que necesitemos una subnet, una
región, etc.
Paso 2
Una buena práctica en desarrollo es la de incluir un encabezado o header donde se indique de qué
se trata el código que se está escribiendo. Ubicamos el propósito de nuestro código, quien lo hizo,
fecha y versión. En algunos casos se suele agregar también el repositorio donde se aloja.
34
Paso 3
Creamos nuestro módulo de variables (variables.tf).
Luego vamos a declarar las variables que queremos utilizar, entre los puntos más relevantes
encontramos la red 10.0.0.0/24 qué es la IP desde donde se comenzarán a segmentar las otras redes
internas.
Encontramos también dos subnets: pública y privada. Recordemos que queremos preparar nuestra
red de forma segura, una buena práctica es la de separar redes, instalando servicios que
consideremos críticos, como una base de datos y una red aislada de internet cuyo tráfico puede
salir, pero no entrar si la conexión no es establecida desde el mismo origen.
Paso 4
Ahora vamos a crear el módulo de proveedores cloud (providers.tf), lo que acá estamos diciendo
es: vamos a trabajar con AWS, por lo tanto, vamos a utilizar ese proveedor. Entonces, cuando
35
ejecutemos terraform init, terraform va a leer este módulo y va a saber que tiene que descargarse
desde “hashicorp/aws” el provider AWS.
En este módulo estamos trabajando con dos archivos: el binario de Terraform y el binario del
Provider. Nosotros vamos a decirle que queremos trabajar con la versión del binario de Terraform
mayor o igual a la version 0.12. ¿Por qué? Básicamente porque hay un quiebre en la madurez del
producto a partir de la 0.12, nuevas funciones, corrección de problemas, etc.
Luego debemos declarar nuevamente el bloque Provider y le pasamos un elemento llamado AWS.
Esto es así porque necesitamos declarar la región en la que toda esta infraestructura se levantará.
Sino detallamos la región a la hora de ejecutar Terraform plan, nos solicitaría entrar manualmente
a la misma lo que de alguna manera rompería un poco con nuestra automatización.
Paso 5
Creamos el vpc en AWS archivo main.tf, para esto vamos a invocar al elemento aws_vpc que nos
permitirá definir un vpc nuevo.
Pero ¿cómo llegamos a esta conclusión? ¿cómo sabemos que para crear un nuevo vpc necesitamos
al elemento “aws_vpc y no otro? La respuesta rápida y simple es porque la documentación oficial
lo dice así. De hecho, una práctica común a medida que vamos codeando es la de tener al lado el
sitio de la documentación abierto e ir buscando referencias de lo que queremos hacer.
36
Acto seguido vamos a definir el identificador (cidr_block), el cual es requerido. ¿Por qué es
requerido? Nuevamente podemos decir que es porque la documentación así lo dice, es de esta
manera como AWS definió que se cree un vpc.
Paso 6
Continuando con nuestra aventura tenemos el bloque correspondiente a la creación de un internet
Gateway, en términos de AWS, un Internet Gateway es una puerta de enlace desde nuestro VPC
hacia internet. El recurso se llama aws_internet_gateway al que le asignamos un label o alias por
medio del cual, podremos hacer llamadas desde otros bloques o módulos de Terraform en caso de
que queramos hacer uso de aws_internet_gateway.
Luego del label main vemos un .id ¿Qué significa esto? El ID es un valor alfanumérico único que
identifica el recurso. ¿Por qué ponemos un ID? Resulta que es parte de la extensibilidad que tiene
en particular este argumento, de igual forma, obtenemos su valor llamado al archivo de variables
“variables.tf” y le damos un tag.
Fijémonos un detalle, el patrón de implementación, el resource tag está dentro del mismo bloque
resource aws_internet_gateway, es decir, que Terraform HCL nos permite anidar bloques
dependiendo de la necesidad.
Paso 7
Comenzamos con la creación de las subnets, recordemos que vamos a levantar dos subredes una
pública y otra privada. En terminología AWS una subnet pública no es más que una subnet que
puede conectarse internet y que también puede recibir tráfico entrante. En este caso, vemos que
no sólo debemos setear un identificador llamado cidr_block sino también otros llamado vpc_id.
Esto es así porque tenemos que decirle a AWS en qué vpc se encontrará esta subnet que estamos
creando.
Ahora vamos con la creación de la subnet privada la cual contendrá servicios que generalmente no
queremos que sean accesibles vía internet, por ejemplo, una base de datos. Para la subnet privada
empleamos la misma lógica que con la subnet pública.
37
Paso 8
Las cosas comienzan a ponerse interesantes. Cuando levantamos un vpc por primera vez este viene
con una tabla de ruteo que, por default, rutea todo el tráfico proveniente de todas la subnets
asociadas. Como nosotros queremos que sólo el tráfico de la subnet pública vaya a internet no es
óptimo que utilicemos este default route table. Por lo tanto, vamos a crear una tabla de ruteo
específica para esta subnet.
Hacemos exactamente lo mismo con nuestra subnet privada, la diferencia es que la subnet no
estará asociada a la tabla de ruteo que tiene declarada la salida directa a internet, sino que tiene
asociado un nat_gateway .
Paso 9
Ya hemos asociado la tabla de ruteo con nuestro Internet Gateway. Ahora debemos asociar nuestra
tabla de ruteo con la subnet pública de tal forma que, la subnet, sepa qué ruta seguir para salir a
internet. Entonces, nuevamente declaramos el bloque resource y nos traemos el elemento
“aws_route_table_association” que nos va a realizar la vinculación.
38
Vemos que toma un identificador requerido llamado “route_table_id” que le vamos a dar el valor
del ID de la tabla de ruteo que creamos y qué llamamos “public_RT.id”. También le vamos a dar el
identificador no requerido “subnet_id” para pasarle el ID de la subnet y así, tener los elementos
que vamos a asociar.
Seguimos con asociación de la subnet privada con su propia tabla de ruteo. Como esta subnet no
debe salir a internet, se define con la red 0.0.0.0/0 que significa que no hay direcciones asignadas y
se interpreta como todas las redes, es decir, también internet.
Paso 10
Nos falta una dirección IP estática, para ello generamos una eip y se lo daremos al NatGateway.
Paso 11
Para finalizar, asociamos el NatGateway con la EIP que creamos previamente.
Toda infraestructura requiere de cimientos sólidos para mantenerse estable y segura durante su
ciclo de vida, es por eso, que la etapa de diseño es muy importante. Requiere comprender bien qué
39
es lo que vamos a hacer antes de hacerlo, identificar cuáles son los elementos que necesitaremos,
como conjugarlos, como asegurarlos, etc.
Resumen de la semana
Durante esta semana conocimos dos herramientas nuevas: Ansible y Terraform. Con ambas
creamos los mismos recursos en nuestra cuenta de Amazon Web Services. Si sumamos
CloudFormation, podemos decir que conocemos las tres herramientas más demandadas en el
mercado.
EJECUCIÓN REMOTA: Con CloudFormation no necesitamos conectarnos a AWS, ¡ya estamos dentro!
Con Ansible y Terraform, al ejecutar desde fuera de nuestra cuenta, aprendimos cómo conectarnos
desde nuestras computadoras y sin contraseñas
OPENSOURCE Y COMUNIDAD: Los módulos usados en Ansible y Terraform, en su mayoría son apoyados
por la comunidad de dos herramientas que comparten su código fuente.
De las tres herramientas Ansible es la que posee la infraestructura más simple y fácil de usar,
además es agentless, esto quiere decir que no necesita instalar un agente en un nodo para
administrarlo.
Hay que darle también mérito a Cloud Formation, en cuanto a la facilidad para aprender a usarla ya
que posee una gran documentación en la web oficial con ejemplos muy práctico. Tomando en
cuenta el aprovisionamiento de infraestructura, Cloud Formation y Terraform tienen una ventaja
sobre Ansible, ya que esta última antes de transformarse y abarcar otras funcionalidades, fue
concebida inicialmente como una herramienta de gestión de configuraciones, es decir, estaba
enfocada únicamente en realizar configuraciones masivas en servidores.
Ahora, en cuanto a los servidores y las aplicaciones que nos brindan las herramientas, la ganadora
es Ansible. Esta herramienta creada con la idea de aplicar configuraciones masivas nos va a permitir
realizar ambas tareas: crear tanto el servidor como servicios y aplicaciones que expongan a ese
servidor.
Con Terraform, por ejemplo, solo vamos a poder realizar la creación del servidor. Si evaluamos su
modularidad, es decir la facilidad para agrupar código, Terraform es la herramienta que aventaja a
40
las otras dos ya que puede dividir código, no sólo en distintos archivos, sino también en distintos
bloques que utilizan un recurso cloud.
De las tres herramientas, las más populares y las que más soporte de su comunidad tienen son
Terraform y Ansible, al ser opensource son fácilmente adaptables si nos vemos en la necesidad de
migrar de proveedor de infraestructura Cloud. Además, garantizan una constante actualización y
mantenimiento por parte de sus comunidades adecuando sus usos según las necesidades del
mercado.
Dos de ellas son productos que poseen la mayor solidez y madurez: Cloud Formatios y Ansible por
una sencilla razón, ambas se crearon antes que Terraform, lo que implica que pasaron por una
mayor cantidad de situaciones, versiones, transformaciones y actualizaciones antes que Terraform.
CloudFormation, Terraform y Ansible son las herramientas más potentes, versátiles y populares
usadas en el mercado. Cada una de ellas presenta sus ventajas y desventajas. Lo importante es
conocerlas, aprender a usarlas y elegir cual es la más adecuada acorde a las necesidades del
proyecto.
Resumen de la Semana
¿QUÉ APRENDIMOS ?: Nos adentramos más en el manejo de IAC utilizando Terraform. Aprendimos
sobre su funcionamiento interno, la manera en que se comunica con la nube, vimos cómo se
estructura su lenguaje de programación y trabajamos levantando recursos de Infraestructura en
AWS.
HCL: Descubrimos que el esqueleto del lenguaje es sumamente sencillo, ya que está compuesto
únicamente por unos pocos elementos para su estructuración.
API: Vimos que Terraform utiliza proveedores, que son plugins que se comunican con la nube.
Esto, por su lado, nos ofrecen unas APIs para que podamos hablarle.
41
Clase 13: Introducción al mundo de los Pipelines
Módulo 3: Pipelines
Pipelines ¿qué son y para qué sirven?
Imaginemos una fábrica que produce un bien físico. Necesita materia prima, ciertas máquinas,
personal que las controle y procesos que definen, de forma lógica, la secuencia de pasos que se
deben ejecutar para lograr el producto que finalmente saldrá de la fábrica y llegará a algún mercado
para su consumo. En la infraestructura como código estos procesos lógicos que permiten la
elaboración de un producto son los que se conocen como pipelines.
Un pipeline es uno o más procesos automatizados que sirven para construir o implementar cierto
código de software de forma rápida, escalable, flexible y segura minimizando errores humanos que
derivan de la tarea manual. Un ejemplo sería el siguiente: tenemos una plataforma Cloud que
hospeda un sitio web y queremos implementar cierta feature, una nueva opción. Para ello
necesitamos los siguientes elementos: una nueva pieza de software, los pasos que el pipeline
realizará, accesos apropiados al ambiente de testing y el destino donde esta feature será
implementada.
Vía GIT pusheamos el código ya revisado por alguien más a un repositorio remoto, un lugar con una
carpeta en otro servidor. Nuestro producto de pipeline recibe el código y este es interpretado
según una serie de reglas preestablecidas.
La TERCERA validar que todos los módulos, referencias o ramificaciones estén presentes.
Nuestro código pasará por cada una de estas etapas y puede, o no, ir arrojando un resultado que
luego será consumido por la próxima etapa del pipeline. Finalmente, el código puede ser
compilado, impactado en el sitio web que será actualizado automáticamente.
42
Es importante destacar que según la madurez del proceso y del equipo, la salida de nuestro pipeline
puede no impactar ni siquiera en nuestro ambiente de testing, sino que se frena el proceso un paso
antes y se requiere una acción manual para realizar el pasaje al sitio web.
Los pipelines dentro de la infraestructura moderna nos brindan una serie de ventajas como:
En resumen, pipelines es una práctica que nos sirve para agilizar los procesos de desarrollo e
implementación de software que se vale de automatizar pasos repetitivos según un procedimiento
preestablecido. Esta arquitectura es bastante común en el desarrollo de software porque tiene la
propiedad de agilizar los procesos de build, deploy y release.
Para hacernos una idea más concreta, lo podemos pensar como una serie de comandos
encadenados donde cada comando está en un nivel determinado. Cuando el comando finaliza su
ejecución, el resultante pasa al siguiente nivel donde otro lo espera para ejecutar una función
predeterminada.
Por ejemplo:
1. Una etapa puede ser el chequeo de que aquello que ingresó en el proceso cumpla con
ciertos requisitos iniciales de seguridad. Si estos requisitos no satisfacen ciertas reglas
predefinidas de antemano, entonces no puede continuar adelante.
43
2. En una etapa posterior se puede, por ejemplo, compilar el código.
3. En la siguiente puede ser almacenado en algún lugar específico. Así, sucesivamente, hasta
llegar al final de la línea.
Un pipeline no es un proceso monolítico, sino que puede consistir en una o varias etapas que están
encadenadas o secuenciadas y que van transformando a nuestro elemento inicial de acuerdo con
ciertas reglas hasta llegar al producto final.
Este tipo de requerimientos son contemplados por productos muy específicos creados para tal
función.
•Es un servicio de repositorio y •Al igual que GitHub es un una •Repositorio que permite colaborar en
control de versiones para herramienta de repositorios que permite proyectos de software. Es muy similar a
colaboración en proyectos de a los usuarios poder colaborar en un los anteriores pero sin opción free.
proyecto de software •Al ser un producto de Atlassian, se
código de software
•Se ha hecho tan popular que existen integra muy bien a JIRA y todos los
•Tiene una característica llamada imagenes de Docker certificadas de tal productos de la misma línea. No necesita
github issues que funciona como forma que se puede descargar y utilizar de procesos complejos de integración
herramienta de ticketing localmente •Dispone de boards para hacer
•Dispone de boards para hacer •Posee una característica llamada CI que seguimientos sobre "issues" creados
seguimiento sobre "issues" creados permite crear y hacer uso de pipelines
para actualizar el código de nuestro
proyecto
Todos estos productos disponen de flujos de trabajo altamente configurables según las
necesidades del usuario. Pero, ¿qué son los flujos de trabajo? ¿De qué se tratan? Los flujos de trabajo
dan cuenta de las características innatas o facilidades que estos sistemas nos ofrecen:
Almacenamiento de código
Versionado
4
https://github.com/about - https://about.gitlab.com/ - https://bitbucket.org/
44
CI/CD
Control de cambios
Colaboración y revisión
Jenkins
Jenkins es un servidor diseñado para la integración continua (CI). Es gratuito y de código abierto
(open source). ¡Y se ha convertido en el software más utilizado para esta tarea!
¿Qué podemos hacer en Jenkins? Nos permite organizar una cadena de acciones que ayudan a
lograr el proceso de integración continua (¡y mucho más!) de manera automatizada.
Características
AUTOMATIZACIÓN: Es el software de automatización más usado para la integración continua.
COMUNIDAD: La comunidad ha desarrollado más de 15000 plugins para agilizar las tareas de
los equipos de desarrollo.
TAREAS: Jenkins puede orquestar cualquier tipo de proceso y ejecutar tareas manuales,
periódicas o automáticas.
Instalación
La instalación varía según el sistema operativo. Cualquiera es válida tanto para servidores como
para nuestras computadoras personales. Las más comunes son:
Correr Jenkins como contenedor de Docker o bien usar la imagen oficial para ejecutarla en
Kubernetes.
Se puede utilizar en distribuciones basadas en Red Hat, como RHEL, CentOS o Fedora a
través de RPM.
Configuración
En la sección de configuración podemos personalizar varias opciones:
SMTP Y OTROS CANALES: Podemos configurar a Jenkins para que se comunique con nosotros por mail,
cargando la información de nuestro SMTP o WebHooks para usar canales como Slack.
VARIABLES DE ENTORNO: En nuestra instancia de Jenkins podemos guardar información sensible (por
ejemplo, los datos de conexión a nuestros servidores como par de llaves para ssh).
SEGURIDAD PRIMERO: Podemos configurar los roles y permisos de nuestro Jenkins para limitar el
acceso de usuarios. Es importante que cada usuario tenga los permisos mínimos para realizar sus
tareas.
Distributivo
Jenkins puede distribuir el trabajo en varias máquinas, lo que ayuda a realizar las compilaciones,
pruebas e implementaciones en varias plataformas con mayor rapidez.
45
Jenkins Master
Plugins
Con cientos de complementos en el Centro de Actualización, Jenkins se integra con prácticamente
todas las herramientas en la cadena de la integración y entrega continua. Algunos ejemplos son:
Docker
Pipelines
Slack Notifications
Azure
Jenkinsfile
Al crear un archivo llamado Jenkinsfile podemos definir nuestro pipeline a través de código escrito
en Groovy (un derivado de Java).
Que nuestro pipeline tenga la misma lógica que una aplicación a través de estructuras de
control.
46
Conociendo Jenkins a través del Jenkinsfile
Un Jenkinsfile es un archivo que contiene las reglas o pasos a ser ejecutados en el pipeline. Este
puede ser declarativo o con script, el archivo reside en el repositorio junto al resto del código.
Jenkinsfile declarativo
Este archivo está compuesto por varios bloques. El pipeline es el bloque principal donde residen el
resto de los bloques. El bloque stages engloba un subconjunto de tareas que se realizan a través
de todo el ciclo del pipeline: construir, probar, desplegar, etcétera. Es utilizado por varios plugins
para visualizar o mostrar el estado y progreso del proceso. Cada una de las tareas que componen
una etapa se denominan steps, básicamente cada paso le dice a Jenkins que hacer en cada uno de
los puntos concretos del ciclo a realizar.
Acá podemos ver todos los bloques mencionados. Dentro del bloque pipeline se encuentran todos
los sub bloques y además una línea “agent any” que hace referencia a agente en que se quiere
ejecutar ese pipeline. Luego tenemos el bloque stage que contiene las distintas etapas del pipeline,
en este caso hay tres etapas bien definidas: build, test y deployed. Dentro de cada uno de estos
bloques están las acciones a llevar a cabo.
En este ejemplo solo colocamos un texto en la salida, pero en el bloque step podemos ejecutar
comandos usando sh comando o incluso hacer uso de distintos plugins. Esto se implementa en los
pipelines.
47
Veamos una vez más el logo de Jenkins, que es un mayordomo, y justamente
podemos pensar a Jenkins de ese modo. Como alguien qué hace lo que se le
solicita. En este caso lleva a cabo la ejecución del pipeline, o sea, construye nuestro
software, lo testea y lo despliega.
Para poder hacer todo esto Jenkins necesita saber qué es exactamente lo que
queremos que haga, es ahí donde entran juego el Jenkins File. Este archivo es una
guía que Jenkins tiene que seguir para que todo salga como queremos. Por
ejemplo, en esta guía podríamos solicitar que construya el software para obtener un ejecutable
para Windows y para Linux. Luego que se ejecuten los test para verificar que el software hace todo
lo necesario para su correcto funcionamiento y, además, que no tenga errores. A continuación, si
los testeos son exitosos queremos que suba los ejecutables a un repositorio para su
almacenamiento y finalmente, deseamos que ese ejecutable sea descargado en el servidor
correspondiente y se ejecute, teniendo así, una nueva versión del Software funcionando. ¡Y todo
esto de manera automática!
Si bien hemos usado un Jenkinsfile declarativo, debemos tener en cuenta que no es la única forma
ya que también Jenkinsfile scripted. Estos ofrecen un mayor control y mayor poder a la hora de
indicar los pasos de un pipeline. Sin embargo, esto tiene la desventaja de que está en un lenguaje
de programación poco utilizado y además suele ser más complejo, con una curva aprendizaje mayor
a la de los Jenkinsfile declarativos.
Cabe destacar también que estos archivos están siempre con el código fuente del software lo que
ofrece todas las ventajas del uso del controlador de versiones como la colaboración entre el equipo,
transparencia, versionado, etcétera.
Según los principios de DevOps tenemos que eliminar la dependencia de las personas que
desarrollan hacia las personas encargadas de operaciones o Sysadmins. Esto permite que quienes
desarrollan pueden desplegar sus aplicaciones de forma automática y sin intervenciones de un
Sysadmins lo que agiliza el proceso de desarrollo de software.
El proceso de build
El pipeline es un componente fundamental en el desarrollo de software automatizado. Si bien el
término se ha utilizado para describir muchos aspectos diferentes de la informática, en la industria
de DevOps usamos pipelines para ilustrar las amplias aplicaciones de comportamientos y procesos
involucrados en integración continua.
Pensemos entonces en los pipelines y sus procesos. Podemos reconocer distintas etapas que
conforman un pipeline. Vamos a dedicarnos a una de ellas: el proceso de build o construcción de
una aplicación. Es decir, la transformación del código fuente en una aplicación funcional para ser
ejecutada por usuarios.
Comencemos el recorrido por este proceso. Veremos cómo se organiza, la manera en que se
compone, y cómo se integra con Jenkins como herramienta de integración continua.
48
Cuando hablamos de build nos referimos al proceso de construcción de una aplicación, es decir, a
la transformación del código fuente a una aplicación funcional para ser ejecutada por usuarios. Este
proceso no implica para algunos lenguajes de programación como python o JavaScript que
conforman el grupo de lenguajes interpreatados en estos, el código fuente es interpretado tal cual
como está al momento de la ejecución del programa.
Otro grupo de lenguajes son los combinables que, si tienen como condición necesaria tener una
etapa de compilación de la aplicación para poder ser utilizadas, algunos ejemplos son C, C++, C#,
Java.
Cuando escribimos nuestro código Java lo hacemos en archivos con extensión .Java el cual lo
entendemos únicamente cuando son abiertos con programas llamados IDE que no son más que
entorno de desarrollo y no son aptos para el uso de usuarios finales. Para que una aplicación Java
pueda ser utilizada, este archivo .java debe transformarse en un archivo ejecutable que tiene
extensión .class, en este proceso el archivo no pierde su nombre solo se modifica la extensión. Pero
entonces ¿POR QUÉ SE COMPILAN LOS PROGRAMAS? La compilación es necesaria para que la máquina
comprenda nuestro código. Para esto el programa que estamos desarrollando se transforma a
Bytecode, un lenguaje de máquina que el procesador de la computadora o servidor puede
comprender y ejecutar.
El código fuente se duplica al ser compilado en un archivo con el mismo nombre, pero con la
extensión .class, esta extensión de archivo compilado puede variar según el lenguaje o la finalidad
de la aplicación. Comparando nuestros archivos se ven así:
49
Con Jenkins tenemos la posibilidad de hacer todo el ciclo DevOps con sus 8 etapas. Esta
herramienta, aunque no es la única que permite hacer esto, sí es una de las más populares. Para
centrarnos en la etapa de compilación de una aplicación Java hacemos lo siguiente:
1. Creamos una tarea de tipo estilo libre, la tenemos que nombrar de la forma más descriptiva
posible.
2. Dentro del grupo de un proyecto de estilo libre vamos a escribir una breve descripción
3. Elegimos el tipo de ejecución qué necesitamos para nuestro proyecto
4. Hacemos clic en guardar.
Ya tenemos nuestro proyecto configurado, ahora podemos ejecutarlo cada vez que lo necesitamos
con la opción construir ahora”. Esto va a dar como resultado una ejecución donde el ID se crea
automáticamente. Al observar la salida podemos ver que está marcada como exitosa y vemos lo
que escribimos en nuestro código, además del script que ejecutamos para automatizar esta tarea.
Continuous integration
Pensemos en una aplicación cuyo código está almacenado en un repositorio remoto. Los
desarrolladores suben cambios al código todos los días, varias veces al día. Por cada envío al repo
se ejecutan un conjunto de pasos automáticos que terminan construyendo una aplicación.
La integración continua (CI) es una práctica de desarrollo que requiere que los desarrolladores
integren código en un repositorio compartido varias veces al día. Al integrar contenido con cierta
frecuencia, detectamos errores rápidamente y los localizamos de manera sencilla.
Características
ENTREGAS MÁS RÁPIDAS : La integración continua nos ayuda a entregar actualizaciones a nuestros
clientes con mayor rapidez y frecuencia al realizar como práctica continuos posteos de código
50
MAYOR VISIBILIDAD: El simple hecho de liberar código más rápido y de forma continua, ya sea con
actualizaciones o correcciones, permite a nuestros clientes ver que el proyecto se está moviendo
(y no tener que esperar a su finalización para acceder a los resultados).
FACILIDAD DE DEBUGGING: Con testeos frecuentes podemos encontrar y solucionar errores mucho
antes que se conviertan en problemas mayores.
Pensemos en este ejemplo: tenemos cientos de fichas de dominó dispuestas una tras otra en serie.
Si le damos un pequeño golpecito a la primera ficha que se encuentra en el extremo esto generará
una reacción en cadena haciendo que todas, y cada una de las piezas, comiencen a caer una tras
otra. La acción de empujar la primera pieza es un trigger.
Un trigger se va a usar para iniciar un pipeline de forma automática y va a decidir qué código
ejecutar cuando se produce un evento específico. En general, cuando hablamos de procesos por
eventos hay un bucle principal que escucha los nuevos eventos entrantes que son disparados por
el trigger. Si bien esta palabra no es más que un concepto hay que destacar que su importancia
subyace en lo que representa: una forma de concatenar procesos.
Según como un pipeline esté configurado pueden existir los siguientes tipos de triggers:
BASADOS EN CI: Estos triggers hacen que se ejecute un pipeline cada vez que se envía una
actualización a un Branch específico o cuando se envían etiquetas específicas.
EXTERNOS: Refiere la integración con distintos productos. Generalmente mediante el uso de APIs.}
51
Los triggers difieren en la forma de uso, implementación y configuración según cada producto de
CI. Sin embargo, su fundamento es el mismo en todos.
Artefacto
Varias veces hemos tenido que compilar código fuente para obtener un producto utilizable. Esos
archivos resultantes del proceso de compilación llevan un nombre puntual: ¡Artefactos!
El artefacto es un objeto o serie de objetos que se produce a partir de estas compilaciones. Estos
resultantes pueden, a su vez, utilizarse para una segunda y/o última compilación. Tenemos como
ejemplo de ello archivos binarios: dll, jar, war, ear, msi, archivos exe, etc.
El tipo de artefacto o artifact va a depender del producto con el que se programe la aplicación.
También pueden existir tipos de artefactos no relacionados con el producto específico, pero
necesarios para el funcionamiento. Por ejemplo, archivos, YAML, XML, TXT, MD, lib, so, bin, etc.
¡Un momento! Para complejizar un poco más el panorama, un artefacto también puede ser un
script, un diagrama, un modelo de datos, etc.
Pero entonces, ¿un artifact es cualquier tipo de archivo? En términos estrictos, es todo aquello que
resulta de un proceso de build.
Administración
Un producto de repositorios de artefactos nos permite básicamente efectuar las siguientes
operaciones: mover, copiar, eliminar ... artefactos para mantener la consistencia en cada repo.
Cuando un artefacto se mueve, copia o elimina, el producto debe actualizar automáticamente los
llamados “descriptores de metadatos”.
Metadata
¡Los metadatos son datos acerca de los datos! Cada artefacto contendrá metadatos que son
esenciales para la reutilización de código.
Por ejemplo, al chequear los datos asociados a cada artefacto podemos ver si fueron alterados.
Esto será de utilidad para validar su descripción, por ejemplo, la versión de un producto. Podremos
52
saber -acerca de ese cambio- quien lo hizo, cuándo, a qué hora exactamente, qué dependencias
tiene, etc.
Sin embargo, la combinación de muchos tipos de metadatos puede llegar a complejizar el proceso
de colaboración. ¡Una buena estrategia inicial es vital para evitar caer en este tipo de situaciones!
Almacenamiento
¿Dónde se almacena todo este código y sus respectivos artefactos?
En este punto está claro que el código suele almacenarse en sistemas de control de versiones como
GitHub, GitLab o BitBucket.
Pero este no es el caso para los artefactos que pueden -por ejemplo- ser archivos binarios. Y quizás
no tiene mucho sentido utilizar un repositorio de proyectos para almacenar archivos binarios que
son ilegibles para el ser humano y pueden ser bastante grandes en tamaño.
Es aquí donde los repositorios de binarios son una parte tan vital del proceso de integración
continua.
El repositorio binario puede permitir alojar todo esto en un solo lugar haciendo que su
administración sea más simple. Ejemplo de productos típicos que podemos encontrar en el
mercado hoy día son: Artifactory, Nexus, Harbor, etc.
También vamos a encontrar aquellos que son basados en Cloud: Azure Artifact, Artifact Registry,
etc.
Esto se logra mediante la exposición de una API RESTful, ya que siendo objetos que deban utilizarse
de inmediato para proporcionar datos de salida, el tiempo de acceso y respuesta debe ser
extremadamente rápido y con bajo consumo de memoria.
Una práctica común en integración continua es la de construir el binario una sola vez, subirlo a un
repositorio de binarios y luego llamarlo desde allí para implementarlo en los diferentes entornos.
De esa manera nos aseguramos de que el código base que ya funciona en el ambiente de desarrollo
es la misma base que se introdujo en producción.
Conclusión
Los artefactos son subproductos de un proceso de desarrollo de software. Son los componentes
con los que un software está hecho.
53
Pasos para el desarrollo de Software
Codificación
Pasamos lo que se definió y diseñó a código fuente, en el lenguaje de programación determinado:
Testeo
Almacenaje de artefactos
El principio de inmutabilidad
Inmutabilidad: “sin mutaciones”, “sin cambios”. En el sentido de DevOps, significa que una vez que
creamos un artefacto —ya sea una imagen de contenedor o un paquete de código compilado— no
debería ser necesario modificarlo. Y si se requieren cambios, se creará una nueva versión del objeto.
¿POR QUÉ NOS RESULTA ÚTIL QUE UN OBJETO O ARTEFACTO SEA INMUTABLE? Porque cuando lo copiamos
—por ejemplo, desde un entorno de desarrollo a la producción— ya sabemos cómo se va a
comportar. No solo el artefacto tiene que ser inmutable para que funcione bien en todos los
entornos, o ambientes, sino también la infraestructura.
54
Clase 15: Cierre de la Semana 5
Resumen de la Semana
INTEGRACIÓN CONTINUA: Es una práctica común en el desarrollo de software. Los desarrolladores
fusionan regularmente cambios de código en un repositorio central para ejecutar pruebas y
compilaciones automatizadas. Facilita los ciclos de retroalimentación entre equipos de operaciones
y desarrollo para que se puedan implementar iteraciones de actualizaciones más rápidamente en
las aplicaciones en producción.
PIPELINE: Conjunto de prácticas que implementan los equipos de desarrollo (Dev) y operaciones
(Ops) para crear, probar e implementar software de forma más rápida y sencilla. El flujo de trabajo
contiene fases que impulsan el desarrollo continuo, integración, pruebas y posterior
retroalimentación para comenzar de nuevo.
AUTOMATIZACIÓN: Utilización de tecnología que reduce el uso de asistencia humana sobre los
procesos haciéndolos más confiables, rápidos, seguros y escalables.
TESTING: Proceso organizativo dentro del desarrollo de software en el que se verifica la corrección,
calidad y rendimiento del software crítico para el negocio.
BUILD: Proceso que convierte archivos con código en un producto de software en su forma final o
consumible.
TRIGGERS: Es ese “algo” que activa la ejecución de otro proceso. Un desencadenante para lograr
que algo se ponga en movimiento.
ARTEFACTOS: Es uno de los muchos tipos de subproductos tangibles que se producen durante el
desarrollo de software.
CD hace referencia al segmento del pipeline final que se encarga de llevar un producto ya construido
a un ambiente productivo, este proceso es continuo porque al estar en un pipeline automatizado
nos permite realizar esta tarea de forma continua siempre que sea necesario. El proceso entero se
compone de las siguientes etapas:
ETAPA DE RELEASE : En ella se lleva a cabo la creación, la calificación del paquete y la subida y
guardado en una bodega de paquetes, lo que llamamos repositorio de artefactos, donde quedará
disponible para su despliegue en el entorno que se requiera.
En este paquete además de nuestra aplicación y su metadata, cómo puede ser una versión
específica, también se suelen incluir archivos de configuración, programa, instalación y
documentación.
55
ETAPA DE DEPLOYMENT: Acá se mueve el producto, se realiza el despliegue, su instalación y se pone
en funcionamiento y queda listo para que pueda ser usado por los usuarios.
ETAPA DE OPERACIÓN : En esta se opera, se utiliza el producto. Aquí se debe preparar el entorno o
lugar de despliegue, es decir, configurar servidores entre otras cosas.
Las etapas, como en todo el pipeline, van una detrás de la otra de manera que si alguna falla o no
cumple con su cometido se aborta al proceso hasta que se corrija aquello que ocasionó el problema.
Continuous Delivery.
Continuous Deployment.
La entrega continua se focaliza en la automatización de los pasos para que nuestro software esté
disponible para ser aplicado en los ambientes productivos en cualquier momento, ¡pero no hace la
implementación automática en producción!
El despliegue va un paso más allá. En esta práctica, todo es automático en los ambientes, ¡también
en producción! Buscamos que no exista intervención humana en ninguno de los procesos de
trabajo.
Para lograrlo, el pipeline de producción tiene una serie de pasos que deben ejecutarse en orden y
forma satisfactoria ¡y de manera automática! Si algunos de esos pasos no finalizan de forma
esperada, el proceso de despliegue no se llevará a cabo.
56
Examinemos ambos procesos
ANTES Y DESPUES: Dependiendo de las practicas adoptadas por la organización, el despliegue puede
percibirse como una etapa posterior a la entrega porque estamos impactando nuestro ambiente
productivo de forma directa luego de hacer el delivery de nuestro producto.
ATENCION: Si bien ambos términos “continuos deployment” y “continuos delivery” manejan todo
su ciclo de procesos de forma similar (Test y Release), la etapa final es distinta. En continuos
deployment el paso al ambiente productivo es automático
MADUREZ Y CONFIANZA : Para que estos procesos corran de manera satisfactoria en nuestra
organización necesitamos de un alto grado de madurez y confianza técnica de nuestro equipo de
trabajo.
AUTOMATIZACION : Es el punto vital de estas prácticas porque sin ella no existirían desencadenantes
o “triggers” que impacten sobre los procesos siguientes. La automatización también nos facilita
los procesos lógicos de toma de decisiones o diseñar bucles para tareas repetitivas.
BENEFICIOS:
Pipelines: CI/CD
Imaginemos una fábrica que produce un bien físico. Necesita materia prima, ciertas máquinas,
personal que las controle y procesos que definen, de forma lógica, la secuencia de pasos que se
deben ejecutar para lograr el producto que finalmente saldrá de la fábrica y llegará a algún mercado
para su consumo, una vez terminada la elaboración del producto comienza su distribución. Pero
antes debe pasar por una serie de etapas que comprueben su calidad y se aseguren de la correcta
entrega a los usuarios que van utilizar dicho producto. Todo este proceso automatizado de
principio a fin, dentro de la elaboración de un producto, es la unificación de dos conjuntos de
pipelines que garantizan su calidad y tiempo de entrega desde la creación del código hasta su
operación: CI y CD.
57
Iniciemos con CI (integración continua) que no es más que la práctica de fusionar o mergear copias
de trabajos de los proyectos de cada desarrollador en un proyecto principal. La idea es realizar
integraciones de código constantemente y quizás, varias veces al día dependiendo del enfoque
estratégico de la compañía. Por cada integración pueden existir uno o más testeos para detectar
posibles errores lo más rápido posible.
Luego seguimos con CD (Entrega Continua) qué es el eslabón procedural que le sigue a CI. Este es
un enfoque o práctica en ingeniería software en el que los equipos producen software en ciclos
cortos. Esto va a granizar que el software se pueda lanzar o entregar de manera confiable en
cualquier momento y de forma automatizada. Su objetivo es crear, probar y lanzar software con
mayor velocidad y frecuencia.
Si bien el proceso CI/CD “finaliza”, al estar operativo el producto, en realidad el ciclo vuelve a
comenzar. El uso de CI/CD nos aporta los siguientes beneficios:
Los cambios de códigos son más pequeños y más simples, más atómicos y tienen menos
consecuencias no deseadas.
El tiempo medio de resolución (MTTR) es más corto justamente debido a cambios de código
más pequeños
Los cambios más pequeños permiten pruebas positivas y negativas más precisas
El tiempo transcurrido para detectar y corregir los escapes de producción es más corto
58
La participación y los comentarios del usuario final durante el desarrollo y el testeo
conducen a mejorar la usabilidad del producto final (retroalimentación continua)
Hoy en día es común ver que las áreas de operaciones y desarrollo trabajan en conjunto en el
desarrollo de un producto de software, lo que se conoce formalmente como prácticas de DevOps.
En este sentido, CI/CD son los pilares fundamentales de estas prácticas que trabajan sobre los
principios de integración continua, entrega continua y desarrollo a través de varias pruebas
automatizadas que garantizan un producto de calidad y su correcta entrega.
Combinamos Deployments
En términos generales la palabra deploy es utilizada para describir que algo fue colocado en su
posición, cuando un sistema es habilitado para su uso ya sea en un ambiente de desarrollo, en uno
para realizar pruebas o, en producción. Pensemos en el caso de haber creado un sitio web en la
computadora y lo dejemos estático, sin publicar. En el momento en que incorporamos la página a
un servidor de web Hosting ese proceso será considerado como deploy.
Ahora bien, no debemos confundir el término implantar con implementar porque son cosas muy
distintas. Cuando decimos implantar hacemos referencia a iniciar algo, mientras que implementar
es el acto de poner algo en práctica. Si lo aplicamos al mundo de la programación cuándo se inicia
el desarrollo de un sistema este está siendo implantado, en el momento en que el proyecto
comienza a ser usado por los usuarios podemos decir que ha sido implementado.
¿CUÁLES SON LAS FORMAS DE REALIZAR DEPLOY ? Hoy existen básicamente 3 formas realizarlo:
59
en este caso, realiza todas las pruebas necesarias para que no existan problemas a la hora
de juntar las integraciones de la producción. Una de las herramientas más utilizadas para el
deploy automatizado es Jenkins.
Entre sus beneficios destacan el alto nivel de productividad, la seguridad que nos brinda y
la calidad en el desarrollo de software.
Existen también tres estrategias muy simples que puede ser implementadas y que permiten realizar
deploy en el día a día:
1. ROLLING: Consiste en subir los servicios con la nueva versión del código, pudiendo coexistir
o no con la versión antigua.
2. BLUE-GREEN: Se caracteriza por tener dos ambientes idénticos conocidos como mirror que
tienen un load balancer (balanceador de carga) permitiendo así, redireccionar el tráfico
para el ambiente deseado. El beneficio de esta estrategia es que nos permite subir una
nueva versión de la aplicación que está en producción mientras que la versión actual, Blue,
solo recibe las solicitudes. De esta forma tan pronto como sean realizadas las pruebas en la
nueva versión, Green, es posible realizar otras solicitudes que apunten hacia esta.
¿CÓMO INTEGRAMOS IAC HACE DENTRO DEL CICLO DE DEVOPS DE NUESTRA APLICACIÓN? Los equipos de
infraestructura utilizan pipelines para IAC por las mismas razones que los equipos de desarrollo
usan pipelines para su código de aplicación, ya que garantizan que cada cambio se haya aplicado a
cada entorno y que las pruebas automatizadas hayan pasado.
Con este enfoque las nuevas instancias del entorno pueden activarse bajo pedido lo cual tiene
varios beneficios:
1. Los desarrolladores pueden crear sus propias instancias de sandbox para que puedan
implementar y probar aplicaciones basadas en infraestructura en la nube o, trabajar en los
cambios de las definiciones de entorno sin entrar en conflicto con los otros miembros del
equipo.
2. Los cambios y las implementaciones se pueden manejar con enfoque Blue-Green. Crea una
nueva instancia, la prueba, luego se intercambia el tráfico y se elimina la estancia anterior
3. Quiénes prueban, revisan y otros miembros del equipo pueden crear entornos según sea
necesario eliminándolos cuando no se utiliza.
De esta manera tenemos integrado la gestión de la infraestructura como código dentro de nuestro
ciclo DevOps donde Jenkins administra las tareas que, para este caso, serán el deploy y la operación
como etapas del ciclo.
Jenkins interactúa con ambas herramientas para que cada una realice la tarea necesaria. Dichas
herramientas devuelven una respuesta si la tarea finalizó correctamente o no y según lo que tenga
definido en el pipeline continua 0 lo finaliza.
60
Es importante conocer el ciclo de vida de una aplicación desde su planificación hasta su despliegue
y operación teniendo presente cuáles herramientas se utilizan para cada una de las etapas.
FALLAR RÁPIDO: Provocar que el pipeline falle ni bien se detecta un problema en la etapa, generando
un feedback a los desarrolladores para que resuelvan el problema sin perder tiempo.
TENER ETAPAS BIEN DEFINIDAS: Cada etapa del pipeline debe representar de manera clara un proceso
de CD/CI para que sea mas fácil medir y analizar su funcionamiento y mejorar o detectar problemas.
HACER PRUEBAS FUERTES : Dedicar tiempo para que las pruebas automatizadas sean exhaustivas, ya
que serán responsables de la calidad de nuestra entrega. ¡No queremos que un producto fallido
llegue a producción!
ACTIVAR EL ROLLBACK: En caso de que llegue un producto fallido a producción, mediante el rollback
podemos volver atrás los cambios y desplegar una versión anterior y sin fallas.
BAJAR LA DEPENDENCIA : Eliminar del pipeline cualquier factor externo que no podamos controlar.
Por ejemplo, si al hacer un test tenemos que hacer una consulta a una base de datos, es conveniente
61
generar una base de datos efímera y no depender de una ajena. La mejor práctica, aunque difícil de
conseguir, es levantar todo el entorno de prueba en cada corrida de pipeline y luego destruirlo.
EJECUTAR FÁCILMENTE : Un pipeline no puede ser complejo de lanzar. El desarrollador tiene que
poder ejecutarlo sin esfuerzo. Por ejemplo, es posible automatizar el lanzamiento al aprobar un
nuevo código en un gestor de versiones.
CONTAR CON CREDENCIALES SEGURAS: Gestionar usuarios y contraseñas en depósitos que permitan
resguardar estos datos sensibles. Ofuscar logs en dodnde puedan aparecer.
Resumen de la semana
CD: Existen dos términos clave cuando hablamos de CD y nos sirven para revisar cómo se lanzan
releases de software a un entorno de producción: la entrega continua (continuous delivery) y el
despliegue continuo (continuous deployment).
ENTREGA CONTINUA: se produce software en ciclos cortos, lo que garantiza que se pueda lanzar de
manera confiable en cualquier momento. Su objetivo es crear, probar y lanzar software con mayor
velocidad y frecuencia.
EL PROCESO DE RELEASE : Este proceso consta de una serie de acciones que nos llevan a tener
disponible un paquete completo. En esta instancia es importante enfocarse en las múltiples
versiones 5y en las etapas que lo componen.
Fallar rápido.
Tener etapas bien definidas.
Hacer pruebas fuertes.
Activar el Rollback.
Bajar la dependencia
Ejecutar fácilmente.
Contar con credenciales seguras
PIPELINES END-TO-END: Hablamos del conjunto completo de procesos: CI+CD. Los pipelines abarcan
flujos de trabajo que van coordinando las diversas etapas. Todo esto se define en archivos de
configuración de proyecto e involucra triggers.
Módulo 4: Monitoreo
¿Qué significa monitorear?
Monitoreo es el proceso que permite recopilar métricas sobre las operaciones en aplicaciones e
infraestructura para garantizar que todo funcione correctamente. El término monitoreo puede
5
https://sites.google.com/site/practicadesarrollosoft/temario/scm/versionado-y-staging-de-componentes
62
estar asociado a diversas aristas el mundo IT como la infraestructura, las aplicaciones y el negocio.
En todos los casos el objetivo que se persigue es siempre el mismo:
Para que el monitoreo se puede hacer efectivo necesitamos contar con diferentes tipos de
herramientas tecnológicas que nos permiten realizarlos:
2. HERRAMIENTAS ANALÍTICAS: Una vez que se obtienen datos sobre el desempeño de los activos
digitales, las aplicaciones nos ayudan a analizar la información para encontrar problemas y
revisar cómo y porque están ocurriendo.
3. HERRAMIENTAS DE ENGAGEMENT: Nos facilitan tomar acciones concisas basadas en las
observaciones y los análisis que se han realizado con las herramientas anteriores.
¿CÓMO CONTROLAMOS NUESTROS SISTEMAS? Mediante las métricas vamos a conseguir monitorear,
gestionar, optimizar y generar informes de todos nuestros sistemas. Para esto tenemos que definir
nuestra necesidad. Por ejemplo, que para una carga de 100 usuarios concurrentes los recursos
hardware de un servidor web no superen el 60% de su capacidad de uso, luego nos aseguramos de
que nuestro sistema funcione bien bajo los parámetros establecidos, en caso de que no funcione
podemos ajustarnos agregando más recursos.
Por último, debemos establecer las alertas que serán enviadas en caso de que se rompan ciertos
umbrales.
¿Vamos por buen camino? ¿Por qué? ¿Cómo y en que deberíamos modificar nuestra intervención
para obtener los resultados esperados? Las respuestas a estas preguntas se responden
monitoreando.
Monitoreo es un proceso sistemático que se encarga de recolectar, analizar y utilizar información con
el objetivo de mantener de manera óptima los recursos computacionales y el software de acuerdo a
los requerimientos del negocio.
63
¡El monitoreo es un proceso clave para garantizar que todo funcione de la manera que se espera y
necesitamos! Nos da información para saber si estamos avanzando en el sentido esperado y nos
alerta acerca de cambios o correcciones que deberíamos hacer. En definitiva, es un proceso
indispensable al implementar un proyecto de sistemas. Cuanto más grande sea el proyecto, ¡más
importancia tendrá!
Como venimos descubriendo, el monitoreo se trata de generar información para poder controlar y
verificar que nuestros procesos marchan de acuerdo a lo planificado.
Desarmando esta idea, podemos identificar cuatro objetivos o propósitos que el monitoreo viene
a cubrir:
Evitar y/o prevenir los problemas que puedan surgir ¡Y poder anticiparnos!
Entender qué está sucediendo en tiempo real en nuestros recursos y mantenerlos siempre
alineados a nuestras necesidades.
Hacer análisis porque nos permite almacenar eventos para una revisión posterior.
Como podemos ver, el monitoreo nos guía en la toma de decisiones de gestión, nos permite
generar reportes de desempeño y crear indicadores de uso y rendimiento.
MANIPULAR DATOS PROCESABLES: Las herramientas actuales de monitoreo nos permiten exportar los
datos crudos, también llamados en ingles raw data, para poder ser graficados, almacenados y/o
procesados por otros motores de datos con el fin de obtener la visualización que necesitemos.
64
mi plataforma operativa se están desalineando para poder tomar acciones correctivas y volverlos
a la normalidad.
VISIBILIZAR LAS OPERACIONES DIARIAS : Tener una vista operativa unificada nos permite optimizar el
rendimiento y el uso de recursos. Al disponer de datos detallados, y en tiempo real, operadores,
gerentes de proyecto y stakeholders podrán actuar y tomar decisiones de acuerdo a la información
que reciben.
A la hora de definir el monitoreo de nuestro ambiente, existen dos grandes separaciones que
tenemos que considerar:
Por otro lado, vamos a encontrar aplicaciones. Allí nos va a interesar monitorear elementos
como el número de peticiones o requests, la cantidad de fallos producidos por un servicio
web, eventos de llamadas API, etc.
Todas las herramientas de monitoreo van a cumplir las mismas funciones sobre aplicaciones e
infraestructura.
Datadog6
Plataforma de seguridad y monitoreo para aplicaciones en la nube. Reúne seguimientos, métricas
y registros de un extremo a otro para que aplicaciones, infraestructura y servicios de terceros sean
completamente observables. Está orientada a proveer servicios en la nube.
Puntos fuertes:
6
https://www.datadoghq.com/product/
65
Nagios7
Sistema de monitorización de redes ampliamente utilizado y de código abierto. Vigila los equipos
(hardware) y servicios (software) que se especifiquen, alertando cuando el comportamiento no sea
el deseado. Mayormente utilizado en ambientes on-premises, aunque dispone de servicios
adicionales que apuntan a tener presencia en la nube.
Puntos fuertes:
Prometheus8
Base de series de tiempo y un sistema de monitoreo y alertas. Las series de tiempo almacenan datos
ordenados cronológicamente, midiendo variables a lo largo del tiempo. Las bases de datos
enfocadas a series de tiempo son especialmente eficientes en almacenar y consultar estos datos.
Dispone de funcionalidad para cloud y on-premises.
Puntos fuertes:
Modelado de datos.
Lenguaje PromQL.
Cloudwatch9
Servicio de monitorización y administración que suministra datos e información procesable para
aplicaciones y recursos de infraestructura locales, híbridos y de AWS. Permite recopilar y obtener
acceso a todos los datos de rendimiento y operaciones en formato de registros y métricas a partir
de una sola plataforma. AWS Nativo, con lo cual se integra fácil y naturalmente con cualquier
servicio de AWS.
Puntos fuertes:
¿Qué es medir?
La medición es el proceso que se basa en comparar una unidad de medida preestablecida con el
elemento cuya magnitud se desea medir y, de esta forma, comprender cuántas veces la unidad está
contenida en esa magnitud.
¿QUÉ NOS PROPONEMOS ? Definir una estructura coherente de métricas a monitorear para poder
gestionar, optimizar y generar informes de todos nuestros servicios de forma regular.
7
https://www.nagios.com/products/nagios-xi/#features
8
https://prometheus.io/docs/introduction/overview/#features
9
https://aws.amazon.com/es/cloudwatch/features/
66
¿Qué son los indicadores?
Son el resultado de manipular las métricas para obtener información sobre el comportamiento
basado en diferentes variables. Tanto las métricas como los indicadores nos pueden dar
información para tomar decisiones de negocio relacionadas con las funcionalidades del producto o
la plataforma donde se encuentra.
¿QUÉ NOS PROPONEMOS ? Convertir datos crudos en indicadores nos permitirá conocer nuestro
ambiente, controlarlo y medir los recursos eficientemente, poder anticiparnos al mercado y
optimizar el esfuerzo en el desarrollo de productos.
Métricas y degradación
¿Qué es la degradación?
Es la desviación de las métricas predefinidas que se suelen manifestar mediante la baja
performance de un servicio. El tiempo y el uso son factores que inciden directamente sobre la
performance de nuestro ambiente.
Esta desviación en las métricas configuradas nos ayudará a identificar problemas en nuestros
sistemas con suficiente tiempo antes de que se produzcan problemas mayores.
Disponer de mapas de arquitectura que muestran el flujo de datos dentro del sistema.
CDM (CPU, disco y memoria) son recursos esenciales a chequear en nuestras mediciones.
Tipos de métricas
Podemos reconocer tres tipos de categorías:
67
Métricas de trabajo
RENDIMIENTO: La cantidad de trabajo que realiza el sistema por unidad de tiempo. El rendimiento
generalmente se registra como un número absoluto.
Métricas de recursos
UTILIZACIÓN: Es el porcentaje de tiempo que un recurso está ocupado o en uso.
SATURACIÓN: Es la medida de la cantidad de trabajo que el recurso aún no puede atender, a menudo
en espera o queue.
DISPONIBILIDAD: Representa el porcentaje de tiempo que el recurso tiene para ofrecer a las
solicitudes.
Eventos
CAMBIO EN EL CÓDIGO: Involucra todo tipo de cambio en el código: modificaciones, compilaciones y/o
fallas.
ALERTAS: Eventos generados en función de algún parámetro preestablecido sobre algún recurso.
Monitorear infraestructura
Dato de la realidad: las organizaciones dependen cada día más de herramientas que se apoyan en
infraestructuras digitales. ¡Gestionar y monitorear estos recursos es cada vez más importante para
el correcto desempeño de un proyecto o negocio!
La infraestructura está compuesta por una serie de elementos usualmente ligados al hardware.
Pero, como venimos viendo, con la utilización de software de virtualización el límite entre hardware
y aplicaciones o servicios es cada vez más difuso.
¿Qué podemos monitorear? Estos son algunos de los recursos en hardware físico o virtual:
Amazon CloudWatch
CloudWatch es un servicio de monitoreo y administración de AWS que nos permite centralizar
todos los datos generados por infraestructuras, servicios y aplicaciones locales, en la nube, e
híbridos.
¿Cómo trabaja?
CloudWatch nos propone un flujo de trabajo con las siguientes partes:
68
1. COLECTA: Se recolectan los datos a visualizar o analizar. CloudWatch permite datos en
formato de métricas, registros y eventos.
3. MONITOREO: Los datos recolectados se almacenan para ser mostrados en paneles visuales o
dashboards.
4. ANÁLISIS: Por último, nos brinda una serie de herramientas para poder realizar análisis sobre
los datos recolectados.
Obtención de datos
Existen tres tipos de datos
MÉTRICAS Existen tres tipos de datos: Valores de magnitudes medibles con una firma de tiempo e
identificador.
REGISTROS: Trozos de texto que representan una información (mensajes de consola de una app).
Amazon cuenta con servicios diseñados para la obtención de datos y su envío a CloudWatch. ¡Solo
hay que configurarlo! También ofrece la posibilidad de subir datos mediante su agente (aplicación
que podemos instalar) o a través de su propia API. Dentro de este servicio vamos a acceder a
distintas secciones: paneles, logs, métricas, eventos, etc., en las que podremos visualizar la
información que necesitemos.
Monitoreo
CloudWatch -como toda buena herramienta de monitoreo- nos permite crear paneles a medida,
gráficos e indicadores que visibilicen mejor el estado de los recursos. También tenemos disponibles
paneles por defecto para la mayoría de los servicios existentes en AWS.
CloudWatch nos facilita crear alarmas simples -que se configuran con umbrales específicos de
acuerdo a la necesidad- y alarmas compuestas, activadas por un conjunto de otras alarmas. Entre
otras características posee detección de anomalías, utilizando aprendizaje automático para
determinar comportamientos poco comunes.
Acciones
Mediante CloudWatch podemos disparar acciones automáticas utilizando tanto las alarmas ya vistas
como eventos. Los eventos pueden ser propios de AWS -como cambios en recursos, por ejemploo
se pueden programar para que se disparen cada un determinado periodo de tiempo, como un
despertador.
69
AUTOESCALADO: Un ejemplo es el autoescalado de recursos: cuando se detecta un alto consumo de
CPU, se dispara la acción de escalar horizontalmente (hacer crecer) la cantidad de máquinas
virtuales para satisfacer la demanda. A su vez, si el consumo es mínimo, podemos hacer decrecer
la cantidad de servidores.
Análisis
CloudWatch ofrece operaciones sobre métricas, para obtener información en tiempo real y
analizarla en un panel gráfico.
Mediante CloudWatch Logs Insight permite analizar los logs, realizar consultas con filtros y
exportar a los paneles obteniendo una visibilidad operativa completa.
70
Autoescalado y Elasticidad
El autoescalado es la posibilidad dimensionar nuestra infraestructura de manera responsiva ante la
demanda de los clientes basándonos en la elasticidad de nuestro proveedor. Donde la elasticidad
no es más que la capacidad de los servicios en la nube de entregar o eliminar recursos
automáticamente, proporcionando la cantidad justa de activos para cada proyecto.
En una tienda física para disminuir el tiempo de espera entre una compra y otra, en un momento
de gran demanda, lo único que podemos hacer es habilitar más cajas o puntos para pagar. Es algo
que dependerá del espacio del lugar también y lo más importante, no podemos habilitar o
deshabilitar estás cajas o puntos de pago de forma dinámica cada vez que la demanda sube o baja.
71
gastos de nuestra infraestructura crecerán solamente cuando la demanda pida, evitando que
existan recursos ociosos y un aumento innecesario de los costos.
Resumen de la semana
MONITOREO: El monitoreo es una tarea periódica que permite documentar y utilizar resultados,
procesos y experiencias como base para dirigir la buena toma de decisiones de forma continua.
PIPELINES Y MONITOREO : El ciclo CI/CD no abarca solamente el planear, codificar, testear, deployar y
liberar, sino también el monitoreo, práctica sin la cual nuestro ambiente no podría mantenerse en
pie por los errores que puedan aparecer.
72