Ce message a été modifié 2 fois.
Dernière modification : 11 février 2015
à 11:47 par
Guybrush.
GuybrushEt aussi, est-ce qu'il est préférable de :Fais un Dockerfile, c'est toujours plus simple de maintenir et partager un script qu'une image. De plus, en clonant le projet, tout est à disposition pour créér et instancier l'image, pas besoin d'indiquer un registry à toi si ton image n'est pas sur le central ou de la partager autrement.
- Charger une image, et dans le container, faire la configuration puis sauver tout ça sous forme d'image (en gros, ça devient mon "environnement" que je peux cloner) ou;
- Créer un Dockerfile sur base d'une image existante et scripter la configuration là-dedans, afin d'avoir le "minimum" de modifications dans l'image de base ?
GuybrushDéfinitivement, créér un volume avec le FS de l'hôte. Un conteneur est volatile par définition.
En gros, est-ce qu'il parait concevable (et prudent ?) que les données persistées le soient "uniquement dans l'image", ou alors il vaut mieux binder ça avec le FS de l'hôte ?
Ce message a été modifié 1 fois.
Dernière modification : 11 février 2015
à 14:59 par
Guybrush.
pomDans notre jargon chez nous, on parle de nœuds applicatifs. Une instance de tomcat, c'est un NA. Un apache, c'est un NA. Une base de donnée Oracle, aussi. Mais attention au piège, 2 webapps sur une même instance de tomcat ne font qu'un NA. Pour un apache avec PHP (ou python), ça ne fait qu'un nœud aussi. J'imagine qu'un répartiteur de charge serait aussi un NA à part entière. Et ce sont ces nœuds qui me semblent être désignés pour être des containers docker.Ok. Je suppose que l'argument clé pour séparer tout ça, c'est le fait que seule une commande peut être "démonisée" dans le container pour que ce dernier soit maintenu. Par contre, j'ai encore du mal à voir si Docker doit être utilisé plutôt pour "virtualiser" l'environnement, tout en récupérant certaines "configurations par défaut" via les images disponibles publiquement, ou si l'usage est plutôt de pousser l'autre extrême, et de configurer un container de façon tellement spécifique qu'il n'y a pratiquement plus qu'à "cliquer sur un bouton" (on se comprend) pour que l'application contenue soit lancée. En fait, j'ai du mal à identifier quels sont les "paramètres" (dans le sens configuration) qu'il vaut mieux enregistrer dans son container, ou passer lors du lancement du container.
pomEnsuite, les containers de data c'est pour rendre les données persistantes, ce n'est pas pour le code (le code n'a pas besoin d'être persisté puisqu'il est censé être sous contrôle de source). Le code (ou les ressources statiques) ça devrait être dans des volumes que tu donnes en paramètres à ton container et pointant vers un répertoire physique de la machine hôte. Pour mon container tomcat, je vois bien lui mettre en paramètre le répertoire target de mon projet eclipse (qui construit via Maven un war).Ok, je pense avoir bien compris
Ce message a été modifié 3 fois.
Dernière modification : 11 février 2015
à 23:54 par
pom.
1996-2024 — Lexpage v4 — GPLv3 (sources)
page générée le 23 décembre 2024 à 01:40:29