Serveurs cloud Linux sur Dockup : 7 distributions disponibles

Les serveurs cloud Linux fournissent un environnement de système d’exploitation que vous configurez via SSH. Ils sont utiles pour les expérimentations, les logiciels legacy, les services système personnalisés, les build hosts et les workloads dont le cycle de vie n’est pas naturellement lié à un dépôt Git ou à une image de conteneur.

Dockup prend en charge sept images : Ubuntu 22.04, Ubuntu 24.04, Debian 12, Alpine 3.20, Fedora 40, AlmaLinux 9 et Rocky Linux 9.

Quand un serveur Linux est-il préférable à un service de conteneur ?

Choisissez un serveur lorsque le workload nécessite de contrôler le système d’exploitation, et pas uniquement un processus applicatif.

Voici quelques cas adaptés :

• Installer plusieurs daemons système.
• Tester interactivement des packages du système d’exploitation.
• Exécuter une application legacy avec une configuration manuelle.
• Gérer un build host ou un hôte d’automatisation.
• Reproduire l’environnement Linux d’un client.
• Exécuter des outils longue durée qui ne sont pas organisés comme un déploiement Git.
• Créer un espace de travail SSH temporaire et isolé.

Préférez un service Dockup lorsque le workload est une application reproductible disposant d’un dépôt, d’une commande de build, d’une commande de démarrage, d’un endpoint de health check et de besoins de scaling horizontal.

Besoin	Serveur Linux	Service de conteneur
Personnalisation poussée du système avec les privilèges root	Très adapté	Placer les modifications dans le Dockerfile
Administration SSH	Native	Interactive shell is PRO
Auto-déploiement par push Git	Configuration manuelle	Intégré
Garde-fou de health check blue-green	Conception manuelle	Intégré
Image reproductible	Runbook ou script nécessaire	Dockerfile/Nixpacks
Autoscaling	Ne correspond pas au modèle du serveur	Option Kubernetes
Test rapide d’une distribution	Très adapté	L’image de base peut suffire

Un serveur offre de la flexibilité au niveau du système d’exploitation au prix d’une automatisation moindre du déploiement.

Quelles sont les sept distributions Linux disponibles ?

Consultez la liste actuelle des images :

dockup box images --json

Image	Écosystème de packages	Raison courante de la choisir
ubuntu-22.04	APT	Compatibilité à long terme
ubuntu-24.04	APT	Base Ubuntu LTS plus récente
debian-12	APT	Serveur généraliste conservateur
alpine-3.20	apk	Environnement léger basé sur musl
fedora-40	DNF	Outils Linux plus récents
almalinux-9	DNF	Compatibilité avec Enterprise Linux
rockylinux-9	DNF	Compatibilité avec Enterprise Linux

Choisissez la distribution en fonction de l’environnement pris en charge par l’éditeur du logiciel. Alpine utilise musl plutôt que glibc, ce qui peut avoir un impact sur les binaires natifs précompilés. Les variantes Enterprise Linux sont utiles lorsque le logiciel attend cet écosystème de packages.

Notez le slug exact de l’image. « Ubuntu » ne suffit pas, car les versions des packages et les périodes de support diffèrent entre 22.04 et 24.04.

Comment créer un serveur cloud Linux ?

Provisionnez l’image avec un nom, une quantité de mémoire et un nombre de CPU :

dockup box create \
  --project production \
  --image ubuntu-24.04 \
  --name build-host \
  --memory 2048 \
  --cpu 1 \
  --json

Cet exemple demande 2 048 Mo de RAM et 1 vCPU. Commencez par des besoins mesurés et ajustez-les en fonction du workload observé. Le CPU, la RAM et le disque sont déduits du solde du plan selon une mesure à la minute.

Le plan Free coûte 0 $ par mois et inclut un crédit initial de 10 $, un workspace, trois bases de données et trois déploiements. Les plans payants autorisent un nombre illimité de ressources, mais le compute réellement utilisé est toujours déduit du solde inclus. Le plan Pro recommandé coûte 20 $ par mois et inclut 20 $ de crédit d’utilisation.

Le serveur créé devient une ressource du projet avec une cible stable telle que production/build-host. Conservez cette cible dans le runbook.

Comment récupérer et protéger l’accès SSH ?

Demandez les informations de connexion :

dockup box ssh production/build-host --json

La réponse contient l’hôte, le port, l’utilisateur et le mot de passe. Considérez le mot de passe comme une information sensible. Stockez-le dans un gestionnaire de mots de passe approuvé, ne l’affichez pas dans la réponse d’un agent et faites-le régulièrement tourner ou remplacez l’accès conformément à la politique de l’organisation.

