Despliegue Atómico para Hipsters de JavaScript

Hola, amigos. Bienvenidos a esta charla para nosotros, la Conferencia de DevOps JS. Vamos a hablar sobre la implementación atómica para Hipsters de JavaScript y TypeScript. Justo antes de comenzar, un poco de información sobre qué es la implementación atómica y la implementación inmutable. En una implementación atómica, tomas dos versiones de una aplicación existente y solo despliegas los cambios entre esas dos versiones, pero todo está autocontenido. Por lo tanto, puedes tomar un archivo completo de una versión en cualquier momento y todo está autocontenido y no tienes que preocuparte por nada al respecto. Esto es lo que hizo que Netlify fuera tan exitoso en el pasado porque de repente solo tenías que hacer push a una rama en tu servidor de versiones como GitHub o cualquier otro, y se desplegaba automáticamente en tu servidor de producción en una URL de preparación como mybranch slash myapp.mydomain.com. Es realmente poderoso porque solo tienes que hacer push de algunos cambios en cualquier tipo de rama y automáticamente tienes muchas vistas previas accesibles directamente. Y cada vez que actualizas tu rama, como actualizar tu PR, la vista previa se actualiza de la misma manera. Así que definitivamente es útil, especialmente cuando el despliegue es un proceso doloroso cuando tienes que preocuparte por las dependencias y la construcción, y así sucesivamente. Entonces, ¿cuál es la forma hipster de hacer este tipo de implementaciones atómicas o inmutables? Mi idea es mantener que funcione. Quiero adherirme a los principios de las implementaciones atómicas e inmutables. Quiero que sea funcional, trabajable y compatible con cualquier proveedor de alojamiento, cualquiera que sea. Y quiero mantener la experiencia de desarrollo sencilla. Como, solo quiero hacer push a mi rama y mi vista previa se despliega o actualiza automáticamente, y eso es todo. Y no me importa cómo usarlo y cómo trabajar con él, y así sucesivamente. Entonces, ¿cuáles son las características esperadas en estas implementaciones específicamente? Quiero que sea configurable porque no quiero rehacer todo el proceso para cada proyecto. Quiero tener algo que se pueda desplegar fácilmente en cualquier tipo de repositorio y donde solo tenga que ajustar algunas variables para configurarlo para este proyecto específico en un momento dado. Quiero que sea compatible a largo plazo, que funcione en cualquier tipo de proveedor de alojamiento en el mundo real. Quiero algún tipo de micro-CI integrado como dependencias de despliegue y construcción, y así sucesivamente. Todo manejado por la solución en sí misma. Por lo tanto, no tengo que preocuparme por nada al respecto. Pero sin las pruebas y demás, no importa. Quiero que el tiempo de inactividad en el despliegue sea mínimo para mantenerlo realmente funcionando. Por lo tanto, no quiero romper algo en producción solo porque hice push a una rama que de repente no se construyó o algo más. Entonces, quiero algún tipo de salvaguardias en algunos puntos para asegurarme de que nada pueda fallar en algún momento. Y quiero que sea auto-publicable. Así que solo quiero hacer push en una rama y boom, mis ramas, mi vista previa asociada a mi rama se actualiza automáticamente. Soy Matt, amigos. Soy un ingeniero de experiencia de desarrollo en Always Data, que es un proveedor de alojamiento, uno independiente.

Entonces, mi responsabilidad en Always Data es trabajar en la experiencia del desarrollador, más específicamente en la CLI y las herramientas asociadas a la plataforma misma. Lo que te mostraré es definitivamente la base de nuestro proceso de implementación automatizada con características de implementación atómica e inmutable. Actualmente está en proceso de desarrollo en la CLI, pero estará disponible pronto. Estoy muy feliz de compartirlo contigo porque es definitivamente el resultado de mi búsqueda. Así que sumerjámonos en el código para ver cómo funciona. Nuestras premisas para esta charla específica son que trabajaremos en el servidor y todo en un servidor, lo que significa que, sea lo que sea, un contenedor, VPS, metal desnudo, lo que quieras para compartir el contenido en un proveedor de alojamiento, no me importa. Pero la idea es que quiero tener en el mismo lugar los hosts web y los repositorios que son responsables de la implementación atómica, la versión, etc. No es obligatorio para esta solución, pero definitivamente es más simple de explicar. Me basaré en una cuenta de sistema única de alojamiento web como `www` para cualquier distribución basada en Debian, pero digamos que todo será manejado por el mismo usuario del sistema en algún momento, repositorio y hosts web. Nos basaremos mucho en el acceso remoto SSH. Por lo tanto, necesitas un acceso remoto SSH a tu solución. Y no utilizaré webhooks para esto, no es que no me gusten, pero está totalmente fuera del alcance de esta charla. Así que hablaré un poco de ellos en la conclusión. Obviamente, cuando vuelva a hablar de ellos, habremos alcanzado

