Este lab se desarrolló junto con nuestro socio HashiCorp. Es posible que tu información personal se comparta con HashiCorp, el patrocinador del lab, si aceptaste recibir actualizaciones, anuncios y ofertas de productos en el perfil de tu cuenta.

GSP752

Descripción general

Terraform debe almacenar el estado sobre tu infraestructura y configuración administradas. El software usa este estado para asignar recursos reales a tu configuración, realizar un seguimiento de los metadatos y mejorar el rendimiento de infraestructuras grandes.

Este estado se almacena de forma predeterminada en un archivo local llamado terraform.tfstate, pero también se puede almacenar de forma remota, lo que funciona mejor en un entorno de trabajo de equipo.

Terraform usa este estado local para crear planes y realizar cambios a tu infraestructura. Antes de cualquier operación, Terraform actualiza el estado con la infraestructura real.

La finalidad principal del estado de Terraform es almacenar vinculaciones entre objetos en un sistema remoto y las instancias de recursos que declares en tu configuración. Cuando Terraform crea un objeto remoto en respuesta a los cambios de la configuración, registrará la identidad de ese objeto con respecto a una instancia de recurso particular, y potencialmente actualizará o eliminará el objeto en respuesta a futuros cambios en la configuración.

Objetivos

En este lab, aprenderás a realizar las siguientes tareas:

• Crear un backend local
• Crear un backend de Cloud Storage
• Actualizar tu estado de Terraform
• Importar una configuración de Terraform
• Administrar la configuración importada con Terraform

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

Lee estas instrucciones. Los labs son cronometrados y no se pueden pausar. El cronómetro, que comienza a funcionar cuando haces clic en Comenzar lab, indica por cuánto tiempo tendrás a tu disposición los recursos de Google Cloud.

Este lab práctico te permitirá realizar las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, se te proporcionan credenciales temporales nuevas que utilizarás para acceder a Google Cloud durante todo el lab.

Para completar este lab, necesitarás lo siguiente:

• Acceso a un navegador de Internet estándar (se recomienda el navegador Chrome)

Nota: Usa una ventana de navegador privada o de Incógnito para ejecutar este lab. Así evitarás cualquier conflicto entre tu cuenta personal y la cuenta de estudiante, lo que podría generar cargos adicionales en tu cuenta personal.

• Tiempo para completar el lab: Recuerda que, una vez que comienzas un lab, no puedes pausarlo.

Nota: Si ya tienes un proyecto o una cuenta personal de Google Cloud, no los uses en este lab para evitar cargos adicionales en tu cuenta.

Cómo iniciar tu lab y acceder a la consola de Google Cloud

1. Haga clic en el botón Comenzar lab. Si debe pagar por el lab, se abrirá una ventana emergente para que seleccione su forma de pago. A la izquierda, se encuentra el panel Detalles del lab, que tiene estos elementos:

   • El botón Abrir la consola de Google Cloud
   • El tiempo restante
   • Las credenciales temporales que debe usar para el lab
   • Otra información para completar el lab, si es necesaria

2. Haz clic en Abrir la consola de Google Cloud (o haz clic con el botón derecho y selecciona Abrir el vínculo en una ventana de incógnito si ejecutas el navegador Chrome).

   El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.

   Sugerencia: Ordene las pestañas en ventanas separadas, una junto a la otra.

   Nota: Si ves el diálogo Elegir una cuenta, haz clic en Usar otra cuenta.

3. De ser necesario, copia el nombre de usuario a continuación y pégalo en el diálogo Acceder.

   {{{user_0.username | "Username"}}}

   También puedes encontrar el nombre de usuario en el panel Detalles del lab.

4. Haz clic en Siguiente.

5. Copia la contraseña que aparece a continuación y pégala en el diálogo Te damos la bienvenida.

   {{{user_0.password | "Password"}}}

   También puedes encontrar la contraseña en el panel Detalles del lab.

6. Haz clic en Siguiente.

   Importante: Debes usar las credenciales que te proporciona el lab. No uses las credenciales de tu cuenta de Google Cloud. Nota: Usar tu propia Cuenta de Google podría generar cargos adicionales.

7. Haga clic para avanzar por las páginas siguientes:

   • Acepta los Términos y Condiciones.
   • No agregues opciones de recuperación o autenticación de dos factores (esta es una cuenta temporal).
   • No te registres para obtener pruebas gratuitas.

Después de un momento, se abrirá la consola de Google Cloud en esta pestaña.

Nota: Para ver un menú con una lista de productos y servicios de Google Cloud, haz clic en el menú de navegación que se encuentra en la parte superior izquierda.

Activa Cloud Shell

Cloud Shell es una máquina virtual que cuenta con herramientas para desarrolladores. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud. Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.

