Module

Modules are Git repositories with roles and packets that typically enable the installation and management of a certain product.

Module repositories can contain packets, roles and whole environments, but also code and documentation that’s not immediately related to Infraxys.
Changes to the roles, packets and environments can be blocked on Infraxys server instances so that developers have to use Git-branches. This enables the four eyes principle through branch protection.

Dependencies can be defined between modules and it’s through the Infraxys UI that they are installed and updated.

Modules don’t require any specific Infraxys-files which means that any existing Git-repository with sources for Ansible, Terraform, Packer, … can be used as is.

Webhooks can be configured to automatically update packets and modules that are connected to branches. Changes can be pulled manually as well.

Adding a module to your Infraxys environment

See Configure Infraxys

module.json

Use this file to define properties of the module itself and to define dependencies. Dependencies are installed automatically in Infraxys. This is a recursive operation.

Example module.json:

{  
  "dependencies": [
    {
      "git_url": "git@github.com:jeroenmanders/python.git
      "branch": "master"
    },
    {
      "git_url": "git@...."
      "branch": "feature-branch"
    }    
  ]
}

Other module-specific files

There are several files that are executed based on their name or location.

See Execution order for a complete list.

How modules are enabled

When an action is run, the module is belongs to is automatically copied into the Docker container of the action. Dependencies that are specified in module.json are also copied, including dependencies of dependencies, … and so on.

through attributes

enable_module_in_parents

Sometimes it’s useful to make the module of an instance available to any action in the instances parent tree.

A case for this is a Terraform module that can be managed through a parent instance. If the module needs to gather information from Vault, for example, then it can ensure that the Vault-module is always available when the parent Terraform Runner is executed.

You can do this by adding an attribute with name ‘enable_module_in_parents’ to the packet of the instance and assigning the value “1” to the attribute on the instance.
This can be done by specifying “Checkbox” for the attribute and specify “1” for the default value if desired.
If users should never be able to change the value of the attribute, then you can make it read-only or invisible.

always_enable_module

The Infraxys core container has instances with this attribute set to “1”.
This container is typically included in the root-project and with overriding disabled.
By doing this, the scripts with “always include” set to true are available in every instance in Infraxys.
Files with attribute values for every instance are also generated under every environment.

Some other usage examples:

  • Enable a module that’s managed by a central team to:
    • Execute validations for every action and cancel the action if needed (a user that executes and action should be a member of a certain Okta group, GitHub team, …).
    • Add auditing.
    • Run some OPA (Open Policy Agent) checks and cancel the action if necessary (the Terraform module can use this to validate a plan before it’s applied).
    • Halt the execution until something is set:
      • if the instance of the action has a “ticket”-attribute, for example, then only continue the execution if the ticket is approved.
      • send a mail for approval and wait until the mail is answered.
      • a file exists in S3.
      • subscribe to a topic in, for example, SNS and continue when a notification is received.
      • …