Automatizar Despliegues de Sitios React desde GitHub a S3 y CloudFront

Hola a todos. Muchas gracias por sintonizar mi charla en la conferencia DevOps.js 2021. Voy a hablarles sobre la automatización de implementaciones de React en S3 y CloudFront. La principal motivación de esta charla es que cada vez más equipos de desarrollo buscan optimizar sus ciclos de lanzamiento para obtener software de calidad en producción. Y el CI/CD es la práctica automatizada que ayuda a los equipos de software a lograr esto. Sin embargo, construir pipelines puede ser un proceso tedioso si se tiene que hacer manualmente para múltiples entornos, además de ser consumidor de tiempo y no escalar muy bien, especialmente cuando se tiene que hacer una y otra vez.

Toda la infraestructura se construirá utilizando Terraform. Además, voy a utilizar una herramienta llamada Terragrunt, que es un envoltorio de Terraform y realmente ayuda en términos de tener un enfoque DRY para programar su infraestructura. Y eso será muy útil. Como pueden ver, no tendremos tanto código en nuestra base de código, incluso para nuestra infraestructura, lo cual será muy útil. Y esta es una de las buenas prácticas cuando se trata de construir recursos como estos. Al final, les demostraré una implementación en múltiples entornos, así como la salida final de tres sitios diferentes desde el mismo código base. Y eso es algo que será bastante interesante de ver una vez que todo se complete.

Antes de continuar, voy a presentarme. Soy Lukhan Demwila. Mucha gente me llama Luke. Algunas personas se divierten y me llaman Skywalker. Soy un ingeniero de software senior en Intellect. También soy un AWS Container Hero y tengo cinco certificaciones de AWS. Actualmente, trabajo como consultor en el sector de servicios financieros, principalmente como ingeniero de cloud y DevOps. Anteriormente, estuve muy involucrado en el desarrollo de aplicaciones, tanto web como móviles, en productos SaaS para startups. Pero desde entonces, he pasado al espacio de cloud y DevOps.

Correcto, algo que encuentro muy útil, especialmente cuando se emprende este tipo de proyectos, es tener una buena vista general o una imagen del proyecto. Quiero intentar encapsular eso con este diagrama simple y mostrarles hacia qué estamos trabajando. Ya lo expliqué anteriormente en la introducción, pero este diagrama puede resumir todo eso, básicamente.

Tendremos una canalización dentro de AWS, en el entorno de la nube de AWS. Utilizaremos GitHub como nuestra etapa de origen para la canalización y para la etapa de compilación e implementación. Utilizaremos solo CodeBuild y CodeBuild ejecutará todos los comandos necesarios para ejecutar pruebas en nuestra aplicación React. Y si las pruebas pasan y estamos satisfechos con la calidad del software, lo implementamos y con implementar me refiero simplemente a copiar los activos estáticos que se generan a partir de la aplicación React en un bucket de S3, que está configurado para alojamiento de sitios estáticos. También tendremos un CloudFront, que es nuestro CDN, que actuará como punto de distribución y tendrá el bucket de S3 como su punto de origen. Esto les dará una buena idea de todo el proceso que vamos a seguir.

Además de eso, algo que creo que es muy útil, especialmente cuando tienes que revisar mucho código, es tener el repositorio en tu máquina. Pueden ir a mi perfil de GitHub y encontrarán un enlace para clonar el repositorio. Será muy útil si pueden revisar el código fuente por su cuenta. En esta presentación, me enfocaré principalmente en los componentes principales de toda nuestra infraestructura y en la arquitectura de todo lo que vamos a construir, para no perder tiempo revisando todos los detalles y mostrándoles variables. No tendremos tiempo para eso.

