Unité 2.1 : Calcul et automatisation des serveurs

Introduction

Vous êtes en train de construire TaskBoard, un service de gestion de tâches qui nécessite un serveur API persistant et une flotte de workers sans état. Avant l'exécution de tout code applicatif, vous devez provisionner la couche de calcul de manière reproductible, à chaque fois, à partir d'un dépôt Git plutôt que d'une console. Cette unité vous guide depuis une ressource ionoscloud_server unique 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 modalités de facturation et de sémantique CPU différentes, une configuration automatisée de la première mise en route via cloud-init, et un auto-scaler horizontal qui impose des exigences strictes que vous devez coder correctement, sinon votre terraform apply échouera. Vous rédigerez le Terraform pour le serveur API de TaskBoard (Dedicated Core, 4 cœurs, 8 Go de RAM) et son worker (vCPU, 2 cœurs), vous intégrerez cloud-init pour installer le runtime, et vous associerez une IP publique afin de pouvoir vous connecter via SSH et vérifier le résultat.

1. Provisionnement de serveurs avec Terraform

La ressource ionoscloud_server est le bloc de construction fondamental de la couche de calcul. Un serveur est toujours hébergé dans un ionoscloud_datacenter (un centre de données virtuel, ou VDC) et est créé avec une famille de 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 Dedicated Core ou CUBE pour Cubes, et le choix entre une configuration Dedicated Core ou une configuration vCPU.

Un serveur Dedicated Core minimal pour la couche API de TaskBoard est présenté ci-dessous. Le volume de démarrage 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 d'être 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
  }
}

La RAM est spécifiée en mégaoctets, de sorte que 8 Go correspondent à 8192. La création du serveur est asynchrone, mais le fournisseur Terraform interroge en interne l'état de la requête IONOS CLOUD, de sorte qu'au moment où apply est renvoyé, le serveur a atteint l'état DONE et le volume de démarrage est attaché. Vous n'effectuez pas d'interrogation manuelle dans Terraform comme vous le feriez avec un appel API brut.

1.1 Cœur dédié par rapport à vCPU

Le choix du modèle de serveur n'est pas purement cosmétique. Un serveur à cœur dédié offre à votre VM un usage exclusif de ses cœurs physiques, et vous pouvez sélectionner puis modifier ultérieurement la famille de CPU. Un serveur vCPU partage les ressources CPU et sa famille de CPU est fixée à la création et ne peut pas être modifiée par la suite. La couche API de TaskBoard exige une latence prévisible, elle utilise donc des cœurs dédiés. La couche de travailleurs est intermittente et sensible aux coûts, elle utilise donc des vCPU.

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

Modèle	Classe de CPU	Cœurs/vCPUs max	RAM max	Famille de CPU sélectionnable
Cœur dédié	Exclusif	62 cœurs	230 Go	Oui (modifiable ultérieurement)
vCPU	Partagé	60 vCPUs	230 Go	Non (fixé à la création)

La RAM peut être réglée par incréments de 0,25 Go. La fonctionnalité de changement de famille de CPU sur les serveurs à cœur dédié s'appelle Core Technology Choice, qui permet de déplacer un serveur existant vers une génération de CPU plus récente sans le reconstruire. Les modèles de 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 travailleur TaskBoard est un serveur vCPU. 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'existe pas de zone 3 pour le calcul, même si les volumes Block Storage proposent une zone 3. Si vous définissez availability_zone = "ZONE_3" sur un serveur, la demande échoue. Utilisez AUTO, sauf si vous répartissez délibérément les répliques entre les zones pour la tolérance aux pannes, auquel cas attachez 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 l'initialisation automatisée

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 Linux publiques sur IONOS CLOUD (Alma Linux, Debian, Rocky Linux et Ubuntu) sont livrées avec cloud-init déjà installé, vous passez donc la configuration via le champ user_data et elle s'exécute automatiquement.

Vous fournissez user_data en tant que chaîne encodée en base64 dans Terraform et l'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 conteneur d'exécution, crée un utilisateur d'application et démarre le service API de TaskBoard. Il est stocké dans un fichier séparé et encodé 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

