With the announcement of the launch of Portainer CE 2.0 on the 31st August, I‘d like to provide additional context on our thinking behind this release, the value we hope it will bring, the target audience, and what you can expect to see from it, features-wise.
Portainer CE 2.0 includes a staggering number of enhancements (~150), as well as a few breaking changes. Before you upgrade, you need to understand the changes in order to decide if 2.0 is right for you.
We have purposely decided to release CE 2.0 as an entirely new image to ensure there are no auto-updaters (like watchtower) that will expose users to risks by automatically updating on release. The new image will be portainer/portainer-ce. The first tag will be :2.0 and we will also use :latest as a tag pointing to the latest release.
Portainer 1.24.x will continue as a separate code branch, released as portainer/portainer:latest, and will receive ongoing security updates until at least 1st Sept 2021. No new features will be added beyond what was available in 1.24.1.
For two reasons we have removed the concept of “extensions” from 2.0 completely. First, we have been criticized for having closed source features as part of the open source project, and so by removing them Portainer CE reverts back to being 100% open source. Second, we have learned that to be successful, extensions need to be delivered as part of a supported solution. Whilst extensions provided al-carte functionality, users really need (and indeed expect) support using them.
Moving forward, we will contain all of our proprietary functionality in a specific commercial version of Portainer called Portainer Business, which will come with full support. Existing extension customers should look out for specific communications about the transition.
As part of removing extensions, we have elected to roll basic oAUTH authentication support into CE, so now you can configure Portainer to authenticate users from an oAUTH source. Be aware, this is a very technical implementation, so you need to be competent with oAUTH before attempting it. The Business Edition will retain ‘click to configure’ simplicity for the most common oAUTH providers like Azure AD, GitHub, Google.
Off the back of our intention to remove the ability to disable Portainer internal authentication, we have added support for the Admin to set a custom “session timeout’. This setting defines how often users are forced to re-authenticate with their Portainer session; the default remains at 8 hours, but it can now be changed to up to 1 year. So, whilst we are not disabling authentication completely, we are trying to make the required authentication invisible for those that don’t care for it.
We’ve also changed the way we handle application templates. Previously we let admins/users customize the application template list, and we provided a rudimentary UX to add/remove applications to the template list. Moving forward, we have changed this behavior. Now, the list of application templates is published by Portainer, maintained and updated by Portainer, and users can’t change it. Admins can choose to unsubscribe from the list and instead provide their own centrally managed list, but it would be “consume only” from a user perspective.
In addition, we have elected to provide a feature called “custom templates” which is where Portainer users can create their own bespoke templates. Unlike previous capability, the new custom templates rely solely upon Stack/Compose files, so when you add a new template, you add it by pasting in (or uploading) a compose file and then annotating some detail around the file. Through Portainer access control, users can choose to publish their custom templates for themselves, for their team, or for all users within their organization.
One other cool addition to the custom templates is the ability to create one from a running stack... simply open a stack and click on the button “create template from stack” and voila, you have a reusable custom template.
This new method of managing application templates means there is a new schema, so any custom template files created for Portainer 1.x will need to be updated to accommodate Portainer 2.0. We have provided a tool to assist with this conversion (https://github.com/portainer/helper-templates).
Speaking of stacks, we have added the ability to stop a stack; this is a Portainer specific feature, and takes all services/containers offline, whilst retaining the configurations required to restart the stack within the Portainer DB should the need arise (simply click the “start stack” button). This is a neat feature that lets you centralize all of your stacks in one place, and control which run, and when.
Looking beyond Docker; we have further matured our support for Azure ACI. You can now reliably deploy applications in an Azure ACI instance from within Portainer. These containers are all stateless, and internet facing. It takes mere seconds to deploy any container in ACI with Portainer, which is very cool.
Regarding Edge Compute; we have relocated the former “Host Jobs” functionality into “Edge Jobs” and reconfigured the logic that underpins this so that they only function when used against Edge Agent enabled endpoints. This now means that the “Edge Compute” specific features includes; the ability to group edge endpoints, the ability to deploy stacks against groups of endpoints, and the ability to run cron jobs against edge endpoints.
And finally, the biggest change of all, Kubernetes.
We have introduced support for Kubernetes enabled endpoints as part of Portainer CE 2.0,. This means you can manage the deployment of applications atop Kubernetes clusters from within Portainer, using the familiar Portainer UX. We have safely abstracted as much of the unnecessary Kubernetes lingo as possible, leaving a clean UI that allows you to deploy/manage/monitor applications in Kubernetes without needing to know all that much about Kubernetes. We negate the need for you to learn YAML and how to write Kubernetes Manifests, we negate the need for you to learn all of the Kubernetes deployment “rules” and constraints, and when to use which deployment mode for what, and we negate the need for you to learn any of the Kube CLI commands.
It’s important to note, we’re not saying that organizations can fully embrace Kubernetes without having any technical insight into how Kubernetes works (as that’s just crazy talk). Like everything in the IT space, the more you know, generally the better off you are. What we are saying however is that with Portainer, not EVERYONE in your IT/Dev team needs to understand Kubernetes to the same degree. There will be some on the team that naturally gravitate to Kube and its infinite flexibility, but equally there will be some on the team that “just want to deploy an app”… Portainer has always been targeted at those that “just want it to work”… and that continues to ring true as we release Portainer CE 2.0.
So, what can you do in Portainer against Kubernetes; well, there is so much, a list is going to be easier to digest...
As an Administrator, you can:
- Define what cluster resources users have access to (eg persistent storage, load balancers, ingress, metrics)
- Create Resource Pools (Kubernetes namespaces) for users to deploy their apps within
- Assign CPU and RAM quota to resource pools
- Assign Ingresses to Resource Pools
- Assign permissions to Resource Pools, so only authorized users can access corresponding resource pools
- See the status and component health of the Kubernetes Cluster
- See the leader status, and which nodes are API endpoint enabled
- See Cluster Events
- See the Cluster resources assigned vs total
- See the Node resources assigned vs total
- Add Node Labels
- Add Node Taints
- See which applications are running on each node
- See and manage all applications deployed across the cluster
- See and manage all configs/secrets defined in the cluster
- See and manage all persistent volumes defined in the cluster
- Deploy applications by directly inputting a Kubernetes Manifest
- Deploy applications using the simplified UX
- See which users deployed which applications and when
As a User, you can:
- Deploy applications in the resource pools you are entitled
- Assign CPU and RAM reservations for applications up to your quota
- Add environment variables to your applications
- Create and Manage Configurations and Secrets for your applications
- Assign Persistent Storage to applications, if enabled by your administrator
- Assign Ingress or Load Balancers to applications, if enabled by your administrator
- Deploy either replicated or global applications
- Deploy one or more replica of an application
- Enable auto-scaling for an application if enabled by your administrator
- Assign placement rules for an application
- Publish an application either internally, across the cluster, or via Ingress/Load Balancers if enabled by your administrator
- See the logs of the Application components (PODs)
- Open a console of each application component (PODs)
- See the effective placement results (which nodes can the application run on)
- See the application events
- See the application resultant manifest
- See the resulting application deployment type (deployment, daemonset, etc)
- Edit and application and adjust any prior setting
- Roll back an application to the last version
- Redeploy an application
- Combine applications into logical groups, called Stacks, for simplified management
- Add annotations for applications to help other users understand the purpose and owner of the application
One final word; in Portainer CE 2.0, we made a change to how we collect anonymous usage data; prior versions leveraged Google Analytics, which was often criticized, and so in 2.0, we have moved to Matomo Analytics, which is hosted in Germany and fully GDPR compliant.
When Portainer first starts, you will be given the option to DISABLE analytics. If you don’t choose to disable it, Portainer will continue to collect anonymous usage as per our privacy policy. We need this basic telemetry to know which features of Portainer are in most demand, and it is the only mechanism we have in order to focus development efforts. Note that there is no personally identifiable information sent or stored at any time.
We are really looking forward to user feedback on Portainer CE 2.0, and can’t wait for you all to get your hands on it.
Neil
COMMENTS