How do I structure a mono repo project

[ares-b]

Hey,

Context

I've a personal project with a bunch of friends where we deploy some VMs in oracle cloud (within the always free tier) and then install docker on each of these VMs.

So everyone of us has a Oracle Cloud account, in which we deploy 1 single VM with maxed out resources (within the always free tier). And then we run an ansible playbook that installs docker and creates some unix users.

Our terraform repository looks like this:

└──terraform
   └── backend.tf
   └── providers.tf
   └── docker_server_01.tf
   └── docker_server_02.tf
   └── docker_server_03.tf
   └── postgresql.tf
   └── vault.tf
   └── variables.tf
   └── modules
       └── oracle_alwaysfree
       └── docker_server

1. For now, we have a single tfstate that manages the 3 oracle cloud accounts. We'd like to have a separate state for each account.
2. For now, in each docker_server_xx.tf we just call oracle_alwaysfree and then docker_server (docker_server needs outputs from oracle_alwaysfree).
   2.1 On files docker_server_xx.tf we also set specific values for variables that are passed to modules oracle_alwaysfree and docker_server
3. variables.tf contains all our variables definition
4. postgresql.tf deploys a docker container with postgresql on docker_server_01.
   5.1 In this file we also handle users creation for postgresql and some other configurations
   5.2 Here we're using cyrilgdn/postgresql to configure stuff once the container is deployed.

   5.3 We would like to put the IP that has been assigned to docker_server_01 dynamically in the postgresql provider.

5. vault.tf deploys a docker container with postgresql on docker_server_02.
   6.1 In this file we also handle vault policies creation and other stuff
   6.2 Here we're using hashicorp/vault provider to configure stuff once the container is deployed

   6.3 We would like to put the IP that has been assigned to docker_server_02 dynamically in the vault provider.

The Problem

Basically we're trying to use terragrunt to solve all the problems above.
Can you please explain to us (with some code examples if possisble) how can we re-factor our terraform repository with terragrunt in the most "DRY" and consice way that also fixes the problems listed above ?

Researches

I've gone through the docs and I feel like I'm going round in circles because there are different ways of organizing this repository, but I can't figure out which is best suited for us.

For example for 1.. I guess we have to create a directory for each account: account_1, account_2, etc. And then at the top level terragrunt.hcl file, we'd have something along these lines:

locals {
  oci_accounts  = jsondecode(get_env("OCI_ACCOUNTS", "[]"))
  tf_backend    = jsondecode(get_env("TF_BACKEND", "{}"))
}

generate "backend" {
    path        = "backend.tf"
    if_exists   = "overwrite_terragrunt"
    contents    = templatefile("s3_backend.tmpl", {
        bucket      = local.tf_backend.bucket
        region      = local.tf_backend.region
        access_key  = local.tf_backend.access_key
        secret_key  = local.tf_backend.secret_key
    })
}


generate "provider" {
    path        = "provider.tf"
    if_exists   = "overwrite_terragrunt"
    contents    = templatefile("oci_provider.tmpl", {
        tenancy_ocid    = local.oci_accounts["${get_terragrunt_dir()}"].tenancy_ocid
        user_ocid       = local.oci_accounts["${get_terragrunt_dir()}"].user_ocid
        fingerprint     = local.oci_accounts["${get_terragrunt_dir()}"].fingerprint
        private_key     = local.oci_accounts["${get_terragrunt_dir()}"].private_key
        region          = local.oci_accounts["${get_terragrunt_dir()}"].region
    })
}

s3_backend.tpl file content:

provider "aws" {
  access_key  = "${access_key}"
  secret_key  = "${secret_key}"
}

terraform {
  backend "s3" {
    bucket         = "${bucket}"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = "${region}"
    encrypt        = true
  }
}

oci_provider.tpl file content:

terraform {
  required_providers {
    oci = {
      source = "oracle/oci"
      version = "5.46.0"
    }
  }
}
provider "oci" {
  tenancy_ocid  = "${tenancy_ocid}"
  user_ocid     = "${user_ocid}"
  fingerprint   = "${fingerprint}"
  private_key   = "${private_key}"
  region        = "${region}"
}

For 2. what comes in mind first is just having specific inputs block in the terragrunt.hcl file of each account folder, but that would make our Terragrunt Architecture not DRY, doesn't it ?

For 5. and 6. I honestly can't figure out how to fix those :/

[yhakbar]

Hey @ares-b ,

What might help you build a mental framework for how to use Terragrunt is to recognize that it is always going to:

1. Load the terragrunt.hcl in a given directory.
2. Execute any logic relevant to that file.
3. Execute OpenTofu/Terraform using those configurations, and what you've specified on the command line.

In your circumstance, it appears that what you're not leveraging includes. This is how Terragrunt code gets dry.

Are you aware of this configuration, and are you using it?

[ares-b]

Hi, I really appreciate your answer !

Yes, after a few hours of documentation and testing, I was able to implement the structure described in my other question: https://github.com/orgs/gruntwork-io/discussions/834#discussioncomment-9936547

Example repository : https://github.com/ares-b/terragrunt_oracle

I'd love to have your input on that