Ahora cambiaré a VS Code y nos pondremos manos a la obra revisando algo de código. Bien, aquí en el panel izquierdo pueden ver la estructura de carpetas. Ampliaré un poco más para que quede claro. Aquí en la raíz, tenemos la aplicación cliente, que es una aplicación React básica. Les mostraré los ajustes que hice en ella. Además de eso, tenemos la carpeta 'infra live', que contendrá nuestros archivos de configuración de Terragrunt. Llegaremos a los detalles de eso más adelante. Aquí tenemos la carpeta 'infra modules', que contendrá los módulos reales para nuestro código fuente de Terraform. Los módulos son simplemente agrupaciones lógicas o contenedores, y uso la palabra contenedor de manera muy amplia, no confundir con procesos o contenedores de Docker. Estas son simplemente agrupaciones lógicas para recursos relacionados de alguna manera para un conjunto particular de infraestructura que deseas implementar. Y aquí está el archivo de configuración principal de Terragrunt. Así que ahora tienen una buena idea del panorama del código fuente y con qué vamos a trabajar.

Y ahora voy a abrir esta aplicación cliente, que es un código base. Utilizo la herramienta CLI de create react app para crear esto. También notarán un archivo adicional aquí llamado build spec.yaml. No se preocupen por eso, lo veremos más de cerca más adelante.

Lo que quiero llamar su atención en este momento es el archivo app.js, así como el archivo app.test.js. Dentro de nuestro archivo app.js, los únicos cambios que realmente he realizado son este párrafo aquí. Especifico el entorno y coloco el nombre del entorno allí, producción. Obviamente, una buena práctica sería utilizar variables de entorno, pero lo principal que quiero mostrarles es cómo se obtendrá cada entorno desde una rama diferente dentro de nuestro repositorio. En este momento estoy en la rama principal, que tiene producción en este fragmento de código. También tengo otras dos ramas. Una es UAT, que es para pruebas de aceptación de usuario. Y así reemplacé eso con UAT. También tengo un entorno de desarrollo que se obtiene de la rama develop. Y como probablemente puedan adivinar, estoy utilizando develop allí. Esos son los únicos cambios. Esto les ayudará a comprender mejor cuando clonen el repositorio y vean tres repositorios diferentes. De esa manera, cuando finalmente implementemos nuestra infraestructura y tengamos nuestro sitio en funcionamiento, les dará una buena vista de tener múltiples entornos y podrán ver la diferencia entre los tres.

En app.test.js, simplemente ajusté la prueba. Lo único que estoy haciendo es probar que el componente llamado app se renderice correctamente. De esta manera, podemos ejecutar la prueba dentro de nuestra etapa de CI. Voy a cerrar esos dos archivos.

Entonces, si puedo retroceder un poco, asumo que han clonado el repositorio, pero si desean tener un ciclo completamente diferente por su cuenta, pueden crear un nuevo repositorio en GitHub. Y un paso importante que deberán realizar es dirigirse a la configuración de desarrollador de GitHub y dirigirse a los tokens de acceso personal. Aquí, generarán un token de acceso. Y la razón de esto es porque desean darle a CodePipeline los permisos relevantes para poder acceder a su repositorio de GitHub. Asegúrense de guardar este token que generen en un lugar seguro.

Entonces, lo estoy guardando en Secrets Manager. Así que tendrás que dirigirte a Secrets Manager dentro de AWS. En este punto, asumo que sabes que estás trabajando con una cuenta de AWS para que todo esto funcione. Así que dirígete al servicio de Secrets Manager. Y cuando se trata de crear un secreto, seleccionarás el otro tipo de configuración de secretos aquí, o tipo más bien. Y estoy usando un valor falso aquí. Así que no te emociones demasiado. Ese no es mi token de acceso personal. Puedes darle el nombre GitHub personal access token o cualquier tipo de clave siempre y cuando sea algo que identifiques porque esto es algo que necesitaremos especificar en nuestro código fuente de Terraform un poco más adelante. Y luego el valor para tu token de acceso personal se colocará aquí. Este es uno de los pasos preliminares que es muy importante.

Porque recuerda que sería diferente si nuestro pipeline estuviera utilizando un repositorio dentro de CodeCommit, que es un servicio de AWS, pero como vamos a un tercero en este caso particular, queremos asegurarnos de tener un enfoque seguro para obtener nuestro código de ese repositorio. Entonces, organiza tu token de acceso personal y dirígete a Secrets Manager y guárdalo allí.

