skip to Main Content

I’m currently trying to deploy a PHP app via Docker. The stack is Caddy -> PHP-FPM, and I’m using a separate container for each component.

Due to the way those components function, both the Caddy and php-fpm containers need to see the application code. (In theory I could present only the PHP files to php-fpm and only the static files to Caddy, but this is too much of a pain.) Thus, I mount a volume with the app code, and put it on both containers.

This works fine, so long as the volume does not exist at build time. However, if the volume already exists, then the data on that volume is used, and the new version of the app doesn’t get copied into it. The only way I’ve found to make it work is to manually docker volume rm the volume every time I build, which is a pain, and doesn’t seem like the right way to do things.

How can I automatically overwrite the existing volume contents at build time? Alternatively, how can I share the code between the two containers without a volume? Apparently tmpfs mounts can’t be shared, so that’s no good.

2

Answers


  1. how can I share the code between the two containers without a volume?

    Build both your own Caddy and php-fpm containers with your code included from two Dockerfiles as part of automatic CI/CD deployment from the repository storing your code as part of your CI/CD pipeline. Both containers would have the same :tag associated with the same code version, like :tag equal to git commit messages or build timestamp. Then, deploy the two containers together with the same docker tag.

    How can I automatically overwrite the existing volume contents at build time?

    Volumes do not exist at build time. When running your application you can start a third container that includes your code with basic shell utilities (busybox) and starts before the other two. This container only copies the code into the shared storage and exits. Typically, such "app-init" containers are run as part of docker-compose deployment and other containers wait for successful termination of them. See for example airflow docker-compose that initialized the airflow database before running other airflow components.

    Login or Signup to reply.
  2. As mentioned in this docker-compose-issue you may try docker-compose down -v -f before the up command which should delete volumes created during the up-process.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search