Platform Preparation

Platform being code-managed, the first thing you need to do is create a dedicated Git repository to handle changes and revisions.

Note

Git repository creation, management, access and permissions is out of the scope of this documentation.

Platform Metadata

As detailed in Platform Metadata section, a specific META.yml is required at the root of your project to allow opsctl to work and further templating.

Let's interactively create one

$ opsctl meta -i

and fill in the various choices:

  • Customer name
  • Region
  • Country
  • Infrastructure provider
  • Remote access
  • Product type
  • License type
  • Support level
  • Platform's secret identifier key
  • Platform's tag
  • Platform's FQDN
  • ...

Initial templating

Based on the information in META.yml file, we'll now create a templated platform Terraform and Ansible configuration.

Let's start by creation secrets management master keys in the requested provider:

$ opsctl secrets init
$ opsctl vault init

This will generate random robust master encryption keys and push them into the selected secrets management provider.

Now let's populate the IaC and CasC templated code:

$ opsctl template

This step requires Internet connectivity and will connect to Dalet's Bitbucket go-environment-templates repository using various platform-specific metadata information to generate a skeleton of code for you.

You will end up with the following structure in place:

$ tree -L 1
.
├── META.yml        <- the project metadata file
├── ansible         <- folder with ansible-specifics platform configuration settings
└── terraform       <- folder with terraform-specifics platform configuration settings

Pre-filled secrets

The templating will take care of generating and pre-filling strong robust random passwords for most if not all of the necessary sensitive variables you may need to use in Terraform and Ansible.

This will lead in the automatic generation of these 2 variable files:

terraform
├── secrets.yml
ansible/vars
└── secrets.yml

which will be Vault and SOPS encrypted using the previously generated master-key.

Infrastructure Tuning

Keep in mind that the generated templated codebase is just that: a template.

It will have to be modified to fit your needs, e.g. specifications and count of computing instances, name and policy of S3 buckets, networking specificities and peering options etc ...

Please refer to the Infrastructure Setup section for futher details.

Application Tuning

The whole application parameters and configuration will be managed by Ansible and map the following structure:

$ tree ansible/vars
├── provider.yml      <- Provider-specific variables, where Flex deployment is depending on Cloud or on-premises specificities for example.
├── secrets.yml       <- Operator-managed master key encrypted secrets file, pre-filled by templating, human managed later.
├── tf.secrets.yml    <- Secrets from Terraform-generated resources. NOT TO BE EDITED.
├── tf.vars.yml       <- Platform-specific variables, auto-generated from Terraform-generated resources. NOT TO BE EDITED.
└── variables.yml     <- Platform-specific variable overrides, operator-managed, free content.

Terraform-generated variables

Terraform is used to create Cloud resources and their usage sometimes requires configuration parameters to be pushed back to Ansible. To prevent copy/paste errors and configuration gaps, Dalet Terraform modules are configured to automatically output relevant configuration details into Ansible's compatible YAML files.

Consequently, the tf.{vars,secrets}.yml from Ansible are Terraform-generated and MUST NOT BE MANUALLY EDITED.

If required to be overriden, the associated variables can be redefined in variables.yml file.

Please refer to the Application Setup section for futher details and Ansible Collections section for the exhaustive list of accepted variables which can be set.