Helm Chart

Hi. I’m wondering if anyone’s built a Helm Chart for Mender? I’d like to deploy it to a Kubernetes cluster that I manage using Rancher and helm charts make the process simpler and more reliable.

Thanks, Andrew.

Hi @ASwingler and welcome to Mender Hub.

We do not provide any helm charts for kubernetes and hopefully someone in the community is able to share something.

If you end up doing it on your own, I am sure that it would be appreciated if you are able to share the results.

Is there any activity on this topic? Does anyone worked on a helm chart already to built upon?

Hi @michafn,

Unfortunately I am not aware of any updates on this topic.

This is a bit frustrating. I’d love to work on a helmchart, but not even the kuberntes setup guide with kompose works. Went through it now several times and the mender inventory and some other pods just do not find the mongo service. Is there any interest from mender team to support here? I guess it would be quite a benefit to have proper helm chart for mender, no?

after hours of debugging we are at least one step further and get the services etc. up. However it fails now here:
https://github.com/mendersoftware/go-lib-micro/blob/master/mongo/migrate/migrator_simple.go line 87.

with msg:

failed to run migrations: failed to apply migrations: db needs migration: inventory has version 0.0.0, needs version 0.1.0`

now this does not make to much sense IMHO and we don’t know how and where the version is gathered. Any ideas?

When you run services with empty DB for a first time you need to ‘initialise’ DBs for all services. To do this you need to run each service with migrate option. I would suggest to use k8s job for this. For Mender 2.2.0 it will look something like the following:

apiVersion: batch/v1
kind: Job
metadata:
  name: mongo-db-version-init
spec:
  backoffLimit: 5
  activeDeadlineSeconds: 300
  template:
    spec:
      containers:
        - name: mender-deployments-migration
          image: mendersoftware/deployments:1.8.0
          args: ["migrate"]

          envFrom:
          - prefix: DEPLOYMENTS_
            secretRef:
              name: mongodb-common

        - name: mender-device-auth-migration
          image: mendersoftware/deviceauth:2.1.0
          args: ["migrate"]

          envFrom:
          - prefix: DEVICEAUTH_
            secretRef:
              name: mongodb-common

        # etc... for all the rest services

thanks a lot, this resolved this issue at least.
Now we struggle to get the deployment service up and running. As per readme (https://github.com/mendersoftware/deployments) i see that it is essential to use an AWS S3 storage for the deployment. Is this really the case? So in order to run mender it is mandatory to have an AWS storage? This seems weird and I recall that I ran it witouth some time ago. Did this change? I can’t see any S3 config in the docker-compose though. And no proper documentation on the AWS config either.

is there any way to deactivate S3? If not, is there any documentation on where and how to provide the respecitve crendtials?

It’s not possible to ‘deactivate S3’ because some storage is required to store artifacts and for uploading them to clients. Deployments service provides unique download links for each client and clients downloads artifacts directly from storage.

Deployments service does API calls to a storage by S3 API, so, it’s possible to use any S3-compatible storage. In docker compose setup Minio is used as such on-premise storage. So, you can use AWS S3 or install Minio on your k8s cluster from the helm chart.

You can take a look on the following docker compose files to understand which environment variables has to be provided to deployments service:

MINIO_ACCESS_KEY should be equal to DEPLOYMENTS_AWS_AUTH_KEY and MINIO_SECRET_KEY == DEPLOYMENTS_AWS_AUTH_SECRET . DEPLOYMENTS_AWS_URI is publicly available FQDN of Minio server.

The following diagram from the documentation can also be useful for understanding how services interacts.