DEV Community: Edward Allen Mercado

From Detection to Resolution: A Closed-Loop System for Managing AWS CloudFormation Drift

Edward Allen Mercado — Wed, 03 Dec 2025 03:50:47 +0000

As cloud estates grow, maintaining the integrity of Infrastructure as Code (IaC) is a critical challenge. AWS CloudFormation provides the blueprint for our infrastructure, but the reality of day-to-day operations—manual hotfixes, temporary changes, and urgent interventions—inevitably leads to configuration drift. Detecting this drift is only half the battle. The real challenge, especially when managing hundreds of stacks, is prioritizing what to fix and cutting through the noise.

What if you could move beyond simple alerts and build a closed-loop system that not only detects drift but allows your team to manage, acknowledge, and prioritize it, all from within your primary communication tools?

This post details the architecture for just such a solution: an intelligent, interactive drift management system built on serverless AWS services.

The Solution: An Interactive Drift Management Tool

Instead of just another notification system that adds to alert fatigue, this solution creates an interactive workflow. It delivers actionable alerts that empower engineers to make decisions directly from Slack. By allowing teams to formally "Acknowledge" or "Ignore" a detected drift, the system brings order to the chaos, creating a clear audit trail and allowing teams to focus on what matters most.

Architectural Blueprint: A Closed-Loop System

This solution moves beyond simple notifications and creates a full, closed-loop system for managing configuration drift at scale. It’s built on a foundation of event-driven, serverless components that provide not just information, but control.

The Trigger (AWS Config): The process begins with the AWS Config service. Using a built-in rule named cloudformation-stack-drift-detection-check, it continuously monitors your CloudFormation stacks. The moment a stack’s actual configuration deviates from its template, AWS Config flags it as NON_COMPLIANT.
The Router (Amazon EventBridge): This NON_COMPLIANT status is published as an event. An Amazon EventBridge rule is set up to specifically listen for these events from AWS Config. Upon catching one, it immediately forwards the event payload to our first AWS Lambda function for processing.
The Notifier (AWS Lambda): This first Lambda function acts as the initial alert mechanism. Triggered by the EventBridge event, it performs two key actions:
- It first inspects the drifted stack to confirm it contains the MONITOR_DRIFT tag with a value of true.
- If the tag is present, it constructs a rich notification—complete with "Acknowledge" and "Ignore" buttons—and sends it to a designated Slack channel, providing the team with immediate visibility and a direct call to action.
The State Manager (AWS Lambda, API Gateway & DynamoDB): This is where the system becomes truly powerful. A second, distinct workflow handles the interactive state management:
- An AWS Lambda function is responsible for persisting the details of drifted stacks into an Amazon DynamoDB table, creating a centralized source of truth.
- When an engineer clicks "Acknowledge" or "Ignore" in the Slack message, the action is sent to an Amazon API Gateway endpoint.
- This API Gateway call invokes our state manager Lambda, which then updates the corresponding stack's status in the DynamoDB table. This allows the team to manage priorities, reduce alert noise by ignoring known drifts, and maintain a clear audit trail.

Putting It Into Practice

Enrolling a stack into this management system remains incredibly simple. To enable drift detection and interactive alerts for any CloudFormation stack, you only need to perform one action:

Add the tag MONITOR_DRIFT with a value of true to the stack.

Once tagged, the stack is automatically picked up by the system. Any future drift will trigger the interactive notification in Slack, allowing your team to begin managing it immediately.

Behind the Code: An Interactive Slack Message

The key to this workflow is the interactive Slack message. Here’s a simplified look at how the JSON payload for a message with action buttons is constructed.

// A simplified look at an interactive Slack message payload
const slackMessage = {
    channel: 'your-drift-alerts-channel',
    text: `*Drift Detected in Stack: YourStackName*`,
    attachments: [
        {
            text: 'A drift from the expected template has been detected. Please review and choose an action.',
            fallback: 'You are unable to choose an action.',
            callback_id: 'drift_action_callback',
            color: '#F35B5B',
            attachment_type: 'default',
            fields: [
                { title: 'Account', value: '123456789012', short: true },
                { title: 'Region', value: 'us-east-1', short: true }
            ],
            actions: [
                {
                    name: 'acknowledge',
                    text: 'Acknowledge',
                    type: 'button',
                    value: 'acknowledged',
                    style: 'primary'
                },
                {
                    name: 'ignore',
                    text: 'Ignore',
                    type: 'button',
                    value: 'ignored'
                }
            ]
        }
    ]
};

This snippet illustrates how action buttons are added to a Slack message, enabling the interactive workflow.

Conclusion

Effective infrastructure management at scale requires moving beyond passive detection to active resolution. By creating a closed-loop, interactive system, you empower your engineers to manage CloudFormation drift efficiently, directly from the tools they use every day. This architecture not only provides a robust audit trail and reduces alert fatigue but also fosters a more organized and prioritized approach to maintaining infrastructure integrity. It’s a powerful pattern for transforming a persistent operational challenge into a streamlined, manageable process.

Migrating Kubernetes volume contents to another

Edward Allen Mercado — Sat, 01 Feb 2025 06:54:20 +0000

When managing Kubernetes workloads, you may encounter scenarios where you must migrate data from one persistent volume to another. This can happen due to storage class changes, resizing constraints, cloud provider migrations, or performance optimizations. Ensuring a smooth transition while maintaining data integrity is crucial.

As per experience, migrating persistent volume (PV) data in Kubernetes can be complex, especially when dealing with large datasets or ensuring minimal downtime.

PV-Migrate is an open-source tool designed to simplify this process by providing a reliable, automated way to transfer data between two persistent volumes in the same or different namespaces.

It leverages rsync over Kubernetes jobs to efficiently copy data while preserving permissions, file structures, and symbolic links. It works seamlessly across different storage classes, allowing users to migrate data without needing manual intervention or external backup tools.

This guide will explore the strategies to migrate Kubernetes volume PersistentVolumeClaims from one AWS EKS Amazon (Elastic Kubernetes Service) Cluster to another using PV-Migrate.

Installation

There are various installation methods for different operating systems. You can follow your relevant installation method here:
https://github.com/utkuozdemir/pv-migrate/blob/master/INSTALL.md

Usage

Once the pv-migrate is installed, we can now explore the command to start our migration.

Here's what you need to know the command, it's usage and the flags.
https://github.com/utkuozdemir/pv-migrate/blob/master/USAGE.md#usage

Notable Flags

--dest and --source - Using these flags we can specify what PersistentVolumeClaims were copying from and where PersistentVolumeClaims were copying to.
--source-kubeconfig and --dest-kubeconfig - Using these flags we can specify on what clusters we're working.
--source-context and --dest-kubeconfig - Using these flags we will specify the needed context of the clusters we're working, this goes hand in hand with the above flags.
--source-namespace and --dest-namespace - specify the namespaces of where the source and destination PersistentVolumeClaims resides.
--helm-set - Using this flag we can pass rsync extra arguments and other pv-migrate helm configuration values.
--strategies - Using this flag you can specify the order of strategies you want to implement in your migration.

Strategies

PV-Migrate offers variety of strategies on how you want to migrate you volume contents and it during the execution of the migration it will try these strategies except until one of the strategies work or all of them will fail except for the local which is in experimental phase at the moment.

mnt2 (Mount both) - Mounts both PVCs in a single pod and runs a regular rsync, without using SSH or the network. Only applicable if source and destination PVCs are in the same namespace and both can be mounted from a single pod.
svc (Service) - Runs rsync+ssh over a Kubernetes Service (ClusterIP). Only applicable when source and destination PVCs are in the same Kubernetes cluster.
lbsvc (Load Balancer Service) - Runs rsync+ssh over a Kubernetes Service of type LoadBalancer. Always applicable (will fail if LoadBalancer IP is not assigned for a long period).
local (Local Transfer) - Runs sshd on both source and destination, then uses a combination of kubectl port-forward logic and an SSH reverse proxy to tunnel all the traffic over the client device (the device which runs pv-migrate, e.g. your laptop). Requires ssh command to be available on the client device.
Note that this strategy is experimental (and not enabled by default), potentially can put heavy load on both apiservers and is not as resilient as others. It is recommended for small amounts of data and/or when the only access to both clusters seems to be through kubectl (e.g. for air-gapped clusters, on jump hosts etc.).

https://github.com/utkuozdemir/pv-migrate/blob/master/USAGE.md#strategies

Setup

In our scenario, our EKS Clusters live in different accounts and different VPC, so there are additional steps to configure networking accessibility compared on working inside the same cluster.

Configure EKS Cluster Config file

You can generate or update your Kubernetes Config file using the below commands.

Don't forget to modify the values for each flags to relevant values for your source and destination cluster.

Generate

