On Mon, Nov 26, 2018 at 09:53:16AM +0100, Jan Pazdziora via FreeIPA-users wrote:
Another focus of the effort was to make it possible to run the containers as read-only (docker run --read-only), making all the changes that are done during the initial ipa-server-install or during runtime properly confined to the /data volume, or pointed to discardable /tmp. While things pass in my local read-only tests, in Travis CI the initial ipa-server-install phase runs fine but starting the read-only container afterwars seems to hang:
I've resolved all issues that I saw with read-only containers and enabled testing --read-only run containers in .travis.yml.
If you are on Fedora/RHEL/CentOS where oci-systemd-hook package is installed and enabled, the container can be read-only out of box, except if you include DNS in your FreeIPA server container, you need to setup the resolv.conf in the container (likely via --dns option to docker run) as the container will not be able to modify that configuration from within.
If you don't have oci-systemd-hook, you may need to create and bind-mount /etc/machine-id to the container from the host because again, the container will not be able to create that file after it has started. You can check tests/run-master-and-replica.sh for example how it's done in Travis CI.
Running the container read-only means that all the writes that the container does both during initialization (ipa-server-install / ipa-replica-install) and in runtime are now properly routed either to the data volume (mounted to /data) or to temporary volume (tmpfs under /tmp).
In Travis CI, we still run a bunch of build with read-write setup, with followup docker diff checks, to catch potential future situations when new version of packages (FreeIPA or any of the dependent ones) starts to use some new location for its configuration or data. Hopefully that way we'll be notified about such situation early and update the image definition (possibly just volume-data-list or volume-tmp-list).