Entonces, ahora voy a dirigir nuestra atención a algún código fuente de Terraform. Como verás aquí, tengo dos módulos. Uno se llama CICD pipeline y el otro se llama webapp. Vamos a comenzar con el webapp. El webapp contiene todo el código fuente para el bucket de S3, así como la distribución de CloudFront que queremos configurar. Voy a abrir mi archivo main.tf aquí y esto te mostrará una buena idea o una descripción general de cómo se ve un módulo en términos de creación. Y así configurarás la fuente particular en términos de dónde vive todo el código para este módulo en particular. Tengo el mío dentro de una carpeta llamada frontend. Aquí estoy configurando algunas variables para el entorno, el ACL del bucket y el nombre del bucket. Ahora vamos a profundizar y entrar en esta carpeta frontend.

Las dos cosas principales que quiero mostrarte serán la distribución de CloudFront y el propio bucket de S3. Como mencioné anteriormente, llevaría mucho más tiempo llevarte a través de cada línea de código en términos de variables, etc. Así que me voy a centrar en los recursos principales que queremos crear aquí. Como puedes ver, estoy creando un recurso, que es el bucket de S3. Luego puedes darle el nombre que desees. Esto especifica el tipo de recurso, por supuesto. Y aquí dentro, le doy un nombre a mi bucket. Defino la lista de control de acceso, que son los permisos del bucket. Además de eso, también tengo una política de bucket. Y aquí puedo definir cuáles son las reglas en términos de cómo acceder a los objetos dentro de ese bucket. Y como lo estoy configurando para alojamiento de sitios estáticos, le proporciono el archivo HTML que se utilizará como documento de índice. Y para un documento de error, utilizo nuevamente index.html, porque como sabes, todos los componentes se inyectan dentro de tu archivo raíz o index.html cuando se trata de una aplicación React. Incluso tu página 404 será esencialmente un componente que se renderizará allí. La versión de tu bucket es opcional. Y es una buena práctica tener una etiqueta para cada uno de tus recursos. Así que lo configuro allí. Y ahora te mostraré CloudFront.

Y así, para la distribución de CloudFront, llevará... Lo primero que es importante aquí es la propiedad. Queremos configurar nuestro origen para la distribución de CDN, y lo estoy apuntando al bucket de S3 que creé. Así que esto es una referencia directa a eso. Cuando lo proporcionas, le das un ID de origen, que en mi caso es 'website'. Y procedo a configurar la caché. Ahora, obviamente esto es algo que se verá muy diferente dependiendo del tipo de aplicación que estés configurando. Así que no tienes que preocuparte demasiado por esto. Esto es principalmente para darte una idea de cómo configurarlo. Pero los valores reales son algo que se verá diferente dependiendo de tu caso de uso particular. Y me aseguro de configurarlo para redirigir a HTTPS. Como mencioné antes, es una buena práctica tener algunas etiquetas allí. Y también hago uso de los certificados predeterminados de CloudFront. Correcto. Así que esos son los recursos principales para nuestra aplicación web actual.

Y echemos un vistazo ahora al pipeline del front end. Y así, los dos recursos principales que queremos crear aquí, solo colapsemos esto, serían CodeBuild y CodePipeline. CodePipeline es el servicio proporcionado por AWS para el CI/CD real. Así que piénsalo como el componente principal aquí, y dentro de él es donde tienes tus etapas y puedes hacer uso de diferentes servicios dentro de él. Y así estoy haciendo uso de CodeBuild para mi etapa de CI, mi integración continua. Y lo que hace CodeBuild esencialmente es crear un contenedor donde, con una configuración particular que le proporcionas en términos del entorno, las herramientas que quieres tener instaladas dentro de él. Y el mío va a hacer uso de un entorno Node.js como puedes imaginar porque estoy usando una aplicación JavaScript. Y así le proporcionarías, gran parte de la información es intuitiva en términos del nombre de tu proyecto CodeBuild. Puedes especificar el tipo de contenedor, puedes proporcionar un contenedor personalizado si quieres para la ejecución de tus comandos. Además de eso, le proporciono algunas variables de entorno, así que obviamente quiero especificar la variable de entorno para la aplicación en particular, así que la proporciono. Además de eso, especifico una variable de entorno para el destino del bucket de S3 porque, como recordarás, mencioné que cuando se construye el código fuente o cuando se construye la aplicación React y voy a usar el comando de construcción de NPM, eso producirá nuestro contenido estático y quiero copiar todo ese contenido al bucket de S3, así que esta es una buena manera de decirle a tu proyecto CodeBuild el destino donde todo ese código fuente debe ser enviado.

