deployando.me 5v6960

Te doy la bienvenida al episodio 37 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 2 de mayo de 2019. Hace un rato que no deployo una edición del podcast, confío que a partir de ahora poder hacerlo en forma en forma periódica. Por supuesto, que siempre puedes seguir cuando sale una edición nueva a través de twitter o instagram @deployandome, o escuchar con tu aplicación de podcast preferida, porque tendrá mucho espacio entre ediciones, pero seguro está en todos lados que he conseguido publicarlo. Me ha sucedido muchas veces que me piden replicar, copiar, espejar los archivos de una carpeta en otro servidor. Generalmente cuando se desea tener una contingencia pasiva del servicio que presta un servidor, es decir, que el servidor principal recibe archivos y se copian a un segundo equipo como contingencia si el primero falla. No creo que esta sea una situación muy excepcional ya que personalmente me ha pasado unas cuantas veces y estamos hablando aquí de algo adicional a un método de respaldos. Mientras que un respaldo habilita puntos de recuperación históricos, sincronizar archivos entre servidores, de mantener un espejo de un servidor en otro. Si has estado en la situación de armar una solución que cumpla estos requerimientos, me inclino a pensar que optaste por lo que siempre suelo optar en primer lugar: por rsync. rsync es una herramienta espectacular para hacer esta sincronización. Cada vez que se corre rsync compara los archivos del origen con el destino y trasmite solamente los diferenciales binarios. Rsync copiará obviamente los archivos nuevos, puede borrar los que no existen más en el origen, pero no copiará los archivos que han cambiado; lo que hace rsync obtener hashes de trozos de los archivos y comparar con el hash correspondiente en destino, si e hash coincide procesa el pedazo siguiente y si no coincide, transfiere el pedazo hasta igualarlo en el destino. Al final los archivos quedan idénticos. Por esta funcionalidad rsync es muy apreciado a la hora de copiar archivos grandes sobre redes que pueden introducir errores o cortes de comunicación, pues cuando la tarea finalice puedes estar seguro que los archivos son iguales. Pero rsync tiene un problema bastante grave: no escala. Si tengo una carpeta con 100 archivos rsync revisará cada uno buscando diferencias y si están iguales finaliza su tarea, para esto demora algunos segundos. Ahora supongamos que estmos frente a una una carpeta con 4 millones de archivos, como ya me ha pasado, y supongamos también que solo un archivo ha cambiado o es nuevo, entonces rsync revisara los 3.999.999 archivos iguales y sincronizará solo el archivo que ha cambiado, para lo cual seguramente demorará... si, muchas horas. Por lo tanto hay un problema de escala donde rsync deja de ser óptimo por el tiempo que demora, necesitamos algo más inteligente ... y de eso, te voy a contar en esta edición de deployandome Si has seguido la explicación anterior, te habrás dado cuenta que el problema de escala que tiene rsync se soluciona dándole inteligencia como para evitar procesar archivos que ya han sido copiados a destino. Y como todo en ingeniería, la solución para este problema puede ser abordada desde distintas enfoques. Un enfoque simple, es decirle a rsync que si el archivo existe en destino lo considere como idéntico y no lo revise por pedazos para saber si hay cambios. Esto se logra con la opción --ignore-existing de rsync, que es ideal, por ejemplo, cuando tenemos la carpeta donde los s de un sitio web suben su foto de perfil; estos archivos no se modifican, lo que sucederá que puede ser reemplazado con otro en un determinado perfil, pero nunca modificado. Con la opción --archive rsync solo analizará el archivo remoto si la fecha del archivo local es más nueva que la del remoto.. Pero en todos los casos rsync necesita analizar, cada vez que se corre, todos los archivos del orígen y compararlos contra todos los archivos de destino. Una opción que me sirvió durante un tiempo fue pasarle a rsync la lista de archivos de origen procesadas con el comando find con la opción -mtime que devuelve solo los archivos modificados entre la vez anterior que se corrió rsync. Pero todas estas soluciones son remedios provisorios a los problemas de escala te comenté, pues llega un momento que esos mismos remedios son insuficientes para encarar el problema de la cantidad de archivos, pues en definitiva todos suponen revisar el 100% de los archivos de origen y con 4 millones de archivos, hasta un simple ls demora minutos en empezar a desplegar resultados. Pero para solucionar este problema y aportar muchas más funcionalidades a la hora de sincronizar o procesar archivos nuevos o cambiados existe lsyncd del cual te voy a contar ahora. lsyncd cómo ya supondrás por la terminación en letra d es un daemon se corre tu Linux y que está continuamente viendo una carpeta del filesystem local para interceptar los eventos de inotify y de fsevents. Inotify es un api del kernel Linux que notifica eventos de filesystem tanto de un archivo como de una carpeta. FSEvents, por su parte, es el equivalente de inotify pero para sistemas MacOSX. Una vez que lsyncd detecta un cambio a nivel de filesystem en la carpeta que está monitoreando, puede lanzar eventos en forma asincróna que actúen exclusivamente sobre ese cambio que se acaba de producir. Es decir que si tengo una carpeta con 4 millones de archivos y agrego o modifico solo un archivo, lsyncd actuará solamente sobre ese archivo y sabe cuál es el archivo porque justamente lo anuncia inotify y no necesita revisar la totalidad de los archivos. ¿y cuáles son los eventos que puede lanzar lsyncd? Lo más simple que puede hacer lsyncd es lanzar un rsync de ese archivo para duplicarlo a otra carpeta. Y es lo más simple pues en el archivo de configuración del daemon le indicas carpeta origin y carpeta destino y no necesitas nada más. Estas opciones de configuración lsyncd las identifica como capa 4, la más alta y más simple de configurar, donde lsyncd tiene directivas y él maneja por debajo el rsync. En la misma capa 4, lsyncd puede lanzar un rsync+ssh para copiarlo a uno o más servidores remotos. Y aquí la configuración es carpeta de orígen, lista de servidores, opciones de conexión ssh y ya! Por defecto lsyncd deja un log de todo lo que va haciendo que te permite conocer cómo han ido evolucionando los datos dentro de la carpeta o carpetas que monitorea. Extendiendo la funcionalidad de lsyncd, ya en lo que denomina capa 3, podemos invocar a comandos del sistema o de bash, como , sed if o lo que necesitemos, pudiendo decidir si actuamos sobre la creación de nuevos archivos o sobre la modificación. En lo que se describe como la capa 2 de configuración, lsyncd nos va a permitir hacer spawn lanzar aplicaciones, como por ejemplo pdftotext, y aquí le vamos a poder decir a lsyncd qué el evento responde a una determinada extensión. Entonces nuestro evento quedaría configurado en condiciones de: cuándo se crea un archivo, cuya extensión es .pdf, ejecute la siguiente línea del comando de pdftotext para convertir su contenido a texto plano. Lsyncd va un paso más, en la capa de configuración más baja de lsyncd, la capa 1, tendremos a nuestra disposición todo el poder del lenguaje lua, que es un lenguaje de programación imperativo muy liviano, utilizado como lenguaje de extensión en cientos de aplicaciones para darte el poder de crear la funcionalidad extra que quieras. Los ejemplos que trae el manual de lsyncd llevan desde registros de cambios en bases de datos, notificaciones en Slack, conexiones con servicios de ftp, esperas por eventos locales o remotos, etc. Y esto es lo interesante de lsyncd, que no solo es un replicador inteligente de archivos, con lo cual soluciona el problema de escalabilidad de rsync que te comentaba en un principio; lsyncd es un procesador de eventos a partir de los cambios en el filesystem. Lsyncd es un Software Libre que está escrito en C y en Lua y se obtiene con licencia GPL versión 2. Se instala mediante paquete en la mayoría de las distribuciones y es un proyecto iniciado en el año 2010 por Axel Kittenberger. Una de las cosas que hice con lsyncd fue crear simple sistema de distribución de archivos para una CDN (Content Delivery Network) que recibía las peticiones de archivos gestionadas por regiones mediante el servicio de DNS que según donde estabas ubicado en el mundo te ofrece el servidor más cercano geográficamente. 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. Referencias: Artículo: How to Use Rsync to Sync New or Changed/Modified Files in Linux Artículo: How To Synchronize Local And Remote Directories In Linux Artículo: How to install and configure Lsyncd Sitio oficial lsyncd(1) - Linux man page Lsyncd Technical Session inotify(7) - Linux man page

Te doy la bienvenida al episodio 36 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 5 de febrero de 2019. Todos tenemos alguna aplicación o algún software que usamos preferente en nuestro entorno de trabajo, una aplicación que usamos más que todas las otras, una aplicación que define nuestro entorno de trabajo. Programador – IDE de programación Diseñador gráfico – Editor de fotos o vectorial Dpto. contable – Planilla electrónica Dpto. istración – Correo electrónico Muchos – Navegador de Internet Para mi es, sin dudarlo, el secure shell, el SSH. Posiblemente por ese motivo le he dedicado muchos episodios de este podcast. La serie OpenSSH que se registra en el blog https://deployando.me tiene actualmente cinco episodios. La cuestión que para mí sin SSH representa casi como estar “sin internet”. Estoy de manos atadas y no tengo casi condiciones de desarrollar mi trabajo. De forma equivalente a cómo el mecánico de mi automóvil mantiene un tablero de herramientas con los perfiles dibujados en color llamativo de cada una de sus herramientas, para encontrarlas y ordenarlas más rápidamente, debo pensar y cuidar mi SSH: debo considerar distintos escenarios, debo hacer la curaduría de mis certificados de y debo estar preparado para tener un SSH disponible cuando lo necesito. Pero, algunas veces no tengo SSH, ni tengo mi notebook, ni tengo los certificados que requiero para acceder. Por eso, en esta edición de depolyandome te voy a contar cómo hago para tener SSH cuando el ambiente donde me encuentro no permite disponer de SSH, es decir, una otra opción al SSH normal de mi notebook. Como te decía, muchas veces debo conectarme a redes donde el SSH está completamente capado. A veces empeora, pues estoy frente a equipos que no son míos, no tienen un cliente SSH y, mucho menos, tienen los certificados que necesito para acceder al equipamiento que mantengo. Pero si hay algo común a esos equipos y redes: en el 99% de los casos ese puesto de trabajo cuenta con un navegador y ese navegador tiene salida internet. Entonces en lugar de intentar conectarme al servicio OpenSSH (puerto 22) puedo conectarme libremente (generalmente a través de proxy auditado) a los servicios web (puertos 80 y 443). Así que por ahí comencé a pensar una solución a la falta de conectividad SSH. Originalmente hice algunas pruebas colocando el servicio SSH escuchando en puerto 443, pero habían dificultades cuando tenía un proxy. También pensé en tunelizar sobre HTTP el servicio SSH. Pero en ambos casos dependía de clientes instalados en los equipos que estaba utilizando. Hasta que encontré un software libre llamado SHELL-IN-A-BOX que permite exportar el shell sobre un navegador web. Es decir que ahora la terminal de mi Linux-box esta dentro de un navegador: es una página web, pues Shellinabox ofrece la emulación de terminal VT100 corriendo dentro de cualquier navegador actual ejecutando. Shellinabox es un paquete que se instala como cualquier otro y levanta un servidor web sobre SSL en el puerto 4200/T y al que se accede con un navegador. Obviamente, si busco una alternativa siempre accesible no podía dejar el puerto 4200 ya que estaría bloqueado en muchas redes o proxies, así que edité la configuración de Shellinabox y modifiqué el puerto por defecto al 443, reinicié el servicio y ahi quedó mi conectividad habilitada. Shellinabox es un software libre licenciado mediante GPL escrito por Markus Gutschke desde el 2008 al 2012, y el paquete Debian instala la versión 2.20. Existe un fork (que dejo en las notas del podcast) que ha recibido varios aportes, fixes y mejoras del proyecto original. De esta forma solucioné mi problema: tener un shell casi en cualquier lado, utilizando un navegador, hasta en un equipo de un hotel o un cybercafé. Dentro de ese shell puedo tener mis certificados SSH y las configuraciones (.ssh/config) para acceder a los servidores que mantengo. Ahora abro el navegador, coloco una URL y veo el conocido prompt de : y luego : del shell de GNU/Linux. Pero ahi me surgió un segundo problema: toda la seguridad de a mis servidores (por más que accedo con certificados con phrase) estaba expuesta a cualquiera que supiera mi y y conociera la URL accesible desde todo internet. Así que implementé un segundo nivel de validación: agregando validación e clave única o como se suele llamar validación de dos pasos utilizando Google Authenticator, que también es paquete de la distribución Debian. En el servidor de Shellinabox configuré el módulo PAM de google-authenticator únicamente para cuando se ingresa por Shellinabox, dejando el de de consola y el por ssh directo sin la validación de dos pasos. Respecto a google-authenticator instalé la aplicación en mi celular para el cálculo de la clave única cada ves que me la solicita. Así que ahora mi por Shellinabox es : -> : -> verification code: Pero como soy dependiente ahora de tener mi celular para ingresar, también me guardé varias claves atemporales de un solo uso, en un correo electrónico dirigido a mi mismo al que puedo acceder por webmail, en caso que no tenga mi celular. Por último, y solo por un tema de delicadeza de la solución, el certificado de validación SSL que utiliza Shellinabox por defecto es autofirmado, por lo que requiere aceptar la validación la primera vez en el navegador que se está utilizando. Para esto instalé y configuré un certificado Let’s Encrypt para que sea utilizado por Shellinabox. Si recuerdas, Let’s Encrypt fue el tema del primer podcast de Deployando.me. Y con eso me quedó una solución a prueba de bloqueos, redes seguras y demás restricciones que a veces suelo encontrar en distintos ambientes o momentos. Por supuesto, que si no tengo ni SSH ni a WEB, ni por red del lugar, ni por red de móvil de mi tablet o mi móvil, es cómo si no tuviera Internet, como si estuviera en la isla de Lost y, en esos casos, creo poder prescindir de acceder a mis servidores. En las notas del blog deployando.me, quedan enlaces a todos estos software que te he mencionado y a algunas guías de cómo se configuran. Si tienes algún sistema de “contingencia” para acceder a tus servidores o tus infraestructuras me gustaría que lo compartas en los comentaros del blog, o con respuestas a los mensajes de Twitter de este episodio o en la noticia en Instagram. 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. Referencias: Sitio oficial Paquete Debian Ubuntu Wiki Fork shellinabox Tecmint tutorial Google-Authenticator Pilas.guru Google-Autenticator

