nick rondeau

ArgoCD: Multi-Cluster Deployments with AWS EKS

Nick Rondeau — Tue, 10 Mar 2026 20:17:43 GMT

I've been using ArgoCD daily for about the past year almost. I've really been able to explore it's strengths, as well as it's shortcomings. The thing I think ArgoCD handles the best is deployment to multiple clusters. I will guide you through this process and how to configure it yourself.

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes. It is designed to manage application deployments and automate the process of synchronizing application states between Git repositories and Kubernetes clusters. ArgoCD provides a user-friendly interface for visualizing and managing application deployments in real-time.

Key Features:

GitOps-Centric: Operates directly from Git repositories, ensuring version control and auditability.
Declarative Configuration: Uses declarative definitions for application deployment, simplifying the management process.
Automated Sync: Continuously monitors and synchronizes application states to match the desired configurations in Git.
Visual Dashboard: Offers a comprehensive dashboard for real-time monitoring and management of deployments.

ArgoCD does an excellent job managing application deployments to multiple EKS clusters, on different AWS accounts. It also has a lot of features built in that make managing these deployments a bit easier. The graphic below describes the architecture of this build.

Infrastructure Overview

Why Argo CD?

Application definitions, configurations, and environments should be declarative and version controlled.
Application deployment and lifecycle management should be automated, auditable, and easy to understand.
Provides a WebUI to manage deployments and prove a visual overview.
Automated deployment of applications to specified target environments
Support for multiple config management/templating tools (Kustomize, Helm, Jsonnet, plain-YAML)
Ability to manage and deploy to multiple clusters
SSO Integration (OIDC, OAuth2, LDAP, SAML 2.0, GitHub, GitLab, Microsoft, LinkedIn)
Multi-tenancy and RBAC policies for authorization
Rollback/Roll-anywhere to any application configuration committed in Git repository
Health status analysis of application resources
Automated configuration drift detection and visualization
Automated or manual syncing of applications to its desired state
Web UI which provides real-time view of application activity
CLI for automation and CI integration
Webhook integration (GitHub, BitBucket, GitLab)
Access tokens for automation
PreSync, Sync, PostSync hooks to support complex application rollouts (e.g.blue/green & canary upgrades)
Audit trails for application events and API calls
Prometheus metrics
Parameter overrides for overriding helm parameters in Git

Solution Overview

We will deploy and configure ArgoCD to a central management cluster which will oversee application deployment to multiple clusters that act as our development environments.

Install and Configuration

Begin the installation process. Get AWS credentials for the AWS account you would like to designate as the management account. Deploy ArgoCD to the management cluster.

Login to the AWS Account and update the kubeconfig. In this case, the Infrastructure Cluster. Create the namespace and run the install manifest.

aws eks update-kubeconfig --region us-east-2 --name infra-us-east-2
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

First, we create some AWS IAM resources with Terraform in each account. Starting with the management account. Here are the local variables we will need to predefine.

locals {
  mgmt_cluster           = "infra-us-east-2" #The name of your mgmt cluster
  mgmt_account_id        = "123456789-1" #The account id of your mgmt cluster
  mgmt_eks_oidc_provider = "oidc.eks.us-east-2.amazonaws.com/id/CXXXXXXXXXXXXXXXXXXX" #The oidc provider of your mgmt cluster
  dev_cluster            = "dev-us-east-2"   #The name of your dev EKS cluster
  dev_cluster_account_id = "123456789-2"   #The account id of your dev cluster
  test_cluster            = "test-us-east-2"   #The name of your test EKS cluster
  test_cluster_account_id = "123456789-3"   #The account id of your test cluster
}

Now we create the code for the IAM role in the infra account.

# ArgoCD IAM - Management Cluster Role

