11

I'm confused about common consensus that one shouldn't use data containers. I have specific use case that I want to accomplish.

I want to have docker nginx container and behind it some other container with application. To run newest version of my app I want to download ready container from my private docker registry. The application is for now purely static html, javascript something.

So my plan is to create docker image which will hold the files, and will specify a named volume in some /webapp folder. The nginx container will serve this volume. I do not see any other way how to move bunch of files to remote system the "docker containerized" way. Am I not actually creating cursed data container?

Anyway what happens during app containers exchange? When I stop the app container the volume remains accesible, as it is placed on host. When I pull and start new version of app container. The volume will be created again and prefiled with image files stored at the same location, replacing the content on host so the nginx container will server from now new version of the application.Right? What happens when I will reference volume that does not exist yet from the nginx container.

It seem that named values are not automatically filed with the content of the image. As well I'm not sure how to create named volume in docker file as this syntax taken from here doesn't work 

FROM training/webapp

VOLUME webapp:/webapp
Zveratko
  • 2,663
  • 6
  • 35
  • 64
  • Instead of going with a named container, you should simple create a new image based upon the NGINX image. It is slightly less efforts in this case then a volume container. – KarateKid Jan 16 '17 at 17:22
  • But in my case I need one nginx as gateway there will by muliple application behind and probably also some other technologies than static pages. I think that running multiple nginx instances will be unnecessary performance overhead. – Zveratko Jan 17 '17 at 07:30

1 Answers1

4

I think you might want what i have described here https://stackoverflow.com/a/41576040/3625317

The problem with volumes is, that when a container is recreated, not docker-compose down but rather docker-compose pull + up, the new container will not have your "new code stored in the volume" but rather, due to the recycled volume, still the old anon volume. The point is, you will need a anon-volume for the code anyway, since you want it redeployable, not a named volume since you want the code to be exchangeable.

On re-create the anon-volume is not removed, that said, lets say you have the image:v1 right now and you pull image:v2 and then do a docker-compose up. It will recreate your container based on image:v2 - when this finished, you will have a new container, but the code is still from the old container, which was based on image:v1, since the anon-volume has not been replaced, it was re-assigned. docker-compose down && docker-compose up will resolve that for you - but you have to keep this in mind when dealing with your idea. (down removes anon-volumes)

In general, there is a pro / con, see my other post.

Data-containers in general have a other meaning and have been replaced by so called named volumes. Data-containers have been used to establish a volume-mount which is "named" and not based on a anon-volume.

In the past, you had to create a container with a volume, and later use a container-name based mount of this volume ( the container would be the static / name part ), today, you just create a named volume name and mount by this volume-name, no need for a busybox killed after start based container-name based volume mount.

Wilfred Hughes
  • 29,846
  • 15
  • 139
  • 192
Eugen Mayer
  • 8,942
  • 4
  • 33
  • 57
  • The concept is to use named volume to overcome the issue of new anonymous volume on every "deploy". Do you know what can be wrong with the named volume creation in the docker file? If it will work I can have some code to fill it automaticaly on start with the files of the app. Maybe the possible way is to create named volume manualy use it as read only from nginx container and replace its content with every webapp container start. – Zveratko Jan 11 '17 at 08:22
  • named volumes do not suite in any way with storing your app code on those, since this will become "undeployable" and should be wrong for all apps. So named volumes are a nogo for a app-containers app-code folder. That said, what you said in the latter will work, but still flanks really every aspect of docker and shall never be done ( but can be done ) – Eugen Mayer Jan 11 '17 at 10:35
  • So is there any other way how to share content of my app container? How is it usually done when one don't want to have bundled app server with app binaries? Are the binaries managed manually outside of docker containers?(i.e. copy them to some volume or directly to some container etc.) – Zveratko Jan 11 '17 at 10:45