Unité 2.1 : Calcul et automatisation de serveurs

Introduction

Vous créez TaskBoard, un service de gestion de tâches qui nécessite un serveur API persistant et une flotte de travailleurs sans état. Avant que tout code d'application ne s'exécute, vous devez disposer d'une couche de calcul provisionnée de manière reproductible, chaque fois, à partir d'un référentiel Git plutôt que d'une console. Cette unité vous guide depuis une seule ressource ionoscloud_server jusqu'à un groupe de mise à l'échelle automatique, le tout exprimé sous forme de code.

Le calcul sur IONOS Cloud vous offre deux modèles de serveurs avec des facturations et des sémantiques CPU différentes, une configuration automatique de premier démarrage via cloud-init, et un régulateur de charge horizontal qui a des exigences strictes que vous devez encoder correctement, sinon votre terraform apply échouera. Vous écrirez le Terraform pour le serveur API de TaskBoard (Dedicated Core, 4 cœurs, 8 GB RAM) et son worker (vCPU, 2 cœurs), connecterez cloud-init pour installer le runtime, et attacherez une adresse IP publique pour que vous puissiez SSH et vérifier le résultat.

1. Provisionnement de serveurs avec Terraform

La ressource ionoscloud_server est l'élément de base du niveau de calcul. Un serveur est toujours situé à l'intérieur d'un ionoscloud_datacenter (un centre de données virtuel, ou VDC) et est créé avec une famille CPU, un nombre de cœurs, et une quantité de RAM. Les deux décisions qui déterminent tout le reste sont le type de serveur, ENTERPRISE pour un cœur dédié ou CUBE pour Cubes, et si vous choisissez une configuration de cœur dédié ou une configuration vCPU.

Un Dedicated Core Server minimal pour le niveau API de TaskBoard ressemble à ceci : . Le disque de démarrage Volume est déclaré en ligne, et l'image du système d'exploitation est résolue par une source de données plutôt que codée en dur.

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
  }
}

Le RAM est spécifié en megaoctets, donc 8 Go équivaut à 8192. La création du serveur est asynchrone, mais le fournisseur Terraform interroge l'état de la demande IONOS de manière interne, donc au moment où apply retourne, le serveur a atteint l'état DONE et le démarrage Volume est attaché. Vous n'interrogerez pas manuellement à l'intérieur de Terraform de la même façon que vous le feriez avec un appel brut API.

1.1 Dedicated Core versus vCPU

Le choix du modèle de serveur n'est pas cosmétique. Un Dedicated Core Server donne à votre VM l'utilisation exclusive de ses cœurs physiques, et vous pouvez choisir et modifier par la suite la famille CPU. Un vCPU Server partage les ressources CPU et sa famille CPU est fixée lors de la création et ne peut pas être modifiée par la suite. Le niveau API de TaskBoard veut une latence prévisible, il utilise donc Dedicated Core. Le niveau worker est bursty et sensible au coût, il utilise donc vCPU.

Les deux modèles partagent le même plafond RAM, mais diffèrent sur la dimension CPU. Les limites ci-dessous proviennent directement de la plateforme et sont les valeurs que Terraform valide.

Le RAM peut être défini par incréments de 0,25 Go. La fonctionnalité de changement de la famille CPU sur les serveurs Dedicated Core est appelée Core Technology Choice, qui vous permet de déplacer un serveur existant vers une nouvelle génération CPU sans le reconstruire. Les modèles CPU disponibles incluent AMD EPYC Gen 3 (Milan), AMD EPYC Gen 5 (Turin), plusieurs familles Intel Xeon Gen 5 (Haswell, Broadwell, Skylake, Ice Lake) et Intel Xeon Gen 6 (Sierra Forest).

Le worker TaskBoard est un vCPU Server. Notez l'absence de cpu_family, car il ne peut pas être choisi.

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 Zones de disponibilité

