Unidad 2.1: Computación y automatización de servidores

Introducción

Está construyendo TaskBoard, un servicio de gestión de tareas que necesita un servidor API persistente y una flota de trabajadores sin estado. Antes de que se ejecute cualquier código de aplicación, necesita que el nivel de computación esté aprovisionado de forma reproducible, cada vez, desde un repositorio Git en lugar de una consola. Esta unidad lo lleva desde un recurso ionoscloud_server único a un grupo de escalado automático, todo expresado como código.

La computación en IONOS Cloud le ofrece dos modelos de servidor con diferentes facturación y semántica CPU, configuración automática de primera inicialización a través de cloud-init y un escalador automático horizontal que tiene requisitos estrictos que debe codificar correctamente o su terraform apply fallará. Escribirá el Terraform para el servidor API de TaskBoard (Núcleo dedicado, 4 núcleos, 8 GB RAM) y su trabajador (vCPU, 2 núcleos), conectará cloud-init para instalar el entorno de ejecución y adjuntará una IP pública para que pueda SSH y verificar el resultado.

1. Provisionamiento de servidores con Terraform

El recurso ionoscloud_server es el bloque de construcción fundamental de la capa de cómputo. Un servidor siempre se encuentra dentro de un ionoscloud_datacenter (un centro de datos virtual, o VDC) y se crea con una familia CPU, un recuento de núcleos y una cantidad de RAM. Las dos decisiones que impulsan todo lo demás son el tipo de servidor, ENTERPRISE para núcleo dedicado o CUBE para Cubes, y si elige una configuración de núcleo dedicado o una configuración vCPU.

Un Dedicated Core Server mínimo para la capa API de TaskBoard se ve así. El arranque Volume se declara en línea, y la imagen del sistema operativo se resuelve mediante una fuente de datos en lugar de codificarse de forma fija.

resource "ionoscloud_datacenter" "taskboard" {
  name     = "taskboard-prod"
  location = "de/txl"
}

data "ionoscloud_image" "ubuntu" {
  type       = "HDD"
  cloud_init = "V1"
  image_alias = "ubuntu:latest"
  location   = "de/txl"
}

resource "ionoscloud_server" "api" {
  name              = "taskboard-api"
  datacenter_id     = ionoscloud_datacenter.taskboard.id
  cores             = 4
  ram               = 8192
  cpu_family        = "INTEL_ICELAKE"
  availability_zone = "AUTO"

  volume {
    name      = "api-boot"
    size      = 20
    disk_type = "SSD Premium"
    image_name = data.ionoscloud_image.ubuntu.id
    ssh_keys  = [var.ssh_public_key]
  }

  nic {
    lan             = ionoscloud_lan.public.id
    dhcp            = true
    firewall_active = false
  }
}

El RAM se especifica en megabytes, por lo que 8 GB es 8192. La creación del servidor es asíncrona, pero el proveedor Terraform sondea el estado de la solicitud de IONOS internamente, por lo que para cuando apply devuelve el resultado, el servidor ha alcanzado el estado DONE y el arranque Volume está conectado. Usted no sondea manualmente dentro de Terraform de la misma manera que lo haría con una llamada cruda a API.

1.1 Núcleo dedicado versus vCPU

La elección del modelo de servidor no es cosmética. Un Dedicated Core Server da a su VM el uso exclusivo de sus núcleos físicos, y usted puede elegir y cambiar más tarde la familia CPU. Un vCPU Server comparte los recursos CPU y su familia CPU es fija en la creación y no se puede cambiar después. La capa API de TaskBoard quiere una latencia predecible, por lo que utiliza Núcleo dedicado. La capa de trabajador es intermitente y sensible al costo, por lo que utiliza vCPU.

Los dos modelos comparten el mismo techo RAM, pero difieren en la dimensión CPU. Los límites a continuación provienen directamente de la plataforma y son los valores que Terraform valida.

El RAM se puede establecer en incrementos de 0,25 GB. La función de cambio de familia CPU en los servidores de Núcleo dedicado se llama Elección de tecnología de núcleo, que le permite mover un servidor existente a una generación más nueva de CPU sin reconstruirlo. Los modelos CPU disponibles incluyen AMD EPYC Gen 3 (Milan), AMD EPYC Gen 5 (Turin), varias familias Intel Xeon Gen 5 (Haswell, Broadwell, Skylake, Ice Lake) e Intel Xeon Gen 6 (Sierra Forest).

