Go to file
2019-08-17 01:14:02 -04:00
.circleci Add tag filter to all steps in ci workflow 2019-08-15 18:22:23 +02:00
client Replace Portainer struct copies with original ones wherever possible 2019-08-10 12:14:55 -04:00
cmd Change endpoint selection strategy from ID to Name 2019-08-15 23:01:11 -04:00
common Add functions to get endpoint from list by name and by id 2019-08-15 22:40:56 -04:00
version Mover version-related code to the version package 2019-08-13 23:33:49 -04:00
.gitignore Rewrite project in Go 2019-07-21 18:49:28 -04:00
.goreleaser.yml Mover version-related code to the version package 2019-08-13 23:33:49 -04:00
CHANGELOG.md Update changelog 2019-08-17 00:45:29 -04:00
CODE_OF_CONDUCT.md Add extended contributing guidelines and code of conduct 2019-08-16 14:23:24 -04:00
CONTRIBUTING.md Add extended contributing guidelines and code of conduct 2019-08-16 14:23:24 -04:00
Dockerfile Fix base Docker image to alpine:3.10 2019-08-14 02:01:03 -04:00
go.mod Update Portainer API compatibility to 1.22.0 2019-08-16 12:53:10 -04:00
go.sum Tidy up go modules 2019-08-16 12:53:10 -04:00
LICENSE Add license 2018-11-21 15:12:03 -05:00
main.go Rewrite project in Go 2019-07-21 18:49:28 -04:00
README.md Add Go and Bash versions distinction in Readme 2019-08-17 01:14:02 -04:00

Portainer Stack Utils

CircleCI Docker Automated build Docker Pulls Microbadger Go Report Card

Table of contents

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. There is ongoing work in 1-0-next branch to enhace that Bash version.

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 from the releases page. The binaries have no external dependencies.

You can also install the source code with go and build the binaries yourself.

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

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=5
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

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.