aws eks update-kubeconfig --region <region-code> --name <eks-cluster-name> --kubeconfig ./<kube-config-file-name> --profile <aws-config-profile>

Update

aws eks update-kubeconfig --region <region-code> --name <eks-cluster-name> --profile <aws-config-profile>

Whether you generated or updated your kube-config file, you can either open the file or use the below command to know the context for your source and destination cluster.

kubectl config get-contexts

Take note for the values of your source and destination kube-config files and contexts.

Configure Networking

As previously stated, our EKS clusters lives on different account and different VPC.

In this scenario, we have couple of options on how to configure our networks; either the communication will be public or we will preserve the communication in private leveraging AWS backbone network.

In our case, we choose the latter and the below are our configuration.

VPC Peering
We've established VPC Peering between our VPCs

Route Table
We've modify the Route Table we have per relevant subnets and created routes to point traffic between the VPCs using their CIDR.

Security Groups
We've modify the Control Plane Security Group for each EKS cluster to allow communication to another.

Configure Permissions

As our EKS clusters lives on different accounts, we need to allow cross-account access between EKS clusters.

This is simply configuring either the aws-auth ConfigMap or EKS iam access entries.

Using aws-auth
Using aws-auth you can create your Kubernetes Roles and Role Bindings to map your Users or Roles that you are using in this migration.

Note: This option will be deprecated soon.

Here's the example aws-auth ConfigMap:

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::111122223333:role/my-role
      username: system:node:{{EC2PrivateDNSName}}
    - groups:
      - eks-console-dashboard-full-access-group
      rolearn: arn:aws:iam::111122223333:role/my-console-viewer-role
      username: my-console-viewer-role
  mapUsers: |
    - groups:
      - system:masters
      userarn: arn:aws:iam::111122223333:user/admin
      username: admin
    - groups:
      - eks-console-dashboard-restricted-access-group
      userarn: arn:aws:iam::444455556666:user/my-user
      username: my-user

For more details, you can follow an AWS documentation here.

Using EKS IAM access entries
This is mostly similar with the former but this can be managed outside your EKS cluster.

Fundamentally, an EKS access entry associates a set of Kubernetes permissions with an IAM identity, such as an IAM role.

Considering that aws-auth will be deprecated soon, it's better to practice using this.

For more details, you can follow an AWS documentation here.

Migration

Once the above steps are configured, we can start the migration. In the previous steps, we gathered all the values needed and we just need to substitute those values into the below command.

Note: Before starting the migration, consider stopping or scaling down the relevant Kubernetes resources to zero. This prevents new data from being written during the migration, ensuring data consistency and avoiding potential conflicts.

pv-migrate \
  --strategies "lbsvc" \
  --lbsvc-timeout 10m0s \
  --helm-timeout 10m0s \
  --helm-set rsync.extraArgs="--ignore-times --checksum" \
  --helm-set rsync.maxRetries=20 \
  --helm-set rsync.retryPeriodSeconds=60 \
  --log-level "DEBUG" \
  --source-kubeconfig "<source-kube-config-file>" \
  --source-context "<source-context>" \
  --source-namespace "<source-namespace>" \
  --source "<source-persistent-volume-claim-name>" \
  --dest-kubeconfig "<destination-kube-config-file>" \
  --dest-context "<destination-context>" \
  --dest-namespace "<destination-namespace>" \
  --dest "<destination-persistent-volume-claim-name>" \
  --dest-delete-extraneous-files

In the command above, we've prioritized using the lbsvc strategy. As stated in the Strategy section, this implementation leverages Kubernetes Service type of LoadBalancer in which in AWS it creates a AWS Load Balancer and performs the migration.

Although this setup does not work as it is, we need to override the default values of the pv-migrate and tailor it on how AWS Load Balancer interacts with the EKS Cluster.

Specifically AWS does takes time to create the Load Balancer and granting it an IP sometimes it takes it 10 minutes to complete the Load Balancer creation. Hence we've added couple of --helm-set flags.

--helm-set rsync.maxRetries=20 and --helm-set rsync.retryPeriodSeconds=60 - Using this flag, we can provide EKS with sufficient time to wait for AWS to assign an IP address to the Load Balancer. Since this process can take some time, EKS may initially be unable to communicate using the FQDN.
rsync.extraArgs="--ignore-times --checksum" - Using this flag we ensures a reliable sync by verifying all file contents, even if timestamps match.

Conclusion

PV-Migrate is a powerful tool for migrating Persistent Volume Claims (PVCs) between EKS clusters across different AWS accounts. By leveraging rsync over Kubernetes jobs, it ensures efficient and reliable data transfer while preserving file integrity and permissions. Unlike manual methods or snapshot-based approaches, pv-migrate simplifies the migration process without requiring downtime or complex configurations.

With its ability to handle cross-cluster and cross-account migrations, its an excellent choice for EKS administrators looking for a seamless and automated way to transfer persistent data between environments.

Before we embark further into our cloud journey, I invite you to stay connected with me on social media platforms. Follow along on Twitter, LinkedIn. Let's continue this exploration together and build a thriving community of cloud enthusiasts. Join me on this exciting adventure!

Unveiling the Kubernetes Resume Challenge: A Quest for Professional Growth - Extra Steps

Edward Allen Mercado — Sun, 03 Mar 2024 04:46:41 +0000

Welcome back, fellow adventurers! In this new installment of my blog, we're diving deeper into the Cloud Resume Challenge, exploring the additional steps beyond the core requirements.

Having successfully completed the initial challenge, I'm eager to share with you the next phase of my journey. These extra steps promise to further enrich our understanding of cloud technologies and push the boundaries of our skills.

Join me as we embark on this exciting continuation!

Implementation

Extra Step 1: Package Everything in Helm

I'm not very familiar in using Helm, fortunately, Helm offers extensive and understandable documentation.
, making it an invaluable resource for Kubernetes resource management.

In this step, I realized the efficiency and convenience Helm brings to the table compared to manually creating Kubernetes resource definition files. While creating .yaml files was essential for laying the foundation of Kubernetes resource creation, Helm allows us to recycle these files and manage them more gracefully.

One of the standout features of Helm is its ability to group Kubernetes resources as needed and handle their management seamlessly. By utilizing the values.yaml file, we can define dynamic data for each Kubernetes resource, enhancing flexibility and convenience.

To dive into the world of Helm, you can start by creating, packaging, and deploying your own Helm chart using the following commands:

helm create deis-workflow
helm package deis-workflow
helm install deis-workflow ./deis-workflow-0.1.0.tgz

These commands, straight from the Helm documentation, provide a solid starting point for exploring Helm and its capabilities.

Extra Step 2: Implement Persistent Storage

Throughout the Cloud Resume Challenge, I encountered scenarios where modifying the database required either recreating the Deployment or experiencing database Pod restarts. In both cases, all previously applied configurations in the database would be overwritten, essentially resetting it to a blank slate.

To address this kind of scenarios, I realized the importance of implementing persistent storage for our database. With the assistance of Kubernetes resources such as PersistentVolume and PersistentVolumeClaim, we can ensure that the data in our database remains persistent, regardless of Deployment recreation or Pod restarts.

The outcome of this step is significant: the lifecycle of the database becomes separated from the storage itself, ensuring that our data will Retain and accessible even amidst infrastructure changes or failures.

Extra Step 3: Implement Basic CI/CD Pipeline

In this phase, we'll streamline the build and deployment process of our resources, extending beyond just our Docker Image and Helm Charts. To achieve this, we'll leverage GitHub Actions, a powerful automation tool provided by GitHub.

Here are some of the GitHub Marketplace Actions that I've utilized to accomplish these tasks. I hope you find them as useful as I did. It's worth noting that there are several ways to achieve these steps, whether by using different GitHub Marketplace Actions or running your own custom commands.

docker / login-action

GitHub Action to login against a Docker registry

About

GitHub Action to login against a Docker registry.

Usage

Docker Hub

When authenticating to Docker Hub with GitHub Actions, use a personal access token. Don't use your account password.

name: ci

on:
  push:
    branches: main

jobs:
  login:
    runs-on: ubuntu-latest
    steps:
      -
        name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

GitHub Container Registry

To authenticate to the GitHub Container Registry, use the GITHUB_TOKEN secret.

name: ci
on:
  push:
    branches: main

jobs:
  login:
    runs-on: ubuntu-latest
    steps:

…

View on GitHub

docker / setup-buildx-action

GitHub Action to set up Docker Buildx

About

GitHub Action to set up Docker Buildx.

This action will create and boot a builder that can be used in the following steps of your workflow if you're using Buildx or the build-push action By default, the docker-container driver will be used to be able to build multi-platform images and export cache using a BuildKit container.

Usage

name: ci

on:
  push:

jobs:
  buildx:
    runs-on: ubuntu-latest
    steps:
      -
        name: Checkout
        uses: actions/checkout@v4
      -
        # Add support for more platforms with QEMU (optional)
        # https://github.com/docker/setup-qemu-action
        name: Set up QEMU
        uses: docker/setup-qemu-action@v3
      -
        name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

Configuring your builder

Version pinning: Pin to a specific Buildx or BuildKit version
BuildKit container logs: Enable BuildKit container logs for debugging…

View on GitHub

Azure / setup-helm

Github Action for installing Helm

Setup Helm

Install a specific version of helm binary on the runner.

Example

Acceptable values are latest or any semantic version string like v3.5.0 Use this action in workflow to define which version of helm will be used. v2+ of this action only support Helm3.

- uses: azure/setup-helm@v4.1.0
  with:
     version: '<version>' # default is latest (stable)
  id: install

Note

If something goes wrong with fetching the latest version the action will use the hardcoded default stable version (currently v3.13.3). If you rely on a certain version higher than the default, you should explicitly use that version instead of latest.

The cached helm binary path is prepended to the PATH environment variable as well as stored in the helm-path output variable. Refer to the action metadata file for details about all the inputs https://github.com/Azure/setup-helm/blob/master/action.yml

Contributing

This project welcomes contributions and suggestions. Most contributions require you…

View on GitHub

bitovi / github-actions-deploy-eks-helm

Deploy Helm charts to AWS EKS cluster

bitovi/github-actions-deploy-eks-helm deploys helm charts to an EKS Cluster

Action Summary

This action deploys Helm charts to an EKS cluster, allowing ECR/OCI as sources, and handling plugin installation, using this awesome Docker image as base.

Note: If your EKS cluster administrative access is in a private network, you will need to use a self hosted runner in that network to use this action.

If you would like to deploy a backend app/service, check out our other actions:

Action	Purpose
Deploy Docker to EC2	Deploys a repo with a Dockerized application to a virtual machine (EC2) on AWS
Deploy React to GitHub Pages	Builds and deploys a React application to GitHub Pages.
Deploy static site to AWS (S3/CDN/R53)	Hosts a static site in AWS S3 with CloudFront

And more!, check our list of actions in the GitHub marketplace

Need help or have questions?

This…

View on GitHub

By automating our build and deployment workflows, we can ensure faster and more consistent releases, ultimately enhancing the efficiency and reliability of our development pipeline.

Conclusion

And with that, this is my conclusion for this challenge, I reflect on the invaluable experiences gained throughout this journey. As I navigated each step, from setting up the infrastructure to fine-tuning the deployment, I encountered various obstacles and triumphs that deepened my understanding of cloud technologies. I reflect on the invaluable experiences gained throughout this journey. As I navigated each step, from setting up the infrastructure to fine-tuning the deployment, I encountered various obstacles and triumphs that deepened my understanding of cloud technologies.

Moving forward, I carry with me the lessons learned and insights gained from this experience. I'm excited to continue exploring new avenues in Kubernetes, Containerization, Cloud Computing and further honing my skills.

I trust that you've found this article helpful in some capacity. It's been a pleasure documenting my journey through the Cloud Resume Challenge and sharing insights and learnings along the way.

If you have any feedback, questions, or suggestions for future topics, I'd love to hear from you. Feel free to reach out at Twitter and LinkedIn and let's continue the conversation. Here's to more learning and growth ahead!

Unveiling the Kubernetes Resume Challenge: A Quest for Professional Growth - Part 2

Edward Allen Mercado — Sun, 03 Mar 2024 03:51:20 +0000

As we embark on the second leg of our journey, it's time to take another step towards conquering the Kubernetes Resume Challenge!

In Part 1, we laid the groundwork, setting up our Kubernetes cluster, configuring services, and preparing our database which covers the Step 1 to 5.

Please join me again as we navigate through the challenges and triumphs that lie ahead, inching closer into completing this quest.

Implementation

Step 6: Implement Configuration Management

In this step, our objective is to create a ConfigMap with the data of FEATURE_DARK_MODE set to true. Subsequently, we'll need to adjust our app/ code to accommodate this configuration by adapting to the value of the Environment Variable. Finally, we'll modify our website Deployment to include the ConfigMap.

We'll implement the Dark Mode feature by creating a separate .css file specifically for this mode. Our approach involves verifying that the Environment Variable FEATURE_DARK_MODE is set to true. Once confirmed, we'll render the dark mode style by linking the appropriate .css file in our application.

Step 7: Scale Your Application

In this phase, we'll evaluate the scalability of our application. Can it gracefully handle increased traffic without manual intervention?

To simulate a scale-up scenario, execute the following command:

kubectl scale deployment/<website_deployment_name> --replicas=6

This command increases the number of Pods in your Deployment to 6. You can monitor the growing number of Pods by running:

kubectl get po -w

Once the scaling operation is complete, see if the newly created Pods are in Running State, then navigate to our website endpoint and verify if it behaves as expected, without any errors, despite the increased resources.

Step 8: Perform a Rolling Update

In this phase, we'll enhance our website by adding a promotional banner to the body of our web pages as part of our marketing campaign. To accomplish this, we'll need to modify the code in the app/ directory accordingly. Once the changes are made, we'll rebuild and push our Docker image with the new tag v2 to our Docker Hub repository.

After updating the Docker image, we'll need to ensure that our website Deployment is using the latest version. We can achieve this by either deleting and recreating the Deployment or by executing the set image command:

kubectl set image deployment/<web_deployment_name> <container_name>=<your_docker_repo>:<new_tag>

In my experience, there have been cases where changes made to the Docker image are not immediately reflected, even when referring to the correct tags. This can occur if we're constantly pushing changes to the same Docker tag, such as v1, without incrementing it. To mitigate this issue, I recommend using the sha of the Docker image instead, as it points to the most recent changes pushed to your Docker repository. You can find this sha output in your repository or every time you push the image via the command line.

v1: digest: sha256:eba9e3bb273a1b62fae7fe6de36956760b06daaa7d8b9e0b70cb054d13822623 size: 5113

Step 9: Roll Back a Deployment

Uh-oh! It seems that the banner we recently deployed has introduced a bug to our website. To rectify this issue, we'll need to roll back the deployment to a previous state.

You can accomplish this by executing the following command:

kubectl rollout undo deployment/<website_deployment_name>

Once the rollout completes successfully, verify if the website returns to its previous state, without the banner, ensuring that the bug has been resolved.

Step 10: Autoscale Your Application

Now that we've observed how our website behaves under increased traffic and during rollbacks, it's time to implement autoscaling to ensure optimal performance under varying workloads. To achieve this, we'll utilize the Horizontal Pod Autoscaler resource.

Simply execute the following command to implement autoscaling:

kubectl autoscale deployment <website_deployment_name> --cpu-percent=50 --min=2 --max=10.

To verify that the Horizontal Pod Autoscaler is functioning as expected, we can use tools like Apache Bench to generate traffic to our endpoint. First, install Apache Bench and generate load to your Website Endpoint using the command:

ab -n 100 -c 10 <website_endpoint>

You can monitor the behavior of the Horizontal Pod Autoscaler and your Pods by executing the following commands in separate command line tabs or windows:

kubectl get hpa -w
kubectl get pod -w

This allows you to observe how the autoscaler adjusts the number of Pods based on the generated load, ensuring optimal resource utilization.

Step 11: Implement Liveness and Readiness Probes

In this phase, we'll enhance the reliability of our website by adding liveness and readiness probes. These probes ensure that before our website starts running, it is verified as working, and it maintains its operational state throughout its lifecycle.

To achieve this, we'll modify the Deployment definition to include these probes and then recreate our Deployment.

In my case, I've utilized specific path and separate php files to verify their functionality, such as /db_healthcheck.php and healthcheck.php.

If you'd like to try this on my website endpoint, simply append the mentioned path to the URL.

This implementation ensures that our website is always responsive and maintains its availability, contributing to a seamless user experience.

Step 12: Utilize ConfigMaps and Secrets

In this phase, we revisit the implementation of our database and website to ensure secure management of database connection strings and feature toggles without hardcoding them in the application.

As previously mentioned, we've already stored these database connection strings and configurations either in an Environment Variable or a ConfigMap, requiring only minor adjustments.

To enhance security, we'll ensure that sensitive data is stored using Secrets, while non-sensitive information can remain in a ConfigMap.

We'll then modify the Deployment definition to include both ConfigMap and Secrets, and subsequently recreate our Deployment.

This approach ensures that our application's sensitive information remains protected, contributing to a more robust and secure deployment.

Conclusion

And there we have it, we've successfully completed the challenge! I hope you found value in following along with my blog.

