Migrer depuis un VPS ou serveur dédié

Votre application tourne sur un VPS ou un serveur dédié — installée à la main, gérée en SSH. La migrer vers Kontainers se fait en quatre temps : inventorier, conteneuriser, externaliser l’état, basculer.

Vous utilisez déjà docker-compose sur votre serveur ?

Passez directement par Migrer depuis un docker-compose — la moitié du travail est déjà faite.

1. Inventorier ce qui tourne

Avant de toucher à quoi que ce soit, listez sur votre serveur :

À inventorier	Comment	Devient sur Kontainers
Les processus / services systemd	systemctl list-units --type=service --state=running	Un Deployment par service
Les ports écoutés	ss -tlnp	Services + Ingress
Les tâches cron	crontab -l (tous les utilisateurs)	CronJobs
Les fichiers écrits par l’app	uploads, caches, données…	PVC — ou stockage objet externe
La base de données	dump + taille	Conteneur + PVC, ou PostgreSQL managé
La configuration	/etc/, variables, fichiers .env	ConfigMaps et Secrets
Les certificats TLS	souvent certbot	Rien à migrer : émis automatiquement

2. Conteneuriser l’application

Si votre application n’a pas encore d’image Docker, un Dockerfile minimal suffit souvent :

FROM node:22-slim            # ou python, php, golang… selon votre stack
WORKDIR /app
COPY . .
RUN npm ci --omit=dev
ENV NODE_ENV=production
EXPOSE 8080
CMD ["node", "server.js"]

Deux règles d’or pour un conteneur qui se comporte bien sur Kubernetes :

1. Ne stockez rien dans le conteneur : tout ce qui doit survivre va dans un volume ou la base de données ;
2. Loggez sur la sortie standard (pas dans des fichiers) : vos logs seront accessibles via kubectl logs et la console Rancher.

Construisez et poussez l’image vers un registre, puis déployez-la.

3. Externaliser l’état

• Base de données : dump sur le serveur (pg_dump, mysqldump), déploiement de la base sur Kontainers (exemple MySQL), puis restauration du dump via kubectl exec ou un Job ;
• Fichiers (uploads, médias…) : copie vers un PVC — montez le volume dans un pod temporaire et transférez avec kubectl cp ou rsync via kubectl exec ;
• Configuration : recréez-la en ConfigMaps et Secrets — c’est le moment de sortir les mots de passe des fichiers de conf.

4. Basculer le DNS (avec retour arrière)

1. La veille : abaissez le TTL de vos enregistrements DNS à 300 s ;
2. Déployez et testez la version Kontainers — accessible immédiatement via kubectl port-forward, puis via votre Ingress avec un sous-domaine de test (beta.example.com) ;
3. Gel des écritures sur le serveur, dernière synchronisation des données ;
4. Basculez le DNS vers la plateforme (Configurer votre DNS) — le certificat s’émet automatiquement dans les minutes qui suivent ;
5. Gardez le serveur allumé quelques jours : le retour arrière est un simple changement DNS inverse.

Ce qui change au quotidien

Avant (serveur)	Après (Kontainers)
ssh serveur	kubectl exec -it deploy/mon-app -- sh
tail -f /var/log/app.log	kubectl logs -f deploy/mon-app
systemctl restart mon-app	kubectl rollout restart deploy/mon-app
certbot + renouvellements	Automatique
Sauvegardes à configurer	Quotidiennes, incluses
Surveillance à installer	Grafana inclus
Mises à jour de l’OS	Plus votre problème