Container virtualization is not a new invention; in fact, it wasn't that even 10 years ago when Docker made it socially acceptable on Linux. Much to the chagrin of many administrators, there is still have a long way to go to achieve everything positive claimed by the container vendors. Many system administrators dealing with containers for the first time give up in frustration: It seems you have to learn a new language to find your way around the dictionary of container terms, and each platform has individual concepts that need to be understood. No matter how you spin it, not much is left of the once loudly trumpeted promise of easy container handling on Linux.

That complexity doesn't have to be the case, claims Portainer, which provides administrators a tool that, according to the manufacturer, keeps them more or less blissfully unaware of the entire container circus. With a simple web-based interface, you tell Portainer which containers to roll out and in what state. According to the advertising material, the program then takes care of the rest autonomously, supporting a variety of solutions from plain vanilla Docker to a deployment with Kubernetes. Support for ready-made Kubernetes distributions from the major hyperscalers is explicitly part of the package, which means you no longer have to deal with Kubernetes itself in detail.

These claims are reason enough to take a closer look under the Portainer hood: Is it really the panacea for administrators who need to deliver containers quickly? What are the differences between the available Portainer editions? How easy is the setup? How much does this fun cost? How quickly does it deliver results?

The Basics

One of the big problems with the container universe on Linux is the enormous number of (supposedly) helpful third-party tools. You'd be hard pressed to keep track of everything, so it makes sense to start the investigation of Portainer by looking at its essential properties: What is the tool, and what can it do?

A quick look at the tool's architecture (Figure 1), derived directly from Portainer's documentation [1], will help. Accordingly, the solution comprises two components at its core. A central server provides the graphical user interface (GUI), which it delivers in the form of a web interface. The services it offers (e.g., a database running in the background) are hidden from the administrator. There are two not quite congruent variants of the agent: Edge and Portainer. Portainer Agent is historically the older one, but more on that later.

Figure 1: The diagram of Portainer's architecture shows that the solution itself does not comprise many components; Server and Agent elements are all you need to serve up the entire feature set. © Portainer

You don't have to do much to try out Portainer. Just install the community edition of Docker (Docker CE) on a current system (e.g., Ubuntu 22.04), create a persistent volume, and then start the Portainer container (Listing 1). The rest happens automatically. The Portainer developers have certainly shown some foresight here. Portainer creates a self-signed SSL certificate at startup to protect passwords and similar content from being transmitted – at least in principle. The tool's documentation also includes instructions on how to use your own SSL certificates to avoid warning messages.

### Install Portainer
# docker volume create portainer_data
# docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest
### Set up Portainer Agent
# docker run -d -p 9001:9001 --name portainer_agent --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker/volumes:/var/lib/docker/volumes portainer/agent:latest

The tool offers a wizard that guides you through the initial configuration process. You first need to create a default user for Portainer (whose account you use later to log in to the web interface). No default password exists that is accidentally left unchanged and later allows attackers to gain access when the application becomes accessible on the web.

As the last step, the wizard automatically detects the environment in which it is running and configures the appropriate presettings. However, don't expect too much from it. Finally, Portainer itself runs in a container and therefore has no access to the physical host on which it runs. At least that is the theory, because the tool exhibits a couple of lapses in terms of security, as you will see later.

After the initial setup, in most cases you will have Portainer's essentially blank web interface in front of you, which is an indication of how the program works as a kind of broker that translates your wishes into concrete container code which it executes on target systems. The target systems are still missing in Portainer after the initial install. The same applies to your desired setup; you will be using the GUI to configure this. Logically, the next step in the Portainer setup is to configure an environment for Portainer to roll out its workloads; you can do so in several ways.

The Surroundings

Undoubtedly the easiest option is to put a host with a running Linux and functional Docker CE installation under the auspices of Portainer. This setup gives you two options: Portainer can control the remote system directly through the Docker API. In principle, it is available on every host with a Docker CE installation, but it is configured as a factory default so it cannot be accessed remotely. Chief information security officers grimace at the thought of opening the Docker API to outside calls, because the API does not support password-based access. The connection can at least be secured by an SSL certificate, but this approach does not seem to make sense. The variant that uses Portainer Agent makes more sense, and it also offers more functionality.

Admittedly, a Docker host doesn't have to be a physical host: A virtual system is fine (as is the case for running Portainer Server, by the way). However, the executing system administrator must have administrative access to the system on which Portainer will be running. This is true of the use case with the Docker API as well as Portainer Agent. After all, Portainer cannot manage the agent setup left to its own devices. Instead, you need to give the service a helping hand by first installing the CE edition of Docker and then running the command from the last line of Listing 1.

In the Portainer user interface (UI), the two variants are not that different from each other. In both procedures, you first need to add a remote environment and then, depending on the situation, either select the variant with the Docker API or the one that uses an agent as a subsection of Docker Standalone. A wizard is again available in the interface to do some of the work of setting up a remote system with Portainer Agent. After storing the first host with Docker CE in Portainer, it's time to roll out some containers.

What About Kubernetes?

At this point, attentive readers will of course wonder what's happening with Kubernetes, Google's container orchestrator. It is now more or less used as a synonym for container, although the two terms are by no means the same.

Portainer can optionally launch its services in the form of standard Docker containers, provided the remote host is an appropriate system and has been stored as a remote environment in Portainer. This use case is preferable for workloads in which only individual applications are in container form. When it comes to cloud-native applications, on the other hand, you are usually dealing with a large number of individual containers that need to be rolled out in a coherent, controlled, and manageable way. This scenario only works with Kubernetes and is precisely one of Portainer's great strengths.

The tool not only understands how to handle Docker, but it is also proficient at handling Kubernetes (K8s) and can just as easily use a K8s installation as a deployment target. When Portainer developers promise system administrators that applications for K8s can be rolled out with Portainer as easily as individual, standalone containers, that's exactly what they mean. Of course, the prerequisite for this is that Kubernetes is already running somewhere.

In Portainer, you are again assisted by a wizard that rolls out the required Portainer services to a running K8s. If you have never run Kubernetes, you can launch it in Azure from within Portainer; this is a managed Kubernetes named Azure Kubernetes (AKS) (Figure 2). This scheme is undoubtedly the easiest way to get Portainer working in combination with Kubernetes.

Figure 2: AKS is the only Kubernetes service by hyperscalers that Portainer supports out of the box. © Microsoft

Alternatively, Portainer also supports Nomad (Figure 3), a tool for automatic scheduling of server tasks and specifically optimized for operation with clouds and container environments. To make the partnership with Nomad work, you first store the Nomad clusters that exist in your environment in the Portainer configuration and then assign tasks in the GUI, in the same way as with Kubernetes. Nomad can then be used to launch workloads in other environments, so Portainer, in combination with Nomad, effectively outsources some of its own functionality.

Figure 3: Deployment targets other than those supported out of the box can be included with Nomad. However, this extra layer adds complexity. © HashiCorp

We had no complaints about this feature in the test lab. This is at least true if you disregard the fact that Nomad makes the setup more complex and is a separate application that you need to get used to first. The notorious layer cake that administrators regularly talk about in the context of K8s and containers is always looming on the horizon with Portainer. Of course, the solution's well-structured interface makes it easy to stay on top.