I'm immensely grateful for the opportunity to tackle this challenge, as it not only tested my technical skills but also fostered personal growth and resilience. The satisfaction of overcoming each hurdle and witnessing the evolution of my project fills me with a sense of accomplishment and pride.

For me, this journey doesn't end here. I've also taken on the extra steps mentioned in the challenge, so stay tuned if you're interested in continuing to explore this challenge further with me!

Before we embark further into our next journey, I invite you to stay connected with me on social media platforms. Follow along on Twitter, LinkedIn.

Unveiling the Kubernetes Resume Challenge: A Quest for Professional Growth - Part 1

Edward Allen Mercado — Sat, 02 Mar 2024 17:38:16 +0000

As March unfolds its chapter in 2024, I was thrilled when I saw this LinkedIn post by @forrestbrazeal.

Forrest Brazeal on LinkedIn: Take on the Kubernetes Resume Challenge

Just one week left until the Kubernetes Resume Challenge kicks off on March 4th! I've heard from several experienced engineers who are excited about jumping…

linkedin.com

And from that post I knew it will be a a tale of exploration, learning, and growth in the vast expanse of cloud computing, a realm where innovation meets opportunity.

Join me as I unveil the beginning of this adventure, a journey fueled by passion, curiosity, and the desire to elevate my skills to new heights.

Scenario

We have to deploy an e-commerce website. This is a modern web application which poses challenges about Scalability, Consistency, and Availability. To address these, we've opted for a solution that harnesses containerization managed by Kubernetes.

Prerequisites

In this challenge, certain prerequisites are necessary, outlined in detail here. However, among these, the most crucial for me is gaining familiarity with the Application Source Code, accessible here.

Implementation

Before commencing each step, it's crucial to fulfill all necessary requirements as progression to subsequent steps may be impeded otherwise. However, Step 1 might be an exception to this rule.

Step 1: Certification

Fortunate to have this certification already secured, yet it's been a while since I delved into Kubernetes. This challenge serves as a refresher, ensuring I'm up to speed with this essential technology.

CKA: Certified Kubernetes Administrator - Credly

Earners of this designation demonstrated the skills, knowledge and competencies to perform the responsibilities of a Kubernetes Administrator. Earners demonstrated proficiency in Application Lifecycle Management, Installation, Configuration & Validation, Core Concepts, Networking, Scheduling, Security, Cluster Maintenance, Logging / Monitoring, Storage, and Troubleshooting

credly.com

Step 2: Containerize Your E-Commerce Website and Database

Web Application Containerization

In this step, our task is to craft our own Docker image starting from the base image of php:7.4-apache and configure the essential components. Fortunately, the provided hints are thorough, guiding us through the process. Let's proceed by crafting a Dockerfile to translate these hints into commands.

This Dockerfile will then be build into a Docker Image and this image will then be pushed into our Docker Hub account. You can use this command to achieve this.

# Build Docker Image
docker build -t "<docker_username>/<repositry_name>:<tag>" . 

# Push to Docker Hub
docker push "<docker_username>/<repositry_name>:<tag>"

Database Containerization

For our Database component, we won't need to create a custom Docker image; instead, we'll simply pull an image from the Public DockerHub.

Notice that there is a db-load-script.sql script, it's essential to understand its functionality before proceeding confidently. Let's delve into its purpose to ensure we're well-prepared for the next steps.

USE ecomdb;
CREATE TABLE products (id mediumint(8) unsigned NOT NULL auto_increment,Name varchar(255) default NULL,Price varchar(255) default NULL, ImageUrl varchar(255) default NULL,PRIMARY KEY (id)) AUTO_INCREMENT=1;

INSERT INTO products (Name,Price,ImageUrl) VALUES ("Laptop","100","c-1.png"),("Drone","200","c-2.png"),("VR","300","c-3.png"),("Tablet","50","c-5.png"),("Watch","90","c-6.png"),("Phone Covers","20","c-7.png"),("Phone","80","c-8.png"),("Laptop","150","c-4.png");

Step 3: Set Up Kubernetes on a Public Cloud Provider

We're now at the stage where we must set up our Kubernetes cluster. For this, I've opted for AWS (EKS). I've taken the initiative to create the necessary resources, starting from the AWS VPC components and extending up to the EKS cluster.

Reminder: In the EKS cluster setup, ensure that you have permission to assume the IAM role on which you'll to create the cluster as you will not be able to access the cluster without it. Unless, you will configure the authentication_mode to API_AND_CONFIG_MAP and cluster_endpoint_public_access to true.

Please be patient as the creation of the EKS cluster may take between 10 to 20 minutes.

Once the cluster is successfully created, you'll want to verify your access by ensuring that you can execute kubectl commands.

To connect to the cluster, add a new cluster context to your .kubeconfig file. You can achieve this by using the following command:

aws eks update-kubeconfig --region <aws_region> --name <cluster_name> --profile <profile_name>

If you're utilizing an EKSClusterCreatorRole IAM Role, you can assume the role and execute the aforementioned command. An effective tool for this purpose is aws-vault.

99designs / aws-vault

A vault for securely storing and accessing AWS credentials in development environments

AWS Vault

AWS Vault is a tool to securely store and access AWS credentials in a development environment.

AWS Vault stores IAM credentials in your operating system's secure keystore and then generates temporary credentials from those to expose to your shell and applications. It's designed to be complementary to the AWS CLI tools, and is aware of your profiles and configuration in ~/.aws/config.

Check out the announcement blog post for more details.

Installing

You can install AWS Vault:

by downloading the latest release
on macOS with Homebrew Cask: brew install --cask aws-vault
on macOS with MacPorts: port install aws-vault
on Windows with Chocolatey: choco install aws-vault
on Windows with Scoop: scoop install aws-vault
on Linux with Homebrew on Linux: brew install aws-vault
on Arch Linux: pacman -S aws-vault
on Gentoo Linux: emerge --ask app-admin/aws-vault (enable Guru first)
on FreeBSD…

View on GitHub

Step 4: Deploy Your Website to Kubernetes

In this step, I've generated a Kubernetes definition file to instantiate a Kubernetes Deployment resource. This deployment utilizes the Docker image we previously pushed to our Docker Hub repository.

In this step, we've also set up another Deployment resource to host our mariadb image. However, configuring this resource involves additional steps, such as specifying the ROOT PASSWORD for the database and setting up the db-load-script.sql.

To set the ROOT PASSWORD, you can define your desired value as an Environment Variable named MYSQL_ROOT_PASSWORD.

As for the db-load-script.sql, we've created a ConfigMap Kubernetes resource to store its data.

A useful trick to streamline this process is employing kubectl commands to automatically generate the Kubernetes definition file. For instance, if you wish to create a Deployment definition file, you can execute the command:

kubectl create deploy --image=busybox sample --dry-run=client -o yaml > sample.yaml

This will generate a sample.yaml file and below are the contents.

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: sample
  name: sample
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sample
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: sample
    spec:
      containers:
      - image: busybox
        name: busybox
        resources: {}
status: {}

And if you want to get the properties of an existing resource, you can do this command instead.

kubectl get deploy <existing_deployment_name> -o yaml > sample.yaml

Note: This commands are not limited to Deployment resource only, you can also use other resources such as Pod, Service, etc.

Configure the Database

In line with best practices, it's recommended to deploy the database before the website. This allows for thorough testing of the database configuration and the creation of a new Database User, as it's considered best practice to avoid using root for day-to-day tasks.

Once the database Deployment is created, you can remotely connect to the Pod.

Once connected, login to the database.

Check if there are Database created, specifically, the ecomdb.

+--------------------+
| Database           |
+--------------------+
| ecomdb             |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+

Check if there are data inserted to the ecomdb database.

Check if there is an created products table and see if there are data inserted.

Note: All of these predefined data are created by the db-load-script.sql.

Once everything is verified, create a Database user.

Take note of the username and password that we've given to the user as website Pod will use this user the to connect to the database.

Configure the Website

With our database preparations complete, our website now possesses the requisite variables for authenticating with the database.

However, before proceeding, we need to make adjustments in the app/ index.php file to ensure our PHP application can fetch the database connection strings that we will provide via Environment Variables.

This Environment Variables will then be defined in our Deployment definition file.

This step is undeniably both laborious and pivotal in ensuring the functionality of our web application. I'm grateful for the little to none hints offered in the challenge steps, as they motivated me to explore diverse strategies to surmount this obstacle. I swear after completing this step, it will be even more exhilarating!

Step 5: Expose Your Website

Now, it's time to set up a Kubernetes Service to make our Deployment accessible. We'll opt for a LoadBalancer type Service, which will generate an AWS Load Balancer to expose our Web Application beyond the confines of our Kubernetes cluster.