Luego aquí tengo mi pipeline de código y dentro del pipeline de código, verás que tengo mis dos etapas que mencioné, también puedo especificar los nombres de estas etapas en particular. Tengo mi origen, que puedes ver aquí como un tercero, estoy usando GitHub para eso y proporcionarías algunos valores de configuración muy importantes aquí en términos del nombre del repositorio, el nombre de la rama en particular y el nombre de la rama es algo que obviamente va a variar dependiendo del entorno y te mostraré cómo puedes configurarlo de una manera genial usando Terragrunt y también, como puedes ver aquí muy importante, el token de GitHub también y ese valor se obtendrá de Secrets Manager y podemos usar Terraform para obtenerlo de manera segura. Segundo aquí para la etapa de CI o la etapa de construcción, estoy usando el proyecto de CodeBuild que acabo de mostrarte y lo referencio aquí usando el nombre particular de ese proyecto de CodeBuild y solo especifico el orden en el que esto viene en mi pipeline en particular y así que este no es un pipeline muy complejo. Solo tiene dos etapas por lo que debería ser relativamente simple configurarlo.

Definitivamente hay ejemplos más complejos. Y ahora, si te muestro el archivo main.tf que contiene el módulo para mi pipeline del front end, verás que aquí estoy utilizando la API de datos de Terraform y esta es una forma muy útil de obtener fuentes existentes. Aquí estoy obteniendo mi secreto que creé para GitHub y esta es una forma muy útil de obtenerlo e inyectarlo en algunos de los recursos que estás creando, lo mantiene seguro y no se filtra ninguna información sensible de ninguna manera.

Y aquí, similar al módulo que te mostré anteriormente, porque hay algunos recursos adicionales que estoy configurando, obviamente hay más valores que se deben o propiedades que se deben completar aquí y todos estos son solo variables. Aquí puedes ver el nombre de mi aplicación, que estoy utilizando en todo el proyecto, el destino del bucket de S3, el nombre del bucket del pipeline y el nombre del bucket de CodeBuild. En caso de que te preguntes para qué son, no están relacionados con el bucket de S3 para el alojamiento de un sitio estático, principalmente funcionan para fines de caché para que cuando se instalen dependencias en nuestro pipeline, la caché haga que las cosas sean mucho más rápidas en cada ejecución sucesiva del pipeline.

