1d972ef174
Before this commit, adding multiple options to a bind-type mount (e.g. /foo/bar:/baz:Z,U) would result in a podman command in which only the last option would be used (e.g. U). This is because when parsing the mount string, a loop would go over each mount option and assign it to mount_opt_dict, this meant that this dict was overridden for each option, thus only the last option in the mount string would be kept and passed onto podman. This commit solves this by appending to a temporary list and then converting it to a comma-separated string and assigning it to the mount_opt_dict. Fixes #412 Signed-off-by: Adrian Torres <atorresj@redhat.com> |
||
|---|---|---|
| .github/ISSUE_TEMPLATE | ||
| docs | ||
| examples | ||
| scripts | ||
| tests | ||
| .gitignore | ||
| .pylintrc | ||
| CODE-OF-CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| podman_compose.py | ||
| README.md | ||
| requirements.txt | ||
| SECURITY.md | ||
| setup.cfg | ||
| setup.py | ||
| test_volumes.py | ||
| test-requirements.txt | ||
Podman Compose
An implementation of Compose Spec with Podman backend. This project focus on:
- rootless
- daemon-less process model, we directly execute podman, no running daemon.
This project only depend on:
podman- podman dnsname plugin: It is usually found in the
podman-pluginsorpodman-dnsnamedistro packages, those packages are not pulled by default and you need to install them. This allow containers be able to resolve each other if they are on the same CNI network. - Python3
- PyYAML
- python-dotenv
And it's formed as a single python file script that you can drop into your PATH and run.
References:
Alternatives
As in this article you can setup a podman.socket and use unmodified docker-compose that talks to that socket but in this case you lose the process-model (ex. docker-compose build will send a possibly large context tarball to the daemon)
For production-like single-machine containerized environment consider
For the real thing (multi-node clusters) check any production OpenShift/Kubernetes distribution like OKD.
Versions
If you have legacy version of podman (before 3.1.0) you might need to stick with legacy podman-compose 0.1.x branch.
The legacy branch 0.1.x uses mappings and workarounds to compensate for rootless limitations.
Modern podman versions (>=3.4) do not have those limitations and thus you can use latest and stable 1.x branch.
Installation
Install latest stable version from PyPI:
pip3 install podman-compose
pass --user to install inside regular user home without being root.
Or latest development version from GitHub:
pip3 install https://github.com/containers/podman-compose/archive/devel.tar.gz
or
curl -o /usr/local/bin/podman-compose https://raw.githubusercontent.com/containers/podman-compose/devel/podman_compose.py
chmod +x /usr/local/bin/podman-compose
or inside your home
curl -o ~/.local/bin/podman-compose https://raw.githubusercontent.com/containers/podman-compose/devel/podman_compose.py
chmod +x ~/.local/bin/podman-compose
or install from Fedora (starting from f31) repositories:
sudo dnf install podman-compose
Basic Usage
We have included fully functional sample stacks inside examples/ directory.
A quick example would be
cd examples/busybox
podman-compose --help
podman-compose up --help
podman-compose up
A more rich example can be found in examples/awx3 which have
- A Postgres Database
- RabbitMQ server
- MemCached server
- a django web server
- a django tasks
When testing the AWX3 example, if you got errors just wait for db migrations to end.
There is also AWX 17.1.0
Tests
Inside tests/ directory we have many useless docker-compose stacks
that are meant to test as much cases as we can to make sure we are compatible