Is this code meant to be used in production?

[josh-padnick]

Yes, the modules are all production-grade, but the root example is meant primarily as an example. Per the discussion on Twitter, if you'd like to use this code in production:

1. First get the example up and running to get a feel for things.
2. Then carefully review the example code to see which aspects don't make sense for production (e.g. we strongly recommend you build your own AMI for your deployment, rather than using ours).
3. Then carefully review the variables.tf file for any modules you call to understand which vars you are and are not using.
4. Deploy in prod and profit.

I'm opening this issue to document this clarification and to signal that we should consider adding this to the official docs.

[davidham]

@josh-padnick thanks for the reply! Maybe also consider deploying the modules on the registry as top-level citizens, and moving the root examples to a separate *-example module? This way, you could have the variable definitions right on the registry page, and end users could use the versions from the registry right from that page.

The modules are super helpful once you figure out kind of how the registry works, but anything you can do to make the registry more consumable will make it better still.

[josh-padnick]

@davidham I think that's valid feedback. To be clear, we, Gruntwork, are responsible for maintaining all the Consul, Nomad, and Vault modules for AWS, Google Cloud, and Azure, but HashiCorp is responsible for updating the registry itself.

HashiCorp has publicly expressed an intention to expose the idea of "submodules" in the registry UI in a first-class way, so hopefully that will land soon!