Te doy la bienvenida al episodio 35 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 28 de noviembre de 2018. En la actualidad todos tenemos una amplia cantidad de sitios, servicios, aplicaciones, servidores donde nos validamos mediante contraseñas. Y no hay un ser humano normal que sea capaz de acordarse las contraseñas para cada uno de esos sitios. Para complicarlo un poco más, muchas veces estas contraseñas o validaciones deben ser compartidas, con mi familia, con mis compañeros de trabajo o con los clientes. Viviendo y aprendiendo, todos hemos adoptado algunas estrategias para tener disponible la contraseña que necesito en el momento que la necesito. Hablando de estrategias he visto mucha cosa, no voy a hacer un exhaustivo resumen ellas, pero muchas veces me encuentro con gente que hace algo de esto: Utilizan la misma contraseña para todo, o que establecen pequeños cambios, como agregarle los números del año de cuándo crearon la cuenta. Quienes tienen una libreta y van con ella a todos lados Los que mantienen planilla electrónica o un documento de texto (a veces con clave). De estos están los que lo guardado en servicios como Dropbox o GoogleDrive. Y hay algunos, que tienen algun algoritmo mental que les permite calcular la contraseña a partir de por ejemplo el nombre del servicio. Un ejemplo simple sería para Google utilizar permutaciones de letras por números G 0 0 G 1 3 o lenguaje de jeringoza y tener la clave tipo G O O P O G L E P O. Ya se, me vas a decir que son terribles ejemplos de lo que NO hay que hacer con claves y contraseñas, pero te juro que semanalmente me encuentro con alguien que utiliza alguna de estas estrategias. Y ya que estamos, vos ¿Cómo manejas tus contraseñas? Todas ellas, desde las super secretas de a tu banco hasta las más triviales de suscripción a una newsletter; desde las personales hasta las compartidas; desde las que requieren complejidad para ser aceptadas hasta los cuatro números del PIN. Como no me considero un experto en la materia no te voy a dar consejos, pero en esta edición de deplorandome te voy a contar cuál ha sido mi experiencia en los últimos 30 años con el manejo de las contraseñas. Te decía que me considero alguien más que “hace lo que puede” para sobrevivir con todas las contraseñas que tiene la necesidad de manejar y mantener. En mis orígenes, ya hace mucho mucho tiempo (década de los ’90) mantenía tres contraseñas distintas: “la trivial” que usaba para sitios que no me importaba nada, incluso es la que conocen mis colegas como mi contraseña por defecto si ellos me están dando un por defecto: “oye entra aquí que ya configuré tu ”. Luego tenía la contraseña “segura”, que me preocupaba de cambiar cada tanto y era la que mantenía, pero que llegado el caso podía darla en caso de emergencia. Y por último, la “super segura y difícil” que no revelaría ni bajo tortura. La aparición del los móviles y los múltiples servicios casi que para todo, hizo que este estrategia de tres claves fuera inútil. La clave “segura” estaba en mucho más sitios que los que me gustaría, o sitios que consideraba “triviales” se volvieron importantes. Así que me fui por una herramienta de gestión de claves. Encontré un artículo en mi blog pilas.guru sobre es de claves que es una investigación que hice en Agosto de 2006 donde hago un relajamiento de lo que encontré en ese momento. Un de claves es un software que se instala en tu computador que permite crear una ficha por cada sitio o clave, clasificar esa ficha en carpetas o categorías y que está todo en una base de datos cifrada, al que se accede mediante una master-, que en definitiva es la única clave que hay que recordar. Así fue como comencé a utilizar Kee, un software libre multi-plataforma licenciado bajo GPL que descargué e instalé en mi computador. Lo que hice fue colocar el archivo de la base de datos en una carpeta vinculada a un servicio de sincronización que me permitía tenerlo también en mi celular y en él me instalé la versión correspondiente de Kee. Una maravilla, fue la primera vez que solamente tenía que recordar una master-, que además podía cambiar las veces que quería. Pero también tuve un problema, el a múltiples servicios, el abrir un sitio tras otro estaba siempre frenado por tener que ir hasta el Kee, abrirlo, buscar el sitio, copiar y pegar la clave. Así que decidí migrar a un servicio on-line de de claves. No te voy a decir qué servicio pues no tengo interés en recomendar un servicio privativo con software privativo y menos aún, porque no es lo que uso actualmente. Pero te voy a comentar las ventajas que vi de un servicio on-line frente al Kee de escritorio. Para empezar la integración con el navegador mediante una extensión. No pienses que acá hablamos de que las claves las recuerde el navegador, los navegadores tienen un de claves, pero son exclusivos para sitios web y tengo infinidad de claves más: de servidores, de mis hijos, de aplicaciones. Muchas claves que el navegador por si solo no me resuelve, pero un sitio online de claves si lo hace. El segundo cambio es que el servicio on-line me llevó a empezar a tener por primera vez claves siempre diferentes para cada sitio. El tener que abrir el Kee me hacía mantener mi política de clave trivial: “esto no es importante, va clave trivial”. Al tenerlo en el navegador cualquier cosa que escribiera ya es recordado automáticamente. Y claro, al ser un servicio on-line lo tenía también disponible en mi movil y el tablet. Pero a partir de este año decidí dejar de utilizar un servicio con software privativo y tener algo donde los autores compartan el código, tanto para el servidor como para el cliente y lo encontré. El de contraseñas que utilizo se llama BITWARDEN al cual le importe los datos del servicio que utilizaba antes y quedó funcionando en forma transparente. Bitwarden es un software libre que se puede instalar en tu propio servidor o puedes utilizar el servicio de los creadores, que te dan una cuenta gratis o planes con diferentes beneficios extras. Los clientes, que también son software libre, están disponibles para todas las plataformas, incluyendo las móviles, y los navegadores más conocidos (lo uso en Safari y Brave). Pero además el servidor Bitwarden expone un API y está disponible un cliente de consola llamado bw para el manejo de las claves en el repositorio. En la actualidad con Bitwarden tengo todas mis contraseñas y credenciales, incluyendo notas confidenciales y datos de tarjetas de crédito, y para todo solo necesito recordar una master- que cambio cada pocos meses. Bitwarden se corre perfectamente con mis dispositivos Apple con iOS, validando directamente desde el teclado con TouchID o FaceID, es decir, que al empezar a escribir un y clave, el teclado desplegable ya me propone obtenerlo de Bitwarden, quedando muy integrado. Bitwarden es un software libre licenciado bajo GPLv3 y su código se encuentra disponible en GitHub y su repositorio core cuenta con más de 2300 estrellitas. Se que hay otras opciones, obviamente no conozco todas. De las aproximadamente 500 claves o fichas que manejo con Bitwarden solamente unas 25 están repetidas, lo que es un 5% del total, y que generalmente son de servicios heredados de otros tiempos. Otra estrategia que he tomado, ademas de tener todas mis claves diferentes es tener s de correo diferentes, aprovechando la funcionalidad que permiten los servicios de Gmail que puedes tener tu nombre seguido de un símbolo de más y luego un cadena de caracteres, antes de la arroba. Entonces cada vez que un sitio me pide un correo, por ejemplo Twich, el correo que utilizo es [email protected]. ¿Para qué? Pues si algun día roban la base de s, como suele pasar casi todos los meses en distintos sitios y empiezo a recibir spam, va a ser muy fácil crear un filtro que frene esos correos. Este mes me encontré con Buttercup que es un software libre bajo licenciamiento MIT, que está programado en Node.JS y que permite tener un servidor de istración de claves, que como no lo he probado, no te puedo decir mucho más de él. No mucho más, si eres de los que utiliza una libreta o una planilla, aquí tienes algunas opciones que he utilizado. Si utilizas un servicio o un software privativo, aquí tienes algunos software libre y servicios basados en software libre al que es fácil cambiarse. En las notas del blog deployando.me, quedan enlaces a todos estos software que te he mencionado. Si conoces alguno más que quieres compartir, te agradeceré lo hagas dejando un comentario. 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.

Te doy la bienvenida al episodio 34 de deployandome, el podcast de tecnología para syss 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 es 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 es 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 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 istració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 , 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 ite 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 ita 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. Referencias https://ostree.readthedocs.io/en/latest/

Te doy la bienvenida al episodio 33 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 11 de octubre de 2018. ¿algunas vez te ha pasado de tener un servidor que está “raro”? Me refiero a un servidor que a veces tiene altos tráficos de datos que no puedes determinar a que se deben, o que tiene abierto puertos que no sabes qué escuchan, o que en la lista de procesos hay algunos procesos que no reconoces y a veces la U y la memoria se consumen pero cuando ingresas empieza a volver a niveles normales. A ver, estos problemas, si tu has armado el servidor y tienes un control completo desde su nacimiento, es decir, que lo instalaste y istras tu, puedes trazar y localizar el problema con relativa facilidad. Pero hay veces que el servidor no es tuyo y te llega, digamos, “enfermito” y te piden que explores y hagas un diagnóstico. Otras veces te llaman en medio del incendio, cuando el servidor ha sido comprometido y está dedicado a mandar spam o minar criptomonedas. Por eso hoy te voy a contar de LYNIS, una herramienta de auditoría que hace un análisis del servidor y te ayuda a identificar el problema para que puedas hacer un diagnóstico, sin necesidad de tener altos conocimientos del sistema instalado. Estamos hablando de LYNIS, una herramienta de software libre que permite hacer una auditoría de tu servidor para evaluar la seguridad y tener alguna indicación de qué defensas se deben implementar. Lynis es un script de bash que en su versión actual 2.6.9 tiene 1100 líneas, que está acompañado por algunas carpetas con más bash script y archivos de texto de configuración y datos. Por esto es muy fácil de instalar, o te viene como paquete en las principales distribuciones, o lo podés clonar a partir de su repositorio git o descargar el release como tgz. Una vez que lo tienes instalado lo ejecutas como lynis autit system y va comenzar por una fase de inicialización para determinar el sistema operativo y el entorno en el que está corriendo, pues lynis corre en AIX, FreeBSD, GNU/Linux, macOS, NetBSD, OpenBSD, HP-UX y Solaris. De ahí lo que te decía, si conoces bien tus cajas GNU/Linux, pero ahora estás frente a un AIX o un GNU/Linux que no es tuyo, lynis te va a hacer ese primer análisis sin que tengas que ponerte a bucear en el listado de procesos que están corriendo. Luego que lynis se ubica dentro de qué sistema está corriendo, está en máquina virtual o en contenedor, va a revisar qué utilidades y herramientas hay instaladas en el sistema, para saber qué puede utilizar para hacer sus análisis. Por ejemplo, buscará herramientas como demidecode, lsu, sysctl o lshw. También investigará si el sistema corre init o systemd para analizar la configuración de arranque. Con esos datos hará primeramente una revisión de si mismo, para conocer su integridad y si está actualizado. Esto siempre y cuando el equipo donde lo estás corriendo tenga conectividad a Internet. Y ahora comenzará con cientos de test individuales, primero test en base a plugins y luego test de seguridad por categorías. En estos test analizará la protección que tiene el sistema y verificará que no sufre de los problemas más comunes en permisos, configuraciones, desórdenes de seguridad, cuentas sin clave, permisos indebidos y auditará el firewall entre otras cosas. El análisis de lynis es oportunista, es decir que ante la presencia de un servicio (por ejemplo, apache) verificará su configuración; en caso que apache no esté instalado, ignorará todos los test sobre él. Para sus análisis LYNIS se basa en las mejores prácticas, en las sugerencias del Center of Internet Security (CIS), del National Institute of Standards and Technology (NIST) y de la National Security Agency (NSA), también en los datos de OpenSCAP y las recomendaciones de seguridad de los proveedores de las distribuciones como Debian, Gentoo o RedHat. A medida que va corriendo, lynis emite un completo reporte de los resultados, pero al finalizar te dará un resumen de las cosas que considera debes dedicar inmediata atención con las sugerencias para solucionar los problemas. Lynis es una herramienta de software libre, licenciada con GPLv3 y pensada para es, profesionales en seguridad y auditores y, obviamente, puede ser utilizada en pentesting para descubrir vulnerabilidades o encontrar fallas para explotar. Actualmente cuenta con más de 50 desarrolladores activos y su código tiene más de 5000 estrellitas en GitHub. Michael Boelen, su principal desarrollador lo comenzó como una forma de evaluar la defensas de sistemas GNU/Linux allá en 2007, hace más de 10 años por lo que tiene un interesante grado de madurez. En 2013 Michael se convirtió en desarrollador full-time, fundó la compañía llamada CISOFY que ofrece soporte comercial y también lanzó una versión Enterpise que permite gestionar información de lynis corriendo en múltiples servidores. Este tipo de herramientas emiten informes que deben ser ponderados de acuerdo a los entornos, las aplicaciones y el negocio en general, por este motivo ellas mismas no modifican ni cierran los agujeros que puedan encontrar. Su función se limita a darte sugerencias que deberás analizar y, si lo consideras, ejecutarlas. En mi experiencia y el uso que le he dado a LYNIS es el que te comentaba en un principio, tener un fácil y rápido diagnostico de un servidor GNU/Linux, generalmente cuando no lo he instalado o no lo istro. Si el tema te interesa, también te sugiero los episodios 16 y 17 de deployandome donde vimos las recomendaciones más recibidas de como fortalecer tu servidor GNU/Linux. 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. Referencias Github CISOFY Linux Security Lynis 2.6.8 – Security Auditing Tool for Unix/Linux Systems

