Skip to content

Pre-requisites

Software

  • kubectl to apply resources to your cluster.
  • sops for secrets management. age is a nice addition if you want to use AGE keys to encrypt secrets (recommended).
  • kustomize for aggregating and adapting resources. kubectl includes kustomize (kustomize subcommand and -k option) but it only allows running KRM functions as docker containers. This creates an impractical dependency on docker. This is why we use the Exec KRM functions model. To use it, however, the kustomize standalone binary is required.
  • krmfnbuiltin is a swiss army knife KRM function allowing us to perform structural modifications to the resources of the environment. Think of it as sed, but for Kubernetes resources. Also knows how to decrypt sops encrypted KRM resources.
  • Kubeconform performs validation of Kubernetes resources. It is useful to check kustomization output.

Todo

Provide already configured environments:

  • Docker container (can be argocd custom image. age is missing)
  • WSL distribution (can be derived from the docker image)
  • LXC root filesystem

Online git provider account

Autocloud is hosted on GitHub and currently uses the following features:

  • OAuth Apps to provide authentication to the Argo CD Web UI.
  • Webhook to trigger cluster update immediately.
  • Deployment keys to allow repository read-only restricted access for Argo CD.

Gitlab provides the same features and can probably be used as well.

Gittea support

Supporting Air gapped developments with a cluster hosted Gittea server is planned.

Kubernetes cluster

To deploy autocloud, you need a Kubernetes cluster. Autocloud is originally used and tested with a vanilla Kubernetes cluster created with kubeadm, running on an Alpine based VM or WSL2 distribution. The deployment of such a cluster is made easy by using the iknite package. On Windows, kaweezle makes this deployment even easier.

In such mono-node deployment configuration, autocloud provides an uninode kustomization and Argo CD application providing basic configuration (CNI, storage, metrics, Load Balancer).

Most lightweight developer oriented Kubernetes distribution like Kind, K3s, MicorK8s or Rancher Desktop as well as all managed clusters already provide such services. Fortunately, autocloud provides an easy way to deactivate uninode.

Note

In this documentation, we will use K3s, that seems to be currently the most popular solution as an example.

Cloud provider account(s)

If you want to get the most out of Autocloud, You will need at least the following:

  • A registered domain name. Make sure that your domain name provider has an API that is known to External DNS and Cert-Manager. OVH, for instance, offers domain names for 1,99€ (without VAT) on its .ovh TLD. Cloudflare promises no markup on their end. With them a .com is less that 10$ a year.
  • To be able to run Autocloud behind a firewall as if it was running in a cloud provider, a tunnelling solution is needed. Cloudflare has a free tier on its tunnel offering that you can use with a domain that has been registered with them. Tailscale also offers a free tier. inlets and ngrok are not cheap. We provide simple Open Source solutions (sish, chisel) if the case that you can deploy software somewhere in the cloud.
  • S3 compatible storage. While you can use Minio, external storage is useful for backups and shared storage. Cloudflare as a free tier for starters and doesn't charge for egress traffic. There are too other numerous solutions to list. Nowadays, everyonec is S3 compatible.

Note

In this documentation, we will use Cloudflare as it provides the three components above. This is not a recommendation. Furthermore, autocloud provides kustomizations for some of the other providers (OVH, for instance).

IDE Integration

Autocloud provides helpful additions if you are using Visual Studio Code as your IDE:

  • Plugins recommendations.
  • Tasks (see .vscode/tasks.json).

Once you have all these elements, proceed to the GitOps setup.