``DB_PASSFILE`` is split into ``HOST_DB_PASSFILE`` and ``CLIENT_DB_PASSFILE`` to allow
to use a ``HOST_DB_PASSFILE`` in a directory that is accessible to ``compose`` even when
run in docker mode.
Using this, we can store HOST_DB_PASSFILE along with the database files,
which makes a lot more sense as it resolv issues of synchronising the
database with the content of this file (namely, the authorization
scheme). So when restoring the datastore of the database, the charm
scripts will be able to use the db password file and will not have to
worry about if it is in sync with the files or not.
Note that ``db_docker_opts`` and ``db_cmd_opts`` are now bash arrays. As
previous implementation was brittle, especially for handling spaces in
arguments.
``$DEFAULT_BASH_IMAGE`` would not be set (because not exported) and as consequence
the ``docker run`` would fail with an errorlevel different from 1. The failure
condition was bogus here, and we should not rely on ``$DEFAULT_BASH_IMAGE`` to be
exported. Both have been corrected.
The ``docker-compose.yml`` is saved along with an executable ``dc`` and
``.env`` in a directory to be shared as a volume in case we'd like to
launch a subservice in the same setup from a launched service. For instance,
a ``cron`` charm could want to launch ``run-once`` services.
The charm only need to access the ``dc`` binary, this can be done by
sharing the binary as a volume. This is the recommended way to do this:
``\${DOCKER_COMPOSE_PATH}/bin/dc:/bin/dc:ro``. Notice how we use a
docker-compose level variable here as the DOCKER_COMPOSE_PATH will only
be computed after all ``init`` hooks are done. This is the purpose of
the ``.env`` file that is also generated.
These directories are garbage collected if no containers have volumes
connected to it.
An empty definition is useful if you need the service to be selected as a
default service when using ``compose up`` with no argument, and you don't
have anything to configure in the given service.
We force ``--remove-orphans`` as it'll remove all the previous
dockers that have been launched in the same project. We don't
need to compute anything for this.
``charm`` is the general recipes. ``service`` is a practical
functionality that will (if not subordinated) spawn a docker container.
In your compose file, you define services that will apply some general
rules borrowed from ``charm``s. Different services can link to the same
charm.
Indeed as the database container might already be launched on another
network before any script is launched. We can use this instance with
this modification.