Te doy la bienvenida al episodio 32 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 28 de agosto de 2018. El otro día estaba revisando viejos archivos y me encuentro una carpeta con material de un taller que dicté en un evento que se hacía anualmente llamado TechMeetup y que se realizó en el complejo de conferencias de la Torre de las Comunicaciones aquí en Montevideo, en el año 2014. El taller se llamó istración de llaves SSH para aplicaciones y ese material está compartido en mi blog pilas.guru En el taller presentaba el problema que nace cuando empezamos a utilizar aplicaciones y a automatizar los s con certificados SSH, ya que quitamos la phrase al certificado, precisamente para que las conexiones se puedan establecer automáticamente y muchas veces para acceder como root en los servidores de destino. Supongo que por la insistencia que le pongo a OpenSSH en distintas ediciones de este podcast te habrás dado cuenta que lo considero algo tan fundamental para gestionar una infraestructura como lo es el servicio DNS para el funcionamiento de Internet. Y por eso, en esta edición de deployando.me, te voy a contar cómo hago mis configuraciones para tener certificados SSH sin pasphrase, que habilitan a mis aplicaciones a conectarse como root, sin que ello signifique un riesgo de seguridad. Sabemos que el par de certificados SSH tiene su llave privada y su llave pública. Sobre la llave pública podemos tener un nivel de seguridad cero, nada. Podemos copiar la llave publica a cualquier servidor, publicarla en un web, ponerla en nuestro perfil de twitter, es decir nada, la llave pública que la tenga cualquiera, no hay problema con ello. Pero la llave privada es otra cosa, por eso su nombre; se tiene que proteger ya que es la que permite colocar mi firma digital, es decir, la llave que me representa, que me abrirá las puertas. Sobre la llave privada tengo dos niveles de seguridad, un primer nivel es el propio archivo, lo que en seguridad se llama “lo que tengo”, sobre el archivo trato de tenerlo solo yo y pondré cuidado en que esto se mantenga así. Un segundo nivel de seguridad es la phrase que me permite utilizar la llave pública, lo que en seguridad se llama “lo que sé” y esta phrase solo la se yo y si por algun motivo tuve que compartirla o escribirla en un ambiente poco seguro, siempre puedo cambiarla en cualquier momento. Ahora fíjate que cuando esto lo llevo a una aplicación automatizada, que digamos corre en el crontab, y debe acceder como root a un servidor lo que tengo que hacer es quitarle la phrase a la llave privada que le dará el , ya que no estaré para escribirla, pues obviamente es automatizada. ¿Qué pasó ahi con la seguridad? Ya no tengo el nivel de seguridad de “lo que se”, es decir la phrase, sino que solo queda la seguridad de “lo que tengo”, en este caso el archivo de la llave privada. Pero, fíjate que la aplicación automatizada no va a estar corriendo en mi notebook, donde digamos yo podría cuidar que nadie haga una copia del archivo de la llave privada, no!, esa llave privada sin phrase va a estar alojada en donde corre la aplicación que estoy automatizando, que será el servidor de respaldo, el servidor de sincronización, el servidor del agente de monitoreo o lo que sea que estoy automatizando. Entonces en resumen estoy dejando un archivo en algún lugar de mi infraestructura que permite a quién lo tenga conectarse a un conjunto de mis servidores y, si esa conexión se hace como root, no te tengo que explicar el “poder” de ese archivo. Pero ahí es que debemos utilizar lo que en la página man del SSHD aparece cuando se describe el formato del archivo authorized_keys como las “opciones” que se pueden configurar en los certificados públicos que tenemos inscriptos. Estas opciones limitarán el alcance o los servicios que OpenSSH dará a las conexiones. Mediante estas opciones podemos configurar para que, aunque alguien mal intencionado tenga el certificado privado sin phrase de la aplicación, no le sirva para nada, o por lo menos, no pueda hacer nada más que lo que hace la aplicación automatizada que lo usa. Es decir, si la aplicación respalda la base de datos, a este mal intencionado no le servirá, por ejemplo, para crear s y solo podrá respaldar la base de datos. Y esto, como te digo, si es que el certificado público le sirve para algo. — La idea es que dentro del authorized_keys copiamos el certificado público, uno por renglón, pero delante en el mismo renglón podemos ponerle estas opciones que limitan cosas. Por ejemplo, podemos ponerle from= y la IP del servidor desde donde aceptamos la conexión, tendrá que llegar con esa IP o jamás el servidor OpenSSH le otorgará el . Otra opción bastante útil es no-pty que evitará otorgarle una terminal interactiva a quién se conecta. Si es una aplicación no necesita una terminal, sino que va a estar ejecutando un grupo de comandos. O si por ejemplo, solo queremos habilitar sFTP, esta sería la opción que le configura el al cliente sftp pero no de shell al cliente ssh. Asi que sumando estas dos opciones en un certificado público haremos que solo sirva si te conectas de una determinada IP y solo puedas ejecutar comandos y no obtener un shell. ¿Entender cómo funciona? Y hay más.. Con la opción no-port-forwarding evitaremos que utilice la conexión como puente para acceder a un servicio de otra. Con no-x11-forwarding evitaremos que ejecute aplicaciones gráficas eventualmente instaladas en mi máquina que se despliegan gráficamente en la de este muchacho mal intencionado que les vengo diciendo que se copió el certificado sin phrase. Y fíjate que justamente para estas dos funcionalidades de ssh no necesita tener un shell, o sea que deberíamos sumarlas a las opciones no-pty y from que te decía antes. Hay otras opciones que te sugiero consultar en el man de sshd pero podemos simplemente utilizar la opción restrict que es un comodín que engloba todas las opciones restrictivas, presentes y futuras que se le puedan poner a un certificado, así podrás asegurarte que el está limitado aunque actualices OpenSSH. Pero hay una opción más que la llamo la ‘última‘ opción, y es la opción command= donde puedes poner el comando que se ejecutará al usar el certificado y será ese comando si o si para lo que servirá el certificado. Fíjate que command=/usr/bin/uptime en un certificado público, cuando alguien acceda por ssh ejecutará uptime y saldrá. No importa si del otro lado quieren ejecutar otro comando, conectando por ejemplo con ssh whoami, lo que verá su terminal es la ejecución de uptime. Por eso, con las opciones from restrict y command en los certificados que tenemos los archivos authorized_keys podemos empezar a dejar certificados privados sin phrase en manos de nuestras aplicaciones con un muy razonable nivel de seguridad. 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.

Te doy la bienvenida al episodio 31 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 14 de agosto de 2018. Cuando instalamos un nuevo servidor, nos preocupamos de dejarlo actualizado, de configurar el idioma y la sincronización de hora, de instalar las aplicaciones y librerías que requiere para su uso, de hacer el hardening correspondiente para darle las condiciones básicas de seguridad, de configurar el sistema de backup y de inscribirlo en el sistema de monitoreo de nuestra infraestructura. Entre todo esto, nos tomamos muy en serio los s para quiénes tendrán que hacer : con qué ingresarán, si ese tendrá permisos en el sudoers y recolectamos e inscribimos con mucho cuidado los certificados públicos SSH en el authorized_keys para que ingresen. Ahora, te pregunto una cosa ¿no sientes que la istración de todos estos certificados ssh es algo frustrante? Te cuento lo que me suele pasar a mi: a medida que va pasando el tiempo los servidores empiezan a tener certificados que no se sabe bien a quién pertenecen, a veces de algún desarrollador que necesitó entrar para una ayuda puntual, a veces de alguna proveedor que necesitó algún . También se vuelve bastante difícil distribuir los certificados para los nuevos es y quitar aquellos de los que no están más afectados al servidor y ya no deberían tener , algunas veces puedo manejar esto con Ansible, algunas veces es una tarea manual. Como que siento que en la carrera de mantener y istrar los s con certificados SSH estoy atrás. Pero existe una luz sobre este problema, una solución bastante simple pues desde la versión de OpenSSH 5.4 es posible utilizar certificados tanto para servidores, como para s, basados en la confianza dada por una Autoridad de Certificación y de esto, vamos a conversar en esta edición de deployandome. Add for certificate authentication of s and hosts using a new, minimal OpenSSH certificate format (not X.509). Certificates contain a public key, identity information and some validity constraints and are signed with a standard SSH public key using ssh-keygen(1). CA keys may be marked as trusted in authorized_key or via a TrustedCAKeys option in sshd_config(5) (for authentication), or in known_hosts (for host authentication). No es la primera vez que en deployandome tratamos el tema de OpenSSH: en la edicione 4 conversamos sobre sshuttle para armar VPN con SSH, en la edición 5 de sshfs para montar por SSH filesystems de servidores remotos, o por ejemplo, en la edicion 20 de MOSH para mantener un shell permanente y performante validando por SSH. Pero más allá de esto, explicar el funcionamiento de la validación que hace OpenSSH con los certificados siempre me ha resultado un desafío interesante; cuando lo hago en el marco de los cursos que dicto en la Universidad termino con unos gráficos en el pizarrón, unas cuantas flechas, recuadros y hasta colores que me ayudan en la explicación. Ahora voy a tratar de explicártelo tipo cuento, acercándote a los conceptos y, si necesitas profundizar, siempre puedes recurrir al blog deployando.me donde dejo comandos y referencias a documentación adicional. Para una conexión por SSH tenemos básicamente dos tipos de validación donde intervienen certificados Primero una validación del host al que nos estamos conectando, donde nos atiende un servidor OpenSSH y nos envía un paquete firmado que verificamos con el certificado público que tenemos guardado en el archivo local known_hosts, que es el llavero donde tenemos los certificados de los hosts en los cuales confiamos. Si no tenemos el certificado público nos pregunta si queremos incorporar el certificado a nuestro llavero y contestamos el famoso yes que precede toda conexión SSH que hacemos por primera vez. La segunda validación es la de y sirve para habilitar el al host remoto. En este caso el certificado público del de origen debe estar inscripto en el archivo authorized_keys del con el que voy a acceder en el host de destino. Esto, que es la configuración normal en que solemos tener un entorno de conexiones SSH, conlleva el problema que debemos gestionar manual la primer conexión a los servidores (para incorporar el certificado del host al known_host) y debemos mantener los certificados para acceder en archivos authorized_keys que están distribuidos en todos los host y en los s de esos hosts. Pero con un sistema de confianza basados en certificados públicos firmados podemos simplificar, automatizar y controlar más eficazmente nuestro entorno de conexiones SSH. La utilidad principal es ssh-keygen que vamos a utilizar para crear, firmar y revisar certificados que hemos firmado. El funcionamiento de firma es simple: Generamos dos pares de llaves SSH estándar que usaremos para firmar las llaves públicas de los host y de los s. Te lo repito: siempre movemos, copiamos y firmamos la parte pública de las llaves SSH, la parte privada queda en los servidores y s que las generaron. Entonces para empezar generamos estos dos pares de llaves que podemos llamar server-CA y -CA, una para firmar llaves de hosts o servidores y otra de s. Para firmar usaremos ssh-keygen seguido de -s de sign. Cuando firmamos un certificado de un host también pondremos -h host y cuando firmemos un certificado de un no necesitamos ningún otro switch. Al firmar, ssh-keygen nos generará un nuevo archivo con el mismo nombre que el archivo de la llave pública que termina en .pub, pero ahora terminado en cert.pub Estas llaves públicas firmadas podemos consultarlas con ssh-keygen -L para listar información de validez, autoridad de certificación y demás datos del certificado. Obviamente que te estoy simplificando los comandos, pero creo que te vas haciendo una idea por donde viene la mano del proceso de firmas. Nuevamente veamos los dos tipos de validación, de host y de , pero ahora utilizando estos certificados firmados. Para la validación de host, la llave firmada de los host tenemos que llevarla a cada host e inscribirla en el archivo sshd_config con la directiva HostCertificate En los archivos known_host de los clientes voy a registrar solamente la llave pública de la autoridad de certificación que llamamos server-CA.pub en una linea que inicia con la directiva @cert-authority Esto va a provocar que al conectar por primera vez por SSH puedo verificar que el certificado ofrecido está firmado por la autoridad de certificación en la que confío y validar la identidad del host automáticamente, sin necesidad de ningun yes ni incorporar nuevos certificados a mi llavero. La ventaja a nivel de aplicaciones automatizadas es notoria ya que inmediatamente todos nuestros servidores que tengan su certificado firmado por esa autoridad de certificación serán confiables para establecer conexión y utilizar todas las funciones de OpenSSH. Para la validación de funciona un poco diferente. Ahora quién hará la validación para otorgar será el propio servidor OpenSSH al que me estoy conectando y ya no dependerá de los s de destino. En el servidor de destino, modificamos el archivo sshd_config pero esta vez usaremos la directiva TrustedCAKeys seguido un archivo que concatena la llave pública de la autoridad de certificación, o sea la -ca.pub. Los s que inician conexión tienen las tres llaves: su privada, la pública y la pública firmada. Cuando establezcan conexión SSH será el propio servidor que validará la llave firmada por la autoridad de certificación y si el al que quiere conectar existe, habilitará el . Si necesitamos separar los s, es decir que un no quede con a todos los s de todos los servidores, podemos tener diferentes certificados para firmar, es decir, un certificados para databases, otro para webs, otro storage, y así. Y para evitar el como root tenemos la directiva PermitRoot del servicio SSH. Con el uso de certificados OpenSSH firmados podemos armar un esquema de control de las validaciones de host y s de s en nuestra infraestructura. OpenSSH implementa además la posibilidad de crear y disponibilizar listas de revocación para tener una validación inmediata de los certificados que no están más autorizados; pero esto sería tema para otra edición de deployandome. Por un lado, te reconozco que puede no sea una solución ideal, que no estamos hablando de un esquema X.509, ni de un sistema de autenticación centralizado. Pero, por otro lado, es un método simple que tenemos a nuestra disposición sin mayor esfuerzo, pues no necesitamos instalar servicios adicionales ni tener un servidor online para validación de certificados de la autoridad de certificación. Y a la hora de manejar una infraestructura dinámica y elástica utilizar certificados SSH firmados nos va a solucionar unos cuantos workarrounds que hacemos generalmente para que SSH fluya sin trabas. Te recuerdo que en blogpost de este podcast dejo información adicional. 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. sshd_config man page What the -I certificate_identity ssh-keygen option is for? Setting up a SSH Certificate Authority (CA)

Te doy la bienvenida al episodio 30 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 26 de junio de 2018. Hace unos días me junté con amigos es de sistemas y que también son profesores en otra universidad y hablando de cursos y preparación profesional surgió la pregunta: ¿Hay que saber programar para ser de sistemas? Esa charla de boliche se fue por los caminos normales: a medida que se va llenando el estómago (de bebida y comida) van cambiando las respuestas que ensayamos y el abordaje que hacemos del tema. Pero la pregunta quedó dando vueltas en mi cabeza. Por eso hoy, basados en esta pregunta, inauguro una modalidad de deployando.me que he dado en llamar no, donde a partir de un tema invito a amigos a que expresen su opinión y trato de aprender de ellos. Y por eso en este primer DEPLOYANDO.ME NO buscaremos dar respuesta a la pregunta ¿Hay que saber programar para ser sys? De la cual imagino, tu también tienes tu opinión o puedes contestarla, pero veamos qué opinan nuestros invitados. Le formulé la pregunta a mi amigo Daniel Coletti DAX, de Buenos Aires, Argentina, a quién conocí liderando el Grupo de s Linux de Capital Federal (CAFELUG) allá por por el 2003 en la segunda edición de CAFECONF la Conferencia Abierta de GNU/Linux que se realizaba anualmente en la Capital Federal. Pero dejemos que DAX se presente y nos de su opinión sobre este tema: Daniel Coletti Que interesante esto que nos plantea DAX sobre la evolución del sys hacia operadores de nube y devops, un poco deprecando el rol del sys. Sin duda también podemos tener nuestra opinión al respecto, pero creo que todos coincidiremos en que estamos en un momento de revolución en cuanto a qué conocimientos, qué roles se perpetúan y cómo debemos posicionarnos en nuestra profesión. Gracias DAX También le mandé la pregunta a mi amigo Anahuac de Paula, que vive en el nordeste de Brasil, en la ciudad de Joao Pessoa, junto ahí donde está la puntita de América sobre el Océano Atlántico. Con Anahuac nos conocimos en II Fórum Internacional do Software Livre (FISL) en el 2001, y luego tuvimos la oportunidad de compartir muchos otros eventos juntos. De hecho Anahuac es palestrante en la próxima edición del FISL 18 que se celebrará del 11 al 14 de julio próximo, como siempre en la ciudad de Porto Alegre. Vamos a dejar que Anahuac se presente y nos de su respuesta sobre el tema: Anahuac de Paula Gracias a ti Anahuac por sumarte a otra de mis locuras y compartirnos tu opinión. Por último le hice llegar la pregunta a mi amigo Enrique (el gallego) Verdes. Con Enrique como vivimos aquí en Montevideo, tenemos mucha historia juntos desde hace también muchos años vinculados a GNU/Linux y el Software Libre en general, ambos fuimos Presidente del Grupo de s Linux del Uruguay y actualmente compartimos esa pasión por la enseñanza. Así que Enrique, preséntate y dame tu opinión en este tema: Enrique Verdes Gracias Enrique y aprovecho a contar que precisamente por esa conversación que tuvimos sobre tu necesidad de armar una curricular para tu curso de de Sistemas es que surgió esta pregunta. Hay una vieja frase del de sistemas, que no es de mi autoría, que dice: La primera vez hice la tarea, la segunda vez hice la tarea y la scriptie, la tercera vez la tarea se hizo automática. Y creo que es un buen resumen que evidencia la necesidad de saber programar que tenemos para istrar sistemas y un buen cierre para esta primer edición de NO de deployando.me. 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.

