Forem: Kaye Alvarado

How to Pass the AZ-204 Microsoft Azure Developer Associate Exam

Kaye Alvarado — Thu, 29 Jan 2026 05:21:54 +0000

I was 10 months into a DevOps role (using Azure) before I took the AZ-204 Azure Developer Associate certification exam. I also had 6+ years of experience with AWS cloud with 6 AWS certifications under my belt (most of which has expired in the last year).

Comparing the two (AWS vs Microsoft), I can say that Microsoft has a better exam format that tests not just your ability to answer multiple-type and multi-select questions, but also your analysis, developer, and architecting capabilities. The exam format is 100 minutes long, with 48 questions (10 for two case studies, 38 for generic questions). There are simple coding questions (finding the right commands), selecting the right service, and implementation steps questions ensuring mastery of Azure development before gaining the coveted certification.

It was definitely harder than most of the AWS exams I took before (with the exception of AWS DevOps Professional, which is expected as the latter is pro-level). I am sharing a few tips below to give an overview of the exam.

1. Study, study, study!

This is not an exam that you can pass through memorization. It is better to be familiar with services (what they do and when to use them), navigation through the Azure portal, and real life implementation (may incur costs even with a free account). It is also recommended to be familiar with a few recommended cloud or hybrid architectures to be able to handle the *case study * sections well.

The path I took when studying goes like this:

Go through the Azure Developer Associate preparation in Microsoft Learn.
Take the practice assessment multiple times until you consistently earn around 78% or above in score.
Take the practice tests of Tutorials Dojo for Microsoft Azure Developer Associate. For me, TD has created a very similar experience to the actual exam having questions that are drag-and-drop, multi-select and drop-down for coding. Having gone through it definitely helped a lot in what to expect in the actual exam.
Take notes when reviewing your practice exams. Understand why an answer is incorrect and not just why something fits. It helps in the process of elimination during the exam.

2. Be familiar with Microsoft Learn Documentation

I didn't realize that Microsoft Learn can be accessed during the exam and just discovered it about 30 minutes in! Despite this, the exam is still time-crunched so being familiar with how to search through Microsoft documentation fast will help add in points.

3. Make use of marked for review

Always reserve time to review items that you are not 100% certain of. Sometimes, going through the whole exam will help you determine if you answered a few questions incorrectly (especially on question formats that are in series).

4. Do actual practice

The exam is not foundational, meaning it would be extremely hard to pass without an actual cloud experience. Be sure to at least create an Azure portal account and follow labs before taking the exam. Be sure to also be familiar with basic az commands as these appear pretty frequently in the exam.

If you have any questions for me, feel free to drop them in the comments section. Good luck!

Containers and Kubernetes

Kaye Alvarado — Mon, 12 May 2025 12:46:18 +0000

