Unidad 2.1: Cómputo y automatización de servidores

Introducción

Está construyendo TaskBoard, un servicio de gestión de tareas que requiere un servidor API persistente y una flota de workers sin estado. Antes de que se ejecute cualquier código de la aplicación, necesita aprovisionar la capa de cómputo de forma reproducible, cada vez, desde un repositorio Git y no desde una consola. Esta unidad lo lleva desde un recurso ionoscloud_server individual hasta un grupo de escalado automático, todo expresado como código.

El cómputo en IONOS CLOUD le ofrece dos modelos de servidor con semánticas de facturación y CPU diferentes, configuración automatizada de la primera iniciación a través de cloud-init, y un escalador horizontal automático que tiene requisitos estrictos que debe codificar correctamente o su terraform apply fallará. Escribirá el Terraform para el servidor API de TaskBoard (Dedicated Core, 4 núcleos, 8 GB de RAM) y su worker (vCPU, 2 núcleos), integrará cloud-init para instalar el entorno de ejecución, y asignará una IP pública para que pueda iniciar sesión mediante SSH y verificar el resultado.

1. Aprovisionamiento de servidores con Terraform

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

Un servidor Dedicated Core mínimo para la capa de API de TaskBoard se ve así. El volumen de arranque se declara de forma integrada, y la imagen del sistema operativo se resuelve mediante una fuente de datos en lugar de estar codificada 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
  }
}

La RAM se especifica en megabytes, por lo que 8 GB es 8192. La creación del servidor es asíncrona, pero el proveedor de Terraform consulta internamente el estado de la solicitud de IONOS CLOUD, de modo que cuando apply devuelve un resultado, el servidor ha alcanzado el estado DONE y el volumen de arranque está adjunto. No se realiza una consulta manual dentro de Terraform de la misma manera que se haría con una llamada a la API sin procesar.

1.1 Núcleo dedicado frente a vCPU

La elección del modelo de servidor no es cosmética. Un servidor de núcleo dedicado otorga a su VM el uso exclusivo de sus núcleos físicos, y puede seleccionar y cambiar posteriormente la familia de CPU. Un servidor de vCPU comparte recursos de CPU y su familia de CPU es fija en el momento de la creación y no puede cambiarse después. La capa de API de TaskBoard requiere una latencia predecible, por lo que utiliza núcleos dedicados. La capa de trabajadores es intermitente y sensible al costo, por lo que utiliza vCPU.

Los dos modelos comparten el mismo límite máximo de RAM, pero difieren en la dimensión de CPU. Los límites siguientes provienen directamente de la plataforma y son los valores contra los que Terraform realiza la validación.

La RAM puede configurarse en incrementos de 0,25 GB. La función de cambio de familia de CPU en los servidores de núcleo dedicado se denomina Core Technology Choice, que permite mover un servidor existente a una generación más nueva de CPU sin reconstruirlo. Los modelos de 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 servidor de vCPU. Observe la ausencia de cpu_family, ya que no puede seleccionarse.

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 cómputo pueden ubicarse en la zona de disponibilidad 1, la zona 2 o AUTO. No existe una zona 3 para cómputo, aunque los volúmenes de Block Storage sí ofrecen una zona 3. Si configura availability_zone = "ZONE_3" en un servidor, la solicitud fallará. Utilice AUTO a menos que esté distribuyendo deliberadamente réplicas entre zonas por tolerancia a fallos, en cuyo caso fije un servidor en ZONE_1 y otro en 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 la inicialización automatizada

Un servidor aprovisionado sin software no es útil. Cloud-init es el paquete que se ejecuta en el primer arranque y aplica su configuración: instala paquetes, escribe archivos, inicia servicios e inyecta claves SSH. Todas las imágenes públicas de Linux en IONOS CLOUD (Alma Linux, Debian, Rocky Linux y Ubuntu) se entregan con cloud-init ya 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 en la API. El contenido decodificado puede ser un documento YAML de cloud-config, un script de shell, un archivo de inclusión o varios otros formatos admitidos. Para TaskBoard, un documento de cloud-config es la forma más limpia de declarar el estado final deseado.

2.1 Cloud-config para TaskBoard

El siguiente cloud-config instala el runtime de contenedores, crea un usuario de aplicación e inicia el servicio de la API de TaskBoard. Se encuentra en un archivo separado y se codifica en base64 mediante 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

Intégrelo en el recurso del servidor con user_data. El uso de templatefile le permite inyectar variables, como la clave SSH, en la cloud-config en el momento de la planificación.

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 resolverse a un tipo admitido), un script de datos de usuario que comience con #! o Content-Type: text/x-shellscript, un archivo de inclusión que comience con #include, datos de cloud-config que comiencen con #cloud-config en YAML, y trabajos de upstart. La propiedad user_data es inmutable: solo se tiene en cuenta durante la creación del volumen, por lo que cambiarla posteriormente requiere recrear el volumen, no actualizarlo in situ.