1. Haz clic en Activar Cloud Shell en la parte superior de la consola de Google Cloud.

Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu PROJECT_ID. El resultado contiene una línea que declara el PROJECT_ID para esta sesión:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con la función de autocompletado con tabulador.

2. Puedes solicitar el nombre de la cuenta activa con este comando (opcional):

gcloud auth list

3. Haz clic en Autorizar.

4. Ahora, el resultado debería verse de la siguiente manera:

Resultado:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. Puedes solicitar el ID del proyecto con este comando (opcional):

gcloud config list project

Resultado:

[core] project = <project_ID>

Resultado de ejemplo:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: Para obtener toda la documentación de gcloud, consulta la guía con la descripción general de gcloud CLI en Google Cloud.

Finalidad del estado de Terraform

El estado es un requisito necesario para el correcto funcionamiento de Terraform. En ocasiones, los usuarios preguntan si Terraform funciona sin estado o puede no usar uno y sencillamente inspeccionar recursos en la nube en cada ejecución. En los casos en los que Terraform podría ejecutarse sin un estado, hacerlo requeriría trasladar una cantidad muy significativa de la complejidad de un lugar (el estado) a otro (el concepto que lo sustituye). Esta sección explica por qué es necesario el estado de Terraform.

Asignación al mundo real

Terraform requiere algún tipo de base de datos para asignar la configuración de Terraform con recursos del mundo real. Cuando tu configuración contiene una declaración resource "google_compute_instance" "foo", Terraform la usa para saber que la instancia i-abcd1234 está representada por ese recurso.

Terraform espera que cada objeto remoto se vincule a una sola instancia de recurso. Esto normalmente está garantizado porque Terraform es responsable de crear los objetos y registrar tus identidades en el estado. Si en su lugar importas objetos que se crearon fuera de Terraform, debes verificar que cada uno por separado se importe a una única instancia de recurso.

Si un objeto remoto se vincula a dos o más instancias de recurso, Terraform podría realizar acciones inesperadas con respecto a esos objetos, puesto que la asignación desde la configuración al estado del objeto remoto se volvió ambigua.

Metadatos

Además del seguimiento de las asignaciones entre recursos y objetos remotos, Terraform también debe hacer el seguimiento de metadatos, como las dependencias de recursos.

De manera habitual, Terraform usa la configuración para determinar el orden de la dependencia. Sin embargo, cuando quites un recurso de una de tus configuraciones, Terraform debe saber cómo eliminarlo. Terraform puede reconocer que existe una asignación para un recurso que no se encuentre en tu archivo de configuración y que planees destruir. Sin embargo, dado que el recurso ya no existe, no se puede determinar el orden solo a partir de la configuración.

Para garantizar una correcta operación, Terraform retiene una copia del conjunto de dependencias más reciente dentro del estado. Ahora bien, Terraform aún puede determinar el orden correcto para la destrucción a partir del estado cuando eliminas uno o más elementos de la configuración.

Esto se podría evitar si Terraform conociera el orden requerido entre los distintos tipos de recursos. Por ejemplo, Terraform podría saber que los servidores se deben eliminar antes que las subredes de las que forman parte. Sin embargo, la complejidad de este enfoque pronto se vuelve difícil de administrar: además de comprender la semántica de orden de cada recurso para cada nube, Terraform también debe entender el orden entre los distintos proveedores.

Por otra parte, Terraform almacena otros metadatos por motivos similares, por ejemplo, un puntero a la configuración del proveedor usada más recientemente con el recurso en situaciones en las que están presentes varios proveedores que utilizan un alias.

Rendimiento

Además de la asignación básica, Terraform almacena una caché de valores de atributos para todos los recursos en el estado. Esta es una función opcional del estado de Terraform, y se usa solo como una mejora de rendimiento.

Cuando se ejecuta el comando terraform plan, Terraform debe conocer el estado actual de los recursos para determinar de manera efectiva los cambios necesarios para alcanzar la configuración que deseas.

Para infraestructuras pequeñas, Terraform puede hacer una búsqueda entre tus proveedores y sincronizar los atributos más recientes a partir de todos tus recursos. Este es el comportamiento predeterminado de Terraform: para cada comando plan y apply, Terraform sincronizará todos los recursos en tu estado.

Para infraestructuras más grandes, la búsqueda de cada recurso es demasiado lenta. Muchos proveedores de servicios en la nube no proporcionan APIs para consultar múltiples recursos simultáneamente, y el tiempo de ida y vuelta para cada recurso es de cientos de milisegundos. Por otra parte, los proveedores de servicios en la nube suelen tener límites de frecuencia de API, por lo que Terraform solo puede solicitar una cantidad limitada de recursos en un período. Otros usuarios de Terraform con necesidades más grandes frecuentemente usan las marcas -refresh=false y -target para solucionar esta situación. En estos casos, el estado almacenado en caché se trata como un registro de certeza.

