Infraestructura como Código para Aplicaciones React en AWS Escritas en TypeScript

Rate this content
Bookmark

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

30 min
22 Oct, 2021

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
React Day Berlin 2023React Day Berlin 2023
21 min
React's Most Useful Types
We don't think of React as shipping its own types. But React's types are a core part of the framework - overseen by the React team, and co-ordinated with React's major releases.In this live coding talk, we'll look at all the types you've been missing out on. How do you get the props type from a component? How do you know what ref a component takes? Should you use React.FC? And what's the deal with JSX.Element?You'll walk away with a bunch of exciting ideas to take to your React applications, and hopefully a new appreciation for the wonders of React and TypeScript working together.
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.
Vue.js London 2023Vue.js London 2023
30 min
Stop Writing Your Routes
The more you keep working on an application, the more complicated its routing becomes, and the easier it is to make a mistake. ""Was the route named users or was it user?"", ""Did it have an id param or was it userId?"". If only TypeScript could tell you what are the possible names and params. If only you didn't have to write a single route anymore and let a plugin do it for you. In this talk we will go through what it took to bring automatically typed routes for Vue Router.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Top Content
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Node Congress 2024Node Congress 2024
83 min
Deep TypeScript Tips & Tricks
Workshop
TypeScript has a powerful type system with all sorts of fancy features for representing wild and wacky JavaScript states. But the syntax to do so isn't always straightforward, and the error messages aren't always precise in telling you what's wrong. Let's dive into how many of TypeScript's more powerful features really work, what kinds of real-world problems they solve, and how to wrestle the type system into submission so you can write truly excellent TypeScript code.
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
Workshop
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
 
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
 
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
 
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.
TypeScript Congress 2022TypeScript Congress 2022
116 min
Advanced TypeScript types for fun and reliability
Workshop
If you're looking to get the most out of TypeScript, this workshop is for you! In this interactive workshop, we will explore the use of advanced types to improve the safety and predictability of your TypeScript code. You will learn when to use types like unknown or never. We will explore the use of type predicates, guards and exhaustive checking to make your TypeScript code more reliable both at compile and run-time. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Are you familiar with the basics of TypeScript and want to dive deeper? Then please join me with your laptop in this advanced and interactive workshop to learn all these topics and more.
You can find the slides, with links, here: http://theproblemsolver.nl/docs/ts-advanced-workshop.pdf
And the repository we will be using is here: https://github.com/mauricedb/ts-advanced