> The problem was that I wanted to add files to the /webapp directory, but
> once the Dockerfile defines it as volume you can't modify it as part of
> the container definition, you can only mount to it from outside.
> 
> My general approach is to have two images, one without the volumes, for
> use in defining derived containers, and a working image that defines the
> volumes so they are ready for mounting from other containers or from the
> host.
> 
> I suppose another way to handle it is to not define the volumes at all and
> then do it in Docker-compose scripts (I'm using docker-compose to manage
> all my related containers and provide a convenient way to  manage
> everything through one command).

The way it meant to be is usually adding logic/program code to derived
images, and putting data/information into volumes. How those are managed
depends on personal needs, preferences and the available infrastructure.

THis way you can "throw away" containers at any time, they don't have
any state left any more. To publish a new version, you simply start a
new container from the updated image accessing the data, but don't have
to pass any application logic into the container.

Relying on docker-compose is a good thing to do, it also easons up
migrating to a Docker swarm or other infrastructure management tools.

-- 
Jens Erat
Universität Konstanz
Kommunikations-, Infomations-, Medienzentrum (KIM)
Abteilung Basisdienste
D-78457 Konstanz
Mail: jens.e...@uni-konstanz.de

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to