README.md

Portainer Stack Utils

Table of contents

• Overview
  • Mission
  • Vision
• Supported Portainer API
• How to install
• How to use
  • Configuration
    • Inline flags
    • Environment variables
    • Configuration files
      • YAML configuration file
      • JSON configuration file
  • Environment variables for deployed stacks
  • Endpoint's Docker API proxy
    • Known limitations
  • Log level
  • Exit statuses
• Contributing
• License

Overview

Portainer Stack Utils is a CLI client for Portainer written in Go.

Attention: The master branch contains the next major version, still unstable and under heavy development. A more stable (and also older) version is available as a Bash script in release 0.1.1, and also as a Docker image. There is ongoing work in 1-0-next branch to enhace that Bash version.

Mission

To provide an easy and extensible way of interacting with Portainer in automated, non-interactive environments.

Vision

By December 2019 Portainer Stack Utils:

• Has a stable API
• Doubles its GitHub stargazers (+50)
• Triples its DockerHub downloads (+900)

Supported Portainer API

This application was created for the latest Portainer API, which at the time of writing is 1.22.0.

How to install

Download the binaries for your platform and architecture from the releases page.

How to use

The application is built on a structure of commands, arguments and flags.

Commands represent actions, Args are things and Flags are modifiers for those actions:

APPNAME COMMAND ARG --FLAG

Here are some examples:

psu help
psu status --help
psu stack ls --endpoint primary --format "{{ .Name }}"
psu stack deploy mystack --stack-file docker-compose.yml -e .env --log-level debug
psu stack rm mystack

Commands can have subcommands, like stack ls and stack deploy in the previous example. They can also have aliases (i.e. create and up are aliases of deploy).

Some flags are global, which means they affect every command (i.e. --log-level), while others are local, which mean they only affect the command they belong to (i.e. --stack-file flag from deploy command). Also, some flags have a short version (i.e --insecure, -i).

Configuration

The program can be configured through inline flags (i.e. --user), environment variables (i.e. PSU_USER=admin) and/or configuration files, which translate into multi-level configuration keys in the form x[.y[.z[...]]]. Run psu config ls to see all available configuration options.

All three methods can be combined. If a configuration key is set in several places the order of precedence is:

1. Inline flags
2. Environment variables
3. Configuration file
4. Default values

Inline flags

Configuration can be set through inline flags. Valid combinations of commands and flags directly map to configuration keys:

Configuration key	Command	Flag
user	psu	--user
stack.list.format	psu stack list	--format
stack.deploy.env-file	stack deploy	--env-file

Run psu help COMMAND to see all available flags for a given command.

Environment variables

Configuration can be set through environment variables. Supported environment variables follow the PSU_[COMMAND_[SUBCOMMAND_]]FLAG naming pattern:

Configuration key	Environment variable
user	PSU_USER
stack.list.format	PSU_STACK_LIST_FORMAT
stack.deploy.env-file	PSU_STACK_DEPLOY_ENV_FILE

Note that all supported environment variables are prefixed with "PSU_" to avoid name clashing. Characters "-" and "." in configuration key names are replaced with "_" in environment variable names.

Configuration files

Configuration can be set through a configuration file. Supported file formats are JSON, TOML, YAML, HCL, envfile and Java properties config files. Use the --config global flag to specify a configuration file. File $HOME/.psu.yaml is used by default if present.

YAML configuration file

A Yaml configuration file should look like this:

log-level: debug
user: admin
insecure: true
stack.list.format: table
stack:
  deploy.env-file: .env
  deploy:
    stack-file: docker-compose.yml

Note that flat and nested keys are both valid.

JSON configuration file

A JSON configuration file should look like this:

{
  "log-level": "debug",
  "user": "admin",
  "insecure": true,
  "stack.list.format": "table",
  "stack": {
    "deploy.env-file": ".env",
    "deploy": {
      "stack-file": "docker-compose.yml"
    }
  }
}

Note that flat and nested keys are both valid.

Environment variables for deployed stacks

You will often want to set environment variables in your deployed stacks. You can do so through the stack.deploy.env-file configuration key. :

touch .env
echo "MYSQL_ROOT_PASSWORD=agoodpassword" >> .env
echo "ALLOWED_HOSTS=*" >> .env

# Using --env-file flag
psu stack deploy django-stack -c /path/to/docker-compose.yml -e .env

# Using PSU_STACK_DEPLOY_ENV_FILE environment variable
PSU_STACK_DEPLOY_ENV_FILE=.env
psu stack deploy django-stack -c /path/to/docker-compose.yml

# Using a config file
echo "stack.deploy.env-file: .env" > .config.yml
psu stack deploy django-stack -c /path/to/docker-compose.yml --config .config.yml

Endpoint's Docker API proxy

If you want finer-grained control over an endpoint's Docker daemon you can expose it through a proxy and configure a local Docker client to use it.

First, expose the endpoint's Docker API:

psu proxy --endpoint primary --address 127.0.0.1:2375

Then (in a different shell), configure a local Docker client to use the exposed API:

export DOCKER_HOST=tcp://127.0.0.1:2375

Now you can run docker ... commands in the primary endpoint as in a local Docker installation, with the added benefit of using Portainer's RBAC.

Note that creating stacks through docker stack ... instead of psu stack ... will give you limited control over them, as they are created outside of Portainer.

Known limitations

• Docker commands requiring a websocket connection (like docker attach, docker exec, docker system events) are known to fail with an unable to upgrade to tcp, received 200 error or just hang up (see #31).

Log level

You can control how much noise you want the program to do by setting the log level. There are seven log levels:

• panic: Unexpected errors that stop program execution.
• fatal: Expected errors that stop program execution.
• error: Errors that should definitely be noted but don't stop the program execution.
• warning: Non-critical events that deserve eyes.
• info: General events about what's going on inside the program. This is the default level.
• debug: Very verbose logging. Usually only enabled when debugging.
• trace: Finer-grained logging than the debug level.

WARNING: trace level will print sensitive information, like Portainer API requests and responses (with authentication tokens, stacks environment variables, and so on). Avoid using trace level in CI/CD environments, as those logs are usually recorded.

This is an example with debug level:

psu stack deploy asd --endpoint primary --log-level debug

The output would look like:

DEBU[0000] Getting endpoint's Docker info     endpoint=primary
DEBU[0000] Getting stack                      endpoint=primary stack=asd
DEBU[0000] Stack not found                    stack=asd
INFO[0000] Creating stack                     endpoint=primary stack=asd
INFO[0000] Stack created                      endpoint=primary id=89 stack=asd

Exit statuses

• 0: Program executed normally.
• 1: An expected error stopped program execution.
• 2: An unexpected error stopped program execution.

Contributing

Contributing guidelines can be found in CONTRIBUTING.md.

License

Source code contained by this project is licensed under the GNU General Public License version 3. See LICENSE file for reference.