``$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.
