Fig a été déprécié et il a été remplacé par docker-compose. Mais pour le moment, c'est le même code.
Il y a pas mal de changement dans l’écosystème docker en ce moment et ça peut être vite troublant :)
Je n'ai pas encore testé swarm.
il y a la méthode lvs/keealived qui pourrait marcher.
De plus avec fig, on peut dynamiquement changer le nombre container d'un service.
J'ai fais ça pour le fun et mieux comprendre la technologie
Pour une archi perso, ça apporte peu de chose au quotidien:
- la facilité de migration.
- la non-adhérence au système: tu peux déployer une infra en une ligne de commande et la supprimer en une autre
- pour tester des services (exemple: owncloud 8, tu récupères le dockerfile qui va bien, c'est opérationnel tout de suite et quand tu veux arrêter: tu supprimes le container et tu n'as pas de dépendance qui reste installée
si le paquet apache est mis à jour dans les dépots,
il faudra reconstruire l'image docker:
L'avantage de docker permet de séparer les programmes (apache) et les données.
il est facilement possible de supprimer le container et de le ré-instancier dans la version mise à jour sans avoir à toucher aux données.
exemple:
#reconstruire l'image docker:
docker build -t alban-garrigue-apache ./
#supprimer le container:
fig stop webalban
fig rm webalban
#puis le reinstancier
fig up
nous voila avec un apache tout neuf.
Si l'image est instanciée X fois, il faudra faire cette manipulation X fois ou utiliser un outil pour industrialiser le tout sur des architectures plus grande.
Grâce à la portabilité des images, on peut tester en local, s'assurer que tout fonctionne bien et pousser tout ça en prod sans trop de problème avec une interruption de service minime.
# Mission accomplie
Posté par albang . En réponse à la dépêche Boohu : version 0.9, tuiles et génération de cartes. Évalué à 2.
Le jeu est super chouette quoiqu'un peu frustrant, j'ai pas encore réussi à arriver au niveau où on peut avoir de l'or! Merci pour cette découverte!
[^] # Re: Compose
Posté par albang . En réponse au journal Migration d'une infra lamp vers docker. Évalué à 1.
Fig a été déprécié et il a été remplacé par docker-compose. Mais pour le moment, c'est le même code.
Il y a pas mal de changement dans l’écosystème docker en ce moment et ça peut être vite troublant :)
[^] # Re: Par rapport à LXC
Posté par albang . En réponse au journal Migration d'une infra lamp vers docker. Évalué à 1.
Je n'ai pas encore testé swarm.
il y a la méthode lvs/keealived qui pourrait marcher.
De plus avec fig, on peut dynamiquement changer le nombre container d'un service.
[^] # Re: A quoi ça sert ?
Posté par albang . En réponse au journal Migration d'une infra lamp vers docker. Évalué à 5.
J'ai fais ça pour le fun et mieux comprendre la technologie
Pour une archi perso, ça apporte peu de chose au quotidien:
- la facilité de migration.
- la non-adhérence au système: tu peux déployer une infra en une ligne de commande et la supprimer en une autre
- pour tester des services (exemple: owncloud 8, tu récupères le dockerfile qui va bien, c'est opérationnel tout de suite et quand tu veux arrêter: tu supprimes le container et tu n'as pas de dépendance qui reste installée
[^] # Re: Intéressant
Posté par albang . En réponse au journal Migration d'une infra lamp vers docker. Évalué à 1.
ceci est bien un trop rapide copier coller, par contre je n'ai pas trouvé comment éditer un journal
[^] # Re: Mise à jour
Posté par albang . En réponse au journal Migration d'une infra lamp vers docker. Évalué à 3.
si le paquet apache est mis à jour dans les dépots,
il faudra reconstruire l'image docker:
L'avantage de docker permet de séparer les programmes (apache) et les données.
il est facilement possible de supprimer le container et de le ré-instancier dans la version mise à jour sans avoir à toucher aux données.
exemple:
nous voila avec un apache tout neuf.
Si l'image est instanciée X fois, il faudra faire cette manipulation X fois ou utiliser un outil pour industrialiser le tout sur des architectures plus grande.
Grâce à la portabilité des images, on peut tester en local, s'assurer que tout fonctionne bien et pousser tout ça en prod sans trop de problème avec une interruption de service minime.