Te doy la bienvenida al episodio 29 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 29 de mayo de 2018. Si recuerdas, en el episodio anterior conversamos sobre Secure Enhanced Linux (SELinux) y vimos que despliega de una capa de seguridad basada en políticas que se aplican mandatoriamente a todos los s del sistema, ya sean aplicaciones, s o el propio root. Quedamos en ver cómo hace SELinux para aplicar estas políticas, es decir, cómo permite o niega una determinada acción. Y también en cómo podemos hacer nosotros para istrar nuestras configuraciones de políticas o aquello que te comentaba de cómo sobrevivir con SELinux activado. La decisiones de SELinux para autorizar o denegar una determinada acción se basan en el contexto entre el sujeto (quién inicia la acción) y el objeto (que será el destino de la acción). Este contexto es un componente de las reglas que mantiene SELinux en sus políticas. ¿Cómo se define, entonces, un contexto? SELinux lo que hace es manejar etiquetas o labels que representarán estos sujetos y objetos. Fíjate que con un manejo de etiquetas, SELinux se abstrae de conocer cosas como el propietario de un proceso, los permisos de un archivo y, a la vez, se puede empezar a etiquetar cosas que hasta ahora no tenían referencia explícita, como puertos o sockets. Los archivos guardan las etiquetas en atributos extendidos del filesystem; los procesos, puertos y otros será el kernel Linux quién maneje directamente las etiquetas en runtime. Claro, te preguntas ¿cómo son estas etiquetas? Las etiquetas tienen un formato de cuatro campos separados por dos puntos: el primer campo es el (que atención!, no tiene una correlación con el de sistema), el segundo campo es el rol, el tercer campo es el tipo (que también se le llama contexto) y un cuarto campo opcional para definir niveles. Si hiciéramos una equivalencia con un sistema de gafete para una empresa que reparte identificaciones para las personas que están dentro de su predio, podríamos decir que el puede ser “visitante” (¿ves que no tiene nada que ver con la persona en si misma?), el rol puede ser “auditor”, tipo podría ser “hornos” o “línea ensamblado” y el nivel podría ser uno “técnico”, “supervisor”, “procesos” etc. De esta forma etiquetas a una persona como visitante:auditor:línea_ensamblado:seguridad y te permite definir si va a tener , por ejemplo, detener la linea de ensamblado. ¿lo entiendes? Para lo que te estoy contando que es cómo ser amigos de SELinux, solo el tercer campo, el campo tipo, nos es relevante. Los otros campos de la etiqueta, como o el rol, se utilizan cuando tienes requisitos de seguridad de que se enmarcan en controles de de Multi-Level Security (MLS), utilizado generalmente en el ámbito militar, o Multi-Categories Security (MCS), utilizado en el ámbito financiero, por lo que esta será la única referencia que haré a estos tres campos y nos concentraremos de aquí en más en el campo del tipo. Ahora veamos cómo esas etiquetas de tipo permiten vincular los sujetos con los objetos, y creo que lo mejor es verlo con un ejemplo: y vamos a usar el servidor web Apache, que ya por sí es un estándar maduro para servicios web. Pero antes debes saber que para las etiquetas se ha definido la opción -Z (generalmente mayúscula) para que los distintos comandos desplieguen las etiquetas de lo que ellos muestran. Por ejemplo, el comando id -Z mostrará la etiqueta que llevas tu ahora, como del sistema (por supuesto, solo si estás en un sistema con SELinux). En el ejemplo de Apache, el binario que ejecutamos es httpd que si consultas con ls -Z verás que tiene un tipo (o contexto) definido como httpd_exec_t. Si lo lanzas verás la etiqueta del demonio con el comando ps axZ, que que tiene un tipo o contexto httpd_t Con el comando ss -z (en este caso minúscula) podemos listar los sockets abiertos, ver que que el puerto 80 está vinculado al proceso etiquetado como httpd_t. O usar el comando semanage port -l | grep httpd para ver que existe una etiqueta httpd_port_t que contiene, entre otros, el puerto 80. También si hacemos un ls -Z al directorio donde Apache puede leer los archivos web, en mi caso /var/www/html podremos ver que su contexto es httpd_sys_content_t. Y con esto ya tenemos los ingredientes para armar un sistema de políticas de y asociar la etiqueta de un sujeto con la etiqueta de un objeto y decirle si se aceptan o deniegan las acciones. Ah, ¿creías que era más complicado? Tranquilo, es como todo, cuestión de agarrarle la mano. El comando para manejo de las etiquetas es semanage. Que nos va a permitir cosas como: asignar etiquetas a s del sistema manejar los puertos o sockets vinculados a una etiqueta definir los contextos de los archivos Entre otro montón de otras opciones de configuración. La sintaxis de semanage no es simple, hay que referirse a la documentación, casi que en todos los casos. La otra característica es que todo lo que instalo por el sistema de paquetes, si lo utilizo como viene por defecto, queda configurado con políticas de SELinux adecuadas y no debo tomar ninguna acción. Aparte de las etiquetas para sujetos y objetos, SELinux maneja permisos que afectan las funciones de las aplicaciones o deamons mediante los llamados booleans ya que se prenden (valor on o 1) o se apagan (valor off o 0). En particular, los booleans son políticas (o conjuntos de políticas) de SELinux que definen un funcionamiento aceptable para los procesos del sistema. Siguiendo con el ejemplo de Apache, podemos apagar el booleano que permite acceder a un filesystem montado por red, o a conectarse a una base de datos LDAP, o servir los home de los s. ¿Qué quiere decir esto? Que el la configuración de Apache pude muy prolijamente tener configurada y activada una de estas funcionalidades, pero la política de SELinux le puede negar hacer uso de esa funcionalidad. Y son cientos los boleados que vienen per-configurados para muchos tipos de daemons y aplicaciones. Los comandos que se usan para el manejo de boleados son getsebool y setsebool según si se quiere consultar o configurar el estado de un booleano. Y podemos decir que esto es todo, aunque para ser amigos de SELinux podemos hacer algo más y eso es conocer los modos de SELinux. Los modos es cómo SELinux aplica las políticas y tenemos tres posibilidades: puede ser de modo Enforced permitiendo o denegando; de modo Permissive permitiendo todo, pero guardando en el log de auditoría (audit.log) los incumplimientos de las políticas, o, la tercer opción, puede ser Disabled que es cuando SELinux está apagado. Dependiendo de la distribución, tendrás SELinux pre-configurado en alguno de estos modos. Para manejo de los modos se dispone de los comandos getenforce y setenforce que que permiten pasar entre Enforced y Permissive en cualquier momento. Esto es muy útil para cuando algo no funciona como uno espera, pasar SELinux a Permissive y si ahora comienza a funcionar, seguro se debe a alguna política y deberemos ajustar las etiquetas o cambiar el booleano. Y si, hay mucho más de SELinux pero creo que con estos puntos que te he comentado puedes hacerte una idea de por donde viene la cosa. Si lo vas a activar, cosa que obviamente te sugiero, es conveniente dejarlo funcionando desde la instalación inicial, pues cada cambio lo hagas será siguiendo las políticas. Si no lo has activado y tienes tu servidor en funcionamiento desde hace tiempo, al activarlo, posiblemente sean muchas cosas las que incumplan políticas y la adecuación se te hará difícil. En todos los casos SELinux requiere que de RTFM por lo que espero que esta presentación de SELinux en dos ediciones de deployandome te permita decidir si sirve para tus necesidades de seguridad. 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.

Te doy la bienvenida al episodio 28 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 24 de abril de 2018. No creo sorprender al afirmar que la seguridad significa un compromiso con la usabilidad. Esto lo podemos ver en nuestras propias casas: si tenemos una reja permitetral en el jardin, una reja delante de la puerta, una puerta y una alarma; para entrar y salir nos llevará un cierto tiempo dedicado solo pasar por los elementos de seguridad que hemos colocado y además deberemos cargar o recordar llaves o mandos para cada uno de esos elementos de seguridad. No es la primera vez, ni será la última, que en deployandome abordaré temas vinculados a la seguridad, la seguridad es parte de nuestras tareas. Si recuerdas, en la edición 1 ya hablamos de certificados SSL con Let’s Encrypt. En la edición 7 vimos con solo poner un archivo en una carpeta ya quedaba cifrado. En las ediciones 16 y 17 repasamos algunas prácticas generales para fortalecer nuestros servidores. Pero en esta edición 28 voy a traer un elemento de seguridad que en la mayoría de los manuales sugieren “desactivarlo” y te confieso la mayoría de los colegas con los suelo hablar lo tienen, efectivamente, desactivado. “Desactívalo y vas a ver que todo te funciona” es la frase más común que solemos escuchar vinculada a Security Enhanced Linux, que todos conocemos como SELinux, y que hoy lo voy a deployar contigo. Pues, como te digo, percibo que SELinux está en la mente de la mayoría de mis colegas como una molestia, como una traba de seguridad que complica más de lo que soluciona y te confieso que tuve esa misma sensación hasta que lo conocí o hasta que nos hicimos amigos. Por eso, para ser justos con SELinux, tenemos que entender qué hace, para qué está y qué soluciona, luego recién podremos decidir si es bueno aplicarlo o no. En GNU/Linux tenemos un solido sistema de permisos basados en privilegios de s. Por un lado tenemos s que tienen permiso de a ciertas partes del filesystem, a abrir cierto rango de puertos para conexiones T y a editar ciertos archivos. Cambiando estos permisos de , principalmente en los archivos, podemos lograr independizar el accionar de un con otro y ya el kernel Linux se encargará de separar los espacios de memoria, los procesos, las conexiones. En esta nube de s independientes entre si, conviven las aplicaciones y los s humanos, que los llamamos system s y s respectivamente. Un tercer jugador es el : root. Adecuadamente comparado con Dios. Ya que sus permisos son globales, inclusive puede actuar contra el propio sistema, borrando espacios de disco, interceptando memoria, gestionando procesos ajenos… en fin, puede hacer todo. Para llevar la gestión diaria de un sistema GNU/Linux hay tareas que son iniciadas como y luego decrece privilegios para ejecutar como y, hay otras, que un puede pedir que sean realizadas como , cuando él no tiene suficientes permisos. A este sistema de permisos se le conoce como un sistema “discrecional”, es decir, depende quién seas será lo que puedas hacer, siendo que la mayor jerarquía puede incluso deshacer lo que se ha hecho por debajo de ella. Llevemos este sistema de permisos al mundo real: imaginemos una organización que llamaremos ENTIDAD-A que está basada en una jerarquía discrecional: supongamos tiene un tesorero que se encargara de la gestión financiera y un secretario que lleva la gestión istrativa. De esta forma, el tesorero no podrá establecer contratos y el secretario no puede hacer pagos. Pero existe el Presidente de la ENTIDAD-A que puede venir y cesar un funcionario o puede pedir se pague algún gasto, y solamente por ser el presidente, puede hacer esto y mucho más. Las organizaciones con jerarquías “discresionales” están por todos lados: ¿cuántos de nosotros le decimos a un compañero que abra un ticket por su reclamo, pero salimos volados de nuestro escritorio si llama un gerente por un reclamo equivalente? Si te pasa esto entonces trabajas en una organización con jerarquía “discresional”. Suelo explicarles a mis alumnos que un discrecional es aquel que se contesta con “dime quién eres y te diré que puedes hacer“. Esto es lo que tenemos normalmente en nuestros sistemas GNU/Linux. Tratamos de trabajar como y anteponemos sudo para tareas puntuales que requieren privilegios superiores, justamente para que el sistema nos de la protección del discrecional. ¿o nunca escuchaste la frase “no conviene trabajar como root“? Pues es precisamente por esto: por el control discrecional. ¿Y sabes qué? El discrecional no se adapta a las necesidades de una organización moderna. A ver si entendemos el problema del control discrecional: Los es y los encargados de seguridad sabemos que es necesario manejar un cierto nivel de “confianza” en las personas que operan el sistema para mantenerlo seguro. Esto se debe a que, en el GNU/Linux discrecional, gran parte de la confianza en el sistema depende de la voluntad de los s que lo operan y que escalan privilegios para hacer sus tareas y entonces “confiamos” que no harán cosas no autorizadas y apelamos la ética profesional para mantener la seguridad. Una organización basa su seguridad en “políticas” que no pueden estar basadas en la “confianza” ni en la “ética, sino que se deben aplicar en forma mandatoria, siempre, sin importar quién seas, o si te desempeñas éticamente o no. Y es precisamente lo que llamamos “ mandatorio”. Imaginemos nuevamente la ENTIDAD-A, pero ahora con mandatorio, con políticas definidas e impuestas por igual a todos: en este entorno, si viene el presidente y pide que se cese un funcionario, se le responde que el único que puede hacer esa tarea es el secretario y que deberá seguir un procedimiento. En un ambiente de políticas, cuanto recibes un reclamo del gerente le respondes que tu procesas los reclamos recibidos mediante tickets y que debes recibir uno para que puedas ayudarlo. Así estarás aplicando políticas; y claro que no impide que tu mismo le escribas el ticket por el gerente para ayudarlo a tener una solución más rápida, pero también podrías hacerlo para cualquier otro compañero. Las políticas mandatorias que se aplican por encima de las personalidades, de los cargos y a nivel informático son impuestas por el kernel y nadie escapa de ellas. Esto es lo que hace SELinux, implementa políticas que estarán por encima de los s y del . EL proyecto Security Enhanced Linux fue iniciado y desarrollado por la Agencia de Seguridad Nacional de los Estados Unidos de América, la famosa NSA, allá por diciembre del año 2000. Es la implementación de una arquitectura del sistema de seguridad de GNU/Linux con una configuración basada en políticas que se conoce como Flux Advanced Security Kernel o FLASK. A SELinux se lo puede entender como una capa adicional de seguridad que nos permite imponer políticas por encima del simple rwx o el sudo. SELinux es parte del kernel Linux y utiliza la interfaz Linux Security Module (LSM) para colocarse entre la interacción de los procesos (en espacio de ) y los recursos. istra varios s, como ser leer archivos, obtener atributos de un directorio, conectarse a unix sockets, abrir o conectarse a T sockets y hasta la ejecución de ciertas capacidades de una aplicación, todo mediante un proceso de imposición de políticas. Veamos como funciona: Cuando tenemos una aplicación (por ejemplo, el servidor nginx) que está corriendo como un determinado (en este ejemplo sería www-data), y quiere realizar una determinada acción sobre un recurso (por ejemplo, leer la carpeta /tmp) esta acción será primero revisada por el sistema de discrecional y, todos sabemos, que la carpeta /tmp tiene de lectura para todos los s, por lo cual se concede el y ahi la implementación de LSM llama a SELinux para que revise la política y retorne si el es permitido o no y, ya te adelanto que este no es permitido en las políticas por defecto, por lo que nginx no podrá leer el /tmp a menos que se hagan configuraciones específicas. Lo mismo pasa si configuras el servidor OpenSSH para que escuche en el puerto 2222, cuando lo re-inicies SELinux en la configuración por defecto, se encargará de negarle el a ese puerto, pues el puerto 2222 no es el que determinan las políticas para el servicio OpenSSH. Y las políticas de SELinux llegan hasta opciones propias de las aplicaciones. Por ejemplo, si configuras tu servidor FTP para que acepte s anónimos, algo que se hace habilitando algunas opciones en el archivo de configuración, SELinux por defecto no dejará que los s anónimos ingresen; y no importa cuán root tu seas, ni cuán prolijamente lo habilitaste en el archivo de configuración, la política que los s anónimos no ingresan será lo que se aplicará. Esas políticas se aplican a todos los s, a todos los procesos y a todos los recursos Ahora que mas o menos tenemos una idea de por donde viene SELinux tenemos que entender cómo lo hace y como nosotros podemos actuar para adecuar estas políticas a nuestra realidad, es decir, re-pactar esas políticas. Pero esto tenemos tiempo de verlo en futuras ediciones de deployándome. 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.

