DEV Community: Tran Huynh An Duy (Andy)

Masking sensitive data for Jenkins server by Mask Passwords plugin

Tran Huynh An Duy (Andy) — Thu, 18 Dec 2025 13:58:57 +0000

Overview

The purpose of these activities is to implement the automatic masking of passwords or other information from build parameters.

1. Current situation

During the pipeline build process, the sensitive data (userID or password,...) is usually embedded or included in the script. This information can be exposed by checking the Console Output after running the job.

2. Solution

2.1 Installation Mask Passwords plugin:

From the Jenkins dashboard, go to Manage Jenkins → Plugins → Available plugins → type "Mask Passwords" in the search bar → select the check box and click Install.

Then remember to select the checkbox "Restart Jenkins when installation is complete and no jobs are running".

2.2 Configure the plugin:

After the installation is completed, select the job you would like to implement the masking on → then click Configuration *→ **Environment *→ **select Mask password and regexes → Define variables with values you would like to do the masking.

Go to Build steps → replace the variables above in the execute script.

Then run the test again and compare the differences.

Reference

Mask Passwords | Jenkins plugin

Video about Mask credentials in Jenkins from console output

Enable HTTPS for Jenkins on SUSE by using Apache httpd Reverse Proxy with Existing SSL Certificate

Tran Huynh An Duy (Andy) — Thu, 18 Dec 2025 12:39:02 +0000

1. Prerequisites

SUSE Linux server with Jenkins already installed and running on port 8080.

A domain name pointing to your server (e.g., abc.com).

An SSL certificate (Company certificate) has already been issued (e.g., .crt + .key files, and possibly a CA bundle).

Root or sudo privileges.

2. Install Apache httpd

sudo zypper refresh
sudo zypper install apache2 apache2-utils

Enable and start Apache:

sudo systemctl enable apache2
sudo systemctl start apache2

Check status:

systemctl status apache2

3. Enable Required Apache Modules

Apache needs proxy, proxy_http, ssl, and headers modules:

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod ssl
sudo a2enmod headers

Verify the module is already enabled

sudo apache2ctl -M | grep ssl

If you don’t see ssl_module (shared), then enable it:

Edit /etc/sysconfig/apache2, find the APACHE_MODULES= line and add ssl.Like:

APACHE_MODULES="... proxy proxy_http headers ssl ..."

Also ensure APACHE_SERVER_FLAGS includes SSL so SSL-vhost stuff is actually activated. Something like:

APACHE_SERVER_FLAGS="SSL"

Then reload apache modules / restart Apache:

sudo systemctl restart apache2

4. Place Your SSL Certificate

Copy your certificate and key files into a secure directory:

/etc/pki/tls/certs/abc.com.crt → your certificate

/etc/pki/tls/private/abc.com.key → your private key

/etc/pki/tls/certs/wildcard.abc.com_ca_bundle.crt (optional, if provided by CA)

5. Configure Apache VirtualHost for Jenkins

5.1 Create or edit a config file for the Jenkins service:

sudo nano /etc/apache2/vhosts.d/jenkins.conf

Add this configuration (replace plm-jenkins-dev.konecranes.com with your domain):

<VirtualHost *:80>    

ServerName plm-jenkins-dev.abc.com

Redirect permanent / https://plm-jenkins-dev.abc.com/

 </VirtualHost>  

<VirtualHost *:443>    

ServerName plm-jenkins-dev.konecranes.com
SSLEngine on    

SSLCertificateFile /etc/pki/tls/certs/wildcard.abc.com.crt
SSLCertificateKeyFile /etc/pki/tls/private/wildcard.abc.com.key  
SSLCertificateChainFile /etc/pki/tls/certs/wildcard.abc.com_ca_bundle.crt  

ProxyRequests     Off    

ProxyPreserveHost On    

AllowEncodedSlashes NoDecode     

<Proxy http://localhost:8080/jenkins*>
   Require all granted
</Proxy>

   ProxyPass         /jenkins http://localhost:8080/jenkins nocanon
   ProxyPassReverse  /jenkins http://localhost:8080/jenkins
   RequestHeader set X-Forwarded-Proto "https"
   RequestHeader set X-Forwarded-Port "443"
</VirtualHost>

5.2 Edit the Apache service config file to let it run on the 443 port :

sudo nano /etc/apache2/httpd.conf

Add this configuration (add from the top of the file):

ServerName plm-jenkins-dev.abc.com

6. Restart Apache

Verify the previous configuration:

sudo apache2ctl configtest → If you see y Syntax OK

Restart the service

sudo systemctl restart apache2

7. Configure Jenkins

Ensure Jenkins is aware it’s behind HTTPS.

7.1 Open Jenkins config file:

sudo nano /etc/sysconfig/jenkins

Add this line if missing:

JENKINS_ARGS="--webroot=/var/cache/$NAME/war --httpPort=$HTTP_PORT --prefix=/jenkins"
Environment="JENKINS_PREFIX=/jenkins"

7.2 Open the Jenkins start-up configuration file (from Jenkins 2.3xx we have to apply the change here)

sudo systemctl edit jenkins

Add the value below (from the 3rd rows at the top)

[Service]
Environment="JENKINS_PREFIX=/jenkins"

Then restart the service

sudo systemctl daemon-reload
sudo systemctl restart jenkins

7.3 Inside Jenkins UI → Manage Jenkins → Configure System → set Jenkins URL:

http://plm-jenkins-dev.abc.com/jenkins

7.4 Restart Jenkins:

sudo systemctl restart jenkins

Verify Open in browser:

https://plm-jenkins-dev.abc.com/jenkins

You should see Jenkins running securely with your SSL certificate.

(Optional) Block direct port 8080 access:

sudo firewall-cmd --permanent --remove-port=8080/tcp
sudo firewall-cmd --reload

Jenkins installation in SUSE server

Tran Huynh An Duy (Andy) — Thu, 18 Dec 2025 11:57:00 +0000