la conclusión. Así que vamos a iniciar. La idea es que te bases en los conceptos básicos de Git. Así que accederé directamente al servidor en mi contenedor con mi cuenta de alojamiento, y me aseguraré de estar en la carpeta /var, porque en /var hay una carpeta llamada www. Esta es la ruta de documentos para nuestro motor de servidor web, como Apigee o Nginx o Traphic o cualquier otro que desees, no me importa. Inicializaré un repositorio, un repositorio vacío en la misma carpeta en /var/repo. Un repositorio vacío es más o menos lo mismo que tienes en la carpeta .git en tu árbol de trabajo, pero solo tienes los diferentes archivos y elementos dedicados a Git y no el contenido general de tus árboles de origen, porque no me importa dar acceso al código en el servidor en cualquier momento. Así que si verifico, todavía tengo en mi carpeta /var dos subcarpetas, el repositorio en formato vacío y el www1 listo para manejar nuestras aplicaciones web. Así que volvamos localmente a mi computadora. Me moveré a la carpeta de mi proyecto, donde quieras almacenar tu proyecto. Tú decides. Crearé una nueva aplicación, por ejemplo, utilizando Vite con plantillas, así que crearé una aplicación en mi carpeta app. Así que está en mi carpeta app, y ahora puedo ingresar directamente a mi aplicación. Luego vincularé el repositorio previamente creado en mi contenedor a este proyecto localmente. Inicializaré el repositorio con git init, agregaré todo lo que esté disponible en él y haré el primer commit inicial. Así que todo está en el commit raíz en el primer commit en el commit inicial, el primero, inicializándolo. Agregaré un remoto llamado deploy, que apunta a través de SSH al contenedor y a la carpeta /var/repo que creamos antes. ¿Por qué deploy y no origin? Porque probablemente queramos mantener origin para nuestro servidor de versiones, como GitHub o GitLab o cualquier otro que desees. Y puedes tener tantos remotos como desees en Git, así que ¿por qué no llamar a este deploy, porque está listo para manejar el proceso de implementación y mantener origin para el original, el regular. Así que puedo hacer git push deploy main. Así que hago push en deploy de la rama main, y obtengo un mensaje de confirmación de Git diciendo, ok, en contenedores, en el repositorio /var, he creado una nueva rama main que apunta a la rama main. ¡Éxito! Ok, ahora vamos a configurarlo. Queremos que el proyecto sea configurable, así que volvamos a través de SSH al repositorio /var. Todavía estamos en nuestro repositorio vacío, y si verifico las configuraciones locales de Git, puedo ver que tengo muy pocas claves de configuración, lo cual es interesante, porque no quiero depender del nuevo archivo de configuración YAML en mi árbol de origen. Quiero tener algunas variables configurables que quiero ajustar solo para este repositorio específico dedicado a la implementación. Así que ¿por qué no confiar en la herramienta git config para hacerlo? El formato siempre es el mismo, rearm.keyed.value. Así que podemos crear una configuración local de git porque queremos mantenerla local. Deals.build.dist, porque en este proyecto, es un proyecto de Vite, por lo que Vite creará una carpeta dist, y es esta carpeta dist la que quiero implementar en mis aplicaciones web y demás. No quiero implementar todo el árbol de origen, solo la carpeta dist. Así que especifico eso para este proyecto específico y lo hago con git config. Hay una construcción dist, y puedo usarla. Así que recomiendo usar dist o lo que sea. No uses nada en lo que Git ya confíe, como core, porque existe el riesgo de sobrescribirlo.