Les serveurs de calcul peuvent être placés dans la zone de disponibilité 1, la zone 2, ou AUTO. Il n'y a pas de zone 3 pour le calcul, même si les volumes Block Storage offrent une zone 3. Si vous définissez availability_zone = "ZONE_3" sur un serveur, la demande échoue. Utilisez AUTO, à moins que vous ne répartissiez délibérément des répliques entre les zones pour la tolérance aux pannes, auquel cas fixez un serveur à ZONE_1 et un autre à 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 pour le démarrage automatique

Un serveur provisionné sans logiciel n'est pas utile. Cloud-init est le paquet qui s'exécute au premier démarrage et applique votre configuration : installation de paquets, écriture de fichiers, démarrage de services et injection de clés SSH. Toutes les images publiques Linux sur IONOS Cloud (Alma Linux, Debian, Rocky Linux, et Ubuntu) sont livrées avec cloud-init déjà installé, vous pouvez donc passer la configuration à travers le champ user_data et elle s'exécutera automatiquement.

Vous fournissez user_data sous la forme d'une chaîne codée en base64 dans Terraform et le API. Le contenu décodé peut être un document cloud-config YAML, un script shell, un fichier d'inclusion ou plusieurs autres formats pris en charge. Pour TaskBoard, un document cloud-config est la manière la plus propre de déclarer l'état final souhaité.

2.1 Cloud-config pour TaskBoard

Le cloud-config suivant installe le runtime de conteneur, crée un utilisateur d'application et démarre le service TaskBoard API. Il se trouve dans un fichier séparé et est codé en base64 par la fonction 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

Branchez-le dans la ressource de serveur avec user_data. L'utilisation de templatefile vous permet d'injecter des variables telles que la clé SSH dans le cloud-config au moment de la planification.

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
  }
}

Les formats de données utilisateur pris en charge incluent des données codées en base64 (le contenu décodé doit se résoudre en un type pris en charge), un script de données utilisateur commençant par #! ou Content-Type: text/x-shellscript, un fichier d'inclusion commençant par #include, des données cloud-config commençant par #cloud-config en YAML, et des tâches upstart. La propriété user_data est immuable : elle n'est honorée qu'à la création de Volume, donc la modifier plus tard nécessite de recréer Volume, et non de le mettre à jour sur place.

2.2 Clés SSH et vérification du premier démarrage

Vous pouvez injecter des clés SSH de deux manières : via la liste ssh_keys de Volume, ou à l'intérieur du bloc cloud-config ssh_authorized_keys. L'argument ssh_keys est le chemin le plus simple pour une clé unique sur l'utilisateur par défaut. Après apply, la clé publique IP apparaît dans les attributs exportés de la carte réseau, et vous pouvez vous connecter immédiatement.

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

L'exécution de blocs cloud-init status --wait se poursuit jusqu'à ce que la configuration du premier démarrage soit terminée, ce qui est le signal correct que vos paquets sont installés et que les services sont en cours d'exécution. Ne supposez pas que le serveur est prêt simplement parce que SSH accepte la connexion.

3. Allocation publique IP

Les serveurs sur un LAN public reçoivent une IP de DHCP automatiquement, mais cette adresse est éphémère et peut changer. Pour une IP publique stable et réservée, allouez un ionoscloud_ipblock et attribuez l'une de ses adresses à la carte réseau. Cela est requis pour le point de terminaison API de TaskBoard, auquel les enregistrements DNS et les equilibreurs de charge pointent.

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]
}

L'argument size contrôle le nombre d'adresses que le bloc réserve. Une IP réservée survive à la récreation du serveur, ce qui signifie que vous pouvez reconstruire le serveur API sans changer l'adresse à laquelle les enregistrements DNS se résolvent. Le location du bloc IP doit correspondre à l'emplacement du centre de données, sinon l'attribution échoue.

4. Images & Snapshots as Code

La source de données ionoscloud_image résout une image du système d'exploitation en un ID au moment du plan, de sorte que vous n'avez jamais à coder en dur un identifiant d'image volatile. Filtrez par type, location, cloud_init, et image_alias pour épingler l'image exacte que vous souhaitez :

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

