Back in September 2020, I wrote a short article on how to get Portainer up and running as well as connecting it with multiple Docker hosts using the Portainer agent.

With that article, you have all you need to get up and running. In this article, I would like to talk about docker-compose and how you can use Portainer and its stacks feature to use docker-compose files as well as what benefits you might have when using Portainer as oppose to the Docker command line.  

Stacks = docker-compose, the Portainer way

If you have ever started Portainer you will notice its main menu on the left-hand side and most of the options here are self-explanatory. One thing that sticks out, is Stacks.

So what's the stacks option? The stacks, as Portainer calls them, are sets of features that will allow you to start and run your container(s) using a well-structured docker-compose.yml file.

You might be wondering why would you need to run a docker-compose container in the first place? Well, if you look at Synology's Docker UI, you will find out soon that it doesn't cover all potential options and features that you might need with certain solutions out there that you want to run inside Docker.

That will turn you towards a docker-compose file that will have all the instructions needed to run the container, and in order to run it, you start by going into the command line and run a simple single line.

So what's the advantage of running a "stack" using Portainer? Well, you have a nice UI that will give you all the tools needed including a web editor that will check if the YML file is formated and structured correctly. Meaning you will be able to have a color-coded docker-compose file ready to be executed and changed on the fly if you have the need to do it.

There are several ways you can start with docker-compose in Portainer. As you can see from the image above, there are four methods of doing this.

Web editor, uploading a file, using a GIT repository, or using a custom template.

For my personal use case, I use web editor or upload methods just because most of the time I just write my own compose files, or if I already have them saved, simply upload them or again just copy the content of the file into the web editor.

Another reason I favor web editor is that I can just quickly edit (and correct it if needed) the composed file content and redeploy the container.

Now just to be clear you can still use and manipulate your container created via the stack the same way as you would any other container. As you can see on the image above, there are still tools that allow you to start, stop, kill or restart your container.

On top of these tools, you will have the section on stack tools as well. There is a way to stop, delete and create a template from that stack.

In case you were wondering, stoping the stack will stop all the containers in the stack and there will be no exceptions around this, so choose what containers you want to be part of a single stack.

One thing that you can also see is that while the container and stack are running you also have access to the editor part of the stack.

From the above example you can see that while the container is in the running state, you can edit the docker-compose and use the Update the stack button to remove the old container and redeploy a new one.

One example that this might be useful is that you want to change the port number on the fly, or use a different image tag to deploy the same container but with a new repo tag, or just change the name of the container. The point is that you have it all right there in a single window with no need to use a different code editor, save your changes, and then use the up/down docker-compose CLI command.

Manage "stacks" created outside Portainer

Now there are some cases at the moment that you might not be able to use the full potential of docker-compose CLI commands inside Portainer. One example is using the env_file command.

Just to show you how a "stack" (or how it's called a "project") crated via command line looks like on the Portainer end.

If we compare the images you will notice that the stack tools are missing. So there are no options to stop, delete or make a template out of this stack if it was not initiated from the Portainer in the first place.

Still, you do have an overview and you can control the containers that are the result of this stack.

Not really a topic for this particular article but will just mention one thing about agents that will in the end make sense when dealing with stacks.

Portainer agents - aggregate your Docker hosts in a single UI

One more way that a web editor might be handy is the quick deployment of the same container on multiple Docker hosts. Templates or again, web editor, can come in handy to switch from one host to the other using the same Portainer UI.

Let's say you have a Portainer host running on one of your Docker hosts, but you also have a number of other Docker hosts as well. Instead of having multiple Portainers on all of those hosts, and the need to log into each of them, why not pull them together under a single Portainer instance with agents?

With version 2.6 of Portainer, there will be an accompanying version of the agent as well.

From the official Portainer News and Blog post:

What does this mean exactly?

When you install Portainer CE 2.6 there will be a matching Agent version 2.6 available. If you already have a Portainer instance 2.5.1 running, you’ll need to set up the Agent version 2.5.1.
This helps to remove confusion around version compatibilities when installing particular instances and when updating versions. Now, you might be asking what if I don’t follow this. What happens? Well, we want the agent to work across different versions of Portainer, however, in the future, this may not be possible. So, we recommend version pining to avoid any unplanned disruptions.

Info on how to connect multiple Docker hosts using the agents can be found in my other Portainer article here, under the Add Docker host to your Portainer using an agent heading.

The reason I am saying this is that in this configuration there are other cool benefits of running stacks and using Portainer at the same time.

Migration and duplication of stacks

If you have a Docker Swarm cluster up and running and controlled by the Portainer or simply have multiple hosts connected with agents, you can migrate your stack from one host to the other.

Once you have decided on the stack you want to migrate, give it a new destination name and select the host from the list of endpoints.

To make this happen and work keep a few things in mind:

So basically, just like when you are making a new fresh container/stack on your host you will need to make sure that all those prerequisites are met in the migration process as well.

Conclusion

If you are serious about containers on any platform, you should consider using Portainer. It will allow you all the features that Docker offers, as well as allow you to use it with Kubernetes, Docker Swarm, and Azure ACI.

There are still people that like to use CLI of course and there is nothing wrong with that, but Portainer will be there for anyone that wants to have a powerful UI to do all those tasks. Also, with its support for users and teams, Portainer will be a one-stop shop for all your collaborative needs as well.

Let me know down in the comments if you use Portainer, and for what, and if so, has it helped you out, or is it missing some features that you need or would like to be able to use.