It's crucial to ensure the selector section in your definition file contains the correct values. Below is a sample Service definition file for your reference.

apiVersion: v1
kind: Service
metadata:
  name: <name_of_service>
spec:
  type: LoadBalancer
  ports:
  - port: 80
    protocol: TCP
  selector:
    <label_key_of_webapp_pod>: <label_value_of_webapp_pod>

Even though its not mentioned in the step, I think its also beneficial to create another Service for our Database Deployment resource so it can be reached in a consistent manner using the Service endpoint.

Once the website Service is established, it generates a DNS endpoint through which you can access the web application. You can find this endpoint either by retrieving the details of the Service or within the AWS Management Console as a Load Balancer.

For instance, you can access my website at this link as an example of such an endpoint.

You might encounter several issues here, specifically regarding the authentication of our web application to our database, such as:

ERROR 1045 (28000): Access denied for user 'username'@ 'localhost' (using password: NO)

In such cases, it's crucial to exercise extra caution and ensure that you're providing the correct credentials as configured in the previous step.

I'm concerned that the length of this blog post might be making it feel tedious. However, it's important to remember that despite being only halfway through our journey, each step we take brings us closer on completing this challenge.

AWS Client VPN Implementation for Private Networks

Edward Allen Mercado — Thu, 25 Jan 2024 13:50:03 +0000

In the dynamic landscape of cloud computing, seamless and secure connectivity is paramount for organizations managing private networks. As businesses harness the power of AWS (Amazon Web Services), establishing a robust and secure communication channel becomes essential to access resources in a private network from virtually anywhere. Enter AWS Client VPN, a versatile solution that bridges the gap between remote users and private networks, ensuring a streamlined and secure connection.

Scenario

Imagine a complex network landscape where the need for a seamless and secure solution is paramount. Picture a scenario where all traffic must flow seamlessly from a dedicated Network or Shared Services AWS account to various private networks or Virtual Private Cloud (VPC) residing in different AWS accounts, aptly named as workload accounts.

Each workload account boasts its own set of computing resources, necessitating strict isolation from one another. In this intricate web of connectivity, only the Network or Shared Services account should wield the power to communicate with each workload account. The catch? Workload accounts must remain oblivious to one another's existence, ensuring airtight segregation.

This connectivity conundrum doesn't stop there – these workload accounts might find themselves dispersed across different AWS regions, adding an extra layer of complexity to the puzzle.

The Architecture

Setup

Now that we've laid eyes on the architectural diagram, it's time to roll up our sleeves and dive into the nitty-gritty of setting up the AWS services. This section is your backstage pass to the configuration wizardry that makes the entire system click.

AWS Organizations (Optional)

Let's create an AWS Organization, Ideally, in this scenario you will need to create another account which is called Management Account on where you will create this AWS Organization.

Creating and Configuring an Organization

You can then invite the Shared Services or Network account and each of the workload account to these organization.

Inviting an Account To Your Organization

Transit Gateway

We need create a Transit Gateway in the Network or Shared Services Account.

Creating the Transit Gateway

Note: Make sure to disable the Auto accept shared attachments, this is for the best practice, and when we share this Transit Gateway later using Resource Access Manager to the other accounts, the account needs to accept the shared resource.

Resource Access Manager (RAM)

We will use Resource Access Manager to share the Transit Gateway to each workload accounts.

Transit Gateway Resource Sharing

Transit Gateway Attachments

Now that the Transit Gateway has been seamlessly shared with the workload accounts, the next step is to establish the vital connections through attachments. Attachments play a pivotal role in associating the Transit Gateway with specific subnets within each Virtual Private Cloud (VPC).

Create a Transit Gateway Attachment to a VPC

If your architecture spans multiple workload accounts, repeat the process for each one. This ensures a comprehensive and interconnected network across all relevant accounts.

Note: It is recommended to create a separate subnet on where you will place your attachment.

Once finished, all of the created attachments will be shown when you go back to Shared Services or Network account Transit Gateway Attachments Console.

VPC Route Tables

We now need to configure the routing of each VPC Route table in each involved Subnets in each AWS account. We need to point out the traffic that needs to be forwarded to the Transit Gateway.

We need to modify the VPC Route Table for each account involved.

Add or Remove Routes from a Route Table

For the sake of simplicity, we've used the 10.0.0.0/8 CIDR Block to cover the IP address ranges of all of the accounts.

In doubt that we will confuse the routing, we can still point the traffic later using the Transit Gateway Route Tables and the 10.0.0.0/8 CIDR Block is spread to all of the accounts without overlap.

Note: We need to modify the VPC Route Table for each account.

Transit Gateway Route Tables

Now that the traffic is pointing to the Transit Gateway, we now need to create the Transit Gateway Route Tables to manage the routing at the Transit Gateway level.

Go back to your Shared Services or Network Account, create Transit Gateway Route Table.

Create Transit Gateway Route Table

Note: We need to create a Transit Gateway Route Table for each of the account involved.

It should be like the below, where all of the Route Table are created inside the Shared Services or Network Account only.

Transit Gateway Route Table Associations

Once the Transit Gateway Route Tables are now created, we now need to associate them to the Transit Gateway Attachments we created in the previous step.

To put it simply, the Transit Gateway Route Table created for the Shared Services or Network account will be associated with the Transit Gateway Attachment we created for the account. This will be same for the workload account.

Associate a Transit Gateway Route Table

Transit Gateway Route Table Propagations

Now that we've associated the Transit Gateway Route Table to their respective attachments, we now need to create the Transit Gateway Route Table Propagations so the routes advertised in the Transit Gateway are dynamically added to the Transit Gateway Route Table Routes.

At least the dynamic propagation will be beneficial to the Shared Services or Network Account as it needs to learn the routes so it can communicate to each workload account.

Shared Services or Network Account

Select the Transit Gateway Route Table of the Shared Services or Network Account and go to the Propagations Tab then Create Propagation for each of the Workload accounts Transit Gateway Attachments. It will look like the below.

In the Routes Tab, it will then add the advertised routes which you can see as Propagated in the Route Type column.

Workload Account

We need to also create Propagations for each workload account but we only need to create propagations to the Shared Services or Network Account.

The routes will also be added dynamically but only the routes of the Shared Services or Network Account.

Client VPN

The Transit Gateway section is now finished, we now need to create the Client VPN.

For the sake of simplicity, we will use mutual authentication for the Client VPN.

During its creation, we need the below details:

Client IPv4 CIDR
This just needs to be a non-overlapping CIDR block from the CIDR blocks we’ve used earlier for the VPCs.
Server Certificate ARN
You can create this certificate using easyrsa, you can use this guide to generate a server certificate and upload this to the AWS Certificate Manager.
VPC ID
This needs to be the VPC ID to where you associated the Transit Gateway using the Transit Gateway Attachments.
Security Group IDs
The important is the Security Group that you associate with has an Outbound and is open to all traffic.

Once all the relevant configurations are filled, we can now create the Client VPN endpoint.

Client VPN Target Network Associations

In the creation of the Client VPN, we only specified the VPC where will be the Client VPN hosted. Using the Target network associations, you need to associate the same VPC and the subnets where you want the Client VPN endpoints created. We need to select the VPC Subnets we configured earlier that have been associated with the relevant VPC Route Tables.

You can only create one association per VPC subnet and it's okay to create an association per relevant VPC subnet.

Client VPN Authorization Rules

We need to create rules to grant clients access to networks. Here you can specify the CIDR block and you can granularly grant access to either Allow access to all users or Allow access to users in a specific access group.

For testing purposes, we’ve just added a 0.0.0.0/0 CIDR block to all networks.

Client VPN Route Table

We need create another Route Table in the Client VPN level to create routes for each CIDR block destination. Here you can specify the CIDR block and select the Subnet ID (this Subnet ID goes back to the selected VPC Subnet when we did the Target network associations) so if you created multiple Target network associates for multiple VPC Subnets, you will then need to create multiple Client VPN Route Table which is the best practice.

In this case, we’ve only created one Target network association and we use this to route to multiple VPC CIDRs

Finally, we’ve finished setting up the Client VPN and its network connectivity to all the accounts, we can now download and set up the AWS VPN Client on your machine.

Download AWS VPN Client Configuration

Configure AWS VPN Client Configuration

Follow for the next part of this article to learn on how to extend this solution to another AWS region

For any queries, you can reach me at:

Dev.to
Twitter
LinkedIn

How Cloud Bridge uses Cloudamize to accelerate client workload migration to AWS

Edward Allen Mercado — Thu, 16 Mar 2023 09:02:57 +0000

Nowadays, cloud technology is one of the biggest IT trends. This trend offers a lot of benefits, mostly in terms of cost savings, which is why a lot of enterprises are encouraged to use it.

