Replies: 2 comments
-
|
For the vast majority of my projects, I just use local state, and I check it in with git. I use environment variables for all my providers so critical credentials don't get stored. Git provides a level of backup with versioning, and then it's also backed up when I push to my server. I do work on multiple machines, so making sure I'm current when I switch is just a git pull away. I recently migrated to a self-hosted GitLab server and have been experimenting with GitLab-managed remote state with good success. It's part of GitLab's CI/CD feature suite (which I don't use), but was reasonably easy to set up. Like local state, it gets stored and versioned in the repo with my code, but it's also encrypted on disk and then further secured behind GitLab's authentication and permission system. I do use S3/Dynamo remote state for my AWS projects, but for my local Proxmox projects, remote state seems kind of extraneous. |
Beta Was this translation helpful? Give feedback.
-
|
I wasn't aware of that functionality in gitlab thank you. Although I have a very old local copy of gitlab running, I don't think I want to go in that direction. I'm also keen to keep the terraform state with secrets on site. I'm putting the terraform into a public repo (e.g. uptime kuma ), but not the seed passwords. Is anyone writing/implemented a small terraform state provider that plugs into the proxmox API? -- |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
How are people using the
bgp/proxmoxprovider storing terraform state?Given that I am using Proxmox as my self hosted 'cloud', I want to be able to store my deployment state in the Proxmox ecosystem. If I am provisioning infrastructure into AWS (or Azure, GCP, ...) I always setup state management with locking early on in the project. This is important for storing state so I don't have a pet machine with that state as a single point of failure. It also allows automated deployment.
I don't really want to create/move that single point of failure somewhere else. Provisioning another service (e.g. an S3 service, or a database service) just means I then have to store the terraform state for that service (a bit of a chicken an egg situation).
It would be good if the Proxmox Cluster File System (pmxcfs) could be leveraged for this purpose.
Any ideas out there? Has anyone created a http based definition to bridge the gap?
--
Beta Was this translation helpful? Give feedback.
All reactions