27 – Docker Swarm Te doy la bienvenida al episodio 27 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 20 de marzo de 2018. Si recuerdas el episodio anterior de deployándome habíamos estado conversando en forma general sobre los cluster de docker y habíamos visto que permiten solucionar problemas de escalabilidad. Vimos que son útiles cuando tus aplicaciones o servicios tienen requisitos de disponibilidad continua y en caso de problemas necesitas recuperarte automáticamente. También los clusters, permiten adaptar en forma elástica el consumo de recursos de computación asignando mas recursos o liberándolos. En esta edición voy a concentrar las características del cluster nativo de Docker; vamos a estar viendo Docker Swarm: que podemos definir como la manera de tener varios Docker Engine corriendo como un enjambre. Decir que Docker Swarm es nativo en Docker tiene una doble implicancia: Por un lado significa que no se debe instalar nada más que docker (y me refiero al daemon Docker Engine y su cliente docker) para poder armar un cluster, es decir que Docker Swarm está integrado en Docker que ya tienes instalado. Y, por el otro lado, significa que es muy fácil de implementar, pues el trabajo de instalarlo es exactamente el mismo que instalar Docker en varias máquinas. Lo que vamos a tener son Docker Engine que asumen distintos roles y esos roles son dos: manager y worker. Los worker solamente levantarán dockers con mi aplicación y los manager también lo harán, pero además se encargarán de los servicios del propio cluster. Además de estas dos características, Docker Swarm tiene una serie de funciones automáticas, de las cuales te comento cinco de ellas: Primero, la reconciliación de estado, es decir que si mi servicio se basa en tener levantados, por ejemplo, cinco réplicas de contenedores balanceados y por algún motivo alguna se cae, Docker Swarm se dará cuenta del problema y se encargará de recuperar el estado deseado de mi servicio sin que necesite tomar ninguna acción. Pero la reconciliación del estado no se queda solo en el servicio o mi aplicación. Si por algún motivo el nodo con el rol de manager activo se cae otro nodo con el rol manager tomará su lugar y se volverá activo, si es que configuramos más de un manager dentro del cluster (algo recomendado en ambientes de producción) Segundo el descubrimiento de los servicios. ¿qué quiere decir esto? supongamos que tengo un cluster formado por diez computadores (o máquinas virtuales) cada una de ellas corriendo Docker Swarm y cuando levanto mi servicio digo que debe tener cinco réplicas corriendo, cada una ira a levantarse en alguno de los nodos, sin un orden y será tarea del manager activo registrar en qué nodos se levantó cada réplica de mi servicio, para conducir las peticiones de los clientes hasta la aplicación. Obviamente podemos definir políticas de afinidad para que una aplicación vaya al nodo o grupo de nodos que deseo. En tercer lugar Docker Swarm hará una magia interesante a nivel de red para que mi servicio que puede requerir multiples dockers pueda funcionar como siempre, es decir, como si estuviera en una sola máquina. A ver si me explico: Supongamos que levantamos WordPress: tendremos un docker para el servidor web, digamos nginx, otro para el PHP con php-fpm y otro para la base de datos MySQL, cada uno de estos docker tendrá con la directiva EXPOSE configurado el puerto que escucha su servicio y se vinculará con la directiva LINK desde el docker que consume los servicios. Hasta aquí algo que hacemos con cualquier WordPress que levantamos en docker. Cuando lo llevamos a un cluster Docker Swarm esto se complica, pues podemos configurar que tendremos solo una réplica para el MySQL que se levanta en algun nodo, digamos el nodo 1; tres réplicas de PHP que se levantará en los nodos 2, 3 y 4 y dos réplicas del web de nginx que se levantaran en los nodos 3 y 5. ¿empezas a ver donde está la magia? En este ejemplo Docker Swarm se encargará de presentar el puerto EXPOSE 3306 del docker MySQL que corre en el nodo 1 como localhost:3306 en los docker de PHP que están corriendo en los nodos 2, 3 y 4 y yo no tendré nada más que hacer lo que siempre he hecho, usar la directiva LINK. Y si los docker cambian de nodo, por reconciliación o por el motivo que sea, Docker Swarm se encargará de gestionar el tráfico interno de red para que los docker se comuniquen como si estuvieran en la misma máquina. ¿te estarás preguntando si esto funciona con VOLUMES? Y no, Docker Swarm para un storage entre varios docker requiere un servicio de storage independiente al cluster. A mi modo de ver un manejo externo del storage compartido no es muy diferente a lo que requiere un servicio de cloud con múltiples instancias. Pero sigamos con las funcionalidades de Docker Swarm: Estamos en el cuarto punto, Docker Swarm se encargará balancear automáticamente las peticiones de los clientes hacia todas las instancias docker repartidas en el cluster que se encargan de nuestro servicio. Y, por último como quinto punto, Docker Swarm se encargará de gestionar los procesos de actualización de nuestros aplicaciones, siempre manteniendo el servicio activo mientras va reemplazando uno a uno los contenedores con la nueva versión cuando se deba actualizar. ¿te gusta? pongámos a correr nuestro cluster Docker Swarm y luego me cuentas. Para empezar necesitamos un conjunto de máquinas corriendo Docker Engine. La forma más fácil que conozco es con la utilidad docker-machine que también viene nativa con Docker. Docker Machine es una herramienta que nos permite levantar y istrar máquinas virtuales con docker sobre hypervisores Oracle Virtualbox o Microsoft Hyper-V tanto en forma local como en nuestro propio datacenter y también en instancias en las nubes de Amazón, Digitalocean o Azure. Además docker-machine nos va ayudar istrar nuestro conjunto de máquinas ya sea para ingresar a alguna de ellas por ssh o para configurar el entorno de nuestro cliente docker local para utilizar el cluster swarm que levantemos. Así que con docker-machine create vamos a ir levantando una a una las máquinas de soportarán nuestro cluster, las que necesitemos: yo con cinco máquinas me conformo para estas pruebas y con docker-machine ls podemos listar las máquinas que se han creado. #!/bin/bash docker-machine create --driver virtualbox manager1 docker-machine create --driver virtualbox manager2 docker-machine create --driver virtualbox worker1 docker-machine create --driver virtualbox worker2 docker-machine create --driver virtualbox worker3 echo echo sleep 5 docker-machine ls A conjunto de máquinas necesitamos configurarlas en un cluster swarm. Para ello necesitamos ingresar a cada una de las máquinas con docker-machine ssh y ejecutar unos comandos de docker siguiendo estos cuatro pasos: Primero: ingresar en el nodo manager y ejecutar docker swarm init para iniciar nuestro cluster y que nos va a devolver un comando docker swarm con un token. Segundo: ingresar en cada uno de los nodos que serán worker y pegar ese comando de docker swarm con el token para unirlos al cluster. Tercero: nuevamente en el nodo manager ejecutamos docker swarm -token manager que nos devolverá otro comando docker swarm pero ahora con el token para unir nodos managers. Y cuarto: ingresar a los otros nodos manager y ejecutar docker swarm pero con el token de manager. Con esto tendremos nuestro cluster Docker Swarm con manager activo, managers no-activos y workers armado. ¿fácil, no? Para poder istrarlo con nuestro docker local corremos docker-machine env que nos devolverá el entorno que debemos configurar localmente y ahora sí podemos ejecutar comandos como docker node ls para consultar el estado de nuestro cluster. Si has conseguido seguir mi explicación, te resultará muy simple. ¿cómo levantamos una aplicación en nuestro cluster? Tiene algunas “pisadas”, pero es casi lo mismo que levantar una aplicación docker común y corriente, es decir, podemos usar tanto el comando docker como docker-compose. Debemos recordar que si vamos a basarnos en una imágen esa imagen debe estar accesible en un repositorio al que todos los nodos puedan llegar ya que será cada nodo el que descargue y levante la imagen. Suelo hacer docker push contra repositorios en Amazon Elastic Container Registry, pero perfectamente puedes usar docker hub o un Registry dentro de tu datacenter. Ahora docker no va a levantar un contenedor, sino que lo que levantará es un servicio con el comando docker service create y como parámetro el número de réplicas que queremos que mantenga el cluster. Y ya está! podemos ejecutar docker service ls reiteradas veces para ver como el cluster va levantando de a una las replicas del servicio que le he pedido hasta llegar al estado deseado. En un ambiente de pruebas quedan muchas cosas divertidas por hacer: apagar algunos nodos worker para ver como nuestro servicio se re-establece apagar el manager activo, para ver como el otro manager toma su lugar cambiar la cantidad de replicas deseadas de un servicio actualizar la imagen de nuestra aplicación y correr docker service update para ver como Docker Swarm realiza el recambio de los docker por la última version. y de seguro se te ocurrirán más cosas, pues te confieso que esto tiene tela para rato. Por ejemplo, puedes orquestar un servicio multi-container con docker-compose, pero si además usas archivos yaml de docker-compose version 3, puedes usar la funcionalidad de docker-compose ya nativa del comando docker con docker deploy. Te invito a que busques alguna imagen docker con un servicio para probar o te crees una tuya propia, utilices docker-machine para levantar varias máquinas virtuales y armes tu cluster Docker Swarm. 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.

Te doy la bienvenida al episodio 26 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 20 de febrero de 2018. Cuando hablamos de un cluster en informática nos referimos a un conjunto de computadoras que se les ha asignado una tarea común;  de esta forma podemos llegar a percibir que se trata de una única computadora o una única unidad que desempeña la tarea. Estos conjuntos de computadoras en cluster se suelen armar por dos motivos: el primero es dar condiciones de disponibilidad, es decir, que ante la falla de algún componente del cluster, el servicio o la aplicación siga corriendo. el segundo es para mejorar el rendimiento, puede ser o para acortar el tiempo de los procesos,  porque se reparte una tarea grande entre varios del cluster o para atender una mayor demanda, porque se balancea entre los La necesidad de un cluster está fundada en estos dos conceptos de disponibilidad y rendimiento. Si tu aplicación puede estar apagada algunos minutos sin que provoque mayor molestia, o tus procesos y aplicaciones funcionan adecuadamente en tiempos “normales”, entonces eres de la mayoría que no necesitas un cluster. Disponer de un cluster no es un tema de élite o de tamaño de empresa, es una tecnología enfocada a resolver estos problemas y no vale la pena el esfuerzo de tener un cluster si no tienes el problema a resolver. En este episodio de deployándome vamos a abordar tema de correr nuestra aplicación docker en un cluster. Me refiero tu  servicio o api, corriendo en contenedor docker, que está mantenido entre varias computadoras. Para entender el tema, creo que nos conviene repasar desde lo simple hasta lo complejo. En un computador o servidor se pone a correr el servicio Docker Engine que es una tecnología de software libre que permite armar y mantener contenedores corriendo. Docker Engine junto con Docker Registry, el servicio de repositorio de imágenes de contenedores, permiten armar un flujo de trabajo para crear y poner en contenedores las aplicaciones. Sabemos que con contenedores docker (me refiero a un Docker Engine y un Docker Registry) tenemos solucionadas algunas cosas y se nos facilitan otras, veámoslo: El despliegue de nuestra aplicación. Ejecutamos `docker run` y la imágen y tendremos esa imagen copiada desde el Docker Registry corriendo como contenedor activo en el Docker Engine. La actualización de esa aplicación y el mantenimiento de versiones, creando nuevas imágenes del contenedor con `docker build` y eventualmente subiéndolo a un Docker Registry central con `docker push` La creación de ambientes de desarrollo, testing, producción y la posibilidad de que esos ambientes sean iguales. El uso de herramientas de continuous integration y continuous deployment para automatizar el flujo de trabajo con nuestras aplicaciones. Y todo esto solamente por usar Docker, es decir, esto es lo más simple de la infraestructura docker, te lo repito un Docker Engine y un Docker Registry. Podemos entender esto como la solución base y general para la mayoría de las aplicaciones y los servicios que pueden correr en nuestros servidores. ¿pero qué pasa cuando necesito escalar por una mayor demanda de mi aplicación? Es decir cuando enfrentamos un problema de escalabilidad. Docker Engine y Docker Registry por si solos no me solucionan el problema de escalabilidad, pero podemos hacer el método digamos simple: ponemos a correr muchos Docker Engine, cada uno en un servidor o computador distinto y cargamos una copia de nuestra contenedor con la aplicación en cada uno de esos Docker Engine. Obviamente vamos a necesitar repartir a nuestros clientes entre todos esos docker engine, cosa que podemos hacer con un balanceador de tráfico, con un round-robin de DNS o con alguna otra metodología para que cada uno de los Docker Engine tenga la copia del contenedor con mi aplicación trabajando o brindando servicio. Entonces, podemos solucionar el problema de escalabilidad de esta forma rudimentaria, pero efectiva. Pero ya te estás dando cuenta que estaremos enfrentando nuevos problemas que requieren ajustes en esta infraestructura. Por ejemplo, qué sucede si alguno de esos computadores o servidores que tiene un Docker Engine, que corre una copia de nuestro con nuestro contenedor y nuestra aplicación falla, es decir, se ve afectada su disponibilidad.   ¿qué debemos hacer para mantener la calidad de servicio?   ¿cómo el sistema se restablece ante un problema de este tipo?  Y aquí hablamos de la resiliencia. Pero además, que pasa si nuestro grupo de computadores son, por ejemplo diez.  ¿corremos todas nuestros contenedores diez veces, uno en cada Docker Engine?  ¿no habrá alguna aplicación que perfectamente puede trabajar con dos copias? Y ¿qué pasa si tenemos una aplicación que solo dos veces al año requiere las diez copias, pero el resto del tiempo perfectamente puede estar ejecutado una sola vez?  (como puede ser un sistema de inscripción para un colegio) Y aquí me refiero a un tercer problema: la elasticidad.   Que podamos tener dos contenedores con nuestra aplicación y que aumente a diez cuando requiera satisfacer la demanda y vuelva a bajar a dos cuando entre en una etapa ociosa. Entonces nuestra infraestructura de varios Docker Engine balanceados ya no funciona bien cuando agrego necesidades de disponitilidad, resiliencia y elasticidad. Aquí es donde un cluster me soluciona estas cuatro características, las tres que acabamos de nombrar y la escalabilidad, todo en forma automática y nativa. Existen varias posibilidades para tener un cluster para correr contenedores Docker. Una de las más maduras es Kubernetes, una implementación de software libre para automatizar el despliegue, escala y istración de aplicaciones en contenedores.  Originalmente fue diseñado por Google y actualmente es mantenido por la Cloud Native Computing Foundation. Otra implementación es Docker Swarm, que es una de las formas más simples de tener un cluster de docker.  Se trata de una funcionalidad del propio Docker Engine que permite armar un cluster.    Desde el punto de vista del para usar docker swarm es el mismo comando docker con la opción service . Otra opción es tener un cluster que corre Apache Mesos, una implementación de software libre que permite crear y istrar clusters. También se puede tener un cluster de docker en servicios de nube como ser Amazon ECS (Elastic Container Services) o Azure Container Services. En futuras ediciones de deployándome pienso abordar alguna de estas implementaciones, pero creo que por ahora te vas haciendo una idea de cuándo y cómo se justifica un cluster para correr tus aplicaciones en contenedores. 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.

Te doy la bienvenida al episodio 25 de deployandome, el podcast de tecnología para syss 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 istrando. 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 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 es 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 s 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 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.