Los claves existentes, pero definitivamente puedes confiar en almacenar tu propia configuración. Está abierto, está bien. Así que si verificamos, está bien. Ya está almacenado. Así que vamos a engancharlo. Así que todo lo que ocurra ahora ocurrirá en la carpeta ssh.var.repo. Así que unas palabras sobre los ganchos de Git. Los ganchos de Git son un mecanismo que te permite reaccionar a algunos eventos que ocurren en el ciclo de vida de tu repositorio de Git. En la lista completa, que es muy larga, de diferentes eventos disponibles, hay algunos que son interesantes, y uno en particular es realmente interesante. Es un gancho post-receive, que a menudo se dedica a hacer push al servidor de producción. Interesante. Esto es exactamente lo que estamos tratando de hacer. Así que confiemos en el gancho post-receive. Echemos un vistazo rápido a él.

Es un gancho que reacciona a los eventos de git push. Cuando se realizan actualizaciones, ramas que llegan, se ejecuta en el repositorio remoto. Excelente. Y una vez que todas las referencias se han actualizado, lo cual es interesante, puedo hacer push de todas las ramas, mi repositorio las manejará y reaccionará a todas las ramas una por una. Así que definitivamente puedo actualizar e implementar cada rama una por una cada vez que reciba un evento de git push si contiene diferentes ramas. Pero si solo hay una, está bien. Así que lee las líneas de la entrada estándar, y es un proceso automatizado. Así que lo escribiré en Bash. Puedes confiar en Python o Deno o lo que quieras hacer. Pero solo automatiza un montón de comandos de terminal diferentes. Así que Bash es una gran herramienta para hacerlo. Así que verificamos que todavía estamos en el repositorio. Creamos un archivo post-receive y lo hacemos ejecutable. Así que vamos a inicializarlo. Es un contenido de Bash. Tenemos un bucle while para leer la entrada estándar.

para cada línea. Y en cada línea, tenemos tres tipos de información, una línea, una rama. Y tenemos tres informaciones, el commit de revisión antiguo, el commit de revisión nuevo y la referencia, que obviamente es el nombre de la rama. Así que podemos imprimir en pantalla, trabajando en la rama, blah blah blah.

De acuerdo. Así que tenemos que configurar el entorno. Tenemos que recuperar la ruta a la carpeta git pair en el propio servidor. Podría codificarla directamente, pero quiero que sea agnóstico, así que tengo que detectarlo. Es un poco complicado. No voy a profundizar en ello, pero lo tienes. Tenemos acceso a la carpeta git y entramos en ella como si fuera un CD. Así que entramos en la carpeta git para ejecutar el resto de los comandos. Verificamos si tenemos esta clave de configuración de implementación y si no la hemos definido. Así que podemos utilizar una carpeta en el mismo nivel de la carpeta git en el directorio VVV, que es exactamente lo que tenemos, slash virus slash VVV para la implementación. Así que aquí tenemos una implementación. Verificamos que la carpeta ya esté lista para manejar el resto, y vamos a donde estamos listos para continuar. Así que podemos configurar cada rama, para cada una, podemos configurar la rama. Estamos haciendo algunos trucos para mejorar la legibilidad. Así que tenemos un nombre de referencia, que elimina el prefijo 'heads' de la referencia. Utilizamos solo un commit de alto costo y creamos un directorio temporal para alojar nuestro árbol de código fuente para esta rama específica. También creamos un directorio de enlace a la referencia de la carpeta de implementación, que es una ruta legible, porque no quiero configurar todo mi host web a slash virus slash VVV slash un ID de commit,

pero quiero que apunten a var VVV, el nombre de mi rama. Así que puedo mover simplemente un enlace, que es solo un puntero desde el nombre de referencia hasta el commit actual dedicado a esta rama. Así que será mejor. Por lo tanto, usamos un enlace para hacerlo y preparamos el nombre del enlace.