One of the more advanced topics in DevOps is Kubernetes. I have been in a DevOps role for a while before I truly grasped the concept. In this blog, I attempt to explain the concept (hopefully it's clear!).

First, let us clarify some terminologies where a lot of engineers get confused.

Containers, Images, and Kubernetes

Containers - are lightweight deployable packages that has the minimum required dependencies, code, and configuration to run an application.

Image - is the blueprint of containers. Basically, it is a non-running container and is usually stored in a container registry like ECR (Elastic Container Registry), Artifactory, or Docker Hub.

Kubernetes - is a container orchestration "platform". It manages containers through all it's magic across clusters.

Kubectl Commands

Kubectl is a command line tool that allows interaction with a Kubernetes cluster. Before you can interact with Kubernetes in the cloud, you would need to setup a kubeconfig file in your local machine with either aws eks (for AWS) or az aks (for Azure).

For AWS

aws configure
aws eks update-kubeconfig --region <aws-region> --name <cluster-name>

Replace with your AWS region (ex. us-east-1).
Replace with your EKS cluster name.

For Azure

az login
az aks get-credentials --resource-group <resource-group> --name <cluster-name>

Replace with your Azure Resource Group name.
Replace with your AKS cluster name.

After running these commands, you should have a kubeconfig file setup. For MAC, this usually lives on the following path: ~/.KUBE/config.

Below are some of the common `kubectl` commands to know:

kubectl apply -f <file.yaml> -n <namespace> → Deploy a resource from a YAML manifest

kubectl logs -f <pod-name> -n <namespace> → View logs from a pod

kubectl exec -it <pod-name> -n <namespace> -- bash → Open an interactive shell in a running container

kubectl get events → Displays events such as pod scheduling, container creation, scaling actions, failures, or errors.

All the Commands

Below are some basic kubernetes resources and their corresponding kubectl commands.

Pod – The smallest deployable unit in Kubernetes.

#List all pods
kubectl get pods -n <namespace>
#Get detailed info on a specific pod
kubectl describe pod <pod-name> -n <namespace>

Deployment – Manages replicated pods and ensures their availability.

#List all deployments
kubectl get deployments -n <namespace>
#Detailed view of a deployment
kubectl describe deployment <deployment-name> -n <namespace>
#Save a definition to a file
kubectl get deployment <deployment-name> -n <namespace> -o yaml >> <file_name>
#Edit the deployment directly
kubectl edit deployment <deployment-name> -n <namespace>

ReplicaSet – Ensures a specified number of pod replicas run at all times.

#View all replica sets
kubectl get replicasets 
#Get details on a specific ReplicaSet
kubectl describe replicaset <replicaset-name>

Service – Provides network access to a set of pods.

#View all services
kubectl get services 
#Get detailed info on a service
kubectl describe service <service-name>

ConfigMap – Stores configuration data in key-value pairs.

#List all ConfigMaps
kubectl get configmaps 
#View details of a ConfigMap
kubectl describe configmap <configmap-name>

Secret – Stores sensitive information like passwords or API keys.

#List all secrets
kubectl get secrets 
#Get details on a secret
kubectl describe secret <secret-name>

*PersistentVolume (PV) *– Represents storage in Kubernetes.

#View available persistent volumes
kubectl get pv 
#Get details on a specific PV
kubectl describe pv <pv-name>

PersistentVolumeClaim (PVC) – Requests storage from a PersistentVolume.

#View all PVCs
kubectl get pvc 
#Get details of a PVC
kubectl describe pvc <pvc-name>

Namespace – Provides a way to logically separate resources.

#View all namespaces
kubectl get namespaces 
#Get details on a namespace
kubectl describe namespace <namespace-name>

Node – Represents a worker machine in the cluster.

#View all nodes in the cluster
kubectl get nodes
#Get details on a node
kubectl describe node <node-name>

As always, concepts are easier to understand as you build a project in Kubernetes. Here is another blog I wrote previously that shows the container deployments with DevOps concepts: https://dev.to/aws-builders/build-a-container-package-for-your-react-app-with-docker-and-github-actions-4nf5.

Creating Signed mTLS Certificates

Kaye Alvarado — Fri, 14 Feb 2025 12:53:55 +0000

First, generate a private key file with 2048 or 4096 key size. This will prompt you for a passphrase for the private key.

openssl genrsa -aes256 -out privatekey.pem 4096

Optionally, you can decrypt this private key. This will prompt you for the passphrase to decode the key.

openssl rsa -in privatekey.pem -out privatekey-decrypted.pem

If you want to directly create an (unencrypted) private key, you may run the following command:

openssl genrsa -out privatekey.pem 2048

Then, create a Certificate Signing Request from the private key.

openssl req -new -sha256 -key privatekey.pem -out request.csr

Using this, you can then use a signer tool such as Venafi to sign the key. A certificate authority, can sign the certificate (essentially, adding a chain to the certificate).

For self-signed certificates, you may use the following command:

openssl x509 -req -days 365 -in request.csr -signkey privatekey.pem -out publiccertificate.pem

All the MongoDB Commands that You Need to Know

Kaye Alvarado — Fri, 24 Jan 2025 08:44:45 +0000

Here is a collection of common NoSQL queries and the mongodb commands needed for them:

1. Exact Match

Collection Name: users
Object Field: first_name
Search for: Kaye

db.getCollection('users').find({"first_name":"Kaye"})

2. Like Match

Collection Name: users
Object Field: last_name
Search for: varad

db.getCollection('users').find({"last_name":/varad/})

All the Git Commands that You Need to Know

Kaye Alvarado — Tue, 07 Jan 2025 05:29:52 +0000

Here is a collection of common scenarios of code management and the git commands needed for them:

1. Clone a repository to your local branch

git clone https://github.com/<organization>/<repository_name>.git

2. Check if the current state of your local branch

git status

3. Commit a change from your local to the remote repository

After doing edits (add/update/delete) to the files in your local repository, you can make them available to other developers by pushing your changes to the remote branch. First, stage the changes:

git add <path>

Alternatives

git add --all
git add .
git add ../subpath

You can then add a commit message to your check-in. Some developer teams follow the Conventional Commit specification when adding commit messages, which dovetails SemVer and makes it easier to publish release notes based on widely known standards.

git commit -m "commit message"

After adding a commit messsage, you can then push the change to a remote repository. If the remote_branch_name already exists in the remote repository, a simple git push command will do.

git push -u origin <remote_branch_name>

4. Revert to a previous commit in the remote branch

There are times when you accidentally push a commit to an incorrect remote branch and wishes to revert to a previous commit. You can follow the following steps in order to do this.
First identify the commit id by checking the git history

git log

You can then switch your local to an older commit_id

git reset --hard <commit_id>

Then, force push the current state of the branch to the remote branch. Make sure that there are no restrictions in the remote branch against force pushes.

git push -f origin <remote_branch_name>

5. Reset commit history in a git repository

These sequence of steps will essentially reset the git commit history of the remote repository by overwriting the main branch (which contains all commit history) with a fresh branch that contains all the files of the main branch:

git checkout --orphan temp-branch
git add -A
git commit -m "reset history"
git checkout main
git reset --hard temp-branch
git branch -D temp-branch
git push -f origin main

6. Deleting local and remote branches

[for local branch]
git branch -D [branch-name]
[for remote branch]
git push origin -d [branch-name]

7. Squash multiple commits

View the list of commits in the current branch with git log, then identify the start of the commit that needs to be squashed.

222bb33  Adjust tests
99aa111  add feature
def5678  fix: type
abc1234  initial commit

In the results above, I want to combine the commits from def5678 to 222bb33 to a single commit. With this, start interactive rebase with the commit before the first in the range which should be abc1234

git rebase -i abc1234

In the editor that opens, change the top commit as pick and change the subsequent ones that needs to be squashed to that commit as squash. Then, save and exit.

pick def5678  fix: type
squash 99aa111  add feature
squash 222bb33  Adjust tests

Push to the remote branch.

git push --force-with-lease

And that's it! Let me know if you have questions in any of the use-cases!

Are there any other common scenarios in code management that is useful to you? Leave them at the comment section for others!

Build a Container Package for your React App with Docker and GitHub Actions

Kaye Alvarado — Thu, 10 Oct 2024 06:52:15 +0000

This is the first part of a series for Code Pipeline: Deploying a React App in AWS. There's a lot of blogs already around this topic but there's a particular use-case that I want to document in an easy-to-follow guide for DevOps Engineers.

Below are some of the technologies that I will briefly touch on in the entirety of this series (some at a later point): #containers #docker #dockerfile #react #GitHubActions #ecr #ecs #fargate #iam

What am I Doing?

The image above depicts the sequence of steps that we're trying to do here. Taking from a React UI code, we will build a simple pipeline in Github Actions to package it into a container using a Dockerfile and store the package in Amazon ECR (Elastic Container Registry) for future deployment which we'll tackle in the next parts of the series.

Create a React Application

React has a Quick Start guide here to do the first step. In my case, I want to create a React App based on a TypeScript template so I will append --template typescript to the creation command.

npx create-react-app react-ui --template typescript

This will create a directory called react-ui in the current folder with an initial project structure of the application. Navigate to the folder and from here, run the app locally on your machine.

cd react-ui
npm start

Now, let's create a Dockerfile in the same directory and put the following code:

FROM node:20-alpine as build
WORKDIR /app
ENV PATH=/app/node_modules/.bin:$PATH
COPY ./package*.json /app/
RUN npm install
COPY . /app
RUN npm run build

EXPOSE 3000

CMD ["npm", "start"]

npm install ensures that all dependencies are installed in the container runtime. As best practice, we can add a .dockerignore file in the react-ui directory so that the script will explicitly ignore files or directories that are not needed when moving files around. For example, I can add node_modules in .dockerignore so that it will not be copied in the container being built when I run the copy command.

Build and Tag the Image: From the root directory, run the following command to build and tag the image:

docker build -f Dockerfile -t react-ui:latest .

Then, check the details:

$ docker image ls
REPOSITORY   TAG         IMAGE ID       CREATED         SIZE
react-ui     latest      63ac15re6a37   1 minute ago    135MB

Test Run the Application: Run the container using the following command:

docker run -it -p 80:3000 --rm react-ui:latest

You can use any port when running the container to route to the exposed port 3000. You can then use this same port when testing the application in a web browser http://localhost:80

Think like a DevOps Engineer: Build a Pipeline for Reusability

Now, everytime a software developer updates the react app code, it doesn't make sense for someone to manually run these commands on their machine to deploy the changes to a production server.

It is recommended to store the code in a repository like GitHub. Then we can make use of a workflow to automatically run scripts ensuring accuracy in deployments.

In my GitHub Workflow, I will trigger a pipeline that has the following steps:

Checkout the react code from GitHub to the GitHub runner
Generate a random tag to the package
Build the image, then push the image to ECR

Checkout the Code from GitHub

The action below is one of the commonly used actions in building a GitHub Actions pipeline. This will simply download the code being built to the GitHub runner that spins up.

      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
          ref: ${{ github.ref_name }}

Generate a Random Tag to the Package

There are several ways on how to uniquely tag a package in ECR. For my use-case, I'd like a simple logic to add a date in the tag so I will add an action to pull the date.

      - name: "Get current date"
        id: date
        run: echo "::set-output name=date::$(date +'%Y%m%d')"

Using this, I can create an environment variable that can be used on other actions with this string, along with another random number such as the github.run_number.

IMAGE_TAG: ${{ steps.date.outputs.date }}-${{ github.run_number }}

Now, let's slightly modify the Dockerfile with a few more commands. Assume that the react application now includes packages that needs to be downloaded from 3rd party package repositories. We would need to include an .npmrc file temporarily to the Dockerfile to allow the image runtime to pull the package with authorization to the package repository.

FROM node:20-alpine AS build
ARG AUTH
ARG EMAIL
WORKDIR /app
ENV PATH=/app/node_modules/.bin:$PATH
COPY ./package*.json /app/
COPY ./.npmrc /app/
RUN echo "//registry.npmjs.org/:_auth=$AUTH" >> .npmrc && \
    echo "email = $EMAIL" >> .npmrc && \
    echo "always-auth = true" >> .npmrc && \    
    npm install --force && \
    rm -f .npmrc
COPY . /app

FROM node:20-alpine 
WORKDIR /app
COPY --from=build /app /app

RUN npm run build

EXPOSE 3000

CMD ["npm", "start"]

Notice here that I added two arguments to pass the authentication at runtime. I will then remove the .npmrc file from the package after the npm install. I also added another stage to also remove the auth from the docker history (basically doing multi-stage builds as explained here). There are other more modern ways to solve this like using Docker build secrets, details are also explained on the linked blog. Wow, I like saying "also"! 😅

Build the Image and Push it to Amazon ECR

Now that everything is ready let's continue with the pipeline. To further interact with other AWS services from the runner, we will need to authenticate in AWS and also (also?!) login to Amazon ECR.

      - name: "Configure AWS credentials"
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ASSUME_ROLE }}
          aws-region: us-east-1
          role-session-name: ReactDeployment
          role-duration-seconds: 3600
          role-skip-session-tagging: true

      - name: "Login to Amazon ECR"
        id: ecr-config
        uses: aws-actions/amazon-ecr-login@v1
        with:
          mask-password: true