2.2 Claves SSH y verificación de la primera iniciación

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

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

La ejecución de cloud-init status --wait se mantiene en espera hasta que finalice la configuración de la primera iniciación, que es la señal correcta de que sus paquetes están instalados y los servicios están en ejecución. No asuma que el servidor está listo solo porque SSH acepta la conexión.

3. Asignación de IP pública

Los servidores en una LAN pública reciben una IP de DHCP de forma automática, pero esa dirección es efímera y puede cambiar. Para obtener una IP pública estable y reservada, asigne una ionoscloud_ipblock y asigne una de sus direcciones a la NIC. Esto es necesario para el punto de conexión de la API de TaskBoard, al cual apuntan los registros de 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 cuántas direcciones reserva el bloque. Una IP reservada sobrevive a la recreación del servidor, lo que significa que puede reconstruir el servidor de API sin cambiar la dirección a la que resuelven sus registros de DNS. El location del bloque de IP debe coincidir con la ubicación del centro de datos, o la asignación fallará.

4. Imágenes y Snapshot como código

La fuente de datos ionoscloud_image resuelve una imagen del sistema operativo a un ID en el momento de la planificación, de modo que nunca se codifique de forma fija 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 volumen de arranque configurado como instantánea y aprovisione nuevos servidores a partir de ella. El recurso ionoscloud_snapshot crea una instantánea a partir de un volumen existente, y ese identificador de instantánea puede servir para crear 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 Snapshot son completas y están activas en la misma región que el volumen de origen. Utilizar una Snapshot como base para nuevos servidores omite el paso de instalación de cloud-init para todo lo que esté integrado en la imagen, lo cual acelera la escalabilidad y elimina las desviaciones entre los nodos recién creados.

5. VM Auto Scaling

VM Auto Scaling se encuentra actualmente en Acceso Anticipado (EA); IONOS CLOUD recomienda limitarlo a cargas de trabajo no productivas, y su API de Cloud está versionada de forma independiente en https://api.ionos.com/autoscaling (versión v1.ea), en lugar de la superficie estable /cloudapi/v6 utilizada para servidores y bloques de IP.

VM Auto Scaling crea y elimina réplicas de servidores de forma automática en función de métricas. Solo admite escalado horizontal: agrega más VMs, 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 controla.

Tenga en cuenta el modelo de escalado: VM Auto Scaling es exclusivamente horizontal. Agrega y elimina réplicas completas de servidores de su ionoscloud_autoscaling_group, respaldadas por servidores de Compute Engine. Los cambios en la configuración de la réplica se aplican a las réplicas recién creadas, no a las 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étrica de escalado son el promedio de utilización de CPU de la 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 mediante 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 aprovisiona.

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 VMs) o PERCENTAGE (una proporción de la cantidad actual). El período de espera predeterminado es de 5 minutos, la cantidad mínima de réplicas es 1 y el límite recomendado es de aproximadamente 100 réplicas. Un grupo puede asociarse con un Application Load Balancer para que las nuevas réplicas se agreguen automáticamente a la piscina de objetivos del LB.

5.2 Las réplicas tienen nombres, no son direccionables por ID de servidor

Un problema operativo sutil: los nombres de servidor de réplica generados automáticamente son nombres, no IDs de servidor, y no pueden usarse para recuperar información a través de la API. Si sus scripts de monitorización o despliegue asumen que pueden GET /servers/{id} utilizando el nombre de la réplica, la llamada fallará. Trate las réplicas como ganado. Refiérase a ellas a través del grupo y del load balancer, no por ID de servidor individual.

6. Cubes para Workloads sin estado

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

Un Cube no es solo de almacenamiento. Además del volumen NVMe obligatorio, puede adjuntar hasta 23 dispositivos de almacenamiento en bloque adicionales, para un total de 24 ranuras de dispositivos, con el volumen NVMe ocupando una ranura. El NVMe de plantilla fija y el modelo más económico compatible con suspensión hacen que Cubes sea una buena opción para workloads sin estado o efímeros donde se 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
  }
}

Un matiz de facturación que debe codificarse 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 contador en funcionamiento. Si inicia Cubes para trabajos por lotes y espera dejar de pagar suspendiéndolos, se sorprenderá. Ejecute terraform destroy en Cubes efímeros para detener realmente los cargos.

Tarjeta rápida de referencia de la API

Puntos finales de la API clave para la aprovisionamiento de cómputo:

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

