Loading Compose Files
For use-cases where you have a compose-file, and want some of the compose.mk
features, but you don't have a project Makefile, you can skip the usual integration by letting loadf
generate integration for you just in time.
General usage looks like this:
$ ./compose.mk loadf <path_to_compose_file> <other_instructions>
Basic Usage
If no additional downstream targets are passed, the default behaviour is to open a shell for each tool container using the TUI. Here's what it looks like:
See instead the selector docs for interactively selecting a container instead of opening all of them.
Arbitrary Downstream Targets
Using loadf
effectively runs compose.import
for you so that afterwards you can use any of the other targets documented as part of the bridge or the static targets.
This means that loadf
doesn't really need to involve the TUI at all. The example below is using the <svc_name>.get_shell
target:
Note that despite all the output this is pipe-safe, in case the commands involved might return JSON for downstream parsing, etc.
As another example, you can use the <svc_name>.pipe
target to push data into a container with a command like this:
$ echo hostname | ./compose.mk loadf \
demos/data/docker-compose.yml debian.shell.pipe
debian
Ultimately though, using the TUI for quick and convenient inspection is probably the main use case. Here's a few more examples along those lines:
# Opens 3 panes with container-shells
$ ./compose.mk loadf demos/data/docker-compose.yml \
tux.open.service_shells/debian,alpine,debian
# Equivalently, using lower-level generic targets
$ ./compose.mk loadf demos/data/docker-compose.yml \
tux.open/debian.shell,alpine.shell,debian.shell
# Opens 2 panes of bash-shells for the TUI container itself
$ ./compose.mk loadf demos/data/docker-compose.yml \
tux.open/io.shell,io.shell
Related Links
The Embedded TUI documentation has other examples that are using loadf
, discussion of default pane layouts, etc.
For more details about available targets, see the bridge documentation.