Sincronización

Según la configuración predeterminada, Terraform almacena el estado en un archivo en el directorio de trabajo actual en el que se ejecuta Terraform. Esto funciona cuando comienzas a trabajar, pero, cuando se usa Terraform en equipo, es importante que todos trabajen con el mismo estado de manera que las operaciones se apliquen a los mismos objetos remotos.

La solución recomendada para este problema es el estado remoto. Gracias a su backend de estado con todas las funciones, Terraform puede usar el bloqueo remoto como medida para evitar que distintos usuarios ejecuten Terraform accidentalmente al mismo tiempo, lo cual garantiza que cada instancia de ejecución de Terraform se inicie con el estado actualizado más reciente.

Bloqueo de estado

Si tu backend lo admite, Terraform bloqueará tu estado para todas las operaciones que podrían escribirlo. Esto evita que otros usuarios adquieran la información del bloqueo y corrompan tu estado.

El bloqueo de estado sucede automáticamente en todas las operaciones que podrían escribirlo. No verás ningún mensaje de que esto sucede. Si falla el bloqueo de estado, Terraform no continuará. Puedes inhabilitar el bloqueo de estado para la mayoría de los comandos con la marca -lock, pero no se recomienda hacerlo.

Si la adquisición de la información de bloqueo tarda más de lo esperado, Terraform mostrará un mensaje de estado. Si Terraform no muestra un mensaje, el bloqueo de estado todavía está en efecto.

No todos los backends admiten el bloqueo. Consulta la lista de tipos de backend para obtener detalles al respecto.

Lugares de trabajo

Cada configuración de Terraform tiene un backend asociado que define la manera en que se ejecutan las operaciones y donde se almacenan los datos persistentes, como el estado de Terraform.

Los datos persistentes que se almacenan en el backend pertenecen a un lugar de trabajo. Inicialmente, el backend tiene un solo lugar de trabajo, llamado default y, por lo tanto, solo un estado de Terraform se asocia con esa configuración.

Algunos backends admiten múltiples lugares de trabajo con nombre, lo que permite asociar varios estados con una sola configuración. En todo caso, la configuración tiene un solo backend, aunque se pueden implementar varias instancias distintas de esa configuración sin tener que configurar un nuevo backend o cambiar las credenciales de autenticación.

Tarea 1. Trabaja con backends

Un backend en Terraform determina la manera en que se carga el estado y cómo se ejecuta una operación como apply. Esta abstracción permite el almacenamiento de estado de archivos no locales, la ejecución remota, etcétera.

De forma predeterminada, Terraform usa el backend “local”, que es el comportamiento habitual que conoces. Este es el backend que se invocaba en los labs anteriores.

Estos son algunos de los beneficios de los backends:

• Trabajo en equipo: Los backends pueden almacenar su estado de manera remota y protegerlo con bloqueos para evitar su corrupción. Algunos backends, como Terraform Cloud, pueden almacenar automáticamente un historial de todas las revisiones del estado.
• Mantener información sensible fuera del disco: el estado se recupera de los backends según demanda y solo se almacena en la memoria.
• Operaciones remotas: para infraestructuras de mayor tamaño o ciertos cambios, la instrucción terraform apply puede llevar mucho tiempo. Algunos backends admiten operaciones remotas, lo que permite que la operación se ejecute de este modo. Puedes apagar tu computadora, y tu operación se completará de cualquier manera. Cuando se combina con el almacenamiento de estado remoto y el bloqueo (que se describió más arriba), esto también es útil en entornos de trabajo en equipo.

Los backends son completamente opcionales: puedes utilizar Terraform de forma correcta sin tener que aprender a usar los backends. Sin embargo, resuelven puntos débiles que afectan a los equipos a determinada escala. Si trabajas de forma independiente, probablemente no tengas necesidad de usar un backend.

Incluso si tu intención es usar solo el backend “local”, podría ser útil aprender sobre el tema porque también puedes cambiar el comportamiento del backend local.

Agrega un backend local

En esta sección, configurarás un backend local.

Cuando configures un backend por primera vez (con lo que pasas de no tener un backend definido a configurar uno explícitamente), Terraform te dará la opción de migrar tu estado al backend nuevo. Esto te permite adoptar backends sin perder los estados existentes.

Para mayor precaución, te recomendamos que también crees manualmente una copia de seguridad de tu estado. Para hacerlo, simplemente copia tu archivo terraform.tfstate en otra ubicación. El proceso de inicialización debería crear una copia de seguridad, pero nunca sobran las medidas adicionales.

Configurar un backend por primera vez no es diferente de hacer cambios en el futuro: se crea la nueva configuración y se ejecuta terraform init. Terraform te guiará por el resto del proceso.

