greenled / portainer-stack-utils

CLI client for Portainer

Home Page:https://hub.docker.com/r/greenled/portainer-stack-utils/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How do you use Portainer Stack Utils?

greenled opened this issue · comments

Hi @hoangphamw, @hoffigk, @idetoile, @jaygridley, @jobleadsorder, @joonyoung-lee, @jpahullo, @kanthi, @LolHens, @mcs07, @mcs07, @ntman4real, @null395922, @rickmclean, @somq, @tortuetorche, @uniconstructor, @xinity, @yeckey, all of you Protainer Stack Utils's stargazers.

I apologize for dragging your attention this massive way. I will be short, promised.

First of all, thank you for starring PSU, it's highly motivating. I would like to have a clearer idea of how is it being used out there in order to stay scoped and serve the most people.

It would be very helpful if you leave a comment briefly describing how you use (or would use, or know someone else uses) PSU, and what do you think is its strongest point.

Best regards,
Juan Carlos

Hello, @greenled .

Here is my answers:

  1. (usage) I would use Portainer Stack Utils as a default cli tool for deploying several different Docker app stacks in one machine. I prefer PSU cli instead of native docker-compose cli because of several reasons:
  • PSU has more high-level API, with "get the shit done" commands like psu stack deploy <mystack>
  • much more simple structure of yaml/json config
  • CI/CD friendly (I use GitLab CI)
  • environment variables management looks more clearer for me (ability to separate script's env-values from stack env-values is important for me)
  • microservice deployment & testing: if you are a backend developer, you need to deploy several microservices on a singe-instance test-server, and you don't have time to deep dive into docker-compose docs or learn things Ansiable (regardless of awesomeness of those tools) - the PSU is probably best choice for you to get your test-server up and running "here and now"
  1. (strongest point) The simplicity is the main feature for me

I almost got to the point to integrate it in a service that manages rolling updates in a proprietary system, but I finally decide to re-wrote it for consistency reasons.

I now use it as a cli tool to facilitate dev process; eg. deploying or undeplodying quickly a stack through portainer.

So strong points to me are: easy-to-use/flexible and stable/reliable. I want it to work, and with no pain

Hello,

  1. (usage)
  • we use PSU as part of our CD pipeline
  • we have PSU in Docker container and basically using docker run with bind of docker-compose.stack.yml into container and deploying it into Portainer using PSU call
  1. (strongest point)
  • simplicity
  • just works

Wonderful! Thank you for your thoughts.

Hello,
I use it as library for a little docker stack env helper that I've developed in python (at first just few lines in bash, then I moved on python and added a lot of features) and not allready documented (it will be in future) named stackd.
I use ansible in upstream to setup the whole architecture. For now I've added a local copy of PSU directly into my package, I now it's a bit dirty, but this way it's installed at same time as the pip package.
What I like in PSU:

  • simplicity (the do one thing and do it well)
  • no dependencies (except bash)
  • easy to understand code (and so easy to modify if needed)

PS: thanks for this awesome tool

@idetoile You're welcome. I'm glad you findit useful.

So, from your comments I see the project's main features are simplicity, reliability and extensibility. And it's used mainly as part of CI/CD pipelines.

Thanks for your feedback.