Te doy la bienvenida al episodio 25 de deployandome, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 16 de enero de 2018.
En la edición pasada te contaba sobre cómo es el concepto "infraestructura inmutable" y porqué es un abordaje que ayuda a posicionarse frente al cloud computing y a los contenedores. Durante la semana recibí unos cuantos comentarios y agradecimientos lo que me dió a entender que el tema resultó de bastante interés.
En mis comentarios al final del episodio indicaba que no era fácil aplicar infraestructura inmutable, principalmente cuando se trabaja en equipos multidiciplinarios o con clientes que están cómodos trabajando con sus infraestructuras permanentemente en mutación. También por alguno de esos comentarios que recibí me dieron a entender que infraestructura inmutable estaba bueno, pero se veía algo lejos de ser aplicable.
Por eso he decidido volver a tratar el tema de la infraestructura inmutable, pero ahora desde un punto de vista más práctico y lo que me parece más adecuado es contarte cuál ha sido mi experiencia, es decir cuál ha sido el camino que he recorrido para apropiarme de la infraestructura inmutable y por eso he titulado esta edición como "yo y la infraestructura inmutable".
Recapitulando, seguro recuerdas que en el episodio anterior hablamos de dos formas de manejar o posicionarnos frente a la infraestructura que estamos administrando.
La primera, o mejor dicho, la tradicional, que llamamos infraestructura mutable, que se caracteriza por entrar a nuestros servidores por SSH a cambiar cosas. Que describimos las consecuencias y los conceptos que le son afines a esta forma de gestionar la infraestrutura. Que la infraestructura mutable la representé con la metáfora del "martillo y el clavo" como procedimientos y herramientas que domino y sobre los que tengo reconocida experiencia.
Y la segunda o la nueva forma que se llama infraestructura inmutable, que vimos que le es afin al cloud computing y a todo el séquito de tecnologías o herramientas emergentes. Que infraestructura inmutable es partir de cero, es decir, de tener solamente una cuenta y los permisos para acceder a nuestro proveedor de cloud, en forma automática levantamos toda nuestra infraestructura (redes, servidores, gateways, etc.), realizamos las configuraciones de cada uno de los componentes, instalamos las aplicaciones necesarias y realizamos los test de conformidad, levantamos las alertas y registros de monitoreo y emitimos las notificaciones de que llegamos a 100% y luego no tocamos ni modificamos nada, solo monitoreamos y medimos. Si necesitamos actualizar o ajustar algo, levantamos nuevos componentes actualizados, que pasarán los test correspondientes y suplantarán los anteriores que serán desafectados y borrados definitivamente.
¿se nota la inmutabilidad, no? Ningún SSH para ajustar nada y todo automatizado, siempre partiendo de cero a cien y descartando componentes obsoletos.
Y aquí viene cómo practicar esto. Cómo hice yo para hacerme amigo de las diferentes tecnologías y herramientas que se requieren para la infraestructura inmutable.
Primer paso: el clavo y el martillo automático
No estuve en la situación de estar a cargo de la infraestructura de algún Netflix o startup innovadora que me zambullera en la infraestructura inmutable, así que mi punto de partida fue de algo afín, es decir empecé con infraestructura mutable pero automatizada. Es decir, dejé de hacer SSH a cada servidor y automaticé los cambios con un sistema administrador de configuración.
En los episodios 18 y 19 de deployandome te cuento primero en forma general y luego en forma más particular, qué son los los administradores de configuración, cuál es su alcance y cuáles fueron las ventajas que encontré utilizándolos.
Empecé usando Puppet y luego lo sustituí por Ansible que me resultó mucho más afín y fácil de entender para mi mente formateada al calvo y al martillo. Con Ansible empecé a delegar al principio pocas tareas, por ejemplo, mantener los authorized_keys de los accesos por SSH, el agente de backup o el cliente de software de monitoreo, para terminar describiendo la configuración completa de mis servidores en producción.
Con el administrador de configuración aprendí que podía tener mis servidores 100% descriptos y documentados en un guión y las cosas adicionales que requería ese guión para ser aplicado, por ejemplo, el código git de la aplicación, los procesos de testing y aprobación de las instalaciones.
Segundo paso: el proveedor
Necesité aprender a interactuar con el proveedor de cloud. Por supuesto que conocía el API que podía colocar en un script y voilá aparecía mi infraestructura, pero siempre me pareció muy "a pedal" y dependiente del proveedor, pues cada uno tiene su cliente para usar su API en particular.
Ahi es donde Vagrant jugó un papel importantísimo en mi camino hacia la infraestructura inmutable.
En los episodios 12, 13 y 14 te cuento sobre qué es y cómo se usa Vagrant, sobre sus conceptos de "provider" que permite instanciar la infraestructura y el concepto de "provision" que es justamente la instalación que ya sabía automatizar con Ansible. En el episodio 14 te explico cómo es el workflow de vagrant donde inicias tu jornada levantando toda la infraestructura lo necesario para tu trabajo y al finalizar borras todo.
Vagrant me separó del API propia de cada proveedor y me permitió utilizar fácilmente una y otra nube o incluso levantar infraestructuras híbridas entre componentes locales y componentes multi-proveedores.
¿lo podría haber hecho con Ansible? Si claro, pero no fue mi caso.
Y de Vagrant di el paso a la herramienta que considero más apropiada para vincularme y mantener infraestructuras con proveedores de cloud y hablo de Terraform, también de los autores de Vagrant y que aún no he tratado en deployandome. Creo que cuando termine esta edición tendré un conjunto interesantes de cosas para tratar en algún momento.
A estas alturas ya había hecho propio el concepto de empezar sin nada, sin ningún recurso y terminar con mi infraestructura a nivel de servicio o con todos los recursos activos.
Tercer paso: elasticidad y resiliencia
Te confieso que este ha sido un aprendizaje difícil, principalmente porque con estamos con infraestructura mutable la elasticidad no es tan elástica es decir, se puede crecer y decrecer pero dentro de parámetros acotados y la resiliencia que daba solución a mis problemas se basaba en un sistemas activo-pasivo bastante básico.
En infraestructura inmutable hablamos de monitorear y automatizar elasticidad levantando instancias adicionales del recurso en cuestión y de resiliencia en sistemas activo-activo con eventuales reemplazos de los recursos que están comprometidos.
Para esto lo que he utilizado son los orquestadores nativos de los proveedores de nube, armando lo que se conoce como plantillas de stack de recursos con escalabilidad. En Openstack utilicé el orquestador Heat y en Amazon el orquestador CloudFormation. (si, más cosas para tratar en futuras ediciones).
Cuarto paso: contenedores y clusters
Docker por si mismo es efímero, generalmente se levanta de un punto base y se le configuran los cambios que uno necesita. Es fácil levantar clusters (kubernetes o swarm) para mantener un grupo de contenedores prestando un servicio. Esos clusters necesitan procesos de monitoreo y anuncio de cambios, de gestión de puertos, de endpoints y proxies,
En fin, no voy profundizar mucho, pues yo mismo estoy en procesos de separar la paja del trigo en estos temas y me gusta hablar de aquello que entiendo (o creo que entiendo) y puedo explicar.
Pero lo que si tengo claro que docker es el último escalón en el que me apoyo para apropiarme del concepto de infraestructura inmutable.
Como te decía, esto que te he compartido es mi experiencia personal y no me considero para nada un iluminado que te cuenta de como he vuelto un ser de luz, por el contrario, me gusta y entusiasma saber de otras experiencias equivalentes que hacen los procesos más fácil, más progresivos o más óptimos. Por eso te invito a que, si es tu caso, me comentes como aplicas infraestructura inmutable en forma total o parcial en tus procesos de trabajo o cuál ha sido tu experiencia de aprendizaje.
Soy Rodolfo Pilas, en twitter me puedes seguir por @pilasguru, confío que este podcast te haya aportado para mejorar, te dejo un saludo y, como siempre, espero tus inquietudes y sugerencias comentando en deployando.me
Hasta la próxima edición.