Every choice is made simpler if you know that you can change your mind.
That is why CNDI is easy to pick up and easy to put down. It is built on top of industry standard tools like Kubernetes and Terraform, all the tools you likely would’ve chosen if you wanted to build everything yourself. This means if you ever decide to eject, you’ll have what you need to manage your cluster afterwards. Let’s dig into how that all works, starting with some information about how CNDI operates.
Every CNDI project begins with a Template which is responsible for creating a number of artifacts.
The first artifact is a file called cndi_config.yaml, and one of our primary
goals is to ensure that if the user has a solid understanding of this file, that
they can succeed with CNDI.
The second artifact is the .env which contains any sensitive information which
must not be uploaded to source control.
As you iterate on your CNDI project, every change will be made to one of these 2 files.
Our tool is designed in this way so that the files and interfaces you interact with are simple and powerful.
This comes at a cost. In order to make the interfaces friendly, we must run a
command to process these 2 files, and convert them into machine readable files.
This command is cndi ow, and its outputs are written to the ./cndi directory
in your project repo.
The files generated by cndi ow are processed by Terraform to provision your infrastructure, and ArgoCD to provision the software to run on that infrastructure.
These files and your environment variables are the only inputs to automation.
This means that if you want to eject from CNDI, you can delete your
cndi_config.yaml file, and edit your Terraform and Kubernetes resources
directly.
To trigger automation as a CNDI user, you simply uploaded these artifacts to
GitHub and the GitHub Workflow we created for you was responsible for delivering
your changes. It did this by calling terraform apply, which would then resolve
all of your updates, including configuring ArgoCD to watch your CNDI Git
Repository for changes to your Kubernetes manifests.
Terraform is not stateless, it maintains a representation of all of the infrastructure it provisions for you, and can be configured to store this representation in a number of places. Popular options include Terraform Cloud and AWS S3.
CNDI manages Terraform state by creating a branch in your Git repository called
_state and updates this branch for you every time Terraform exits, this saves
you the trouble of needing to setup or pay for a state store.
If you are to eject from CNDI you would no longer have this automation, so you would need to migrate your state to a more conventional provider. Configuring a state store would likely take only a couple of hours.
Lastly, if you eject from CNDI and you want to update any of your cluster’s
Kubernetes Secrets, you’ll need to run the kubeseal CLI yourself to generate
your SealedSecret resources.
So, there you have it! You can use CNDI without the fear of getting tied down. In the end our focus is making your life easier and letting you control your own destiny. Cheers to flexibility and freedom, it’s the open source way.
TL;DR - If you want to eject from CNDI:
cndi ow you’ll need to learn about the files it generates. These
files are Kubernetes manifests and Terraform objects.cndi ow you’ll need to “seal” your Kubernetes Secrets by hand with
the kubeseal CLIcndi run automation, you’ll need to modify your GitHub workflow to
call terraform apply directly when changes are pushed to Gitcndi run automation you’ll need to setup a place to store Terraform
state after each terraform apply