Bienvenidos al episodio 24 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 9 de enero de 2018. Un viejo amigo me dijo hace mucho tiempo, “después que se aprende a usar el martillo todos los problemas se solucionan con clavos“. Y ese es precisamente uno de los problemas que he enfrentado cuando me acerqué al Cloud Computing, era un experto en martillo y mi primer acercamiento fue con un clavo por delante y después de muchos errores, de enfrentarme a pre-conceptos, de sentirme incómodo y de notar que las cosas no fluían ni quedaban como quería me he dado cuenta que en Cloud Computing hay que dejar el clavo y el martillo de lado, y apropiarse de la tecnología para usarla en forma correcta. Es decir, con cloud computing no solo nos enfrentamos a una nueva herramienta sino que también a una nueva metodología de trabajo y hay que hacer un cambio de enfoque, un cambio de la forma que concebimos las cosas. A mi no me fue fácil y les confieso que aún tengo algún problema, pues me considero experto en el martillo y el clavo. Entonces, en este primer podcast de 2018 te voy a contar sobre “infraestructura inmutable”, un concepto que me ha ayudado mucho a hacer el cambio de mentalidad para entender y sentirme más cómodo con cloud computing. Veamos el tema de una forma más concreta: ¿No te ha pasado de sentirte incómodo con el hecho que si terminas una instancia todo tu disco desaparece? ¿esto no te hace sentir que estás armando tus servidores sobre una cama de huevos? Originalmente este fue una de mis mayores incomodidades en Cloud Computing, como que sentía todo es esfímero y solo se podía sobrevivir con una política estricta de respaldos, imágenes y snapshots. (por las dudas….) ¿Y no te pone nervioso saber que si tu instancia se reinicia puede tomar una IP distinta? Justamente aquello que siempre fue la manera segura de llegar a un equipo, su dirección IP, en Cloud Computing es tan esfímero como sus discos. Tus aplicaciones pueden dejar de funcionar luego de un reboot si te basas en estas IP. (hoy en día me encuentro con gente que esto no lo sabe… y ahí corre todo producción con esas IP que cambian harcodeadas) Y claro que he leído sobre la importancia de pensar las aplicaciones con escalabilidad horizontal o sobre las ventajas de la elasticidad y el uso de los recursos a demanda, pero estaba apegado al viejo paradigma que se llama “infraestructura mutable” (digamos al martillo y al clavo) y desde ahí, todo esto me resultaba más anecdótico que práctico. Y entonces, como te decía, fue recién cuando hice propio el concepto de “infraestructura inmutable” que di el “click” y todo se volvió más lógico y natural. Los conceptos anecdóticos se convirtieron en fantásticos features que potencian mi trabajo. Te decía que la forma tradicional de relacionarnos con nuestra infraestructura la llamamos “infraestructura mutable”; mientras que la forma nueva, impulsada por las tecnologías emergentes como Cloud Computing, Contenedores o directamente el As A Service la llamamos “infraestructura inmutable”. ¿y qué caracteriza a cada una de estos dos abordajes de la la infraestructura? La documentación sobre infraestructura mutable es casi unánime al definirla como aquella que accedemos a los servidores por ssh para ajustes, cambios y actualizaciones. Esto así es la característica esencial de toda una forma de pensar y posicionarse frente a la infraestructura que vamos a mantener y, podemos decir, que es lo que siempre hemos hecho. Es decir, tenemos una máquina (real o virtual), a la que le instalamos el sistema base, le hacemos las configuraciones de seguridad, de requisitos y servicios necesarios para dejarla lista para recibir la aplicación o aplicaciones, a partir de ahí la mantenemos con mejoras, actualizaciones y cambios que sean necesarios (accediendo por SSH) y, eventualmente agregamos o desinstalamos aplicaciones que corren en ella a lo largo de su vida útil. Por esto, se llama infraestructura mutable, pues va cambiando a lo largo de su vida útil de la infraestructura. Por esto hay toda una suerte de conceptos y tareas que son afines y normales a la infraestructura mutable: hacer backup periódicos de cada servidor, o snapshots, o imágenes, pues el backup anterior no tiene la información que hemos cambiado nosotros mismos. el sentido de estabilización o equilibrio de un servidor, aquello que solemos definir con la frase “si funciona, no lo toques”, pues justamente nuestra tarea definir y ponderar cuándo es necesario tocar un servidor. la alta disponibilidad por master slave o activo pasivo, pues justamente nuestra infraestructura es muy estática la escalabilidad vertical, agregando recursos de hardware para satisfacer los picos de consumo y la documetación… continuamente desajustada con la realidad, detrás de la que todos corremos, pues nuestros servidores siempre tienen algo que no está documentado (que generalmente insertamos nosotros mismos) solo por nombrar alguna de las cosas que todos conocemos y que son afin justamente a esta forma de mantener infraestructura mutable, desde que nacen sus componentes, los ayudamos a crecer, maduran y son desafectados algun dia, pero mientras tanto son como nuestros hijos con nombre propio, como “zeus”, “mickey” o “bond” y nos sentimos orgullosos de sus uptimes. Y es adrede que acabo de comparar nuestros los servidores con seres vivos que criamos como hijos, pues justamente para entender el concepto de “infraestuctura inmutable” es precisamente la forma que tienen los sistemas biológicos de crecer, de recuperarse ante traumas o de mejorar su cuerpo y es mediante lo que se denomina “computacion natural” Nosotros como seres humanos no crecemos haciendo cada vez mejor y más fuerte nuestras células, no Señor. Nosotros crecemos, maduramos, mantenemos nuestros sistema inmune, nos recuperamos ante enfermedades o traumas físicos directamente destruyendo componentes y reemplazándolos por nuevos que no tienen los problemas de los anteriores. Eso es precisamente computación inmutable: los componentes de nuestra infraestructura no se mejoran o se arreglan, no se modifican. Lo que se hacemos es reemplazarlos con nuevos componentes que incorporan los arreglos o mejoras. Una vez que hemos reemplazado los componentes y todo funciona de acuerdo a los requerimientos del sistema, descartamos los componentes obsoletos. Este reemplazo y destrucción de componentes se hace con algo tan relevante como un cambio de versión de la aplicación o la actualización del sistema, hasta con algo tan simple como actualizar un certificado digital o crear un nuevo. Entonces con infraestructura inmutable también hay un conjunto de conceptos que le son afines, como ser: automatización: este reemplazo de servidores enteros no se puede hacer si no es en forma automática, necesitamos de herramientas que utilicen el API de nuestro proveedor de cloud computing para pedir nuevos componentes, que luego se encarguen de todo el aprovisionamiento de configuración, de la instalación de la aplicación y del proceso de reemplazo y descarte. infraestructura como código: las herramientas de automatización tendrán datos completos de cómo es el estado actual de nuestra infraestructura, será nuestra documentación que obviamente podremos tener gestionada por un sistema de control de versiones. escalabilidad horizontal: una vez automatizado levantar un servidor o levantar cien, es cuestión de una variable, por lo que es lógico esta forma de gestionar nuestra alta disponibilidad. elasticidad: si tenemos automatizada la creación de nuestros servidores de cero al estado de producción con las ultimas mejoras, perfectamente podemos tener algo que esté monitoreando la carga y levante más recursos en forma automática si se requieren, o apague recursos si ya no son necesarios. (si si… como la cantidad de glóbulos blancos reaccionando ante una infección) ¿y nuestro querido ssh? ….. y nada, es lo que usamos para mantener nuestras infraestructuras mutables, de las cuales casi todos igual seguimos manteniendo. Y si me apuras y me preguntás cómo me va con esto de la infraestructura inmutable, te tengo que confesar que no es un camino de rosas ni un tobogán a la felicidad. A mi me está resultando un trabajo de hormiga donde debo negociar con gente que tiene sistemas de virtualización y los trata bien bien mutablemente y así se sienten seguros y conformes. O también con desarrolladores que cuando entienden el concepto parece que no les aporta nada e insisten en pasar a producción la nueva versión de la aplicación, mediante un script ejecutado por SSH. De todas formas, como te decía al principio del podcast, el concepto de “infraestructura inmutable” y también el de “computación natural” me han ayudado a entender mejor las características de cloud computing y a hacer propio esas cosas que otros flacos escriben en libros y hablan en conferencias. Soy Rodolfo Pilas, en twitter me puedes segir 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.

Bienvenidos al episodio 23 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 21 de noviembre de 2017. Con este episodio abro una nueva serie de podcast. Como ya hice en otros episodios que los junté en series, por ejemplo de OpenSSH o sobre el Correo Electrónico, este podcast es el primero de los dedicados a Docker. Y no tengo un interés en particular de empezar a contarte lo que es Docker, ni tampoco explicar las diferencias entre contenedores y virtualización. No, esa temática estará implícita a lo largo de las ediciones que hable sobre docker. Si tu necesitas entenderlo o refrescar los conocimientos básicos de Docker en Internes hay Gigas de información en nuestro idioma sobre los contenedores y sobre docker en particular. Por eso, hoy abro la serie de podcast de Docker, pero dedicados a aquellas herramientas o software que conozco que ha llamado mi atención. Y en este episodio 23, te voy a contar de un verdadero porta-contenedores. A ver si me explico, con una analogía de los contenedores marítimos, que todos tenemos una idea de lo que son, o sea esas cajas metálicas que se usan para transportar mercaderías en barcos, aviones o medios de transporte de carga. A nivel de barcos para llevar contenedores se utilizan unos navíos diseñados y construidos especialmente para llevar contenedores, es decir barcos cuya estructura está pensada para optimizar la relación entre la carga y la gestión de los recursos, es decir, el transporte. A esos barcos los conocemos como porta-contenedores. Ahora imaginemos a nuestro kernel Linux levantando contenedores docker como si fuera un barco para transportar contenedores. Una distribución estándar, diseñada para ser un servidor o desktop, podrá cargar contenedores sin problemas, pero a la hora de cargar contenedores en serio… me refiero a que nuestro servidor esté 100% dedicado a contenedores ¿una distribución estándar para servidor, ¿es lo podemos tener? ¿podemos diseñar y construir una distribución destinada a optimizar la relación entre carga de contenedores y gestión de recursos? Como si fuera uno de esos barcos porta-contenedores enormes cuando está lleno y diminuto cuando está vacío que solemos ver en nuestros puertos.. Y la respuesta es SI, podemos crear una distribución de GNU/Linux pensada para la carga de contenedores docker. Y una de esas distribuciones es RancherOS. Como te comentaba, RancherOS es una distribución de GNU/Linux diseñada para correr contenedores docker. No es la única, otras son CoreOS, Redhat Project Atomic o Ubuntu Core OS, pero entones ¿cuál es la diferencia de RancherOS? pues que lleva el concepto de porta-contenedor al extremo. Y seguro te preguntarás qué quiere decir llevar el concepto de porta-contenedor al extremo en una distribución GNU/Linux. En proceso de booteo cuando el kernel finaliza su arranque, con el scheduler tomando control del sistema para proveer la multi-tarea comienza el proceso de init. En una distribución estándar hablamos que se arranca el PID 1 que es systemd. Pero en RancherOS el PID 1 es docker daemon y a partir de allí lo que podemos hacer es correr contenedores docker. Decimelo vos, ¿esto ya no parece fantástico? Kernel, Docker y a cargar contenedores. Seguramente te estarás preguntando qué pasa con todos esos servicios que require un sistema GNU/Linux para correr. Cosas tan básicas como udev para tener dispositivos en espacio de , o network, o aid, o directamente console para tener un , o syslog, cron. Es decir, esos servicios que solemos darle restart con systemctl cuando actualizamos o configuramos. Pues los arquitectos de RancherOS han cargado estos servicios como contenedores, un contenedor por cada uno. Un RancherOS recién iniciado, es un kernel cuyo init es docker daemon y luego arrancan una serie de contenedores para cada uno de los servicios básicos del sistema. Y esto en RancherOS constituye una primer instalación de docker, que se denomina system-docker. System-docker es un docker engine para esta función de mantener los servicios básicos, con su propio docker registry y que se definen docker-compose y se configuran mediante cloud-init. Si, si, el mismo cloud-init que se utiliza para configurar instancias en cloud computing. Te confieso que la primera vez que vi esto y comencé a entender cómo estaba construida esta distribución sentí la misma emoción que allá por los 90 del siglo pasado sentí cuando empecé a ver por primera vez GNU/Linux, así con la mochila vacía por la ignorancia y el afán de descubrir cosas. En RancherOS no solo usas docker, sino que todo es docker. Si quiere agregar a tu sistema base, por ejemplo, un agente de monitoreo como zabbix tendrás que construir una imagen con Dockerfile y la tendrás que poner a correr con system-docker run. Si quieres modificar el comportamiento de un servicio que está corriendo se dispone de un utilitario llamado `ros`, por ejemplo para modificar el `/etc/resolv.conf` del contenedor de sistema network. ros también se usa para generar conocer cómo está configurado un servicio en el contenedor y para ayudarte a crear los archivos yaml de cloud-init. “¿querías docker? dos platos” Y el segundo plato de docker es precisamente docker común, el que puede estar delegado a nivel de s. En RancherOS se le llama “ docker”, para diferenciarlo del system-docker. Docker para nosotros es el comando docker de siempre. Tiene su obviamente docker registry y es lo que podemos definir como la “carga útil” del porta contenedor. Si seguimos la analogía de porta-contenedores marítimo, una vez que aseguramos los servicios para la tripulación y el barco en si mismo, lo que podemos hacer es empezar a cargar contenedores… como que en un porta-contenedores no hay mucho más para hacer, bueno, si podríamos tomar sol en su cubierta, pero seguramente hay lugares más interesantes donde hacerlo. RancherOS se define como un distribución para correr containers en niveles de desarrollo, testing o producción. Donde los servicios del sistema se presentan en contenedores, reduciendo la carga de istración. Las librerías y los servicios extra han sido eliminados lo que resulta en sistema base muy reducido, simple de actualizar, aplicar parches y mantener. Se pueden dar cuenta las ventajas de esta arquitectura de armado de distribución ya que la lógica de contenedores se aplica desde el vamos: monitorear un proceso, es monitorear un contenedor; automatizar la configuración de un servicio, es automatizar el deploy de un contenedor. ¿y cómo lo instalamos? Empezando como cualquier otra distribución de GNU/Linux: a partir de un .ISO de 59MB, de un dump para RaspberryPI de 87MB o de una imagen para máquina virtual, que las hay en Amazon, DigitalOcean, Openstack, Azure. Antes de usarlo en producción y para pruebas yo lo levanto con docker-machine en una máquina virtual Virtualbox, directamente del ISO, como explica la Guía Rápida de instalación. Fíjate que con ese tamaño puedes arrancarlo desde un USB y utilizar todo el espacio de disco de tus servidores para volúmenes de tus contenedores docker. ¿y hasta donde podemos llegar con RancherOS? Pues RancherOS es una excelente plataforma para soluciones de cluster. Podemos subir kubernetes en containers, cargando en cada nodo del cluster los servicios de kubernetes necesarios para las funciones de Master o Minion, dejando la plataforma para los contenedores de carga útil. Equivalente podemos hacer con un cluster docker-swarm. Si te has entusiasmado con RancherOS como yo lo estoy, esta es solamente la punta del hilo, si recorres Github o Gitlab encontrarás una cantidad proyectos vinculados a RancherOS. Rancher Labs Inc, la empresa detrás de RancherOS, provee un de istración web de docker llamado Rancher (que se puede instalar independientemente de RancherOS) que se carga también como un contenedor más en RancherOS, dándote una plataforma para tus dockers, si! muchos click para tener tus docker corriendo, aunque también tiene su API. RancherOS es obviamente una distribución que utiliza software con diferentes licencias, pero su licencia principal es Apache 2.0, lo que nos asegura que podemos estudiarlo a fondo, modificarlo si tenemos necesidad y eventualmente compartir esas modificaciones. Soy Rodolfo Pilas, en twitter me siguen por @pilasguru y les dejo un saludo a todos, confiando en que este podcast les haya aportado para mejorar y, como siempre, espero sus inquietudes y sugerencias comentando en deployando.me Hasta la próxima edición.