When it comes to transforming and migrating various workloads to the cloud, enterprises have a longer road ahead of them than their smaller SME counterparts. The same question is at the top of many large corporations' list of concerns: how can we migrate workloads quickly and efficiently to meet business objectives?

Migrating current on-premises infrastructure requires a significant amount of planning and analysis to achieve the client’s desired migration results. The size and complexity of the initial migration can be complicated for many enterprises. This process can be time-consuming and there’s a risk of exceeding predicted timeframes if that complexity is initially underestimated.

That’s why the initial discovery and planning stages of a migration are so vital.

Cloudamize is an analytics platform that produces highly accurate diagnostics that significantly improve the speed, ease, and accuracy of migrating to AWS. These diagnostics will help you to make the right migration decision across your infrastructure migration and will help when building the optimal operating model for your organization.

This article describes how Cloud Bridge utilized the Cloudamize tool to migrate client workloads at pace.

Cloud Bridge has designed a series of methodologies that build on the core migration logic of the Cloudamize tool. These agendas include the analysis of the platform, gathering of the relevant data, and evaluation of the deliverables.

Cloud Bridge is an AWS Advanced Consulting Partner with over 100 years of combined AWS expertise across technical teams. Cloud Bridge guides customers from all industries on their cloud journey, through our tailored professional management and cost-optimization services.

Platform Overview

For the first agenda, let us analyze the hardware or the workloads that are in scope for the migration.

The installation of the Cloudamize software needs to be done in this process.

Installation Methods

Cloudamize can be installed on different Linux flavors and Windows Server OSes.

Agent-based

From a variety of Linux flavors and Windows Server OSes, the Cloudamize Agent collects performance measurements, application dependencies, and SQL data. We recommend using this installation method as this collects more information on the servers.

Agentless

Each server detected is collected by the Cloudamize Agentless Data Collector (ADC), which gathers performance data and application requirements. Although agent-based approaches are still preferable for this purpose, the agentless method may now be used to find SQL workloads.

Feature Comparison between Agent-based vs Agentless

How Cloudamize Analytics Engine works

Once the Cloudamize software is installed on the server the Data Analytics Engine will begin collecting high level information about the machine’s CPU, RAM, running processes, interdependencies, firewall rules, SQL license editions/versions and operating systems. This process of gathering data will take two weeks.

Data Collection

After two weeks of collecting the data from the servers, Cloudamize will generate an overview of the current state of the infrastructure. Using the gathered data, the tool will recommend several optimization options around the Storage, Compute, Database, Network, etc.

The flow of the data from the servers to Cloudamize varies based on the options you have chosen to install the software.

Agent-based Data flow

Agentless Data flow

Summary Overview

Based on the discovered data, Cloudamize will show deck designs in relation to the mappings of your workload or hardware.

Hardware Mapping
This is a like-to-like mapping of system configurations to an equivalent AWS instance and storage size. This mapping is based on system hardware specifications (e.g., number of CPUs, CPU speed, assigned memory, disk size, etc.). Total Cost of Ownership (TCO) is estimated based on this configuration.

Workload Mapping
This takes system configurations into account and incorporates actual workload and usage characteristics. That data is then projected to an AWS environment. Mapping of instance sizes, storage, and network demand is provided and the TCO is estimated based on the suggested configuration.
Cloud Bridge examines the generated design decks from Cloudamize then generates its own design based on the requirements from the clients.

Deliverable Review

Using the information gathered from the previous steps, Cloud Bridge presents the Optimization and License Assessment (OLA) analysis decks and distinctive designs which highlight the options that the client will benefit from.

Based on the recommended optimizations, the data will be projected to an AWS environment. Mapping of instance sizes, storage, and network demand is provided and the TCO is estimated based on the suggested configuration.

Go or No-Go

This is a crucial step for the client. After presenting several migration options to the client. Cloud Bridge will let the client decide whether to migrate or not.

Once the client has confirmed that they want to continue the migration, Cloud Bridge will then take the initiative to plan the migration by producing an architectural design that is situated around a series of wave migrations that will act as the blueprint during the migration.

Customer Success Story – UK Pub chain

Cloud Bridge serves up and end-to-end AWS cloud migration program to a pub company.

The Challenge

When the organisation chose to migrate its on-premises environment to the cloud, it sought a partner to assist it in becoming acquainted with cloud technologies, selecting a cloud service provider, completing the whole migration, and managing the new cloud infrastructure.

The Solution

The company wanted to see a zero-change migration and Cloud Bridge delivered.

Cloud Bridge scoped the migration and uses the Cloudamize tool to perform TCO analysis and apply its recommended optimizations.
Provide architectural designs that help clients to understand their infrastructure in AWS.
We deployed AWS resources using automated provisioning based on infrastructure-as-code approach.

The Outcome

Cloud Bridge migrated their infrastructure ahead of the expected time. This bought more time for the pub company to market their services.

The pub chain reaped the following benefits by moving to the cloud:

Improved security, stability, and reliability of its technology foundation.
Long-term cost savings by eliminating on-premises infrastructure management costs.
Improved application performance.

Conclusion

Our Professional Services experts at Cloud Bridge wrap governance and procedure around an AWS migration. They ensure that workloads are migrated into AWS in the correct sequence based on business goals and objectives by using transparent project management.

To learn more about how Cloud Bridge can assist with your business challenges related to digital transformation, migration, and application modernization, visit the Cloud Bridge website.

Sync Git Repository from Github to AWS CodeCommit with Terraform

Edward Allen Mercado — Wed, 17 Aug 2022 08:14:00 +0000

What is a Git Repository?

Git repository is like a data structure that VCS uses to store metadata for a set of files and directories. Contains a collection of files and a history of changes made to those files.

This git repository can then be a remote repository stored on a code hosting service like Github, BitBucket, etc.

The advantage of storing your git repository on a code hosting services like Github is to promote collaboration whereas it will be a common repository that all team members use to exchange their changes among the files.

Having a central code repository is essential part of development. Hence this needs to be planned well.

In our case, we have our private Github organization where we store our project codes and we have a requirement to synchronized it to another repository in AWS CodeCommit.

Getting Started

At first, we need to generate several tokens and an SSH Key.

Generate a GitHub Token - provide workflow, organization, create and delete repository permissions
Clone this repository.
Generate an SSH Key.
Substitute the appropriate values below (see description), create a terraform.tfvars file and replace the placeholders.

github_token          = "PUT YOUR GITHUB PERSONAL ACCESS TOKEN HERE"

aws_access_key_id     = "PUT AWS SECRET ACCESS KEY ID HERE"
aws_secret_access_key = "PUT AWS SECRET ACCESS KEY HERE"

github_repository_name     = "Github Repository Name e.g. 'samplegithubrepo'"
codecommit_repository_name = "CodeCommit Repository Name e.g. 'samplecodecommitrepo'"

ssh_private_key_path  = "PUT THE PATH WHERE SSH PRIVATE KEY IS STORED e.g. ~/.ssh/id_rsa"
ssh_public_key_path   = "PUT THE PATH WHERE SSH PUBLIC KEY IS STORED e.g. ~/.ssh/id_rsa.pub"

aws_region            = "PUT YOUR AWS REGION OF CHOICE"

Please take note that the values inside your terraform.tfvars file are not to be pushed to the Github repository. To prevent this, the Github repository itself has .gitignore file which *.tfvars are included.

Deployment

After doing the prerequisites above, you can start deploying the solution.

Run terraform init.
Run terraform apply.
Check the resources to be deployed and type "yes" to deploy the resources.

Troubleshooting

Here are some error's we encountered during testing of this solution.

Workflow Failed

> Run pixta-dev/repository-mirroring-action@v1
> fatal: no path specified; see 'git help pull' for valid url syntax

Resolution:

Open the created GitHub Repository, Go to Settings > Secrets > Update CODECOMMIT_SSH_PRIVATE_KEY with your private SSH key.
Rerun workflow.

Result

All parts of the GitHub Repo are mirrored, i.e. branches, commits, etc.
Setup CodePipeline to use CodeCommit as source.
Pushing to Git auto-triggers a push up to CodeCommit, which in turn triggers a pipeline rerun.

Github Repository

See the Github repository here.

edwardmercado / mirror-repo-from-github-to-codecommit

Mirror Github Repository to CodeCommit

Prerequisites:

Terraform
AWS with appropriate credentials
SSH Key Pair (public and private)
GitHub Token

Getting Started

Generate a GitHub Token - provide (workflow, create and delete repository permissions)
Clone this repository.
Generate an SSH Key - keep the default name if possible as it points to ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub.
Substitute values below, create a terraform.tfvars file and paste the below values.

