Terraform Module Registry

Traditinally, you would get four physical servers together and then manually load an operating system onto each one.

With the advent of cloud technology, you can simply go to Amazon or DigitalOcean or whoever and just "create" these resources by paying for space in their data centers. You get four "virtual servers" instead of physical boxes you have to configure yourself.

Terraform essentially lets you "code" and automate the cloud provisioning. Instead of going to a dashboard and ordering four servers, you run a script that describes all of the servers you need as well as their operating system / networking / etc. needs. This scales very well (once you have a config you can replicate it to whatever quantity you require) and also provides consistency and reliability, as well as documentation, of your infrastructure.

Terraform provisions servers and infrastructure based on yaml config files that you can do things like commit to source control and see a diff of changes to your cloud provider. It's really fun but very tied into each specific service providers' nomenclature and services, I wish it was higher level. It provides backends for all the major players but I think there is (was?) some large variation in quality.

Wonderful talk here explaining with real examples: http://www.ybrikman.com/writing/2016/03/31/infrastructure-as...

For the modules that we are publishing for Kubernetes[2] we are actively testing them and appreciated that the publishing process and bug reporting process are tied to GitHub. Between that and the verified modules I think it does add some signals of quality.

Now, don't get me wrong I think the DSL could be more expressive to make modules easier to configure and deploy. I am hopeful the project will get there.

[1] https://registry.terraform.io/browse?verified=true [2] https://registry.terraform.io/search?q=kubernetes

p.s. the registry site seems to be struggling a bit; launch day blues.

In designing the registry, its API, its required module structure, etc. we worked for the past year with ~10 or so large community users, consultancies, partners, and customers. We had a representative from each that was actively involved in the design from the beginning, and they had a really big impact on what the registry ended up being. These are people who've written hundreds of modules, who know the best practices of their clouds, etc. So we hope with this collective knowledge we've built something that was longer than a five minute demo. :) They also had great feedback on various improvements we can/should make to Terraform itself and we are doing a lot of that with TF 0.11.

On the "works or not" topic: we provide verified modules for this reason. Verified modules are not only tested by HashiCorp engineers but also involve an active relationship with the module maintainer to ensure that the modules stay functioning across Terraform updates and cloud updates. These are recognizable with the blue checkmark. We launched with about three dozen of these but I expect community modules to lap this quickly.

At the same time, we don't want to actively disallow or heavily curate what people do with modules. So community members can publish pretty much anything they want on the registry. If you're using a community module, you're definitely taking your own risk and we hope we spell that out in the docs.

We already have plans underway to provide "module scorecards" in a way to help the community further recognize the quality of a module versus simply the blue check mark or no blue check mark binary approach. This design was part of our initial design, but isn't ready for launch.

Going beyond the public registry, we also announced today we'll have a private registry available in Terraform Enterprise. Note that the actual public API of the registry is documented (https://www.terraform.io/docs/registry/api.html) so separate implementations are possible and welcome.

But within our commercial private registry, we will actually track _who_ is using your modules. When you change the public interface to a module (inputs, outputs), we do provide warnings that "you may break X downstream workspaces" and allow you to contact those workspace owners. This isn't something we can easily do with the public registry simply due to the data model and not wanting to have everyone's usage information stored (we don't store or have access to any of that right now nor do we have plans, don't worry). But the private registry will be doing all of that because the application has all that information already from Terraform Enterprise.

And beyond all of this: Terraform 0.11 (due for release late this year and we talked about it during the HashiConf keynote briefly) is bringing along huge improvements to the module system in the core of Terraform which will make it much easier and more robust to work with modules.

Lots of stuff! But I hope this helps answer some of the questions for you and others.

(I'll add an edit since after posting this I saw some of your other comments: we are planning some major changes around HCL, we've publicly said so on issues, and we expect those to start hitting around 0.11. There are definitely some mistakes we shipped in its original form and while that's unfortunate, but we've learned a lot and brought on some people very experienced on such topics and we plan to address these shortcomings over time.)

When I add some dependency to the Maven pom of my legacy Java EE app, I'm exposed to exactly the same kind of risk.

In short: research any dependency you pull in, whether it is a library for your favorite language or a module for your infrastructure automation tool of choice.