Deploy Rancher in your desired Kubernetes distribution
Explore the docs »
Report Bug
·
Request Feature
Table of Contents
This repository comprises reusable terraform modules to deploy Rancher, a complete software stack for teams adopting containers, on a Kubernetes cluster provisioned in any of the infrastructure/cloud platforms(AWS/VMware/Azure/GCP/DigitalOcean). Provisioning can be customized using different Kubernetes distributions(RKE/RKE2/K3S/EKS/AKS/GKE) and will be here by referred to as recipes. We can deploy upstream Kubernetes (cluster used only for running Rancher), deploy Rancher and Downstream Kubernetes (cluster used for workloads) using these terraform modules by stitching together various recipes.
Most of the codebase is using HCL(Hashicorp Configuration Language) and some portion is using cloud-init and bash scripts.
To get started you can clone the git repository to a desired location in your local or remote computer.
git clone [email protected]:rancherlabs/tf-rancher-up.git
Git should be installed on the local or remote computer which is used for cloning the repository as mentioned above. Git comes installed by default on most Mac and Linux machines . Please refer the git installation guide here if you need help.
Git clone can be performed only after setting up the required ssh keys. Please refer here if you need help on this.
Terraform should be installed on your local or remote computer where the repository is cloned. Please refer here for installation instructions.
Once you clone the repository please go to the desired recipes path and start configuring required environmental variables for your platform. Please refer the README under recipes for details about how to start provisioning.
- Add support for RKE2 and K3S
- Add support for DO as infrastructure provider
- Option to deploy Rancher Prime
See the open issues for a full list of proposed features (and known issues).
Check out this file for all the information about how you can contribute to this project.
-
Ensure the new names chosen for the variables follow the pattern found in existing modules.
-
No abbreviated variable names.
Example: tkt vs ticket, ct vs count.
-
Use native Terraform functionality as much as possible.
-
Avoid usage of heavy logic in shell scripts outside of Terraform resources.
-
Use of
null_resources
Tf resource as a last resort, and that too with minimal functionality/logic. -
Use of proper/sane defaults for all the variables.
-
Add validation for variables if possible.
See the example of the Regions.
- Any Recipe should run with just 1) terraform init 2) terraform apply 3) terraform destroy.
Justify the opposite if necessary.
Providing just the Cloud credentials.
-
The Recipe should itself be runnable as a Module.
-
No hard-coded values anywhere in the code. Any value used should be via a variable only.
-
All configurable values from the modules should be exposed via Recipe.
Almost a copy-paste of variables.tf from Module to Recipe.
-
Ensure any timeouts available are exposed via config variables.
-
Ensure the code is generic enough that it's reusable elsewhere.
- Add tests where possible with various use cases.
See existing modules.
- Ensure they run in the Pipeline.