_images/login_button.png _images/signup_button.png



Modules in Scalr

Reading time: 4 minutes

Terraform modules enable standardization and support and the common objective of keeping code DRY. When a module is called from a Terraform configuration the source parameter specifies where Terraform should pull the module from. Terraform configurations run through Scalr can use 3 source types.

Source Type

Description

Example

Scalr Module Registry

Versions or tagged release of modules in VCS repositories can be registered in Scalr and pulled using Scalr internal URLs (VCS and CLI)

source = "my-account.scalr.io/acc-sscctbisjkl35b8/scalr_dynamic_vpc_dns/aws"

Modules from Git

Module sources can be pulled from git repos using same authentication as the configuration (VCS only).

source = "github.com/user/repo"

Modules from Paths

Module is in a sub-directory of the repository (VCS) or local folder (CLI).

source = "./my_module" or source = "/home/user/my_module"

Scalr Module Registry

The module registry can be used by developers to publish modules directly from their own VCS accounts without having to provide or share credentials to their account with every user that needs the module.

Note

The registry supports registering modules from sub-folders of a mono-repo as well as single module repos (micro-repo).

This works for:

  • VCS repository based configurations where the module is accessed via a different set VCS provider credentials than the main configuration.

  • CLI runs that need to call modules in VCS repositories.

Tip

The module registry is available in environments, accounts and globally (self-hosted IacP). Modules registered globally and in accounts are inherited by all accounts/environments below.

The module registry also provides version control for modules. Modules can only be registered if Git Releases or Tagged Versions have been created in the repository. Module calls via the registry must use versions, thus new versions can be released with impacting existing deployments.

Example module call from the registry:

module "instance" {
  source  = "my-account.scalr.io/org-sfgari365m7sck0/instance/aws"
  version = "1.0.1"
  instance_type = var.instance_type
  instance_count = var.instance_count
  subnet = var.subnet
  sg = var.security_group
  key = var.ssh_key
  vpc_id = var.vpc_id
  ami = var.ami
}

Note

A git release is a tagged version of the code. Once created a release never changes as it is pinned to a specific commit. Tags must use semantic version numbering (m.m.p, e.g v1.0.4, 0.7.3) and can be created via the CLI (see git tag) or in the git VCS console via the “releases” page.

Modules in the registry are automatically pulled into workspaces where they are needed and the registration process automatically creates internal references to the module to be used in the Terraform configuration.

Module Repositories

Modules to be used in the registry can either be in a micro-repo, or they can be in the sub-folder of a mono-repo. The release tag can be on any branch.

Follow the VCS system specific method to create a release or tagged version. Tags/releases can also be created using the git CLI command git tag.

Micro-Repo

For modules in their own unique repository, the repository itself must be named using the format terraform-<provider_name>-<module_name>, e.g. terraform-aws-vcs_module.

Example from Github.

_images/git_mod_rel_1.png


_images/git_mod_rel_2.png

Mono-Repo

For modules in a mono-repo the repository itself can have any name, but the sub-folders for each module must use the format terraform-<provider_name>-<module_name>, e.g. terraform-aws-instance.

Example from Github.

_images/git_mod_rel_3.png


_images/git_mod_rel_4.png

Publishing Modules

A module can be registered in environments, accounts, or globally (self hosted IaCP only). Modules registered in an account or globally can be used in any environment/workspace below.

To publish a module first create a VCS provider if this has not already been done.

  • Navigate to “Modules”. Click on “New Module” and select the VCS provider and the repository. For a mono-repo also add the path to the module.

    _images/module_pub_1.png _images/module_pub_1a.png
  • The resulting screen will show the boiler plate code with the internal source reference that can be used to call the module from any Terraform configuration in this environment or all environments if the module was created in the account or globally.

    _images/module_pub_2.png

Example Module Call from Registry

This is an example of Terraform configuration run via the CLI calling a module via the registry. Note the source and version parameters.

terraform {
  backend "remote" {
  hostname = "my-account.scalr.io"
    organization = "org-sfgari365m7sck0"
    workspaces {
      name = "module-test"
    }
  }
}

provider "aws" {
  region = var.region
}

module "instance" {
  source  = "my-account.scalr.io/org-sfgari365m7sck0/instance/aws"
  version = "1.0.1"
  instance_type = var.instance_type
  instance_count = var.instance_count
  subnet = var.subnet
  sg = var.security_group
  key = var.ssh_key
  vpc_id = var.vpc_id
  ami = var.ami
}

Modules from Git

Terraform configurations running in a Scalr VCS integrated workspaces can call modules directly via git HTTPs URLs.

This option will work if the VCS Provider used by the workspace to pull the configuration will also allow access to the modules repository. When a workspace is integrated with VCS the access token is propagated to the workspace, thus making it possible to pull the module as well.

Note

This ONLY works for VCS integration. It does not work for CLI runs

Example module call from Git

provider "aws" {
  region = var.region
}

module "instance" {
  source  = "github.com/scalr-eap/instance"
  instance_type = var.instance_type
  instance_count = var.instance_count
  subnet = var.subnet
  sg = var.security_group
  key = var.ssh_key
  vpc_id = var.vpc_id
  ami = var.ami
}

Modules from Paths

If a module exists as a sub-directory in the Terraform configuration directory it can also be sourced using a relative or absolute path. This works for VCS integration and the CLI as the directory and all it’s sub-directories are always loaded into the Scalr workspace.

Example for CLI configuration

terraform {
  backend "remote" {
  hostname = "my-account.scalr.io"
    organization = "org-sfgari365m7sck0"
    workspaces {
      name = "module-test"
    }
  }
}

provider "aws" {
  region = var.region
}

module "instance" {
  source  = "./instance"
  instance_type = var.instance_type
  instance_count = var.instance_count
  subnet = var.subnet
  sg = var.security_group
  key = var.ssh_key
  vpc_id = var.vpc_id
  ami = var.ami
}