All Projects → greenled → portainer-stack-utils

greenled / portainer-stack-utils

Licence: GPL-3.0 license
CLI client for Portainer

Programming Languages

go
31211 projects - #10 most used programming language
Dockerfile
14818 projects

Projects that are alternatives of or similar to portainer-stack-utils

Flubucore
A cross platform build and deployment automation system for building projects and executing deployment scripts using C# code.
Stars: ✭ 695 (+953.03%)
Mutual labels:  deployment, continuous-deployment
Devtron
Software Delivery Workflow For Kubernetes
Stars: ✭ 130 (+96.97%)
Mutual labels:  deployment, continuous-deployment
Lightning Sites
☁️ Lightning deployment for your ~/Sites folders
Stars: ✭ 8 (-87.88%)
Mutual labels:  deployment, continuous-deployment
Httpie
As easy as /aitch-tee-tee-pie/ 🥧 Modern, user-friendly command-line HTTP client for the API era. JSON support, colors, sessions, downloads, plugins & more. https://twitter.com/httpie
Stars: ✭ 53,052 (+80281.82%)
Mutual labels:  api-client, httpie
BuildConfig.swift
Android-like auto-generate configuration files for macOS/iOS
Stars: ✭ 30 (-54.55%)
Mutual labels:  json-configuration, yaml-configuration
Ssh Deploy
GitHub Action for deploying code via rsync over ssh
Stars: ✭ 272 (+312.12%)
Mutual labels:  deployment, continuous-deployment
Slimjim
SlimJim is a simple auto update script utilizing Slim (a PHP micro-framework), incron (inotify cron system), and GitHub/BitBucket post-receive-hook
Stars: ✭ 98 (+48.48%)
Mutual labels:  deployment, continuous-deployment
kuzgun
simple, ssh based deployment tool
Stars: ✭ 16 (-75.76%)
Mutual labels:  deployment, continuous-deployment
Rocket
Automated software delivery as fast and easy as possible 🚀
Stars: ✭ 217 (+228.79%)
Mutual labels:  deployment, continuous-deployment
Build
Netlify Build runs the build command, Build Plugins and bundles Netlify Functions.
Stars: ✭ 135 (+104.55%)
Mutual labels:  deployment, continuous-deployment
configmanager
Forget about configparser, YAML, or JSON parsers. Focus on configuration. NOT RECOMMENDED FOR USE (2019-01-26)
Stars: ✭ 15 (-77.27%)
Mutual labels:  json-configuration, yaml-configuration
build-plugin-template
Template repository to create new Netlify Build plugins.
Stars: ✭ 26 (-60.61%)
Mutual labels:  deployment, continuous-deployment
Hapistrano
Deploy tool for Haskell applications, like Capistrano for Rails
Stars: ✭ 91 (+37.88%)
Mutual labels:  deployment, continuous-deployment
Inertia
✈️ Effortless, self-hosted continuous deployment for small teams and projects
Stars: ✭ 133 (+101.52%)
Mutual labels:  deployment, continuous-deployment
ci-docker-image
A Docker Image meant for use with CI/CD pipelines
Stars: ✭ 23 (-65.15%)
Mutual labels:  deployment, continuous-deployment
workflow-webhook
A Github workflow action to call a webhook with payload data from the event. Support for JSON or URL encoded endpoints.
Stars: ✭ 90 (+36.36%)
Mutual labels:  deployment, continuous-deployment
repotoddy
Repotoddy is a continuous deployment tool that works in conjunction with Reposado. An open source tool that replicates the key functionality of macOS Server's Software Update Service.
Stars: ✭ 26 (-60.61%)
Mutual labels:  continuous-deployment
client-js
JS client for polygon.io api
Stars: ✭ 81 (+22.73%)
Mutual labels:  api-client
webflow-ruby
🕸 🌀Webflow API bindings for Ruby
Stars: ✭ 20 (-69.7%)
Mutual labels:  api-client
amiws
Asterisk Management Interface (AMI) to Web-socket proxy
Stars: ✭ 60 (-9.09%)
Mutual labels:  yaml-configuration

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, 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:

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.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].