Intégrez-le à la ressource 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 les données encodées en base64 (le contenu décodé doit correspondre à 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 prise en compte que lors de la création du volume, de sorte qu'une modification ultérieure nécessite de recréer le volume, et non de le mettre à jour sur place.

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

Vous pouvez injecter des clés SSH de deux façons : via la liste ssh_keys du volume, ou à l'intérieur du bloc ssh_authorized_keys de cloud-config. L'argument ssh_keys est le moyen le plus simple pour une clé unique sur l'utilisateur par défaut. Après apply, l'adresse IP publique apparaît dans les attributs exportés de l'interface 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 cloud-init status --wait se poursuit jusqu'à la fin de la configuration au premier démarrage, ce qui est le signal correct indiquant 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 d'une IP publique

Les serveurs sur un LAN public reçoivent automatiquement une IP via DHCP, mais cette adresse est éphémère et peut changer. Pour obtenir une IP publique stable et réservée, allouez un ionoscloud_ipblock et assignez l'une de ses adresses à la carte réseau. Cette opération est requise pour le point d'accès API de TaskBoard, auquel les enregistrements DNS et les équilibreurs de charge sont dirigés.

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 subsiste après la recréation du serveur, ce qui signifie que vous pouvez reconstruire le serveur API sans modifier l'adresse à laquelle vos enregistrements DNS résolvent. Le location du bloc IP doit correspondre à l'emplacement du centre de données, sinon l'attribution échoue.

4. Images and Snapshots as Code

La source de données ionoscloud_image résout une image système d'exploitation en un identifiant au moment de la planification, afin que vous n'ayez jamais à coder en dur un identifiant d'image volatile. Filtrez par type, location, cloud_init et image_alias pour fixer l'image exacte souhaitée.

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

Pour des environnements de référence reproductibles, capturez un volume de démarrage configuré sous forme d'instantané et approvisionnez de nouveaux serveurs à partir de celui-ci. La ressource ionoscloud_snapshot crée un instantané à partir d'un volume existant, et cet identifiant d'instantané peut servir à initialiser des volumes futurs.

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

Les Snapshots sont complets et actifs dans la même région que le volume source. L'utilisation d'un Snapshot comme base pour de nouveaux serveurs permet d'ignorer l'étape d'installation cloud-init 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 nouvellement créés.

5. VM Auto Scaling

VM Auto Scaling est actuellement en accès anticipé (EA) ; IONOS CLOUD recommande de le limiter aux charges de travail non de production, et son API Cloud est versionnée séparément à https://api.ionos.com/autoscaling (version v1.ea) plutôt que 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 des VM supplémentaires, il ne redimensionne pas une VM existante. Vous définissez une configuration cible des répliques, des politiques de réduction et d'expansion, ainsi que 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 à partir de votre ionoscloud_autoscaling_group, adossées à des serveurs Compute Engine. Les modifications de la configuration des répliques s'appliquent aux répliques nouvellement créées, et non aux répliques déjà en cours d'exécution. Les types de stockage des répliques pris en charge sont HDD, SSD Premium et SSD Standard. Les options de métrique de mise à l'échelle sont la moyenne de l'utilisation du CPU des instances (pourcentage), les octets réseau entrants, les octets réseau sortants, les paquets réseau entrants et les paquets réseau sortants.

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 politique. Le modèle de réplique définit la dimension de chaque réplique de serveur que le groupe provisionne.

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 VM) ou PERCENTAGE (une proportion du nombre actuel). La période de refroidissement par défaut est de 5 minutes, le nombre minimal de répliques est de 1, et le plafond recommandé est d'environ 100 répliques. Un groupe peut être associé à un Application Load Balancer afin que les nouvelles répliques soient automatiquement ajoutées au pool de cibles du LB.

5.2 Les répliques sont nommées, mais ne sont pas adressables par identifiant de serveur

Un piège opérationnel subtil : les noms de serveurs de réplique générés automatiquement sont des noms, et non des identifiants de serveur, et ils ne peuvent pas être utilisés pour récupérer des informations via l'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-vous à elles via le groupe et le load balancer, et non par identifiant de serveur individuel.

6. Cubes pour les charges de travail sans état