Bienvenidos al episodio 22 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 7 de noviembre de 2017. Unas semanas atrás me invitaron a dar una charla interna en la empresa que trabajo, en esa oportunidad hablé de Docker Swarm, que es un tema que trataré seguramente en un próximo episodio de deployando.me, pero en este les voy a contar de mi experiencia con una herramienta que considero una hermosa pieza de software que utilicé en dicha presentación. Resulta que la presentación requería hacer algunos demos y cualquiera que haya hecho una presentación con un demo que Murphy suele hacerse presente en esos momentos. Es decir hay altas probabilidades que la demo falle en medio de la presentación. El mítico manual del presentador dice que se se deben evitar los demos en vivo durante las presentaciones. La solución que se sugiere son las famosas “capturas de pantalla”; pero, en los casos que no queda más remedio que hacer una presentación en vivo, el manual del presentador sugiere hacer algún chiste tipo disclaimer para preparar la audiencia para una eventual falla. En fin, hay que reconocer que los demos en las presentaciones son un stress adicional para el presentador y para la audiencia si es que algo no fluye como se espera. Entonces, como les decía, me proponía a hacer un demo en vivo como parte de mi presentación de Docker Swarm, pero además del stress del posible fallo, me enfrentaba a algunas tareas que insúmen un tiempo interesante. Y ahí fue que me acordé de una herramienta hermosa que conocí hace relativamente poco tiempo y que terminó siendo impresionantemente útil para este propósito de hacer un demo en vivo: me refiero a asciinema. Así que en este episodio de deployando.me me voy a tomar la libertad de desviarme del objetivo del podcast y en lugar de algo para sys y devops voy a hablar de esta este software que es para todos en general. Asciinema es una solución muy eficiente y liviana para capturar la sesión en la terminal. Permite grabar, tocar y compartir una grabación de la sesión de la terminal en formato JSON. Notaran que la mayor ventaja sobre otras alternativas para grabar la sesión como Recordmydesktop o VokoScreen es que Asciinema guarda todo el input, output y error en un archivo de texto plano ASCII y agrega las secuencia de escape ANSI en caso de necesitar representar colores o movimientos del cursor. Entonces el video de la captura de nuestra sesión es un archivo JSON minúsculo, que puede ser fácilmente compartido o guardado. Pero ademas, en el sitio asciinema.org se puede tener una cuenta donde la captura se publica automáticamente (si no se le indica un archivo local) y se obtiene una URL donde queda disponible nuestra sesión. También desde asciinema.org se puede obtener el código para embeber el video con un player directamente en tu sitio web. Esto a mi la primera vez que lo vi me provocó una exclamación de “pah”. Así que para el demo en mi presentación recurrí a asciinema y grabé en archivos locales JSON cada uno de los demos que iba a realizar, pero obviamente cometí errores: siempre algun teclazo errado se escapa, y edité con `vim` el archivo JSON, localicé las lineas con errores y las eliminé. Si, como lo has oido: edité el video con vim ! Y les comentaba que algunas partes del demo tomaban mucho tiempo ¿recuerdan? y también lo modifiqué: donde decía que el comando antes de ser mostrado esperaba 30 segundos, lo cambié por un valor menor según el que quería provocar. Pero además, algunas salidas de pantalla donde los procesos de creación de máquinas virtuales pasaban líneas y líneas de salida , dejé algunas y borré la mayoría, cambiándolas por algunas líneas con puntos suspensivos. El resultado: cero estrés en la presentación cero error ¿es un video, no? ajusté el tamaño de los caracteres de mi terminal y el demo fue presentado en la misma terminal manteniendo toda la configuración que tenía en ese momento la presentación acompañó mi didáctica de presentación en tiempos y lo que se mostró exactamente. Y al final compartí presentación, notas y videos (en archivos JSON) mediante un repositorio git, con quién lo quisiera clonar. Quedé muy conforme y por eso, si no conoces asciinema te invito a instalarla y probarla pues es un software que se debe instalar, está disponible como paquete en la mayoría de las distribuciones GNU/Linux, en MacOS se instala con brew. Pero si quieres puedes clonarte su repo Githab y compilarlo tu mismo. Con el comando `asciinema rec` se comienza a grabar y se finaliza con Ctrl-D. Como no le colocamos un nombre de archivo JSON para guardar, por defecto nos ofrecerá subirlo a asciinema.org. Les decía que yo edité los tiempos a mano para dar un parecido al real, pero acelerado. Si evitar los tiempos muertos, puedes grabar tu video con el parámetro `-w` y los segundos que deseas; entonces automáticamente puedes demorar lo que quieras entre comando y comando o tecla y tecla, que asciinema usará esos segundos como máximo de espera entre uno y otro. Creo que esto es ideal si damos comando pintando y pegando desde un editor en otra ventana. Si tienes el video (en archivo local o publicado en asciinema.org) puedes correrlo con `asciinema play` seguido del nombre del archivo JSON o la URL de tu video, y lo verás en tu propia terminal, como cuando lo grabaste. asciinema es un proyecto de software libre licenciado mediante GPL v3 y que comenzó a principios de 2011 por Marcin Kulik. El sitio web para compartir los videos abrió en Marzo de 2012 y actualmente tiene un desarrollo activo por una importante comunidad de desarrolladores. asciinema es un conjunto de varios sub-proyectos: el software de linea de comandos para grabar y reproducir videos el sitio web donde los videos se comparten el API por el cual los videos se publican y el player javascript que se ve en el sitio y se puede embeber desde otros lugares de internet. Soy Rodolfo Pilas, en twitter me siguen por @pilasguru y les dejo un saludo a todos, confiando en que este podcast les haya aportado para mejorar y, como siempre, espero sus inquietudes y sugerencias comentando en deployando.me Hasta la próxima edición. Referencias: Sitio oficial Repositorio Github

Bienvenidos al episodio 21 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 31 de octubre de 2017. Aproximádamente por estas semanas estoy viendo en mis cursos de la Universidad el tema del Storage en Cloud Computing, por lo que me pareció interesante dedicar el capítulo de hoy al storage, o sea guardar grandes cantidades de datos. Todos sabemos o tenemos una idea que cuando la cantidad de datos a guardar supera la capacidad de almacenamiento de nuestras computadoras debemos recurrir a soluciones al almacenamiento externo. Si el volumen de datos que vamos a guardar esta generado por varias personas o aplicaciones que a su vez, tienen el requisito de disponibilidad inmediata de esos datos, estamos hablando de un recurso de almacenamiento masivo y online. En estos casos se suele utilizar hardware dedicado especialmente destinado a storage. Estos hardware dedicados para storage, según como se utilizan y conectan se dividen en dos grupos principales: SAN o Storage Area Network Es cuando el espacio de almacenamiento se obtiene de una red dedicada que presenta unidades de disco como si fueran discos físicos. En estos casos los sistemas operativos ven discos locales pero están presentados a través de una red y son partes de un hardware externo. Es fácil darse cuenta cuando estamos ante una SAN, pues los comenzamos a utilizar con el comando fdisk, luego los formateamos con mkfs, para recién poderlos montar y usar su espacio. En SAN los permisos para a los archivos están gestionados por el sistema operativo que utiliza ese disco de red. NAS o Network Attached Storage En estos casos hablamos de una tecnología de almacenamiento por el cual se comparte espacio de disco a través de la red. Los sistemas operativos ven que aparece “espacio” para usar. También es fácil darse cuenta cuando estamos utilizando un NAS, pues comenzamos montando (mount) un disco de red compartido. En NAS los permisos para a los archivos están gestionados por el servidor que comparte su disco y no por el sistema operativo que lo utiliza. A estos dos sistemas tradicionales y muy utilizados como storage de red se agrega una tercer arquitectura de storage que es el almacenamiento de objetos u “Object Storage”. En estos casos, en lugar de referirnos a archivos, discos o bloques, hablamos de manejar los datos como objetos, que son guardados en forma desestructurada, lo que permite manejar cantidades masivas de datos. Es decir, simplemente mando a guardar archivos en ráfagas y por cada uno obtengo un puntero que luego me permite recuperar el archivo en caso de necesitarlo. Los datos guardados como objetos, facilitan algunas funciones como replicación, caching, balanceo en sistemas distribuidos, inclusive en distintas regiones geográficas. Los archivos en un object storage se gestionan a través de un API. Y entonces, como en Deployando.me siempre busco compartir algo que puedas implementarlo y probarlo en esta edición voy a contarte de CEPH Storage. Ceph es un software para gestionar un sistema de almacenamiento (storage) que permite utilizar hardware estándar y está diseñado para brindar una excelente performance, confiabilidad y alta escalabilidad. CEPH una vez levantado presta servicios de Block Storage, de Filesystem y de Object Storage y luego cada uno de los servidores o aplicaciones puede valerse de alguno de estas tres funcionalidades de storage, según sus necesidades. En concreto Ceph es un conjunto de daemons que se corren sobre el sistema GNU/Linux estándar y que permiten gestionar un cluster de storage. Es decir, con Ceph se puede comenzar con un storage de pocos nodos y hacerlo escalar para satisfacer las necesidades de almacenamiento y confiabilidad de toda una organización o de un prestador de servicios. Como CEPH es un Software Libre, este crecimiento no está atado a un licenciamiento que te persiga con límites de funcionalidad, recortes de servicios o de tamaño de tu instalación. Una vez que instalamos y ponemos a funcionar un claster Ceph, significa que tendremos en nuestra red un servicio al cual solicitarle la creación de discos que apeamos como un dispositivo en el /dev y a partir de ahí particionarlo y darle un formato para su uso. Si bien podemos utilizar estos discos para ampliar la cantidad de disco de nuestro GNU/Linux, generalmente serán utilizados por sistemas de cloud computing como Openstack o de virtualización como KVM. Cuando Ceph se utiliza como filesystem el uso ya puede ser más común en nuestra red la red y puede ser consumido por cualquiera que necesite filesystem. Para ello, Ceph nos permitirá gestionar llaves de que utilizaremos para montar el filesystem remoto. Pero, teniendo en cuenta la escalabilidad y el nivel de servicios logrado por el cluster, está recomendado para sistemas de cloud computing como Openstack. Como object storage Ceph es compatible con el API S3 de Amazon y puede ser utilizado también por Openstack Swift para sus servicios de cloud computing. Si fuera a resumir las características de Ceph empezaría por destacar que es Software Libre, con licencia LGPL v2.1 Que se trata de un storage definido por software lo que permite utilizar hardware diferente para atender distintas cargas de trabajo. Que se puede construir con hardware commodity, por lo que es fácil de evaluar y de implementar y se puede comenzar a probarlo ya. Que escala, que su arquitectura está pensada para alta eficiencia y soportar casos de borde, es decir está validado para nivel empresarial. Que se puede construir un storage distribuido que implementa protección de datos y alta disponibilidad nativa. ¿qué más decirles? Ceph existe gracias a la cooperación de una comunidad que incluye ingenieros e investigadores en almacenamiento. Que detrás de Ceph están empresas como RedHat, Canonical, SuSE, Fujitsu, Intel, SanDisk y ZTE entre otras. Claro Ceph no se trata de un software que uno instala a nivel hogareño, pues cuando se comienzan a apreciar las bondades nativas del cluster Ceph es cuando tenemos seis o más equipos funcionando como Storage. Pero podemos probarlo corriendo en una única máquina virtual: así lo hice yo la primera vez que lo utilicé, mis usos actuales son en instalaciones de OpenStack, tanto ofreciendo block storage para Cinder, object storage para Swift, o filesystem Manila. Si te has entusiasmado, en el 2015 escribí una guía de Comandos de Ceph con un acercamiento bien práctico para utilizar un cluster Ceph en sus distintas modalidades de storage. La idea es levantar una máquina virtual con Ceph per-instalado y utilizarlo desde otra máquina virtual. Esa guía la basé principalmente en el libro de Sage Weil titulado Learning Ceph, de la editorial Packt Publishing. Dejaré el enlace en el artículo del blog sobre este episodio. Por eso, les recuerdo que en el blog deployando.me siempre pongo la transcripción total del contenido del podcast, que también suelo acompañar con algún enlace o material extra. Soy Rodolfo Pilas, en twitter me siguen por @pilasguru y les dejo un saludo a todos, confiando en que este podcast les haya aportado para mejorar y, como siempre, espero sus inquietudes y sugerencias comentando en deployando.me Hasta la próxima edición. Referencias: Sitio oficial Ceph en RedHat Documentación oficial de Ceph Guía de comandos de Ceph