Pour des environnements dorés reproductibles, capturez un Volume de démarrage configuré sous la forme d'un Snapshot et provisionnez de nouveaux serveurs à partir de celui-ci. La ressource ionoscloud_snapshot crée un Snapshot à partir d'un Volume existant, et l'ID de ce Snapshot peut alimenter les futurs volumes.

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

Les instantanés sont complets et vivent dans la même région que la source Volume. En utilisant un Snapshot comme base pour de nouveaux serveurs, l'étape d'installation de cloud-init est omise pour tout ce qui est intégré à l'image, ce qui accélère la mise à l'échelle et supprime les écarts entre les nœuds fraîchement construits.

5. VM Auto Scaling

VM Auto Scaling est actuellement en accès anticipé (EA) ; IONOS recommande de le limiter aux charges de travail non productives, et son Cloud API est versionné séparément à https://api.ionos.com/autoscaling (version v1.ea) plutôt qu'à la surface stable /cloudapi/v6 utilisée pour les serveurs et les blocs IP.

VM Auto Scaling crée et supprime automatiquement des répliques de serveurs en fonction des métriques. Il prend en charge uniquement la mise à l'échelle horizontale : il ajoute plus de machines virtuelles, il ne redimensionne pas une VM existante. Vous définissez une configuration de réplique cible, des stratégies de mise à l'échelle et de réduction, et la métrique qui les pilote.

Gardez à l'esprit le modèle de mise à l'échelle : VM Auto Scaling est uniquement horizontal. Il ajoute et supprime des répliques de serveurs entières de votre ionoscloud_autoscaling_group, étayées par des serveurs Compute Engine. Les modifications apportées à la configuration de réplique s'appliquent aux répliques nouvellement créées, et non aux répliques déjà en cours d'exécution. Les types de stockage de réplique pris en charge sont HDD, SSD Premium, et SSD Standard. Les options de métrique de mise à l'échelle sont l'utilisation moyenne de l'instance CPU (pourcentage), les octets du réseau entrant, les octets du réseau sortant, les paquets du réseau entrant, et les paquets du réseau sortant.

5.1 Groupe de mise à l'échelle automatique via Terraform

La ressource ionoscloud_autoscaling_group définit le groupe, son modèle de réplique, et sa stratégie. Le modèle de réplique définit la taille de chaque réplique de serveur que le groupe met à disposition.

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"))
    }
  }
}

Le amount_type peut être ABSOLUTE (un nombre fixe de machines virtuelles) ou PERCENTAGE (une proportion du décompte actuel). La période de refroidissement par défaut est de 5 minutes, le décompte de répliques minimum est de 1, et jusqu'à environ 100 répliques est le plafond recommandé. Un groupe peut être associé à une Application Load Balancer afin que de nouvelles répliques soient automatiquement ajoutées à la cible du pool d'équilibrage de charge.

5.2 Les répliques sont nommées, et non adressables par ID de serveur

Un piège opérationnel subtil : les noms de serveurs de répliques auto-générés sont des noms, et non des ID de serveur, et ils ne peuvent pas être utilisés pour récupérer des informations sur le API. Si vos scripts de surveillance ou de déploiement supposent qu'ils peuvent GET /servers/{id} en utilisant le nom de la réplique, l'appel échoue. Traitez les répliques comme du bétail. Référez-les par le groupe et le Load Balancer, et non par ID de serveur individuel.

6. Cubes pour les charges de travail sans état

Cubes sont un type de serveur de calcul avec un stockage NVMe directement attaché obligatoire défini par un modèle de configuration. Le modèle le plus petit, Basic Cube XS, fournit 1 vCPU, 2 GB RAM, et 60 GB de stockage NVMe directement attaché. Le vCPU, RAM, et la taille de stockage directement attaché sont fixés par le modèle et ne peuvent pas être modifiés après la mise à disposition du Cube, et le stockage NVMe Volume ne peut pas être démonté ou supprimé.

