How to edit code in a Docker container in developm

Question

I have all my websites' code under /srv in my containers.

My Dockerfile downloads the code using git and makes it part of the image for easier deployment to production.

But then how do I edit the code in development? I thought using volumes was the solution, eg: -v /docker/mycontainer/srv:/srv. But it overwrites the directory in the container. If it's the first time I run it it empties it because there's nothing in the host. So whatever I did in the Dockerfile was gets lost.

There are also directories and files inside /srv/myapp that I want to be shared across the different versions of my app, eg: /srv/myapp/user-uploads. This is a common practice in professional web development.

So what can I do to be able to do all these things?:

• edit code in /srv in development
• share /srv/myapp/user-uploads across different versions
• let Dockerfile download the code. Doing "git clone" or "git pull" outside of Docker would defeat Docker's purpose in my opinion. Besides there are things that I can't run in the host, like the database migrations or other app-specific scripts.

Is there a way to do a reverse volume mount? I mean make the container overwrite the host, instead of the opposite.

I'm thinking one soluiton might be to copy /srv to /srv.deployment-copy before running the container's daemon. And then when I run the daemon check if /srv.deployment-copy exists and copy everything back to /srv. This way I can use /srv as a volume and still be able to deploy code to it with the Dockerfile. I'm already using aliases for all the docker commands so automating this won't be a problem. What do you think?

Answer 1

Note: you cannot mount container directory to host directory with -v.

I don't think that you need to mangle /srv and /srv.deployment-copy. If you

I think that:

• You should use volume for persistent/shared data: -v /hostdir/user-uploads:/srv/myapp/user-uploads, or you can use data volume container concept. You can consider this a filesystem backed database that is stored at host (data only container) and container is allowed to use it by -v.

• You are correct: for production deployment - you can build the image with source code (git clone), you build an image for every release. There should be no need to edit the source code in production.

• for development environment - you should build the image without source code or you can shadow the source code directory with volume in case of using the same image for deployment/development. Then git clone source code locally and do use volume -v /hostdir/project/src:/srv/project to share source code with container. Preferably you should share the source code read-only (:ro at the end) and any temporary or intermediate files should be stored somewhere else in the container. I have setup scripts (data migration, rebuild some index/cache data files etc.) executed at the container start, before service start. So whenever I feels I need fresh re-init, I just kill the dev container and run it again. Or, I do not stop the old container - I just run another one.

Answer 2

I found a nice way of doing this using just git:

CONTAINER=my_container
SYNC_REPO=/tmp/my.git
CODE=/var/www

#create bare repo in container
docker exec $CONTAINER git init --bare $SYNC_REPO

#add executable syncing hook that checks out into code dir in container
printf "#!/bin/sh\nGIT_WORK_TREE=$CODE git checkout -f\n" | \
docker exec -i $CONTAINER bash -c "tee $SYNC_REPO/hooks/post-receive;chmod +x \$_"

#use git-remote-helper to use docker exec instead of ssh for git
git remote add docker "ext::docker exec -i $CONTAINER sh -c %S% $SYNC_REPO"

#push updated local code into docker
git push docker master

Assumes you have a local git with the code. Git needs to be installed in container. Alternatively you could probably use docker run and a data container with a shared volume with git installed.

Answer 3

I found the best way to edit code in development is install everything as usual (including cloning your app's repository), but move all the code in the container to say /srv/myapp.deploy.dev. Then start the container with a rw volume for /srv/myapp, and a init.d script that cleans that volume and copies the new contents inside like this:

rm -r /srv/myapp/*
rm -r /srv/myapp/.[!.]*
cp -r /srv/myapp.deploy.dev/. /srv/myapp
rm -r /srv/myapp.deploy.dev

Answer 4

Assuming git is not the entrypoint of the container, if git is installed in your docker container you can ssh into the container and run the git clone/git pull. Because of the way the volume is shared with the host, changes made from the container to the files will be made to the host as well (really it's the same files).

Here is some explanation of how to quickly ssh into a container.

Answer 5

There is another way to start container with volume from another container:

Look at https://docs.docker.com/userguide/dockervolumes/
Creating and mounting a Data Volume Container

If you have some persistent data that you want to share between containers, or want to use from non-persistent containers, it's best to create a named Data Volume Container, and then to mount the data from it.

Let's create a new named container with a volume to share.

$ sudo docker run -d -v /dbdata --name dbdata training/postgres echo Data-only container for postgres

You can then use the --volumes-from flag to mount the /dbdata volume in another container.

$ sudo docker run -d --volumes-from dbdata --name db1 training/postgres

And another:

$ sudo docker run -d --volumes-from dbdata --name db2 training/postgres

Another useful function we can perform with volumes is use them for backups, restores or migrations. We do this by using the --volumes-from flag to create a new container that mounts that volume, like so:

$ sudo docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata

=============

I think you should not use mounting of your host directory to a container. But you can use volumes with all its powers. You can edit files in volumes using other containers with perfect set of your editors and tools. And container this your app will be clean without overhead.

Structure is:
-) Container for app data
docker run -d -v /data --name data
-) Container for app binaries
docker run -d --volumes-from data --name app1
-) Container for editors and utilities for development
docker run -d --volumes-from data --name editor