No Direct Access

As already described, Portainer Agent comes in two forms: the original form and the edge variant. What at first sounds like a marketing blurb simply refers to the communication model between Portainer Server and Agent. The functionality of the two agents is the same.

However, the standard Portainer Agent relies on commands being pushed by Portainer Server. This classic server-agent model cannot be implemented in many setups today. In many companies, for example, it is considered sacrilege to open up parts of your own infrastructure for incoming connections, and it's unlikely that every remote system you want Portainer to manage will be accessible directly from the outside.

The systems in edge environments are largely isolated from the outside world as compute cells. In this case, the edge variant of Portainer Agent, which relies on the pull principle, steps into the breach. The agent autonomously connects to Portainer Server and queries the pending tasks. Edge Agent works where clients are allowed to send data to the Internet themselves or can use a VPN connection to do so.

Many Options

Once you have set up Portainer and upgraded it with target nodes, you can look forward to comprehensive container service. Simple tasks can be carried out with just a few mouse clicks. For example, if you want to start a Docker container with a server attached to it on a target system, you can do so from the Containers tab in the GUI sidebar.

It quickly becomes apparent that the developers deliberately constructed the Portainer interface so that any admin who has already dealt with other virtualization solutions (e.g., VMware) will be able to find their way around easily. Entries for images and networks and for creating persistent volumes can be found in the menu on the left, but you don't have to use them. As your knowledge grows, you can create networks and storage volumes implicitly when you create a container or a stack (i.e., a container environment in a Kubernetes installation).

Many companies are now moving to ban completely the use of Docker Hub images. Experience shows that less experienced admins in particular are more likely to turn to dubious images in search of quick solutions to a problem. These images often contain unwanted add-ons, such as Bitcoin miners. Portainer also covers this application scenario. You can explicitly prohibit the use of Docker Hub and enable the use of other, private registries by storing them in the Portainer configuration.

However, it is a pity that Portainer does not come with its own image registry, because from the point of view of a system administrator, it is not so easy to establish a private registry, particularly if it has to meet all of your organization's security requirements. Most commercial providers have components in their portfolios, but these components form an integral part of a huge solution such as OpenShift and are of little interest to container newcomers.

Another option in the Portainer UI is something you would not expect to find. Almost disrespectfully, the developers describe their tool in their own documentation as a ClickOps tool, which can be loosely translated as a tool hiding the vast majority of complexity from the administrator carrying out the operational tasks.

The topic of continuous integration and continuous deployment (CI/CD) is not something I would put in this category. Nevertheless, the Portainer developers have now added options for integration with CI/CD pipelines to their tool. To do this, you can use webhooks to connect Portainer to GitLab or GitHub, for example, and then monitor source code directories for which the CI/CD function has been enabled. If something changes there, the modified configuration is then adopted into production use.

When the content of an image changes, you need to make sure the updated image somehow makes it into a publicly accessible registry, from which Portainer will then reliably download and launch the new version. This is not quite as much feature overkill as you would have with a full-fledged Jenkins installation, but it offers a quick introduction to the topic without assuming too much knowledge.

Potentially Blind

In a number of places, one of the central problems associated with the use of containers becomes clear: You need to trust Portainer to work and run correctly in the background, even more so because the tool comes with an application template gallery (Figure 4), which can be used to roll out various services with just a few mouse clicks.

Figure 4: The application templates in Portainer tempt you to roll out many services, but if something goes wrong, you need to know what to do. © Red Hat

It's one thing to roll out containers on a system that has the community edition of Docker installed. The required knowledge can be acquired quite quickly, even without any relevant previous knowledge that would empower you to, say, troubleshoot a container. However, things are different with regard to Kubernetes or more complex tasks such as processing a CI/CD toolchain, because Kubernetes itself is highly complex, even if you only use the standard edition.

If you use a Kubernetes distribution like Rancher or OpenShift (Figure 5), you have several additional layers of complexity on top to deal with. The same applies to hyperscaler-managed Kubernetes instances, some of which work differently under the hood than normal Kubernetes, implicitly adding more layers of complexity yet again. If you roll out services here with Portainer, you are likely to be out of your depth if you then experience issues, because you might not have the prior Kubernetes knowledge to fix them. Debugging Kubernetes without prior knowledge is challenging, if not impossible.

Figure 5: OpenShift is a complex construct that offers many additional features on top of the functionality of normal Kubernetes. © Red Hat

Just so you have no misunderstandings: Up to this point, Portainer reliably does everything its developers promise. Even without any knowledge of Kubernetes, getting workloads running in K8s is not difficult from an administrator's perspective. Portainer abstracts the Kubernetes layer almost completely. That's all well and good, as long as everything runs smoothly, but if something goes wrong, the blessing can quickly turn into a curse, especially if Portainer fails with production workloads.