1. En una ventana nueva de Cloud Shell, crea el archivo de configuración main.tf:

touch main.tf

2. Para recuperar el ID del proyecto, ejecuta el siguiente comando:

gcloud config list --format 'value(core.project)'

3. En la barra de herramientas de Cloud Shell, haz clic en Abrir editor. Para pasar de Cloud Shell al editor de código, haz clic en Abrir editor o Abrir terminal según sea necesario, o bien haz clic en Abrir en una nueva ventana para dejar el editor abierto en una pestaña distinta.

4. Copia el código de recurso para el bucket de Cloud Storage en tu archivo de configuración main.tf. Esto sustituye las definiciones de las variables project y name con tu ID del proyecto:

provider "google" { project = "# REPLACE WITH YOUR PROJECT ID" region = "{{{project_0.default_region | REGION}}}" } resource "google_storage_bucket" "test-bucket-for-state" { name = "# REPLACE WITH YOUR PROJECT ID" location = "US" uniform_bucket_level_access = true }

Obtén más información sobre los recursos de Cloud Storage en la Documentación de Terraform.

5. Agrega un backend local a tu archivo main.tf:

terraform { backend "local" { path = "terraform/state/terraform.tfstate" } }

Esto hace referencia a un archivo terraform.tfstate en el directorio terraform/state. Para especificar una ruta de archivo diferente, cambia la variable path.

El backend local almacena el estado en el sistema de archivos local, bloquea ese estado mediante las APIs del sistema y realiza operaciones de manera local.

Terraform debe inicializar cualquier backend que se haya configurado antes de usarlo. Para hacerlo, debes ejecutar terraform init. Como primer paso, cualquier miembro de tu equipo debe ejecutar el comando terraform init en cualquier configuración de Terraform. Es seguro ejecutarlo varias veces, además de que realiza todas las acciones de configuración que requiere un entorno de Terraform, incluida la inicialización del backend.

El comando init debe llamarse en los siguientes casos:

• En un entorno nuevo que configura un backend
• Ante cualquier cambio a la configuración del backend (esto incluye su tipo)
• Cuando se elimina por completo la configuración del backend

No es necesario que recuerdes estos casos exactos. Terraform detectará si es necesaria la inicialización y presentará un mensaje de error en tal situación. Terraform no se inicializa automáticamente porque podría requerir información adicional por parte del usuario o realizar migraciones de estado, entre otras situaciones.

6. En la barra de herramientas de Cloud Shell, haz clic en Abrir terminal, luego inicializa Terraform:

terraform init

7. Aplica los cambios. Escribe yes cuando recibas el prompt de confirmación:

terraform apply

El editor de Cloud Shell ahora debería mostrar el archivo de estado llamado terraform.tfstate en el directorio terraform/state.

8. Examina tu archivo de estado:

terraform show

Debe aparecer tu recurso google_storage_bucket.test-bucket-for-state.

Agrega un backend de Cloud Storage

Un backend de Cloud Storage almacena el estado como un objeto en un prefijo configurable en un bucket determinado de Cloud Storage. Este backend admite además el bloqueo de estado para todas las operaciones que podrían escribirlo, lo cual evita que otros usuarios adquieran la información del bloqueo y corrompan tu estado.

El bloqueo de estado sucede automáticamente en todas las operaciones que podrían escribirlo. No verás ningún mensaje de que esto sucede. Si falla el bloqueo de estado, Terraform no continuará. Puedes inhabilitar el bloqueo de estado para la mayoría de los comandos con la marca -lock, pero no se recomienda hacerlo.

1. Navega a tu archivo main.tf en el editor. Ahora sustituirás el backend local actual con un backend gcs.

2. Para modificar la configuración del backend local existente, copia la siguiente configuración en tu archivo, con lo que se sustituye el backend local:

terraform { backend "gcs" { bucket = "# REPLACE WITH YOUR BUCKET NAME" prefix = "terraform/state" } } Nota: Asegúrate de actualizar la definición de variables del bucket. Si no modificaste la configuración, será la variable name del recurso google_storage_bucket. Este bucket se usará para alojar el archivo de estado.

3. Inicializa de nuevo tu backend; esta vez, se migrará automáticamente el estado:

terraform init -migrate-state

Escribe yes cuando recibas el prompt de confirmación.

4. En el menú de navegación de la consola de Cloud, haz clic en Cloud Storage > Buckets.

5. Haz clic en tu bucket y navega al archivo terraform/state/default.tfstate. Tu archivo de estado ahora existe en un bucket de Cloud Storage.

Nota: Si ya no deseas utilizar un backend, puedes quitar la configuración del archivo. Terraform detectará que esto es como cualquier otro cambio y te pedirá reinicializar.

Como parte de la reinicialización, Terraform te preguntará si deseas migrar tu estado al estado local normal. Cuando complete este proceso, Terraform regresará a su comportamiento predeterminado.