Les Cubes sont un type de serveur de calcul doté d'un stockage NVMe en direct obligatoire, défini par un modèle de configuration. Le modèle le plus petit, Basic Cube XS, fournit 1 vCPU, 2 Go de RAM et 60 Go de stockage NVMe en direct. La taille du vCPU, de la RAM et du stockage en direct est fixée par le modèle et ne peut pas être modifiée après le provisionnement du Cube, et le volume NVMe ne peut pas être démonté ni supprimé.

Un Cube n'est cependant pas uniquement un stockage. En plus du volume NVMe obligatoire, vous pouvez attacher jusqu'à 23 périphériques de stockage bloc en option, soit 24 emplacements de périphériques au total, le volume NVMe occupant un emplacement. Le NVMe à modèle fixe et le modèle économique compatible avec la suspension rendent les Cubes bien adaptés aux charges de travail sans état ou éphémères où vous souhaitez un forfait 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 subtilité de facturation à intégrer dans vos scripts de cycle de vie : pour Cubes, seule la suppression met fin à la facturation, la suspension ne le fait pas. La suspension d'un Cube maintient le compteur en fonctionnement. Si vous déployez des Cubes pour des traitements par lots et que vous vous attendez à cesser 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.

Fiche de référence rapide de l'API

Points de terminaison API clés pour le provisionnement de calcul :

Méthode	Point de terminaison	Description
`GET`	`/datacenters/{dcId}/servers`	Liste tous les serveurs d'un VDC
`POST`	`/datacenters/{dcId}/servers`	Crée un nouveau serveur
`GET`	`/datacenters/{dcId}/servers/{serverId}`	Récupère les détails d'un serveur
`PATCH`	`/datacenters/{dcId}/servers/{serverId}`	Met à jour les propriétés d'un serveur
`DELETE`	`/datacenters/{dcId}/servers/{serverId}`	Supprime un serveur
`POST`	`/ipblocks`	Réserve un bloc d'IP public
`GET`	`/groups`	Liste les groupes de mise à l'échelle automatique
`POST`	`/groups`	Crée un groupe de mise à l'échelle automatique

URL de base Compute Engine / IP Blocks : 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>

Atelier de code

Objectif : Déployer la couche de calcul de TaskBoard avec Terraform : un serveur Dedicated Core API initialisé par cloud-init, avec une IP publique 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 ou version ultérieure 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 : Rédiger 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 contrôle de validation :

[ ] terraform apply s'achève avec l'ajout de 4 ressources
[ ] La sortie api_ip affiche une adresse publique réservée
[ ] cloud-init status renvoie done et Docker est installé
[ ] SSH se connecte à l'aide de la clé injectée

Nettoyage :

terraform destroy -auto-approve

Erreurs courantes

Erreurs de développement à éviter lors de l'automatisation du calcul sur IONOS CLOUD :

Définition d'une famille de CPU sur un serveur vCPU
- Problème : Votre terraform apply échoue ou le serveur de travail est provisionné avec un CPU inattendu lorsque vous définissez cpu_family sur une configuration vCPU.
- Cause : La famille de CPU d'un serveur vCPU ne peut pas être choisie lors de la création et ne peut pas être modifiée ultérieurement. Seuls les serveurs Dedicated Core prennent en charge la sélection de la famille (Core Technology Choice).
- Solution : Omettez cpu_family entièrement pour les serveurs vCPU et ne le définissez que sur les serveurs Dedicated Core :
```
resource "ionoscloud_server" "worker" {
  cores = 2
  ram   = 4096
  # no cpu_family on vCPU servers
}
```
S'attendre à ce que VM Auto Scaling redimensionne une VM en cours d'exécution
- Problème : Vous augmentez le nombre de cœurs ou la RAM dans la configuration des répliques en vous attendant à ce que les répliques existantes augmentent de taille, mais les VM en cours d'exécution conservent leur taille initiale.
- Pourquoi cela se produit : VM Auto Scaling est uniquement horizontal. Il ajoute et supprime des répliques entières plutôt que de les redimensionner, et les modifications de la configuration des répliques ne s'appliquent qu'aux répliques nouvellement créées.
- Correction : Laissez le groupe effectuer une mise à l'échelle horizontale en ajoutant des répliques pour absorber la charge. Si une charge de travail nécessite réellement des VM individuelles plus grandes, redimensionnez le serveur en dehors du groupe de mise à l'échelle automatique, ou laissez le groupe remplacer les répliques afin que le nouveau dimensionnement prenne effet.
Supposer qu'un Cube cesse d'être facturé lorsqu'il est suspendu
- Problème : Vous suspendez les Cubes utilisés pour les travaux par lots afin d'économiser de l'argent, mais la facture continue d'augmenter.
- Pourquoi cela se produit : Pour les Cubes, seule la suppression arrête la facturation, pas la suspension. Le volume NVMe obligatoire et les ressources du modèle restent réservés 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 désormais provisionner l'infrastructure de calcul IONOS CLOUD entièrement sous forme de code : serveurs Dedicated Core et vCPU avec les contraintes de CPU et de RAM appropriées, un amorçage cloud-init qui installe et démarre votre environnement d'exécution au premier démarrage, des adresses IP publiques réservées qui subsistent après les reconstructions, et un groupe de mise à l'échelle automatique horizontale pour les travailleurs sans état. Vous savez également quelles charges de travail conviennent aux serveurs standard par rapport aux Cubes, et comment les modèles de facturation et de stockage diffèrent entre eux.