El trabajador de TaskBoard es un vCPU Server. Tenga en cuenta la ausencia de cpu_family, porque no se puede elegir.

resource "ionoscloud_vcpu_server" "worker" {
  name          = "taskboard-worker"
  datacenter_id = ionoscloud_datacenter.taskboard.id
  cores         = 2
  ram           = 4096
  # cpu_family omitted: vCPU servers do not allow CPU family selection

  volume {
    name       = "worker-boot"
    size       = 10
    disk_type  = "SSD Standard"
    image_name = data.ionoscloud_image.ubuntu.id
    ssh_keys   = [var.ssh_public_key]
  }

  nic {
    lan  = ionoscloud_lan.app.id
    dhcp = true
  }
}

1.2 Zonas de disponibilidad

Los servidores de computación pueden ubicarse en la Zona de disponibilidad 1, Zona 2, o AUTO. No existe la Zona 3 para la computación, aunque los volúmenes de Block Storage sí ofrecen una Zona 3. Si establece availability_zone = "ZONE_3" en un servidor, la solicitud falla. Utilice AUTO a menos que esté dispersando deliberadamente réplicas en varias zonas para la tolerancia a fallos, en cuyo caso fije un servidor a ZONE_1 y otro a ZONE_2.

resource "ionoscloud_server" "api_zone_a" {
  # ...
  availability_zone = "ZONE_1"
}

resource "ionoscloud_server" "api_zone_b" {
  # ...
  availability_zone = "ZONE_2"
}

2. Cloud-init para inicialización automática

Un servidor provisto sin software no es útil. Cloud-init es el paquete que se ejecuta en el primer arranque y aplica su configuración: instalando paquetes, escribiendo archivos, iniciando servicios y inyectando SSH claves. Todas las imágenes públicas Linux en IONOS Cloud (Alma Linux, Debian, Rocky Linux, y Ubuntu) ya vienen con cloud-init instalado, por lo que usted pasa la configuración a través del campo user_data y se ejecuta automáticamente.

Usted proporciona user_data como una cadena codificada en base64 en Terraform y el API. El contenido decodificado puede ser un documento de configuración de cloud-config YAML, un script de shell, un archivo de inclusión o varios formatos admitidos. Para TaskBoard, un documento de configuración de cloud-config es la forma más limpia de declarar el estado final deseado.

2.1 Cloud-config para TaskBoard

La siguiente configuración de cloud-config instala el tiempo de ejecución del contenedor, crea un usuario de aplicación y inicia el servicio TaskBoard API. Vive en un archivo separado y está codificado en base64 por la función base64encode de Terraform.

#cloud-config
package_update: true
packages:
  - docker.io
  - postgresql-client
users:
  - name: taskboard
    groups: docker
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - ${ssh_public_key}
runcmd:
  - systemctl enable --now docker
  - docker run -d --restart unless-stopped -p 80:8080 \
      --name taskboard-api registry.example/taskboard-api:latest

Conéctelo al recurso del servidor con user_data. Usar templatefile le permite inyectar variables como la clave SSH en la configuración de cloud-config en el momento del plan.

resource "ionoscloud_server" "api" {
  name          = "taskboard-api"
  datacenter_id = ionoscloud_datacenter.taskboard.id
  cores         = 4
  ram           = 8192
  cpu_family    = "INTEL_ICELAKE"

  volume {
    name       = "api-boot"
    size       = 20
    disk_type  = "SSD Premium"
    image_name = data.ionoscloud_image.ubuntu.id
    user_data  = base64encode(templatefile("${path.module}/cloud-init.yaml", {
      ssh_public_key = var.ssh_public_key
    }))
  }

  nic {
    lan  = ionoscloud_lan.public.id
    dhcp = true
  }
}

Los formatos de datos de usuario admitidos incluyen datos codificados en base64 (el contenido decodificado debe resolver a un tipo admitido), un script de datos de usuario que comienza con #! o Content-Type: text/x-shellscript, un archivo de inclusión que comienza con #include, datos de configuración de cloud-config que comienzan con #cloud-config en YAML, y trabajos de upstart. La propiedad user_data es inmutable: solo se respeta en la creación de Volume, por lo que cambiarla más tarde requiere recrear el Volume, no actualizarlo en su lugar.