De acuerdo, ahora tenemos un árbol de trabajo en la carpeta temporal. Así que verifiquemos el árbol de trabajo. Usamos el comando work tree, que es como un checkout, pero de una manera más potente. Así que agregamos un nuevo árbol de trabajo a esta carpeta temporal basado en esta rama actual. Y nos movemos a él para ingresar a este árbol de trabajo . Tenemos que manejar el proceso de compilación, así que verificamos si tenemos un directorio de compilación configurado. Este es el caso. Lo definimos antes, así que lo tenemos. De lo contrario, es simplemente una carpeta actual. Probamos si tenemos un diseño de paquete disponible. Si es así, probamos si tenemos un bloqueo de paquete. Si es así, hacemos una instalación limpia, porque somos personas limpias, de lo contrario. Hagamos una instalación, pero recuerda hacer tus archivos de registro, y luego podemos ejecutar el script de compilación si el script está presente. Si no, está bien. Está perfectamente bien. Si la compilación falla, el script se cerrará y pasaremos a la siguiente rama. Y todo está protegido de esa manera. Así que vamos a la siguiente. Una breve explicación sobre los enlaces duros de Unix. La idea en el proceso atómico, si recuerdas correctamente, es que solo quiero copiar los archivos que han cambiado desde mi versión anterior a esta. Así que no quiero copiar todo y duplicar el contenido. Mi idea es decir, okay, verifiquemos si tenemos una versión anterior de esta rama. Así que queremos verificar dónde está el punto de bifurcación desde la rama principal o desde la rama de origen, y queremos verificar si hay un commit dedicado a eso. Si es así, si el archivo no ha cambiado entre esta rama de origen y esta nueva, simplemente copiemos este. Simplemente hagamos un enlace duro a esta versión. De lo contrario, copiemos una nueva versión. Será más performance,

Será más rápido y definitivamente más fácil de mantener. Y solo copiarás los cambios, pero cada versión será autocontenida. Por eso no confiamos en los enlaces simbólicos, sino que preferimos utilizar enlaces duros para hacerlo. Esto significa que tenemos que encontrar un ancestro de comando git. Supongamos que estamos en la rama fixd. Si estamos allí, podemos suponer que el punto de bifurcación es un commit C1. Pero si le preguntamos a git, hey, ¿cuál es el punto de bifurcación para mi rama actual?, git no escribe nada porque git no almacena realmente un árbol de las diferentes ramas, sino solo una lista de commits. Así que tienes que confiar en ti mismo para hacerlo. Tienes que obtener la lista de revisiones desde la punta de tu rama hasta la rama principal y el commit inicial. Luego tienes que verificar para cada uno de estos commits si es un ancestro válido. Si es el punto de bifurcación de una rama anterior, y si es así, entonces podrías considerar que este commit, si todavía está en una rama, podría ser utilizado como base para el despliegue. ¿Cómo hacerlo en código? Tenemos la lista de revisiones, gracias al comando revlist. Y para cada revisión, es decir, para cada commit en esta lista, retrocedemos en la historia. Y para cada uno de ellos, verificamos si es un posible ancestro para mi rama en esta revisión específica. Si es el caso, es decir, si es el punto de bifurcación, entonces verifiquemos que todavía está en una rama y que esta rama fue desplegada antes. ¿Este commit todavía está disponible? Si es así, entonces podríamos considerar que podemos, como bifurcamos el código, bifurcar el despliegue y usar esta carpeta como carpeta base para la revisión. De lo contrario, simplemente insertamos la revisión y desplegaremos desde cero, y está bien. Es perfectamente legítimo hacerlo. Si tenemos un ancestro común, simplemente agregamos algunas opciones a air sync, que será nuestra herramienta de despliegue, para decir, ok, para esta tarea de copia específica, usa esta carpeta como base. Y si el archivo no cambió entre esta carpeta y la nueva, simplemente haz un enlace duro entre las dos. Así que vamos a desplegar. Confiamos en air sync, como esperabas. Así que desplegaremos desde el directorio de construcción de trabajo dentro de él. Así que mi directorio de disco dentro de mi árbol de trabajo, y lo desplegaremos en mi directorio de despliegue. El commit de ID de revisión. Confiamos en el checksum para hacerlo con la opción de air sync activada. Así que enlaces duros activados, si es confiable en este contexto, y así sucesivamente. Después de eso, simplemente podemos eliminar la carpeta de trabajo del repositorio git porque ya no la necesitamos, y somos personas limpias, así que limpiamos detrás de nosotros. Y luego podemos publicarlo, lo que significa crear los enlaces entre el nombre de referencia y el nombre de revisión. Moviendo el puntero del

