Package: paunch
Utility to launch and manage containers using YAML based configuration dataFree software: Apache licenseDocumentation:https://docs.openstack.org/developer/paunchSource:https://opendev.org/openstack/paunchBugs:https://bugs.launchpad.net/paunchRelease Notes:https://docs.openstack.org/releasenotes/paunchFeaturesSingle host only, operations are performed via the podman client.Zero external state, only labels on running containers are used when
determining which containers an operation will perform on.Single threaded and blocking, containers which are not configured to detach
will halt further configuration until they exit.Co-exists with other container configuration tools. Only containers created
by paunch will be modified by paunch. Unique container names are assigned if
the desired name is taken, and containers are renamed when the desired name
becomes available.Accessable via thepaunchcommand line utility, or by importing python
packagepaunch.Builtindebugcommand lets you see how individual containers are run,
get configuration information for them, and run them any way you need to.Running Paunch CommandsThe only state that paunch is aware of is the labels that it sets on running
containers, so it is up to the user to keep track of what paunch configsshouldbe running so that others can be deleted on cleanup. For these
examples we’re going to store that state in a simple text file:$ touch paunch-state.txtWe’ll start of by deleting any containers that were started by previous calls
topaunch apply:$ paunch --verbose cleanup $(cat paunch-state.txt)Next we’ll apply a simple hello-world config found inexamples/hello-world.ymlwhich contains the following:hello:
  image: hello-world
  detach: falseApplied by running:$ paunch --verbose apply --file examples/hello-world.yml --config-id hi
$ echo hi >> paunch-state.txtA container calledhellowill be created, print a Hello World message, then
exit. You can confirm that it still exists by runningpodman ps-a.Now lets try running the exact samepaunch applycommand:$ paunch --verbose apply --file examples/hello-world.yml --config-id hiThis will not make any changes at all due to the idempotency behaviour of
paunch.Lets try again with a unique –config-id:$ paunch --verbose apply --file examples/hello-world.yml --config-id hi-again
$ echo hi-again >> paunch-state.txtDoing apodman ps-anow will show that there are now 2 containers, one
calledhelloand the other calledhello-(randomsuffix). Lets delete the
one associated with thehiconfig-id:$ cat paunch-state.txt
$ echo hi-again > paunch-state.txt
$ cat paunch-state.txt
$ paunch --verbose cleanup $(cat paunch-state.txt)Doing apodman ps-awill show that the originalhellocontainer has been
deleted andhello-(randomsuffix)has been renamed tohelloGenerallypaunch cleanupwill be run first to delete containers for configs
that are no longer apply. Then a series ofpaunch applycommands can be run.
If theseapplycalls are part of a live upgrade where a mixture of old and
new containers are left running, the upgrade can be completed in the next run
topaunch cleanupwith the updated list of config-id state.Paunch can also be used as a library by other tools. By default running thepaunchcommand won’t affect these other containers due to the differentmanaged_bylabel being set on those containers. For example if you wanted to run paunch
commands masquerading as theheat-agentsdocker-cmd hookthen you can run:paunch --verbose apply --file examples/hello-world.yml --config-id hi --managed-by docker-cmdThis will result in ahellocontainer being run, which will be deleted the
next time thedocker-cmdhook does its owncleanuprun since it won’t
be aware of aconfig_idcalledhi.Idempotency BehaviourIn many cases the user will want to use the same –config-id with changed
config data.  The aim of the idempotency behaviour is to leave containers
running when their config has not changed, but replace containers which have
modified config.Whenpaunch applyis run with the same--config-idbut modified config
data, the following logic is applied:For each existing container with a matching config_id and managed_by:
* delete containers which no longer exist in config
* delete containers with missing config_data label
* delete containers where config_data label differs from current configDo a full rename to desired names since deletes have occuredOnly create containers from config if there is no container running with that nameexecactions will be run regardless, so commands they run may require
their own idempotency behaviourOnly configuration data is used to determine whether something has changed to
trigger replacing the container duringapply. This means that changing the
contents of a file referred to inenv_filewillnottrigger replacement
unless something else changes in the configuration data (such as the path
specified inenv_file).The most common reason to restart containers is to have them running with an
updated image. As such it is recommended that stable image tags such aslatestare not used when specifying theimage, and that changing the
release version tag in the configuration data is the recommended way of
propagating image changes to the running containers.Debugging with PaunchThepaunch debugcommand allows you to perform specific actions on a given
container.  This can be used to:Run a container with a specific configuration.Dump the configuration of a given container in either json or yaml.Output the podman command line used to start the container.Run a container with any configuration additions you wish such that you can
run it with a shell as any user etc.The configuration options you will likely be interested in here include:--file <file>         YAML or JSON file containing configuration data
--action <name>       Action can be one of: "dump-json", "dump-yaml",
                      "print-cmd", or "run"
--container <name>    Name of the container you wish to manipulate
--interactive         Run container in interactive mode - modifies config
                      and execution of container
--shell               Similar to interactive but drops you into a shell
--user <name>         Start container as the specified user
--overrides <name>    JSON configuration information used to override
                      default config valuesfileis the name of the configuration file to use
containing the configuration for the container you wish to use.Here is an example of usingpaunch debugto start a root shell inside the
test container:# paunch debug --file examples/hello-world.yml --interactive --shell --user root --container hello --action runThis will drop you an interactive session inside the hello world container
starting /bin/bash running as root.To see how this container is started normally:# paunch debug --file examples/hello-world.yml --container hello --action print-cmdYou can also dump the configuration of this to a file so you can edit
it and rerun it with different a different configuration.  This is more
useful when there are multiple configurations in a single file:# paunch debug --file examples/hello-world.yml --container hello --action dump-json > hello.jsonYou can then usehello.jsonas your--fileargument after
editing it to your liking.You can also add any configuration elements you wish on the command line
to test paunch or debug containers etc.  In this example I’m running
the hello container withnet=host.# paunch debug --file examples/hello-world.yml --overrides '{"net": "host"}' --container hello --action runConfiguration FormatThe current format is loosely based on a subset of thedocker-compose v1
formatwith
modifications. The intention is for the format to evolve to faithfully
implement existing formats such as theKubernetes Pod format.The top-level of the YAML format is a dict where the keys (generally)
correspond to the name of the container to be created.  The following config
creates 2 containers calledhello1andhello2:hello1:
  image: hello-world
hello2:
  image: hello-worldThe values are a dict which specifies the arguments that are used when the
container is launched. Supported keys which comply with the docker-compose v1
format are as follows:command:String or list. Overrides the default command.detach:Boolean, defaults to true. If true the container is run in the background. If
false then paunch will block until the container has exited.environment:List of the format [‘KEY1=value1’, ‘KEY2=value2’]. Sets environment variables
that are available to the process launched in the container.env_file:List of file paths containing line delimited environment variables.image:String, mandatory. Specify the image to start the container from. Can either
be a repositorys/tag or a partial image ID.net:String. Set the network mode for the container.pid:String. Set the PID mode for the container.uts:String. Set the UTS namespace for the container.privileged:Boolean, defaults to false. If true, give extended privileges to this container.restart:String. Restart policy to apply when a container exits.remove:Boolean: Remove container after running.interactive:Boolean: Run container in interactive mode.tty:Boolean: Allocate a tty to interact with the container.user:String. Sets the username or UID used and optionally the groupname or GID for
the specified command.volumes:List of strings. Specify the bind mount for this container.volumes_from:List of strings. Mount volumes from the specified container(s).log_tag:String. Set the log tag for the specified container.