Share registry setup as infrastructure as code

[virtualroot]

Description of the feature you are looking for.

It's impossible to help as a collaborator with some issues as the setup isn't shared and can't be reproduced.

Are there plans to share the setup as IaC?

[virtualroot]

As an example, #168, is labeled as a good first issue. but I find it difficult to do since IaC is missing.

[Yantrio]

Right now we've set things up manually (Mainly because it was super easy to set up an r2 bucket fronted by a url in cloudflare).

But I do think you're right, we should generate some IaC for this so that others can reproduce it and host their own registry easily.

[ghost]

I think we might need to document how to run the registry generation manually first.

[virtualroot]

I think we might need to document how to run the registry generation manually first.

@janosdebugs I have been able to run it myself by digging into the GitHub workflows.

$ go run ./cmd/generate-v1 --destination ../generated

I made a small HTTPS server for local testing. I created local certificates with mkcert.

$ mkcert -install
$ mkcert localhost
$ go run ./cmd/registry-e2e/ -certificate cmd/registry-e2e/localhost.pem -key cmd/registry-e2e/localhost-key.pem

This was good enough for fetching providers and modules.
If this is of help, I can create a pull request.

[flickerfly]

I think @virtualroot's point that the first need is documentation is well founded. I expect there are a number of different environments this would get deployed into so there isn't a "one size fits all" standard for the code. Also, in order to support and simplify this documentation, I also think having clear versioned releases would be important. This way the deployment documentation can assume the release process. Maybe that's less a thing in a Go project, but I also think us more "Operations" type guys will benefit from familiarity.

Also, I'm looking at this from an air-gapped environment perspective, I would appreciate having a strong ability to host a registry inside my disconnected environments that can be updated easily. A clearly versioned release is easier to ingress than a codebase.

I'd be happy to see this as a containerized application and some kubernetes manifests as a starting point. If that documentation and a versioned release existed, that is even the sort of thing I'd happily write a PR around or run as a separate project if that would be preferred.

[ghost]

@flickerfly the current registry is not designed to be reusable as it is hardwired to use GitHub as a source. Also, there won't be a container manifest because the registry doesn't have a server component, it relies entirely on static generated data and a server (Cloudflare R2 in our case) to serve it.

[flickerfly]

Gotcha, so no matter what, I'd need to wrap what is "registry" in my own nginx container, download the required artifacts or something like that to self-host/airgap it. Is that a correct understanding?

[ghost]

@flickerfly no, the registry is merely an index of the releases available from GitHub, we don't host the release binaries or modules. For an airgap you will need to mirror the release binaries/module repos too. The OpenTorfu registry is entirely unsuitable for that. I would look into the large number of self-hosted Terraform/OpenTofu registries out there instead. I believe GitLab has one, but I'm not sure.

[flickerfly]

@janosdebugs Thank you for taking the time to correct. I use the GitLab one now, but I'm interested in something light-weight outside a development environment. I'll poke around elsewhere!

[virtualroot]

@flickerfly have a look here https://github.com/virtualroot/awesome-opentofu?tab=readme-ov-file#registry. One of those should fit your use case. 🤞