J’ai lu des sujets comme celui-ci et d’autres, et il semble qu’à ce jour, il n’existe aucun moyen simple de déployer une image Discourse dans un service comme ECS, GKE ou tout autre orchestrateur de conteneurs de votre choix, tout en garantissant un fonctionnement fluide…
J’utilise Terraform pour gérer un cluster Elasticache, une instance RDS et un cluster ECS. Je souhaite simplement pouvoir indiquer : « Voici mon image Discourse, et voici les variables d’environnement pour me connecter à Postgres, Redis, SMTP, etc. »
Quelque chose de similaire existe-t-il en 2020 ? Il semble que, lors de toutes les discussions précédentes sur ce sujet, aucune solution satisfaisante n’ait été trouvée, et nous sommes toujours contraints d’utiliser les scripts personnalisés de Discourse, qui contredisent les conventions des conteneurs et compromettent la compatibilité avec la manière idiomatique dont les gens utilisent les conteneurs…
C’est une hypothèse incorrecte. Tous ces éléments font partie de Discourse et doivent être contrôlés par Discourse dans son conteneur pour garantir une configuration réussie.
Si vous vous lancez dans des scénarios complexes avec plusieurs conteneurs, cela n’est nécessaire que pour les grands clients disposant de budgets importants. Dans ce cas, je vous recommande notre service d’hébergement entreprise.
Pourquoi cela nécessite-t-il ce script d’amorçage étrange qui lance des conteneurs et agit comme un orchestrateur ?
Pourquoi l’image Discourse ne pourrait-elle pas accepter des variables d’environnement et, dans son point d’entrée, contacter toutes ces ressources pour créer les tables dont elle a besoin, etc. ? D’autres services ou applications web dépendant de couches de persistance externes ont été correctement conteneurisés de cette manière. Il suffit de les placer dans un ECS, un EKS ou autre, de leur indiquer où trouver la base de données, etc., et tout fonctionne parfaitement. Est-ce possible avec Discourse ?
C’est précisément parce que nous sommes l’inverse — une organisation à but non lucratif sans budget énorme — que nous souhaitons maintenir les coûts aussi bas que possible en regroupant toutes nos applications d’entreprise sur un seul hôte AWS ECS. Cela nécessite cependant que les applications individuelles soient correctement conteneurisées et puissent être définies comme des définitions de tâches ECS, c’est-à-dire des images Docker autonomes.
Eh bien, en quelque sorte — étant donné que Discourse s’intègre facilement dans un VPS à 5 $/mois via une image Docker unique et simple, je ne suis pas sûr que l’économie de quelques centimes sur ce montant — avec une augmentation massive de la difficulté d’installation et de la complexité de maintenance continue — vaille vraiment la peine ? Restez simple !
Comme le décrit le lien ci-dessus, vous pouvez créer des conteneurs et les lancer avec Kubernetes. J’ai réalisé des déploiements GKE pour certains clients qui y tenaient car ils étaient liés à la plateforme.
Si votre objectif est d’économiser de l’argent, un abonnement de 5 à 10 $ par mois est la meilleure option.
Nos outils sont optimisés pour l’utilisateur le plus courant de loin : les petits groupes sans équipe informatique spécialisée pour gérer l’orchestration de conteneurs.
Les éléments nécessaires sont toutefois disponibles si vous souhaitez passer au mode « Cloud complet ». Le dépôt source à consulter est :
Le fichier samples/web_only.yml qui s’y trouve montre comment utiliser des ressources externes.
Le script launcher est également capable de construire une image Docker personnalisée avec la sous-commande bootstrap.