I’m happy to announce that the alpha release of Amlen 1.1.0 is now available. The main focus of the release is the addition of an Ansible based operator. This is our first foray into the world of operators so if you spot something that you think is crazy let us know as it could just be we didn’t know any better.
As with all alphas this isn’t ready for production, there are likely to be bugs and rough edges which we welcome your feedback on sanding them down.
Why?
The most obvious question is why use the operator? What benefit do you get? It allows you to quickly and easily get an Amlen system up and running. Whilst getting a stand alone Amlen server running is easy, when it comes to aspects like High Availability and adding LDAP capabilities things can be a little more tricky.
With the operator if you want High Availability you just add the HA definition and it does the hard work for you. If you want an LDAP server created and configured you add an ldap definition and it creates the server and configures Amlen to use it.
Not only is it easier to create your system it allows you to update it. Updating a High Availability system can be tricky, you need to ensure that you aren’t updating the wrong server at the wrong time causing outages. The operator monitors the health of the servers in the High Availability pair and only updates one when it believes it is safe to do so.
How?
The first step to using an operator is to install the operator. This can be tricky and something that needs improvements. The safest way to do it is directly from the source code. Inside the operator directory is a Makefile and deploying it should be as simple as setting the operator img and using Make:
export IMG=quay.io/amlen/operator:1.1.x ; make deploy
Alternatively there is a yaml file in the eclipse download area called amlen-operator.yaml which can be downloaded via wget and applyed directly. This is created during the build process and may be able to be applied directly or it may need customizing depending on you kubernetes setup:
wget https://download.eclipse.org/amlen/snapshots/1.1.x/20220704-2130_eclipsecentos7/centos7/amlen-operator.yaml
oc apply -f amlen-operator.yaml
Finally there is an operator bundle, this is produced by the build and available on quay.io. However, it has not been tested so should be treated as very experimental. Adding the bundle to operator.hub is a possibility we could investigate if people want that.
Once you have the operator the next step is how to create an Amlen system in Kubernetes. There are some sample yaml files that can be used to get running. However, the first thing you need is cert-manager, this is used for creating the certificates used for configuring HA pair communication and can be used for connecting devices using TLS. Testing has been done with version 1.8.0 of cert manager which can be applied via:
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.8.0/cert-manager.yaml
Once cert-manager is running (which can take a few minutes) you can create your certificate issuer. The samples include selfsigned.yaml for creating self signed certificates. You can also use the ca-cert.yaml that uses the selfsigned issuer to create a certificate for use in ca-issuer.yaml
Then there are a couple of optional features that you might want to use. If deploying an LDAP server then you are going to need an configuration for it. In the samples directory there is config-ldap.yaml that is compatible with Amlen.
There is a default configuration for Amlen used but you may want to use a custom configuration. For example if using LDAP then you will want to turn on password authentication in the securityProfile. The config.yaml in samples requires the use of certificates.
Finally, the operator will create a random admin password for each Amlen system it creates. If you want to set it to a specific value then you need to create a secret upfront. simple_password.yaml gives an example of this. Note that the password is for a specific Amlen system so if you deploy multiple systems and want them all to use the same password then you will need to have one secret per system.
Finally you need to create the Custom Resource Definition (CRD) that instructs the operator what to do. Again in the samples directory we have an example of amlen_v1_amlen.yaml but we will go through it in a bit more detail here.
apiVersion: amlen.com/v1alpha1
kind: Amlen
metadata:
name: amlen-sample
spec:
size: 2
ha:
cert_issuer:
name: "amlen-selfsigned-issuer"
enabled: true
device_cert_issuer:
mode: "automatic"
name: "amlen-selfsigned-issuer"
config: "amlen-config"
ldap:
cert_issuer:
name: "amlen-selfsigned-issuer"
enabled: true
Size refers to the number of Amlen systems that should be created, so in this case as ha is also defined it will create 2 ha pairs (so 4 servers in total) it needs the name of the certificate issuer.
We have said that the operator should create device certificates and configure the system to use them. If the mode is set to manual then certificates need to be provided in a secret.
We have specified that we are using a custom config called amlen-config (that must exist in the same namespace that we are deploying into) and it will deploy and configure an LDAP server. Note that both ha pairs will be configured to use the single LDAP server.
Once you have a running deployment there will be a number of services that are created which will need to be exposed, the most important is the MQTT service for allowing devices to connect via MQTT. There will be a service per Amlen system. There are also services for admin connections to each node that you may want to expose to allow remote access to various settings.
Where?
This has all been developed using CodeReady Containers, which is a development tool for creating an Openshift cluster on a single server. Part of the purpose for the Alpha is to allow people to take it and run it on different environments. There are various guides for getting started with CodeReady Containers if you want to try this out in a sandbox style rather than on established clusters.
Next?
There are a number of limitations that we want to remove before the 1.1.0 release, the primary one being that at the moment changing the admin password of the systems will not work. From a security point of view that is not acceptable for the 1.1.0 release, it is possible to manually change the password but will cause outages and could go very wrong.
Other limitations will remain, for example reducing the number of systems by decreasing the “size” variable does not cleanup the deployments. Once LDAP is configured turning off the option does not de-configure anything, so again manual cleanup is needed along with manual configuration changes. In future releases these may be improved, but for version 1.1.0 there is no plan to remove them.
Having an option to deploy and configure a WebUI alone with the Amlen systems is desirable but may not feature in 1.1.0
Have Feedback?
If you find a problem either because something has gone wrong or you can’t work out how to do something then you can open an issue at:
https://github.com/eclipse/amlen/issues
You can also post any feedback in the forum:
https://www.eclipse.org/forums/index.php/f/572/
or you can chat on slack, the link is available at:
https://www.eclipse.org/amlen/