De acuerdo, por último, llegamos a infra live y aquí verás que he dividido las carpetas en los entornos correspondientes y lo que tenemos es un pipeline de CICD y una aplicación web, reflejando los módulos que realmente tenemos y también voy a abrir mi archivo de configuración Terragon, el archivo principal. Y uno de los archivos secundarios. El archivo principal se utiliza para generar un proveedor y el proveedor es lo que obviamente vamos a utilizar para especificar el proveedor de nube que queremos utilizar para construir nuestra infraestructura. Especifico la región en la que quiero que se construyan mis recursos y el perfil que voy a utilizar para eso. Además, puedes especificar información adicional en términos de las versiones que quieres usar para la API. En este caso particular para AWS, qué versión quiero utilizar y qué versión de Terraform también voy a utilizar. Y aquí, muy importante, este último bloque, los estados remotos y el estado se utilizan para realizar un seguimiento de todos los recursos que se han creado o que están activos o se han implementado. Y así debe haber una forma óptima de realizar un seguimiento de esos recursos. Y así puedes tener eso configurado localmente o de forma remota. Una buena práctica es tenerlo configurado de forma remota porque si está local y algo sucede con ese archivo local, entonces no tienes una forma de realizar un seguimiento de lo que se ha construido. Y así estoy utilizando S3 para almacenar un archivo de estado de Terraform, como puedes ver aquí. Y ese archivo de estado de Terraform es esencialmente un archivo JSON que contiene todos los recursos que se han construido. Además, estoy utilizando el bloqueo de estados y mi bloqueo de estados se realiza utilizando una tabla DynamoDB. Esto es muy útil cuando se trabaja en equipo porque lo que sucede es que cuando se utiliza el bloqueo de estados, proporciona un enfoque de protección para tener varias personas trabajando en el mismo tipo de estado. Y así, cuando una persona está implementando algo o está en medio de alguna ejecución, entonces, en esencia, el estado estará bloqueado para que nadie más actúe sobre él, lo cual es una gran medida de protección cuando se trabaja en equipo. Disculpa por el ruido de fondo. Y ahora te voy a mostrar un archivo de configuración secundario de TerraGrant aquí. Y este archivo de configuración secundario de TerraGrant es para el pipeline de CICD. El de la aplicación web o el sitio web se verá muy, muy similar. Solo voy a colapsar esto aquí y dentro de él, para el pipeline, especifico el nombre de la rama y el entorno. Y esta es una forma agradable de mantener las cosas DRY, como mencioné, lo que TerraGrant te ofrece es todos los pasos de la CLI que tendrías en Terraform, pero esencialmente hace que las cosas sean más eficientes con estos archivos de configuración. Y ejecuta todos esos comandos en segundo plano, es esencialmente un envoltorio. Algo a lo que quiero llamar tu atención aquí es este bloque de Terraform, y apunta al módulo en particular desde el que vas a implementar recursos. Y además de eso, puedes tener algunas variables comunes y podrá obtenerlas de las carpetas principales.

Así que tengo un archivo llamado sensitive.tfvars. Y está correcto. No lo he subido a mi repositorio por buenas razones. Por lo tanto, el archivo sensitive.tfvars es algo que no quieres tener en tu repositorio. Básicamente, contiene variables con valores muy sensibles que se han establecido. Así que eso es algo que no debes subir. Solo debes tenerlo en cuenta cuando compartas un proyecto con otros compañeros de equipo.

Y así, el archivo de configuración para el propio sitio web no se verá muy diferente. Las entradas variarán porque, como recordarás, esos modules tienen diferentes propiedades que deben establecerse. Además de las variables que puedes almacenar dentro de las respectivas carpetas de módulos, puedes establecerlas en este bloque de entradas aquí, que es lo que estoy haciendo. Y eso es solo una descripción general rápida de nuestros modules así como de nuestros archivos de configuración de Terragon.

Ahora voy a llamar tu atención sobre AWS y mostrarte rápidamente nuestro pipeline. Solo te mostraré el de desarrollo, aunque he creado los tres. Y como puedes ver, los recursos se crearon sin ningún problema en particular. Puedes ver que la fuente es GitHub, que es lo que esperamos. Y si haces clic en eso, verás que las ramas son develop, que es lo que queremos para el entorno de desarrollo. Y en esta etapa de construcción aquí se utiliza CodeBuild. Puedes hacer clic en eso para ver los detalles y te mostrará todos los registros cuando se ejecuten los diferentes comandos y pasos. Y esto fue genial, me alegra que no haya llevado mucho tiempo. Solo voy a desplazarme hacia abajo. Puedes ver la instalación de las dependencias que ocurre allí. Y así verás, aquí es donde se ejecuta esa prueba para la aplicación de la aplicación React. Y luego procedo a construirlo y subo mi contenido estático a un bucket de S3, como puedes ver allí. Y así, cuando esto se ejecute correctamente, junto con el uso de Terraform para construir mis distribuciones de cloud front, se vinculan a los orígenes relevantes, que puedes ver aquí son las URL de los buckets de S3 para el alojamiento de mi sitio estático. Y puedes hacer clic en cualquiera de estas distribuciones y hacer clic en la configuración de la distribución para obtener el nombre de dominio relevante, o puedes obtenerlo aquí mismo. Y así, disculpa, te voy a mostrar, esta es la salida final para el entorno de desarrollo, como puedes ver, entorno dev. Y si abro este, entorno uat y entorno producción. Y así obtenemos la salida deseada al final en términos de tener esos múltiples entornos para nuestras aplicaciones react, y tenemos un proceso optimizado para implementar estos recursos.