Laboratorio de código

Objetivo: Desplegar la capa de cómputo de TaskBoard con Terraform: un servidor de Dedicated Core API inicializado mediante cloud-init, con una IP pública reservada, y verificar el acceso SSH.

Requisitos previos:

• Cuenta de IONOS CLOUD con un token de 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: Escriba 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: Defina el centro de datos, la imagen y el bloque de 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 de 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 de validació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 usando la clave inyectada

Limpieza:

terraform destroy -auto-approve

Errores comunes

Errores de desarrollo a evitar con la automatización de cómputo en IONOS CLOUD:

1. Establecer una familia de CPU en un servidor vCPU

   • Problema: Su terraform apply falla o el servidor de trabajo se aprovisiona con una CPU inesperada cuando establece cpu_family en una configuración vCPU.
   • Por qué ocurre: La familia de CPU de un servidor vCPU no puede elegirse en el momento de la creación ni modificarse posteriormente. Solo los servidores Dedicated Core admiten la selección de familia (Core Technology Choice).
   • Solución: Omita cpu_family por completo en los servidores vCPU y establézcalo solo en los servidores Dedicated Core:

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

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

   • Problema: Aumenta los núcleos o la RAM en la configuración de la réplica esperando que las réplicas existentes crezcan, pero las VM en ejecución mantienen el mismo tamaño.
   • Por qué ocurre: VM Auto Scaling es solo horizontal. Añade y elimina réplicas completas en lugar de redimensionarlas, y los cambios en la configuración de la réplica se aplican únicamente a las réplicas creadas de nuevo.
   • Solución: Permita que el grupo se escale hacia afuera añadiendo réplicas para absorber la carga. Si una carga de trabajo necesita realmente VM individuales más grandes, redimensione el servidor fuera del grupo de escalado automático, o permita que el grupo reemplace las réplicas para que el nuevo tamaño surta efecto.

3. Suponer que un Cube deja de facturar cuando se suspende

   • Problema: Suspende Cubes utilizados para trabajos por lotes para ahorrar dinero, pero la factura sigue aumentando.
   • Por qué ocurre: Para Cubes, solo la eliminación detiene la facturación, no la suspensión. El volumen NVMe obligatorio y los recursos de la plantilla permanecen reservados mientras están suspendidos.
   • Solución: Desmonte los Cubes efímeros con terraform destroy en lugar de suspenderlos, o convierta la carga de trabajo en un servidor estándar que pueda detener.

Resumen

Ahora puede aprovisionar por completo la computación de IONOS CLOUD como código: servidores Dedicated Core y vCPU con las restricciones correctas de CPU y RAM, inicialización con cloud-init que instala e inicia su entorno 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 qué cargas de trabajo corresponden a servidores estándar frente a Cubes, y cómo difieren los modelos de facturación y almacenamiento entre ellos.

Esta es la base de computación de TaskBoard. La siguiente unidad conecta estos servidores a una red de múltiples niveles, pero los patrones aquí, imágenes resueltas por fuente de datos, configuración 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 familia de CPU; los servidores vCPU tienen un conjunto fijo de familias en la creación
• VM Auto Scaling es solo horizontal: agrega y elimina réplicas completas de servidores, y los cambios en la configuración de la réplica se aplican solo a las réplicas nuevas
• Ambos modelos de servidor llegan a un máximo de 62 núcleos / 60 vCPUs y 230 GB de RAM, con la RAM configurada en incrementos de 0,25 GB
• Cloud-init user_data está codificado en base64 e es inmutable; cambiarlo requiere recrear el volumen
• Los servidores de computación existen solo en Zone 1, Zone 2 o AUTO, sin Zone 3 para computación
• Cubes incluyen un volumen NVMe fijo y obligatorio, admiten hasta 23 dispositivos de almacenamiento en bloques adicionales y solo dejan de facturarse en la eliminación

Terminología importante:

• Servidor Dedicated Core: Un servidor de computación con núcleos físicos exclusivos y una familia de CPU seleccionable y modificable.
• Servidor vCPU: Un servidor de computación con recursos de CPU compartidos cuya familia de CPU no es seleccionable y no puede modificarse (el hipervisor la asigna).
• Cloud-init: El paquete de automatización del primer arranque, presente en todas las imágenes públicas de Linux, que aplica la configuración user_data como la instalación de paquetes y la inyección de claves SSH.
• Core Technology Choice: La función Dedicated Core que le permite mover un servidor existente a una generación de CPU más nueva sin reconstruirlo.
• Bloque de 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

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

Temas relacionados:

• Unidad 1.2: Terraform Provider y patrones principales
• Unidad 2.4: Aprovisionamiento de almacenamiento como código