1.1 Install pre-requisites and Jenkins service

To install Jenkins, you need to install Java as the 1st requirement.

Below is the script to install the prerequisites for the server running SUSE Linux Enterprise Server. After you have received the handover from the server team, access to server by SSH (via Putty application) and run the script below.

Note: If you can start from the 1st step in the script below, you might need help from the local service team to install the rest (from step 1 to 5) from their side. After that, you can continue from section 1.2.

#jenkins-install.sh

#1.Update system
sudo zypper up

#2.Install java
sudo zypper install -y java-21-openjdk java-21-openjdk-devel

#3.Add repo Jenkins
sudo zypper addrepo -f http://pkg.jenkins.io/opensuse-stable/ jenkins

#4.Install Jenkins 
sudo zypper install -y jenkins

#5.Enable Jenkins service
sudo systemctl enable jenkins
sudo systemctl start jenkins
sudo systemctl status jenkins


#6.Checking the port 8080 open in server (Local Address:Port)
sudo ss -tlpun

Note: If you get the error related to Permission denied, you can check the picture in the Troubleshooting section.

1.2. Configuration for Jenkins

Access to the Jenkins Server via IP address is available with the default port, 8080.

Example: http://Server-IP-address:8080/

Then enter the Administrator password value from this path: /var/lib/jenkins/secrets/initialAdminPassword

By using the code below:

cat /var/lib/jenkins/secrets/initialAdminPassword

Select Install suggested plugins

Wait until the plugin installation is completed

Create 1st Admin user

Start using Jenkins

Enter the public IP address or domain name of the server (including port 8080)

Home screen of Jenkins

1.3 Change Jenkins's working folder

To change the current working folder from /var/lib/jenkins to /opt/devops/jenkins,

do the following steps:

Change working folder steps

#1. Stop Jenkins service
sudo systemctl stop jenkins

#2. Create the new directory
sudo mkdir -p /opt/devops/jenkins

#3. Grant permission for jenkins user to new folder
sudo chown -R jenkins:jenkins /opt/devops/jenkins

#4. Copy existing Jenkins data (included jobs, plugins,...)
sudo rsync -avzh /var/lib/jenkins/ /opt/devops/jenkins/

#5. Update Jenkins configuration
sudo nano /etc/sysconfig/jenkins

##5.1 Find JENKINS_HOME="/var/lib/jenkins" -> Change to JENKINS_HOME="/opt/devops/jenkins"
##5.2 Find WorkingDirectory=/var/lib/jenkins -> WorkingDirectory=/opt/devops/jenkins (Optional if available)

##5.3 If the steps 5.1 does not work, you should also edit file usr/lib/systemd/system/jenkins.service and replace 2 parameters as steps 5.1 and 5.2 in that file.

#6. Reload systemd:
sudo systemctl daemon-reload

#7. Start Jenkins again
sudo systemctl start jenkins

#8. Verify new home directory
ps aux | grep jenkins

The expectation can be checked by the step No. 8 above.

or inside Jenkins UI → Manage Jenkins → System Information → Environment Variables → JENKINS_HOME

Cross-check the existing job already there in the new folders:

ls /opt/devops/jenkins/jobs

Troubleshooting

While installing the pre-requisite or Jenkins, if you face the problems below:

Solution: contact the local service team, who provided the access to your ADM account or your Infodba account.

Day 15: Decoupling and Connecting - Mastering AWS VPC Peering with Terraform

Tran Huynh An Duy (Andy) — Wed, 10 Dec 2025 11:37:42 +0000

Today, we successfully implemented VPC Peering using Terraform, a foundational skill for anyone managing complex cloud infrastructure. This mini-project demonstrated how to securely connect separate network environments across different regions.

What is VPC Peering?

VPC peering is a networking connection between two Virtual Private Clouds (VPCs) that enables instances in either VPC to communicate with each other privately. This is achieved as if the instances were on the same network.

Why is this necessary?

In enterprise environments, you often need to share resources or data securely between different departments, environments (like Dev and Prod), or even AWS accounts. For example, a web server located in one VPC might need to securely retrieve data from a backend database residing in a separate VPC.
Without VPC peering, that data connection would have to traverse the Internet Gateway, exposing the traffic to the public internet—a major security risk. VPC peering allows this communication to occur over a private AWS backbone, ensuring security and low latency.

The Non-Negotiable Rules of Peering

Before establishing any connection, two rules are critical:
1. Non-Overlapping CIDR Ranges: The IP address ranges (CIDRs) of the two VPCs must not overlap. For our project, we used 10.0.0.0/16 for the primary VPC and 10.1.0.0/16 for the secondary VPC.
2. Bidirectional Connection: VPC peering is not a single connection; it requires a bidirectional setup. You must initiate a connection from VPC A to VPC B, and then establish a corresponding connection from VPC B back to VPC A.

Terraform Implementation: Multi-Region Setup

Our project involved provisioning VPCs in different AWS regions (US East 1 and US West 2). To manage resources across these distinct regions in a single Terraform configuration, we utilized aliases in our provider definition:

# Define Primary Provider (US East 1)
provider "aws" {
  region = var.primary_region 
  alias  = "primary"
}

# Define Secondary Provider (US West 2)
provider "aws" {
  region = var.secondary_region 
  alias  = "secondary"
}

Establishing the Connection

We used the aws_vpc_peering_connection resource to create the connection request (A to B) and then set up a corresponding resource to accept the request (B to A, or the acceptor).

# VPC Peering Connection Request (Primary to Secondary)
resource "aws_vpc_peering_connection" "primary_to_secondary" {
  provider      = aws.primary
  vpc_id        = aws_vpc.primary_vpc.id
  peer_vpc_id   = aws_vpc.secondary_vpc.id
  peer_region   = var.secondary_region
  auto_accept   = false # The destination must explicitly accept
}