Para publicar la aplicación, asegúrate de que todo esté bien, creando el enlace. Luego, reiniciamos el servidor. En esta demo, arreglé el reinicio. Simplemente detuve el servidor existente lanzado previamente y cambié aleatoriamente el puerto y lancé un servidor HTTP que apunta a este nuevo enlace de producción que creé antes y que apunta a mi nuevo commit. Y voilà, todo está bien. Esto es para la publicación. Permíteme mostrarte cómo funciona. Regreso a mi carpeta local. Actualizo mi aplicación. Verifico que todavía estoy en mi aplicación. Creo una nueva rama llamada fit/actualizar-nombre. Cambio a esta rama, edito la aplicación, hago un commit con el mensaje de commit elegante 'actualizar nombre' y luego puedo enviarlo. Así que hago git push deploy fit/actualizar-nombre. Envío para desplegar mi rama fit/actualizar-nombre. Y dice que está bien, despliego la rama en VAR vvv. Estamos trabajando en la rama fit/actualizar-nombre. Estoy preparando el árbol de trabajo. Así que nos estamos moviendo al árbol de trabajo en un estado desconectado. Aquí, estamos instalando los paquetes npm. Así que estamos construyendo cosas con npm run build cosas para VIT. Así que estamos produciendo la carpeta dist. Encontramos el commit base de despliegue porque la rama se bifurcó de una rama principal, y estamos desplegando esta carpeta dist en VAR vvv, mi nombre de commit de referencia. Luego podemos hacer el enlace desde fit/actualizar-nombre hasta el ID final del commit. Y reinicio la aplicación. Y si verifico, puedo asegurarte que funciona. Y en menos de 60 líneas de código bash. Para lo mismo.

tan exitoso como Netlify. Esto es simplemente increíble. Entonces, ¿cuáles son los casos de uso reales? Porque he dicho que falsifiqué el proceso de reinicio. Probablemente tendrás algún tipo de acciones como crear o actualizar el sitio web con la URL correcta como el nombre de mi rama punto mi aplicación punto mi dominio punto com. Probablemente realizar algunas acciones en la base de datos como migración y así sucesivamente, invalidación de caché, reiniciar el sitio web, lo que desees. Entonces, debes hacerlo, envuélvelos en llamadas de API, reemplazando el contenido falso de reiniciar el servidor HTTP. Pero si son solo archivos estáticos como los que tenemos aquí, simplemente estás creando un nuevo VOS en tu motor web y está bien. Así que eso es genial. ¿Qué hay de los webhooks? Como dije antes, puedes usarlos principalmente para automatizar el envío desde el repositorio de origen al repositorio de implementación. Entonces, cada vez que haces push a GitHub o GitLab o cualquier otro, a tu servidor upstream, gracias a los webhooks, puedes automatizar el proceso de recuperación en la rama del servidor de implementación. Escribí una publicación en el blog al respecto si quieres. Así que puedes usarlos para eso y está perfectamente bien, está perfectamente bien. Solo reduce la fricción en términos de developer experience. Algunos consejos para la envoltura. Mantenlo simple y estúpido. Lo hago realmente agnóstico. No quiero que sea demasiado inteligente ni nada por el estilo. Una vez más, son menos de 60 líneas de código bash. Así que hazlo realmente simple y será mucho más fácil de mantener y adaptar a muchas aplicaciones diferentes. Usa la configuración de Git para almacenar tus variables y procesos de configuración ajustes y demás. Abstrae cualquier cambio en la configuración de tu alojamiento web en llamadas de API utilizando CLI, utilizando la API, utilizando lo que desees. Y definitivamente puedes confiar en Deno o Node.js como sistema de compilación gracias al archivo package json. Puedes crear muchos scripts para ejecutar y asegurarte de que las dependencias estén instaladas, ejecutar el proceso de pre-compilación, el proceso de compilación, el proceso de post-compilación, incluso en aplicaciones complejas escritas en Python, Ruby, Rust, lo que desees. Pero definitivamente puedes usar Node.js como motor de CI para el proceso de compilación. Así que gracias de nuevo. Gracias por tenerme hoy y espero que disfrutes el resto de la conferencia. ¡Adiós!