2017-10-05 46 views
0

J'utilise le conteneur solr 6.6 officiel utilisé dans un environnement docker-composer sans aucun volume pertinent. Si je modifie un conteneur solr en cours d'exécution, les données survivent à un redémarrage. Je ne vois pas tous les volumes montés et il fonctionne pour un conteneur Solr simple:Docker: Comment un conteneur conserve-t-il des données sans volumes dans le conteneur?

docker run --name solr_test -d -p 8983:8983 -t library/solr:6.6 
docker exec -it solr_test /bin/bash -c 'echo woot > /opt/solr/server/solr/testfile' 
docker stop solr_test 
docker start solr_test 
docker exec -it solr_test cat /opt/solr/server/solr/testfile 

exemple ci-dessus de la woot 'impressions. Je pensais qu'un conteneur ne conserve aucune donnée? Le documentation mentionne également que les noyaux de solr persistent dans le conteneur. Tout ce que j'ai trouvé, concernant la persistance des conteneurs, c'est que j'ai besoin d'ajouter des volumes par moi-même comme mentionné here. Donc, je suis confus: les conteneurs stockent-ils les données modifiées dans le conteneur ou non? Et comment le conteneur de solr achève-t-il ce comportement? La seule option que je vois est que j'ai mal compris la pérennité dans le cas de docker ou la construction du conteneur peut définir une sorte d'option pour réaliser ceci que je ne sais pas et n'ai pas vu dans le Dockerfile de solr.

+0

Pourrais-je vous aider avec la réponse? –

+0

yep - beaucoup de thx, je n'ai jamais utilisé le docker commit mais je savais qu'il existait et je pensais principalement aux conteneurs comme environnement jetable pour une application –

Répondre

2

Ceci est un comportement attendu. Les données que vous créez dans un conteneur sont conservées tant que vous ne supprimez pas le conteneur.

Mais pensez conteneurs d'une certaine manière de jeter la mentalité. Normalement, vous voudriez pouvoir supprimer le conteneur avec docker rm et générer une nouvelle instance incluant vos fichiers de configuration modifiés. C'est pourquoi vous auriez besoin d'un e.g. volume nommé ici, qui survit à un cycle de vie de conteneur sur votre hôte.

Le Dockerfile, parce que vous le mentionnez dans votre question, ne définit réellement que l'image. Lorsque vous appelez le docker run, vous créez un conteneur à partir de celui-ci. Exactement comme défini dans l'image. Une nouvelle instance sans aucune modification. Lorsque vous appelez docker commit sur votre conteneur, vous l'installez (y compris les modifications que vous avez apportées aux fichiers) et vous en créez une nouvelle image. Ils atteignent la persistance des données de cette façon. La documentation à laquelle vous faites référence explique cela en détail.

+1

bonne réponse. il y a à ajouter, que exec exécute une commande sur un conatainer _running_ seulement. Un démarrage n'est pas une suppression, c'est une "pause" si vous voulez, ainsi toutes les données sont toujours valides et le conteneur n'est pas supprimé. Lorsque vous appelez start, le même conteneur est repris - ce n'est pas un nouveau conteneur créé. Start ne peut être appelé que sur un conteneur déjà créé, et non sur une image. En effet, il ne crée jamais d'image, ce qui est le but de l'exécution. Il crée un nouveau conteneur à partir d'une image. Donc, start/stop/exec sont pour les conteneurs existants (créés), run en crée un nouveau. –

+0

peut-être une autre question que je n'ai pas trouvé de réponse dans une recherche courte: existe-t-il une option pour docker composer ou docker start qui force un conteneur à partir de l'image au démarrage - je sais que je pourrais retirer le conteneur exiger des connaissances supplémentaires sur la manipulation des fichiers de composition. Je pense à certaines applications apache/php qui pourraient utiliser un cache de fichier dont je m'attendrais à être vide à (re) démarrer à titre d'exemple. –

+0

regarder dans le système docker élague pour la suppression des réseaux, des volumes et des images et docker up --build pour reconstruire à partir de votre Dockerfile –