i'm not a devops engineer. i appreciate any critique or correction.
Managing Proxmox VE via Terraform and GitOps
This program enables a declarative, IaC method of provisioning multiple resources in a Proxmox Virtual Environment.
Deployment
-
Go to the GitLab Project/Repository > Settings > CI/CD > Runner > Create project runner, mark Run untagged jobs and click Create runner.
-
On Step 1, copy the runner authentication token, store it somewhere and click View runners.
-
On the PVE Web UI, right-click on the target Proxmox node and click Shell.
-
Execute this command in the PVE shell.
bash <(curl -s https://gitlab.com/joevizcara/terraform-proxmox/-/raw/master/prep.sh)
[!CAUTION] The content of this shell script can be examined before executing it. It can be executed on a virtualized Proxmox VE to observe what it does. It will create a privileged PAM user to authenticate via an API token. It creates a small LXC environment for GitLab Runner to manage the Proxmox resources. Because of the API limitations between the Terraform provider and PVE, it will necessitate to add the SSH public key from the LXC to the authorized keys of the PVE node to write the cloud-init configuration YAML files to the local Snippets datastore. It will also add a few more data types that can be accepeted in the local datastore (e.g. Snippets, Import). Consider enabling two-factor authentication on GitLab if this is to be applied on a real environment.
- Go to GitLab Project/Repository > Settings > CI/CD > Variables > Add variable:
Key: PM_API_TOKEN_SECRET
Value: the token secret value from credentials.txt
- If this repository is cloned locally, adjust the values of the .tf files to conform with the PVE onto which this will be deployed.
[!NOTE] The Terraform provider resgistry is bpg/proxmox for reference.
git pushsignals will trigger the GitLab Runner and will apply the infrastructure changes.
-
If the first job stage succeeded, go to GitLab Project/Repository > Build > Jobs and click Run ▶️ button of the apply infra job.
-
If the second job stage succeeded, go to the PVE WUI to start the new VMs to test or configure.
[!NOTE] To configure the VMs, go to PVE WUI and right-click the gitlab-runner LXC and click Console. The GitLab Runner LXC credentials are in the credentials.txt. Inside the console, do
ssh k3s@<ip-address-of-the-VM>. They can be converted into Templates, converted into an HA cluster, etc. The IP addresses are declared in variables.tf.
Diagramme
Please do not normalize running scripts directly from websites.
As much as I agree, I think we're past the point of preventing normalization.
Agreed. Just point them to the repository. Cloning the repo and running the script is the barrier to entry here. If they can’t do that then reading it would do them no good either which means they have some learning to do.
i agree. they should be run in a confined env first
No - you shouldn't be putting
bash <(curl ...)into a post and telling people to run it at all. It's bad and shouldn't be normalized in any way. Take. It. Down.Especially dangerous because the script can change. So this stays up, gets indexed and put in the search results for people looking to do this... And then poof suddenly the script is an info stealer.
Might not even be the original poster doing this, maybe their account gets hacked and the link gets every so slightly edited.
Just bad practice.
Though I must admit I do use proxmox helper scripts... But at least that's a somewhat trusted repo.
100% this - at the very least do a
curl URL | lessto inspect the script before piping it to bash, or better yet download it, review it thoroghly, then run it locally.