Lo último que quiero mostrarte, que es el paso más importante cuando se trata del lado de la aplicación react, es el archivo YAML de especificaciones de construcción. Y este archivo de configuración se utiliza para indicarle a CodeBuild que ejecute estos pasos relevantes.

Y es una buena manera de personalizar el contenedor que se va a ejecutar. Y así puedes especificar la versión de tiempo de ejecución para ese contenedor. En mi caso, uso la versión de nodejs 12. Y verás que no hay muchos pasos involucrados aquí. Solo estoy imprimiendo algunas cosas para decir qué estoy haciendo. Y como este repositorio en sí es el que se utiliza para el pipeline, me cambio al directorio de la aplicación cliente y luego continúo e instalo todas las dependencias relevantes para mi aplicación React. Y luego imprimo el hecho de que estoy ejecutando esta etapa de compilación para ese entorno en particular. Continúo y ejecuto las pruebas de la aplicación React utilizando este comando aquí, npm test. Y establezco ci en true. Opcionalmente, puedes agregar la fecha para esa ejecución en particular. Y luego simplemente puedes ejecutar npm run build. Si estás familiarizado con las aplicaciones React, entonces conocerás algunos de estos comandos. Y lo bueno es que esencialmente estás llevando lo que tendrías localmente a la etapa de CI aquí en la nube. Y por último, menciono copiar todo el contenido de la compilación al bucket de S3 de destino. Recordarás que en CodeBuild, le proporcioné una variable de entorno para el destino del bucket de S3. Y eso es lo que hago. Utilizo la CLI de AWS para copiar recursivamente todo el contenido dentro de la carpeta de compilación de mi aplicación React al bucket de S3 de destino. Y así, esta es una configuración realmente genial que utiliza Terraform para construir toda tu infraestructura y el panorama de AWS con las herramientas de CICD relevantes para agilizar las implementaciones en los respectivos entornos. Haciendo uso tanto de Terraform como de Terragrunt para tener un enfoque sólido en tu desarrollo en el sentido de utilizar un enfoque seco. De lo contrario, tendrías que ejecutar varios comandos de CLI en segundo plano. Los mismos comandos de CLI que estarías ejecutando se trasladan esencialmente a ser ejecutados en segundo plano por Terragrunt.

Y eso es mi charla en pocas palabras. Es mucho, pero espero que haya sido muy útil para usted y le brinde una perspectiva realmente buena sobre cómo abordaría algo así. Por favor, adelante y clone el repositorio y échele un vistazo. Si tiene algún problema, no dude en registrarlo en ese repositorio en particular y estaré encantado de ayudarle.

Echemos un vistazo a la pregunta de la encuesta. Así que le preguntaste a la audiencia, ¿cuál es tu herramienta de integración continua preferida? Y preguntaste CircleCI, CodeBuild, Jenkins, TravisCI u Otro? ¿Cuáles son tus pensamientos sobre la selección aquí? ¿Qué es ese Otro? Sí, sería realmente interesante saber qué es ese Otro. No puedo decir que esté demasiado sorprendido por los resultados de CircleCI y Jenkins. Sé que son definitivamente populares y son excelentes herramientas. Me sorprende que TravisCI haya obtenido un cero. He trabajado con TravisCI y también creo que es muy bueno. Muy intuitivo. Sí, conozco a algunas personas de TravisCI, así que sí. Sí, me gustaría mucho saber qué es ese Otro también. Ok, ok. Hay muchas, para ser honesto, hay muchas herramientas de CI disponibles. Y estoy seguro de que las personas también construyen las suyas propias. Eso también es una opción. Sí, sí. Pero por favor, todos los que hayan respondido esto, vayan a la sesión de preguntas y respuestas de DevOps y siéntanse libres de decirnos qué es ese Otro, porque realmente nos gustaría saberlo. Veo que algunas personas mencionan GitHub Actions. GitHub Actions es mucho. También se mencionan los pipelines de GitLab. Así que sí, gracias. Sí, GitHub y GitHub Actions también. Definitivamente, GitLab es muy popular. Sí, sí, sí, sí, sí. Veo a alguien diciendo incluso manualmente. Esa también es una forma de hacer integración continua si no respetas tu tiempo.