Now my docker commands will look something like this:

      - name: "Build & tag, then push image to Amazon ECR"
        env:
          ECR_REGISTRY: ${{ steps.ecr-config.outputs.registry }}
          ECR_REPOSITORY: ${{ env.IMAGE_NAME }}
          IMAGE_TAG: ${{ steps.date.outputs.date }}-${{ github.run_number }}
        run: |
          docker build -f Dockerfile --build-arg AUTH=${{ secrets.AUTH }} --build-arg EMAIL=${{ secrets.EMAIL }} -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

As a bonus, I added some logic below on how I intend to identify my "latest" image in ECR, which is based on the date that it was pushed:

      - name: Get latest image tag
        id: get-latest-tag
        run: |
          image=$(aws ecr describe-images \
            --repository-name react-ui \
            --output text \
            --query 'sort_by(imageDetails,&imagePushedAt)[-1].imageTags[0]')
          echo "latest=$image" >> $GITHUB_ENV

That's it! Stay tuned on the next part of this series where I intend to explain one of the options to deploy this image in AWS. See you then!

K8s QuickBites: Helm Basics

Kaye Alvarado — Mon, 26 Aug 2024 01:12:00 +0000

Hey there! Welcome to another quick bites blog on Kubernetes. Read time, 2 minutes! I like to keep it short and serve as quick references only when doing common tasks as a K8s administrator.

The focus of this discussion is on Helm.

What is Helm?

Think about bringing up an end-to-end application in Kubernetes with multiple yaml files that includes various resources such as deployments, service accounts, secrets, and others. A simple application would have some complexity in management, but as it becomes larger, it would be very difficult to manage. This is what helm is trying to solve.

Helm is nothing but a package manager for Kubernetes. Helm is used to manage Charts, which are packages of pre-configured Kubernetes resources making application management in Kubernetes way easier.

Installation of helm is pretty straightforward and options can be viewed here.

Basic Helm Commands

First, search and download from a helm repository to your local machine. You can also update it if it already exists.

$helm search repo <repository>
$helm repo update <repository>

To view the existing repositories on your local machine, you can use the list command

$helm ls 
NAME         CHART VERSION   APP VERSION.  DESCRIPTION                                       
chart/name   1.0.0           1.0.0         App Description

Install Helm Charts

You can install a helm chart overriding the default values with a values.yaml file.

$helm install <chart> <repo> -n <namespace> -f <path to values.yaml file>

Once installed, you can then verify the deployments, daemonsets, or other resources that was installed

$kubectl get deploy -n <namespace>
$kubectl get ds -n <namespace>
$kubectl get pods -n <namespace>

You can also use the values used in the helm installation and modify this for a later update

$helm get values <release-name> -n <namespace>