Un Cube n'est pas uniquement un stockage, cependant. En plus du stockage NVMe Volume obligatoire, vous pouvez attacher jusqu'à 23 appareils Block Storage supplémentaires, pour un total de 24 emplacements d'appareils, avec le stockage NVMe Volume occupant un emplacement. Le modèle de stockage NVMe fixe plus le modèle suspendu moins cher rend Cubes adapté aux charges de travail sans état ou éphémères où vous voulez un bundle prévisible.

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
  }
}

Une nuance de facturation à encoder dans vos scripts de cycle de vie : pour Cubes, seule la suppression arrête la facturation, et non la suspension. La suspension d'un Cube laisse le compteur tourner. Si vous démarrez Cubes pour des tâches par lots et vous attendez à arrêter de payer en les suspendant, vous serez surpris. Exécutez terraform destroy sur les Cubes éphémères pour arrêter réellement les frais.

API Référence Carte Rapide

Points de terminaison clés API pour la provision de calcul :

URL de base des blocs Compute Engine / IP : https://api.ionos.com/cloudapi/v6 URL de base VM Auto Scaling (Accès anticipé) : https://api.ionos.com/autoscaling/v1.ea Authentification : Authorization: Bearer <token>

Laboratoire de code

Objectif : Déployer le niveau de calcul de TaskBoard avec Terraform : un serveur API dédié Core initialisé par cloud-init, avec une adresse publique IP réservée, et vérifier l'accès SSH.

Prérequis :

• Compte IONOS Cloud avec un jeton API (IONOS_TOKEN exporté)
• Terraform 1.5+ installé localement
• Une paire de clés SSH (~/.ssh/id_ed25519.pub)

Étape 1 : Configurer le fournisseur

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

Sortie attendue :

$ terraform init
Terraform has been successfully initialized!

Étape 2 : Écrire le fichier cloud-init (cloud-init.yaml)

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

Sortie attendue :

(file saved, no command output)

Étape 3 : Définir le centre de données, l'image et le bloc 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"
}

Sortie attendue :

(validated by terraform plan in Step 5)

Étape 4 : Définir le serveur 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] }

Étape 5 : Planifier et appliquer

terraform plan
terraform apply -auto-approve

Sortie attendue :

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

Étape 6 : Vérifier cloud-init et SSH

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

Sortie attendue :

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

Liste de validation :

• [ ] terraform apply se termine avec 4 ressources ajoutées
• [ ] La sortie api_ip affiche une adresse publique réservée
• [ ] cloud-init status renvoie done et Docker est installé
• [ ] SSH se connecte en utilisant la clé injectée

Nettoyage :

terraform destroy -auto-approve

Erreurs courantes

Erreurs de développeur à éviter avec l'automatisation de calcul sur IONOS Cloud :

1. Définition d'une famille CPU sur un vCPU Server

   • Problème : Votre terraform apply échoue ou le serveur de travail est provisionné avec une famille CPU inattendue lorsque vous définissez cpu_family sur une configuration vCPU.
   • Pourquoi cela se produit : La famille CPU d'un vCPU Server ne peut pas être choisie lors de la création et ne peut pas être modifiée plus tard. Seuls les serveurs Dedicated Core supportent la sélection de la famille (Core Technology Choice).
   • Correction : Omettez cpu_family entièrement pour les serveurs vCPU et définissez-le uniquement sur les serveurs Dedicated Core :

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

2. En attendant que VM Auto Scaling redimensionne une VM en cours d'exécution

   • Problème : Vous augmentez les cœurs ou les RAM dans la configuration de réplica en attendant que les réplicas existants grandissent, mais les machines virtuelles en cours d'exécution restent de la même taille.
   • Pourquoi cela se produit : VM Auto Scaling est uniquement horizontal. Il ajoute et supprime des réplicas entiers plutôt que de les redimensionner, et les modifications de configuration de réplica ne s'appliquent qu'aux réplicas nouvellement créés.
   • Correction : Laissez le groupe mettre à l'échelle en ajoutant des réplicas pour absorber la charge. Si une charge de travail a réellement besoin de machines virtuelles plus grandes, redimensionnez le serveur en dehors du groupe de mise à l'échelle automatique, ou laissez le groupe remplacer les réplicas pour que la nouvelle taille prenne effet.

