Consideramos qué es IaC (Infraestructura como Código) y por qué deberíamos invertir nuestro tiempo/dinero en ello. Será una charla estilo masterclass y al finalizar, tendrás una infraestructura completa como código para una aplicación React en AWS escrita en TypeScript
Video Summary and Transcription
Esta charla cubre la infraestructura como código utilizando Terraform y CDK. El orador demuestra cómo construir la infraestructura para una aplicación React, incluyendo un bucket S3 y la conexión a un dominio real. También se discute la configuración del comportamiento de la caché, CloudFront y los backends remotos. TypeScript se destaca como un lenguaje poderoso para la infraestructura como código, y se enfatiza la importancia de la automatización y el código bien documentado para infraestructuras a escala global.
Available in English
1. Introducción a la Infraestructura como Código
Short description:
Vamos a hablar de infraestructura como código. Mi equipo en The Zone está cambiando la forma en que los fanáticos se involucran con los deportes. Tenemos una amplia gama de infraestructura. Para evitar errores manuales y garantizar la escalabilidad, necesitamos utilizar la infraestructura como código. Hay dos paradigmas de programación: imperativo y declarativo. Terraform, un software de código abierto, admite miles de proveedores y nos permite administrar la infraestructura con código, incluido TypeScript.
Genial. Sí, como dije, ahora vamos a hablar de infraestructura como código. Pero antes, permítanme presentarme y darles un poco de contexto sobre por qué lo necesitamos. ¿Qué está pasando? Genial. Mi nombre es Denys Artyukhovic. Soy el líder del equipo en The Zone. Originalmente, soy de Bielorrusia, pero ahora estoy basado en Londres. Y en The Zone, estamos cambiando todos los aspectos de cómo los fanáticos se involucran con los deportes, desde la distribución de contenido hasta una experiencia verdaderamente inmersiva en tiempo real donde puedes ver datos aumentados para las transmisiones de video. Estamos disponibles en más de 200 países y en varios tipos de dispositivos, incluidos televisores inteligentes, tabletas, computadoras portátiles y, por supuesto, Xbox, PS5 y otras consolas de juegos. Y creo que puedes imaginar la cantidad de infraestructura que tenemos. Y mi equipo ha construido características que son multiplataforma. Están disponibles en la web y en los televisores. Entonces, la respuesta ahora, probablemente sea obvia, pero consideremos el flujo normal de desarrollo de sus aplicaciones. Comenzamos con una característica, o digamos un servicio, luego una nueva y brillante idea llega al escenario y tenemos una característica más, y luego boom, cientos de ellas. Y en nuestro caso, podemos esperar cambios en nuestra infraestructura incluso varias veces al día, y creo que puedes imaginar lo estresante que podría ser si todo fuera manual, porque necesitas replicar algunos cambios manuales, ¿y qué pasa si algunos de los desarrolladores olvidan actualizar la documentación? ¿O qué pasa si la interfaz de usuario misma ha cambiado en nuestro proveedor de la nube, como AWS, y hacemos clic en la casilla de verificación incorrecta y Facebook no está disponible durante unas horas? Así que puede ser realmente estresante, ¿verdad? Para evitar esta situación y solucionar este problema y nunca tener un problema así, nuevamente, necesitamos aprovechar la infraestructura como código. Pero antes de comenzar a hablar sobre la infraestructura en sí, consideremos estos dos paradigmas de programación, ya que son bastante relevantes cuando hablamos de codificación para la infraestructura. Por un lado, tenemos el enfoque imperativo, que se basa en instrucciones explícitas para todo literalmente. Por lo general, nos referimos a algunos scripts de shell, y de hecho, la instrucción explícita es la mayor ventaja de este enfoque. Pero al mismo tiempo, es la mayor preocupación, porque debes mantener todo tú mismo y no es realmente escalable a lo largo del tiempo. Por otro lado, tenemos el enfoque declarativo, que se basa en describir el resultado y dejar que el proveedor haga el resto del trabajo, lo cual es mucho más fácil y mejor para escalar. Entonces, sí, nuevamente, con el enfoque imperativo, eres inteligente y siempre culpas al sistema de que no funciona como esperas, porque escribiste tantas líneas de código. Cuando con el enfoque declarativo, simplemente no te importa hasta que los proveedores inteligentes se encarguen de todo por ti. Y la buena noticia es que Terraform, en realidad, es un software de código abierto. ¿Quién ha trabajado con Terraform antes? Permítanme hacer esta pregunta primero. Sí. Ok. Algunas personas. Increíble. Entonces, Terraform es un software de código abierto que fue desarrollado originalmente por HashiCorp, y admite miles de proveedores diferentes, y nos permite administrar nuestra infraestructura con código, y lo que es más importante para hoy es que también admite TypeScript. O mejor dicho, CDK, que significa
2. Construyendo Infraestructura con Terraform y CDK
Short description:
Para implementar infraestructura, antes necesitabas aprender un nuevo lenguaje. El lenguaje de Terraform no es complejo y creo que es un cambio de juego. En los próximos 30 minutos, construiremos una infraestructura lista para producción para una aplicación de React, paso a paso. Comenzaremos creando carpetas e instalando CDK. Luego, usaremos React Create App para crear una aplicación básica de React con TypeScript. A continuación, inicializaremos el proyecto con CDK-TF, especificando una plantilla de TypeScript y un backend local. Si encuentras errores de TypeScript, agrega la bandera skip-loop check al archivo ts-config de Terraform.
El Kit de Desarrollo de la Nube, CDK, admite TypeScript. Y realmente creo que es un verdadero cambio de juego porque anteriormente, para implementar infraestructura, probablemente necesitabas aprender un nuevo lenguaje. Con el lenguaje de Terraform de HashiCorp, que no es malo, no es complejo, probablemente un poco más complejo que los archivos JSON o YAML, pero ya sabes, somos desarrolladores. Realmente me gusta el poder de los lenguajes de programación y he estado programando durante muchos años, y eso es con lo que me gustaría crear mi infraestructura, y sí, por eso creo que es un verdadero cambio de juego. Entonces, en los próximos 30 minutos, lo que vamos a hacer, quiero decir, probablemente un poco menos, vamos a construir la infraestructura lista para producción para nuestra aplicación de React, para ser honesto, incluso para cualquier aplicación de JS que elijas. Y sí, lo haremos paso a paso, será como una clase magistral, puedes seguir con las laptops, pero no te preocupes si necesitas tomarte tu tiempo, al final de la charla compartiré contigo todos los ejemplos de código y habrá un enlace al repositorio de GitHub para que puedas seguir más adelante, y estoy bastante seguro de que esta charla será grabada. Ok, así que podemos empezar. Entonces, déjame hacer esto porque es un poco extraño. Genial. ¿Puedes ver mi pantalla? Y solo un segundo, lo haré escalable para poder controlarlo. Ok, lo siento mucho. Acabo de desordenar las cosas. Pero todo bien ahora. Genial. Sí, el primer paso, lo que vamos a hacer, vamos a usar React Create. Espero que todos. Sí. Entonces vamos a usar React Create App solo para crear la aplicación básica de React con TypeScript y vamos a ejecutar este comando para hacerlo y después de esto tendremos esta aplicación bonita y brillante lista. Pero hasta ahora nada está relacionado con la infraestructura en sí. Ahora vamos a empezar creando algunas carpetas para nuestra infraestructura. Y como requisito previo, necesitamos instalar CDK. Puedes instalarlo a nivel global en tu máquina o puedes instalarlo por proyecto. Tú decides. Pero básicamente, tan pronto como tengamos CDK-TF, podemos crear una carpeta de proyecto y comenzar a configurar nuestra infraestructura. Para esto, voy a usar un comando que es CDK-TF init. Voy a pasar la plantilla como TypeScript, de manera similar a lo que hemos hecho para la aplicación de React, y voy a especificar un backend local. Si sabes lo que significa un backend local en términos de Terraform, genial. Si no, no te preocupes. Lo cubriremos un poco más adelante durante la charla. Después de la inicialización, es posible que veas errores relacionados con TypeScript y la razón de esto es porque estoy bastante seguro de que Terraform los abordará en breve, pero hasta ahora necesitas agregar skip-loop check porque realmente no espera que haya otro proyecto de TypeScript en el mismo proyecto. Tan pronto como agreguemos skip-loop check
3. Implementando Infraestructura con S3 Bucket
Short description:
Vamos a comenzar a implementar nuestra infraestructura utilizando el archivo main.ts. Más adelante, se puede refactorizar. Agregamos el proveedor de AWS a la configuración CDKTF.json y definimos nuestras necesidades de infraestructura. Lo primero que necesitamos es almacenamiento, específicamente un bucket de S3. Creamos el bucket con la configuración deseada, incluido el acceso de lectura público. Después de realizar los cambios necesarios, construimos y sintetizamos los cambios.
verifica la bandera check en el archivo ts-config de Terraform, todo estará bien. Y vamos a poder ver que hay un archivo TS que se genera para nosotros con el Stack Principal. Se llama main.ts. Y este archivo es básicamente lo que vamos a usar como punto de partida y donde comenzamos a implementar nuestra infraestructura. Por supuesto, porque es TypeScript, más adelante puedes crear, digamos, una carpeta de origen, estructurarla de la manera que prefieras, dividir todo en funciones reutilizables. Ahora lo haré todo en un solo archivo, pero más adelante se puede refactorizar de la manera que prefieras. Genial. Antes de comenzar, necesitamos agregar un proveedor de Terraform. Como dije, hay miles de proveedores disponibles para ti. Todos son de código abierto y puedes crear tu propio proveedor. Vamos a usar el proveedor de AWS, así que lo agregamos a la lista de proveedores en la configuración de CDKTF.json, y después de eso, estamos listos para continuar. Pero ahora necesitamos definir cómo se verá nuestra infraestructura, qué necesitamos realmente para nuestra aplicación frontend.
Y lo primero que podemos necesitar es almacenamiento, ¿verdad? Necesitamos almacenar nuestra aplicación en algún lugar. No sé cuántos de ustedes han trabajado con buckets de S3 en AWS, pero es solo un simple servicio de almacenamiento que tiene una gran disponibilidad, 99.99%, lo cual es genial, pero para nosotros, lo importante es que lo vamos a usar para almacenar nuestros activos estáticos, ¿de acuerdo? Entonces, para esto, podemos importar el proveedor de AWS y el bucket de S3. Esa va a ser una infraestructura simple que puedes imaginar, y es muy sencilla. Como va a estar lista para producción, más adelante planeo conectar un dominio real y por eso creo que podemos llamar al bucket con el nombre del dominio solo porque es más explícito. Vamos a crear un proveedor. Puedes usar cualquier región que prefieras. Yo voy a usar US-East-1. Solo un dato, para tu bucket, por ejemplo, puedes usar una región europea y EU Central-1, lo que sea. Eso está perfectamente bien, pero ACM, que vamos a usar para los certificados SSL más adelante, requiere la región US-East-1. No tiene nada que ver con cómo codificamos la infraestructura, solo está relacionado con cómo AWS opera. Ellos lo necesitan en sus requisitos. Si vas a crear otra región, simplemente crea la segunda más adelante para ACM. Genial. Estamos creando el bucket de S3, pasando solo el nombre del bucket, pasando el proveedor. Estamos diciendo que será un sitio web con index.html como documento raíz. También estamos especificando la lista de control de acceso como lectura pública, porque ¿a quién le importa la seguridad? Estoy bromeando, lo arreglaremos más adelante. Por ahora, déjalo como público. Tan pronto como hagas estos cambios, solo necesitas construirlos y ejecutar el comando YARN syns
4. Implementando una Aplicación React en un Bucket de S3
Short description:
Para implementar nuestra aplicación React en el bucket de S3, podemos usar Terraform o el comando AWS S3. Después de la implementación, el sitio estará disponible en la URL del bucket. Sin embargo, para que esté listo para producción, necesitamos conectarlo a un dominio real.
para sintetizar esos cambios. Después de esto, todo será transpilado. Se generará una carpeta CDKTF out en la que puedes ingresar y ejecutar comandos en el siguiente orden. Debes ejecutar Terraform init. Solo necesitas este comando la primera vez, porque estamos comenzando con Terraform. Después de esto, puedes ejecutar un plan. El plan es opcional. Es solo para ver qué se planea aplicar en nuestra infraestructura. Y después de eso, puedes ejecutar apply. Y si sigues estos pasos, verás una salida similar en tu terminal, que te dirá qué se creó. Lo verás en el sitio web y en el punto. Y ahora, podemos construir nuestra aplicación React con el comando Yarn build y implementar esta aplicación React en el bucket de S3. La implementación es un poco complicada. Puede ser manejada con Terraform cuando creas que está relacionada con tu infraestructura. Con el mundo del frontend, diría que no está estrechamente acoplada a la infraestructura porque vas a crear la infraestructura. No quieres esperar cambios en tu infraestructura todo el tiempo cuando estás actualizando la versión de React y agregando nuevas características. Por lo tanto, la implementación probablemente será separada en tu CI. Así que lo voy a hacer manualmente ahora usando el comando AWS S3. Estoy pasando la carpeta de salida que se ha construido y estoy pasando el nombre de mi bucket de S3 que acabo de usar. Y, nuevamente, estoy especificando ACL como lectura pública. Y después de esto, si lo descargas, podrás ver que tu sitio está disponible en esta URL, bucketname.s3. Amazon.AWS.com. Y también podemos comenzar a compartirlo con nuestros, no sé, amigos, QA, SPOs, lo que sea. Pero por supuesto, aún no está listo para producción, ¿verdad? Al menos necesitamos conectarlo con el dominio real. Entonces, sí, celebremos que hemos logrado algo.
5. Conectando al Dominio Real
Short description:
Para conectarnos al dominio real, utilizamos Route 53, el servicio DNS de AWS. Las solicitudes de los usuarios pasan a través de la infraestructura de AWS y son interceptadas por Route 53, que las redirige al bucket de S3. Especificamos la zona de Route 53, la creamos y creamos un registro para los subdominios, configurando nuestro bucket como un alias. Después de ejecutar el comando Terraform Apply y esperar la validación, todo estará creado. El dominio se redirigirá a nuestro bucket de S3, pero aún no es seguro y no está listo para producción. Para mejorar el rendimiento, utilizaremos CloudFront y ACM. CloudFront redirige a los usuarios desde Route 53 a la ubicación de borde más cercana, y ACM emite un certificado SSL asociado con nuestro dominio.
Primero, consideremos cómo conectarnos al dominio real. Para conectarnos, utilizaremos Route 53, que es el servicio DNS proporcionado por AWS. Ahora, nuestro flujo se verá así. Los usuarios que envían la solicitud pasan a través de la infraestructura de AWS, que es interceptada por Route 53, que redirige a los usuarios al bucket de S3. Para lograr esto, necesitaremos realizar algunos cambios. Especificaremos la zona de Route 53, la crearemos y utilizaremos nuestro dominio principal, ya que me gustaría crear la infraestructura para el subdominio. Crearé un registro para los subdominios y pasaré mi zona de alojamiento y la configuración de nuestro bucket como alias, lo que significa que todos los que accedan a este registro serán redirigidos al bucket. Nuevamente, ejecutamos los comandos de construcción, navegamos a la carpeta, planificamos y aplicamos. Ahora, si lo ejecutas, verás que, permíteme rebobinar esto, estoy un poco consciente del tiempo, verás que habrá un problema en el último paso. Veamos qué se ha creado en realidad. Vamos a la consola de AWS para Route 53 y veremos que se ha creado la zona de alojamiento y habrá incluso un registro, ¿entonces qué ha fallado? La cosa es que lo hice intencionalmente. Compré el dominio con un proveedor diferente porque creo que es un caso de uso común cuando tienes un dominio comprado en un proveedor diferente a AWS, y necesito conectarlos de alguna manera, así que para esto necesito copiar los servidores NS que ahora se generan en AWS y conectarlos a mi proveedor de dominio, ya que mi proveedor de dominio no tiene proveedores para Terraform, así que lo haré manualmente. Puedes hacerlo con Terraform también, pero sí, esto es algo que se hace una vez, así que mi proveedor de dominio está en Rusia, por eso ves la interfaz en ruso, pero tan pronto como lo conectemos, necesitamos esperar de 5 a 10 minutos hasta que se actualicen los NS y ahora ejecutamos el comando con Terraform Apply y esta vez veremos, permíteme rebobinar esto un poco, después de la validación que toma, no sé, unos minutos como máximo, veremos que todo se ha creado, sí, se ha creado un recurso, nada se ha destruido, nada ha cambiado, y ahora, si intentamos acceder a este dominio, veremos que se redirige a nuestro bucket de S3 y podemos ver nuestro sitio web, que nuevamente es realmente genial. Pero aún no es seguro y aún no está listo para producción, ya que estamos almacenando nuestro bucket de S3 en algún lugar de Estados Unidos, por lo que probablemente el tiempo de respuesta para nuestros clientes será lento, y necesitamos aprovechar todas las ubicaciones de borde, por lo que probablemente queramos utilizar un servicio CDN, también probablemente queramos utilizar HTTPS para conexiones seguras, así que hagamos estos cambios. Para estos cambios, utilizaremos CloudFront y ACM. CloudFront es un servicio CDN disponible en AWS. ACM, por otro lado, es el Administrador de Certificados. Para nosotros, es interesante porque emitirá un certificado SSL asociado con nuestro dominio. Bien, veamos ahora nuestro diagrama de infraestructura un poco más complejo. Ahora, el flujo será que el usuario comienza desde Route 53 y, en lugar de ir directamente al bucket de S3, será redirigido a la ubicación de borde más cercana. Y nuestro CloudFront será responsable de recuperar objetos para almacenar en caché solo en casos en que la caché se invalide o si es el primer intento de acceso y aún no se haya creado una caché. Genial, y ACM se utilizará para el certificado SSL. Creamos el certificado ACM de la siguiente manera. Utilizamos el proveedor ACM. Nuevamente, pasamos la configuración especificando un comodín para nuestro dominio principal, ya que me gustaría usarlo para todos los subdominios en el futuro, no solo para uno. Por eso hay este signo de asterisco. Crearé el registro de validación del certificado. Es solo un registro más para nuestro dominio que se utilizará para la validación. Y crearé la validación en sí, pasando el certificado ACM y el registro de validación del certificado. Entonces, nuevamente, necesitamos crear la distribución de CloudFront. Y por favor, no
6. Configurando el Comportamiento de la Caché y Corrigiendo ACL
Short description:
No los entiendo completamente. Es solo la forma final de configuración de nuestro estado que estamos tratando de lograr. Vamos a cubrir los métodos get, head y options para el comportamiento de la caché. Pasaremos nuestro certificado SSL y haremos el cambio final en Route 53. Ahora, nuestro sitio se carga más rápido y es más seguro. Necesitamos corregir nuestra ACL de lectura pública utilizando una identidad de acceso de origen. Este es el diagrama de infraestructura final listo para producción.
No te asustes si ves y piensas que hay muchas líneas de código. No los entiendo completamente. En realidad, son líneas muy sencillas cuando sabes cómo funciona AWS. Pero si trabajas con un proveedor de nube diferente, los aprenderás desde allí. Si no los conoces, no te preocupes. Solo ve a su sitio web del proveedor de Terraform y lee y comprende lo que representan. Pero es solo la forma final de configuración de nuestro estado que estamos tratando de lograr. Entonces, básicamente, aquí estoy especificando que el comportamiento de caché predeterminado será redirigir a HTTPS. Vamos a cubrir los métodos get, head y options porque no creo que necesitemos ningún método postal u otros para nuestro frontend. Vamos a establecer el TTL predeterminado como un día y no voy a especificar ninguna restricción o ningún orden para el comportamiento de la caché. Pero si quieres especificar un orden de comportamiento de caché, son excepciones. Por ejemplo, una carpeta específica que deseas cachear solo durante cinco minutos o como no deseas cachear el índice html en absoluto. Puedes especificarlo en el orden de comportamiento de caché, eso es lo que representa. Entonces, vamos a pasar nuestro certificado SSL, que acabamos de emitir con el certificado ACM. Y ahora, necesitamos hacer el cambio final en Route 53. En lugar de nuestro nombre de bucket, vamos a pasar el nombre de dominio de la distribución de CloudFront. Entonces, Route 53 no redirigirá al bucket de S3. Ahora, se redirigirá a la distribución de CloudFront y solo estamos cambiando el nombre y la zona alojada. Necesitamos ejecutar nuevamente yarn build, yarn scenes, ir a la carpeta CDK TF out, ejecutar plan y apply. Y después de que se complete la aplicación, veremos que ahora tenemos una conexión segura, pero además, nuestro sitio se carga más rápido. Y la razón de esto es porque ahora está disponible en todas las ubicaciones de borde. Así que hemos cubierto el CDN aquí. Y eso es muy genial. Pero recuerda, como dije al principio, ¿a quién le importa la seguridad? Ahora es el momento de pagar por ello. Y ahora es el momento de configurarlo. Entonces, ahora necesitamos corregir nuestra ACL de lectura pública. Y vamos a usar una identidad de acceso de origen para ello. Entonces, nuestro diagrama de infraestructura será un poco más complejo. Pero este es el final.
7. Configurando CloudFront y Backends Remotos
Short description:
Vamos a tener a Route 53 dirigiendo a ubicaciones de borde previamente. Ahora, vamos a tener CloudFront que va a recuperar objetos para caché. Pero lo que va a cambiar es que en esta ocasión, el bucket de S3 va a tener algunas políticas de bucket específicas asociadas. Y esta política de bucket específica va a verificar que solo las identidades de acceso de origen específicas puedan acceder a ella. Entonces, en este caso, nuestro CloudFront debe tener una identidad de acceso de origen asociada para acceder al bucket de S3. Y, por supuesto, después de este cambio, nuestro bucket no estará disponible públicamente. Para lograr esto, vamos a cambiar el ACL del bucket a privado, crear una identidad de acceso de origen, especificar el documento de política, crear la política del bucket y asociarla con el certificado ACM. Luego podemos eliminar todo del bucket y volver a implementarlo, utilizando el ACL privado predeterminado. El dominio de S3 ya no estará disponible, pero CloudFront y Route 53 funcionarán como se espera. Finalmente, hablemos de los backends remotos. Terraform tiene un concepto de backends, que se utilizan para almacenar el estado de salida. Hay varias opciones de backends, pero dado que estamos utilizando AWS, tiene sentido crear un backend de S3. Necesitamos especificar un bucket, una clave y una región. Una vez que hayamos hecho esto, podemos ejecutar init y elegir copiar el estado existente al backend remoto.
Uno. Este es el último listo para producción. Vamos a tener a Route 53 dirigiendo a ubicaciones de borde previamente. Ahora, vamos a tener CloudFront que va a recuperar objetos para caché. Pero lo que va a cambiar es que en esta ocasión, el bucket de S3 va a tener algunas políticas de bucket específicas asociadas. Y esta política de bucket específica va a verificar que solo las identidades de acceso de origen específicas puedan acceder a ella. ¿De acuerdo? Entonces, en este caso, nuestro CloudFront debe tener una identidad de acceso de origen asociada para acceder al bucket de S3. Y, por supuesto, después de este cambio, nuestro bucket no estará disponible públicamente. Genial. Entonces, para lograr esto, lo que necesitamos hacer es cambiar el ACL del bucket a privado. Vamos a crear una identidad de acceso de origen. Y después de esto, vamos a especificar el documento de política. Nuevamente, es solo la configuración que AWS quiere que pongamos. Aquí estoy diciendo que queremos tener acceso a los objetos y que vamos a tener acceso para obtener la lista de estos objetos. Y así de simple, luego creamos la política del bucket, pasando el ID del bucket y el documento de política en sí. Y asociándolo con el certificado ACM, esta identidad de acceso de origen para que nuestro CloudFront lo tenga. Ahora, por razones de simplicidad, la opción más simple es simplemente eliminar todo lo que hemos puesto en nuestro bucket y volver a implementarlo, sin especificar el ACL, y usar el predeterminado que será privado. Y tan pronto como lo hayamos hecho, podemos comprobar que el dominio de S3 ya no está disponible. Vamos a ver esta brillante página de error proporcionada por AWS por defecto, que dice que se denegó el acceso. Mientras tanto, CloudFront y Route 53, por otro lado, funcionarán perfectamente bien y eso es exactamente lo que estábamos tratando de lograr. Y déjame felicitarte, si estás sudando ahora como yo, te prometo que no hay más cosas relacionadas con la infraestructura que necesitamos codificar, pero hablemos de un par de ellas. Estamos cerca del final de esta presentación, pero aún quiero cubrir los backends remotos porque hasta ahora todo lo que hemos hecho lo hemos hecho en una máquina y localmente, y no funcionará si empezamos a compartirlo con nuestros compañeros de equipo. Entonces, puedes pensar que probablemente podemos subir nuestro estado de Terraform, el estado de Terraform, no sé, tal vez incluso a GitHub, pero es una mala idea, te lo prometo, porque se almacenarán información confidencial, y para esto, Terraform tiene un concepto de backends y esos backends, en realidad, hay muchos de ellos. Puedes usar diferentes bases de datos, por ejemplo, DynamoDB, puedes usar almacenamiento S3, puedes usar el almacenamiento de Terraform, no recuerdo cómo se llama, pero hay muchas opciones. Creo que, dado que nos quedamos con AWS, tiene sentido crear nuestro backend en AWS también, y creo que esto es algo bueno de hacer, y perdón, para aclarar, el backend es solo nuestro estado de salida. Básicamente, es un archivo JSON que proporciona información sobre qué recursos se han creado y cuál es el estado actual de nuestra infraestructura. Entonces, vamos a crear un backend de S3. Para esto, necesitamos pasar un bucket. Este es en realidad un bucket separado creado manualmente, por lo que puedes pasar cualquier bucket. Por lo general, en las empresas tienes algunos buckets privados que no están disponibles en ningún otro lugar. Y sí, vamos a pasar una clave, que es el nombre de nuestro archivo, y vamos a pasar una región, que puede ser cualquier región. Una vez que lo hayamos hecho, necesitamos ejecutar init, y esta vez, cuando lo ejecutes en tu terminal, verás que te pregunta si quieres
QnA
TypeScript y Infraestructura como Código
Short description:
TypeScript es más poderoso que el lenguaje de configuración de hash core, proporcionando autocompletado, tipos y otras ventajas. Permite una mejor estructuración y compartición de código, lo que lo hace relevante tanto para desarrolladores frontend como backend. También se puede gestionar la infraestructura de herramientas de monitoreo como New Relic y Sentry con Terraform. Ten en cuenta que, aunque Terraform está maduro, CDK aún está en beta. Los ejemplos de código y recursos adicionales están disponibles en los repositorios proporcionados.
Vamos a copiar el estado existente para eliminar el backend. Y si tu respuesta es sí, todo lo que se copie se transferirá al bucket de S3 y se eliminará de tu máquina local. Genial, ahora hablemos de por qué usamos TypeScript. ¿Por qué usamos TypeScript para la infraestructura como código? Creo que es genial que no haya un nuevo lenguaje que aprender, a pesar de que el lenguaje de configuración de hash core que mencioné anteriormente no es tan malo, pero la mayoría de nosotros conocemos TypeScript y no necesitamos agregar nada más. Además, TypeScript es sin duda mucho más poderoso que el lenguaje de configuración de hash core. Tenemos autocompletado, tenemos tipos, tenemos todas las ventajas de un lenguaje maduro. Puedes pensar en los métodos que tienes para mapas, reducciones, ciclos, estructuración con diferentes modelos. No puedes lograrlo realmente con el lenguaje de configuración de hash core. Necesitas almacenar todo en una carpeta y no hay una conexión clara de qué está referenciado a qué, y en mi opinión, es un completo desorden. Pero ahora tenemos más opciones para la estructuración del código y nuevas formas de compartir, y aquí estoy hablando de que antes podíamos crear módulos o complementos de Terraform por separado, pero eran cosas completas y estaban completamente separadas del frontend. Ahora podemos usar NPM y compartir nuestro código con NPM, e incluso podemos implementar pruebas para nuestra infraestructura también. Además, quiero destacar, porque es muy importante, que intenté que esta charla se centrara en los desarrolladores frontend, porque veo que muchos desarrolladores backend conocen el concepto de infraestructura como código cuando no es exactamente así en el mundo frontend. Pero creo que es bastante relevante para ambos mundos, no solo para crear la infraestructura de tu propia aplicación, sino también para la infraestructura de tu monitoreo. Por ejemplo, tienes New Relic y quieres especificar algunas alertas o crear paneles de control, o digamos que tienes Sentry para este propósito. Nuevamente, todo se puede gestionar y, en mi opinión, debería gestionarse con proveedores de infraestructura como código, en este caso, Terraform. Por lo tanto, puedes manejar la gestión de incidentes con pager duty y nuevamente crear la infraestructura para esto con Terraform. Solo un comentario aparte, Terraform en sí mismo ya se utiliza ampliamente en producción en todo el mundo, pero CDK aún no. Actualmente está en fase beta, por lo que puedes esperar algunos cambios en CDK, así que ten cuidado con eso, y sí, no sería justo no mencionarlo. Y ahora, como prometí, todos los ejemplos de código están disponibles en este repositorio que puedes ver en la diapositiva. Intenté seguir la historia de Comet durante la charla, para que puedas seguir esta charla. Y muchas gracias, eso es todo, y hay otro repositorio, Terraform TypeScript Frontend Infrastructure, que tiene una estructuración ligeramente más avanzada y un poco más de ejemplos, así que si estás interesado, también puedes echarle un vistazo. Y ahora creo que tenemos una sesión de preguntas y respuestas si todavía hay tiempo, ¿verdad? De nada. Gracias. Sí. Bueno, toma asiento, ahora podemos relajarnos. ¿Te gustaría algo de beber? Oh, no, estoy bien. Aplaudiré para la audiencia remota, probablemente estén aplaudiendo en casa, y... gritando a su pantalla, suena un poco negativo, pero de manera positiva. Así que quiero pasar a las preguntas, y como recordatorio, aún puedes hacer preguntas si estás aquí, también estoy usando Slido, y al final Denise seleccionará la mejor pregunta y le daremos una camiseta de React Advanced al ganador. La primera pregunta es de Bruno Palino, la infraestructura de sitios estáticos es increíble, pero ¿qué pasa cuando necesitas servidores reales e implementaciones de aplicaciones con bases de datos, puedes manejar todo esto con Terraform? Sí, absolutamente, quiero decir, para eso está Terraform, para manejar todo esto, incluidas las bases de datos, incluyendo la infraestructura variada que puedas imaginar para tus microservicios o aplicaciones monolíticas o lo que sea, así que creo que es bastante popular entre todos los ingenieros de DevOps y backend y lo usamos bastante extensamente. Genial, okay, la siguiente pregunta es de Anónimo, así que Anónimo no recibirá una camiseta, podemos, oh, esto es incorrecto, esto no debería estar aquí, estoy leyendo las preguntas en voz alta, eso no debería ser preguntas.
Discusión sobre Infraestructura y Escala Global
Short description:
La mayoría de nuestras infraestructuras en Dazone se crean con Terraform, pero usamos Azure Corp Configuration Language en lugar de TypeScript. Somos una empresa global con millones de clientes, por lo que la automatización y el código bien documentado son cruciales para nosotros.
Entonces, ¿todo lo que nos mostraste son cosas que también usas en Dazone? Sí, claro, en realidad, la mayoría de nuestras infraestructuras se crean por supuesto con Terraform, pero usamos Azure Corp Configuration Language en lugar de TypeScript, estamos comenzando a adoptar TypeScript, pero como dije, todavía está en fase beta, por lo que debes tener cuidado con esto y debes tener en cuenta las preocupaciones relacionadas con la mantenibilidad si hay cambios significativos relacionados con ello, así que debería ser una llamada de atención.
Eres una empresa global y cualquier cambio es un gran cambio, supongo que es realmente difícil probar cosas a tu escala. Sí, absolutamente, quiero decir, estamos disponibles para millones de clientes en todo el mundo, por lo que para nosotros es cada vez más crucial automatizar todo lo que podamos y documentarlo bien con código, así que pongámoslo así.
Bien, como no tenemos más preguntas en este momento, creo que terminaremos la sesión de preguntas y respuestas o actualizaré si ha habido alguna pregunta en el ínterin. Si recibo algún data. Disculpen a todos los que estaban en línea y tuvieron problemas de audio, no fue desde mi computadora portátil, algo sucedió. Sí, se solucionó en los primeros minutos. Mi data es realmente mala aquí en Londres. Y necesito moderar las preguntas antes de que aparezcan allí y allá. Oh, no te preocupes. Y no tengo data. Pero, sí, Deniz, muchas gracias. Y pasaremos al siguiente ponente entonces. Sí, muchas gracias. Así que todos, un aplauso más para Deniz.
