Using ``DEBUG=1`` on binary compose docker launcher prints
pretty-printed docker command launched as well as important
system variables.
Signed-off-by: Valentin Lab <valentin.lab@kalysto.org>
We want to propagate user's current ssh config, and have specially
crafted vars for each os/users.
Signed-off-by: Valentin Lab <valentin.lab@kalysto.org>
We prefer to create a file with the ``/etc/timezone`` information
in our own file directory to be shared read-only with containers.
Signed-off-by: Valentin Lab <valentin.lab@kalysto.org>
This helps charm direct actions to keep a tidy standard output, and allows
them to be used in scripts.
``docker-compose`` was updated to the latest version available (aka
``1.24.0``) and was patched to include what might have been forgotten
when implementing the ``COMPOSE_IGNORE_ORPHANS`` environment variable.
On ``compose`` side, we need to make sure to pass environment variables
that are to be used by ``docker-compose``.
PR: https://github.com/docker/compose/pull/7020
Signed-off-by: Valentin Lab <valentin.lab@kalysto.org>
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.
