Bonjour à tous.
J’ai une instance Discourse assez petite qui tourne depuis des années (avec pratiquement zéro problème) : https://discuss.cubeisland.de/.
J’utilise le processus de déploiement standard basé sur le launcher sur une VM dédiée (sur mon propre matériel dans un data center). La seule modification que j’ai apportée au fil des ans a été de migrer vers une base de données PostgreSQL externe partagée.
Récemment, j’ai commencé à migrer des applications depuis des VM dédiées vers un swarm Docker, comme étape préparatoire avant de migrer vers un cluster Kubernetes, principalement pour économiser des ressources et rendre certaines parties de l’infrastructure plus « élastiques ».
Aujourd’hui était le jour où je me suis penché sur cette petite instance Discourse, l’une des rares VM d’application dédiées restantes. « Elle tourne déjà sur Docker, comment cela pourrait-il être difficile de la déployer dans un swarm ? », me suis-je dit. Et d’après ce que j’ai lu, ce serait en effet le cas. Je peux simplement prendre l’image de l’instance actuellement en cours d’exécution, la pousser vers notre registre interne et l’exécuter dans le swarm, et tout fonctionnera parfaitement, ce qui est formidable.
J’ai examiné les fichiers du launcher, en particulier les modèles et les exemples, et j’ai pensé qu’il serait probablement judicieux de séparer Redis dans un tel déploiement, et peut-être que je pourrais configurer un job CI pour construire de nouvelles images lorsque j’ajoute des plugins ou que je souhaite mettre à jour. J’ai donc cloné discourse_docker localement, copié ma définition de conteneur app.yml existante dans le clone et essayé d’exécuter ./launcher bootstrap app pour construire une image que je pourrais ensuite pousser vers mon registre, sans la déployer immédiatement.
À ma grande surprise, le script a tenté de se connecter au serveur PostgreSQL « production » pour migrer la base de données, ce qui, heureusement, n’était pas possible depuis mon poste de travail local.
J’ai regardé autour de moi ici et apparemment c’est ainsi que cela fonctionne, ce qui me fait me demander :
- Comment construire un conteneur pour une nouvelle instance, où je n’ai pas encore de base de données ? Devrais-je configurer la base de données de production avant de pouvoir construire l’image ?
- Je suppose que c’est la seule fois où db:migrate est exécuté, donc si j’ai plusieurs instances similaires (par exemple, prod et test), je devrais mettre à niveau l’une des instances pour construire la nouvelle image, puis je ne pourrais pas utiliser la même image pour la seconde instance, même si l’image serait identique.
- Comment procéder pour construire des images pour des instances où le serveur de base de données n’est pas accessible depuis le système qui construit l’image (ce qui ne devrait pas être si rare).
Après avoir lu plusieurs publications (évidemment y compris celle-ci), je suis parfaitement conscient des raisons du processus de construction tel qu’il est actuellement et je vois la valeur de celui-ci pour les 99 % de personnes qui déploient Discourse de manière occasionnelle sur leur VM standard complète. Et je suis très habitué aux modèles de conteneurs « tout-en-un » et je ne m’y oppose pas. Après tout, la valeur clé de Docker réside dans le fait que le fournisseur de logiciels peut pré-configurer des configurations hautement optimisées et les regrouper dans un environnement d’exécution reproductible, éliminant ainsi le besoin de nombreuses connaissances très spécifiques à l’application du côté des opérations. Je suis donc tout à fait partant pour utiliser vos outils fournis ; pourquoi m’attendrais-je à ce que quelqu’un d’autre construise de meilleurs conteneurs que le fournisseur de logiciels lui-même ? Pourquoi voudrais-je séparer nginx et l’application Ruby, alors qu’il n’y a aucun avantage à en tirer, juste pour rendre le déploiement plus « pur » (quoi que cela signifie…) ?
Cependant, il est étrange de voir un conteneur qui modifie l’état d’exécution alors qu’il n’est même pas en cours d’exécution. J’exécute déjà pas mal d’applications dans des conteneurs et j’en ai moi-même conteneurisé plusieurs, dont certaines n’étaient pas destinées à fonctionner dans des conteneurs.
L’exemple principal qui me vient à l’esprit, d’une application qui traite des exigences/problèmes similaires de manière similaire à Discourse, est Gitlab. Bien qu’ils fournissent désormais un charmant graphique Helm pour un déploiement Kubernetes pleinement décomposé « tel que cela devrait être », je suppose (sans regarder les chiffres) qu’une proportion similaire de 99 % de ses déploiements de taille petite à moyenne utilisent l’image Docker omnibus de Gitlab (ou le paquet OS, qui est pratiquement la même chose). Ils ont un processus de démarrage similaire, mais basé sur Chef à l’intérieur du conteneur, qui est tout exécuté à chaque démarrage et effectue les tâches habituelles comme les migrations de base de données et la compilation des assets.
Oui, le démarrage de Gitlab peut prendre plusieurs minutes à cause de cela, mais cela n’a jamais été un problème pour les déploiements que j’ai vus (certains dans de grandes entreprises). Surtout avec les systèmes d’orchestration modernes comme Docker Swarm et Kubernetes, etc., qui peuvent exécuter des mises à jour en roulement pour vous, où l’ancienne instance n’est éteinte que si la nouvelle instance est en cours d’exécution et a passé avec succès les vérifications de santé et de disponibilité, un processus de déploiement long pourrait en réalité ne pas être un problème. Mais même sans mises à jour en roulement sophistiquées, qui peuvent ou non fonctionner, vous pouvez aussi vous en sortir avec pas mal de temps d’arrêt dans de nombreuses situations.
Donc : est-il possible de configurer le launcher pour sauter les opérations dépendantes de la base de données pendant la construction de l’image et effectuer ces opérations au démarrage du conteneur à la place ?
Je suis certainement prêt à investir un peu de temps moi-même, mais mon temps le soir est limité, donc toute indication serait la bienvenue.
Je suis également ouvert à des processus complètement différents si vous pensez que c’est stupide ou même pas possible, etc.
Merci pour tout retour d’information !