Managing blog infrastructure as code

Published on January 20, 2026

This article demonstrates how to import Cloudflare resources into OpenTofu code and manage them in GitLab.

Preface

When start building this blog, I thought about how to serve contents. I occasionally host tools for personal use temporarily on my home server, but maintaining a publicly accessible server securely over the long term is no easy task. Therefore, I decided that using cloud infrastructure was the best way to reliably deliver my blog to others. The cloud service providers (CSPs) I have experience with are Amazon Web Services (AWS) and Google Cloud Platform (GCP), and if private clouds count, OpenStack as well. However, I thought it would be worthwhile to challenge something new, so I decided to use Cloudflare. The web interface provided by Cloudflare for managing resources felt easier to use than the equivalents available on AWS or GCP in my opinion. That said, managing infrastructure as code is still preferable to clicking through settings—a lesson learned the hard way.

This article describes how I configured things. It’s not necessarily the optimal route, and there are some redundant steps, but I’ve intentionally left them—it might be useful to someone. I use Void Linux as OS and zsh as shell, so the command examples below assume that environment. While they shouldn’t differ significantly, please adjust them to suit your own setup.

Import manually created resources into code
Manage resource states remotely
Pass credentials via environment variables
Data-at-rest encryption for state files
Using CI/CD
Conclusion

Import manually created resources into code

Let me be honest. At first, I thought I could just quickly set things up using the web interface. But I reconsidered and decided to write it as code so future me wouldn’t get confused.

In the process of importing the resources I had already created into the code, I used a tool called cf-terraforming that is provided for this specific purpose. To begin with, a tool to work with tf files is needed. I use opentofu, but terraform is also an option, depending on your preference.

To build and install tofu into ~/.local/bin/:

1
git clone https://github.com/opentofu/opentofu
2
cd opentofu
3
git checkout v1.11.3
4
go build \
5
    -ldflags '-w -s -X "github.com/opentofu/opentofu/version.dev=no"' \
6
    -o ~/.local/bin/tofu \
7
    ./cmd/tofu

The tofu version I used is as follows.

1
tofu version

OpenTofu v1.11.3
on linux_amd64

tofu supports shell’s tab completion, so zsh for example, you can enable it by adding the following lines to your initialization script.

1
() {
2
    readonly cmd=tofu
3
    command -v $cmd >/dev/null || return 0
4
    if ! command -v complete >/dev/null; then
5
        autoload -U +X bashcompinit
6
        bashcompinit
7
    fi
8
    complete -C $cmd $cmd:t
9
}

To download and install cf-terraforming on an x86-64 Linux machine:

1
install-cf-terraforming () {
2
    local -r os=linux
3
    local -r arch=amd64
4
    local -r version=0.24.0
5
    local -r sha256sum=35eb5c975f5c3ed7e7b822d665bb5cd533a1804d92625d4d62163ff3eaf12b49
6
    local -r url=https://github.com/cloudflare/cf-terraforming/releases/download/v$version/cf-terraforming_${version}_${os}_$arch.tar.gz
7
    local -r download_dst=~/Downloads/cf-terraforming/${url##*/}
8
    local -r extract_dst=~/.local/share/cf-terraforming-$os-$arch-v$version
9
    local -r install_dst=~/.local/bin
10
    curl --create-dirs -Lo "$download_dst" "$url"
11
    sha256sum -c <<<"$sha256sum  $download_dst" || return 1
12
    tar xvf "$download_dst" --one-top-level=$extract_dst
13
    mkdir -pv "$install_dst"
14
    ln -srvft "$install_dst" "$extract_dst"/cf-terraforming
15
}
16
install-cf-terraforming

The cf-terraforming version I used is as follows.

1
cf-terraforming version

cf-terraforming v0.24.0

Create a file provider.tf to configure the provider.

1
terraform {
2
  required_providers {
3
    cloudflare = {
4
      source  = "cloudflare/cloudflare"
5
      version = "~> 5"
6
    }
7
  }
8
}
9

10
provider "cloudflare" {
11
}

And then initialize the working directory.

1
tofu init

Output

Initializing the backend...

Initializing provider plugins...
- Finding cloudflare/cloudflare versions matching "~> 5.0"...
- Installing cloudflare/cloudflare v5.15.0...
- Installed cloudflare/cloudflare v5.15.0 (signed, key ID C76001609EE3B136)

Providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://opentofu.org/docs/cli/plugins/signing/

OpenTofu has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that OpenTofu can guarantee to make the same selections by default when
you run "tofu init" in the future.

OpenTofu has been successfully initialized!

You may now begin working with OpenTofu. Try running "tofu plan" to see
any changes that are required for your infrastructure. All OpenTofu commands
should now work.

If you ever set or change modules or backend configuration for OpenTofu,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

The above command installs the provider under directory .terraform/ and creates a file .terraform.lock.hcl containing its information. If you are managing your code with Version Control System (VCS) such as Git or Jujutsu (and I think you should be), now would be a good time to create a .gitignore file.

Below is an example of basic configuration. Depending on the situation, you may also want to add files such as *.auto.tfvars. The key point is that the lock file is managed in VCS.

1
.terraform/
2
*.tfstate
3
*.tfstate.*

Before executing cf-terraforming, set several environment variables.

First, set an API token for operating Cloudflare resources to variable CLOUDFLARE_API_TOKEN. That can be created in API Tokens. Settings vary depending on the use case, but in this example, permission to edit DNS was granted.

To configure the zone settings, you need to set the Zone ID to CLOUDFLARE_ZONE_ID, which can be found at Account Home. For more details, please refer to Find account and zone IDs.

Finally, specify the binary path to allow cf-terraforming to run tofu.

1
 export CLOUDFLARE_API_TOKEN=Hzsq3Vub-7Y-hSTlAaLH3Jq_YfTUOCcgf22_Fs-j
2
export CLOUDFLARE_ZONE_ID=d8b3ea000123deadbeef456787959185
3
CLOUDFLARE_TERRAFORM_BINARY_PATH=$(command -v tofu)
4
export CLOUDFLARE_TERRAFORM_BINARY_PATH

One might think the leading space in the first line of the command example above is a typo, but it actually isn’t. zsh has an option called HIST_IGNORE_SPACE. When enabled, it prevents commands from being saved in history file if you execute them with leading whitespace. This is useful when handling credentials.

1
setopt hist_ignore_space

Now it’s time to generate the code. Here we import cloudflare_dns_record, but you can check the Supported Resource Types for other resource types.

1
cf-terraforming generate \
2
    --resource-type cloudflare_dns_record |
3
    tee dns.tf

Executing the above command should create a file named dns.tf that looks like the following.

1
resource "cloudflare_dns_record" "terraform_managed_resource_df2efc022011c2adcc0f401c7c53731e_0" {
2
  content  = "198.51.100.1"
3
  name     = "docs.example.com"
4
  proxied  = true
5
  tags     = []
6
  ttl      = 1
7
  type     = "A"
8
  zone_id  = "d8b3ea000123deadbeef456787959185"
9
  settings = {}
10
}
11

12
resource "cloudflare_dns_record" "terraform_managed_resource_aebdaa573101d6425d2e0a5d2e9066d9_1" {
13
  content  = "3fff::1"
14
  name     = "shop.example.com"
15
  proxied  = true
16
  tags     = []
17
  ttl      = 1
18
  type     = "AAAA"
19
  zone_id  = "d8b3ea000123deadbeef456787959185"
20
  settings = {}
21
}

At this point, the code representing the infrastructure has been created, but its state is not yet managed by the tool. To import resources into the tool’s management environment, additional steps are required.

1
cf-terraforming import \
2
    --modern-import-block \
3
    --resource-type cloudflare_dns_record |
4
    tee import-dns.tf

The above command creates a file import-dns.tf containing import blocks like the one below.

1
import {
2
  to = cloudflare_dns_record.terraform_managed_resource_df2efc022011c2adcc0f401c7c53731e_0
3
  id = "d8b3ea000123deadbeef456787959185/df2efc022011c2adcc0f401c7c53731e"
4
}
5

6
import {
7
  to = cloudflare_dns_record.terraform_managed_resource_aebdaa573101d6425d2e0a5d2e9066d9_1
8
  id = "d8b3ea000123deadbeef456787959185/aebdaa573101d6425d2e0a5d2e9066d9"
9
}

I changed the automatically generated names like terraform_managed_resource_df2efc022011c2adcc0f401c7c53731e_0 to something more understandable, but that’s up to personal preference. You can now import the resources using the following command.

1
tofu apply

Once the import is complete, file import-dns.tf can be deleted.

Manage resource states remotely

Local state file terraform.tfstate contains resource details, so it is generally recommended not to commit it to VCS. However, managing it separately from the repository is a pain and something you probably don’t want to do. Fortunately, GitLab has a feature that handles this for us.

Create a file backend.tf that sets the backend to http.

1
terraform {
2
  backend "http" {
3
  }
4
}

A GitLab personal access token is required. This can be created on the web, and the only required scope is the api. Also, set the username and project ID. Note that the project ID is different from the repository name. For details, see Find the Project ID.

1
 gitlab_access_token=glpat-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2
gitlab_username=example-user
3
gitlab_project_id=87654321

You can store multiple states in a single repository. Set a name that are meaningful to you.

1
state_name=example-state

Once you have set the above variables, you can save the state to the remote.

1
tofu init \
2
    -backend-config=address=https://gitlab.com/api/v4/projects/${gitlab_project_id:?}/terraform/state/${state_name:?} \
3
    -backend-config=lock_address=https://gitlab.com/api/v4/projects/${gitlab_project_id:?}/terraform/state/${state_name:?}/lock \
4
    -backend-config=unlock_address=https://gitlab.com/api/v4/projects/${gitlab_project_id:?}/terraform/state/${state_name:?}/lock \
5
    -backend-config=username=${gitlab_username:?} \
6
    -backend-config=password=${gitlab_access_token:?} \
7
    -backend-config=lock_method=POST \
8
    -backend-config=unlock_method=DELETE \
9
    -backend-config=retry_wait_min=5

In my case, since this state with the given name did not exist remotely, an option to copy it from the local source was presented.

Initializing the backend...
Acquiring state lock. This may take a few moments...
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "local" backend to the
  newly configured "http" backend. No existing state was found in the newly
  configured "http" backend. Do you want to copy this state to the new "http"
  backend? Enter "yes" to copy and "no" to start with an empty state.

  Enter a value:

Entering yes not only initializes the remote state but also copies the local value.

  Enter a value: yes

Releasing state lock. This may take a few moments...

Successfully configured the backend "http"! OpenTofu will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Reusing previous version of cloudflare/cloudflare from the dependency lock file
- Using previously-installed cloudflare/cloudflare v5.15.0

OpenTofu has been successfully initialized!

You may now begin working with OpenTofu. Try running "tofu plan" to see
any changes that are required for your infrastructure. All OpenTofu commands
should now work.

If you ever set or change modules or backend configuration for OpenTofu,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

The state saved remotely can be checked in https://gitlab.com/<GITLAB_USERNAME>/<PROJECT_NAME>/-/terraform.

If you later decide to change the state’s name, you can do so as follows.

1
new_state_name=default
2
tofu init \
3
    -migrate-state \
4
    -backend-config=address=https://gitlab.com/api/v4/projects/${gitlab_project_id:?}/terraform/state/${new_state_name:?} \
5
    -backend-config=lock_address=https://gitlab.com/api/v4/projects/${gitlab_project_id:?}/terraform/state/${new_state_name:?}/lock \
6
    -backend-config=unlock_address=https://gitlab.com/api/v4/projects/${gitlab_project_id:?}/terraform/state/${new_state_name:?}/lock \
7
    -backend-config=username=${gitlab_username:?} \
8
    -backend-config=password=${gitlab_access_token:?} \
9
    -backend-config=lock_method=POST \
10
    -backend-config=unlock_method=DELETE \
11
    -backend-config=retry_wait_min=5

Pass credentials via environment variables

Since I migrated the state to remote in the previous section, the local state file is now just an empty file.

1
stat -c %s terraform.tfstate

On the other hand, the information for connecting to the backend is stored in file .terraform/terraform.tfstate, which includes the previously specified personal access token.

1
{
2
    "version": 3,
3
    "serial": 2,
4
    "lineage": "a2d0b9dd-6eed-b4c3-29e0-92c8c2fd3b12",
5
    "backend": {
6
        "type": "http",
7
        "config": {
8
            "address": "https://gitlab.com/api/v4/projects/87654321/terraform/state/default",
9
            "client_ca_certificate_pem": null,
10
            "client_certificate_pem": null,
11
            "client_private_key_pem": null,
12
            "headers": null,
13
            "lock_address": "https://gitlab.com/api/v4/projects/87654321/terraform/state/default/lock",
14
            "lock_method": "POST",
15
            "password": "glpat-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
16
            "retry_max": null,
17
            "retry_wait_max": null,
18
            "retry_wait_min": 5,
19
            "skip_cert_verification": null,
20
            "unlock_address": "https://gitlab.com/api/v4/projects/87654321/terraform/state/default/lock",
21
            "unlock_method": "DELETE",
22
            "update_method": null,
23
            "username": "example-user"
24
        },
25
        "hash": 2984870146
26
    },
27
    "modules": [
28
        {
29
            "path": [
30
                "root"
31
            ],
32
            "outputs": {},
33
            "resources": {},
34
            "depends_on": []
35
        }
36
    ]
37
}

The following is a quote from the OpenTofu Docs.

Warning: We recommend using environment variables to supply credentials and other sensitive data. If you use -backend-config or hardcode these values directly in your configuration, OpenTofu will include these values in both the .terraform subdirectory and in plan files. Refer to Credentials and Sensitive Data for details.

As described, I executed the previous command with the -backend-config option specified, causing that information to be saved to the file. To follow the recommendation and pass credentials via environment variables, add a few lines to backend.tf as shown below.

1
locals {
2
  backend_address = "https://gitlab.com/api/v4/projects/${var.project_id}/terraform/state/${var.state_name}"
3
}
4

5
terraform {
6
  backend "http" {
7
    address        = local.backend_address
8
    lock_address   = "${local.backend_address}/lock"
9
    unlock_address = "${local.backend_address}/lock"
10
    lock_method    = "POST"
11
    unlock_method  = "DELETE"
12
    retry_wait_min = 5
13
    username       = var.gitlab_username
14
  }
15
}

To avoid repetition and for brevity, I created several variables.

1
variable "state_name" {
2
  description = "Name of the state saved in GitLab"
3
  type        = string
4
}
5

6
variable "project_id" {
7
  description = "Project ID of this repository"
8
  type        = number
9
}
10

11
variable "gitlab_username" {
12
  description = "GitLab username"
13
  type        = string
14
}

Set the values of the variables in file terraform.tfvars. I don’t consider these values to be sensitive, but depending on their content, there may be cases where it’s better not to include them in the repository.

1
state_name      = "default"
2
project_id      = 87654321
3
gitlab_username = "example-user"

Since the personal access token is a credential, it is passed as an environment variable TF_HTTP_PASSWORD at runtime.

1
export TF_HTTP_PASSWORD=${gitlab_access_token:?}

Apply these settings.

1
tofu init -reconfigure

After that, you can confirm that the credential is no longer saved to the file.

1
{
2
    "version": 3,
3
    "serial": 3,
4
    "lineage": "a2d0b9dd-6eed-b4c3-29e0-92c8c2fd3b12",
5
    "backend": {
6
        "type": "http",
7
        "config": {
8
            "address": "https://gitlab.com/api/v4/projects/87654321/terraform/state/default",
9
            "client_ca_certificate_pem": null,
10
            "client_certificate_pem": null,
11
            "client_private_key_pem": null,
12
            "headers": null,
13
            "lock_address": "https://gitlab.com/api/v4/projects/87654321/terraform/state/default/lock",
14
            "lock_method": "POST",
15
            "password": null,
16
            "retry_max": null,
17
            "retry_wait_max": null,
18
            "retry_wait_min": 5,
19
            "skip_cert_verification": null,
20
            "unlock_address": "https://gitlab.com/api/v4/projects/87654321/terraform/state/default/lock",
21
            "unlock_method": "DELETE",
22
            "update_method": null,
23
            "username": "example-user"
24
        },
25
        "hash": 2269132671
26
    },
27
    "modules": [
28
        {
29
            "path": [
30
                "root"
31
            ],
32
            "outputs": {},
33
            "resources": {},
34
            "depends_on": []
35
        }
36
    ]
37
}

Managing credentials passed to tools

With the setup so far, I now have to handle two environment variables, CLOUDFLARE_API_TOKEN and TF_HTTP_PASSWORD. So, how should I manage these? Setting these variables in ~/.zprofile or ~/.bash_profile would be defeating the purpose.

What I’m using is pass, which is a command-line interface (CLI) password manager. Combining pass with a YubiKey enables the retrieval of credentials only when necessary, using a physical key and passphrase. I won’t cover YubiKey setup here, but I’d like to create a separate entry for it at some point.

To install pass on Void Linux:

1
sudo xbps-install pass

The version I used is as follows.

1
pass version

============================================
= pass: the standard unix password manager =
=                                          =
=                  v1.7.4                  =
=                                          =
=             Jason A. Donenfeld           =
=               Jason@zx2c4.com            =
=                                          =
=      http://www.passwordstore.org/       =
============================================

This utility stores passwords in encrypted files using the GNU Privacy Guard (GnuPG or GPG). For details and examples, please refer to the man page.

If this is your first time using pass, you must first initialize the password store with GPG ID.

1
pass init user@example.com

The above command creates a directory at $PASSWORD_STORE_DIR, which defaults to ~/.password-store.

Let’s save the GitLab personal access token created earlier. Here, the hierarchy example-project/gitlab.com/personal-access-token is used.

1
pass insert example-project/gitlab.com/personal-access-token

mkdir: created directory '/home/example-user/.password-store/example-project'
mkdir: created directory '/home/example-user/.password-store/example-project/gitlab.com'
Enter password for example-project/gitlab.com/personal-access-token:
Retype password for example-project/gitlab.com/personal-access-token:
[main 47f928f] Add given password for example-project/gitlab.com/personal-access-token to store.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 example-project/gitlab.com/personal-access-token.gpg

To retrieve the saved value:

1
pass show example-project/gitlab.com/personal-access-token

glpat-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Since the password store is just a git repository after all, even if you accidentally overwrite a value, you can undo it like this:

1
pass git revert HEAD

If you’re interested in the contents of the generated file, it can be inspected as follows.

1
gpg -v --list-packets \
2
    ${PASSWORD_STORE_DIR:-~/.password-store}/example-project/gitlab.com/personal-access-token.gpg

Similarly, save the Cloudflare API token in example-project/cloudflare.com/user-api-token.

1
pass insert example-project/cloudflare.com/user-api-token

At this point, credentials are stored in encrypted form and can be retrieved as needed, but with a few more tweaks to make them even easier to use. pass allows users to execute scripts placed under $PASSWORD_STORE_EXTENSIONS_DIR, which defaults to $PASSWORD_STORE_DIR/.extensions, as alternative commands. Save the following script as tofu.bash in $PASSWORD_STORE_EXTENSIONS_DIR.

1
#!/usr/bin/bash
2

3
set -eu
4
[[ "${PASS_TOFU_VERBOSE-}" != 2 ]] || set -x
5

6
pass_names=$(pwd)/.pass
7
readonly pass_names
8
readonly cmd=tofu
9

10
if [[ -e "$pass_names" ]]; then
11
    while read -r line; do
12
        key=${line%%=*}
13
        name=${line#*=}
14
        val=$(pass show "$name")
15
        export "$key"="$val"
16
        [[ "${PASS_TOFU_VERBOSE-}" != 1 ]] ||
17
            printf '"%s" has been set by "%s"\n' "$key" "$name"
18
    done <"$pass_names"
19
fi
20
! [[ "${PASS_TOFU_VERBOSE-}" =~ ^[12]$ ]] || printf '\n'
21

22
exec "$cmd" "$@"

Make that file executable.

1
chmod -c u+x \
2
    ${PASSWORD_STORE_EXTENSIONS_DIR:-${PASSWORD_STORE_DIR:-~/.password-store}/.extensions}/tofu.bash

To enable extensions, you must set PASSWORD_STORE_ENABLE_EXTENSIONS to true.

1
export PASSWORD_STORE_ENABLE_EXTENSIONS=true

To have it set automatically upon login, add the above line to ~/.zprofile, ~/.bash_profile, etc.

Creating a file named .pass in the directory where the tf files resides. The format is separated by =, with the left side being the environment variable name you want to set, and the right side being the path within pass where it is stored.

1
CLOUDFLARE_API_TOKEN=example-project/cloudflare.com/user-api-token
2
TF_HTTP_PASSWORD=example-project/gitlab.com/personal-access-token

Execute the tofu command with pass preceding it. Setting PASS_TOFU_VERBOSE to 1 will output which variables were set.

1
PASS_TOFU_VERBOSE=1 pass tofu plan

"CLOUDFLARE_API_TOKEN" has been set by "example-project/cloudflare.com/user-api-token"
"TF_HTTP_PASSWORD" has been set by "example-project/gitlab.com/personal-access-token"

Acquiring state lock. This may take a few moments...
cloudflare_dns_record.terraform_managed_resource_df2efc022011c2adcc0f401c7c53731e_0: Refreshing state... [id=df2efc022011c2adcc0f401c7c53731e]
cloudflare_dns_record.terraform_managed_resource_aebdaa573101d6425d2e0a5d2e9066d9_1: Refreshing state... [id=aebdaa573101d6425d2e0a5d2e9066d9]

No changes. Your infrastructure matches the configuration.

OpenTofu has compared your real infrastructure against your configuration and found no differences, so no changes are needed.
Releasing state lock. This may take a few moments...

Data-at-rest encryption for state files

At this point, the state file should be managed remotely, and I believe that environment is sufficiently trustworthy. However, since OpenTofu provides encryption for state and plan files at rest, let’s take advantage of it.

Generate a passphrase using pass for example-project/tf-passphrase.

1
pass generate -n example-project/tf-passphrase 100

Add the following line to the .pass file created earlier.

1
CLOUDFLARE_API_TOKEN=example-project/cloudflare.com/user-api-token
2
TF_HTTP_PASSWORD=example-project/gitlab.com/personal-access-token
3
TF_VAR_passphrase=example-project/tf-passphrase

Create a file named encryption.tf that describes the encryption settings.

1
variable "passphrase" {
2
  sensitive = true
3
}
4

5
terraform {
6
  encryption {
7
    method "unencrypted" "migrate" {}
8

9
    key_provider "pbkdf2" "state" {
10
      passphrase = var.passphrase
11
    }
12

13
    method "aes_gcm" "state" {
14
      keys = key_provider.pbkdf2.state
15
    }
16

17
    state {
18
      method = method.aes_gcm.state
19

20
      fallback {
21
        method = method.unencrypted.migrate
22
      }
23
    }
24
  }
25
}

Migrate unencrypted state to encrypted one.

1
pass tofu apply

When you download the encrypted state file from https://gitlab.com/<GITLAB_USERNAME>/<PROJECT_NAME>/-/terraform, its contents should look something like this:

1
{
2
    "serial": 2,
3
    "lineage": "dfda5a40-39fd-7617-1877-8dad24da69b2",
4
    "meta": {
5
        "key_provider.pbkdf2.state": "<KEY_PROVIDER_PBKDF2_STATE>"
6
    },
7
    "encrypted_data": "<ENCRYPTED_DATA>",
8
    "encryption_version": "v0"
9
}

The unencrypted method configured in encryption.tf was temporary for migration purpose, so remove it and enforce encryption.

1
variable "passphrase" {
2
  sensitive = true
3
}
4

5
terraform {
6
  encryption {
7
    method "unencrypted" "migrate" {}
8

9
    key_provider "pbkdf2" "state" {
10
      passphrase = var.passphrase
11
    }
12

13
    method "aes_gcm" "state" {
14
      keys = key_provider.pbkdf2.state
15
    }
16

17
    state {
18
      method = method.aes_gcm.state
19

20
      fallback {
21
        method = method.unencrypted.migrate
22
      }
23
      method   = method.aes_gcm.state
24
      enforced = true
25
    }
26
  }
27
}

If you also want to encrypt the plan file, not just the state file, you can do so by creating a plan block similar to the state block.

1
variable "passphrase" {
2
  sensitive = true
3
}
4

5
terraform {
6
  encryption {
7
    key_provider "pbkdf2" "state" {
8
      passphrase = var.passphrase
9
    }
10

11
    method "aes_gcm" "state" {
12
      keys = key_provider.pbkdf2.state
13
    }
14

15
    plan {
16
      method   = method.aes_gcm.state
17
      enforced = true
18
    }
19

20
    state {
21
      method   = method.aes_gcm.state
22
      enforced = true
23
    }
24
  }
25
}

This time, since this change is applied without a plan file existing, I didn’t need to go through the unencrypted fallback method like before.

Using CI/CD

For personal websites, owners can basically update them whenever they like. However, for team projects, allowing each member to freely create or delete resources at their own timing can lead to problems. To ensure smooth code reviews and merge processes, leveraging CI/CD can be helpful. I’ll briefly explain how to utilize GitLab CI/CD pipelines here.

As written in .pass, the environment variables passed to the tofu command in the local environment are the followings:

CLOUDFLARE_API_TOKEN
TF_HTTP_PASSWORD
TF_VAR_passphrase

These variables will need to be present in the CI/CD environment. When running locally, TF_HTTP_PASSWORD was set to a personal access token, but it is preferable to set a separate token when running remotely. For this purpose, create a Project Access Token, which can be generated in https://gitlab.com/<GITLAB_USERNAME>/<PROJECT_NAME>/-/settings/access_tokens. According to the documentation, the token’s role must be set to Maintainer to manage state files. For the scope, selecting api is sufficient.

You can also create another token for CLOUDFLARE_API_TOKEN instead of using the one used previously, but the TF_VAR_passphrase must remain identical.

To make these variables available in CI/CD environments, configure them in https://gitlab.com/<GITLAB_USERNAME>/<PROJECT_NAME>/-/settings/ci_cd.

Screenshot of the interface for adding variables

GitLab CI/CD
variables

Pipeline configuration is done in the .gitlab-ci.yml file located in the top-level directory of the repository. Let’s first try it with the minimal settings.

1
include:
2
- component: gitlab.com/components/opentofu/validate-plan@4.2.0

After pushing the commit that created the above file, you can see that the pipeline has been executed at https://gitlab.com/<GITLAB_USERNAME>/<PROJECT_NAME>/-/pipelines.

Screenshot of the pipeline status

GitLab pipeline
minimal

What the above setting do is essentially execute the following commands as jobs:

tofu fmt
tofu validate
tofu plan

As a more practical example, let’s have a bot to automatically post plans generated from merge requests. To do this, set the CI/CD variable GITLAB_TOFU_TOKEN to the same value you previously set for TF_HTTP_PASSWORD, then edit the configuration file as follows.

1
workflow:
2
  rules:
3
  - if: $CI_PIPELINE_SOURCE == "merge_request_event"
4
  - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
5
    when: never
6
  - if: $CI_COMMIT_BRANCH
7

8
stages:
9
- validate
10
- build
11
- deploy
12

13
include:
14
- component: gitlab.com/components/opentofu/job-templates@4.2.0
15
  inputs:
16
    use_rootless_image: true
17
    lockfile: readonly
18
    plan_artifacts_access: developer
19
    post_mr_plan_comment: true
20

21
fmt:
22
  extends:
23
  - .opentofu:fmt
24
  allow_failure: false
25
  rules:
26
  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
27
  - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH
28

29
validate:
30
  extends:
31
  - .opentofu:validate
32
  rules:
33
  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
34
  - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH
35

36
plan:
37
  extends:
38
  - .opentofu:plan
39
  rules:
40
  - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH
41
    when: manual
42

43
fetch-mr-plan:
44
  extends:
45
  - .opentofu:fetch-mr-plan
46
  rules:
47
  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
48

49
apply:
50
  extends:
51
  - .opentofu:apply
52
  rules:
53
  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

After pushing .gitlab-ci.yml, let’s try creating a new resource. In this example, a new DNS record is added.

1
variable "zone_id" {
2
  type    = string
3
}
4

5
data "cloudflare_zone" "this" {
6
  zone_id = var.zone_id
7
}
8

9
resource "cloudflare_dns_record" "mr_example" {
10
  name    = "mr.${data.cloudflare_zone.this.name}"
11
  ttl     = 1
12
  type    = "A"
13
  zone_id = data.cloudflare_zone.this.zone_id
14
  content = "192.0.2.1"
15
}

In terraform.tfvars, set the value you previously assigned to CLOUDFLARE_ZONE_ID to the variable named zone_id.

1
state_name      = "default"
2
project_id      = 87654321
3
gitlab_username = "example-user"
4
zone_id         = "d8b3ea000123deadbeef456787959185"

When you create a merge request for the above changes, the pipeline will run. fmt and validate are performed automatically, but since plan is configured to run manually, user interaction is required to proceed.

Screenshot of the pipeline status after merge request created

GitLab pipeline status merge
requested

When you run plan, the bot will post the results to the merge request.

Screenshot of the comment posted on the merge request

GitLab merge request
comment

The plan results can be downloaded from https://gitlab.com/<GITLAB_USERNAME>/<PROJECT_NAME>/-/artifacts. Once the changes are merged, the pipeline will run up to the apply step on the default branch using the uploaded plan.

Screenshot of the pipeline status after merged

GitLab pipeline status
merged

Conclusion

Managing infrastructure in business operations requires careful handling, as failures can lead to losses. This makes trial and error difficult and opportunities for mastery scarce. Personal projects like blogs, however, pose little risk even if they fail, making them excellent opportunities for practice.

This was my first time using GitLab CI/CD, and while it seems similar to GitHub Actions, there are many differences, which I found interesting. Trying out various options rather than sticking to a single platform is also an effective way to avoid lock-in.

Since development environments are changing rapidly, fueled by the AI trend, I wish to continually seek out diverse experiences and hope to share them through this blog.