# VPC Peering Connection Acceptor (Secondary accepts Primary's request)
resource "aws_vpc_peering_connection_accepter" "secondary_acceptor" {
    provider = aws.secondary
    vpc_peering_connection_id = aws_vpc_peering_connection.primary_to_secondary.id
    auto_accept = true # Auto-accept the incoming request
}

The Crucial Routing Step

Creating the peering connection is only half the battle. To allow traffic to flow, we must update the Route Tables in both VPCs. Each VPC's route table must be configured to send traffic destined for the peer VPC's CIDR range (e.g., 10.1.0.0/16) to the newly created VPC peering connection ID.
This crucial step, combined with correctly configured security groups (allowing ICMP/Ping traffic between the VPC CIDR blocks), ensures successful private connectivity.

Advanced Caveat: Transitive Peering

During the project, we encountered a vital architectural lesson: Transitive Peering does not work.

If you connect:

VPC A to VPC B
VPC B to VPC C

Traffic will not automatically flow from VPC A to VPC C. To enable A and C to communicate privately, you must create a dedicated VPC peering connection between A and C as well. This is a key consideration when designing larger, interconnected networks.

By successfully provisioning and configuring VPC peering, we established secure, private communication between two instances running in separate regions, a vital step toward building complex, enterprise-grade infrastructure with Terraform.

Day 14: Real-World Terraform - Hosting a Static Website with S3 and CloudFront

Tran Huynh An Duy (Andy) — Tue, 09 Dec 2025 09:33:00 +0000

Having covered the fundamental concepts of Terraform, from file structure and type constraints to functions and data sources, it’s time to apply that knowledge to a real-time project: hosting a static website using a private S3 bucket backed by a CloudFront Distribution. We will build this entire, production-ready architecture using Terraform.

Why We Use CloudFront in Front of S3

While S3 buckets can host static websites directly, this approach is problematic in production. Direct S3 serving often incurs higher data transfer and storage costs, requires the bucket to be publicly accessible (a major security risk), and makes the website vulnerable to DoS attacks.
To solve these challenges, we introduce Amazon CloudFront, a Content Delivery Network (CDN).
CloudFront creates Edge Locations—points of presence geographically close to your users worldwide. These edge locations serve two key purposes:

1. Speed and Cost: Edge locations cache frequently accessed files (like HTML, images, and CSS). When a user requests a file, it is served instantly from the nearest edge location rather than traversing continents to reach the origin S3 bucket. This reduces latency and lowers data transfer costs.

2. Security: By using CloudFront, we can keep the S3 bucket private. Only the CloudFront distribution is granted access to fetch files from the S3 bucket, ensuring users cannot access the bucket directly.

The Secure Architecture

Our goal is to provision an architecture that provides secure access to static files.
Architectural Flow: We need to establish authentication and authorization between the CloudFront Distribution and the private S3 bucket.
• Origin Access Control (OAC): This resource acts as the identity management system that allows only the specified CloudFront Distribution to access the private S3 bucket. This is the recommended, modern approach, replacing the deprecated Origin Access Identity (OAI).
• Bucket Policy: We must attach a bucket policy to the S3 bucket to authorize the CloudFront distribution to perform necessary actions, such as Get and List files, which are required for caching at the edge locations.

Diagram of the Concept:

Imagine users accessing the site globally. Instead of hitting the centralized S3 bucket directly, they hit the closest CloudFront edge location. If the file is cached (TTL, or Time To Live, default is around 24 hours), it’s served immediately. If not, the edge location securely retrieves the file from the private S3 bucket.

Terraform Implementation: Key Resources

To realize this architecture, we define several Terraform resources:

S3 Bucket & Public Access Block: A private aws_s3_bucket is created, and we use the aws_s3_bucket_public_access_block resource to ensure public access is entirely disabled.
Origin Access Control (OAC): Defines the secure identity for CloudFront interaction.
S3 Bucket Policy: This resource grants the OAC identity s3:GetObject and other necessary permissions using a complex JSON structure, which must be encoded using the jsonencode() function in Terraform.
Uploading Files: Instead of manually uploading static files, we use the aws_s3_object resource combined with iteration functions to upload everything in the local www directory.
CloudFront Distribution: This resource defines the global CDN, referencing the OAC ID and setting cache behaviors (e.g., allowing only GET and HEAD methods).

This comprehensive approach allows us to deploy secure, high-performance static websites without manually touching the AWS console. While we implemented the core components, follow-up tasks include adding Route 53 DNS records, using an SSL certificate from ACM, and configuring custom error pages for a complete production solution.

Embed the video "14/30 - Host A Static Website In AWS S3 And Cloudfront (using terraform)" from @piyushsachdeva

Day 13: Decoupling Your Infrastructure - Mastering Terraform Data Sources

Tran Huynh An Duy (Andy) — Tue, 09 Dec 2025 09:16:24 +0000

We’ve spent the last few days mastering expressions and functions to make our code reusable. Today, we tackle a critical concept for enterprise environments: Data Sources.

Data Sources allow your Terraform configuration to read information about resources outside of your current configuration—meaning resources that already exist in your AWS environment but were not created by this specific Terraform code. This ability to reference pre-existing components is crucial for decoupling and sharing infrastructure across multiple teams.

Why Data Sources? The Need for Decoupling

When provisioning new infrastructure, you often rely on shared or existing components. For example, if you need to provision an EC2 instance, you need several pieces of external information:

1. AMI ID: The Amazon Machine Image (AMI) is necessary for the instance, but the AMI itself is not stored inside your AWS environment; it's pulled from an external, often open-source, repository. You don't want to hardcode the AMI ID, which changes with new releases; you want the latest one dynamically.

2. Shared VPC/Subnets: In an enterprise setting, infrastructure like Virtual Private Clouds (VPCs) and subnets are often pre-provisioned and shared among development, QA, and DevOps teams. When creating new resources, you must reference these existing network components rather than creating new ones.

