Otomi is a platform as a service for Kubernetes, well let’s unpack exactly what that breaks down to. For instance in Kubernetes you’re mostly empowered depending on how you configure your cluster by numerous plugins/resources. Depending on how you are hosting your cluster this can be limited to the CSP’s native controls but also can unlock others with plugins. This isn’t a easy task as you’ll need to understand at a high-level some of these concepts.
- Runtime Detection (Falco – Configuration)
- Monitoring (Prometheus – Node Exporter/Configuration, PromQL)
- ArgoCD (GitOps – what and how to provision this and utilize)
- OPA (Gatekeeper – Policy-as-Code for restricting operations)
- Trivy (Image Scanning – SBOM/Etc)
It’s quite easy to become overwhelmed with the configurations and settings depending if you haven’t automated or created your own tailored helm charts and to keep these all up to date is no small feat.
Otomi aims to have these plugins/tools installed out of the box with a UI/UX to help assist developers focus on applications only and not managing a complex kubernetes cluster, for today’s blog post I’m going to explore the capabilities of Otomi in Google Cloud Platform.
Existing Prerequisites (should you want to follow along)
- Kubernetes Cluster (1.24, 1.23) support for newer releases tbd
- Helm
- Node pool (machine) with 6 vCPU/8GB + Ram (minimum – as more is advised from documentation)
- Calico CNI (network policies can also be implemented with other CNI’s)
https://otomi.io/docs/get-started/installation
helm repo add otomi https://otomi.io/otomi-core
helm repo updateExport VERSION=”1.24” #or 1.23 if you are running that
Export CLUSTERNAME=”<cluster-name>”
Export PROVIDER=”google”If you are using something else you’ll have to change “google” to whichever platform use “custom” for on-prem
helm install otomi otomi/otomi \
--set cluster.k8sVersion=$VERSION \ # 1.23 and 1.24 are supported
--set cluster.name=$CLUSTERNAME \
--set cluster.provider=$PROVIDER # use 'azure', 'aws', 'google', 'digitalocean', 'ovh', 'vultr', 'scaleway' or 'custom' for any other cloud or onprem K8sNext we have to have a account at
Portal.otomi.cloud
If you don’t have one go ahead and create one as we will use this for the UI/UX
A blank one should look like the image above with the Register Cluster
You’ll get a license key – ensure you keep this somewhere safe and then you’ll hit connect to cluster, if this takes some time don’t worry.
You’ll also have to ensure you’ll run this command to ensure otomi is up and running given the amount of tools running use this command
kubectl logs jobs/otomi -n default -f
After you click through some of the warnings depending on browser keycloak will populate with the login screen
You then will paste in your activation key that we’ve received from the otomi.portal we got earlier
You can then navigate to the Apps page that will show what is installed from our Otomi platform
We can use Gitea for our Git server we can also navigate to Drone CI for our pipelines let’s open Drone and explore further.
Mind you this will re-direct you to login to Gitea for the server access that will stay in the otomi/values as default if we want to add a repository to trigger a pipeline and move onto that side we can do that as well.
This will show your Gitea repository server and we can add a repository, I’m going to add one just as a test case.
Once created we can also have the quick-guide for the clone repository along with the values to add your files.
Navigating back to our console we can see the values that are listed and can be managed from the portal such as Teams, Policies, Builds and Workloads along with others.
We can also use shortcuts that have useful links along with description of the links listed.
Next we can move to Policies this will house our OPA Gatekeeper policies
I’ve selected the Container Limits this will show the inputs along with the banner to enable Gatekeeper for the policies makes this turn key option for your team to apply.
If we move into the Teams tab we can also manage multiple teams I’ve created a few to demonstrate this area further in a use-case
For the build area we’d have to Tekton and Harbor activated
To build quite easily you can see once these are (activated) you’ll input the docker image or buildpack you’d like to use along with options for Private Repository.
For the Workloads or GitOps out of the box the service will utilize ArgoCD once this activated you’ll see this screen under the Workloads tab.
For the Backups which you should always have backups for your stateful clusters/stateless workloads for production if needed this service utilizes Velero I’ve created a backup to show this area.
For the Settings you can get a more dashboard view of all the services being used along with the configuration.
Think of this as the platform settings configured such as Backups you can select how each service along with Cron-type schedule of the snapshots for the selection of services
Summary
Otomi enables developers to get a out-of-box or what I’ve termed turn-key solution for various services that can get your team up and running without headaches. Additionally, Otomi does have extensive labs to get your team more familiar with the platform while this is the community edition. Every organization will likely face the following long-term questions with the fast paced cloud adoption – avoiding vendor-lock in, this platform provides a agnostic way to enable best practices and address that while still providing capabilities to your developers.
As the term platform engineering and making the developer experience as “self-service” with tools like this the reduced complexity can greatly add value, in terms of what I’d consider for security as always with the use of key-cloak I’d set up various authentication (AuthN/AuthZ) to limit to least privilege, define teams along with utilizing OPA for your teams. If considering multi-tenancy as most organizations are tightening the (sugar rush) of cloud spend this can be addressed with use of tools such as Kiosk / Capsule these will be covered in a future blog.