The newly released Mender Server 4.0 changes the Helm chart. These changes are meant to streamline the way services are handled, improve security, and fix issues with sub-chart compatibility. We’ve made some important architectural shifts that may impact how you use the chart and configure your deployments. Let's dive into these updates and what they mean for you as a Helm chart user.
Prior to the Mender Server 4.0, there was a separate Git repository for each service. Moving to a monorepo simplifies the development and deployment pipeline, allowing us to manage all services in one place. A direct consequence of this architectural choice is the different usage of the Container Registry; the Enterprise images are now published to registry.mender.io/mender-server-enterprise/ instead of registry.mender.io/mendersoftware/. For example:
When pulling Docker images, the tags are now much simpler. Previously, the image tags had prefixes like mender-3.7.0, but with the monorepo, those prefixes are dropped. Now, the tag is just the version, like v4.0.0. Simpler tag prefixes help reduce confusion and make it clear which version of the overall system you’re running.
When configuring Helm values, make sure to adapt Docker image configurations accordingly to account for the new prefixes.
To update to Mender Server 4.0, follow the New repositories location and the Drop the "mender-" prefix in the tags names sections in the documentation.
Defining shared configurations is a useful option within Helm charts, however, the introduction of sub-charts can create problems.
If you set global.image, that value gets applied to all sub-charts, too. This causes conflicts, especially when using other charts like NATS that might also have a global.image key. Moving away from global.image to default.image can fix this problem with sub-charts
For more information follow the Global section deprecations section in the documentation
Storing passwords directly in the values.yaml file is a bad practice, as plain text isn’t always secure . Previously, you might have used global.image.username and global.image.password to provide authentication for pulling images which store passwords in plain text.
We’re switching to default.imagePullSecrets, which allows you to configure Kubernetes secrets for authentication, keeping your passwords secure and away from prying eyes.
Instead of using cleartext passwords, configure your imagePullSecrets and reference those in your values.yaml. Leveraging secrets ensures that your sensitive data is handled securely without sacrificing functionality. Configuring imagePullSecrets is valid only for Enterprise users with active credentials to the Mender Enterprise Registry.
The ImagePullSecrets instead cleartext credentials section in the documentation provides more information
To enhance security, we’ve rebuilt the GUI container to run as a rootless container. As a result, the web application has switched from running on the privileged 80 port to the unprivileged 8090 port.
The rebuilt rootless GUI container ensures enhanced security and follows best practices by not running with root privileges. If your deployment relied on port 80, you’ll need to update your configurations to expose port 8090 instead.
Please make sure to follow the Rootless gui container section in the documentation.
Finally, we’ve added a nice quality of life (QoL) improvement regarding service key generation. Following this change, if you don’t specify a Deviceauth and Useradm keys in the values.yaml, the Helm chart will automatically generate one for you.
You no longer need to worry about providing a service key every time you access the Helm chart. The Helm chart will automatically handle it for you. Of course, if you want to use your own key, you can still specify it as usual, this change simply reduces manual configuration and helps prevent errors from missing or misconfigured keys
Without the storage proxy feature, you’ll end up with two different endpoints. For example, the Mender Server and the Artifacts storage have
https://mender.example.com and https://my-mender-artifacts.s3.amazonaws.com as endpoints.
With the storage proxy enabled, your endpoints will be https://mender.example.com and https://mender.example.com/my-mender-artifacts for the Mender Server and the Artifacts storage, respectively. This storage proxy change is a QoL enhancement so it is enabled by default.
Just specify your domain and your artifacts storage name, and the Mender Server v4.0 will work as a storage proxy for you.
Follow the Storage Proxy enabled by default section in the documentation.
For open source plans, NATS and MongoDB services are now enabled by default in the Mender Helm chart as a subchart in Mender Server 4.0. For Enterprise plans, Redis is also included and enabled, and the open source setup is disabled by default.
The default setup is open source. Please follow the NATS and MongoDB subcharts enabled by default, the Redis subchart disabled by default, and the Enterprise false by default sections in the documentation.
The updates to Mender Helm charts aim to provide a better experience using Mender. By switching to a monorepo, fixing issues with the global key, enhancing security through secrets and rootless containers, and introducing auto-generated service keys, the Mender Helm chart feature is future-proof, secure, and user friendly.
For complete upgrade documentation, visit the official documentation page.
We appreciate your general feedback on Mender, be it positive or needing improvement, in the Mender Hub General Discussions forum. Your continued feedback ensures Mender will meet your needs even better in the future!
If you believe you have encountered a bug, please submit your report in the Mender JIRA issue tracker.
We hope you enjoy the new features and look forward to hearing from you!