Avant de vous connecter :

1. Vérifiez le projet et le slug du serveur.
2. Confirmez que l’opérateur est autorisé.
3. Notez l’objectif de la session.
4. Évitez de copier des secrets de production sur un serveur temporaire.
5. Veillez à ce que l’historique des commandes et les logs ne contiennent aucun identifiant.
6. Fermez les chemins d’accès et les sessions inutilisés.

L’accès SSH donne des privilèges étendus à l’intérieur du serveur. Un agent de programmation disposant des identifiants pourrait installer des packages, modifier des services, exposer des ports ou supprimer des fichiers. N’autorisez l’accès d’un agent que dans le cadre d’une tâche précise et validée, et conservez une trace d’audit en dehors du shell.

L’article Garde-fous de production pour les agents IA présente le modèle d’autonomie.

Comment démarrer un workload SSH sur un serveur Linux ?

Après avoir récupéré l’accès SSH, configurez le démarrage des processus avec les outils système pris en charge par la distribution. Ubuntu, Debian, Fedora, AlmaLinux et Rocky Linux utilisent généralement systemd ; Alpine possède ses propres conventions de gestion des services.

La définition de démarrage doit préciser l’exécutable, le répertoire de travail, l’utilisateur d’exécution, l’environnement requis, la stratégie de redémarrage et la destination des logs. Conservez les identifiants en dehors du fichier d’unité ou du script de démarrage et utilisez des chemins absolus afin que le comportement ne dépende pas d’un shell interactif.

Vérifiez les points suivants :

• Le workload démarre après un redémarrage sans connexion d’un opérateur.
• L’environnement requis est disponible sans exports propres au shell.
• Les logs se trouvent dans un emplacement connu.
• Le processus s’exécute avec l’utilisateur prévu.
• Les défaillances sont détectables.
• Les mises à jour ne remplacent pas silencieusement les dépendances.

Pour un processus web unique répondant à ces exigences, un service de conteneur basé sur Git peut déjà offrir un meilleur cycle de vie.

Comment exploiter et reconstruire un serveur Linux ?

Considérez chaque commande manuelle comme une source potentielle de configuration drift. Documentez la configuration dans un script ou un processus de gestion de configuration :

#!/usr/bin/env bash
set -euo pipefail

apt-get update
apt-get install -y git ca-certificates
mkdir -p /opt/app

Cet exemple générique n’est pas une commande Dockup ; il montre comment rendre la configuration d’un serveur reproductible. Épinglez ou documentez les versions des packages lorsque le workload exige de la stabilité.

Le runbook d’un serveur doit inclure :

• Le slug de l’image.
• Le CPU et la mémoire demandés.
• Les packages et dépôts installés.
• Les comptes utilisateurs et la politique SSH.
• Les emplacements du système de fichiers.
• Le service de démarrage, l’exécutable et le répertoire de travail.
• Les services ouverts et leur authentification.
• La méthode de sauvegarde des données.
• La procédure de patch et de redémarrage.
• Les étapes de reconstruction.
• Les critères de migration ou de retrait.

Ne supposez pas que le système de fichiers d’un serveur utilise le même workflow de snapshots que le volume d’un service Dockup, sauf si ce workflow est explicitement configuré et pris en charge pour la ressource. Concevez les sauvegardes en fonction des données et des logiciels qui y sont réellement exécutés.

Quand faut-il déplacer le workload dans un conteneur ?

Passez à un service de conteneur lorsque :

• La configuration est devenue un script stable.
• Un seul processus applicatif constitue l’objectif principal.
• Les modifications du code source doivent être déployées depuis Git.
• Des releases sans interruption de service, protégées par un health check, sont nécessaires.
• Le rollback doit permettre de sélectionner un ID de déploiement précédent.
• Plusieurs replicas identiques sont nécessaires.
• La configuration du serveur dérive selon les opérateurs.
• SSH ne sert qu’à redéployer manuellement.

Convertissez la configuration en Dockerfile, définissez le port applicatif et le chemin de health check, puis déployez d’abord un service de preview ou hors production. Comparez son comportement avant d’arrêter le serveur.

Le guide Nixpacks vs Dockerfile vous aide à choisir la nouvelle méthode de build. Kubernetes vs Docker présente les options de placement au niveau du runtime.

Checklist de sélection d’un serveur Linux