Actualiza el estado

El comando terraform refresh se usa para conciliar el estado del que Terraform tiene conocimiento (mediante tu archivo de estado) con la infraestructura del mundo real. Esto se puede usar para detectar cualquier desvío del último estado conocido y actualizar el archivo de estado.

Esto no modifica la infraestructura, solo el archivo de estado. Si el estado cambia, podría provocar cambios durante la siguiente ejecución de los comandos plan o apply.

1. Regresa a tu bucket de almacenamiento en la consola de Cloud. Selecciona la casilla de verificación que se encuentra junto al nombre.

2. Haz clic en la pestaña Etiquetas.

3. Haz clic en Agregar etiqueta. Establece la Clave 1 = key y el Valor 1 = value.

4. Haz clic en Guardar.

5. Regresa a Cloud Shell y usa el siguiente comando para actualizar el archivo de estado:

terraform refresh

6. Examina las actualizaciones:

terraform show

Debe mostrarse el par clave-valor "key" = "value" en el atributo de etiquetas de la configuración.

Haz clic en Revisar mi progreso para verificar el objetivo. Trabajar con backends

Limpia tu espacio de trabajo

Antes de pasar a la siguiente tarea, destruye tu infraestructura aprovisionada.

1. Primero, revierte tu backend a local, de manera que puedas borrar el bucket de almacenamiento. Sustituye la configuración gcs con lo siguiente:

terraform { backend "local" { path = "terraform/state/terraform.tfstate" } }

2. Inicializa de nuevo el backend local:

terraform init -migrate-state

Escribe yes cuando recibas el prompt de confirmación.

3. En el archivo main.tf, agrega el argumento force_destroy = true a tu recurso google_storage_bucket. Cuando borras un bucket, esta opción booleana borrará todos los objetos ahí contenidos. Si intentas borrar un bucket que contiene objetos, Terraform no se ejecutará. Tu configuración de recursos debe ser similar a la siguiente:

resource "google_storage_bucket" "test-bucket-for-state" { name = "qwiklabs-gcp-03-c26136e27648" location = "US" uniform_bucket_level_access = true force_destroy = true }

4. Aplica los cambios:

terraform apply

Escribe yes cuando recibas el prompt de confirmación.

5. Ahora puedes destruir correctamente tu infraestructura:

terraform destroy

Escribe yes cuando recibas el prompt de confirmación.

Tarea 2: Importa la configuración de Terraform

En esta sección, importarás un contenedor de Docker y una imagen existentes a un espacio de trabajo vacío de Terraform. Con ello, conocerás estrategias y consideraciones para importar infraestructura del mundo real a Terraform.

El flujo de trabajo predeterminado de Terraform implica la creación y administración completa de infraestructuras con Terraform.

• Escribe una configuración de Terraform que defina la infraestructura que deseas crear.

• Revisa el plan de Terraform para asegurarte de que la configuración tendrá como resultado el estado y la infraestructura esperados.

• Aplica la configuración para crear tu estado e infraestructura de Terraform.

Después de crear la infraestructura con Terraform, puedes actualizar la configuración, planificar y aplicar dichos cambios. Cuando ya no sea necesaria, usarás Terraform para destruir la infraestructura. Este flujo de trabajo asume que Terraform creará una infraestructura completamente nueva.

Sin embargo, es posible que debas administrar la infraestructura que Terraform no cree. La importación con Terraform resuelve este problema, ya que carga los recursos admitidos en el estado del lugar de trabajo de Terraform.

Sin embargo, el comando import no genera automáticamente la configuración para administrar la infraestructura. Por ello, importar la infraestructura existente en Terraform es un proceso que requiere varios pasos.

Poner la infraestructura existente bajo el control de Terraform requiere los siguientes cinco pasos principales:

• Identificar la infraestructura existente que se debe importar
• Importar la infraestructura a tu estado de Terraform
• Escribir una configuración de Terraform que coincida con dicha infraestructura
• Revisar el plan de Terraform para garantizar que la configuración coincide con el estado y la infraestructura esperados
• Aplicar la configuración para actualizar tu estado de Terraform

En esta sección, crearás primero un contenedor de Docker con la CLI de Docker. Luego, lo importarás al nuevo espacio de trabajo de Terraform para actualizar la configuración del contenedor con Terraform antes de destruirla cuando termines.

Advertencia: Importar una infraestructura manipula el estado de Terraform en formas que podrían hacer que los proyectos existentes tengan un estado no válido. Haz una copia de seguridad de tu archivo terraform.tfstate y del directorio .terraform antes de utilizar la importación de Terraform en un proyecto real. Almacena estas copias en un lugar seguro.

Crea un contenedor de Docker

