Ce message a été modifié 1 fois.
Dernière modification : 9 janvier 2019
à 09:40 par
Guybrush.
GuybrushJe suppose que l'idée de base est de partir sur des rôles (probablement prédéfinis et trouvables sur Ansible Galaxy) pour Redis, pgsql et Gunicorn, et ensuite de voir comment organiser tout ça ?Dans un monde parfait, oui, ton besoin est super standard donc Ansible Galaxy devrait te donner les building blocks pour le faire rapidement.
Guybrushpermettre un déploiement aussi bien dans un environnement de développement qu'en production.Habituellement, je joue avec les groups et subgroups dans l'inventory. Avoir un groupe par environnement permet d'avoir des group_vars dédiées ("production", "dev"), en plus des groupes fonctionnels ("nginxhost", "appcontainer", "dbservers").
Ce message a été modifié 1 fois.
Dernière modification : 9 janvier 2019
à 14:38 par
Fabe.
GuybrushPar contre, c'est pas trivial de faire en sorte que l'application soit utilisable au sein d'un docker en prod (avec les settings qui vont avec), d'un docker en dev (avec les settings qui vont avec) voire même sans dockerC'est à dire ? la philosophie de Docker c'est d'avoir une seule image pour dev et prod, ce qui change devrait être exposé dans les variables d'environnements ou dans un éventuel gestionnaire de secret externe.
make
ou a minima avec les standards de son langage (pip/composer/maven, que sais-je).Fabela philosophie de Docker c'est d'avoir une seule image pour dev et prod, ce qui change devrait être exposé dans les variables d'environnements ou dans un éventuel gestionnaire de secret externe.Je commence seulement à voir les subtilités du
CMD
dans Docker et des possibilités de pouvoir passer des arguments à ce qui va être exécuté dans le conteneur. Mais la "difficulté", c'est qu'il y a une couche intermédiaire (gunicorn) qui doit aussi connaître ces paramètres pour distinguer prod/dev. Mon idée pour l'instant est de faire en sorte que le conteneur fonctionne sur base d'un seul fichier settings, qui sera différent en fonction de l'environnement dans lequel le conteneur va tourner. Le "hic", c'est qu'il y a déjà trois settings différents pour Lexpage (dev, prod et travis), et que je vais devoir "dupliquer" certains settings pour permettre de faire tourner le site en dehors d'un conteneur également (par ex, hors conteneur, c'est sqlite et memcache qui sont utilisés, alors que dans le conteneur ou en prod, c'est pgsql/redis). J'aimerai éviter de dupliquer les settings (y a déjà un "settings_common" qui est inclus dans les deux fichiers de settings existants, mais j'aimerai pouvoir "composer" tout cela un peu plus proprement).SyssonEt ce serait super sympa d'en informer tous les autres gens qui ne font que du docker et pour lesquels tu peux te brosser si tu veux installer à l'ancienne! Et oui installer à l'ancienne pour connaitre le bousin ça a une valeur à minima éducative, faire l'expérience de la stack et tout via un moyen simple : le déploiement!Tout à fait, sans compter que certaines opérations ne sont pas simples à réaliser si l'application tourne dans un conteneur lors du dev (par exemple, je ne sais pas dans quelle mesure nos tests de Django avec Selenium peuvent être lancés dans le conteneur, tout en ayant Selenium qui communique avec le browser en dehors du conteneur. A moins de faire comme avec Travis et de faire tourner ces tests en mode "headless" (mais ça veut dire un dockerfile spécifique pour le dev, du coup, même si c'est pas "fondamentalement" un souci).
1996-2024 — Lexpage v4 — GPLv3 (sources)
page générée le 23 décembre 2024 à 11:10:02