2.2 SSH Claves y verificación de primer arranque

Puede inyectar SSH claves de dos maneras: a través de la lista ssh_keys del Volume, o dentro del bloque ssh_authorized_keys de configuración de cloud-config. El argumento ssh_keys es la ruta más sencilla para una sola clave en el usuario predeterminado. Después de apply, la clave pública IP aparece en los atributos exportados de la NIC, y puede conectarse inmediatamente.

terraform output api_public_ip
#=> 203.0.113.42
ssh root@203.0.113.42 'cloud-init status --wait'
#=> status: done

Ejecutar cloud-init status --wait bloques hasta que termine la configuración de primer arranque, que es la señal correcta de que sus paquetes están instalados y los servicios están en ejecución. No suponga que el servidor está listo solo porque SSH acepta la conexión.

3. Asignación de IP Público

Los servidores en un LAN público reciben una IP de DHCP automáticamente, pero esa dirección es efímera y puede cambiar. Para una IP pública estable y reservada, asigne un ionoscloud_ipblock y asignar una de sus direcciones a la NIC. Esto es necesario para el punto de conexión API de TaskBoard, al que apuntan los registros DNS y los equilibradores de carga.

resource "ionoscloud_ipblock" "api_ip" {
  location = ionoscloud_datacenter.taskboard.location
  size     = 1
  name     = "taskboard-api-ip"
}

resource "ionoscloud_server" "api" {
  # ... cores, ram, volume as above ...

  nic {
    lan  = ionoscloud_lan.public.id
    dhcp = true
    ips  = [ionoscloud_ipblock.api_ip.ips[0]]
  }
}

output "api_public_ip" {
  value = ionoscloud_ipblock.api_ip.ips[0]
}

El argumento size controla la cantidad de direcciones que reserva el bloque. Una IP reservada sobrevive a la recreación del servidor, lo que significa que puede reconstruir el servidor API sin cambiar la dirección a la que resuelven los registros DNS. La location del bloque de IP debe coincidir con la ubicación del centro de datos, o la asignación falla.

4. Images & Snapshots como código

La fuente de datos ionoscloud_image resuelve una imagen del sistema operativo en un ID en el momento del plan, por lo que nunca codifica de forma rígida un identificador de imagen volátil. Filtre por type, location, cloud_init y image_alias para fijar la imagen exacta que desea.

data "ionoscloud_image" "rocky" {
  type        = "HDD"
  cloud_init  = "V1"
  image_alias = "rockylinux:latest"
  location    = "de/txl"
}

Para entornos dorados reproducibles, capture un Volume de arranque configurado como un Snapshot y aprovisione nuevos servidores a partir de él. El recurso ionoscloud_snapshot crea un Snapshot a partir de un Volume existente, y ese ID de Snapshot puede generar volúmenes futuros.

resource "ionoscloud_snapshot" "api_golden" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  volume_id     = ionoscloud_server.api.boot_volume
  name          = "taskboard-api-golden-v3"
}

Las instantáneas son completas y viven en la misma región que la fuente Volume. Al utilizar una Snapshot como base para nuevos servidores, se omite el paso de instalación de cloud-init para todo lo que está integrado en la imagen, lo que acelera la escalabilidad y elimina la deriva entre los nodos recién construidos.

5. VM Auto Scaling

VM Auto Scaling se encuentra actualmente en acceso temprano (EA); IONOS recomienda limitarlo a cargas de trabajo no de producción, y su Cloud API está versionado por separado en https://api.ionos.com/autoscaling (versión v1.ea) en lugar de la superficie estable /cloudapi/v6 utilizada para servidores y bloques IP.

VM Auto Scaling crea y elimina réplicas de servidores automáticamente en función de métricas. Solo admite escalado horizontal: agrega más máquinas virtuales, no redimensiona una VM existente. Usted define una configuración de réplica objetivo, políticas de escalado hacia adentro y hacia afuera, y la métrica que las impulsa.