resource "aws_iam_role" "mgmt_argocd_service_account" {
  name               = "${local.mgmt_cluster}-argocd-server-sa"
  path               = "/"
  assume_role_policy = <

Now, we do similar steps in the other accounts. First Dev Account.

locals {
  mgmt_cluster           = "infra-us-east-2" #The name of your mgmt cluster
  mgmt_account_id        = "123456789-1" #The account id of your mgmt cluster
  dev_cluster            = "dev-us-east-2"   #The name of your dev EKS cluster
  dev_cluster_account_id = "123456789-2"   #The account id of your dev cluster
}

# ArgoCD - Dev Cluster Cross Account Role

resource "aws_iam_role" "dev_cluster_argocd_service_account" {
  name               = "${local.dev_cluster}-argocd-server-sa"
  path               = "/"
  assume_role_policy = <

And Test Account.

locals {
  mgmt_cluster           = "infra-us-east-2" #The name of your mgmt cluster
  mgmt_account_id        = "123456789-1" #The account id of your mgmt cluster
  test_cluster            = "test-us-east-2"   #The name of your test EKS cluster
  test_cluster_account_id = "123456789-3"   #The account id of your test cluster
}

# ArgoCD - Test Cluster Cross Account Role

resource "aws_iam_role" "test_cluster_argocd_service_account" {
  name               = "${local.test_cluster}-argocd-server-sa"
  path               = "/"
  assume_role_policy = <

With all of this in place, it’s time to access the web ui. We need to grab the password from a secret in our management cluster for the first login attempt.

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath='{.data.password}' | base64 --decode

Kubectl port-forwarding is used here to connect to the API server without exposing the service.

kubectl port-forward svc/argocd-server -n argocd 8080:443

Leave this terminal up.

Now, access the UI https://localhost:8080

Use the username admin and the password we pulled from the secret in the previous step.

You will be greeted with the applications tab. We have none set up yet. Go to settings and change the password for the admin account.

Once verified it’s operational, there is some additional configuration needed for the cross-account IAM roles to access the EKS clusters in the Dev and Test environments.

Start by editing the aws-auth ConfigMap for the dev and test clusters. Login to each and follow these steps:

kubectl edit -n kube-system configmap/aws-auth

Under mapRoles you will be adding the following information:

    - groups:
      - system:masters
      rolearn: arn:aws:iam::ACCOUNT_ID:role/CLUSTER_NAME-argocd-server-sa
      username: arn:aws:iam::ACCOUNT_ID:role/CLUSTER_NAME-argocd-server-sa

💡

For example - If working in the Dev account, use the Dev account ID and cluster name. When making the edit on the Test cluster, use the Test account ID and cluster name.

It may also look like this:

{"rolearn":"arn:aws:iam::1234XXXX0:role/test-us-east-2-argocd-server-sa","username":"arn:aws:iam::2391222XXXX7:role/test-us-east-2-argocd-server-sa","groups":["system:masters”]}

The next step involves authenticating back into the management cluster. We will be linking our ArgoCD service accounts with the IAM roles.

kubectl edit serviceaccount argocd-server -n argocd

Annotate the service account with the role information.

eks.amazonaws.com/role-arn: arn:aws:iam::MGMT_ACCOUNT_ID:role/MGMT_CLUSTER_NAME-argocd-server-sa

Do the same for the application controller service account.

kubectl edit serviceaccount argocd-application-controller -n argocd

Next, we need to add a SecurityContext to the argocd-server k8s deployment.

kubectl edit deployment argocd-server -n argocd

Scroll down you will see an empty securityContext field. Change it to the following:

securityContext:
  fsGroup: 999

Lastly, restart all of the deployments.

kubectl rollout restart deployment argocd-server -n argocd
kubectl rollout restart deployment argocd-repo-server -n argocd
kubectl rollout restart deployment argocd-redis -n argocd
kubectl rollout restart deployment argocd-notifications-controller -n argocd
kubectl rollout restart deployment argocd-dex-server -n argocd
kubectl rollout restart deployment argocd-applicationset-controller -n argocd

We haven’t added any clusters at this point. First, we need to make sure the roles are properly configured.

💡

There is no option to add an external cluster through the web UI.

Create a pod in the argocd namespace, we will use this to install the ArgoCD CLI and AWS CLI to ensure everything is working correctly. Deploy the following yaml to the management cluster. Save as argocd-cli-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    app.kubernetes.io/name: argocd-cli
  name: argocd-cli
spec:
  serviceAccountName: argocd-server
  containers:
  - name: argocd-cli
    image: amazon/aws-cli
    command: [ "/bin/bash", "-c" ]
    args:
      - |
        set -e
        curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
        install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
        sleep 5000

Apply it.

kubectl apply -f argocd-cli-pod.yaml -n argocd

Let's shell into it:

kubectl exec --stdin --tty argocd-cli -n argocd -- /bin/bash

The pod now has both CLIs installed and let’s check our credentials to make sure the IAM linked role is configured correctly.

Now, we assume the role in one of the workload accounts using it’s account number and cluster name.

aws sts assume-role --role-arn arn:aws:iam::123456789:role/test-us-east-2-argocd-server-sa --role-session-name Workload1

The output will look like this, copy the Keys and Token.

Export the provided keys and token, then check your aws credentials again.

export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
export AWS_SESSION_TOKEN=

aws sts get-caller-identity

It should now show the workload account number, instead of the infra account number, The output will be different than before.

We now export the kubeconfig and add the cluster to our ArgoCD managment cluster.

aws eks update-kubeconfig --name test-us-east-2 --region us-east-2

argocd login argocd-server --username admin --password 1234567890

argocd cluster add arn:aws:eks:us-east-2:123456789:cluster/test-us-east-2 --aws-role-arn arn:aws:iam::123456789:role/test-us-east-2-argocd-server-sa --aws-cluster-name test-us-east-2

Do the same for the Test Cluster. Unset the aws credentials.

We have now added and external cluster through AWS AUTH to our management cluster. Now we can deploy applications by setting the destination server for the applications we are looking to deploy.

💡

You may need to restart the ArgoCD controller pod to update authentication changes.

Next, we move on to setting up the actual deployments to the clusters. Let’s try creating a test application. I am going to use the guestbook example from the ArgoCD repository.

`Deployments`

In the ArgoCD UI go to Settings > Projects and create a new project.

This is where we set the base configuration for our applications. You can whitelist resources and various other tasks.

Add your source repos.

Create entries for all of the clusters you plan to deploy to, the ones we previously registered with ArgoCD.

Set the allowed Cluster Resources and allowed Namespaces permissions:

You can also run this command in the CLI:

argocd proj allow-cluster-resource  "*" "*"

Now, we move to connecting GitHub and our project.

You will need to authorize GitHub via a Personal Access Token (PAT). In GitHub, under settings, at the bottom you will see Developer settings.

Then create a classic token.

Then, in ArgoCD you will connect to the repo via HTTPS and then use the user/pass from the token.

Now go to Applications and select new app.

Select the project we created, and the path is the path on the repository you want argocd to watch for this deployment. In this case, the dev environment.

Sync the application, you will see all the pods are healthy and the sync process successful.



Creating a Kubernetes Cluster at Home
Nick Rondeau — Thu, 11 Apr 2024 02:11:03 GMT
I've had the itch recently for a really good homelab project.  After looking at the other server I have, it's running almost 50 containers.  It's main use is Plex.  It runs everything from this blog you are reading, to our family recipe book.  Why am I bogging it down while it's trying to transcode media?  I asked myself this and decided to make a plan for these additional services.
I've always wanted to run my own Kubernetes cluster and a little challenge is nothing to be scared of.  It's always looked like it would fun to make and maintain my own.  I've already done it a bunch of times, installing and creating a new cluster is part of the CKA exam after all.  I was initially looking at k3s, but decided to do the full k8s install instead.  More fun that way with a bit more control.  Also, it's fun to learn as much as possible during the process.
A small footprint, a lot more power, and much cheaper than raspberry pi 4s
I purchased four Lenovo ThinkCentre M900 workstations,  so I will have a master and three worker nodes.  An affordable solution, each unit was under $75.
This will run through the process of how I created my Kubernetes cluster, starting from fresh Debian bookworm installs to having a working cluster.  Let's begin.
Login as root and install sudo:
su -
apt update
apt install sudo
and then add yourself to sudo:
adduser myusername sudo
Install ufw - the firewall we are going to use for this.
sudo apt install ufw
Next, add your default policies.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
Enable ufw.
sudo ufw enable
Let's set a static ip.
sudo apt install vim net-tools
View route and gateway
netstat -nr 
It will have an output like this:

ronnic@debian-lenovo1:~$ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eno1
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eno1
Let's edit our interfaces file, first back it up.
cp /etc/network/interfaces /etc/network/interfaces.bak
If you need to ever restore it, reverse the command.
cp /etc/network/interfaces.bak /etc/network/interfaces
Make the following edits, using your own info:
iface eth0 inet static
       address 192.168.1.10 #this is the static IP address I want to set
       netmask 255.255.255.0 #use the info from the last line above
       network 192.168.1.0  #use the info from the last line above
       gateway 192.168.1.1 #your router's address/gateway
Reboot and ssh back in using the new IP.
Services with known vulnerabilities are a huge attack vector. You can get automatic security updates with unattended-upgrades.

Install the package:
sudo apt install unattended-upgrades
Enable automatic upgrades:
sudo dpkg-reconfigure unattended-upgrades
The build-essential meta package includes all the relevant tools and necessary packages to enable developers to build and compile software from the source.
sudo apt install build-essential -y
Install Docker and follow the post-install instructions for linux as well. This allows the running of docker commands without sudo as well as running at startup.
Now, let's set up kubectl, which is the command line tool for kubernetes.  Well also install kubelet, the node agent.  Last, kubeadm for cluster admin.  This is done on what will be our master node.
Install packages needed to use the Kubernetes repository:
sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl
Download the public signing key. The same signing key is used for all repositories so you can disregard the version in the URL:
sudo mkdir -p -m 755 /etc/apt/keyrings

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
Add the repository:
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
This overwrites any existing configuration in /etc/apt/sources.list.d/kubernetes.list
Install the tools:
sudo apt update
sudo apt install -y kubelet kubeadm kubectl
Prevent automatic updates to these applications:
sudo apt-mark hold kubelet kubeadm kubectl
Verify Installation
To verify your installation, you can check the version of each tool:
kubeadm version
kubectl version --client
sudo systemctl status kubelet
You should see that the service is active even if you haven’t yet used it to set up a cluster.
Everything working perfectly so far
Kubernetes requires swap to be turned off.  Either install Debian without a swap partition, if one exists, comment out any swap lines in /etc/fstab
Also, run
sudo swapoff -a
Load Required Kernel Modules next, ensure that the br_netfilter module is loaded. This module is necessary for Kubernetes networking to function correctly.
sudo modprobe br_netfilter
To ensure these settings persist across reboots, add the following lines to /etc/sysctl.conf or a Kubernetes-specific configuration file under /etc/sysctl.d/:
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
Then apply the sysctl settings with:
sudo sysctl --system
Next, Adjust Firewall Settings. Since we set up ufw, we need to allow traffic on the ports used by Kubernetes. 
To elaborate on the network setting, here is a bit of an explanation of the ports we need open for master and worker.
For Master Nodes:
6443: This is the Kubernetes API server port, the primary control plane component for the cluster. It must be accessible from all nodes in the cluster, so if your worker node needs to communicate with the master, this port must be open.
2379-2380: These ports are for etcd server communications, used by Kubernetes to store all cluster data. They need to be accessible by all master nodes.
10250: The Kubelet API, which must be accessible from the Kubernetes control plane.
10251: The kube-scheduler port, accessible by the control plane.
10252: The kube-controller-manager port, also for the control plane.
179: Calico
For Worker Nodes:
10250: The Kubelet API, which should be accessible from the master node.
30000-32767: These are NodePort ports, which might be used if you expose services using NodePort type. They need to be accessible from outside the cluster.
For ufw, commands to open these ports would look like:
sudo ufw allow 2379:2380/tcp
sudo ufw allow 6443,10250,10251,10252,179/tcp
Finally, we get to initializing the master node. Initialize the Cluster by running kubeadm init to initialize the cluster. Specify the pod network CIDR if you plan to use a networking solution that requires it (such as Calico):
sudo kubeadm init --pod-network-cidr=192.168.0.0/16
I was running into an error when running the init command:
If you find you are also getting this error, all you need to do is remove the containerd config, then restart it.
Remove the installed default config file: rm /etc/containerd/config.toml
containerd config default > /etc/containerd/config.toml
sudo systemctl restart containerd
Now, we deploy a pod network: Choose a pod network add-on compatible with kubeadm and deploy it. For example, to deploy Calico.  Download the deployment.yaml from here:
https://docs.projectcalico.org/manifests/calico.yaml
Apply after you uncomment the following lines in it:
            - name: CALICO_IPV4POOL_CIDR
              value: "192.168.0.0/16"
We need to set up calicoctl also, which I do as a kubectl plugin.
Download and make calicoctl executable:
curl -L https://github.com/projectcalico/calico/releases/download/v3.27.3/calicoctl-linux-amd64 -o kubectl-calico
chmod +x kubectl-calico
Find a suitable directory in your PATH:
echo $PATH
This command will output something like /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin. These are the directories (separated by colons) where your system looks for executable files.
Move kubectl-calico to a directory in your PATH:
For most users, /usr/local/bin is a common directory for user-installed software and is typically in your PATH. To move kubectl-calico there, use:
sudo mv kubectl-calico /usr/local/bin
Let's make sure it works, run:
kubectl calico version
Now, let's set up the worker nodes.  Make sure to disable swap.
Run the following for Master and Worker:
sudo systemctl status *swap 
sudo systemctl mask  "dev-<>.swap"
Follow the same instructions for installing kubeadm, kubectl, and kubelet.  Also, allow the worker ports in ufw for each node.
If you need to create another token and join command, use the following on the master node:
sudo kubeadm token create --print-join-command
For each worker we load Debian on the new machine, configure the static ip, configure the firewall, install docker and containerd, then install the kube tools.  Then, run the join command.
As you are running these join commands, check back on your master node to see if the additional workers are ready.
Four nodes with READY status!
There you have it, once you join the other nodes, you are ready to use your new cluster!
Want to automate this with Ansible?  I have it covered.
GitHub - ronnic1/ansible-k8s-nodes: Ansible set up of local Kubernetes Cluster
Ansible set up of local Kubernetes Cluster. Contribute to ronnic1/ansible-k8s-nodes development by creating an account on GitHub.
GitHubronnic1
Thanks for reading.


Drone CI Workflows for Encrypted Backups to AWS S3
Nick Rondeau — Fri, 08 Mar 2024 18:50:39 GMT
Recently I started self hosting Vaultwarden and wanted a nice automated way to run backups, but also encrypt them.  I was already using Gitea , and after some research Drone CI seemed like an excellent fit to get me started.
I want to configure a pipeline to grab the docker config directories on my server, compress them, encrypt them, and then upload to S3.  This would ensure I always have a cloud backup for all of my containers - especially important services like Vaultwarden.  I need to always have a backup of my personal vault.  What better place than s3?
First, I need to set up a little infrastructure.  I want to have my Terraform state file also saved to s3, with Dynamodb handling state locking.  This is a pretty simple set up.



You will need to create the bucket part of the code first, then bring in the state and dynamodb sections.  When you run terraform init -migrate-state it will move it over to s3. 
A successfully uploaded state to s3
Create an IAM role for drone with s3 access and kms access if you plan to use SSE.
Authorize Drone CI in the Gitea settings, so it can access the repo we will run the pipeline from.
Here is the docker compose file I used, configured for gitea.



In this compose file, we are creating the drone container, as well as a runner which is required to run our pipeline.
A quick refresher to load the compose file:
To start your application (in the background or detached mode):
docker compose up -d
To stop your application and remove containers, networks, etc.:
docker compose down
To build or rebuild services:
docker compose build
All of the important pieces are in place.  Next, create a repository and place a .drone.yml file which is places in the root of the repo.
Add a few secrets to the repo.
AWS access keys, default region, as well as the encryption key which can be any 16+ digit string you like.  This will be the key to decrypt your archive.



The pipeline is pretty simple, it compresses and encrypts the config folder, creating a .7z file.  Then, uploads to your s3 bucket of choice.
It's time to run it! Log into DroneCI, you will now see the list of your repos.  Choose the repo you placed the .drone.yml file.
Activate the repository
After the repository is activated, select it. Now create a build with the pipeline.
Choose branch and create
You should now have a working pipeline.
Let's verify in S3.
All of our encrypted archives placed neatly in our bucket. 
I hope this helps you with your own homelabs and servers. It's no use hosting services like Vaultwarden if your whole password vault could be corrupted or lost on a local machine.  This is a simple and effective to securely backup these services.  Not to mention cheap.  This costs less than 25 cents a month in s3 charges, if you use KMS for SSE that will cost an extra $1. 
Thank you for reading!


Using Docker Swarm on AWS with Ansible & Terraform
Nick Rondeau — Sun, 03 Mar 2024 07:50:25 GMT
Docker Swarm is an open-source container orchestration platform and is the native clustering engine for and by Docker. It allows you to manage multiple containers deployed across multiple host machines.
One of the key benefits associated with docker swarm is the high level of availability offered for applications. In a docker swarm, there are multiple worker nodes and at least one manager node that is responsible for handling the worker nodes’ resources efficiently and ensuring that the cluster operates efficiently.
Let’s start setting up our cluster in Terraform.
Verify your Terraform installation:
$ terraform --version
Terraform v0.14.2
With Terraform (version 0.14.2 as of writing this) we can provision cloud architecture by writing code which is usually created in a programming language. In this case it’s going to be HCL — a HashiCorp configuration language.
We are going to be setting up a Swarm cluster on AWS using Ansible and Terraform, refer to the diagram below. We will be setting up one Master node and two Worker nodes.
Global Variables
This file contains environment specific configuration AMI, Instance type, region, etc.



Configure AWS as our Provider



Set up Security Groups for inbound/outbound traffic.



Configure our EC2 Instances, Our Workers and Master



Next, our Bootstrap script to install the latest version of Docker



Transform to Swarm Cluster with Ansible, setting up the playbook



Everything is now complete and ready to initialize Terraform, Plan out the actions we are going to take, and then apply them to the cloud.
$ terraform init
$ terraform plan
$ terraform apply
Update the /etc/ansible/hosts file with the public ip of each EC2 instance.
$ ansible -i hosts playbook.yml
I felt this was a good introduction to all of the tools involved.  Thanks for reading.
I have uploaded all the files to GitHub.


CI/CD using Docker, Travis CI, ECS, and Python
Nick Rondeau — Mon, 12 Feb 2024 18:00:02 GMT
I am going to take you through the steps setting up an environment for automated building, testing, and deployment, using containers and services hosted in the cloud.
What we need:
GitHub
Docker and Docker Compose installed
Docker Hub
Travis CI
Amazon Web Services (AWS)
When a commit or a merge is done to a branch, this will trigger Travis and run a list of instructions to build and run our tests. If the build is done successfully and every test passes, Travis will push our Docker image to Docker Hub and trigger an update event on ECS telling to our cluster that it has a new image version to be downloaded.
Our Python application consists of two files. main.py contains our Flask code and then requirements.txt which will layout dependencies etc.







Now let’s build a Dockerfile and a docker-compose for our Python code and upload it to Docker Hub.



Now it’s time to create the image and push it to Docker Hub.
$ docker-compose build --pull
$ docker-compose push
You should see something similar to this when complete:
a successful build
and it’s now been pushed to Docker Hub….
Let’s check
There it is!
Now it’s time to log in to Travis-CI with your GitHub account.This will sync your repositories.
We will need to create .travis.yml and travis-deploy.sh scripts:







Now we approach the ECS portion…
Choose a name for the container. for image, use the following format:
Docker Hub username/Repository name:latest
Also, under port mappings make sure you specify 8000.
Then under Load Balancer type, choose Application Load Balancer.
Choose a cluster name.
Review and create.
Now on to Travis CI…
You will see your GitHub repo you have your travis file uploaded to. it will detect it and run the file.
We have to set up our environment variables in Travis. Under your project, go to settings.
this is what they should look like
Now, on AWS go to EC2>load balancer>Basic Configuration, copy your DNS. Copy the DNS name and paste in your browser with the port 8000.
You will see the text we set up earlier
text we entered into main.py
Let’s go ahead and put everything to the the test! Make a change to the text and commit. You can see events put in motion on Travis.
Refresh and see the update — It worked!
After building and testing Travis will deploy our image to Docker Hub and notify ECS that there’s a new version. You have now created your own CI/CD environment! Thanks for reading and following along. Share what you’re working on in the comments.
I have uploaded all my files to GitHub so you can follow along.


VPC Peering Between Two AWS Accounts Using Terraform
Nick Rondeau — Fri, 09 Feb 2024 17:42:36 GMT
Continuing with Terraform, it’s amazing how easily it cuts through tedious tasks, such as setting up more complicated infrastructure. Taking something you would assume would take hours, into minutes and easily replicated if need be. The end result of this project will be completing a VPC peering connection request across 2 AWS accounts.
It’s assumed that the 2 VPCs that you need peered already have been created previously. We need to create the peering request from the peering owner VPC, accept the peering connection request in the accepter account, and update the route tables in both the VPCs with entries for the peering connection from either side.
Some of the salient considerations to be kept in mind are:
Access Credentials are needed for both AWS accounts
There may be multiple route tables in each VPC, and peering connection entries have to be updated in all of them



Since we have 2 accounts, I’ve created 2 variables namely owner_profile and accepter_profile to pass these at runtime, or as a .tfvars file. I have the option to hard-code credentials, but it is not a good security practice. Additionally, since we serve multiple customers and we will be re-using the code, variables are the way to go. I’ve also defined variables for both the VPCs in question.
When you do a cross-account peering connection request, you need the 12 digit account ID of the AWS account where the accepter VPC resides. If you’ve noticed, I have not defined this as a variable. While it’s not straightforward, it’s possible to get the account ID using the Amazon Resource Names (ARNs).
VPC Peering Request Screen- AWS Console
ARNs typically have a format as follows:
arn:aws:servicename:region:account-id:resource
Since we now have the VPC id of the accepter VPC, we can use it’s ARN to extract the account-id. The code below does exactly that. I am using the aws_vpc data source, and using the arn to extract the account-id. I have defined the accepter_account_id as a local value.



Now that I have the information needed to raise a VPC peering request, I am completing the peering request initiation and acceptance as below. If you notice, I am using the profile variables to tag the peering connections as well. Tagging is a good practice, especially if you have multiple peering connections and it’ll help during any maintenance or network troubleshooting.



Now that the peering connection is created, we have to update the route table entries on both sides to send traffic via the peering connection. Given that a single VPC can have multiple route tables, and I wanted the to code to work irrespective of the number of route tables each VPC has. I have created a loop using count to cycle through all the route tables and create the route entry to the other VPC via the peering connection ID. Note that the route tables are being updated with the peered VPC CIDR block. It is also possible to route specific subnets via the peering connection, but I have not done that here. This may be relevant in cases where you need to access some central servers such as Directory Service, Anti-virus server, in a Shared Services VPC as part of a landing zone. Some organisations may also host other servers in the Shared Services VPC which are not relevant for all the peered VPCs, and want to restrict access to specific subnets only.



Conclusion
I explained how to create VPC peering connections and update route tables. I also touched upon some concepts of Terraform like data sources, split local values, and loops. You can find the complete Terraform code for the above at my GitHub repository. Thanks for reading, until next time.


The OSI Model - The Seven Layers Explained
Nick Rondeau — Tue, 06 Feb 2024 20:10:31 GMT
The Open Systems Interconnection (OSI) model is a conceptual framework used to understand and standardize the functions of a telecommunications or computing system without regard to its underlying internal structure and technology. Its design is structured into seven distinct layers, each with a specific role in the process of transferring data from one system to another. These layers facilitate modular troubleshooting by allowing network administrators to isolate and address issues at a specific layer, enhancing the efficiency and reliability of network diagnostics.
In the context of data transmission, the OSI model employs a rule where each layer on the source side (the sender) engages in communication with its equivalent layer on the destination side (the receiver). This layer-to-layer interaction ensures that data packets are processed in a uniform manner across both ends of the communication line. For instance, the Data Link layer, which is responsible for node-to-node data transfer and error correction at the link level, one device will directly communicate with the Data Link layer on another device. This direct correspondence between identical layers across the communication stream ensures data integrity and consistency, thereby facilitating seamless and dependable data exchange. This organized approach to data handling allows networks to operate smoothly, supporting a wide range of applications and services.
Layer 1: Physical
This layer is primarily concerned with the tangible elements of network communication, including the hardware and the physical media that facilitate the movement of data across devices. As the initial and most foundational layer of the OSI model, the Physical layer plays a pivotal role in the transmission of digital information.
Key aspects of the Physical layer include:
Signal Conversion: It is responsible for transforming digital data into various forms of signals — electrical, optical, or radio — depending on the medium of transmission. This conversion is crucial for enabling the physical movement of data between devices on a network.
Connection Interfaces: The layer manages the physical connection points, such as network ports, which serve as gateways for data to enter and exit devices. These ports are vital for establishing and maintaining network connections.
Transmission Rate and Distance: The Physical layer determines the speed at which data is transmitted and the maximum distance it can cover. These parameters vary based on the types of cables and technologies employed, affecting the efficiency and scope of data communication.
Signal Integrity: Maintaining the quality of the data signals over the course of their journey is a critical function of this layer. It ensures that data is delivered accurately to its destination, free from errors and interference.
In essence, the Physical layer is dedicated to the infrastructure and physical components that underpin data transmission. It lays the groundwork for the seamless exchange of digital information by addressing the practical and mechanical aspects of network communication.
Layer 2: Data Link
Layer 2 of the OSI model termed the Data Link layer, plays a crucial role in the networking framework, particularly in the context of Ethernet networks. It is tasked with overseeing the direct transfer of data between adjacent network nodes and is instrumental in structuring communication at a more granular level compared to the Physical layer.
Key Functionalities of the Data Link Layer Include:
Data Packetization: This layer segments digital data into packets, organizing them into a standardized structure. Each packet encompasses the payload (the actual data intended for transmission) and additional metadata for routing, error detection, and control information. This structured approach to data handling facilitates efficient and reliable data transmission.
Addressing with MAC Addresses: A pivotal component of the Data Link layer's operation is the use of Media Access Control (MAC) addresses. These unique identifiers, akin to a postal address for physical mail, enable the layer to direct data packets to the correct endpoint within a network. Every device connected to the network possesses a distinct MAC address, ensuring precise and directed communication.
Network Traffic Management: Devices such as switches and bridges operate within this layer, acting as the network's traffic managers. They analyze the data packets' MAC addresses and make decisions on how to forward them through the network to reach their destination efficiently. This involves directing traffic to avoid congestion and ensuring that packets are delivered through the most appropriate paths.
Error Detection and Handling: Beyond simply transmitting data, the Data Link layer is also responsible for maintaining data integrity. It employs various mechanisms to detect and correct errors that may occur during transmission. This ensures that the data received at the destination is accurate and uncorrupted, maintaining the reliability of network communications.
In summary, the Data Link layer serves as the linchpin for data packet organization, addressing, and error management within a network. It ensures that data packets are correctly formatted, addressed, and transmitted between devices on the same network, while actively managing and correcting transmission errors to uphold the integrity of the data.
Layer 3: Network
The Network layer, akin to a sophisticated GPS system for data packets, is responsible for determining the most efficient route for data to traverse from its origin to its destination across interconnected networks. It ensures that data is routed correctly through complex network architectures.
Key Features:
Logical Addressing: Assigns IP addresses to data packets, serving as unique identifiers similar to street addresses, guiding data to its correct destination across the internet.
Inter-networking: Facilitates communication between disparate networks, enabling data to move from local networks to the global internet.
Subnetting: Improves network management and security by segmenting larger networks into smaller, manageable sub-networks.
Routing: Determines the best path for data to follow, optimizing the journey of data packets based on network conditions and topology.
Layer 4: Transport
The Transport layer is responsible for the reliable transmission of data segments between points on a network, ensuring that data is delivered in sequence and without errors. It's like the logistics service of the OSI model, breaking down data into manageable packets and ensuring they arrive safely.
Key Features:
End-to-End Communication: Manages data transmission sessions between devices, ensuring accurate data transfer.
Segmentation: Divides larger data streams into smaller segments for easier handling and reassembles them at the destination.
Flow Control: Regulates data transmission to prevent overwhelming the receiver, ensuring a smooth data flow.
Error Handling: Detects and corrects errors that may occur during data transmission, ensuring data integrity.
Layer 5: Session
The Session layer establishes, manages, and terminates connections between applications. It's like a moderator for communications, ensuring that sessions are maintained and properly closed after data exchange.
Key Features:
Session Management: Controls the dialogues (sessions) between computers, establishing, maintaining, and ending connections as needed.
Synchronization: Adds checkpoints in data streams to allow for the resumption of data transfer after a disruption.
Layer 6: Presentation
The Presentation layer acts as the translator for the network, converting data into a format that can be understood by both the sending and receiving applications. It's concerned with the syntax and semantics of the information transmitted.
Key Features:
Data Formatting: Translates data from a format used by the application layer into a common format at the sending station and then back into the application's format at the receiving station.
Encryption and Compression: Provides data encryption for security and data compression for efficient transmission.
Layer 7: Application
The Application layer is where end-users interact with computers, serving as the window through which networking services are accessed. It supports application and end-user processes, facilitating communication between software applications and lower layers of the OSI model.
Key Features:
Resource Sharing: Facilitates access to network resources and services like file transfers, messaging, and email.
Remote File Access: Enables users to access files and directories on remote computers.
Directory Services: Provides a framework for naming and addressing that locates resources and devices on a network.
Network Management: Supports applications that require network access and management capabilities.
In essence, the OSI model delineates the roles and functions of different network layers, from the physical transmission of data to the application-level interactions that users engage with. Understanding each layer's responsibilities provides insight into the complexities of network communication and the protocols that keep us connecte


Deploying an AWS ECS Cluster of EC2 Instances With Terraform
Nick Rondeau — Mon, 05 Feb 2024 08:17:10 GMT
 This project will utilize two major cloud computing tools.
Terraform is an infrastructure orchestration tool (also known as “infrastructure as code(IaC)”). Using Terraform, you declare every single piece of your infrastructure once, in static files, allowing you to deploy and destroy cloud infrastructure easily, make incremental changes to the infrastructure, do rollbacks, infrastructure versioning, etc.
Amazon created an innovative solution for deploying and managing a fleet of virtual machines — AWS ECS. Under the hood, ECS utilizes AWSs’ well-known concept of EC2 virtual machines, as well as CloudWatch for monitoring them, auto scaling groups (for provisioning and deprovisioning machines depending on the current load of the cluster), and most importantly — Docker as a containerization engine.
Here’s what’s to be done:
Within a VPC there’s an autoscaling group with EC2 instances. ECS manages starting tasks on those EC2 instances based on Docker images stored in ECR container registry. Each EC2 instance is a host for a worker that writes something to RDS MySQL. EC2 and MySQL instances are in different security groups.
We need to provision a some building blocks:
a VPC with a public subnet as an isolated pool for our resources
Internet Gateway to contact the outside world
Security groups for RDS MySQL and for EC2s
Auto-scaling group for ECS cluster with launch configuration
RDS MySQL instance
ECR container registry
ECS cluster with task and service definition
The Terraform Part
To start with Terraform we need to install it. Just go along with the steps in this document: https://www.terraform.io/downloads.html
Verify the installation by typing:
$ terraform --version
Terraform v0.13.4
With Terraform (in this case version 0.13.4) we can provision cloud architecture by writing code which is usually created in a programming language. In this case it’s going to be HCL — a HashiCorp configuration language.
Terraform state
Before writing the first line of our code lets focus on understanding what is the Terraform state.
The state is a kind of a snapshot of the architecture. Terraform needs to know what was provisioned, what are the resources that were created, track the changes, etc.
All that information is written either to a local file terraform.state or to a remote location. Generally the code is shared between members of a team, therefore keeping local state file is never a good idea. We want to keep the state in a remote destination. When working with AWS, this destination is s3.
This is the first thing that we need to code — tell terraform that the state location will be remote and kept is s3 (terraform.tf):
terraform {
    backend "s3" {
        bucket = "terraformeksproject"
        key    = "state.tfstate"
    }
}
Terraform will keep the state in an s3 bucket under a state.tfstate key. In order that to happen we need to set up three environment variables:
$ export AWS_SECRET_ACCESS_KEY=...
$ export AWS_ACCESS_KEY_ID=..
$ export AWS_DEFAULT_REGION=...
These credentials can be found/created in AWS IAM Management Console in “My security credentials” section.Both access keys and regionmustbe stored in environment variables if we want to keep the remote state.
VPC
provider "aws" {}

resource "aws_vpc" "vpc" {
    cidr_block = "10.0.0.0/24"
    enable_dns_support   = true
    enable_dns_hostnames = true
    tags       = {
        Name = "Terraform VPC"
    }
}
Terraform needs to know with which API should interact. Here we say it’ll be AWS. List of available providers can be found here: https://www.terraform.io/docs/providers/index.html
The provider section has no parameters because we’ve already provided the credentials needed to communicate with AWS API as environment variables in order have remote Terraform state (there is possibility to set it up withprovider parameters, though).
The resource block type aws_vpc with name vpc creates Virtual Private Cloud — a logically isolated virtual network. When creating VPC we must provide a range of IPv4 addresses. It’s the primary CIDR block for the VPC and this is the only required parameter.
Parameters enable_dns_support and enable_dns_hostnames arerequired if we want to provision database in our VPC that will be publicly accessible (and we do).
Internet gateway
In order to allow communication between instances in our VPC and the internet we need to create Internet gateway.
resource "aws_internet_gateway" "internet_gateway" {
    vpc_id = aws_vpc.vpc.id
}
The only required parameter is a previously created VPC id that can be obtain by invoking aws_vpc.vpc.id this is a terraform way to get to the resource details: resource.resource_name.resource_parameter.
Subnet
Within the VPC let’s add a public subnet:
resource "aws_subnet" "pub_subnet" {
    vpc_id                  = aws_vpc.vpc.id
    cidr_block              = "10.1.0.0/22"
}
To create a subnet we need to provide VPC id and CIDR block. Additionally we can specify availability zone, but it’s not required.
Route Table
Route table allows to set up rules that determine where network traffic from our subnets is directed. Let’s create new, custom one, just to show how it can be used and associated with subnets.
resource "aws_route_table" "public" {
    vpc_id = aws_vpc.vpc.id

    route {
        cidr_block = "0.0.0.0/0"
        gateway_id = aws_internet_gateway.internet_gateway.id
    }
}

resource "aws_route_table_association" "route_table_association" {
    subnet_id      = aws_subnet.pub_subnet.id
    route_table_id = aws_route_table.public.id
}
What we did is created a route table for our VPC that directs all the traffic (0.0.0.0/0) to the internet gateway and associate this route table with both subnets. Each subnet in VPC have to be associated with a route table.
Security Groups
Security groups works like a firewalls for the instances (where ACL works like a global firewall for the VPC). Because we allow all the traffic from the internet to and from the VPC we might set some rules to secure the instances themselves.
We will have two instances in our VPC — cluster of EC2s and RDS MySQL, therefore we need to create two security groups.
resource "aws_security_group" "ecs_sg" {
    vpc_id      = aws_vpc.vpc.id

    ingress {
        from_port       = 22
        to_port         = 22
        protocol        = "tcp"
        cidr_blocks     = ["0.0.0.0/0"]
    }

    ingress {
        from_port       = 443
        to_port         = 443
        protocol        = "tcp"
        cidr_blocks     = ["0.0.0.0/0"]
    }

    egress {
        from_port       = 0
        to_port         = 65535
        protocol        = "tcp"
        cidr_blocks     = ["0.0.0.0/0"]
    }
}

resource "aws_security_group" "rds_sg" {
    vpc_id      = aws_vpc.vpc.id

    ingress {
        protocol        = "tcp"
        from_port       = 3306
        to_port         = 3306
        cidr_blocks     = ["0.0.0.0/0"]
        security_groups = [aws_security_group.ecs_sg.id]
    }

    egress {
        from_port       = 0
        to_port         = 65535
        protocol        = "tcp"
        cidr_blocks     = ["0.0.0.0/0"]
    }
}
First security group is for the EC2 that will live in ECS cluster. Inbound traffic is narrowed to two ports: 22 for SSH and 443 for HTTPS needed to download the docker image from ECR.
Second security group is for the RDS that opens just one port, the default port for MySQL — 3306. Inbound traffic is also allowed from ECS security group, which means that the application that will live on EC2 in the cluster will have permission to use MySQL.
Inbound traffic is allowed for any traffic from the Internet (CIDR block 0.0.0.0/0). In real life case there should be limitations, for example, to IP ranges for a specific VPN.
This ends setting up the networking park of our architecture. Now it’s time for autoscaling group for a EC2 instances in ECS cluster.
Autoscaling Group
Autoscaling group is a collection of EC2 instances. The number of those instances is determined by scaling policies. We will create autoscaling group using a launch template.
Before we will launch container instancesandregister them into a cluster, we have to create an IAM role for those instances to use when they are launched:
data "aws_iam_policy_document" "ecs_agent" {
  statement {
    actions = ["sts:AssumeRole"]

    principals {
      type        = "Service"
      identifiers = ["ec2.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "ecs_agent" {
  name               = "ecs-agent"
  assume_role_policy = data.aws_iam_policy_document.ecs_agent.json
}


resource "aws_iam_role_policy_attachment" "ecs_agent" {
  role       = "aws_iam_role.ecs_agent.name"
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role"
}

resource "aws_iam_instance_profile" "ecs_agent" {
  name = "ecs-agent"
  role = aws_iam_role.ecs_agent.name
}
Having IAM role we can create an autoscaling group from template:
resource "aws_launch_configuration" "ecs_launch_config" {
    image_id             = "ami-094d4d00fd7462815"
    iam_instance_profile = aws_iam_instance_profile.ecs_agent.name
    security_groups      = [aws_security_group.ecs_sg.id]
    user_data            = "#!/bin/bash\necho ECS_CLUSTER=my-cluster >> /etc/ecs/ecs.config"
    instance_type        = "t2.micro"
}

resource "aws_autoscaling_group" "failure_analysis_ecs_asg" {
    name                      = "asg"
    vpc_zone_identifier       = [aws_subnet.pub_subnet.id]
    launch_configuration      = aws_launch_configuration.ecs_launch_config.name

    desired_capacity          = 2
    min_size                  = 1
    max_size                  = 10
    health_check_grace_period = 300
    health_check_type         = "EC2"
}
If we want to use a created, named ECS cluster we have to put that information into user_data, otherwise our instances will be launched in default cluster.
Basic scaling information is described by aws_autoscaling_group parameters. Autoscaling policy has to be provided, we will do it later.
Having autoscaling group set up we are ready to launch our instances and database.
Database Instance
Having prepared subnet and security group for RDS we need one more thing to cover before launching the database instance. To provision a database we need to follow some rules:
Our VPC has to have enabled DNS hostnames and DNS resolution (we did that while creating VPC).
Our VPC has to have a DB subnet group (that is about to happen).
Our VPC has to have a security group that allows access to the DB instance.
Let’s create the missing piece:
resource "aws_db_subnet_group" "db_subnet_group" {
    subnet_ids  = [aws_subnet.pub_subnet.id]
}
And database instance itself:
resource "aws_db_instance" "mysql" {
    identifier                = "mysql"
    allocated_storage         = 5
    backup_retention_period   = 2
    backup_window             = "01:00-01:30"
    maintenance_window        = "sun:03:00-sun:03:30"
    multi_az                  = true
    engine                    = "mysql"
    engine_version            = "5.7"
    instance_class            = "db.t2.micro"
    name                      = "worker_db"
    username                  = "worker"
    password                  = "worker"
    port                      = "3306"
    db_subnet_group_name      = aws_db_subnet_group.db_subnet_group.id
    vpc_security_group_ids    = [aws_security_group.rds_sg.id, aws_security_group.ecs_sg.id]
    skip_final_snapshot       = true
    final_snapshot_identifier = "worker-final"
    publicly_accessible       = true
}
All the parameters are more less self explanatory. If we want our database to be publicly accessible you have to set the publicly_accessible parameter as true.
Elastic Container Service
ECS is a scalable container orchestration service that allows to run and scale dockerized applications on AWS.
To launch such an application we need to download image from some repository. For that we will use ECR. We can push images there and use them while launching EC2 instances within our cluster:
resource "aws_ecr_repository" "worker" {
    name  = "worker"
}
And the ECS itself:
resource "aws_ecs_cluster" "ecs_cluster" {
    name  = "my-cluster"
}
Cluster name is important here, as we used it previously while defining launch configuration. This is where newly created EC2 instances will live.
To launch a dockerized application we need to create a task — a set of simple instructions understood by ECS cluster. The task is a JSON definition that can be kept in a separate file:
[
  {
    "essential": true,
    "memory": 512,
    "name": "worker",
    "cpu": 2,
    "image": "${REPOSITORY_URL}:latest",
    "environment": []
  }
]
In a JSON file we define what image will be used using template variable provided in a template_file data resource as repository_url tagged with latest. 512 MB of RAM and 2 CPU units that is enough to run the application on EC2.
Having this prepared we can create terraform resource for the task definition:
resource "aws_ecs_task_definition" "task_definition" {
  family                = "worker"
  container_definitions = data.template_file.task_definition_template.rendered
}
The family parameter is required and it represents the unique name of our task definition.
The last thing that will bind the cluster with the task is a ECS service. The service will guarantee that we always have some number of tasks running all the time:
resource "aws_ecs_service" "worker" {
  name            = "worker"
  cluster         = aws_ecs_cluster.ecs_cluster.id
  task_definition = aws_ecs_task_definition.task_definition.arn
  desired_count   = 2
}
This ends the terraform description of an architecture.
There’s just one more thing left to code. We need to output the provisioned components in order to use them in worker application.
We need to know URLs for:
ECR repository
MySQL host
Terraform provides output block for that. We can print to the console any parameter of any provisioned component.
output "mysql_endpoint" {
    value = aws_db_instance.mysql.endpoint
}

output "ecr_repository_worker_endpoint" {
    value = aws_ecr_repository.worker.repository_url
}
Applying the changes
First we need to initialize a working directory that contains Terraform files by typing terraform init. This command will install needed plugins and provide a code validation.
Follow up with terraform plan.
Finding that you’re receiving an error?
You need to manually create theS3bucket through the aws console, making sure to edit terraform.tf with the correct bucket name.
If everything is fine we can run terraform apply to finally provision the desired infastructure.