Data Sources solve this by fetching these details dynamically, eliminating the need for manual intervention or hardcoding IDs.

How Data Sources Work: The Syntax

To use a Data Source, you use the data keyword followed by the resource type (e.g., aws_vpc) and a local name you define:

data "aws_vpc" "vpc_name" {
  // configuration (filters) to find the specific VPC
}

The data source then provides outputs (like ID, CIDR block, etc.) that your resources can reference.

Case Study: Referencing Existing Resources

Here is how we use Data Sources to pull information about an existing VPC, a subnet, and the latest Linux AMI.

1. Finding the Shared VPC and Subnet
Instead of hardcoding the VPC ID, we use filters to look up the default VPC based on its Name tag:

Code Example (VPC Data Source):
data "aws_vpc" "vpc_name" {
  filter {
    name   = "tag:Name"
    values = ["default"] // Assumes the default VPC is tagged 'default' [7]
  }
}

// Data Source for Subnet within the shared VPC
data "aws_subnet" "shared" {
  filter {
    name   = "tag:Name"
    values = ["subnet A"] // Finds the subnet tagged 'subnet A' [8]
  }
  vpc_id = data.aws_vpc.vpc_name.id // Reference the ID found by the VPC data source [8]
}

In this configuration, we successfully filter existing resources in the AWS environment based on tags. We haven't created the VPC or subnet, yet we are correctly referencing the existing ones.

2. Finding the Latest AMI ID

We use the aws_ami data source to fetch the most recent Amazon Linux 2 image:
Code Example (AMI Data Source):