3. En supposant qu'un Cube cesse de facturer lorsqu'il est suspendu

   • Problème : Vous suspendez Cubes utilisé pour les travaux par lots pour économiser de l'argent, mais la facture continue de croître.
   • Pourquoi cela se produit : Pour Cubes, seule la suppression arrête la facturation, et non la suspension. Les ressources NVMe Volume et les ressources de modèle obligatoires restent réservées pendant la suspension.
   • Correction : Détruisez les Cubes éphémères avec terraform destroy au lieu de les suspendre, ou convertissez la charge de travail en un serveur standard que vous pouvez arrêter.

Résumé

Vous pouvez maintenant provisionner IONOS compute entièrement en code : des serveurs Dedicated Core et vCPU avec les contraintes CPU et RAM correctes, une initialisation cloud-init qui installe et démarre votre runtime au premier démarrage, des adresses IP publiques réservées qui survivent aux reconstructions, et un groupe de mise à l'échelle automatique horizontale pour les workers sans état. Vous savez également quels charges de travail appartiennent aux serveurs standard par rapport aux Cubes, et comment les modèles de facturation et de stockage diffèrent entre eux.

Il s'agit de la fondation de calcul de TaskBoard. La prochaine unité relie ces serveurs à un réseau multi-niveaux, mais les modèles ici, les images résolues par source de données, la configuration cloud en base64, les blocs IP réservés et la mise à l'échelle automatique horizontale, se répètent dans chaque pile d'infrastructure que vous construisez sur IONOS Cloud.

Points clés :

• Les serveurs Dedicated Core permettent la sélection de la famille CPU ; les serveurs vCPU ont une famille fixe lors de la création
• VM Auto Scaling est uniquement horizontal : il ajoute et supprime des répliques de serveurs entières, et les modifications de configuration de réplique ne s'appliquent qu'aux nouvelles répliques
• Les deux modèles de serveurs ont un maximum de 62 cœurs / 60 vCPUs et 230 Go RAM, avec RAM réglé en incréments de 0,25 Go
• La configuration cloud-init user_data est codée en base64 et immuable ; la modifier nécessite de recréer le Volume
• Les serveurs de calcul existent uniquement dans la zone 1, la zone 2 ou AUTO, sans zone 3 pour le calcul
• Les Cubes ont un NVMe Volume obligatoire fixe, supportent jusqu'à 23 appareils Block Storage supplémentaires et arrêtent la facturation uniquement lors de la suppression

Terminologie importante :

• Dedicated Core Server : Un serveur de calcul avec des cœurs physiques exclusifs et une famille CPU sélectionnable et modifiable.
• vCPU Server : Un serveur de calcul avec des ressources CPU partagées dont la famille CPU est fixe lors de la création.
• Cloud-init : Le package d'automatisation de premier démarrage, présent sur toutes les images publiques Linux, qui applique la configuration user_data comme l'installation de packages et l'injection de clés SSH.
• Choix de technologie de base : La fonctionnalité Dedicated Core qui vous permet de déplacer un serveur existant vers une nouvelle génération CPU sans le reconstruire.
• Bloc IP : Un ensemble réservé d'adresses IP publiques IP (ionoscloud_ipblock) qui persiste à travers la reconstruction du serveur, utilisé pour les points de terminaison stables.

Prochaines étapes

Continuer l'apprentissage : Unité 2.2 : Réseau et connectivité en tant que code

Sujets connexes :

• Unité 1.2 : Fournisseur Terraform et modèles de base
• Unité 2.4 : Provisionnement de stockage en tant que code