Bienvenidos al episodio 20 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 12 de septiembre de 2017. Todos nosotros que estamos trabajando con sistemas GNU/Linux y istramos servidores utilizamos SSH, casi que asumo que todos Ustedes, oyentes de este podcast lo utilizan. No es por nada que un 10% de las ediciones que llevo hechas de deployando.me fueron dedicadas a herramientas vinculadas a OpenSSH o a distintos usos de SSH. Y en esta edición voy a volver al tema de SSH para presentar MOSH una forma de más eficiente y con más prestaciones para tus conexiones SSH. … A ver, quiero que cada uno de Ustedes piense cuántas veces a tenido alguno de estos problemas al conectarse con sus servidores SSH: PROBLEMA 1: Si no tienes una buena conexión, cuando hay mucha pérdida de paquetes o cuándo la conexión está saturada, que el echo de lo que escribes tiene un lag importante y que debes esperar para confirmar los comandos. PROBLEMA 2: O que pediste hiciste un cat de un archivo de logs enorme y te das cuenta que eso demorará muchísimo en desplegarse en tu pantalla remota y comienzas a apretar Ctrl-C como poseído y sin embargo el buffer de datos esta lleno y el texto sigue pasando por tu pantalla sin que a las decenas de Ctrl-C has presionado les llega el turno de ser atendidas por el servidor. PROBLEMA 3: Tienes abiertas conexiones SSH con uno o varios servidores y cambias el Wifi de tu escritorio de un AP a otro, o cambias de Wifi a red tableada o viceversa, o te mueves dentro de la empresa y cambias de AP o pasas por una zona sin cobertura y cuando vas a ver tus conexiones SSH están todas congeladas, duras.   Que cierras la ventana y las vuelvas a conectar y ves que tu sesión anterior ahí sigue abierta y confías que algún día caducará por timeout. Estoy seguro que han vivido varias veces alguno de estos problemas, porque estos problemas son normales y responden a la forma en que OpenSSH y el cliente SSH se comunican. El tráfico del cliente OpenSSH con el servidor se establece mediante una conexión T al puerto 22 por defecto, lo que lleva a mantener un estado de CONNECT para el uso del servicio. Además cada letra que escribimos en nuestro computador viaja a través de esa conexión hasta el servidor que la recibe y devuelve el echo correspondiente que retorna hasta nuestro cliente que lo despliega en nuestra pantalla, es decir hay un ida y vuelta de datos por cada letra, una vez que estamos conectados. Pero también sabemos que el despliegue de texto en consola enlentece cualquier proceso que se quiera ejecutar y para mejorar la performance, es decir, que el proceso no tenga que esperar por que las letras se dibujen y fluyan por la pantalla,  existen buffers que reciben los datos que van a ser mostrados y permiten que el proceso finalice cuanto antes, a pesar de que el despliegue a pantalla no ha terminado.  Ahora, fíjense que si a esto le adicionamos que el el 100% de ese texto debe ser trasmitido por una conexión remota para desplegarlo en una consola remota, el la demora del proceso total será mayor Y esto es cómo funciona nuestro querido SSH provocando los problemas que les he planteado que a veces son un verdadero dolor en la entrepierna, mientras esperamos completar un comando, apretamos Ctrl-C como desesperados o resoplamos por tener que volver a levantar nuestras conexiones para seguir trabajando. Pero, para solucionar estos problemas y volver nuestro trabajo con SSH una maravilla existe MOSH, The Movile Shell. Arranco a comentarles que MOSH no es un nuevo daemon que hay que tener levantado. Tampoco debemos enfrentarnos a un nuevo sistema de validación. MOSH realiza una conexión y validación utilizando el servidor SSH, para levantar del lado del servidor la utilidad mosh-server, muy semejante a como hace rsync para sincronizar archivos con un servidor remoto. Entonces, tengo que tener instalado mosh tanto en el cliente como en el servidor.  En el cliente inicio la conexión con el comando mosh en lugar del comando ssh; con una sintaxis muy parecida: mosh @servidor El cliente mosh se va a conectar al servidor SSH utilizando toda la configuración de conexión y validación que utilizaría el cliente ssh; es decir, es una conexión ssh T al puerto 22. Una vez que la conexión se establece y se valida, va a ejecutar del lado del servidor mosh-server a nivel de , va a abrir el puerto UDP 60004 para comenzar el intercambio de todo el resto del tráfico mientras dura nuestra sesión. De esta forma, el uso de UDP permite que entre el cliente y servidor mosh se pueda definir una istración del flujo de paquetes propia. Entonces, cada paquete tiene un identificador incremental y tanto del servidor como el cliente arma su propia lista de paquetes conocidos y retransmiten si fuera necesario. Esta característica hace que el cliente pueda hacer roaming entre distintas IP, inclusive entre IPv4 e IPv6, volviendo a reconectar automáticamente.  Mientras que el servidor quedará esperando hasta que continúe el tráfico de paquetes. En términos prácticos, si lo usas desde un dispositivo móvil, como yo que lo uso desde el iPad, puedes conectar trabajar conectado, cerrar el iPad, trasladarte a otro local, volverlo a abrir y ahí seguirás conectado como si no te hubieras movido de lugar. ¿te gusta? Pero las ventajas de MOSH siguen: El cliente MOSH maneja su propio flujo de escritura que sincronizará con el servidor; es decir que cuando tu escribes una letra, esta letra será mostrada en tu pantalla inmediatamente por el propio cliente que verá cómo hacer llegar al servidor. Supongamos también que tu escribes realmente rápido y estás en con una conexión que tiene perdida de paquetes, tu no notarás que tus textos se trancan y escribirás fluidamente. En algún momento el texto se sincronizará con el servidor.  El servidor, por su parte hará lo mismo con la respuesta a la ejecución de tu comando, llegará a ti, como un diferencial de pantalla. Pero si en ese entorno regresas con las flechitas y cambias un caracter, MOSH solo trasmitirá el caracter cambiado y mosh-server se encargará de re-armar la línea del lado del servidor, para esperar tu enter. Y ¿cómo se resuelven los despliegues enormes de texto del lado del servidor?  ¿recuerdas? Esos que trancan tu pantalla por un rato con el cliente SSH. MOSH obviamente tratará de hacerte llegar el despliegue a tu pantalla, pero estará escuchando tus órdenes por teclado y, si recibe un Ctrl-C, lo trasmitirá al comando y dejará de sincronizar la pantalla aunque aún queden unos cientos de líneas que deban ser trasmitidas. ¿Parece muy básico no?  Pues es la idea que me enamoró de MOSH, es sencillo y corrige esos momentos incómodos que tenemos con OpenSSH cliente/servidor. El sitio web de MOSH cuyo enlace queda en el artículo de esta edición en el blog deployando.me lo resume como: Una aplicación de terminal remota que permite roaming, soporta conectividad intermitente y ofrece un echo local inteligente y edición de la linea para lo que escribe el . Mosh es un software libre licenciado mediante GPL v.3, creado originalmente por Keith Winstein en 2012. Está disponible para GNU/Linux, BSD, macOS, Solaris, Android, Chrome, and iOS. Les recuerdo que en el blog deployando.me siempre pongo la transcripción total del contenido del podcast, que también suelo ilustrar con algún enlace o material extra. Soy Rodolfo Pilas, en twitter me siguen por @pilasguru y les dejo un saludo a todos, confiando en que este podcast les haya aportado para mejorar y, como siempre, espero sus inquietudes y sugerencias comentando en deployando.me Hasta la próxima edición.

Bienvenidos al episodio 19 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 8 de agosto de 2017. En el podcast anterior inicié el tema de los es de Configuración y estoy sorprendido por la cantidad de comentarios, retweets y mensajes que me han hecho llegar. Muchas gracias a todos, me alegra cuando el tema que me apasiona también despierta interés en Ustedes. Les recuerdo que en el blog deployando.me siempre pongo la transcripción total del contenido del podcast, que también suelo ilustrar con algún enlace o material extra. Entrando en tema, en el episodio anterior había presentado qué es un de Configuración y les comentaba que se encarga del aprovisionamiento de los nuevos equipos, de la orquestación de un conjunto de equipos (reales o virtuales) o de todo un datacenter y, que todas estas tareas de istración se realizan en forma automática desde un lugar central, sin necesidad que el sys deba acceder a cada servidor para tareas de istración. Pero como todo en informática: hay una curva de aprendizaje, hay cambios de costumbres, hay nuevos desafíos y problemas que deben ser solucionados y me había quedado comprometido en analizar si ese esfuerzo por utilizar un de Configuración valía la pena, o es mejor seguir istrando nuestros servidores de la forma que siempre lo hemos hecho. Sin duda que todos nos hacemos una idea del rango superior e inferior de la aplicación de un de Configuración. Si tenemos un RasperyPI en nuestra casa, no vale la pena automatizar su instalación y, por otro lado, si debemos istrar 300 servidores, cualquier esfuerzo de automatización está justificado. Pero ¿que pasa en el medio? en la zona gris donde puede o no valer la pena el esfuerzo de aprender y utilizar un de Configuración. Por ejemplo, debemos encargarnos de 15 servidores y si los analizamos, casi todos están configurados distintos o son distintos servicios. La respuesta si vale o no la pena, la debe pensar cada uno de Ustedes como profesionales que son y conocedores del entorno y sus necesidades. Lo que puedo hacer es compartir qué experiencia o qué me ha dejado el uso durante algunos años (cada vez en forma más exclusiva) de es de Configuración para mis tareas de sys u operaciones. Así que estas son las ventajas de istrar nuestros servidores y equipos con un de Configuración: Una de las principales ventajas, y que para mi es suficiente para todo el esfuerzo, es tener descripta 100% de la configuración de mi servidor. Es decir que mi servidor en producción está constituido por una instalación del sistema básico más la aplicación de todas “estas” reglas. Fíjense en esta simple característica las consecuencias que tiene: Homogenizar la instalación: como consecuencia natural de configurar igual cosas equivalentes, tratando de reutilizar lo más posible lo que ya he hecho. Si se define que el servidor DNS que vamos a utilizar son los de Google, pues estar seguro que esa configuración es la que tienen todos los servidores. Evitar errores de configuración: que suceden cuando hay muchos servidores iguales y debemos instalarlos y mantenerlos de forma tradicional. Aquí el procedimiento de configuración va a estar automatizado y se va a aplicar siempre igual. Si es bueno tener disponible el paquete “unzip” estar seguro que ahi está instalado, y no cuando lo necesito darme cuenta que justo en este servidor no se instaló. Documentación real y actualizada: tengo la documentación ya hecha de cómo está mi servidor, confrontada imperativamente cada día contra mis servidores. Esa documentación queda entonces lista a la hora de hacer informes, análisis estadísticos o presentarla ante el auditor que necesite revisar y criticar las políticas o configuraciones los servidores o el centro de datos. Instalar rápidamente: poner a funcionar nuevos servidores en forma muy rápida y eficiente. Lo que puede llevar horas de forma manual, serán minutos en forma automatizada. Pero además, ante un desastre, poder volver a estado de producción en pocos minutos, debiendo solamente recuperar recuperar datos de los respaldos. Control de versiones: poder tener versiones de las configuraciones de mis servidores, simplemente guardando las reglas de de configuración en un git. Con todas las ventajas que esto significa de poder crear ramas de variaciones, políticas de revisión y hasta, por qué no, gestión de integración continua de los cambios que se aplican en los servidores. Replicar entornos: si escucharon los podcast 12, 13 y 14 de deployandome saben que Vagrant permite tener entornos para probar cosas corriendo en mi propia máquina (notebook). Pues puedo tomar las reglas del de configuración y levantar un entorno local que aplique esas mismas reglas, reproduciendo el entorno luego de un “vagrant up”. O, por qué no, replicar esos servidores en un entorno de nube tercerizada, para pruebas o para ciertos requisitos puntuales que deben ser satisfechos. A mi estas consecuencias naturales de usar un de configuración me convencieron hace tiempo y Vagrant me ha ayudado a modelar cada instalación. Creo que actualmente me resisto a instalar cosas a mano y, si lo hago, estoy en forma paralela generando las reglas para mi de configuración. No se si notaron, pero estas características que he detallado son independientes de la cantidad de servidores, de si son iguales o cada servidor tiene su propia configuración. Podría comentarles algunas cosas mas marketineras sobre los es de Configuración, como que es la tendencia moderna, que el mundo en el futuro de las operaciones con “Internet de las Cosas” y los micro servicios va a ser automatizado, que es una puerta para acercarse a la filosofía del DevOps, en fin podría seguir, pero creo las características reales que he mencionado justifican el esfuerzo de emprender este salto de conocimiento o cambio de costumbre o como Ustedes quieran llamar al hacer nuestro trabajo con un de Configuración. Soy Rodolfo Pilas, en twitter me siguen por @pilasguru y les dejo un saludo a todos, confiando en que este podcast les haya aportado para mejorar y, como siempre, espero sus inquietudes y sugerencias comentando en deployando.me Hasta la próxima edición.

Bienvenidos al episodio 18 de deployandome, el podcast de tecnología para syss y devops. Soy Rodolfo Pilas y estoy grabando el 2 de agosto de 2017. Hoy quiero comenzar a tratar uno de los temas claves de la istración moderna, también una de las principales tareas del DevOps, me refiero los “adiministrador de configuración: ¿qué es un de configuración? Para entenderlo, veamos primero cómo es la forma tradicional de istrar servidores. Lo hacemos entrando a ellos y haciendo los cambios necesarios: dar de alta s, agendar tareas repetitivas en el crontab, ajustar los parámetros de seguridad, actualizar, y todo lo demás. Las tareas repetidas se scriptean y esos scripts están en alguna carpeta de cada servidor para ayudarnos con esa istración. Y después de hacer cambios, a plasmarlos en algún sistema de documentación que convenga al equipo de istración. Esta forma tradicional de istración tiene muchos problemas: El más notorio es que es un sistema que no escala ¿cuántos servidores podemos mantener así? ¿diez? ¿veinte? ¿cincuenta? ¿cómo resolvemos la configuración de instancias o servidores en la nube, donde necesitamos disponer de nuevos servidores rápidamente? ¿hacemos imágenes en el sistema de virtualización y nos transformamos en mantenedores o es de imágenes, en lugar de servidores? Necesitamos automatizar. Necesitamos un software al cuál especificar nuestras necesidades de configuración y lo apliquen donde y cuando corresponda, a la cantidad de servidores que corresponda, en forma rápida y segura. Y el software que hace eso es, precisamente, el de Configuración. ¿qué hace el de configuración para mantener nuestra infraestructura? Aprovisionamiento (provisioning): todos los pasos que damos a nivel de instalación y configuración inmediatamente luego de terminar de instalar un sistema operativo básico para llevarlo a un nivel de “listo para usar”. El aprovisionamiento involucra los software adicional, los s, los permisos, los servicios, las configuraciones de seguridad, el ajuste de configuraciones y todo lo demás para estar en nivel de producción. Automatización (automation): significa que no hacemos en los servidores para hacer cambios o ajustar configuraciones. La istración de configuración supone que gestionamos los cambios en un “perfil” o en un lugar centralizado y que se aplica en nuestros servidores en forma automática. La automatización también refiere a las tareas de “mantenimiento” que son necesarias luego de el aprovisionamiento inicial. Es decir, si los servidores que ya están en producción requieren la instalación de nuevos servicios, la adecuación de las políticas de seguridad, la creación de nuevos s, habilitar o deshabitar certificados ssh en algún determinado, configurar reglas de crontab, es decir, todo lo demás que puede ser necesario durante la vida útil de un servidor. Y, por último, es automatización mantener el estado deseado de los servidores en forma imperativa. Es decir, que si algún sys realizó un cambio en un servidor de forma que incumple alguna las configuración mantenida por el de configuración, ese cambio va a ser ser revertido, se hará roll-back al estado deseado. Y cuando tenemos aprovisionamiento y automatización ya no importa la cantidad de servidores, empezamos con el problema de dependencias en nuestra infraestructura, Orquestación (orchestration): es aquello necesario cuando gestionamos muchos servidores, decenas o cientos. O sea, para realizar una gestión de mantenimiento automatizado de un centro de datos. Más en particular la orquestación es cuando utilizamos aprovisionamiento y automatización de forma inteligente en un grupo de servidores e involucra conceptos como el _centro de datos dinámico_ o la _infraestructura convergente_. La orquestación tendrá a su cargo cosas como: las dependencias (qué servicio o servidor depende de que exista cual otro servicio o servidor), los recursos globales del centro de datos, los que están en uso y los que están disponibles el consumo y métricas de recursos La orquestación será responsable de escalar hacia arriba o hacia abajo los recursos del centro de datos destinados a una tarea o servicio en particular. Entonces, cuando juntamos gestión de aprovisionamiento, automatización de configuraciones y orquestación de servicios y servidores, estamos ante un sistema de “istración de configuración”. Los es de configuración más conocidos son Ansible, Puppet, Chef y Salt. Cada uno de estos sistemas tienen características que lo hacen mejor o peor para determinadas tareas, pero en definitiva trabajan sobre el aprovisionamiento, la automatización y la orquestación. Queda entonces presentado el de configuración, pero seguiremos hablando de él, pues seguramente muchos de Ustedes se estarán preguntando si vale la pena el esfuerzo de aprender a usarlos para istrar tal vez unos pocos servidores bajo su responsabilidad, pero ¿qué les parece si lo dejamos para la próxima edición de deployandome? Soy Rodolfo Pilas, en twitter me siguen por @pilasguru y les dejo un saludo a todos, confiando en que este podcast les haya aportado para mejorar y, como siempre, espero sus inquietudes y sugerencias comentando en deployando.me Hasta la próxima edición.