data "aws_ami" "linux2" {
  most_recent = true // Ensures we get the latest release [10]
  owners      = ["amazon"] // Owned by Amazon, not us [10]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-gp2"] // Uses a wildcard filter for the name [10]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

3. Provisioning the EC2 Instance

Finally, we use the outputs from these data sources in our resource definition:
Code Example (EC2 Instance using Data Source Outputs):

resource "aws_instance" "example_instance" {
  instance_type = "t2.micro" 

  // Use the AMI ID retrieved by the data source
  ami           = data.aws_ami.linux2.id 

  // Use the Subnet ID retrieved by the data source
  subnet_id     = data.aws_subnet.shared.id 
}

This demonstrates how Data Sources provide the necessary external IDs (AMI ID, Subnet ID) without hardcoding, allowing the instance to be provisioned correctly using existing, shared infrastructure.

Data Sources are fundamental to creating flexible and maintainable configurations, especially in environments where infrastructure management is shared across multiple teams. @piyushsachdeva

Day 12: The Power of Reusability (Part 2) - Mastering Advanced Terraform Functions

Tran Huynh An Duy (Andy) — Mon, 08 Dec 2025 13:01:16 +0000

This is Day 12, a direct continuation of our deep dive into Terraform's built-in functions. If Day 11 focused on basic string and collection manipulation, today we unlock the true power of HCL by mastering validation, type conversion, numeric calculations, and file handling.
Understanding these functions is essential for building robust, secure, and highly dynamic infrastructure configurations.

1. Validation Functions: Enforcing Constraints

Validation functions ensure that the input values provided by the user meet specific criteria before Terraform attempts to execute a plan. This prevents failures later in the provisioning process.
Validation rules are placed directly within the variable declaration, using a validation block which contains a condition and an error_message.

A. Checking Length and Logic

You can combine the length() function with logical operators (&& for logical AND) to enforce length constraints on input strings, such as ensuring an instance type name is between 2 and 20 characters.
Code Example (Length Validation):
variable "instance_type" {
default = "t2.micro"

validation {
condition = length(var.instance_type) >= 2 && length(var.instance_type) <= 20
error_message = "Instance type must be between 2 and 20 characters."
}
}

B. Regular Expressions and can()

For more complex pattern matching, the can() function, combined with regex() (regular expression), allows you to define stringent requirements, such as ensuring an instance type starts with 't2' or 't3'.

C. String Endings (endswith) and Sensitive Data

The endswith() validation function ensures a string meets a naming convention, such as requiring a backup variable name to end with _backup.
Furthermore, you can flag variables as sensitive by setting sensitive = true in the declaration. This prevents the value from being printed in logs or standard output during terraform plan and apply. While this is a critical security feature, it’s important to remember that the value is still saved (Base64 encoded, not truly encrypted) in the state file, so exercise caution.

2. Type Conversion and Collection Functions

Type conversion functions allow you to change the structure of data, which is often necessary when manipulating collections.

A. Combining and Making Unique (concat and toset)

While the concat() function combines two or more lists, the resulting list may contain duplicate values. To eliminate duplicates and ensure a collection of only unique values, you must convert the list into a set using the toset() function.
Code Example (Removing Duplicates):

variable "user_locations" {
  type    = list(string)
  default = ["us-east-1", "us-east-1", "us-west-1"] 
}
variable "default_location" {
  type    = list(string)
  default = ["us-west-2"]
}

locals {
  all_locations   = concat(var.user_locations, var.default_location) 
  # Result: ["us-east-1", "us-east-1", "us-west-1", "us-west-2"] (Duplicates remain)

  unique_locations = toset(local.all_locations)
  # Result: {"us-east-1", "us-west-1", "us-west-2"} (Set removes duplicates)
}

3. Numeric Functions and Spread Operators

Numeric functions handle mathematical operations. Functions like sum(), max(), and min() are designed to work on numbers, but when operating on complex collections like tuples or lists, they require additional iteration or the use of a spread operator.

Calculating Absolute Values and Totals

The abs() function returns the absolute value of a number (converting negative values to positive). To apply abs() to every element in a list (like a list of monthly costs where negative values represent credits), you must use a for loop to iterate through the collection.

The Spread Operator (...)

To use aggregate functions like max() or min() on a list of numbers, you must use the spread operator (...) after the list variable. This operator tells Terraform to treat the elements of the list as individual numbers, allowing the function to work correctly.
Code Example (Calculating Max Cost):

locals {
  # Assuming positive_cost is a list of absolute values like 
  max_cost = max(local.positive_cost...)
  # The '...' spreads the list elements, treating them as arguments: max(200, 100, 75, 50)
}

This technique also allows for calculating the average cost, which involves dividing the total sum by the length of the list.

4. File and Date/Time Functions

A. File Handling

Terraform can interact with local files. The fileexists() function checks if a file is present. You can read the contents of a file using the file() function, and if the file contains structured data (like JSON), you can use jsondecode() to parse it into an accessible HCL map.

B. Date and Time

The timestamp() function returns the current timestamp. The formatdate() function allows you to reformat this timestamp string into a desired structure (e.g., YYYY-MM-DD), which is useful for creating unique, time-based resource names.

Mastering these advanced functions solidifies your ability to write highly dynamic, reusable, and secure configurations, moving you beyond simple resource declarations from @piyushsachdeva

Day 11: The Power of Reusability - Mastering Terraform Functions (Part 1)

Tran Huynh An Duy (Andy) — Mon, 08 Dec 2025 12:35:04 +0000

Welcome to Day 11 of our 30 Days of AWS Terraform series! After structuring our projects and mastering Meta Arguments, we are now diving into a core concept that enables highly efficient and reusable infrastructure code: Terraform Functions.
If you're new to programming concepts, a function is simply a tool that makes life easier by allowing you to reuse code repeatedly. Instead of writing the same four lines of code 10 times, you wrap them once inside a function (like sum) and call that function whenever needed, passing different inputs each time.

Crucially, Terraform is not a full-fledged programming language; it is the HashiCorp Configuration Language (HCL). Because of this, you cannot create your own custom functions in Terraform; you can only use the rich library of inbuilt functions provided by Terraform.
These functions are categorized into types such as string, numeric, collection, type conversion, and more. Today, we explore some of the most practical and frequently used functions.

1. String Manipulation Functions

String functions are used to clean, format, and modify text inputs, ensuring they meet specific infrastructure requirements (like S3 bucket naming conventions).

Lower, Upper, Trim, and Replace

• lower() and upper(): These convert a string to all lowercase or all uppercase characters, respectively.
◦ Example: lower("HELLO WORLD") returns "hello world".
• trim(): Removes specified characters from a string.
◦ Example: trim(" AWSTF ", "f") removes the character 'f' from the string, but leaves the spaces if space is not specified as the character to trim.
• replace(): Substitutes an occurrence of a character or substring with a new character.
◦ Example: replace("hello world", " ", "-") returns "hello-world".
A powerful technique is nesting functions to perform multiple operations in one line. For instance, to ensure a project name is lowercase and uses hyphens instead of spaces:

Code Example (Nesting lower() and replace()):
locals {
  # First, replace spaces with hyphens; then, convert the result to lowercase.
  formatted_project_name = lower(
    replace(var.project_name, " ", "-")
  )
}

output "formatted_name" {
  value = local.formatted_project_name 
}

If var.project_name is "Project Alpha Resource", the output becomes "project-alpha-resource". This is crucial for handling naming constraints (like those for S3 buckets, which must be lowercase and cannot contain spaces).

2. Collection Functions: Managing Groups

Collection functions help manage groups of data (like lists and maps) for tasks such as calculating length or combining inputs.
Length, Concat, and Merge
• length(): Calculates the number of elements in a list.
•** concat(): Combines two or more lists or tuples into a single list.
• **merge(): Combines two or more maps (key-value pairs) into a single map. If duplicate keys exist, the last provided map takes precedence.
The merge() function is excellent for combining default tags and environment-specific tags:

Code Example (Merging Maps):

# variables.tf contains var.default_tags and var.environment_tags (both are maps)

locals {
  new_tag = merge(
    var.default_tags, 
    var.environment_tags
  )
}

resource "aws_s3_bucket" "first_s3" {
  # ... bucket configuration ...
  tags = local.new_tag # This applies all merged tags
}

This single tag block now contains all key-value pairs from both input maps.

3. Lookup Function: Dynamic Environment Selection

The lookup() function is vital for selecting configuration values based on an input key, often used to determine environment-specific settings.
The Structure:
The lookup function requires three arguments: lookup(map, key, default).
1. Map: The entire collection of data (e.g., instance sizes for Dev, Staging, Prod).
2. Key: The value you are looking up (e.g., the current environment name).
3. Default: A fallback value if the key is not found (e.g., t2.micro).
Code Example (Instance Sizing):

variable "instance_sizes" {
  type = map(string)
  default = {
    dev    = "t2.micro"
    staging = "t3.small"
    prod   = "t3.large"
  }
}
variable "environment" {
  default = "prod"
}

locals {
  instance_size = lookup(
    var.instance_sizes, 
    var.environment, 
    "t2.micro" # Default value if key is missing
  )
}

If var.environment is set to "prod", the lookup function returns "t3.large". If it is set to an undefined environment like "production", it returns the default value, "t2.micro".

4. Iteration and Splitting Data

split() and for Expressions
When inputs are provided as a single comma-separated string, you must convert them into a list for iteration. The split() function takes a separator (e.g., comma) and a string, returning a list of substrings.
The for expression (different from the for_each meta argument) then allows you to iterate through that list to create a structured collection of output values, such as security group rules.
Code Example (Splitting String into List and Iterating):

variable "allowed_ports" {
  default = "80,443,8080" # This is a single string
}

locals {
  port_list = split(",", var.allowed_ports) # Output: ["80", "443", "8080"]

  sg_rules = {
    for port in local.port_list : port => {
      name        = "port-${port}"
      description = "Allow traffic on port ${port}"
    }
  }
}

# The 'sg_rules' local is now a map of rules, structured for resource definition.

This process converts a simple string into a complex map of security group rules, demonstrating how functions and expressions combine for powerful data manipulation.

Mastering these functions is the key to writing concise, repeatable, and maintainable Terraform configurations. Thanks @piyushsachdeva

Day 10: Mastering Terraform Expressions - Conditional Logic, Iteration, and Collection

Tran Huynh An Duy (Andy) — Wed, 03 Dec 2025 18:35:39 +0000

This is Day 10, and we are diving deep into Terraform Expressions. Expressions are a fundamental concept, providing powerful, concise syntax that helps avoid rewriting code repeatedly. While similar in function to what we will later cover in Terraform functions, expressions offer immediate utility in making your configurations dynamic and reusable.
We focus today on three key expression types: Conditional, Dynamic Block, and Splat.

                ┌───────────────────────────────────────────┐
                │   Terraform Expressions                   │
                │   Simplify Configurations & Reduce Repetition │
                └───────────────────────────────────────────┘
                                │
   ┌────────────────────────────┼────────────────────────────┐
   │                            │                            │
   ▼                            ▼                            ▼
┌─────────────────┐      ┌────────────────────┐       ┌────────────────────┐
│ Conditional      │      │ Dynamic Blocks     │       │ Splat Expressions  │
│ Expressions      │      │ (nested iteration) │       │ (retrieve multiple │
│ (true/false logic)│     │                    │       │ attributes)        │
└─────────────────┘      └────────────────────┘       └────────────────────┘
   │                        │                            │
   ▼                        ▼                            ▼
┌─────────────────┐   ┌────────────────────┐       ┌────────────────────┐
│ Syntax:          │   │ Syntax:            │       │ Syntax:            │
│ condition ?      │   │ dynamic "block" {  │       │ resource.*.attr    │
│ true : false     │   │   for_each = list  │       │                    │
└─────────────────┘   │   content {...}     │       └────────────────────┘
                      └────────────────────┘
   │                        │                            │
   ▼                        ▼                            ▼
┌─────────────────┐   ┌────────────────────┐       ┌────────────────────┐
│ Example:         │   │ Example:           │       │ Example:           │
│ EC2 instance     │   │ Security Group     │       │ Collect EC2 IDs    │
│ type selection   │   │ ingress rules      │       │ into a list        │
└─────────────────┘   └────────────────────┘       └────────────────────┘

1. Conditional Expressions: True or False Logic

A conditional expression is a simple, one-line piece of syntax that functions like an if/else statement found in most programming languages. It evaluates a condition and returns one of two specified values (the true value or the false value).

The Structure:
The conditional expression is always written as: condition ? true_value : false_value. The colon (:) separates the true value from the false value.

Code Example (Environment Selection):

This is most commonly used to set resource attributes based on environment variables. For instance, we can specify that if the environment is dev, a smaller instance type is used; otherwise, a larger one is selected.

variable "environment" {
  type    = string
  default = "staging" // Will select the false value
}

resource "aws_instance" "example" {
  // If var.environment == "dev" is TRUE, use T2 micro.
  // If FALSE (e.g., staging/prod), use T3 micro.
  instance_type = var.environment == "dev" ? "t2.micro" : "t3.micro" [4, 6]

  // ... other configuration ...
}

As demonstrated in the demo, changing var.environment from dev to anything else (like staging or prod) immediately switches the instance type in the execution plan.

2. Dynamic Blocks: Nested Iteration

Dynamic blocks are essential when you need to write a nested block with multiple values within a resource definition. They help avoid manual repetition of configuration. This is frequently used for managing repeated elements, such as ingress or egress rules within an AWS Security Group.

The Structure and Iteration:

A dynamic block starts with the dynamic keyword, followed by a name (e.g., ingress). Inside, it uses a for_each argument to iterate over a collection (often a complex list of objects, like var.ingress_rules). The resource definitions must be placed within a content block.
When iterating, you access the attributes of the current element using the dynamic block name (e.g., ingress) and the special iterator object (value): ingress.value.from_port.

Code Example (Security Group Rules):

If we define two ingress rules (one for HTTP on port 80, one for HTTPS on port 443) in a list of objects variable, the dynamic block iterates through the list:

// Example Variable (List of Objects containing port, protocol, etc.) [8, 14]

resource "aws_security_group" "ingress_rule" {
  // ... other attributes ...

  dynamic "ingress" {
    for_each = var.ingress_rules // Iterates through the list of rules [11]

    content {
      from_port   = ingress.value.from_port [12] 
      to_port     = ingress.value.to_port [12]
      protocol    = ingress.value.protocol [12]
      cidr_blocks = ingress.value.cidr_blocks [12]
    }
  }
}
// This single block generates multiple ingress rules in the plan [15].

3. Splat Expressions: Retrieving Multiple Attributes

The splat expression is another powerful one-liner used to retrieve a list of attributes from a set of resources. This is most useful when dealing with resources that were created using the count meta-argument, meaning they exist as a collection.
The splat expression uses the star operator ().
The Structure:
The expression is written as: resource_list..attribute.

Code Example (Collecting Instance IDs):

If we use count = 2 to create two EC2 instances (aws_instance.example), the splat expression retrieves the ID attribute for both instances and collects them into a list:

locals {
  // Collects the 'id' attribute from all instances named 'example'
  all_instance_ids = aws_instance.example.*.id [16-18]
}

output "instances" {
  value = local.all_instance_ids [19]
  // Value will be known after apply [19].
}
This efficiently creates a list containing [id_of_instance_0, id_of_instance_1].

Mastering these expressions allows you to write truly dynamic and concise Infrastructure as Code. Make sure you complete the hands-on practice in the Day 10 GitHub repository to solidify your learning from @piyushsachdeva

Day 09 - Mastering Terraform Lifecycle Rules for Secure and Controlled Deployments

Tran Huynh An Duy (Andy) — Wed, 03 Dec 2025 17:34:18 +0000

Today, we are tackling a foundational yet powerful topic: Terraform Lifecycle Rules. These are meta-arguments provided by Terraform that do not configure the resource itself (like setting an AMI ID), but instead control how the resource behaves when it is created, destroyed, or updated.
Lifecycle rules are essential tools that improve security, enhance infrastructure manageability, and prevent accidental resource deletions or modifications.
Here is a breakdown of the key lifecycle rules and how they empower your infrastructure code.

                ┌───────────────────────────────────────────┐
                │   Lifecycle Rules in Terraform            │
                │   Improve Security & Manageability        │
                │   Prevent Accidental Deletions            │
                └───────────────────────────────────────────┘
                                │
   ┌────────────────────────────┼────────────────────────────┐
   │                            │                            │
   ▼                            ▼                            ▼
┌───────────────┐        ┌────────────────┐          ┌─────────────────┐
│ Controlling   │        │ Managing       │          │ Enforcing        │
│ Destruction & │        │ External       │          │ Dependencies     │
│ Downtime      │        │ Changes        │          │ (replace_...)    │
└───────────────┘        └────────────────┘          └─────────────────┘
   │                            │                            │
   ▼                            ▼                            ▼
┌───────────────┐        ┌────────────────┐          ┌─────────────────┐
│ prevent_destroy│        │ ignore_changes │          │ replace_triggered│
│ (no accidental │        │ (allow ops     │          │ (force EC2       │
│ deletions)     │        │ updates)       │          │ replacement)     │
└───────────────┘        └────────────────┘          └─────────────────┘
   │
   ▼
┌──────────────────────────────┐
│ create_before_destroy         │
│ (minimize downtime by         │
│ provisioning new before old)  │
└──────────────────────────────┘

                                ▼
                      ┌───────────────────────────┐
                      │ Validations               │
                      │ precondition / postcondition │
                      │ (check assumptions & enforce │
                      │ compliance after creation)   │
                      └───────────────────────────┘

1. Controlling Destruction and Downtime

Terraform offers precise control over when and how a resource is terminated, preventing costly mistakes and minimizing service interruptions.

A. Preventing Accidental Deletion (prevent_destroy)

Imagine managing a critical S3 bucket or database instance using Terraform. If someone accidentally runs terraform destroy, or if a configuration change implicitly requires the resource to be deleted, you want a safety net.
The prevent_destroy = true rule blocks any deletion of the associated resource. The destruction will fail unless the rule is explicitly updated back to false.

Code Example: Protecting a Critical Asset
resource "aws_s3_bucket" "my_critical_bucket" {
  bucket = "my-audit-logs-bucket"

  lifecycle {
    prevent_destroy = true 
  }
}

B. Minimizing Downtime (create_before_destroy)

When you update certain properties of a resource (like changing the AMI ID of an EC2 instance), Terraform often must destroy the old resource and create a new one to apply the change.
By default, the old resource might be destroyed first, leading to downtime. Setting create_before_destroy = true reverses this order: the new resource is created and fully provisioned before the previous one is destroyed. This ensures minimal downtime for your application.
If this rule is set to false, and the old resource is destroyed first, users will experience downtime. Furthermore, if the attempt to create the new resource fails (due to a bad request or unauthorized image, as shown in the demo), the existing service is lost without a replacement.

Code Example: Ensuring Continuity
resource "aws_instance" "example" {
  ami           = var.ami_id
  instance_type = var.instance_type

  lifecycle {
    create_before_destroy = true // New resource created before old one destroyed
  }
}

2. Managing External Changes (ignore_changes)

Often, specific resource attributes might need to be modified by external processes (e.g., auto-scaling mechanisms or manual operational changes) without Terraform constantly trying to revert those external changes.
The ignore_changes rule allows you to specify attributes that Terraform should ignore during subsequent planning and applying cycles.
A common example is an Auto Scaling Group (ASG). If the desired_capacity is set to 2 in Terraform, but an operations team manually scales it to 1, Terraform would normally try to revert it back to 2. By using ignore_changes, Terraform knows not to revert external updates to that specific field.

Code Example: Allowing External Updates
resource "aws_autoscaling_group" "asg" {
  desired_capacity = 2 
  // ... other configuration ...

  lifecycle {
    ignore_changes = [desired_capacity]
  }
}
// Terraform will not attempt to revert desired_capacity changes made outside its configuration [10].

3. Enforcing Dependencies (replace_triggered_by)

While Terraform handles implicit dependencies (when one resource uses an output of another), sometimes you need to enforce that a change in Resource A forces a replacement of Resource B, even if Resource B doesn't directly reference Resource A.
The replace_triggered_by rule creates this explicit forced dependency. For instance, if you make a change to a Security Group (SG) rule, you might want your associated EC2 instance to be replaced with a new one that inherits the updated SG configuration.

Code Example: Forcing Recreation
resource "aws_instance" "ec2_instance" {
  // ... configuration ...
  lifecycle {
    replace_triggered_by = [aws_security_group.app_sg.id] 
  }
}
// Any change to the app_sg security group will trigger the replacement of this EC2 instance [11].

4. Validations (precondition and postcondition)

Finally, lifecycle rules offer validation checks before or after a resource operation.
• Precondition: Validates assumptions before a resource is created (e.g., checking if the region specified for deployment is allowed).
• Postcondition: Validates resource attributes after it has been created (e.g., ensuring a newly created S3 bucket has a mandatory compliance tag for audit purposes). If the condition fails, an error message is thrown, blocking execution.

Mastering these rules provides a layer of operational security and control that goes beyond basic resource definition.
Embed the video "Day 9 - AWS Terraform Lifecycle Rules Explained" from @piyushsachdeva

Day 8: Mastering Terraform Meta Arguments - The Power of Control and Iteration

Tran Huynh An Duy (Andy) — Tue, 02 Dec 2025 12:51:06 +0000

Welcome back to the 30 Days of AWS Terraform challenge! We are diving into a crucial topic today: Meta Arguments. While standard resource arguments (like bucket or region) are provided by the specific provider (e.g., AWS), Meta Arguments are supplied by Terraform itself. They provide powerful ways to implement advanced logic, control deployment flow, and avoid writing external scripts.

Today, we focus on three essential meta arguments: depends_on, count, and for_each.

1. Controlling Sequence with depends_on

When you define multiple resources in a Terraform file, how does Terraform know the order in which to provision them? While Terraform often detects implicit dependencies (e.g., if Resource B uses an output from Resource A), sometimes you need to enforce a specific creation order,this is known as explicit dependency.
The depends_on meta argument establishes this explicit dependency. It ensures that Resource A is fully provisioned and healthy before Terraform proceeds to create Resource B.

Scenario Flow: Suppose you need a second resource (bucket_two) to only be created after the primary resource (bucket_one) is fully operational:

// Resource 1: Primary Bucket (Created First)
resource "aws_s3_bucket" "bucket_one" {
  // configuration details...
}

// Resource 2: Dependent Bucket (Waits for Resource 1)
resource "aws_s3_bucket" "bucket_two" {
  depends_on = [
    aws_s3_bucket.bucket_one
  ]
  // configuration details...
}

As demonstrated in our hands-on session, Terraform executes the creation of bucket_one first. Only once its creation is complete does it proceed with bucket_two.

2. Iteration for Lists using count

If you need to create multiple, identical resources such as 10 S3 buckets or 5 EC2 instances, you don't need to write the resource block 10 or 5 times. Instead, you use the count meta argument.
count works well when iterating over a variable defined as a list. Lists are ordered collections accessed by a numerical index starting at zero.
We can set count dynamically using the length() function on a list variable. To reference each element during the iteration, we use count.index.

Code Example (Creating Multiple Buckets from a List):

variable "bucket_names" {
  type = list(string)
  default = ["my-unique-bucket-1", "my-unique-bucket-2"]
}

resource "aws_s3_bucket" "bucket_one" {
  // Sets count to 2, based on the list size [10]
  count = length(var.bucket_names)

  // Iterates through the list using the index (0, 1, 2...) [10]
  bucket = var.bucket_names[count.index]
}

3. Iteration for Sets and Maps using for_each

While count is excellent for lists, it won't work effectively with sets or maps because they lack fixed indexes. For these scenarios, we use for_each, which acts like a specialized for loop.
for_each iterates through the elements of the set or map. When using for_each, we reference the elements using the special each object.

• Sets: In a set of strings, there is no key/value distinction. Therefore, each.key and each.value both refer to the content of the element.

• Maps: Maps are defined by distinct key-value pairs (like JSON syntax). When iterating a map, each.key accesses the map key (e.g., name), and each.value accesses the corresponding map value (e.g., Piyush).

Code Example (Creating Buckets from a Set):

variable "bucket_name_set" {
  type = set(string)
  default = ["set-bucket-a", "set-bucket-b"]
}

resource "aws_s3_bucket" "bucket_two" {
  // Iterates through every element in the set [11]
  for_each = var.bucket_name_set

  // In a set, key and value are the same [13]
  bucket = each.value 
}

Mastering these meta arguments allows you to write concise, reusable, and powerful Terraform configurations that efficiently manage dependency and repetition.

Ready to solidify your understanding? Make sure to complete the practical exercises and tasks available in the Day 8 GitHub repository from @piyushsachdeva

Day 7: Mastering Terraform Type Constraints - The Secret to Clean Variables

Tran Huynh An Duy (Andy) — Sun, 30 Nov 2025 19:47:08 +0000

On the day 06, we optimized our workflow by structuring our root module into separate files like main.tf and variables.tf. Today, we dive deeper into the world of variables, focusing specifically on Type Constraints.

Type constraints define the type of value that a variable can store. Understanding these types is crucial for creating robust and predictable infrastructure as code configurations. Variables are broadly categorized as either primitive (simple) or complex (multi-value).

The Primitives: Simple and Straightforward

Primitive types are the standard building blocks you use every day:
1. String: Used for text, strings must be enclosed in double quotes (e.g., name = "Piyush").
2. Number: Used for numerical values (e.g., setting the count argument for an EC2 instance).
3. Boolean (Bool): Represents truth values (true or false). Arguments like monitoring in an EC2 instance configuration often expect a boolean value.
If you do not explicitly set a type constraint, Terraform defaults the variable to the special type any.

Navigating Complex Types: Storing Multiple Values

Complex types are designed to store multiple values in a single variable. These require careful handling, as they are accessed either by index (position) or by key (name).

1. Lists and Sets

Both Lists and Sets store a sequence of values, all of the same data type (e.g., list(string) or set(string)).
• List: An ordered collection where the sequence is fixed. Lists are accessed by their index, starting at zero. Critically, lists allow duplicate values.
• Set: An unordered collection that does not allow duplicate values. Because the order is not fixed, sets cannot be accessed directly by their index. If you need to access a specific element in a set, you must first convert it to a list using a function like tolist().

2. Maps and Objects

Maps and Objects handle data as key-value pairs.
• Map: A collection of key-value pairs where all values must share the same data type, such as map(string). Maps are ideal for defining resource tags (e.g., tags = { environment = "dev" }). Maps are accessed using the key (e.g., var.tags.environment).
• Object: A more flexible structure than a map. Objects allow you to define key-value pairs where each key can have a different data type (e.g., region = string, instance_count = number). This is useful for grouping related configuration metadata. Objects are accessed via the key, just like a map (e.g., var.config.region).

3. Tuples

A Tuple is an ordered sequence designed to hold multiple different data types (e.g., a number, a string, and another number). The sequence of elements matters, as the values provided must match the data types defined by their position. Like lists, tuples are accessed by index.
By correctly specifying these type constraints, you not only improve readability but also ensure Terraform expects and receives the necessary data format for your infrastructure configuration.

Ready to put this into practice? Make sure you complete the hands-on exercise for Day 7 from @piyushsachdeva to solidify your understanding of how to access and manage these complex variables!