search

ucphhpc / docker-migrid

Containerized MiG
GNU General Public License v2.0
3 stars 7 forks source link

Take out volume mount for mig/ directory in production #41

Open benibr opened 6 months ago

benibr commented 6 months ago

As already discussed earlier I'd like to suggest, that we remove the volume mount for the mig/ application folder from the production compose file.

The current situation is: during first start the migrid Docker container populates the mig/ directory with the version of the application that is built into the container. If the container is rebuilt with a newer version and the whole setup is started, the mig/ folder inside the container get overmounted by the already existing volume. Thus we end up with a running Docker container tagged as a newer version which effectively runs the old version.

This is accepable behavior for a development environment where a user wants to change the application on-the-fly and see the results.

For a production environment a user should be able to see the running version by looking at the image tag of the containers.

Current solutions to avoid the version mismatch are: running make clean or even running make distclean and redeploy everything. Both are meant to be used manual and cause downtime. The latter is also very slow.

Without the mig/ volume it would be possible to rebuild the container with a new version, then just rerun telling docker-compose to recreate the container. This is fast and intuitive and does not need extra steps in the automation (eg. Ansible).

So my suggestions is to remove the mig volume from all containers in the production template docker-compose file:

    volumes:
...
      - type: volume
        source: mig
        target: /home/mig/mig

Any thoughts and suggestions appreciated.

benibr commented 6 months ago

One addition:

The checked out version should maybe be visible in the mig/ directory, not just inside the home directory in the container

https://github.com/ucphhpc/docker-migrid/blob/master/Dockerfile.rocky8#L772

jonasbardino commented 4 months ago

Sorry for the slow response - vacation and other tasks kept me busy :-/

I'm not sure I have the full overview of the consequences of the proposed modification, but am not generally averse to the idea. Currently I usually end up using complete docker clean on dev and test sites because of various docker/podman caching issues, possibly including the mentioned one.

One possible problem is the fact that both the mig and httpd dirs/volumes contain generated configuration files implicitly bound to a specific migrid version. That is, I guess we can potentially run into similar issues with the httpd volume being out of sync with the running migrid version.

benibr commented 4 months ago

So maybe we should not only remove the mig volume but also the httpd volume in production?

jonasbardino commented 4 months ago

Well, at least that's what I suppose we might end up having to do if so. I'm just not sure if this will drag us down the way to restructuring everything to use a separate configuration volume setup or something, as we discussed previously here but put on hold for various reasons. If anybody can find time to look into the matter it would be welcome of course.