Portainer 101

Managing containers is hard. There are multiple containerized platforms, each with their own benefits, quirks and ways of doing things. That's where Portainer comes in.

Portainer came about as a way to simplify the management of Docker environments. Over time, Portainer evolved to cover Docker (Standalone and Swarm), Kubernetes and Azure ACI. We wanted to create a unified interface to both simplify container management and empower users and administrators to do what they need to do, as quickly and efficiently as possible.

The vending machine analogy

Anyone can walk up to a vending machine, see what's on offer, put their money in, and get what they want out of it. Simple, straightforward self-service.

The same should be true for containers. A developer, for example, should be able to log in, get what they need in a few clicks, and be up and running within minutes. The underlying environment or how it works shouldn't matter so long as they can successfully run their code.

Our goal with Portainer is to provide just that: a vending machine for containerized environments. You can log into Portainer, quickly and easily provision the containers you need, then get to work - regardless of your platform.

Enter Portainer Business

As our user community grew, the more we learned about its needs. It became clear early on that our business customers' requirements went beyond the functionality provided by our Community Edition. In particular, those related to security, accountability, analytics and support.

To meet this need, we built Portainer Business Edition. Designed to meet the unique requirements of businesses environments, Portainer Business Edition is built on top of the open source Community Edition, leveraging its features and fixes while providing the necessary functionality a commercial organization demands.

You can learn more about the differences between the Community Edition and Business Edition on our website.

Why should I use Portainer?

If you're already a container management expert, you might be wondering how Portainer can help you. While you don't need Portainer to manage your environments, it can make things a whole lot easier.

Portainer provides a unified interface for interacting with your environments so you don't have to worry about the platform you're using (yourself or your users). Technology moves quickly, and keeping up with changes is tough. Portainer lets you and your users focus on consuming your platform without being an expert in it.

From a single interface, you can streamline container management and multiple environments, as well as keep a close eye on hosts and platforms. You can easily see the what, where and how of your applications without the command line, and collate results from multiple locations.

Portainer can also provide increased security to your container environments through identity and access management, and activity logging. Users and teams can be assigned roles that limit the actions they can perform and the environments they can access. Portainer logs all activity, letting you solve issues faster.

Next steps

You're almost ready to dive into the installation! But first, let's spend some time on the architecture, and after that we'll cover some of the general prerequisites for running Portainer on your environments.



Overview of Portainer architecture

Portainer consists of two elements: the Portainer Server and the Portainer Agent. Both run as lightweight containers on your existing containerized infrastructure. The Portainer Agent should be deployed to each node in your cluster and configured to report back to the Portainer Server container.

A single Portainer Server will accept connections from any number of Portainer Agents, providing the ability to manage multiple clusters from one centralized interface. To do this, the Portainer Server container requires data persistence. The Portainer Agents are stateless, with data being shipped back to the Portainer Server container.

We don't currently support running multiple instances of the Portainer Server container to manage the same clusters. We recommend running the Portainer Server on a specific management node, with Portainer Agents deployed across the remaining nodes.

Agent vs Edge Agent

In standard deployments, the central Portainer Server instance and any environments it manages are assumed to be on the same network, that is, Portainer Server and the Portainer Agents are able to seamlessly communicate with one another. However, in configurations where the remote environments are on a completely separate network to Portainer Server, say, across the internet, historically we would have been unable to centrally manage these devices.

With the new Edge Agent, we altered the architecture. Rather than the Portainer Server needing seamless access to the remote environment, only the remote environments need to be able to access the Portainer Server. This communication is performed over an encrypted TLS tunnel. This is important in Internet-connected configurations where there is no desire to expose the Portainer Agent to the internet.

Security and compliance

Portainer runs exclusively on your servers, within your network, behind your own firewalls. As a result, we do not currently hold any SOC or PCI/DSS compliance because we do not host any of your infrastructure. You can even run Portainer completely disconnected (air-gapped) without any impact on functionality.

While we do (optionally) collect anonymous usage analytics from Portainer installations, we remain compliant with GDPR. Data collection can be disabled when you install the product, or at any time after that. If your installation is air-gapped, collection will silently fail without any adverse effects.


General Prerequisites

Valid configurations

Every Portainer release goes through functional, release and post-release testing to ensure it works as expected. Because we cannot test against every configuration variant out there, we test against a subset.

The following table lists all of the configurations that we have tested, validated and consider to be functional. If a variant is not listed, it doesn't mean it won't work, it just means it hasn't been tested.

Portainer Version Release Date Docker Version Kubernetes Version Architectures
Business 2.12 (latest) Mar 8, 2022 20.10.7 20.10.11 20.10.12 1.21.7 1.22 1.23 ARM64, x86_64
Business 2.10 Nov 15, 2021 20.10.6 20.10.7 1.19 1.20.2 1.21 1.22 ARM64, x86_64
Business 2.7 Jul 29, 2021 20.10.6 20.10.7 1.19 1.20.2 1.21 ARM64, x86_64
Business 2.4 May 4, 2021 20.10.5 1.19 1.20.2 1.21 ARM64, x86_64
Business 2.0 Dec 3, 2020 19.03.13 1.17.3 1.18.6 1.19.3 ARM64, x86_64

Persistent storage

The Portainer Server requires persistent storage in order to maintain the database and configuration information it needs to function. The installation process provides a basic storage configuration for your platform. By default, both Docker and Kubernetes provide local (to the node) storage only, and if cluster-wide persistent storage is desired we recommend implementing it at the infrastructure level (for example, via NFS).


In order to access the UI and API, and for the Portainer Server instance and the Portainer Agents to communicate, certain ports need to be accessible. The Portainer Server listens on port 9443 for the UI and API (or on 30779 for Kubernetes with NodePort) and exposes a TCP tunnel server on port 8000 (this second port is optional and only required if using Edge Compute features with Edge Agents). The Portainer Agents listen on port 9001 (or 30778 for Kubernetes with NodePort).

All ports can be changed during installation.

Let's start
Copied Content