Mantenga en mente el modelo de escalado: VM Auto Scaling es solo horizontal. Agrega y elimina réplicas de servidores completas de su ionoscloud_autoscaling_group, respaldadas por servidores Compute Engine. Los cambios en la configuración de réplica se aplican a réplicas recién creadas, no a réplicas que ya están en ejecución. Los tipos de almacenamiento de réplica admitidos son HDD, SSD Premium y SSD Standard. Las opciones de métricas de escalado son utilización promedio de CPU de instancia (porcentaje), bytes de red entrantes, bytes de red salientes, paquetes de red entrantes y paquetes de red salientes.

5.1 Grupo de escalado automático a través de Terraform

El recurso ionoscloud_autoscaling_group define el grupo, su plantilla de réplica y su política. La plantilla de réplica define el tamaño para cada réplica de servidor que el grupo proporciona.

resource "ionoscloud_autoscaling_group" "workers" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-worker-asg"
  max_replica_count = 10
  min_replica_count = 1

  policy {
    metric             = "INSTANCE_CPU_UTILIZATION_AVERAGE"
    range              = "PT24H"
    scale_in_threshold  = 33
    scale_out_threshold = 77
    unit               = "PERCENTAGE"

    scale_in_action {
      amount      = 1
      amount_type = "ABSOLUTE"
      cooldown_period = "PT5M"
    }
    scale_out_action {
      amount      = 1
      amount_type = "ABSOLUTE"
      cooldown_period = "PT5M"
    }
  }

  replica_configuration {
    cores     = 4
    ram       = 4096
    cpu_family = "INTEL_ICELAKE"
    availability_zone = "AUTO"

    nic {
      lan  = ionoscloud_lan.app.id
      name = "worker-nic"
      dhcp = true
    }

    volume {
      image      = data.ionoscloud_image.ubuntu.id
      name       = "worker-vol"
      size       = 10
      type       = "SSD Standard"
      user_data  = base64encode(file("${path.module}/worker-init.yaml"))
    }
  }
}

El amount_type puede ser ABSOLUTE (un número fijo de máquinas virtuales) o PERCENTAGE (una proporción del recuento actual). El período de enfriamiento predeterminado es de 5 minutos, el recuento mínimo de réplicas es 1 y hasta aproximadamente 100 réplicas es el límite recomendado. Un grupo puede estar asociado con una aplicación Load Balancer para que se agreguen nuevas réplicas automáticamente al grupo de destino del equilibrio de carga.

5.2 Las réplicas tienen nombres, no se pueden direccionar por ID de servidor

Un problema operativo sutil: los nombres de servidores de réplicas generados automáticamente son nombres, no IDs de servidor, y no se pueden utilizar para recuperar información a través de la API. Si sus scripts de monitorización o implementación suponen que pueden GET /servers/{id} utilizando el nombre de la réplica, la llamada falla. Trate a las réplicas como ganado. Hágales referencia a través del grupo y la Load Balancer, no por ID de servidor individual.

6. Cubes para cargas de trabajo sin estado

Cubes son un tipo de servidor de cómputo con almacenamiento NVMe directamente conectado obligatorio definido por una plantilla de configuración. La plantilla más pequeña, Basic Cube XS, proporciona 1 vCPU, 2 GB RAM y 60 GB de almacenamiento NVMe directamente conectado. El vCPU, RAM y el tamaño de almacenamiento directamente conectado están fijados por la plantilla y no pueden cambiarse después de que se haya provisionado el Cube, y el almacenamiento NVMe Volume no puede desmontarse ni eliminarse.

Un Cube no es solo de almacenamiento. Además del almacenamiento NVMe Volume obligatorio, puede conectar hasta 23 dispositivos Block Storage adicionales, para un total de 24 ranuras de dispositivos, con el almacenamiento NVMe Volume ocupando una ranura. La plantilla fija NVMe más el modelo suspendido más asequible hace que Cubes sea una buena opción para cargas de trabajo sin estado o efímeras donde desea un paquete predecible.

resource "ionoscloud_server" "cube_runner" {
  name          = "taskboard-batch"
  type          = "CUBE"
  template_uuid = data.ionoscloud_template.basic_xs.id
  datacenter_id = ionoscloud_datacenter.taskboard.id

  volume {
    name      = "cube-das"
    disk_type = "DAS"
    licence_type = "LINUX"
  }

  nic {
    lan  = ionoscloud_lan.app.id
    dhcp = true
  }
}

