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 OSTree es un sistema de actualización para distribuciones de GNU/Linux que realiza actualizaciones atómicas de árboles completos de sistemas de archivos. No es un sistema de paquetes, es un complemento al sistema de paquetes de tu distribución.
OSTree funciona en el espacio de usuario y funcionará sobre cualquier sistema de archivos Linux. Se basa en un almacén de objetos (o repositorio) con direcciones de contenido similar a las git branches (o "refs") para rastrear árboles de sistemas de archivos significativos dentro del repositorio. De este modo, uno puede hacer roll-back o checkout de estas branches.
Y además, OSTree se encarga de la configuración del cargador de arranque (bootloades), la administración del /etc (y ya no necesitaré etckeeper) y las demás funciones para realizar una actualización más allá de la simple replicación de archivos.
En términos generales y si lo paso al ejemplo de como te decía que manejo los servidores reales, imagínate que parto de una instalación del DVD que no modifico nunca más. Luego genero un branch que llamo "mi aprovisionamiento" y le paso todos mis playbooks de ansible para dejarlo en estado de producción.
Para actualizarlo, genero un nuevo branch que llamo "actualización octubre 2018" y corro el apt-get dist-upgrade con total tranquilidad (e irresponsabilidad). Si todo funciona sigo en esta rama, si hay problemas solamente tengo que recuperar la rama anterior "mi aprovisionamiento" y todo seguirá funcionando.
Desde mi punto de vista simplifica y asegura el nivel de servicio que requiero en mucho de los despliegues que tengo en producción.
No se si notaste cuando comentaba que OSTree funciona en espacio de usuario, o sea que puedo utilizarlo transparentemente hasta para el deploy de las aplicaciones fuera del sistema de paquetes, creando repositorios específicos para el mantenimiento de esas aplicaciones instaladas.
Y si lo pienso, y bueno, la documentación lo dice, pero a mi me cuesta visualizarlo, como OSTree maneja los cambios en el bootloader, podría hacer que mi branch o upgrade sea un cambio completo de distribución. Podría instalar Centos y actualizar con un Fedora, manteniendo en el bootloader tendría la posibilidad de arrancar uno u otro kernel y distribución y todo junto en el mismo sistema de archivos.
Y esto pasa porque OSTree admite la grabación y el despliegue de árboles completos de sistemas de archivos (desde el arranque). No tiene conocimiento incorporado de cómo se generó un determinado árbol de sistema de archivos o el origen de archivos individuales, o dependencias, descripciones de componentes individuales, ese conocimiento está en el sistema de paquetes.
Fíjate que debido a que OSTree opera en el sistema de archivos Unix, funciona sobre cualquier sistema de archivos (ext4, BTRFS, XFS o, en general, cualquier sistema de archivos compatible con Unix que admita enlaces duros). Pero si estás usando BTRFS OSTree aprovechará de manera transparente algunas características sus características.
Y te digo más:
El contenido del repositorio OSTree está pensado para poder ser desplegado incrementalmente a clientes remotos utilizando HTTP con validación de firmas GNUpg y en canal cifrado TLS.
¿Te das cuenta? Podría usarse OSTree para desplegar tu cambio en una infraestructura en forma paralela simplemente esparciendo tu branch por los distintos host.
A mi las posibilidades me entusiasmaron apenas comencé a leer la documentación.
libOSTree es un software libre, cuyo código obviamente está disponible y se obtiene bajo licencia LGPLv2+
Hay varios software que se vale de las funcionalidades de OSTree, como ser rpm-ostree que es un puente entre OSTree y DNF para la instalación y mantenimiento de sistemas basados en rpm.
Si el tema te interesa, adelante con la documentación y has pruebas y pruebas. He utilizado la versión Silverblue de Fedora que ya viene con OSTree instalado y activado por defecto, pero no necesitas utilizarlo en todo el sistema operativo, puedes instalarlo y usarlo para una rama de tu sistema de archivos, es decir para solo una aplicación o carpeta.
Y te cuento que a partir de esta edición, deployando.me está disponible para ser escuchado desde Spotify y desde Google Podcast, lo que se suma a iTunes, iVoox, Stitcher, TuneIN y Youtube. Mi idea es que te puedas levantar a la mañana y decir "oye Lola, ¿hay un nuevo episodio de deployandome?.
Y además, si esto de escuchar podcast te entusiasma, te gusta escuchar sobre temática exacta que te interesa, te es cómodo que escuchas cuando tienes ganas y tiempo, que no estás sometido a horarios, bueno, si todo eso te gusta, por favor, no dejes de entusiasmar también a un amigo tuyo; porque los que hacemos podcast nos gusta compartir con nuestros escuchas; así que acerca gente al podcasting.
Soy Rodolfo Pilas, en twitter me puedes seguir por @pilasguru y te dejo un saludo. Confío que este podcast te haya aportado para mejorar y, como siempre, espero tus inquietudes y sugerencias comentando en deployando.me
Hasta la próxima edición.