github_token = "PUT YOUR GITHUB PERSONAL ACCESS TOKEN HERE"
aws_access_key_id     = "PUT AWS SECRET ACCESS KEY ID HERE"
aws_secret_access_key = "PUT AWS SECRET ACCESS KEY HERE"
repository_name = "PUT YOUR REPOSITORY NAME HERE (SAME ON BOTH GITHUB & CODECOMMIT)"

Run terraform init
Run terraform apply -auto-approve

Troubleshooting

Workflow Failed

> Run pixta-dev/repository-mirroring-action@v1
> fatal: no path specified; see 'git help pull' for valid url syntax

Resolution:

Open the created GitHub Repository, Go to Settings > Secrets > Update CODECOMMIT_SSH_PRIVATE_KEY with your private SSH…

View on GitHub

For any queries, you can reach me at:

Dev.to
Twitter
LinkedIn

Continuous Delivery is NOT Continuous Deployment

Edward Allen Mercado — Thu, 07 Oct 2021 06:56:32 +0000

In DevOps methodologies, Continuous Delivery and Continuous Deployment are vague terms that we mostly took for granted and often compared as similar.

Let's discuss first about the well known term in DevOps called the CICD - Continuous Integration and Continuous Delivery/Deployment.

What is Continuous Integration and Continuous Delivery/Deployment?

This is considered as one of the best practices for DevOps teams to implement. This is a method to frequently deliver applications to customers by introducing automation into the stages of application development.

It also integrates with the Agile Methodology best practice as it will enable developers to focus on providing code quality, and meet business requirements.

Now, let's break down these terms into chunks.

Continuous Integration

Continuous Integration (CI) is a practice where developers frequently merge the changes to the main repository (such as Github, AWS CodeCommit, etc.), after which automated builds and tests are run.

CI most often refers to the build or integration stage of application development. Successful CI means new code changes to an app are regularly built, tested, and merged to a shared repository.

Continuous Delivery and Deployment

When the code changes have been built, tested. Continuous Delivery and Deployment (CD) stage will prepare the changes for production release. In simple terms it is an extension of the Continuous Integration stage by deploying all code changes to a testing environment, a production environment, or both after the build stage has been completed.

Continuous Delivery is not Continuous Deployment

Continuous Delivery

We tend to misinterpret Continuous Delivery as after the code has been built, tested in Continuous Integration stage is that every change will immediately be applied to the destination environment such as QA, PROD, etc. but it is not.

The point of Continuous Delivery is to ensure that every change is ready to deploy to the destination environment which involves reviews or manual integrations from non-technical team members to control the process.

Benefits of Continuous Delivery

Enabling a non-technical team as part of the process reduces the burden on the development team so they may continue to execute subsequent application improvements.

Continuous Deployment

On the other hand, Continuous Deployment is an improved version of the Continuous Delivery where all of the changes are ready to deploy to the destination environment without the manual integration, this process is completely automated, and only failed verification step will prevent pushing the changes to the environment.

You can achieve Continuous Deployment when your pipeline is mature enough where the involved teams are confident in the applied automation inside your pipeline.

Benefits of Continuous Deployment

With all of the stages automated, it means that the developer's change could go live within minutes of writing it, you can deliver to customers quicker and start to do iterations base on their feedbacks. It's easier to release changes to apps in small pieces, rather than all at once.

Building a pipeline base on your business needs could be difficult, having these terms clear can help the planning much easier.

Remember that DevOps is a journey, not the destination. Feedback to the pipeline is continuously collected and metrics are still needed to be in place to monitor the critical parts of the pipeline.

Hey! You can reach me at:

Dev.to
Twitter
LinkedIn

The 6 R's Of Cloud Migration

Edward Allen Mercado — Sun, 13 Jun 2021 08:07:41 +0000

Nowadays, a lot of companies are investing towards the migration of their on-premises applications towards the cloud.

In this article, we will learn about the 6 R that will guide your cloud migration journey.

The 6 R's Of Cloud Migration are set of strategies for migrating things into the cloud, by understanding the pros and cons of each you'll be able to plan on what R is appropriate for your application.

Re-host

Also known as lift and shift.
Migrate your application as is. This is the easiest path to get your on-premises application migrated to the cloud. Using this strategy, you copy your application infrastructure to your cloud provider.

You can use tools such as AWS Cloud Endure and VM Import/Export to automate this strategy.

Pros

Reduced management overhead as your cloud provider will managed the physical infrastructure on where your application be hosted also known as Infrastructure as a Service (IAAS).
Easier to optimize, when your application is deployed in your cloud provider it can now easily transformed to fully adopt the benefits of the cloud.
Still offers cost savings as your physical infrastructure is managed.

Cons

Not taking the full advantage of the cloud.
It can delay things that you could do better.

When to choose this strategy?

This fits well if you want to migrate your application without the need of code or infrastructure changes, just implement the same thing you did on-premises and if you're new in the cloud and want try things out.

Re-platform

Also known as lift, tinker, and shift.
Has similarities with Re-hosting but it gradually take the advantage of the cloud offerings without having to change the core infrastructure of your application.

Take this strategy as a safe point for your application. It's moving your database from Infrastructure as a Service to a Database as a Service.

Pros

Reduced management overhead - better than rehosting.
Increased resiliency.
Reduced cost.

Cons

No real negatives as you only allow your cloud service provider to manage more parts of your infrastructure.

Examples

Provisioning Amazon Relational Database Service instead of managed database instance in Elastic Compute Cloud.

When to choose this strategy?

This suits your application migration if you want to gradually adapt on cloud functionalities such as auto-scaling, managed services, etc. without committing to a large migration effort, and by doing these you can achieve benefits than rehosting can offer.

Re-factor or Re-architect

Review the architecture of an application and adopt to a cloud-native architectures and products, such as:

Service Oriented or Microservices
Serverless Architecture
Event-Driven Architecture

This strategy is offers the best long term benefits but comes with stiff price and time consuming process.

Pros

Takes the full advantages of using the cloud.
Produce a much more scalable, better high availability and fault tolerant infrastructure
Cost is aligned according the usage. Pay as you use model.

Cons

Initially, it is expensive and time-consuming.

When to choose this strategy?

This strategy is for those who really knows what are the full advantages of using cloud and make the most out of it. This will require you to drastically modify your application core infrastructure to be suited base on the cloud-native model, although this entails a lot of work this strategy will produce more value to your business in the long run.

Re-purchase

Move from managing installed applications on-premise and consume a Software as a Service (SaaS) model. Many of the common applications nowadays are available and offered as a SaaS.

Example

Move from a Customer Relationship Management (CRM) to Salesforce.com, from Microsoft Exchange to Microsoft 365, an HR system to Workday, or a content management system (CMS) to Drupal.

When to choose this strategy?

This is for the applications that already exist with SaaS offerings that you can subscribe base on your needs.

Retire

In other words If you don't need the application, switch it off. Remove the applications that are no longer needed, applications that are no longer produce value to you or your business. These applications are often running for no reason.

Pros

Often provides 10% - 20% cost savings.

When to choose this strategy?

You'll know, after your initial cloud migration assessment and base on the data you gathered, "Does this application benefit me?"

Retain

Also known as re-visit or do nothing, for now.
Commonly, applications fall on this criteria are:

Old application that has some usage but not worth the move.
Complex application that need to leave till later.
Super important application and it's to risky.

When to choose this strategy?

This strategy is used when most of the applications were deployed and working properly in the cloud, you'll look back and start to plan the migration for the application that falls in this category.

Using these 6 R's you'll be able to produce a table that contains your on-premises application together with the R that fits it. This detailed assessment per application will serve as your guidebook when it's time to migrate to the cloud.

You can reach me at:
Dev.to
Twitter

How to extract emails from Gmail using Python and AWS

Edward Allen Mercado — Tue, 29 Dec 2020 15:46:20 +0000

Let's build an email extractor application in AWS!

Our goal is to extract emails from our Google Mail and store the data (e.g. Email ID, Subject, Date, etc.) in a CSV file for further processing. This application will be executed every 12 hours.

Setup our Google Mail Account

Let's secure our access in our google mail account. First, we need to generate an App Password for our application, we will then use this generated key for login instead of using our usual google mail password.

Create a Lambda function

Authentication

We'll use the imaplib library to help with the connection and authentication in our google mail account. Using the imaplib IMAP4_SSL, we can established a SSL connectivity with gmail imap url imap.gmail.com, we can then pass the our email and the generated app password for our login.

imap = imaplib.IMAP4_SSL('imap.gmail.com')

try:
    imap.login(email_username, email_pwd)
except Exception as e:
    print(f"Unable to login due to {e}")
else:
    print("Login successfully")

Extract

After authentication, we can now extract the email data. For this, I selected my Inbox and get all the email id's and iterate through them one by one.