Pero déjame abordar las preguntas que recibimos de la audiencia porque hubo algunas preguntas de las personas. Pregunta de Will. ¿Qué agrega realmente Terragrunt a Terraform? Y solo para que tenga sentido aquí, Terragrunt es un envoltorio para Terraform. Agrega alguna funcionalidad adicional, pero ¿exactamente qué? Claro. El verdadero valor de Terragrunt radica en cuando estás tratando de trabajar hacia tener una configuración de múltiples entornos, o cuando quieres hacer cosas como versionar tus módulos de Terraform. Entonces, en proyectos más pequeños, es muy difícil ver el valor de Terragrunt. Realmente puedes sentir que, bueno, esto solo agrega una capa de complejidad de la que puedo prescindir. Pero lo que Terragrunt realmente hace es tratar de amalgamar esencialmente todos los pasos de la CLI que estarías ejecutando con Terraform de otra manera. Y empaqueta todo eso en una funcionalidad donde puedes especificar que esas funciones se ejecuten en tu nombre. Entonces, simplifica mucho las cosas. Y quiero decir, tratas con muy pocos archivos de configuración de Terragrunt, por lo que no aumenta tu código. Si acaso, eso es lo que resuelve. Hace que las cosas sean más secas. ¿Terragrunt también maneja los archivos de estado de Terraform y la ubicación de esas cosas? Sí, puedes usar Terragrunt para generar tus archivos de backend, tus archivos de proveedor. Entonces, también hace mucho trabajo pesado por ti. Sí, está bien. Eso es un punto válido. Muchos de nosotros los usamos, los usamos para liberar nuestro propio tiempo para hacer algo mejor. Excelente. Bien, entonces. Lo siento, Darko. Si puedo agregar rápidamente, si usas Terraform Enterprise, probablemente no necesitarías algo como Terragrunt, pero sé que mucha gente usa Terraform Community Edition. Entonces, si estás usando Terraform Community Edition, Terragrunt es un excelente complemento para eso. Punto válido, punto válido. Excelente, excelente. Sí, así que hay un par de preguntas más aquí. Una pregunta de Dennis dice, estás configurando tanto la infraestructura como el código al mismo tiempo. ¿Es posible configurar AWS Code Deploy para esperar a que la infraestructura termine de configurarse, y luego implementar automáticamente la aplicación de React? Bien, entiendo tu punto.

No lo he intentado. De acuerdo. Entonces, si entiendo bien tu pregunta aquí, ¿quieres que tu canalización espere esencialmente a que se cargue el código de tu aplicación específica y luego se ejecute solo después de eso? Sí, parece que sí. Quiere implementar la infraestructura primero y luego implementar. Correcto. Creo que puedes solucionarlo si usas algún tipo de paso automatizado o pensando lógicamente, carga tu código primero, básicamente, porque eso será la fuente para la canalización. Esto significa que deberás asegurarte de que tu archivo de especificación de compilación ya esté dentro de tu React, en el caso de que estés usando una aplicación React como esta. Asegúrate de que el archivo de especificación de compilación ya exista allí para que cuando la canalización extraiga esa fuente en particular, tu etapa de CI tenga ese archivo de configuración para ejecutar los comandos relevantes también. Y de esa manera tu canalización no fallará.

De acuerdo, de acuerdo. Bueno, Lukandre, muchas gracias. Aprecio tu tiempo y que te hayas unido aquí al final. Muchas gracias. Aprecio la charla. Soy un fanático de la infraestructura como código. Soy un fanático de todo lo relacionado con ZBS, así que muchas gracias. Y nos veremos pronto. Genial. De acuerdo, gracias. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós.

Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós, adiós. Adiós. Adiós, adiós, adiós.

Adiós, adiós, adiós. Adiós, adiós, adiós, adiós. Adiós, adiós, adiós.

Adiós, adiós, adiós.