What Is Portainer?

Chapter 4. Portainer Use Cases

In Chapter 3 you learned about the most important features of Portainer with regard to the challenges of cloud native architecture. In this chapter I will outline specific use cases built upon the aforementioned features that you can incorporate into your own infrastructure and workflows. You will learn how to give your team tiered access to resources in your managed Kubernetes clusters, deploy complex applications to them, and manage them with external tooling like kubectl, k9s, or Lens.

Managing Access to Kubernetes with RBAC

RBAC is short for role-based access control, a widely used mechanism to restrict systems access to authorized users. This is done by defining roles with specific privileges and assigning them to users or groups of users, as shown in Figure 4-1.

Portainer’s built-in roles map to cluster roles and namespace roles inside a Kubernetes cluster. Each role gives access to certain resources and the respective actions (or “verbs,” as they are called in Kubernetes) like get, create, or delete that are available for these resources inside the cluster.

You can learn more about the Portainer roles mapped to Kubernetes roles in the official documentation.

Figure 4-1. Overview of Portainer’s RBAC features

Roles can be assigned to teams or users in each environment, as shown in Figure 4-2. Users of a team inherit the roles of their team. Depending on your role, you gain a certain level of access to an environment and its resources (e.g., containers, ConfigMaps, etc.). A few examples include:

• View or edit Namespaces.

• View, create, or delete containers, Secrets, or ConfigMaps.

• Create or edit storage volumes or configurations.

Figure 4-2. Assign roles to teams or users

Using RBAC in combination with a centralized authentication provider and group sync, you can easily grant multiple, distributed developers access to resources in Kubernetes, depending on their role in your organization or the team they are part of.

Using Portainer as a Kubernetes API Proxy

Portainer can work as an API proxy for Kubernetes, as shown in Figure 4-3. As opposed to connecting through the web UI, as Figure 4-1 shows, with the API proxy you can connect external tooling like kubectl, k9s, or Lens that needs proper configuration in the form of a Kubeconfig file to work with a Kubernetes cluster.

Figure 4-3. Overview of Portainer as an API proxy for Kubernetes

Portainer allows you to download a special Kubeconfig file that has the Portainer instance configured as the API endpoint for each environment that is available to you.

With this Kubeconfig file, you authenticate against Portainer with a special user account that inherits your user’s roles and thus privileges on the respective clusters, so working with external tooling gives you the same level of access as working directly from within the Portainer GUI. Some people, like me, prefer to use specialized tooling when interfacing with Kubernetes clusters, which makes this feature a game changer in enterprise environments.

Without Portainer, cluster administrators would need to carefully create accounts and roles inside a cluster themselves when users need to access it with CLI tooling that needs a Kubeconfig file. And from personal experience, I can tell you that this is something you don’t want to deal with regularly. Having Portainer as a proxy, taking care of the necessary security layers, removes the burden of keeping the cluster secure from unwanted access from the shoulders of the cluster administrators and shifts it to a centrally managed control plane with well-designed RBAC rules.

Building Container Platforms for Cloud Native Teams

Figure 4-4 shows the environment overview, where you can review accumulated information about an environment at a central spot. The overview allows you to jump directly to the referenced objects.

Working with cloud native architecture patterns involves quite a few services apart from the actual workloads you might build. These include:

• A container registry

• A service catalog

• A tool for continuous deployment

• A tool for dealing with TLS certificates

• Databases

Figure 4-4. Environment overview

Portainer makes it easy to deploy and manage all the applications a team working with cloud native architecture patterns needs. Environment operators can provide helper tools like a container registry or a service catalog, while standard users (i.e., developers) can deploy their own workloads to an environment, making use of the helper tools without themselves being able to manipulate them (see Figure 4-5).

Figure 4-5. Namespaces list

Migrating Legacy Workloads to Kubernetes

Portainer has a long history with Docker, and many people and organizations use it to manage their Docker containers or docker-compose stacks. One challenge that arose with the advent of Kubernetes was its increased complexity compared to Docker or docker-compose. Many organizations can’t tackle this complexity due to lack of experience or budget.

In Portainer, you can simply import existing docker-compose stacks, and Portainer gladly converts them for you to Kubernetes manifests with the help of Kompose. In most cases, this conversion works seamlessly and thus enables you to safely move between Docker and Kubernetes environments right from within Portainer.

Portainer offers a range of tutorials outlining the process of migrating your legacy applications to Kubernetes:

• Deploy a compose-based app to Kubernetes using Kompose.

• “How to Transition from Docker/Swarm to Kubernetes with Portainer”.

• Deploy applications to Kubernetes.

This functionality helps to bridge the gap between single-node Docker environments and Kubernetes clusters. You don’t need to understand Kubernetes’s YAML manifests to migrate your applications to Kubernetes, but you can start by feeding Portainer an existing Docker Compose stack and then dive deeper into Kubernetes’s configuration language by analyzing and adapting the translated manifests.

Replace Docker Desktop for Container Management

Docker Desktop offers a dedicated user interface for the management of containers, images, and volumes, but it comes with a few strings attached. For one, that user interface is only available to Windows and macOS users but not for Linux users. Additionally, Docker Inc.’s licensing changed a lot over the years, rendering Docker Desktop unusable for large enterprises due to its license constraints.

Portainer can be installed on any Docker engine with a single command and provides a common user interface to manage containers on all operating systems:

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

On top, Portainer also works with alternative container engines like Podman or Lima and provides the same workflows and user experience for any of them.

This makes Portainer the ideal replacement for Docker Desktop, especially in environments with licensing constraints or alternative container engines.

Wrap-up

In the first two chapters, I outlined why a tool like Portainer is actually needed: while the software development ecosystem has evolved a lot in the last few years, the problems developers face have also evolved. Portainer is a great fit for an agile and distributed development environment and has many additional features in addition to the ones I covered in Chapters 3 and 4. I encourage you to catch up on them through Portainer’s documentation, YouTube, or another of the many articles and blog posts on the topic.

Depending on your own use cases, you might find Portainer valuable for totally different reasons: for example, as the container dashboard for your homelab, as a multitenant control plane for a managed services offering, or to quickly start containers from preconfigured templates. My personal background is in infrastructure, software delivery, and distributed development environments, so I naturally picked use cases that I’m familiar with. However, getting started with Portainer and exploring what it can do for you is only a single command away, and I encourage you to get your hands dirty right now:

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

Once it’s running, you can access it on https://localhost:9443 in your browser.

I tried to avoid step-by-step instructions on how to use Portainer in this report because this has been covered numerous times by the sources mentioned. I aimed to provide context as to why the tool exists and how it can help to solve higher-order problems you might encounter in your daily work. Given its popularity these days, it made sense to focus on Kubernetes for this report, but Portainer makes it equally easy to work with Docker or Docker Swarm environments, which are still very prevalent in our industry, albeit predominantly in on-premises environments. Since Portainer isn’t a SaaS solution but can easily be deployed to on-premises infrastructure, it’s worth a look even if Kubernetes is not part of your tech stack (yet). After all, Portainer is about containers at large.

As we all know, the level of abstraction in technology is constantly increasing, but now you’re equipped with a unique understanding of the problem space and a viable solution for some of the challenges you will encounter when developing and deploying software in a cloud native environment. I hope you found value in reading this report and have a clearer perspective on today’s software development ecosystem—and of course Portainer.