Upgrade Helm Charts

Everytime you upgrade a helm chart, a revision is added and this allows you to easily rollback to a previous version if an upgrade becomes problematic. List the versions with the list command (for the current deployed chart), or the history command.

$helm list -n <namespace>
NAME   NAMESPACE  REVISION  UPDATED     STATUS   CHART  
chart  namespace  2         <datetime>  deployed chart-1.0.0
$helm history <chart> -n <namespace>
REVISION    UPDATED                     STATUS      CHART                   APP VERSION DESCRIPTION     
1           Thu May 23 18:53:23 2024    superseded  chart-0.9.9 0.9.9       Install complete
2           Mon Jun  3 19:52:28 2024    superseded  chart-1.0.0 1.0.0       Upgrade complete

To rollback to a previous version, you can use the rollback command

$helm rollback <chart> <version> -n <namespace>

There may be times when a simple upgrade will fail due to a major change in the helm package. An option here is to do an uninstall and install.

$helm uninstall <chart> -n <namespace>
$helm install <chart> <repo> -n <namespace> -f <path to values.yaml file>

...and that's it! Happy helming! 😄

K8s QuickBites: Creating Secure TLS Certificates for Kubernetes Deployments

Kaye Alvarado — Wed, 21 Aug 2024 12:50:47 +0000

This is the first of a series of blogs about Kubernetes Fundamentals, providing a quick step-by-step guide for each management scenario that is relevant when maintaining K8s workloads.

A Kubernetes application can be secured by adding a an SSL certificate to the deployment configuration. This quick bites shows how to manually do this.

Pre-requisites

It is assumed that the reader has set up their kube config file in addition to having the following tools available in their machine:

openssl
kubectl

Let's dive in to the steps!

Creating the Private Key and Certificate Files

Create a private key file using an encryption of your choice

openssl genrsa -aes256 -out privatekey.pem 4096

Now, create a certificate signing request (csr) from the key. A series of questions will come after this command prompting for details of the certificate such as country, state, city, domain name, etc.

openssl req -new -sha256 -key privatekey.pem -out certreq.csr

Then get a trusted certificate authority (CA) to sign your certificate. Optionally, you can also make the certificate self-signed. Download the generated crt tls.crt and key file. To get the unencrypted privatekey, decrypt it. You can use openssl to do this.

#for CA-signed
openssl rsa -in privatekey.pem -out tls.key
#for self-signed
$ openssl req -x509 -new -nodes -days 365 -key privatekey.pem -out tls.crt -subj "/CN=domain.com"

Rename the private key to tis.key. By this time you would have the two files needed for the K8s deployment.

$ls tls*
tls.crt tls.key

Now, create the secret in the namespace that you need it for, replacing secretname and namespace with the proper values respectively

kubectl create secret tls <secretname> --cert=tls.crt --key=tls.key -n <namespace>

A secret will be created in the namespace you specified. You can verify this with the commands below:

kubectl get secrets -n <namespace>
kubectl get secret <secretname> -n <namespace>

The secret will have values for tls.crt and tls.key. You can decode this using base64 to view the value.

echo <tls.crt value>|base64 --decode
echo <tls.key value>|base64 --decode

Adding the TLS secret to the Deployment
—--
The second part is how you will update the K8s deployment to include the certificate files and update the config to use this as the application’s certificate.

First, get the deployment name that you need to edit. Then open the file for editing.

kubectl get deployments -n <namespace>
kubectl edit deployment <deployment_name> -n <namespace>

In the volumes section, add an item for the secret

      volumes:
      - name: <secretname_used_for_deployment>
        secret:
          defaultMode: 420
          secretName: <secretname_in_secrets>

In the volumeMounts section, add the mount path where the certs will be stored

        volumeMounts:
        - mountPath: /etc/ssl/certs
          name: <secretname_used_for_deployment>
          readOnly: true

Once done, you can quickly verify if the certificate is present in the path you provided.

kubectl get pods -n <namespace>
kubectl exec -it <gateway_pod_name> -- ls /etc/ssl/certs

Depending on the configuration of the deployment, you can point it to pick up the certificate from the path of the certificate and private key paths. Deployments may use different directories so just replace the /etc/ssl/certs directory when applicable.

...and that's it!

Let me know if there are any quick bites requests you want me to publish next!

Using GenerativeAI as a Mentor for your Career Growth

Kaye Alvarado — Wed, 22 Nov 2023 14:05:55 +0000

I have been mentoring for the AWS community for a while now, specifically on helping people get AWS certified, and the most common question asked by learners revolves around which appropriate certification to take. Right now, there are 11 distinct AWS certifications across the foundational, associate, professional, and specialty levels to choose from. These certifications cover a broad range of AWS cloud knowledge areas including architecture, operations, security, machine learning, networking, databases, data analytics, and development.

If you ask me, there simply is not one answer to this question. When I first started learning AWS, this was a question I also asked.

Google Does Not Have All the Answers!

Now, this is not the first time when I tried to search for the answer online, but the amount of results is too overwhelming. Instead of the results helping me, it ended up with me having to sort through the results. I had to spend a few minutes or hours reading about each article, get different perspectives, and then finally decide on which certification to take (my original question).

I can add more keywords to my search, but this proves to be a mistake at times as it starts to get more articles related to words I put in the search bar, which aren't really relevant to what I'm looking for.

The Art of Prompt Engineering

With the not-so-recent AI boom, we are introduced to an advanced Large Language Model that is ChatGPT. It is an artificial intelligence system that can interact in a conversation through natural language.

Now, why are LLMs better than a normal browser search? LLMs have conversational ability. It can clarify context and has the ability for conversation. You can ask follow-up questions if you are not satisfied with the initial answer.

With LLMs, prompt engineering comes into play. It is important to know the HOW of asking or structuring text to be best interpreted by a generative AI model.

Chatbots is just one of the advances made with AI. There are also other technologies of GenAI like Image or Text Generation that already proved to be useful in a lot of ways.

Exploring AI is also becoming easier each day. Recently, AWS announced the release of PartyRock, an Amazon Bedrock Playground. Amazon Bedrock is a fully managed service that makes base models from Amazon and third-party model providers accessible through an API. With PartyRock and even with zero code, you can build apps that can generate text or images based on pre-defined prompts depending on your use case.

If AI is so smart, it can answer my hardest questions!