1. Crea un contenedor llamado hashicorp-learn mediante la imagen más reciente de NGINX desde Docker Hub. Luego, obtén una vista previa del contenedor en la máquina virtual de Cloud Shell en el puerto 80 (HTTP):

docker run --name hashicorp-learn --detach --publish 8080:80 nginx:latest

2. Sigue estos pasos para verificar que el contenedor se esté ejecutando:

docker ps

3. En el panel de Cloud Shell, haz clic en Vista previa en la Web y, luego, en Vista previa en el puerto 8080.

Cloud Shell abre la URL de la vista previa en su servicio de proxy en una ventana nueva del navegador y muestra la página predeterminada del índice de NGINX. Ahora tienes una imagen y un contenedor de Docker para importarlos a tu espacio de trabajo y administrarlos con Terraform.

Importa el contenedor a Terraform

1. Clona el repositorio de ejemplo:

git clone https://github.com/hashicorp/learn-terraform-import.git

2. Cambia a ese directorio:

cd learn-terraform-import

Este directorio contiene dos archivos de configuración de Terraform que conforman la configuración que usarás en esta guía:

• El archivo main.tf configura el proveedor de Docker.
• El archivo docker.tf contiene la configuración necesaria para administrar el contenedor de Docker que creaste en un paso anterior.

3. Inicializa tu espacio de trabajo de Terraform:

terraform init Nota: Si recibes un error como Error: Failed to query available provider packages, ejecuta el comando terraform init -upgrade.

4. En el editor de Cloud Shell, navega a learn-terraform-import/main.tf.

5. Busca el recurso provider: docker y marca como comentario o borra el argumento de host:

