Standalone RKE2 Terraform Module

[caroline-suse-rancher]

Issue to track the development of a standalone RKE2 Terraform module.

Related Jira ticket: https://jira.suse.com/browse/SURE-6115

Please create subtasks as necessary.

[matttrach]

picking this up today

[matttrach]

• new module repos:
  • https://github.com/rancher/terraform-github-rke2-install
  • https://github.com/rancher/terraform-aws-server
  • https://github.com/rancher/terraform-aws-access
  • https://github.com/rancher/terraform-kubernetes-rke2
  • https://github.com/rancher/terraform-aws-rke2
  • https://github.com/rancher/terraform-harvester-rke2
  • https://github.com/k3s-io/terraform-kubernetes-k3s
  • https://github.com/k3s-io/terraform-aws-k3s
  • https://github.com/k3s-io/terraform-harvester-k3s

[matttrach]

I have fully tested modules ready for these:

• https://github.com/rancher/terraform-aws-server
• https://github.com/rancher/terraform-aws-access

I am working on https://github.com/rancher/terraform-github-rke2-install

[matttrach]

I don't like the name for "terraform-github-rke2-install", and I have a feeling I am going to need a config module that generates the rke2 config before install. I will need a way to automatically keep something like that up to date with the rke2 arguments.

[matttrach]

Basic tests are currently passing on the install module, which depends on the other modules (meaning that the other modules are working). This is only the most basic use case (single server, all roles, empty config).
My current direction is to get this into a place where changes are automatically tested and versions can be published to the Terraform registry.
Once the groundwork for CI and publishing is complete I intend to expand the use cases, first to multiple servers then to servers with different roles/configs.

[matttrach]

I decided, from internal feedback, that the download module did not make sense as a sub-module in the install module. I am instead moving it to its own module so that it can be composed or left out as desired.
This requires a major change on the install module, renaming it from the terraform-github-rke2-install module to the terraform-null-rke2-install module because the primary provider is now the Hashicorp "null" provider. This will effect both the name of the repo and the name of the module in the terraform registry.
The new registry page is: https://registry.terraform.io/modules/rancher/rke2-install/null/latest
The new repo is: https://github.com/rancher/terraform-null-rke2-install
I don't anticipate another change of this nature for this repo.
The new "download" module registry page is: https://registry.terraform.io/modules/rancher/rke2-download/github/latest
The new "download" repo is: https://github.com/rancher/terraform-github-rke2-download

[matttrach]

The internal comment detailed the beginnings of a use case:

"AirGapped/Secure Use Case" (still working on the name)

• terraform is installed on a workstation (windows/macOS/linux)
• workstation has no access to servers, but does have access to a cloud provider
• servers have ssh disabled
• all files are downloaded to a drive of some kind and already mounted on the server
  • this means we don't need to download the files
  • this means that the files are not local and copying to the remote server needs to be optional
• the OS for the servers needs to be hardened
• immutable infrastructure is an acceptable paradigm
  • this enables the following workflow:
    • build a server using ssh
    • harden it (including disabling ssh)
    • snapshot it into an image
    • distribute the image
    • deploy image in secure cloud region

[matttrach]

I am also targeting a "basic/generic" use case:

Generic

• terraform is installed on a linux based workstation (or if using something else Nix is installed and flake is used)
• workstation is able to contact GitHub
  • downloads files from GitHub release
• workstation is able to contact cloud (currently we only have AWS support, but Azure is coming)
  • please let us know if you would like another provider!
• workstation is able to contact servers over ssh after deployed
• terraform automates installation following the documentation for a "tarball" install
  • this is the most generic install path since it works for the most different operating systems
• servers are linux based (no windows workers)
• rke2 is using the default or "empty" config

[matttrach]

A specific form of the generic use case is tested by CI:

• terraform is installed on the ubuntu-latest GitHub runner
• special limited access is given to the runner to deploy resources (currently this is generated manually, but a module is planned in the future)
• aws security groups only allow the runner's IP to access the servers after deployed
• the runner generates a secure ssh key to access the servers
• the aws servers are the latest SLES 15 image provided by amazon
• the size of the servers is c5.xlarge with 500GB storage
• ssh access is not enabled for root
• ssh authentication is via key only (no password auth)
  • this means that we generate a new user and give it sudo access
• the image's default user is removed (we don't use ec2-user)
• the config is generated using the config module, but is mostly empty (includes a join token and url)
• the runner downloads the files from the GH release specified
• the runner copies the files to the remote server
• the runner installs the version of rke2 specified
• the runner starts the rke2 service

[matttrach]

I have fully extracted the download module from the install module.
While working on it I have made the remote_copy optional and the download module can now be skipped in the aws-rke2 module.
The aws-rke2 module now has release v0.0.3, which is the experimental release of the "Generic" use case.

[caroline-suse-rancher]

Initial work on this is done and functioning - follow-on work will be tracked in other issues. Thanks Matt!