Going back to the original question that I get asked a lot, how do I start learning for the AWS Career Path that I want to take? With this, I created the AWS Career Path Learning Guide (using PartyRock). It uses pre-made prompts that will guide the user on a study plan toward a recommended AWS Certification.

PartyRock: https://partyrock.aws/u/kayea/vT62aROcc/AWS-Career-Path-Learning-Guide

The app also suggests a study guide depending on the amount of time you want to allocate in achieving the AWS certification.

It provides resources to assist in your study plan

Finally, there is a chatbox to ask additional questions on the recommendations:

You can remix any existing app created by other users, or create your own app from scratch. Try to explore #partyrock on your own and let me know what you think about it in the comments!

Building a Pipeline to Deploy Terraform Updates

Kaye Alvarado — Sun, 10 Sep 2023 14:43:41 +0000

This is the last part of the series for Infrastructure as Code: Deploying a Demo App on EC2 with AWS Image Builder and Terraform. On this part, I will focus more on GitHub Actions and how to utilize this CI/CD platform to deploy updates to your Infrastructure code.

Start with a Pre-defined Workflow File

GitHub Actions already provides a sample template to start. Simply search for the sample template in Actions tab, and click on the Configure button.

This will create a terraform.yml file with all the required steps for a Terraform deployment.

Let's walk through each one.
1. The Trigger
This part indicates different GitHub actions to trigger the workflow. The default actions triggers it with a push and pull request action. Since I want to trigger the workflow manually, I added a workflow dispatch action.

name: 'Terraform'

on:
  push:
    branches: [ "main" ]
  pull_request:
  workflow_dispatch:

2. Jobs
The next part will be the actions that will run. Below is the initialization of the GitHub runner (ubuntu-latest image) that will be spun up as the workflow runs.

jobs:
  terraform:
    name: 'Terraform'
    runs-on: ubuntu-latest
    environment: production

The other parts below have definitions in the sample file on what their purpose is:

steps:
    # Checkout the repository to the GitHub Actions runner
    - name: Checkout
      uses: actions/checkout@v3

    # Install the latest version of Terraform CLI and configure the Terraform CLI configuration file with a Terraform Cloud user API token
    - name: Setup Terraform
      uses: hashicorp/setup-terraform@v1
      with:
        cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}

    # Initialize a new or existing Terraform working directory by creating initial files, loading any remote state, downloading modules, etc.
    - name: Terraform Init
      run: terraform init

    # Checks that all Terraform configuration files adhere to a canonical format
    - name: Terraform Format
      run: terraform fmt -check

    # Generates an execution plan for Terraform
    - name: Terraform Plan
      run: terraform plan -input=false

One customization that needs to be done is to create the Terraform API token (TF_API_TOKEN) which will be saved in GitHub secrets as it is an authentication header that will be used. We can generate a token by following this Terraform documentation: https://developer.hashicorp.com/terraform/tutorials/cloud-get-started/cloud-login. Type terraform login and type yes on the prompt.

$ terraform login
Terraform will request an API token for app.terraform.io using your browser.

If login is successful, Terraform will store the token in plain text in
the following file for use by subsequent commands:
    C:\Users\kayea\AppData\Roaming\terraform.d\credentials.tfrc.json

Do you want to proceed?
  Only 'yes' will be accepted to confirm.

  Enter a value: yes


---------------------------------------------------------------------------------

Terraform must now open a web browser to the tokens page for app.terraform.io.

If a browser does not open this automatically, open the following URL to proceed:
    https://app.terraform.io/app/settings/tokens?source=terraform-login


---------------------------------------------------------------------------------

Generate a token using your browser, and copy-paste it into this prompt.

Terraform will store the token in plain text in the following file
for use by subsequent commands:
    C:\Users\kayea\AppData\Roaming\terraform.d\credentials.tfrc.json

Token for app.terraform.io:
  Enter a value:

On the browser, login to Terraform cloud, and you will be redirected to this page. You can type a name to identify this token, and set various expiration dates.

You can now save this token under GitHub Secrets

Go back to the GitHub actions template and commit the change:

Since the push action triggers the workflow, you would see that updating the code will trigger the action:

3. Create an AWS credential
You'll notice that on the initial run, this would immediately fail on Terraform initialize. This is because we haven't configured any AWS credentials on the workflow. We can follow this documentation, or follow along below:

Before this can be done, we need to create an IAM role. Go to the AWS management console and create a role for Web Identity, adding the fields.

AWS also made it available to pre-generate the trust policy to be added to the role

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Principal": {
                "Federated": "arn:aws:iam::111111111111:oidc-provider/token.actions.githubusercontent.com"
            },
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": [
                        "sts.amazonaws.com"
                    ]
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": [
                        "repo:coderkaye/*"
                    ]
                }
            }
        }
    ]
}

Now add the GitHub action below and add the ARN of the role created.

- name: Configure AWS credentials from Test account
      uses: aws-actions/configure-aws-credentials@v3
      with:
        role-to-assume: arn:aws:iam::11111111111:role/aws-githubactions
        aws-region: us-east-1

You also need to update the permissions of id-token to write

permissions:
  id-token: write
  contents: read

On this run, it will not automatically apply the Terraform code, but show the plan.

4. Final Updates
You can now update your pipeline to add specific GitHub Actions triggers. Some best practices for Infrastructure pipeline are below:

Set a manual trigger of the workflow. We do not ever want to accidentally deploy infrastructure without proper review.
Add tests. One Terraform feature is to be able to test the linting of your terraform code. This is one good test to add on top of other tests.
Add approval checks. You can add notifications to your CI/CD pipeline to ensure that someone in authority is able to review the infrastructure being deployed before the infrastructure is actually updated.

If you have any questions or if any part is unclear, feel free to shoot a comment below!

Building a Highly Available EC2 Infrastructure with Terraform

Kaye Alvarado — Mon, 14 Aug 2023 15:31:15 +0000

This is a getting started guide that extends Terraform's Infrastructure as Code (IaC) Build Tutorial to building a CD (Continuous Delivery) pipeline in order to update an infrastructure based on updates to the IaC code. I will go through the same tutorial in order for the reader to follow through without having to go back and forth across both guides. I will also be using an AMI (Amazon Machine Image) that was created as an output of the blog on the first part of this series.

The following infrastructure will be built based on this guide:

Prerequisites

Terraform is installed
AWS CLI is installed
AWS Account and credentials that has access to create AWS resources

I previously wrote about the setup steps of these 3 prerequisites here.

Basics of Terraform

Terraform is a tool for creating Infrastructure as Code (IaC). IaC as a concept helps manage infrastructure with configuration files instead of using the AWS dashboard. The benefits of using IaC in managing your infrastructure are the following:

Consistent infrastructure across environments
Versioning of changes
Reusable and shareable Infrastructure modules

A comprehensive getting-started guide for using Terraform with AWS can be found here.

Terraform Commands

In using Terraform, the four basic commands to keep in mind are the following:

Initialize - will install plugins that Terraform needs to manage the infrastructure code.
Plan - previews the changes that Terraform will make to match your configuration.
Apply - make the planned changes.
Destroy - destroy all infrastructure defined in code.

Building the Terraform Code, and Getting Familiar with Terraform Commands

First, create a main.tf file with the following contents:



provider "aws" {
    region = var.aws_region
}

terraform {
    backend "s3" {
        bucket = "bitscollective"
        region = "us-east-1"
        key    = "awsEC2.tfstate"
    }
}

From above code, we are defining aws as the provider and defining a terraform state file named awsEC2.tfstate that will be stored in the s3 bucket bitscollective.
Then create a vars.tf file with the following contents.



variable "aws_region" {
    type    = string
    default = "us-east-1"
}

This simply creates a variable "aws_region" that can be referenced from this context. Now let's initialize the code.

Terraform Init



kayea@JARVIS MINGW64 ~/workspace/aws-terrraform-ec2app (main)
$ terraform init

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding latest version of hashicorp/aws...
- Installing hashicorp/aws v5.12.0...
- Installed hashicorp/aws v5.12.0 (signed by HashiCorp)

Terraform 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 Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

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

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

Terraform Plan

From here, you'll notice that a .terraform directory is created with a terraform.tfstate file. A providers folder with a terraform executable is also downloaded to the folder.

Now, let's add more code to the main.tf file:



resource "aws_instance" "app_server" {
  ami           = "ami-830c94e3"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

Then from the command line, run terraform plan



kayea@JARVIS MINGW64 ~/workspace/aws-terrraform-ec2app (main)
$ terraform plan

Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.app_server will be created
  + resource "aws_instance" "app_server" {
      + ami                                  = "ami-830c94e3"
      + arn                                  = (known after apply)
      + associate_public_ip_address          = (known after apply)
      + availability_zone                    = (known after apply)
      + cpu_core_count                       = (known after apply)
      + cpu_threads_per_core                 = (known after apply)
      + disable_api_stop                     = (known after apply)
      + disable_api_termination              = (known after apply)
      + ebs_optimized                        = (known after apply)
      + get_password_data                    = false
      + host_id                              = (known after apply)
      + host_resource_group_arn              = (known after apply)
      + iam_instance_profile                 = (known after apply)
      + id                                   = (known after apply)
      + instance_initiated_shutdown_behavior = (known after apply)
      + instance_lifecycle                   = (known after apply)
      + instance_state                       = (known after apply)
      + instance_type                        = "t2.micro"
      + ipv6_address_count                   = (known after apply)
      + ipv6_addresses                       = (known after apply)
      + key_name                             = (known after apply)
      + monitoring                           = (known after apply)
      + outpost_arn                          = (known after apply)
      + password_data                        = (known after apply)
      + placement_group                      = (known after apply)
      + placement_partition_number           = (known after apply)
      + primary_network_interface_id         = (known after apply)
      + private_dns                          = (known after apply)
      + private_ip                           = (known after apply)
      + public_dns                           = (known after apply)
      + public_ip                            = (known after apply)
      + secondary_private_ips                = (known after apply)
      + security_groups                      = (known after apply)
      + source_dest_check                    = true
      + spot_instance_request_id             = (known after apply)
      + subnet_id                            = (known after apply)
      + tags                                 = {
          + "Name" = "ExampleAppServerInstance"
        }
      + tags_all                             = {
          + "Name" = "ExampleAppServerInstance"
        }
      + tenancy                              = (known after apply)
      + user_data                            = (known after apply)
      + user_data_base64                     = (known after apply)
      + user_data_replace_on_change          = false
      + vpc_security_group_ids               = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

───────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't
guarantee to take exactly these actions if you run "terraform apply" now.

Terraform Apply
This will show that the code is attempting to add a new resource. Now, run terraform apply.



Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

Enter a value of yes



aws_instance.app_server: Creating...
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]
aws_instance.app_server: Still creating... [30s elapsed]
aws_instance.app_server: Creation complete after 36s [id=i-0a5d2d786793f8176]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Go to EC2 in the AWS dashboard, and the created instance should now show up here.

In S3, you will see that the state file have been created. This file will keep track of any changes done to the code. Keeping this file in a remote location such as S3 ensures that any remote server will follow a single source of truth for any updates to the infrastructure code.

Terraform Destroy

To destroy all created resources, you can run terraform destroy. Terraform destroy command ensures that all created resources are removed.



Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

Terraform destroy command ensures that all created resources are removed.



  Enter a value: yes

aws_instance.app_server: Destroying... [id=i-0a5d2d786793f8176]
aws_instance.app_server: Still destroying... [id=i-0a5d2d786793f8176, 10s elapsed]
aws_instance.app_server: Still destroying... [id=i-0a5d2d786793f8176, 20s elapsed]
aws_instance.app_server: Still destroying... [id=i-0a5d2d786793f8176, 30s elapsed]
aws_instance.app_server: Still destroying... [id=i-0a5d2d786793f8176, 40s elapsed]
aws_instance.app_server: Destruction complete after 43s

Destroy complete! Resources: 1 destroyed.

Note that destroying the infrastructure does not remove the created terraform state file in the s3 bucket.

Terraform Modules

Let's continue with building the rest of the infrastructure with an introduction to Terraform modules. Terraform modules are nothing but putting together infrastructure code into logical reusable groups to allow re-use on other parts of the code.

Download the rest of the project from github.

Here, you'll see that I grouped the infrastructure code under one folder named ha-application. Ultimately, I wanted to be able to re-use this module when deploying the same infrastructure code across multiple environments (dev, qa, staging, prod).

Under this folder, there's a vars.tf file that would have default values, but can be overwritten when calling the module so that the values can be updated when deploying across environments.

Going back to the main code, I'm invoking the module and passing the required variables which is also referenced in the main code's vars.tf file.



module "application" {
   source               = "./modules/ha-application"
   aws_region           = var.aws_region
   imageid              = var.imageid
   availability_zones   = var.availability_zones
   vpc_id               = var.vpc_id
}

Deploying the code
Since the code have significantly changed and would require new plugins, we need to re-run terraform init again. After this, we can go directly to terraform apply to check out the resources being created.



kayea@JARVIS MINGW64 ~/Workspace/aws-terrraform-ec2app (main)
$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:        
  + create

Terraform will perform the following actions:

  # module.application.aws_alb.application-lb will be created
  + resource "aws_alb" "application-lb" {
      + arn                                         = (known after apply)
      + arn_suffix                                  = (known after apply)
      + desync_mitigation_mode                      = "defensive"
      + dns_name                                    = (known after apply)
      + drop_invalid_header_fields                  = false
      + enable_deletion_protection                  = false
      + enable_http2                                = true
      + enable_tls_version_and_cipher_suite_headers = false
      + enable_waf_fail_open                        = false
      + enable_xff_client_port                      = false
      + id                                          = (known after apply)
      + idle_timeout                                = 60
      + internal                                    = (known after apply)
      + ip_address_type                             = (known after apply)
      + load_balancer_type                          = "application"
      + name                                        = "application-lb"
      + preserve_host_header                        = false
      + security_groups                             = [
          + "sg-0c9234a6c5f976d95",
          + "sg-3ab9a217",
        ]
      + subnets                                     = [
          + "subnet-51813e1c",
          + "subnet-d33cd6f2",
        ]
      + tags_all                                    = (known after apply)
      + vpc_id                                      = (known after apply)
      + xff_header_processing_mode                  = "append"
      + zone_id                                     = (known after apply)
    }

  # module.application.aws_alb_listener.http-listener will be created
  + resource "aws_alb_listener" "http-listener" {
      + arn               = (known after apply)
      + id                = (known after apply)
      + load_balancer_arn = (known after apply)
      + port              = 80
      + protocol          = "HTTP"
      + ssl_policy        = (known after apply)
      + tags_all          = (known after apply)

      + default_action {
          + order            = (known after apply)
          + target_group_arn = (known after apply)
          + type             = "forward"
        }
    }

  # module.application.aws_alb_target_group.http will be created
  + resource "aws_alb_target_group" "http" {
      + arn                                = (known after apply)
      + arn_suffix                         = (known after apply)
      + connection_termination             = false
      + deregistration_delay               = "300"
      + id                                 = (known after apply)
      + ip_address_type                    = (known after apply)
      + lambda_multi_value_headers_enabled = false
      + load_balancing_algorithm_type      = (known after apply)
      + load_balancing_cross_zone_enabled  = (known after apply)
      + name                               = "application-tg"
      + port                               = 80
      + preserve_client_ip                 = (known after apply)
      + protocol                           = "HTTP"
      + protocol_version                   = (known after apply)
      + proxy_protocol_v2                  = false
      + slow_start                         = 0
      + tags_all                           = (known after apply)
      + target_type                        = "instance"
      + vpc_id                             = "vpc-cf89b1b5"

      + health_check {
          + enabled             = true
          + healthy_threshold   = 2
          + interval            = 15
          + matcher             = "200"
          + path                = "/"
          + port                = "80"
          + protocol            = "HTTP"
          + timeout             = 5
          + unhealthy_threshold = 3
        }
    }

  # module.application.aws_autoscaling_group.application-asg will be created
  + resource "aws_autoscaling_group" "application-asg" {
      + arn                              = (known after apply)
      + availability_zones               = [
          + "us-east-1a",
          + "us-east-1d",
        ]
      + default_cooldown                 = (known after apply)
      + desired_capacity                 = 2
      + force_delete                     = false
      + force_delete_warm_pool           = false
      + health_check_grace_period        = 300
      + health_check_type                = (known after apply)
      + id                               = (known after apply)
      + ignore_failed_scaling_activities = false
      + load_balancers                   = (known after apply)
      + max_size                         = 2
      + metrics_granularity              = "1Minute"
      + min_size                         = 0
      + name                             = "application-asg"
      + name_prefix                      = (known after apply)
      + predicted_capacity               = (known after apply)
      + protect_from_scale_in            = false
      + service_linked_role_arn          = (known after apply)
      + target_group_arns                = (known after apply)
      + vpc_zone_identifier              = (known after apply)
      + wait_for_capacity_timeout        = "10m"
      + warm_pool_size                   = (known after apply)

      + launch_template {
          + id      = (known after apply)
          + name    = (known after apply)
          + version = "$Latest"
        }
    }

  # module.application.aws_launch_template.application-template will be created
  + resource "aws_launch_template" "application-template" {
      + arn                    = (known after apply)
      + default_version        = (known after apply)
      + id                     = (known after apply)
      + image_id               = "ami-070d7322559e500ee"
      + instance_type          = "t2.micro"
      + latest_version         = (known after apply)
      + name                   = "application-template"
      + name_prefix            = (known after apply)
      + tags_all               = (known after apply)
      + update_default_version = true
      + vpc_security_group_ids = [
          + "sg-0c9234a6c5f976d95",
        ]
    }

Plan: 5 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

After this, let's checkout the resources created.

Launch Template contains the EC2 configuration and references the ami we created previously.
Target Groups contains a reference to the EC2 instances were traffic will be forwarded to.

Auto-scaling Group contains the scaling configurations for high-availability
The Load Balancer will be forwarding traffic to the target defined.

Also notice that the application load balancer will have a DNS endpoint which we can now load in the browser (application-lb-1968702359.us-east-1.elb.amazonaws.com)

A better architecture will use https and have an SSL certificate.

As always, destroy the infrastructure after testing to ensure you are not being charged unnecessarily. And that's it! Stay tuned for my next update (where I'll be creating a pipeline in Github to run the Terraform commands on a runner instead of my machine)!

Building a Reusable Image Pipeline with AWS Image Builder

Kaye Alvarado — Sun, 13 Aug 2023 17:17:23 +0000