provider "docker" { # host = "npipe:////.//pipe//docker_engine" } Nota: Esta es la solución alternativa actual para un problema conocido con un error de inicialización de Docker.

6. A continuación, navega a learn-terraform-import/docker.tf.

7. En el código marcado como comentario, define un recurso docker_container vacío en tu archivo docker.tf, que representa un contenedor de Docker con el ID de recurso de Terraform docker_container.web:

resource "docker_container" "web" {}

8. Busca el nombre del contenedor que deseas importar; en este caso, es el contenedor que creaste en el paso anterior:

docker ps

9. Ejecuta el siguiente comando terraform import para conectar el contenedor de Docker existente al recurso docker_container.web que acabas de crear. La importación de Terraform requiere este ID de recurso, así como el ID completo del contenedor de Docker. El comando docker inspect -f {{.ID}} hashicorp-learn muestra el ID completo del contenedor en SHA256:

terraform import docker_container.web $(docker inspect -f {{.ID}} hashicorp-learn) Nota: El ID que acepta terraform import varía según el tipo de recurso y se registra en la documentación del proveedor para cualquier recurso que se pueda importar a Terraform. Para este ejemplo, consulta la documentación del proveedor de Docker

10. Verifica que el contenedor se importe a tu estado de Terraform:

terraform show

Este estado contiene todo lo que Terraform sabe acerca del contenedor de Docker que acabas de importar, pero la importación de Terraform no crea la configuración para ese recurso.

Crea la configuración

Deberás crear la configuración de Terraform antes de poder usarlo para administrar este contenedor.

1. Ejecuta el siguiente código:

terraform plan Nota: Terraform mostrará errores para los argumentos faltantes obligatorios, que son image y name. Terraform no puede generar un plan para un recurso al que le faltan argumentos obligatorios.

Existen dos enfoques para actualizar la configuración en docker.tf para que coincida con el estado que importaste. Al establecer esta configuración, puedes aceptar el estado actual completo del recurso o seleccionar individualmente los atributos obligatorios. Ambos enfoques pueden ser útiles en distintas circunstancias.

• A menudo, usar el estado actual es más rápido, pero puede tener como resultado una configuración en exceso verbosa debido a que cada atributo se incluye en el estado, sin importar si es necesario incluirlo en su configuración.

• Seleccionar los atributos obligatorios de forma Individual puede ofrecer una configuración más manejable, pero requiere que comprendas cuáles se deben establecer en la configuración.

Para los fines de este lab, usarás el estado actual como recurso.

2. Copia tu estado de Terraform en tu archivo docker.tf:

terraform show -no-color > docker.tf Nota: El símbolo > reemplazará todo el contenido de docker.tf con el resultado del comando terraform show. A pesar de que esto funciona para este ejemplo, importar un recurso a una configuración que ya administra recursos requerirá que edites el resultado de terraform show para quitar los recursos existentes cuya configuración no desees reemplazar por completo y combinar los recursos nuevos con tu configuración existente.

3. Inspecciona el archivo docker.tf para ver que se haya sustituido su contenido con el resultado del comando terraform show que acabas de ejecutar.

4. Ejecuta el siguiente código:

terraform plan

Terraform mostrará advertencias y errores sobre un argumento obsoleto (“links”), y varios argumentos de solo lectura (ip_address, network_data, gateway, ip_prefix_length, id).

Estos argumentos de solo lectura son valores que Terraform almacena en su estado para los contenedores de Docker, pero que no puede establecer mediante la configuración dado que Docker los administra de manera interna. Terraform puede establecer el argumento links con una configuración, pero mostrará una advertencia dado que es obsoleto y futuras versiones del proveedor de Docker podrían no admitirlo.

Dado que el enfoque que se muestra aquí carga todos los atributos representados en el estado de Terraform, tu configuración incluye atributos opcionales cuyos valores son los mismos que sus valores predeterminados. Cuáles atributos son opcionales, y sus valores predeterminados, varía de proveedor a proveedor, y se enumeran en la documentación de proveedores.

5. Ahora puedes quitar selectivamente estos atributos opcionales. Quita todos estos atributos, pero mantén solo los obligatorios: image, name y ports. Después de quitar estos atributos opcionales, tu configuración debería coincidir con la siguiente:

resource "docker_container" "web" { image = "sha256:87a94228f133e2da99cb16d653cd1373c5b4e8689956386c1c12b60a20421a02" name = "hashicorp-learn" ports { external = 8080 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

Cuando importes una infraestructura real, consulta la documentación del proveedor para saber qué hace cada argumento. Esto te ayudará a determinar cómo manejar los errores o advertencias del paso de ejecución del comando plan. Por ejemplo, la documentación para el argumento links se encuentra en la documentación de proveedores de Docker.

6. Verifica que se hayan resuelto los errores:

terraform plan

El plan debería ahora ejecutarse correctamente. Nota que el plan indica que Terraform actualizará el contenedor para agregar los atributos attach, logs, must_run y start.

Terraform usa estos atributos para crear contenedores de Docker, pero Docker no los almacena. Como resultado, terraform import no cargó sus valores en el estado. Cuando planifiques y apliques tu configuración, el proveedor de Docker asignará los valores predeterminados para estos atributos y los guardará en el estado, pero no afectarán el contenedor en ejecución.

7. Aplica los cambios y termina el proceso de sincronización de tu configuración y estado actualizados de Terraform con el contenedor de Docker que representan. Escribe yes cuando recibas el prompt de confirmación.

terraform apply

Ahora tu archivo de configuración, estado de Terraform y el contenedor están sincronizados, y puedes usar Terraform para administrar el contenedor como lo harías normalmente.

Crea un recurso de imagen

En algunos casos, puedes poner recursos bajo el control de Terraform sin usar el comando terraform import. A menudo, este es el caso para recursos que se definen según un solo ID único o etiqueta, como las imágenes de Docker.

En tu archivo docker.tf, el recurso docker_container.web especifica el ID de hash SHA256 de la imagen que se usó para crear el contenedor. Docker almacena de esta manera el ID de la imagen de forma interna, y terraform import cargó el ID de la imagen directamente en tu estado. Sin embargo, el ID de la imagen no es tan legible como la etiqueta o el nombre de la imagen, y podría no coincidir con tu intent. Por ejemplo, quizá prefieras usar la versión más reciente de la imagen “nginx”.

1. Para recuperar el nombre de etiqueta de la imagen, ejecuta el siguiente comando, pero sustituye <IMAGE-ID> con el ID de la imagen de docker.tf:

docker image inspect -f {{.RepoTags}}

2. Agrega la siguiente configuración a tu archivo docker.tf para representar esta imagen como recurso:

resource "docker_image" "nginx" { name = "nginx:latest" } Nota: No reemplaces todavía el valor de la imagen en el recurso docker_container.web; de lo contrario, Terraform destruirá tu contenedor y volverá a crearlo. Dado que Terraform aún no carga el recurso docker_image.nginx en el estado, no tiene un ID de imagen para compararlo con el que está codificado, lo que provocará que Terraform asuma que se debe sustituir el contenedor. Para resolver esta situación, crea primero la imagen y, después, actualiza el contenedor para usarlo, como se muestra en este lab.

3. Crea un recurso de imagen en el estado:

terraform apply

Dado que Terraform ya creó un recurso para la imagen, puedes hacer referencia a ella en la configuración del contenedor.

4. Cambia el valor de la imagen por docker_container.web para hacer referencia al nuevo recurso de imagen:

resource "docker_container" "web" { image = docker_image.nginx.image_id name = "hashicorp-learn" ports { external = 8080 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

5. Busca los cambios:

terraform apply

Dado que docker_image.nginx.latest coincidirá con el ID de imagen codificado que sustituiste, no se mostrarán cambios si se ejecuta terraform apply en este punto.

Nota: Si el ID de la imagen para la etiqueta “nginx:latest” cambió en el lapso entre que creaste el contenedor de Docker y ejecutaste este comando, el contenedor se destruirá y se volverá a crear con la imagen nueva.

Administra el contenedor con Terraform

Puesto que Terraform ya administra el contenedor de Docker, usa Terraform para cambiar la configuración.

1. En tu archivo docker.tf, cambia el puerto externo del contenedor de 8080 a 8081:

resource "docker_container" "web" { name = "hashicorp-learn" image = docker_image.nginx.image_id ports { external = 8081 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

2. Aplica el cambio:

terraform apply

Escribe yes cuando recibas el prompt de confirmación.

Esto provocará que Terraform destruya el contenedor y lo vuelva a crear con la nueva configuración del puerto.

3. Verifica que se haya sustituido el contenedor con uno nuevo que tenga la nueva configuración:

docker ps

Nota que el ID del contenedor cambió. Debido a que cambiar la configuración del puerto requiere destruirlo y volver a crearlo, es un contenedor completamente nuevo.

Destruye la infraestructura

Importaste tu contenedor de Docker y la imagen que se usó para crearlo en Terraform.

1. Ahora destruye el contenedor y la imagen:

terraform destroy

Escribe yes cuando recibas el prompt de confirmación.

2. Valida que el contenedor se haya destruido:

docker ps --filter "name=hashicorp-learn" Nota: Dado que agregaste la imagen tanto a tu configuración de Terraform como al contenedor, la imagen se quitará de Docker y del contenedor. Si otro contenedor usaba la misma imagen, el paso de destrucción fallará. Recuerda que importar un recurso a Terraform significa que Terraform administrará el ciclo de vida completo del recurso, incluida su destrucción.

Limitaciones y otras consideraciones

Hay varios aspectos importantes que se deben considerar cuando importes recursos a Terraform.

La importación de Terraform solo conoce el estado actual de la infraestructura según la informa el proveedor de Terraform. Por ello, desconoce lo siguiente:

• Si la infraestructura funciona correctamente
• El intent de la infraestructura
• Los cambios que realizaste en la infraestructura que no controla Terraform; por ejemplo, el estado del sistema de archivos de un contenedor de Docker

Importar implica pasos manuales que pueden provocar errores, especialmente si la persona que importa los recursos carece del contexto sobre cómo y por qué se crearon esos recursos en un principio.

La importación manipula el archivo de estado de Terraform; te sugerimos que crees una copia de seguridad antes de importar una infraestructura nueva.

La importación de Terraform no detecta ni genera relaciones entre las infraestructuras.

Terraform no detecta atributos predeterminados que no es necesario establecer en tu configuración.

No todos los proveedores y recursos son compatibles con la importación de Terraform.

Importar infraestructura en Terraform no significa que este pueda destruirla y volver a crearla. Por ejemplo, la infraestructura importada podría depender de otra infraestructura o configuración no administrada.

Seguir las prácticas recomendadas de infraestructura como código (IaC), como la infraestructura inmutable, puede evitar muchos de estos problemas. Sin embargo, es poco probable que la infraestructura creada manualmente siga estas prácticas.

Las herramientas como Terraformer pueden automatizar algunos pasos manuales que se asocian con la importación de infraestructura. Sin embargo, estas herramientas no son parte de Terraform, y HashiCorp no las recomienda ni es compatible con ellas.

¡Felicitaciones!

En este lab, aprendiste a administrar backends y estados con Terraform. Creaste backends locales y en Cloud Storage para administrar tu archivo de estado, actualizaste el estado e importaste la configuración en Terraform. Después actualizaste la configuración y la editaste manualmente para administrar por completo el contenedor de Docker con Terraform.

Próximos pasos y más información

Asegúrate de consultar los siguientes labs para adquirir más práctica con Terraform:

• Hashicorp en Google Cloud Marketplace
• Hashicorp Learn
• Comunidad de Terraform
• Ejemplos de Google con Terraform

Capacitación y certificación de Google Cloud

Recibe la formación que necesitas para aprovechar al máximo las tecnologías de Google Cloud. Nuestras clases incluyen habilidades técnicas y recomendaciones para ayudarte a avanzar rápidamente y a seguir aprendiendo. Para que puedas realizar nuestros cursos cuando más te convenga, ofrecemos distintos tipos de capacitación de nivel básico a avanzado: a pedido, presenciales y virtuales. Las certificaciones te ayudan a validar y demostrar tus habilidades y tu conocimiento técnico respecto a las tecnologías de Google Cloud.

Última actualización del manual: 26 de enero de 2024

Prueba más reciente del lab: 11 de diciembre de 2023

Copyright 2024 Google LLC. All rights reserved. Google y el logotipo de Google son marcas de Google LLC. Los demás nombres de productos y empresas pueden ser marcas de las respectivas empresas a las que estén asociados.