Production-ready Azure Terraform modules

Why

Claranet has recently released a bunch of Terraform modules for Azure and intends to publish more: https://registry.terraform.io/search?q=claranet%20azure.

Built for production

The modules we release are not intended to cover the full scope of the underlying resources but to set some settings by default or ease some configuration for the production environment, and those last 2 words are important.

Naming

For our modules, all the created resources have their names generated from the project name, customer name, region, environment and resource type as recommanded by Azure.

Logs & metrics

We always want, for production-ready resources, logging enabled and aggregated along with detailed and numerous metrics.

High availability

Most of the Azure services offer high availability through zone redundancy, multiple instances or clustering. We chose to have a highly available service with each module default configuration.

  • Having a non-redundant infrastructure should be a choice explicitly made in your code.

Non-intrusive

We do not assume that the user has extensive rights on the Azure environment. So that, the modules do not use internally any Azure Active Directory read or write operation as it can be done for RBAC management on some resources.

Modularity

Our modules are built for everyone. That’s why, even though we made some recommendations by setting default values, we do not hard-code anything, letting users choose how they want to use the module.

Run tools

Production platforms need tools to operate them like logs, backups and monitoring. For monitoring, we use Datadog (SignalFx now, blog post yet to come…) as an external solution and don’t rely directly on Azure Monitor.

Application lifecycle

Modules are published to Github and Terraform registry with semver versioning.

Made for humans

At last, we design modules as APIs that can be easily understood and focus on the user’s needs and not on the underlying Terraform mechanism or Azure API.

  • The Sku variables for MySql or SQL resources that need to provide redundant information is changed to provide as less information as possible, like size & family and either guess or enforce other information.
  • Storage linking for logs, backup or any other internal behaviour sometimes require the resource id, and sometimes the storage name. Sometimes the access is made through a SAS token, sometimes through an access key. We hide this diversity by using always the same input variables no matter what the implementation is.

Conclusion

Releasing Terraform modules is a huge work that takes us a lot of time but we can see every day the benefits and we believe it’s worth the effort. We can observe in a short lap of time:

  • Uniform base code for all our projects
  • High availability and security best practices enforced
  • Environments created with always up-to-date Azure features and tools, and you know it’s going incredibly fast on this

Combining pioneering technologies, practices, and expertise to propel your business ambitions