درباره این اپیزود
Te doy la bienvenida al episodio 34 de deployandome, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 6 de noviembre de 2018.
Si lo recuerdas, este año comencé contándote de "infraestructura inmutable". En la edición 24 hablamos de los conceptos generales y en la 25 te decía cómo me fui "desayunando" de esta forma de ver, trabajar y organizar la infraestructura.
La idea es bastante simple, pero requiere un entenderla y adoptarla, bah, lo que en educación llamamos "apropiarse del conocimiento".
Básicamente tenemos una base genérica y común cada vez que levanto un servidor o una máquina, que podríamos hacer equivaler a nuestro GNU/Linux recién instalado y con las configuraciones de seguridad (que vimos en las ediciones de deployando.me 16 y 17). Esta base es fija y no cambia, es inmutable.
Sobre esta base aplico los cambios que requiere mi aplicación o el servicio, es decir, que voy a levantar, como si fuera una capa por encima de esa capa inmutable. Y si también recuerdas, para aprovisionar estos cambios hablamos de Administradores de Configuración en las ediciones 18 y 19.
Obviamente todo este manejo simple de entender y automatizar se vio fomentado por la existencia del cloud computing, donde la forma natural levantar una instancia es a partir de una imagen común. Y se terminó de consolidar con el advenimiento de los contenedores donde poner a correr una imagen inmutable y mantener los datos aparte casi no insumo costo (hablo de tiempo y procesamiento) y los contenedores se levantan, bajan, se reemplazan las veces que sea necesario.
Fíjate lo que te digo: ni siquiera la virtualización, que significó pasar equipamiento real a ser un "archivo" que se pone a correr, ayudo a este concepto. Mucha gente en virtualización, realiza las instalaciones arrancando de los DVD de instalación, o mantiene catálogos inmensos de imágenes o snapshots de máquinas totalmente instaladas y configuradas.
Así que, como te digo, el concepto de tengo una primer capa que es una base inmutable sobre la que aplico una segunda capa con mi personalización, llegó a nosotros recién con el cloud computing y los contenedores.
Entonces ¿qué pasa con los que manejan servidores reales? o los que trabajan con virtualización exactamente igual a cómo lo hacían con servidores reales?
Te puedo contar de mi propia experiencia. Lo que suelo hacer en esos casos es tratar de mantener el sistema instalado lo más puro posible, es decir, tal cual cae del DVD de instalación. Y mis cambios los hago principalmente en la carpeta /opt o en la /usr/local y tratando de mantener esto lo más posible.
Entonces para todo lo que es actualizaciones trato de mantenerme dentro del sistema de paquetes que me ofrece la distribución que uso y para los cambios en el /etc utilizo etckeeper del que te conté en la edición 3 de deployando.me.
Además aplico administradores de configuración tratando de tener todo lo más posible escrito en base a playbooks de ansible que versiono y guardo en git.
Y luego respaldos y monitoreo.
Igual, con todas estas precauciones, con todo este esfuerzo de prolijidad que quiero mantener en los servidores reales (o virtualizados) cuando tengo que actualizarlos o reponerlos siempre me resulta una astilla en el dedo.
Y si, no me pasa lo mismo cuando hablamos de instancias en la nube o cuando son contenedores, por precisamente tengo infraestructura inmutable.
Y todo esto hasta ahora, porque hace muy muy poco que descubrí libOSTree (o "los amigos" podemos llamarlo OSTree) que en forma general se puede ver como "git para binarios del sistema operativo", lo que transforma mi servidor real a infraestructura inmutable más los "commit" necesarios para mantenerlo actualizado.
Como te decía, mi vinculación con OSTree es bastante reciente y recién estoy haciendo mis primeros deploy utilizándolo.
La idea es que OSTre