Una sutileza de facturación que debe codificar en sus scripts de ciclo de vida: para Cubes, solo la eliminación detiene la facturación, no la suspensión. Suspender un Cube mantiene el medidor en marcha. Si inicia Cubes para trabajos por lotes y espera dejar de pagar suspendiéndolos, se llevará una sorpresa. Ejecute terraform destroy en Cubes efímeros para detener realmente los cargos.

API Tarjeta de referencia rápida

Puntos de conexión clave de API para la provisión de cómputo:

URL base de bloques Compute Engine / IP: https://api.ionos.com/cloudapi/v6 URL base de VM Auto Scaling (Acceso temprano): https://api.ionos.com/autoscaling/v1.ea Autenticación: Authorization: Bearer <token>

Laboratorio de código

Objetivo: Implementar la capa de cómputo de TaskBoard con Terraform: un servidor de núcleo dedicado API inicializado por cloud-init, con una dirección pública IP reservada, y verificar el acceso SSH.

Requisitos previos:

• Cuenta de IONOS Cloud con un token API (IONOS_TOKEN exportado)
• Terraform 1.5+ instalado localmente
• Un par de claves SSH (~/.ssh/id_ed25519.pub)

Paso 1: Configurar el proveedor

terraform {
  required_providers {
    ionoscloud = {
      source  = "ionos-cloud/ionoscloud"
      version = "~> 6.0"
    }
  }
}
provider "ionoscloud" {}

Salida esperada:

$ terraform init
Terraform has been successfully initialized!

Paso 2: Escribir el archivo cloud-init (cloud-init.yaml)

#cloud-config
package_update: true
packages: [docker.io]
runcmd:
  - systemctl enable --now docker

Salida esperada:

(file saved, no command output)

Paso 3: Definir el centro de datos, la imagen y el bloque IP

resource "ionoscloud_datacenter" "taskboard" {
  name = "taskboard-lab"; location = "de/txl"
}
data "ionoscloud_image" "ubuntu" {
  type = "HDD"; cloud_init = "V1"
  image_alias = "ubuntu:latest"; location = "de/txl"
}
resource "ionoscloud_ipblock" "api_ip" {
  location = "de/txl"; size = 1; name = "lab-ip"
}

Salida esperada:

(validated by terraform plan in Step 5)

Paso 4: Definir el servidor API

resource "ionoscloud_server" "api" {
  name = "taskboard-api"; datacenter_id = ionoscloud_datacenter.taskboard.id
  cores = 4; ram = 8192; cpu_family = "INTEL_ICELAKE"
  volume {
    name = "api-boot"; size = 20; disk_type = "SSD Premium"
    image_name = data.ionoscloud_image.ubuntu.id
    ssh_keys = [file("~/.ssh/id_ed25519.pub")]
    user_data = base64encode(file("cloud-init.yaml"))
  }
  nic { lan = 1; dhcp = true; ips = [ionoscloud_ipblock.api_ip.ips[0]] }
}
output "api_ip" { value = ionoscloud_ipblock.api_ip.ips[0] }

Paso 5: Planificar y aplicar

terraform plan
terraform apply -auto-approve

Salida esperada:

Apply complete! Resources: 4 added, 0 changed, 0 destroyed.
Outputs:
api_ip = "203.0.113.42"

Paso 6: Verificar cloud-init y SSH

ssh root@$(terraform output -raw api_ip) 'cloud-init status --wait && docker --version'

Salida esperada:

status: done
Docker version 24.0.x, build ...

Lista de verificación:

• [ ] terraform apply se completa con 4 recursos agregados
• [ ] La salida api_ip muestra una dirección pública reservada
• [ ] cloud-init status devuelve done y Docker está instalado
• [ ] SSH se conecta utilizando la clave inyectada

Limpieza:

terraform destroy -auto-approve

Errores comunes

Errores de los desarrolladores que deben evitarse con la automatización de cómputo en IONOS Cloud:

1. Establecer una familia de CPU en un vCPU Server

   • Problema: Su terraform apply falla o el servidor de trabajo se aprovisiona con una familia de CPU inesperada cuando establece cpu_family en una configuración de vCPU.
   • Por qué sucede: La familia de CPU de un vCPU Server no se puede elegir durante la creación y no se puede cambiar más tarde. Solo los servidores Dedicated Core admiten la selección de familia (Core Technology Choice).
   • Solución: Omite cpu_family por completo para los servidores de vCPU y solo establézcalo en los servidores Dedicated Core:

   resource "ionoscloud_server" "worker" {
     cores = 2
     ram   = 4096
     # no cpu_family on vCPU servers
   }
   

