Migrer votre pile vers Opfield

Ce guide migre une pile existante vers Opfield : serveurs, accès, ingress, charges de travail, bases de données avec leurs sauvegardes et supervision. Chaque étape se termine par une vérification. Les couches migrent indépendamment : vous pouvez migrer un service de bout en bout, ou une couche pour tous les services à la fois. Pour des réponses courtes aux questions avant achat, voir Évaluer Opfield.

1. Installer Opfield et connecter vos serveurs

1. Installez Opfield et terminez la configuration initiale : administrateur, MFA, URL publique.
2. Ajoutez chaque serveur depuis Nodes > Add Node avec sa commande d’une ligne, ou créez de nouveaux serveurs via une intégration d’hébergeur. Attribuez à chaque nœud les rôles dont il a besoin : Ingress, Docker, Storage, Build Worker, Monitoring.
3. En production, exécutez au moins deux relais sur des hôtes autres que l’hôte Opfield.
4. Constituez le jeu de reprise du plan de contrôle et conservez la clé maîtresse séparément des sauvegardes de la base de données.

Vérification : chaque nœud est en ligne avec ses rôles. Les conteneurs et projets Compose qui s’exécutent déjà sur les nœuds Docker apparaissent dans Docker sans aucune importation.

2. Configurer les accès

Créez des groupes correspondant aux responsabilités métier, connectez votre fournisseur SSO si vous en avez un, et invitez l’équipe. Accordez à chaque groupe les Routes, charges de travail, bases de données et nœuds sur lesquels il travaille, jusqu’à la ressource individuelle. Voir Permissions.

Vérification : un opérateur non administrateur réalise un changement normal et se voit refuser toute action hors de ses droits ; les deux apparaissent dans le journal d’audit.

3. Migrer l’ingress

Pour chaque nom d’hôte :

1. Créez le domaine et une Route vers l’application. Une application sur un nœud Docker est jointe via un Secure Link, sans port publié.
2. Émettez un certificat Let’s Encrypt via HTTP-01 ou DNS-01, ou téléversez le certificat existant. HTTP-01 exige que le nœud Ingress soit joignable sur le port 80 ; DNS-01 fonctionne via l’intégration Cloudflare avant la bascule du DNS.
3. Ajoutez des listes d’accès et une page de maintenance là où l’ancien proxy en avait.
4. Faites pointer le DNS vers le nœud Ingress.

Voir Domaines, Routes et TLS.

Vérification : une vraie requête HTTPS via le domaine atteint l’application. Retirez ensuite l’hôte de l’ancien proxy et son certificat de la tâche cron de renouvellement.

4. Migrer les charges de travail

• Les conteneurs autonomes sont déjà listés sur leur nœud Docker. Accordez-y des accès et lisez leurs journaux immédiatement.
• Projets Compose : adoptez le projet (Personal et supérieur). Remplacez env_file par environment: et des variables Opfield, déplacez les montages de répertoires de l’hôte dans l’image ou dans un volume nommé, et conservez les clés de volumes : les volumes nommés gardent leur nom et leurs données. La première application recrée les conteneurs des services ; planifiez-la comme n’importe quel redéploiement.
• Services que vous publiez souvent : exécutez-les en Deployments avec bascule de slots et retour arrière, construits depuis Git sur un Build Worker (Business et supérieur).
• Services qui doivent survivre à la panne d’un serveur : activez Docker Availability (Business et supérieur) pour qu’ils passent sur un autre nœud en cas de panne.
• Déplacement entre serveurs : migrez un conteneur autonome avec les données de ses volumes vers un autre nœud.

Vérification : la charge de travail est saine, sa Route répond, et une publication ainsi qu’un retour arrière aboutissent via Opfield.

5. Migrer les bases de données et les sauvegardes

1. Enregistrez chaque base existante comme connexion externe. Elle bénéficie immédiatement des vérifications de santé, des métriques, de l’Explorer, de la Console et des sauvegardes planifiées.
2. Pour la transformer en base managée, arrêtez les écritures, effectuez une sauvegarde et restaurez-la depuis la Console. La restauration crée une nouvelle base managée sur un nœud Storage et n’écrase jamais la source.
3. Connectez l’application via une liaison privée. L’application obtient sa propre identité de base de données, sans port ouvert.
4. Pour un basculement automatique, exécutez la base sur plusieurs serveurs (Business et supérieur).
5. Planifiez des sauvegardes vers S3, FTP, FTPS ou SFTP.

Vérification : l’application fonctionne via la liaison, et la restauration de la dernière sauvegarde dans une nouvelle base réussit.

6. Migrer la supervision, les alertes et le statut

L’état de santé et les métriques des nœuds arrivent dès l’enrôlement, et les journaux des conteneurs et des Routes sont rattachés à leurs ressources. Ajoutez des règles d’alerte et des canaux de notification pour ce dont l’équipe doit être informée, et publiez une page de statut avec des composants pour les services publics. Voir Observabilité.

Vérification : une alerte de test atteint son canal, et la page de statut affiche chaque composant public. Désactivez ensuite les anciens tableaux de bord, alertes et contrôles de disponibilité pour les services migrés.

7. Retirer les anciens outils

Donnez à chaque ressource un seul propriétaire : retirez les ressources migrées des anciennes configurations de proxy, scripts, panneaux et tâches cron afin que rien ne réécrive ce qu’Opfield possède désormais. Fermez les ports et panneaux de gestion devenus inutiles grâce à Opfield ; les nœuds se connectent en sortie.

À consigner pour chaque service

• qui en est responsable et quel groupe l’exploite ;
• le résultat d’une publication et d’un retour arrière ;
• le résultat d’une restauration de sauvegarde ;
• le canal d’alerte et le composant de la page de statut.

Aide à la migration

Business inclut Guided Onboarding and Configuration Review, et Enterprise inclut Assisted Deployment and Migration, en tant qu’avantages du plan ; le contrat commercial en définit l’étendue. Pour obtenir de l’aide avec un autre plan, contactez [email protected].