Ceci constitue la base de calcul de TaskBoard. L'unité suivante attache ces serveurs à un réseau multi-niveaux, mais les schémas présentés ici, à savoir les images résolues par source de données, la configuration cloud en base64, les blocs d'IP réservés et la mise à l'échelle automatique horizontale, se retrouvent 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 de CPU ; les serveurs vCPU ont un ensemble de familles fixe à 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 des répliques ne s'appliquent qu'aux nouvelles répliques
Les deux modèles de serveurs atteignent un maximum de 62 cœurs / 60 vCPUs et 230 Go de RAM, avec la RAM réglée par incréments de 0,25 Go
Le user_data de Cloud-init est encodé en base64 et immuable ; sa modification nécessite la recréation du volume
Les serveurs de calcul existent uniquement dans la Zone 1, la Zone 2 ou AUTO, sans Zone 3 pour le calcul
Les Cubes comportent un volume NVMe fixe et obligatoire, prennent en charge jusqu'à 23 périphériques de stockage en bloc supplémentaires, et cessent d'être facturés uniquement lors de la suppression

Terminologie importante :

Serveur Dedicated Core : Un serveur de calcul doté de cœurs physiques exclusifs et d'une famille de CPU sélectionnable et modifiable.
Serveur vCPU : Un serveur de calcul doté de ressources CPU partagées dont la famille de CPU n'est pas sélectionnable et ne peut pas être modifiée (l'hyperviseur l'assigne).
Cloud-init : Le paquet d'automatisation du premier démarrage, présent sur toutes les images Linux publiques, qui applique la configuration user_data telle que l'installation de paquets et l'injection de clés SSH.
Choix de technologie de cœur : La fonctionnalité Dedicated Core qui vous permet de déplacer un serveur existant vers une génération de CPU plus récente sans le reconstruire.
Bloc d'IP : Un ensemble réservé d'adresses IP publiques (ionoscloud_ipblock) qui persiste au-delà de la recréation du serveur, utilisé pour des points de terminaison stables.

Prochaines étapes

Continuer à apprendre : Unité 2.2 : Network and Connectivity as Code

Sujets connexes :

Objectifs d'apprentissage

Unité 2.1 : Calcul et automatisation des serveurs

Introduction

1. Provisionnement de serveurs avec Terraform

1.1 Cœur dédié par rapport à vCPU

1.2 Zones de disponibilité

2. Cloud-init pour l'initialisation automatisée

2.1 Cloud-config pour TaskBoard

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

3. Allocation d'une IP publique

4. Images and Snapshots as Code

5. VM Auto Scaling

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

5.2 Les répliques sont nommées, mais ne sont pas adressables par identifiant de serveur

6. Cubes pour les charges de travail sans état

Fiche de référence rapide de l'API

Atelier de code

Erreurs courantes

Résumé

Prochaines étapes