Une décision fiable concernant les serveurs cloud Linux répond aux questions suivantes :

1. Lequel des sept slugs d’image correspond au support de l’éditeur ?
2. Pourquoi le workload ne peut-il pas utiliser un service standard ?
3. Comment les identifiants SSH sont-ils protégés ?
4. Comment la configuration est-elle reproduite ?
5. Où se trouvent les logs et les données persistantes ?
6. Comment les patches sont-ils testés ?
7. Quel processus doit démarrer automatiquement ?
8. Quel événement déclenche la conteneurisation ou le retrait ?

Consultez la référence de la CLI Dockup pour connaître les commandes actuelles relatives aux serveurs et la liste des images. Pour les workloads exclusivement Windows, comparez avec Machine virtuelle Windows avec RDP.

Contrôler la fiabilité des packages et des dépôts

Un serveur peut installer n’importe quel package demandé par l’opérateur ; les sources des packages font donc partie de la boundary de sécurité. Utilisez les dépôts signés de la distribution, documentez les dépôts tiers et évitez d’envoyer directement des scripts réseau non vérifiés dans un shell root.

Enregistrez la liste des packages après la configuration et comparez-la lors des opérations de maintenance. Lorsqu’un agent propose d’installer un outil, exigez la source du package, sa version, son objectif et son plan de suppression.

Mesurer si le serveur reste justifié

Examinez chaque mois la fréquence des sessions SSH, les étapes de déploiement manuel, les besoins de disponibilité, l’utilisation des ressources et les incidents de drift. Un serveur qui reçoit régulièrement des releases applicatives via SSH indique qu’il a probablement besoin d’un workflow de service reproductible.

Consultez la consommation de CPU, de RAM et de disque du serveur dans app.dockup.ai, en parallèle du runbook. Les serveurs cloud Linux sont précieux lorsque le contrôle du système d’exploitation est requis ; ils deviennent coûteux à exploiter lorsqu’ils ne servent qu’à dissimuler un déploiement applicatif non documenté.

Retirer les serveurs temporaires de manière volontaire

Un serveur de test doit avoir un responsable et une date d’expiration dès sa création. Avant son retrait, exportez uniquement les données persistantes approuvées, supprimez les identifiants copiés, conservez tout script de configuration réutilisable et vérifiez qu’aucun DNS, job planifié ou runbook d’équipe ne dépend encore de l’hôte.

Vous éviterez ainsi qu’une expérimentation courte ne devienne un serveur permanent non patché.

Désigner un responsable de l’accès d’urgence

Désignez la personne ou l’équipe responsable lorsque l’opérateur SSH habituel n’est pas disponible. Le responsable suppléant doit savoir où les identifiants sont stockés et comment vérifier la cible exacte sans partager les mots de passe.

Conserver la justification

Documentez pourquoi les serveurs cloud Linux restent nécessaires.

Commencer par un déploiement vérifiable

Créez un petit serveur hors production, automatisez l’intégralité de sa configuration depuis une image vierge et définissez à l’avance les éléments qui justifieraient le déplacement du workload dans un conteneur.

Commencez gratuitement sur app.dockup.ai. Le plan Free coûte 0 $ par mois, inclut un crédit initial de 10 $ et prend en charge un workspace, trois bases de données et trois déploiements.

FAQ

Quelles distributions Linux les serveurs Dockup peuvent-ils utiliser ?

Dockup prend en charge ubuntu-22.04, ubuntu-24.04, debian-12, alpine-3.20, fedora-40, almalinux-9 et rockylinux-9.

Comment obtenir les identifiants SSH d’un serveur Linux ?

Exécutez dockup box ssh avec la cible exacte du projet et du serveur, ainsi que --json, puis stockez les informations de connexion renvoyées de manière sécurisée.

Comment démarrer un logiciel après la configuration de SSH ?

Configurez le démarrage avec le service manager pris en charge par la distribution sélectionnée et documentez l’exécutable, le répertoire de travail, l’utilisateur d’exécution, l’environnement, la stratégie de redémarrage et les logs.

Quand un service de conteneur est-il préférable à un serveur Linux ?

Utilisez un service de conteneur lorsque le workload est une application reproductible unique qui bénéficie d’un déploiement Git, de health checks bloquants, du rollback et de l’autoscaling.

Comment les ressources des serveurs Linux sont-elles facturées ?

La consommation de CPU, de RAM et de disque est mesurée à la minute et déduite du solde du plan. Surveillez donc l’utilisation réelle et évitez les allocations surdimensionnées.