Maintaining a secure, up-to-date AMI (Amazon Machine Image) used to be a tedious, and expensive process of running the latest updates on a running EC2 machine, and creating an image based off of this EC2 machine. If any required step is missed such as stopping any service, the image created will not work as intended and can sometimes waste an engineer's time looking through logs and finding the issue.

In December 2019, AWS introduced Image Builder that aims to solve these problems and allow users to create an image pipeline at no cost, except for the underlying resources used by the service.

What is EC2 Image Builder?

EC2 Image Builder is an AWS service that simplifies the building, testing, and deployment of Virtual Machine and container images for use on AWS or on-premises. Image builder has the capability to create an image with customization with pre-built templates available, allow testing on the image, and export the image making it accessible across regions and/or across accounts.

This is a walkthrough on the different steps of building an image pipeline to ultimately produce a secure, working image of an application.

Creating the Image Pipeline

To get started, navigate through the Image Builder service in AWS. On the left pane, click on Image pipelines and click on the Create image pipeline to start building.

1. Specify Pipeline Details

On the first step, specify the pipeline details such as Pipeline name, description. Here, you can also specify a Build schedule to instruct image builder to build a new version of the AMI on a regular/cron-based schedule. You can also choose to trigger the pipeline if there is a dependency update on the components that you specify.

2. Creating a Recipe

Next step is for the creation of the image recipe. As a recipe contains the ingredients list and steps in creating a final food product, an image recipe is a document defining the components to be applied to the base images to create the desired configuration for the output image. If a recipe needs to be modified, a new version must be created with the updated components

If you already created an image recipe prior to building the image pipeline, you can just select it here. If building the recipe for the first time, you can follow along the steps. Image type can either be an existing AMI or a Docker image. Also add a name and description to easily identify this recipe. Note that you can update the working directory at this stage. I've updated mine to /var/tmp to test this out.

Going back to the image recipe, I'm selecting an Amazon-managed AMI using the latest OS version of Amazon Linux 2 x86. As part of the recipe, you can also add user data. User data are commands run on a Linux instance at launch time.

Build Components

This is a section on the recipe that I'd like to focus on. As defined, components are software scripts allowing for custom configuration of the image. The components can either be Amazon-managed, owned by me, shared with me, or third party managed.

Let us ensure that we are updating to the latest linux version. This can be done by adding the Amazon-managed update-linux component.

Let us also create a custom component to be added, by clicking on the Create build component button on the upper right side.

Creating a Custom Component

Select the component type as Build. This component will run the configuration script to run the script to install Apache, and create and run the Apache application, so I'm naming this as apache-application and setting the version as 1.0.0.

For the content, copy and modify the script below:



name: imagebuilder-applicationcomponent
description: 'This component will download the apache install script, and deploy a sample application'
schemaVersion: 1.0
phases:
    - name: build
      steps:
        - name: DownloadInstallScript
          action: S3Download
          onFailure: Abort
          maxAttempts: 3
          inputs:
            - source: s3://bitscollective/install-apache.sh
              destination: /var/tmp/install-apache.sh
        - name: RunScript
          action: ExecuteBash
          onFailure: Abort
          maxAttempts: 3
          inputs:
            commands:
              - 'chmod 755 {{ build.DownloadInstallScript.inputs[0].destination }}'
              - 'bash {{ build.DownloadInstallScript.inputs[0].destination }}'
        - name: SampleApplication
          action: S3Download
          onFailure: Abort
          maxAttempts: 3
          inputs:
            - source: s3://bitscollective/index.html
              destination: /var/www/html/index.html
        - name: CleanupInstallFiles
          action: ExecuteBash
          onFailure: Abort
          maxAttempts: 3
          inputs:
            commands:
              - 'rm {{ build.DownloadInstallScript.inputs[0].destination }}'

This will allow us to add this custom component in the recipe.

For the s3 files that will be accessed by this component, create the following files:

index.html ```html

<!DOCTYPE html>

Sample Application

hello!

- install-apache.sh
```bash


#!/bin/bash

# Install Apache
sudo yum install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpd

Adding a Test Component
Another great feature of the image builder is the capability to add tests to the instance after image creation, to ensure that the image is working as you expect. There are a few basic AWS-managed test components available for use, and you can create any custom test component yourself to be added to the pipeline.

2. Defining Infrastructure Configuration (Optional)
Infrastructure configuration determines the EC2 instances created when customizing the images and running validation tests. The default setting will also create an IAM role with the required policy to execute commands and customize the image.

3. Defining Distribution Settings (Optional)
Distribution settings will allow customizations on allowed regions, encryption, launch permissions, allowed accounts that can launch the output AMI, and license configurations.

Continue to the last step, and create the pipeline.

Running the Image Builder Pipeline

To start testing the image, first let's run the pipeline to create an image with all the customizations we defined. Go to image pipelines, select the pipeline created, then click on Actions > Run pipeline.

On the message that pops up, click on View details. This will allow navigation to the pipeline workflow where we can drill down to the steps and identify any issues if any.

Based from the logs, there is a 403 encountered because the role assumed by the EC2 image builder does not have permissions to get files from the S3 bucket. To find out the role, go back to the pipeline and get the IAM role that has been set up.

Now, go the the S3 bucket and add the required bucket policy to allow access to Image builder.



#Replace <accountid> with the aws account id
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ImageBuilder",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<accountid>:role/EC2InstanceProfileForImageBuilder"
            },
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::bitscollective/*",
                "arn:aws:s3:::bitscollective"
            ]
        }
    ]
}

Re-run the pipeline, and the issue should be resolved now

Once complete, the image should appear under the output resources and can now be used for EC2s.

Testing and Using the Created AMI

To quickly test if the image works as expected, go to the EC2 service, and on the left pane, select AMI. Select the AMI created and click on Launch instance from AMI.

Add a name to the EC2 host, let other details remain as default and click on Launch instance.

Once the instance is created, get the public IP and attempt to load this in a web browser. If the page doesn't load for some reason, one possibility is that http traffic is not allowed on the EC2 instance. To update this, go to the instance's security tab and click on the security group link. Edit the inbound rules and add an allow all for http traffic (port 80). Save the rule.

Reload the public IP again from the browser.

Now that you verified that the image works, you can terminate the EC2 resource created to ensure you are not being charged with anything.

This is the first of a three-part series about Infrastructure as Code. Stay tuned for the next article!