Open ljupcovangelski opened 2 years ago
Decoupling the Airy CLI from Kubernetes means that the process of installing Airy are separated from applying the configuration and interacting with the API.
For installing the Airy helm chart, access to Kubernetes is mandatory (otherwise the Kubernetes resources cannot be deployed). Therefore, I propose that we also decouple this process from the CLI altogether. I propose that airy create
only initializes the workspace and prints out next steps which the user should execute on his own
, in order to install Airy Core on a new or on an existing Kubernetes cluster.
airy create --provider minikube
:
airy create --provider aws
:
airy.tfvars
airy create --provider generic
(or generic/kubernetes/existing, this should be the default option):
[^1]: Command for creating a Minikue cluster: minikube --profile=airy-core start --extra-config=apiserver.service-node-port-range=1-65535 --ports=80:80 --driver=docker --container-runtime=containerd --cpus=4 --memory=7168
[^2]: Commands for deploying Airy Core with Helm: helm repo add airy https://helm.airy.co helm install airy airy/airy --namespace default --values ./airy.yaml
[^3]: Commands to create Airy with Terraform: terraform init terraform apply
I think this is a good solution but I would like to hear what the product team has to say. This looks like a question for them.
This is the way to go. One small DX improvement might be to just output a ./up.sh
script or something for minikube.
By decoupling the Airy CLI from Kubernetes, we cannot directly run
helm install
orhelm upgrade
.We should run these jobs from the
airy-controller
or use thehelm
binary directly.Depends on #2754