VM Windows dans le cloud avec RDP sur Dockup
VM Windows dans le cloud avec Dockup : choisissez Server 2019/2022/2025 ou Windows 10/11, allouez le CPU et la RAM, récupérez l’accès RDP et exploitez-la de manière sécurisée.
Une VM Windows dans le cloud est adaptée lorsque la charge de travail nécessite un véritable système d’exploitation Windows, un accès RDP interactif, un logiciel exclusivement compatible avec Windows ou un environnement qui ne peut pas être représenté par un conteneur Linux. Dockup prend en charge les machines virtuelles Windows Server 2019, 2022 et 2025, ainsi que Windows 10 et Windows 11.
Une VM ne remplace pas par défaut un conteneur. Elle implique un cycle de vie de système d’exploitation, un accès à distance au bureau, un état logiciel installé et une surface d’attaque plus large. Choisissez-la parce que la charge de travail a besoin de Windows, et non parce que RDP vous est familier.
Quelles charges de travail nécessitent une VM Windows Server ?
Les raisons courantes sont les suivantes :
- Une application fournie par un éditeur ne prend en charge que Windows.
- Le service dépend d’API Windows ou d’une version du .NET Framework qui ne convient pas à Linux.
- Un processus de build ou de test nécessite un bureau Windows.
- Une automatisation contrôle une application native Windows.
- Un service legacy attend un système de fichiers ou un registre Windows.
- Un opérateur a besoin d’un bureau distant isolé pour une tâche approuvée.
- Les tests de compatibilité doivent couvrir Windows 10 ou Windows 11.
N’utilisez pas une VM Windows uniquement pour héberger une API classique en Node.js, Python, Go ou compatible avec les conteneurs. Un service Dockup construit à partir de Git est plus facile à reproduire, à déployer en blue-green, à soumettre à des health checks et à restaurer vers une version précédente.
| Exigence | Meilleur point de départ |
|---|---|
| API web standard | Service Git/conteneur |
| Installeur exclusivement Windows | VM Windows |
| Bureau interactif | VM Windows |
| Worker background sans état | Service conteneurisé |
| Compatibilité navigateur sous Windows | VM Windows 10/11 |
| Test d’un rôle de domaine/serveur | VM Windows Server |
| Shell Linux jetable | Machine Linux |
Rendez explicite la différence de modèle d’exploitation lors de la revue d’architecture.
Quelles versions de Windows Dockup prend-il en charge ?
Interrogez la liste actuelle des images :
dockup win versions --json
Les choix pris en charge sont les suivants :
| Image | Utilisation courante |
|---|---|
server-2019 | Compatibilité avec des serveurs legacy |
server-2022 | Charges de travail de serveurs d’entreprise actuelles |
server-2025 | Nouvelles fonctionnalités serveur et tests |
win-10 | Tests de compatibilité desktop |
win-11 | Environnement desktop actuel |
Sélectionnez la version la plus ancienne qui satisfait les exigences de l’éditeur et de sécurité uniquement lorsque la compatibilité l’impose. Les systèmes plus anciens peuvent accroître les risques liés aux patchs et au support. Pour les nouvelles charges de travail serveur, validez la compatibilité avec les versions de Windows Server prises en charge par l’éditeur.
Consignez la version exacte dans le runbook. « Un serveur Windows » n’est pas une description suffisamment reproductible pour une restauration ou un remplacement.
Comment créer la VM Windows ?
Provisionnez une VM avec une version, une quantité de mémoire et une allocation CPU documentées :
dockup win create \
--project production \
--version server-2022 \
--memory 4096 \
--cpu 2 \
--json
L’exemple demande 4 096 Mo de mémoire et 2 vCPU. Dimensionnez la machine à partir de l’empreinte mémoire mesurée du logiciel, du nombre d’utilisateurs simultanés et des services background. N’allouez pas le maximum « au cas où » : la consommation de CPU, de RAM et de disque est déduite du solde du plan avec une mesure à la minute.
L’installation de Windows est plus lourde que le démarrage d’un conteneur ; le provisioning n’est donc pas un déploiement instantané. Conservez la cible project/VM renvoyée et attendez que la VM soit disponible avant de demander les informations d’accès.
Les plans Dockup payants autorisent un nombre illimité de déploiements, de bases de données et de workspaces. Le plan Pro recommandé coûte 20 $ par mois et inclut 20 $ de crédit d’utilisation, tandis que la consommation réelle des ressources Windows est mesurée séparément du libellé de l’abonnement.
Pour une charge de travail qui nécessite uniquement SSH et un système d’exploitation Linux, comparez les machines Linux.
Comment récupérer et utiliser l’accès RDP ?
Demandez les informations de connexion pour la cible de VM exacte :
dockup win rdp production/win-abc123 --json
La réponse contient l’hôte, le port RDP, le nom d’utilisateur et le mot de passe. Traitez le mot de passe comme un credential susceptible d’être renvoyé lors de la configuration de l’accès ; ne le collez pas dans une réponse d’agent, une issue ou un runbook permanent.
Connectez-vous avec un client RDP depuis un appareil approuvé. Avant d’ouvrir la session :
- Vérifiez que la cible correspond au workspace et à la VM prévus.
- Stockez les credentials dans un password manager approuvé.
- Confirmez qui est autorisé à se connecter.
- Évitez les credentials personnels partagés.
- Consignez l’objectif et la durée prévue de la session.
- Verrouillez ou fermez la session lorsque vous avez terminé.
Le transport RDP fournit un accès interactif ; il ne rend pas toutes les actions d’administration sûres pour autant. Un utilisateur disposant de privilèges d’administrateur peut installer des logiciels, modifier les paramètres du firewall, exposer des données ou désactiver des contrôles de sécurité.
Un agent IA ne doit pas recevoir de credentials RDP bruts dans un prompt. Utilisez la VM pour les opérations desktop contrôlées par un humain ou une voie d’automatisation examinée séparément.
Comment configurer une VM Windows pour la production ?
Traitez la VM comme un serveur dont l’état est déclaré, même si Dockup fournit le compute.
Documentez :
- L’image et l’édition Windows.
- Les exigences en CPU, mémoire et disque.
- Les logiciels installés et la propriété des licences.
- Les services Windows requis.
- La procédure d’installation et de mise à jour de l’application.
- Les répertoires de données et la méthode de backup.
- Les utilisateurs RDP et la policy d’accès.
- La fenêtre de patch et le comportement lors des reboots.
- Les emplacements du monitoring et des logs.
- Le plan de récupération ou de remplacement.
Évitez les connaissances exclusivement manuelles. Conservez les scripts d’installation, les exports de configuration ou des runbooks précis dans le version control, sans credentials. Une VM qui ne peut être reconstruite qu’en se souvenant des clics effectués constitue un point unique de défaillance opérationnelle.
Séparez les données durables de l’état système remplaçable lorsque l’application le permet. Stockez le code source et les installeurs dans des emplacements contrôlés. Sauvegardez les données applicatives avec une méthode adaptée au logiciel concerné ; le workflow de volume d’un service Dockup s’applique aux conteneurs, mais pas automatiquement à chaque application Windows.
Quels contrôles de sécurité sont importants pour RDP ?
RDP est une voie d’accès privilégiée. Appliquez le principe du moindre privilège et réduisez la durée d’exposition.
| Risque | Mesure d’atténuation |
|---|---|
| Partage de credentials | Credentials individuels et contrôlés |
| Mot de passe dans une transcription | Ne jamais l’imprimer ni le copier dans le chat |
| Système d’exploitation non patché | Fenêtre de mise à jour définie |
| Logiciels non suivis | Inventaire des installations |
| Session administrateur persistante | Se déconnecter après utilisation |
| Données copiées sur un appareil local | Policy de transfert approuvée |
| Protection désactivée | Revue et audit de la baseline |
| Dérive de configuration de la VM | Documentation de reconstruction |
Ne désactivez pas les fonctionnalités de sécurité Windows simplement pour faire fonctionner un installeur sans en comprendre les conséquences. Privilégiez une configuration prise en charge par l’éditeur.
Si la VM exécute un service exposé sur Internet, ajoutez le TLS au niveau applicatif, l’authentification, les logs et le monitoring adaptés à ce logiciel. L’accès RDP n’est ni un système de déploiement ni un système d’observabilité.
L’article sur les bonnes pratiques de sécurité présente les principes courants applicables à la production, tandis que l’article sur les garde-fous de production pour les agents IA explique pourquoi les credentials doivent rester en dehors des transcriptions d’agents.
Quand faut-il abandonner la VM ?
Réévaluez l’utilisation de la VM lorsque :
- L’application devient stateless et compatible avec les conteneurs.
- L’installation peut être reproduite dans un Dockerfile.
- L’accès à un bureau interactif n’est plus nécessaire.
- La montée en charge nécessite plusieurs instances identiques.
- Les patchs et la dérive de configuration manuels dominent l’exploitation.
- Un service managé remplace la dépendance exclusivement Windows.
- L’éditeur introduit un déploiement Linux ou web pris en charge.
Un service Dockup conteneurisé bénéficie d’un déploiement basé sur Git, de builds via Dockerfile ou Nixpacks, d’un basculement blue-green sans interruption, de health gates, du déploiement automatique sur push et du rollback des déploiements. Il est difficile de reproduire ces fonctionnalités avec une VM opaque gérée depuis un bureau.
Checklist de transmission d’une VM Windows
Une transmission complète d’une VM Windows dans le cloud contient la cible, la version exacte, le CPU et la mémoire demandés, le responsable RDP, l’emplacement de stockage des credentials, l’inventaire des logiciels installés, la policy de patch, la sauvegarde des données, le monitoring et le plan de reconstruction.
Vérifiez les commandes d’image et d’accès dans la référence de la Dockup CLI. Pour modéliser les coûts à la consommation, consultez Comprendre la tarification des PaaS.
Séparez l’accès desktop de la disponibilité du service
Une session RDP est un canal d’administration, pas un health check. Un bureau déconnecté peut laisser l’application fonctionner, et une connexion RDP réussie ne prouve pas que l’application est healthy.
Définissez des contrôles de niveau service en dehors de la session interactive : endpoint public ou privé, état du service Windows, log applicatif, résultat d’une scheduled task ou monitor fourni par l’éditeur. Consignez l’emplacement d’exécution de ces contrôles et les destinataires des alertes.
Planifiez les patchs et les reboots
Les mises à jour Windows et les installeurs des éditeurs peuvent nécessiter un reboot. Testez la séquence de démarrage de l’application après le reboot et vérifiez que les services requis ne dépendent pas de la connexion d’un opérateur.
Planifiez les patchs, consignez l’état logiciel précédent, protégez les données durables et validez la charge de travail ensuite. Une VM Windows dans le cloud n’est prête pour la production que lorsque la maintenance peut être effectuée sans improviser dans une session desktop ouverte.
Consignez la responsabilité des licences
Documentez quelle organisation possède les licences Windows ou celles des logiciels tiers installés sur la VM, ainsi que la manière dont les droits sont vérifiés lors d’une reconstruction.
Définissez une date de revue des accès
Vérifiez qui peut récupérer ou utiliser le credential RDP et supprimez les accès qui ne répondent plus à un besoin opérationnel actuel.
Commencez par un déploiement vérifiable
Provisionnez une image Windows hors production, documentez chaque étape d’installation manuelle et vérifiez qu’un second opérateur peut se connecter et reconstruire l’environnement sans credentials stockés dans le chat.
Commencez gratuitement sur app.dockup.ai. Le plan Free coûte 0 $ par mois, inclut 10 $ de crédit initial et prend en charge un workspace, trois bases de données et trois déploiements.
FAQ
Quelles versions de Windows Dockup peut-il provisionner ?
Dockup prend en charge les images Windows Server 2019, 2022 et 2025, ainsi que Windows 10 et Windows 11.
Comment obtenir les credentials RDP d’une VM Windows Dockup ?
Utilisez dockup win rdp avec la cible project/VM exacte et --json, puis stockez de manière sécurisée l’hôte, le port, le nom d’utilisateur et le mot de passe renvoyés.
Une API web classique doit-elle s’exécuter dans une VM Windows ?
Généralement non lorsqu’elle est compatible avec les conteneurs. Un service Git ou conteneurisé est plus facile à reproduire, à soumettre à des health checks, à déployer sans interruption et à restaurer vers une version précédente.
Les ressources d’une VM Windows sont-elles facturées comme une instance fixe ?
Dockup mesure la consommation de CPU, de RAM et de disque à la minute et la déduit du solde du plan. Surveillez donc l’utilisation réelle au lieu de vous baser uniquement sur la taille demandée.
Puis-je donner le mot de passe RDP à un agent IA ?
Évitez de placer les credentials RDP dans des prompts ou des transcriptions. Utilisez un accès contrôlé par un humain ou une interface d’automatisation examinée séparément, avec des permissions limitées.