imap.select('inbox')
data = imap.search(None, 'ALL')
mail_ids = data[1]
id_list = mail_ids[0].split()   
first_email_id = int(id_list[0])
latest_email_id = int(id_list[-1])

for email_ids in range(latest_email_id, first_email_id, -1):
    raw_data = imap.fetch(str(email_ids), '(RFC822)' )

    for response_part in raw_data:
        arr = response_part[0]
        if isinstance(arr, tuple):

            msg = email.message_from_string(str(arr[1],'utf-8'))
            email_subject = msg['subject']
            email_from = msg['from']
            email_date = msg['Date']

You noticed that we split the mail id's because we need to remove a character so we can easily iterate through them. Google mail id's are incremental numbers, the lowest number is the oldest mail and the highest number will be the most recent mail in your mailbox.

Store

At this point we're able to extract the needed details from our emails, we're now ready to store them. For this, we're gonna use the CSV library that is included in Python standard library to easily manage our data's inside a .csv file.

with open('/tmp/<your_file>.csv', 'a', newline='') as file:
        writer = csv.writer(file)
        writer.writerow([email_ids, email_from, email_subject, email_date])

Transformation

Our lambda function has a /tmp directory for temporary storage of our data. Let's use this as a storage for our extracted data and transform the data using the power of Pandas Library before uploading it to S3.

Note: /tmp is a 512MB storage in our Lambda function. This directory will not be wiped after each invocation it actually preserve itself for 30 minutes or so .. to anticipate any subsequent invocations.

Upload

Let's now upload our .csv file to our S3 Bucket.

try:
    response = s3_client.upload_file("/tmp/<your_file>.csv", s3_bucket, "<file_name_in_s3>")
except Exception as e:
    print(f"Unable to upload to s3, ERROR: {e}")
else:
    print("Uploaded file to s3")

Control Flow

Let's add a control flow to determine whether we're inserting a whole new data initially or just need to append the most recent data on our .csv file because after all, this process is scheduled to execute every 12 hours.

If our .csv file does not exists in our AWS S3 Bucket then we'll extract all of the existing emails in our account. We can use the boto3 library to interact with AWS resources.

If it does exists, we can just append the new emails in our data.

What if there's no new email received? Let's then compare the latest_email_id from our gmail and the latest_email_id from our .csv file, also using these variables we can substitute them in our Extract code to control the range of email data that we're gonna extract and append in our .csv file.

try:
    s3_resource.Object(s3_bucket, 'emails.csv').load()
except botocore.exceptions.ClientError as e:

    if e.response['Error']['Code'] == "404":
        # The object does not exist.
        print("Excel file not found.. Initial Insert")
        #create csv
        create_csv()
        #insert initial values
        initial_insert(imap, latest_email_id, first_email_id)
        #store to s3
else:
    #compare
    if latest_email_id != last_email_id_from_csv:
        #append data
        update_insert(imap, last_email_id_from_csv, latest_email_id)
    else:
        #dont append anything
        print("Nothing is inserted")

That's it! You can now view your .csv file on your S3 Bucket.

Schedule Actions

Let's leverage AWS EventsBridge and configure it to execute our Lambda function every 12 hours.

Deployment and Security

I created all of the resources using an AWS Cloudformation template and use it's Paremeters section to provide email and app generated password and store them in AWS SSM Parameter Store.

Overall, here's the diagram of our application.

If you happen encountered some issues, just hit me up in the comments.

You'll see the full implementation and codebase in my repository

You can reach me at:

Dev.to
Twitter
LinkedIn

Build a modern Web Application

Edward Allen Mercado — Thu, 17 Dec 2020 07:14:41 +0000

What makes your web application modern?

There's a lot of aspects you need to consider to call it a modern web application. For me, the most important one is that your application can dynamically alter their own content without loading a new document and can handle large to intermittent shifts of traffic to meet the demands.

Modern applications utilizes the use of cloud for it to be highly available and scalable, this kind of applications isolates business logic, optimize reuse and iteration and remove administrative overhead whenever possible. For example, AWS cloud has a lot of services that enables you to just focus on writing your code while automating infrastructure maintenance tasks.

Create a Static Website

I said earlier that the most important aspect for your web application is to be dynamic (don't worry we'll get there), we can't also deny the fact that there are always parts of the website that are fixed.

The best and the cheapest services that will handle our static contents are AWS CloudFront and AWS S3.

Let's create an AWS S3 bucket and upload all of our static web contents (e.g. html, css, JS, medias, etc.). I'll configure our CloudFront distribution to deliver these contents in multiple Edge Locations around the world.

For security, I'll create an CloudFront Origin Access Identity (OAI) and create a S3 Bucket Policy stating that this identity only can have a read access on our S3 Bucket. I'll use AWS Certificate Manager to provision a certificate for our website so we can deliver our content via HTTPS.

Additionally, you can register a domain in AWS Route53 for the FQDN (Fully Qualified Domain Name) of our website and create a record that will point to our CloudFront distribution.

Build a Dynamic Website

Here I will create a Flask application in a container behind a Network Load Balancer. These will make our frontend website more interactive and yes, you read it right, dynamic.

Here I'll used AWS Elastic Container Service (ECS) with the deployment option of Fargate so I can deploy containers without having to manage any servers.

Build a docker image from the dockerfile with our application dependencies and push the image to AWS Elastic Container Repository (ECR), you can troubleshoot your docker image by running it locally.

After the docker image is pushed to ECR, let's create ECS Cluster, Service, and Task Definition so we can place where (subnet) our containers will run and set resources and configurations that they require.

Let's then create a Network Load Balancer and configure the listener to our Target group that will forward the traffic to our containers.

Here we will create AWS API Gateway that will proxy the traffic from the internal Load Balancer. To make this work we will provision a VPC Endpoint for our Load Balancer that is inside the VPC to be able to communicate with the API Gateway.

Build a CI/CD Pipeline

Let's integrate Continuous Integration/Continuous Deployment (CI/CD) in our application so every changes that will be made are automatically built and deployed to our docker image. Its a good practice to increase the development speed, we will not go through all the same steps every time we wanted make some changes in our application.

First, let's create an AWS CodeCommit Repository where we can store our code, then an artifacts bucket that will store all our CI/CD artifacts for every build in our pipeline.

Let's continue with the service that will do the most of the tasks in our pipeline CodeBuild, it will provision a build server using the configuration provided and execute the steps required to build our docker image and push every new version to ECR.

Finally, lets arrange our pipeline to automatically build whenever a code change was pushed in our CodeCommit repository then configure it to deliver the latest code that was build using our CodeBuild project to our ECR, all of this will be orchestrated using CodePipeline.

At this point, if you have any issues on your builds, check the Identity Access Management (IAM) Roles you granted on every service and also check the CloudWatch Logs.

Store Data

We will create a DynamoDB Table that will store our data.

While we are on the table creation, let's also create Secondary Indexes so we can filter items efficiently.

Again, we will create a VPC Endpoint for our container be able to communicate to DynamoDB without traversing to the public network.

User Registration

User Registration will help us modulate our website features access. Obviously, authenticated users will have more features then unauthenticated users.

Let's create AWS Cognito, using this service we will be able to require our users to be authenticated before they can do something that may affect our database.

We will setup our Cognito to require users to verify their email address before they can complete their registration

Again, we will setup an API Gateway that will be use to authorize actions for our authenticated users.

Capture User Behaviors

By implementing this, we can understand the actions that our users performs in our website (e.g. User Clicks, etc.). This will help us design our website efficiently so we can provide better user experience in the future.

To help us gain insights on user behaviors, let's use AWS Kinesis Firehose that can ingest data and will help us store these data's to several storage destinations, for this we'll gonna store the ingested data to S3 (e.g. S3, ElasticSearch, RedShift, etc.)

We will again use API Gateway to abstract the request being made to the Kinesis Firehose.

While the website interactions are being ingested, we will use AWS Lambda to process these data furthermore.

Problems encountered along the way

Docker Pull Rate Limits

This made my build fail multiple times and by the time I checked my CloudWatch Logs, I saw error:

toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

I found out that this was caused by Docker Pull Rate Limit. This rate limit has been announced by Docker, Inc. that took effect last November 2, 2020.

For more information about this, you can check this blog from Docker.

Solution
Here is the solution that I used.

Insufficient space on my build

I updated my dockerfile to a specific Linux distribution version and by the time I try to build my image, it throws an error:

Docker error : no space left on device

Solution
docker prune -all

Overall, here's the diagram with all the related microservices integrated with each other.

Here's my final output: Mythical Mysfits

Does it look familiar? Yes! it's a workshop made by Amazon Web Services (AWS). You can see the detailed information here. I added steps and integrated services for the application to be much efficient and highly available.

You can reach me at:

Dev.to
Twitter
LinkedIn