Bonjour à tous,
Je test actuellement Docker avant de le mettre en prod (de la vrai prod et pas sur du dev). Tout est ok mais je bloque sur la partie sauvegarde.
Je sauvegarde les images avec :
docker save [...]
Je les restaures avec :
docker load [...]
Mais voilà c'est uniquement l'image et non le container. Du coups après restauration je n'ai pas les paramètres de lancement du container. Je pourrais repartir du docker file mais si le container a été lancé en ligne de commande et que les paramètres n'ont pas été reportés dans le fichier je ne pourrais pas remettre le container à son état avant restauration.
Avez-vous une idée de comment faire ?
# docker inspect
Posté par lord taki (site web personnel) . Évalué à 1.
docker inspect pour avoir les informations du dit container
[^] # Re: docker inspect
Posté par palm123 (site web personnel) . Évalué à 3.
et les flemmards utiliseront
https://github.com/nexdrew/rekcod
(c'est docker écrit à l'envers) qui automatise la même chose
comme le dit le readme
Reverse engineer a docker run command from an existing container (via docker inspect).
ウィズコロナ
[^] # Re: docker inspect
Posté par Philippe M (site web personnel) . Évalué à 1.
Pas mal ça. Je commençais à me lancer dans le parse de la sortie de inspect.
Je vais tester tout ça, merci.
Born to Kill EndUser !
[^] # Re: docker inspect
Posté par palm123 (site web personnel) . Évalué à 2.
comme la sortie de docker inspect est du JSON, dans ce cas tu aurais pu utiliser jq
https://stedolan.github.io/jq/
ウィズコロナ
[^] # Re: docker inspect
Posté par Philippe M (site web personnel) . Évalué à 2.
Yep je lisais la doc mais avant je vais tester rekcod. Pourquoi re-inventer la roue ;)
Born to Kill EndUser !
# docker compose
Posté par xenom . Évalué à 5.
Effectivement il faut utiliser docker inspect pour avoir les paramètres du container. Mais je me pose surtout la question du besoin.
Il n'y normalement pas d’intérêt à sauvegarder un container, surtout sur de la prod. Le container lui même doit pouvoir être changé et n'a pas de besoin à être sauvegarder.
Pour garder les paramètres du container je conseillerai plutôt d'utiliser docker compose et de sauvegarder ce fichier.
[^] # Re: docker compose
Posté par Marc Quinton . Évalué à 4.
il se trouve qu'il y a des environnements de prod qui n'ont pas un accès direct à Internet ou plus concrètement à une registry Docker. Si si, cela existe réellement, au 21-ième siècle, en particulier pour certains environnements contraints (sécurité).
la solution consiste donc à transférer le container, via un export / import dans un gros paquet et via une clé USB ou transfert de fichiers.
[^] # Re: docker compose
Posté par xenom . Évalué à 6.
Je connais ce problème, j'ai déjà administré des serveurs sans accès à des registry. Mais même dans ce cas, on exporte/importe des images docker, jamais des conteneurs.
[^] # Re: docker compose
Posté par Philippe M (site web personnel) . Évalué à 3. Dernière modification le 12 mars 2018 à 16:10.
Je suis d'accord qu'un container vie, mais imaginons un container lancé en prod il y a 1 an avec des paramètres spécifique (volumes montés, réseaux, port ouvert…). Au début tout ça peut être créé via un dockerfile. 6 mois plus tard je modifie un paramètre du container et tête en l'air que je suis j'oublie de reporter ces modifications dans le dockerfile. 3 mois plus tard… pouff crash. Je remonte l'image
docker load -i monimage
Mince y a quoi déjà qui tourne sur le bouzin, quelle volume est mappé avec cette image, est-ce que le réseau est linké avec un autre docker… Vite le dockerfile… oups il est pas à jour.
Alors qu'avec une sauvegarde du container (enfin des paramètres) 30s tout est repartie.
Born to Kill EndUser !
[^] # Re: docker compose
Posté par xenom . Évalué à 6.
Justement vu l'usage je conseillerai vraiment d'utiliser docker compose.
En prenant l'exemple de la documentation docker:
version: '3'
services:
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/code
links:
- redis
redis:
image: redis
On a un fichier qui défini le binding des ports, les volumes, et le lien vers un autre conteneur, et on peut y mettre toutes les options disponibles de la ligne de commande docker.
Si tu as une modification à faire sur un conteneur existant, tu modifie le fichier docker-compose, et tu lancer "docker-compose up" pour relancer le conteneur avec ces modifications.
En cas de crash pareil et pour déployer ce même service sur un autre serveur il suffit de copier le docker-compose et de démarrer le conteneur. Pas besoin de copier et d'exporter les conteneurs, voir même les images si elles sont disponibles sur un registry.
Ça permet d'avoir toujours les modifications qui ont été faites dans un fichier, et de pouvoir facilement modifier ces options.
[^] # Re: docker compose
Posté par Philippe M (site web personnel) . Évalué à 2. Dernière modification le 12 mars 2018 à 17:00.
Effectivement passer par docker-compose serait pas mal mais vu qu'on est plusieurs à gérer le truc je préfère limiter les accès au serveur. La création / modification se fait par une UI Portainer.
Les images sont basées sur Debian mais adaptées au besoin, j'aime pas trop prendre les images toutes faites et pas trop savoir comment et quoi est installé… Non j'suis pas parano.
Born to Kill EndUser !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.