2. Esperando que VM Auto Scaling redimensione una VM en ejecución

   • Problema: Usted aumenta los núcleos o RAM en la configuración de réplica esperando que las réplicas existentes crezcan, pero las máquinas virtuales en ejecución siguen siendo del mismo tamaño.
   • Por qué sucede: VM Auto Scaling es solo horizontal. Agrega y elimina réplicas completas en lugar de redimensionarlas, y los cambios en la configuración de réplica se aplican solo a las réplicas recién creadas.
   • Solución: Deje que el grupo se escale horizontalmente agregando réplicas para absorber la carga. Si un Workload realmente necesita máquinas virtuales individuales más grandes, redimensione el servidor fuera del grupo de autoescala, o deje que el grupo reemplace las réplicas para que el nuevo tamaño surta efecto.

3. Suponiendo que un Cube deja de facturarse cuando se suspende

   • Problema: Usted suspende Cubes utilizado para trabajos por lotes para ahorrar dinero, pero la factura sigue creciendo.
   • Por qué sucede: Para Cubes, solo la eliminación detiene la facturación, no la suspensión. Los recursos de NVMe Volume y plantilla obligatorios siguen reservados mientras están suspendidos.
   • Solución: Desmonte Cubes efímeros con terraform destroy en lugar de suspenderlos, o convierta el Workload en un servidor estándar que pueda detener.

Resumen

Ahora puede aprovisionar IONOS compute completamente como código: servidores Dedicated Core y vCPU con las restricciones correctas de CPU y RAM, inicialización de cloud-init que instala y inicia su tiempo de ejecución en el primer arranque, direcciones IP públicas reservadas que sobreviven a las reconstrucciones, y un grupo de escalado automático horizontal para trabajadores sin estado. También sabe a qué cargas de trabajo pertenecen los servidores estándar versus Cubes, y cómo difieren los modelos de facturación y almacenamiento entre ellos.

Esta es la base de cómputo de TaskBoard. La siguiente unidad conecta estos servidores a una red de varios niveles, pero los patrones aquí, imágenes resueltas de fuente de datos, configuración de cloud en base64, bloques de IP reservados y escalado automático horizontal, se repiten en cada pila de infraestructura que construya en IONOS Cloud.

Puntos clave:

• Los servidores Dedicated Core permiten la selección de la familia CPU; los servidores vCPU tienen una familia fija establecida en la creación
• VM Auto Scaling es solo horizontal: agrega y elimina réplicas de servidores completas, y los cambios de configuración de réplica se aplican solo a las nuevas réplicas
• Ambos modelos de servidor tienen un máximo de 62 núcleos / 60 vCPUs y 230 GB RAM, con RAM establecido en incrementos de 0,25 GB
• La inicialización de cloud-init user_data está codificada en base64 y es inmutable; cambiarla requiere recrear el Volume
• Los servidores de cómputo existen en la Zona 1, Zona 2 o AUTO solo, sin Zona 3 para cómputo
• Cubes llevan una NVMe Volume fija y obligatoria, admiten hasta 23 dispositivos Block Storage adicionales y dejan de facturarse solo al eliminarlos

Terminología importante:

• Dedicated Core Server: Un servidor de cómputo con núcleos físicos exclusivos y una familia CPU seleccionable y modificable.
• vCPU Server: Un servidor de cómputo con recursos CPU compartidos cuya familia CPU es fija en la creación.
• Cloud-init: El paquete de automatización de primer arranque, presente en todas las imágenes públicas Linux, que aplica la configuración user_data como la instalación de paquetes y la inyección de claves SSH.
• Elección de tecnología de núcleo: La función Dedicated Core que le permite mover un servidor existente a una generación más nueva de CPU sin reconstruirlo.
• Bloque IP: Un conjunto reservado de direcciones IP públicas (ionoscloud_ipblock) que persiste a través de la recreación del servidor, utilizado para puntos finales estables.

Próximos pasos

Continuar aprendiendo: Unidad 2.2: Red y conectividad como código

Temas relacionados:

• Unidad 1.2: Proveedor Terraform y patrones básicos
• Unidad 2.4: Provisionamiento de almacenamiento como código