DEV Community: Wilson Anorue

4 Mistakes to Avoid When Setting Up a CI/CD Pipeline

Wilson Anorue — Thu, 15 Aug 2024 12:35:17 +0000

Continuous Integration and Continuous Deployment (CI/CD) pipelines automate the process of building, testing, and deploying code to remote servers, streamlining software delivery. Having built CI/CD pipelines for many applications in real business environments, I’ve made mistakes and seen colleagues make them too — each providing valuable lessons.

These experiences build up the expertise of any DevOps engineer, so I wanted to share what I’ve learned.

Making these mistakes can ruin your projects, disrupt your application environment, or cause your projects to drag on far longer than it should.

Based on my experience, here’s what you should do — or watch out for — when setting up your CI/CD pipeline. These tips are vendor-agnostic, meaning they apply whether you’re using GitHub Actions, Jenkins, TravisCI, AmplifyCI, CircleCI, or others.

Let’s explore these common mistakes and how to avoid them.

It’s common knowledge to use environment variables or secrets in your pipeline to avoid manually typing in passwords, SSH keys, connection strings, and other sensitive details. Since this is widely understood, I won’t dwell on it here.

Take a Snapshot of Your Server Before You Begin

If you’re planning to make changes to your server environment — such as adding or deleting files — especially if you’re new to this, it’s crucial to take a snapshot of your server before setting up your CI/CD pipeline. Snapshots are quick and straightforward to create, and they provide an easy way to restore your server to its previous state if something goes wrong.

I once witnessed a colleague accidentally delete our server environment and critical system files while configuring a CI/CD pipeline to sync code changes. This could have been easily avoided with a simple snapshot.

Set Up Your SSH Key Properly

To connect to your remote server where you’ll deploy your application, you’ll need both a private key and a public key. You can either create a new key pair specifically for your pipeline or use the existing public key you already use to access your instance. Either option works, but you’ll need to copy the contents of your private key file and paste them into GitHub Secrets.

Here are two important things to keep in mind:

Avoid Opening Your Key File as a Text File
When copying your private key, it’s better to display its contents in your terminal and copy it from there, especially if you’re using a Windows system. Opening the file directly as a text file can lead to formatting issues. Use the following commands to display the private key file content: cat key.pem for Linux or type key.pem for Windows.
Copy the Entire Key Content, Including Headers
Ensure you copy the entire content of the key file, including the headers and footers like; — –BEGIN RSA PRIVATE KEY — — and — –END RSA PRIVATE KEY — –. Paste the complete content into your GitHub Secrets box without any spaces.

Additionally, it’s better to append the key content to a file using commands like echo or cat rather than copying and pasting it manually into a text editor. For example, if you need to add a new SSH public key to your ~/.ssh/authorized_keys file, using the command line approach is more reliable and less error-prone. Here’s how to do it:

echo "ssh-rsa ***your key content***" >> ~/.ssh/authorized_keys

or using cat:

cat ~/.ssh/rsa_key.pub >> ~/.ssh/authorized_keys

This method reduces the risk of errors compared to manual editing.

Carefully Review Your Deployment Path

It’s crucial to thoroughly review and understand the deployment path where your code or files will be affected, especially when deleting or syncing files on your server. If you’re resyncing files to your server, create a dedicated folder where your code files will be resynced, and always double-check the path before testing the pipeline.

I once worked on a project where a colleague mistakenly resynced files directly to the root directory (/home/bitnami/). This error resulted in the code being deployed in the root environment and inadvertently deleting other essential folders, including our /.ssh/ directory, environment paths, and other critical files.

This led to significant work to regain SSH access to the server and recreate the SSH public and private keys. Since we had done extensive configurations on the server, starting from scratch would have been far more stressful and time-consuming.

- name: Upload new files 
        run: |
          rsync -avz --no-times --delete-after --exclude '.git' ./ bitnami@${{ secrets.YOUR_SERVER_IP }}:/home/bitnami

As example, the code above will delete all files in the root directory (/home/bitnami) including your SSH key which is usually located in that directory.

To avoid such scenarios, always keep a snapshot of your server as a backup.

Here are the high-level steps to recreate SSH keys for your server if you find yourself in a similar situation:

Prerequisite: Ensure you can connect to the server via SSH through an alternative method, such as browser-based sessions.

Generate an SSH RSA Key Pair:
Use your terminal to generate a new SSH RSA key pair.

Add the Public Key Content to Your Server:
Append the public key file content (.pub) to your ~/.ssh/authorized_keys file. It’s recommended to use the echo or cat commands, as discussed earlier:

echo "ssh-rsa ***your key content***" >> ~/.ssh/authorized_keys

cat ~/.ssh/rsa_key.pub >> ~/.ssh/authorized_keys

Add the Private Key to Your Local Machine or Pipeline Secrets:
Store the private key content on your local machine or copy it to the secrets environment of your pipeline.

Test the New Key:
Attempt to connect to your server using the new SSH key. It should work now.
By following these steps and being meticulous about your deployment paths, you can avoid costly mistakes and ensure smoother operations.

Use Server Configuration Management Tools for Your Environment

In one of the challenging experiences I mentioned earlier, we could have saved ourselves a lot of stress if we had set up our environment using configuration management tools like Ansible, Chef, or Puppet.

These tools would have allowed us to easily replicate the same configuration on another server when we lost SSH access to the previous one.

Instead of struggling to regain access, we could have simply spun up a new server and run the configuration playbook or cookbook to restore our setup.

Although DevOps engineers typically don’t create configuration scripts for a single server, it’s still a best practice to do so. It’s not only important but also incredibly useful for recreating your server configuration in various scenarios.

Build Fast, Fail Fast, and Enable Detailed Monitoring

Building your code quickly, testing it promptly, and making necessary changes is essential. This approach enables you to deploy more often, reducing context switching, which is a best practice in DevOps. Regular deployments ensure that code is tested in staging and production as soon as possible.

Detailed monitoring of your builds and deployments allows you to quickly spot issues and address them directly, minimizing guesswork. Trust me, this will save you a significant amount of time.

Some Additional Useful Tips

Build Once: Ensure you build your code once, run your tests, and deploy the same artifact to staging and production if successful. Avoid building the code separately for each stage, as this might introduce inconsistencies. You can store your artifacts or outputs in repositories like Docker, ECR, or S3. Also, make sure to version your code appropriately, ensuring that the code you deploy is the same as what you built and tested, so it will perform consistently.

Code, Build, and Deploy Frequently: Frequent coding, building, and deployment are at the heart of DevOps. This approach ensures that mistakes and errors are spotted and corrected quickly, and it provides immediate feedback from both testing teams and customers.
These are the tips I have for you. I have personally experienced how these practices can save you time, improve your DevOps experience, prevent unnecessary mistakes, and help you quickly remediate any errors that do occur.

Conclusion

By implementing these best practices, you’ll streamline your DevOps workflow, minimize costly errors, and enhance your deployment efficiency. Embrace these tips to improve your DevOps experience, ensuring faster, more reliable, and consistent software delivery.

Please share any additional tips you might have, or let me know if I missed something important!

I write articles and helper notes for Cloud, DevOps engineer and SYS Administrator, please check out my blog to see more of it. https://digitalspeed.com.ng

Creating a CICD Pipeline using Jenkins on AWS EC2, Monitoring using Prometheus, and Grafana

Wilson Anorue — Sun, 04 Aug 2024 11:12:04 +0000

In this post we will deploy a simple containerized web application through Jenkins to an EC2 server, we deploy Prometheus and Grafana as containers to monitor the web application for security, operational state, and others. Note that the web app runs on two containers MySQL and Node application.

When you complete this project you should see that your EC2 instance is now running multiple containers (5 containers) which are for; Node application, MySQL, Grafana, Node Exporter, and Prometheus. All containers have been easily connected through the network we defined in our docker-compose file.

I want to state if you are building this as a project with the intention to learn from it then I suggest that you build the project first as I explained then when everything is working as required you can change something about the project or try out something in a different way than how I have done it.

I built the architecture myself for this project, I wasn't following any particular tutorial, I built it incrementally i.e first building with a few containers and then adding other containers along the way, so I had lots of learning while building that's why I suggest you modify a lot about the project so you can learn a lot too.

Prerequisite

You need familiarity with AWS as I won't be going into the details when implementing on AWS. For any EC2 instance please select the free tier eligible T2micro type so you don't get charged. Check out this post to learn more about Amazon EC2

We will use Jenkins as our CICD pipeline to automate the deployment of our containerized application to our EC2 instance.

Why Jenkins

Jenkins is an open-source automation server that helps automate software development processes such as building, testing, and deploying code changes to production. It is widely used in the DevOps industry to achieve continuous integration and continuous delivery (CI/CD) of software applications and one of the most important attributes is that it runs on our infrastructure.

Jenkins provides a user-friendly web-based interface, which allows developers to create automated jobs or tasks called pipelines. A pipeline in Jenkins is a set of instructions that define the stages of the software delivery process. It is a powerful tool that helps to streamline the software development process, improve productivity, and reduce errors.

A Jenkins pipeline is a combination of plugins that supports the integration and implementation of continuous delivery pipelines using Jenkins. It provides a way to define the entire software delivery process as code, which can be easily reviewed, versioned, and shared across the team.

A pipeline can be thought of as a sequence of stages that represent the steps in the software delivery process such as build, test, and deploy. The pipeline is written in a domain-specific language called Groovy, which makes it easy to define complex software delivery workflows. With the Jenkins pipeline, teams can automate the entire software delivery process, making it more efficient, reliable, and scalable.

The workflow in this case is simple, Jenkins gets triggered by GitHub webhook whenever there's an accepted change in the codebase, Jenkins pulls the repository and builds it, it carries out any necessary tests and deploys the code to our EC2 instance through the public key-pair file we attached.

We would start with our GitHub repository, Clone the repository to your local computer

git clone https://github.com/willie191998/to-do-app-with-docker-jerkins-prometheus.git

Initialize the repository git init

Check the current branch git branch

Make small changes and commit changes

git commit -m <change details>

Connect your local repository to its remote GitHub repository, use the command git remote add origin
Push your files or changes to your GitHub repository, run the command git push origin master

Ensure you use the correct branch should be likely master or main.

You should now see the files in your GitHub repository.

Installation and Set Up of Jenkins

Create an EC2 instance, I used an Amazon Linux 2 OS but you can use Ubuntu or any other. Ensure you allow HTTP and SSH traffic for the EC2 instance also allow a custom port (port 8080) so we can access the Jenkins interface running on our server. Please check out the previous post to learn how to connect up an EC2 instance.

Install Java on our EC2 instance, connect your EC2 instance through SSH, see how to connect to your EC2 instance through SSH, and run the following command through SSH to install Java on your EC2 instance.

sudo dnf install -y java-11-amazon-corretto
sudo wget -O /etc/yum.repos.d/jenkins.repo  https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key

The GPG key ensures that the packages you're downloading are from the Jenkins repository and haven't been tampered with.

sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key

Install Jenkins

Now that the GPG key is imported, you can proceed with the Jenkins installation.

sudo dnf install -y Jenkins

Start and Enable Jenkins

Once Jenkins is installed, you can start the service and enable it to start on boot.

sudo systemctl start jenkins
sudo systemctl enable Jenkins

Check Jenkins Status

Verify that Jenkins is running correctly.

sudo systemctl status jenkins

Install docker and docker-compose

sudo yum update -y
sudo amazon-linux-extras install docker
sudo service docker start
sudo usermod -a -G docker ec2-user
sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

Configure Jenkins

Open Jenkins Web Interface
Visit http://your-ec2-public-ip:8080 in your web browser.

Retrieve the Initial Admin Password form SSH CLI

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Complete the Jenkins Setup Wizard;

Enter the admin password when prompted.
Install suggested plugins.

Create the first admin user and complete the setup.

Install Plugins

Jenkins plugins extend functionality, enabling seamless integration with tools, enhancing CI/CD pipelines, and automating tasks. Over 1,700 plugins support various stages of the development lifecycle.

These are the plugins you will need for this project; Git plugin, GitHub, Git Pipeline, Build Timeout, and Docker Pipeline.

Set up environmental variables for Jenkins

Go through this route in your Jenkins dashboard; Jenkins >> Manage Jenkins >> Manage Credentials >> Global >> New Credentials

Create new credentials, select username and password for the credentials type, and put in your GitHub username and password, this will be used for the GitHub access

Create another credential Select the public key, and put your AWS keypair file public key (You can get your public key from your ec2 instance key pair by printing the content of the keypair using the cat command).

You should copy the whole content as printed and paste it on the selected credentials public key field. Remember that you would use this same key pair when creating the other EC2 instance.
Create another credential, this time it is the username and password for your Docker Hub account, put in your correct Docker Hub details.

Also don't forget to use a good ID for your credentials appropriately as it is what you will use to access it on your Jenkins pipeline.

You can also set environmental variables which can hold in details like your Docker Hub username but we won't do that now.
Set up Jenkins Pipeline

Select - Manage Jenkins >> Select Create Pipeline >>
Under GitHub project select it and add the link of your GitHub repository without the .git

Under Definition select Pipeline script from SCM, under SCM select Git, put your GitHub repository link (the HTTPS form ending with .git) into the git repository field, and select the credentials you created earlier that have your GitHub username and password.

Select the Jenkins file (script) to be executed on your pipeline as Jenkinsfile which is what we have on our repo.

Ensure you Select the GitHub hook trigger for GITSCM polling.
Apply the details and Save the pipeline.

Connect GitHub to Jenkins

Log in to your GitHub and locate your repository, select settings from the list of options for that repository, and select Add Webhook.

Select Add payload and add the following URL http:///github-webhook/

Set the Content type to application/json
Choose Just the push event
Click Add webhook

Remember to change the URL to use your Jenkins EC2 instance IP
Create your Hosting EC2 instance Create a new EC2 instance as you have done before but with some minor changes but ensure you use the same keypair as before;

Expose the following custom port for your instance SG group 1000–9090 TCP traffic

Expose the SSH 443, and HTTP port 80 as before.

Go to advance settings while creating the instance add the following script under user-data script to set a docker/docker-compose environment on your new EC2 instance

#!/bin/bash
# Update package information
sudo yum update -y
# Install Docker
sudo yum install -y docker
# Start Docker service
sudo systemctl start docker
sudo systemctl enable docker
# Add ec2-user to the docker group to run docker without Sudo
sudo usermod -a -G docker ec2-user
# Install Python 3 and pip
sudo yum install -y python3 python3-pip
# Install Docker Compose using pip
sudo pip3 install docker-compose

No worries if you can't do this when you create your ec2 instance you can connect to it through SSH and run each of these commands individually and still get the same result.

You can connect to your instance through SSH and confirm your environment has been configured i.e. docker and docker-compose are installed.

docker --version
docker-compose --version

Modify your Jenkinsfile

Open your Jenkinsfile from your local repository and modify the following content to your own details
The credentials ID for Github, Docker Hub, and public key for EC2 instance.
Modify the following parameters values; DOCKER_USERNAME, AWS_REGION, EC2_USER, EC2_IP, DOCKER_IMAGE_NAME, DOCKER_REPO.

Ensure you use the appropriate values for the following variables.

Make changes on your local repo and push the changes to GitHub following these commands

git add .
git commit -m <changes details>
git push origin master

You should see your code build, it will run tests (if you defined any), it will push the image to your Docker Hub, and deploy the containers to your other EC2 instance, it automatically starts the process by stopping any running containers and deleting the current image before starting the new one so your instance runs your latest software.

You can SSH to your EC2 instance and confirm the container is running through the command docker ps you should see all the containers (5 in total) running on your EC2 instance.

If any one container is not there then you can check the logs to know why the container is not running *docker logs
*
Recall I mentioned that I built the containers incrementally, first with two containers; web app and MySQL then Prometheus and node exporter then Grafana but currently you have all the containers running on your instance, you can simply modify the docker-compose file if you want to start with any of those.

Access your containers running on your EC2 instance through the instance IP and the port the container is running on.

Web App - :3000
Prometheus - :9090
Grafana - :4000

Note that Node Exporter and MySQL do not have a web interface so you can't access them directly on your browser.

Connecting Prometheus as a Data Source to Grafana

Access your Prometheus interface on one window and your Grafana interface on another window

On Grafana, use the default username and password both are admin to log in then you will be asked to create a new password.

When you finally log in, you can explore the interface before connecting Prometheus as a data source.

Add Prometheus Data Source

Click on the gear icon (Configuration) in the left sidebar. Select Data Sources from the dropdown menu
Click on the Add data source button

Configure the Prometheus Data Source

From the list of available data sources, select Prometheus.
In the URL field, enter the address of your Prometheus server. If Prometheus is running on the same host as Grafana, http://prometheus:9090 as you are using docker containers else you can use :9090 if running directly on the VM.
Scroll down and click on the Save & Test button to ensure Grafana can connect to Prometheus

After clicking Save & Test you should see a message indicating that the data source was successfully added and is working.

Create and save a Dashboard in Grafana

Click on the + icon in the left sidebar and select Dashboard, Click on Add new panel.
In the Query section, select the Prometheus data source you just added.
Enter a Prometheus query to fetch the metrics you want to visualize.

For example, node_cpu_seconds_total to visualize CPU usage and node_memory_Active_bytes to visualize memory usage. Customize the panel settings, including visualization type (e.g. graph, gauge, table).
Click on the Save button (disk icon) in the top right corner.
Provide a name for your dashboard and save it.

Conclusion

While replicating this project, it is expected that you make a few mistakes especially if you are using this service for the first time so here are some useful commands you can use for docker containers;

docker pull: Downloads an image from a registry.
docker build: Builds an image from a Dockerfile.
docker run: Runs a container from an image.
docker push: Uploads an image to a registry.
docker ps: Lists running containers.
docker stop: Stops a running container.
docker rm: Removes a stopped container.
docker rmi: Removes an image from the local repository.
docker logs: Fetches logs of a container.
docker exec: Runs a command in a running container.
docker-compose up: Starts and runs containers defined in a docker-compose.yml file.
docker-compose down: Stops and removes containers, networks, and volumes defined in a docker-compose.yml file.
docker-compose build: Builds or rebuilds services defined in a docker-compose.yml file.
docker-compose logs: Displays logs from services defined in a docker-compose.yml file.

I supposed you have some basic Linux skills to change directory, create directory, delete files, check and change file permission and ownership, etc. Because you will need those.

GitHub Repo

https://github.com/willie191998/to-do-app-with-docker-jerkins-prometheus.git

How to deploy a containerized app on AWS EKS clusters with Ingress-NGINX enabled

Wilson Anorue — Wed, 15 May 2024 07:42:39 +0000

Prerequisite

You have an AWS account with billing enabled.

You have installed the AWS CLI on your local computer, except if you use the AWS cloud shell from your management console. Install and update AWS CLI

We have an existing containerized application setup in the GitHub link below. This app is intended to run 2 client servers, 2 backend servers, 1 worker server where calculations for the application will be made, 1 Redis server, and 1 Postgres server.

Don't worry, you won't be building the application from scratch; the application files and modules have been created, and the application image has been deployed to Docker Hub. The files available in the GitHub repo are just the cluster configuration files for Kubernetes.

We will be working with AWS CLI, although you can use the cloudshell to do the configuration just as illustrated in this article.

Let's get started

Clone the repo to your local computer or the console environment if you're using the console command line.

git clone https://github.com/willie191998/Kubernetes-cluster-ingress-nginx/

Set up roles and user

You need to set up a role for your node group, a role for your EKS cluster, and a role for your local command-line user access. If you are using Cloudshell, you need to ensure your user has the minimum permissions to carry out this activity.

Setup Local Command Line user

I assume you already have a command line user for using AWS CLI. However, depending on the permissions you've granted this user, you might want to review them to ensure they have the necessary access to create, modify, and interact with the resources used in this tutorial.

Personally, I couldn't figure out the exact permissions to add to my user, so I temporarily gave them administrative access and removed it once I was done. Giving administrative permissions to a command line user is risky, so be sure to limit these permissions whenever possible.

Setup EKS role

Navigate to your IAM dashboard from the search box

Select Roles from the IAM dashboard, and click Create Role.
Choose AWS Service as the trusted entity type, select Elastic Kubernetes Service (EKS) from the list of services, and click Next.
In the Attach permissions policies section, search for and select the appropriate policies for your EKS cluster, AmazonEKSClusterPolicy, AmazonEKSServicePolicy, and Click Next.

Review and click Create role.

Setup EC2 Nodegroup role

Navigate to your IAM dashboard from the search box
Select Roles from the IAM dashboard, and click Create Role.
Choose AWS Service as the trusted entity type, select Elastic Compute Cloud (EC2) from the list of services, and click Next.
In the Attach permissions policies section, search for and select the appropriate policies for your EKS cluster, AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy, AmazonEC2ContainerRegistryReadOnly, Click Next.
Review and click Create role.

Set up infrastructure and platform

After installing the AWS CLI, configure it by running aws configure. Enter your user access key ID and secret access key. You'll be prompted to set a default region; use the short representation for the region, such as eu-west-3 for Paris.

Create the EKS cluster from your command line; otherwise, you won't be able to deploy files to it using your command line user. Changing the user later is possible but stressful and tedious. Here’s a forum discussion of the issue: https://repost.aws/knowledge-center/eks-api-server-unauthorized-error

aws eks create-cluster --name --role-arn role-arn --resources-vpc-config "subnetIds=subnet1,subnet2,securityGroupIds=sg-1"

Replace cluster-name, role-arn, subnet1, subnet2, sg-1 with appropriate values.

Confirm that your cluster has been provisioned and active before you continue.

Set Kubectl to be based on your cluster when you use it.

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

Confirm the config context for kubectl rightnow, run,

kubectl config get-contexts

The context should be the arn of your EKS cluster.

Set up a namespace file, you can name it anything you want, and save it as a file.

apiVersion: v1 
kind: Namespace 
metadata:
  name: my-namespace

Change the name in the file appropriately, Apply namespace.

kubectl apply -f my-namespace.yaml

I didn't use a namespace because I was only working on one cluster, so all my instances and deployments were stored in the default namespace. However, I urge you to use namespaces to prevent future errors.

Create your node group if it hasn't been created yet. To check if a node group already exists, open your EKS cluster, select Compute from the options at the bottom, then select Nodegroup. If there's none, click Create.

Give your node group a name, select the role you created for the EC2 node group, and select the instance type for it, T2.micro if you want to benefit from the free tier, set the maximum, required, the minimum number of nodes, mine was 4, 14, 15 respectively. Now you can create your node group and confirm that it’s active.

Deploy your cluster configuration files. These files contain definitions for deployments and services in the cluster. As long as you haven't added any new files to the folder, you can run the command below to create the deployments and services as defined on one run.

Kubectl apply –f ./k8s

Else you create all services and deployment individually, like this

Kubectl apply –f client-cluster-ip-service.yaml

Kubectl apply –f client-deployment.yaml

Do the same for Redis, postgres, worker, and server files.

Confirm your deployments, services are running with the command below.

kubectl get all –n <namespace>

You would see all the deployed pods, deployments, services, etc. Note that you should replace the namespace in the command above with your actual namespace.

Confirm that the pods are ready and not just created as shown in the image below else run the command to recreate the deployment or service.

Now your cluster is running but you cannot access them via an IP address or DNS link because they were not configured to receive traffic from external sources directly.

To receive traffic you need to enable Ingress-NGINX, an open source project developed by the Kubernetes community.

Ingress-NGINX controller will create an external load balancer outside your cluster, a NGINX server which we will configure very soon to send traffic to our deployments.

Configure the Ingress-NGINX controller, download the file from the terminal

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.10.1/deploy/static/provider/aws/nlb-with-tls-termination/deploy.yaml

I used Windows so this command did not work from the command prompt so I used WSL terminal to download the content into this folder k8s.

Various ways of configuring Ingress-NGINX depend on your local OS, cloud provider (AWS, Azure, GCP), local testing, etc. See the main documentation page here (https://kubernetes.github.io/ingress-nginx/deploy/)

After downloading the file, we need to configure it as stated in the documentation for AWS. Open the file downloaded, deploy.yaml, and get ready to edit.

Locate proxy-real-ip-cidr at about line 329 for me, should be around that line for you. You are required to change that value there to the CIDR block of your VPC.

Locate service.beta.kubernetes.io/aws-load-balancer-ssl-cert at around line 348. Remove the dummy value there arn❌x:... to the arn of an AWS verified domain certificate. The certificate I use is associated with another server/website entirely, but it worked fine provided it was verified.

Save your changes and create the ingress-nginx controller

Kubectl apply –f deploy.yaml

You should see that different pods and services are created successfully.

Confirm Ingress-NGINX is running

kubectl get all -n ingress-nginx

You should see details of a newly deployed load balancer which you can confirm when you go to your EC2 dashboard then, select load balancer at the bottom left, you should see one created by your Ingress-NGINX.

Wait for your load balancer to become active then copy its DNS address and enter it on a browser tab, if everything has worked correctly you will see a default NGINX 404 page.

Open the LB link.

The default NGINX page you see is a default end page created by ingress-nginx to serve as the endpoint when you have yet to configure the NGINX server.

To configure the ingress-nginx controller, you need an ingress file which is given below. It was made to enable NGINX networking for our project.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-service
  namespace: default
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/use-regex: 'true'
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    # Ensure LoadBalancer creation
    nginx.ingress.kubernetes.io/service-type: "LoadBalancer"
spec:
  ingressClassName: nginx
  rules:
    - HTTP:
        paths:
          - path: /?(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: client-cluster-ip-service
                port:
                  number: 3000
          - path: /api/?(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: server-cluster-ip-service
                port:
                  number: 5000

Copy and paste the content above on a new file, name it ingress-service.yaml, and apply it to our cluster.

kubectl apply –f ingress-service.yaml

To refresh the load balancer DNS link and should now have access to our web app running on the EKS cluster served via Ingress-NGINX.

You can test things around the website but remember that you might be billed for EKS and load balancer.

Delete your resources in this order

Nodegroup

load balancer

EKS cluster

iam roles and maybe the user

You don’t get charged for Iam and user access so you might not need to delete it.

Let us hear from you if you did this.

Conclusion

You have deployed a containerized app to an EKS cluster and configured it to use EC2 instances in a node group. You also set up an Ingress-NGINX to forward external traffic to the cluster through a load balancer. This is quite a standard setup for a Kubernetes cluster right now.

Share your comment below.
See the article from my blog DigitalSpeed

How to create a publicly available bucket on AWS using Terraform

Wilson Anorue — Tue, 14 May 2024 09:46:20 +0000

It's really common to create publicly accessible S3 bucket from the the management console, this time we want to create an S3 bucket, upload an object to it, and make it publicly accessible using Terraform.

Prerequisites

You have an AWS account.
You have AWS CLI installed on your computer, test by typing aws on your command line and see a reply telling you how to structure a command else follow this link to install AWS CLI Install or update to the latest version of the AWS CLI – AWS Command Line Interface (amazon.com)

What is Terraform

Terraform is a service that lets you define infrastructure using code, offering a structured way to represent your desired states while benefiting from features like versioning, collaboration, and automation.

This code-centric approach makes infrastructure changes more reliable and easier to track.

Moreover, Terraform integrates seamlessly with AWS, providing comprehensive support for provisioning and managing a wide array of AWS resources.

Why use Terraform

Infrastructure as Code (IaC)

Terraform allows you to define infrastructure configurations using code, providing a consistent, automated approach to managing resources. This makes it easier to apply best practices, track changes, and collaborate with others, reducing the risk of manual errors.

Easy Deployment of Infrastructure

Terraform streamlines infrastructure deployment through a simple command-line interface. By defining your desired state in code, you can deploy new environments or make changes to existing ones with a few commands, making it efficient and straightforward.

Recreate Infrastructure Consistently

Terraform’s code-based approach enables you to create identical infrastructure multiple times. This is useful for spinning up identical test, staging, or production environments, ensuring consistency across deployments.

Error-Free Deployment Once Configured
Once you’ve properly defined your Terraform configuration, deploying infrastructure becomes more predictable and less prone to errors. Terraform’s declarative nature ensures that the desired state is achieved without unexpected behavior, making deployments reliable.
Resource Dependencies and Orchestration

Terraform manages dependencies between infrastructure resources, ensuring that they are created, modified, or destroyed in the correct order. This built-in orchestration reduces the risk of misconfigurations and simplifies complex infrastructure setups, allowing you to focus on the overall design rather than manual sequencing.

Create an AWS IAM user

You need to create an AWS user that you can use to create or deploy AWS resources through the command line.

In the AWS Console, go to the “Services” menu and select “IAM” (Identity and Access Management).
Click on Users in the IAM dashboard, Click the Add users button to create a new IAM user.
Provide a username for the new user.
Select Access key – Programmatic access to create access keys for CLI access,
Click Next: Permissions.
Under Set permissions, choose Attach policies directly.
In the search box, type AmazonS3FullAccess and select the AmazonS3FullAccess policy.
Click Next: Review.
After creating the user, you’ll be presented with the user’s access key ID and secret access key.
Download the CSV file or copy the keys and store them securely. These keys are essential for CLI access and cannot be retrieved after this step.
Click Close.
Open a terminal and run the command aws configure. You should see a user input show up if you have the AWS CLI installed on your computer.

Enter the access key ID, secret access key, desired AWS region, and output format (e.g., JSON).

Test the setup by running a simple AWS CLI command, like aws s3 ls, to verify that the user has access to S3.

Ensure you have Terraform installed on your computer. Type terraform version to confirm this if You don’t have Terraform installed, then follow this link
https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli
Create your Terraform configuration file, here’s mine, and I will explain the file’s content below.

provider "aws" {
    region = "eu-west-2"
}

resource "aws_s3_bucket" "my_public_bucket" {
    bucket = "public-documents"
    tags = {
        Name = "public-documents"
    }
}

resource "aws_s3_object" "test_object" {
    bucket = aws_s3_bucket.my_public_bucket.id
    key = "test.txt"
    content = "Just a test file"
}

resource "aws_s3_bucket_ownership_controls" "public_access" {
  bucket = aws_s3_bucket.my_public_bucket.id
  rule {
    object_ownership = "BucketOwnerPreferred"
  }
}

resource "aws_s3_bucket_public_access_block" "public_access" {
    bucket = aws_s3_bucket.my_public_bucket.id

    block_public_acls       = false
    block_public_policy     = false
    ignore_public_acls      = false
    restrict_public_buckets = false
}

resource "aws_s3_bucket_acl" "public-read" {
    depends_on = [
        aws_s3_bucket_ownership_controls.public_access,
        aws_s3_bucket_public_access_block.public_access,
    ]

    bucket = aws_s3_bucket.my_public_bucket.id
    acl    = "public-read"
}

resource "aws_s3_bucket_policy" "bucket_public_policy" {
    bucket = aws_s3_bucket.my_public_bucket.id
    policy = data.aws_iam_policy_document.public_bucket_policy_statement.json
}

data "aws_iam_policy_document" "public_bucket_policy_statement" {
  statement {
    effect = "Allow"

    principals {
      type        = "AWS"
      identifiers = ["*"]  # Allowing public access
    }

    actions = [
      "s3:GetObject",
    ]

    resources = [
      "${aws_s3_bucket.my_public_bucket.arn}/*",  # Apply the policy to all objects in the bucket
    ]
  }
}

The provider block is a plugin that allows Terraform to interact with different service APIs, like AWS, Azure, or Google Cloud Platform. When you define a provider, you’re setting the context for Terraform to work with a specific cloud service.

Aws as the provider specifies that the configuration is for interacting with Amazon Web Services (AWS) and you just simply set the region to eu-west-2.

The resource block in Terraform defines the actual infrastructure elements that Terraform creates, manages, modifies, or deletes. This block contains the parameters and settings associated with the resource type, as specified in the Terraform documentation. A resource may have mandatory attributes that must be set, along with optional attributes that can be configured as needed.

In this particular configuration file, there are five resources, each dependent on the others to achieve the desired outcome. These dependencies are crucial for ensuring proper orchestration and sequencing during deployment.

Although the resource has a name in the Terraform code to keep track of it, this name does not necessarily correspond to the name of the infrastructure component that Terraform creates on the cloud (AWS in this case).

Instead, it’s a unique identifier within the Terraform configuration to manage dependencies and relationships between resources.

The data block allows you to retrieve or reference existing infrastructure or external information within your configuration.

This is useful when you need to work with resources that are not created by Terraform but are still part of your deployment process.

Now you have your file, follow the commands below to start the creation and configuration of your infrastructure.

Execute terraform init
This command initializes your Terraform working directory, downloading provider plugins and preparing your workspace.

To view the proposed changes to your infrastructure, ensuring there are no errors in your configuration file relative to the provider’s specifications.

Execute terraform plan
This step gives you an overview of what Terraform will do, allowing you to confirm the expected actions before making any changes.
To deploy the specified infrastructure according to your configuration file.

Execute terraform apply.
This command carries out the plan, creating or updating your infrastructure as described in your Terraform configuration.
You should see the response Apply complete as shown in the screenshot below.

Locate your S3 page in your AWS account, and confirm that the bucket has been created and an object was uploaded to it.

Locate the public link of the object and confirm that you can download the object from any computer using the public URL.

To remove this particular infrastructure you have created using Terraform, ensure you are in the right directory where the config file is present, run the command terraform destroy

Below is the relevant Terraform documentation I used when writing this config file, it contains more details for setting AWS S3 resources using Terraform.

aws_s3_bucket_policy | Resources | hashicorp/aws | Terraform | Terraform Registry

aws_s3_bucket_acl | Resources | hashicorp/aws | Terraform | Terraform Registry

Terraform Registry S3

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_object

Conclusion

We have successfully set up S3 bucket and made it public using Terraform, we did not need to use the AWS management console for anything except to confirm that the resources have been set up as required.

Thanks for reading through to the end, Let me hear your comment.

Read the story from my blog
DigitalSpeed

DEV Community: Wilson Anorue

4 Mistakes to Avoid When Setting Up a CI/CD Pipeline

Take a Snapshot of Your Server Before You Begin

Set Up Your SSH Key Properly

Carefully Review Your Deployment Path

Use Server Configuration Management Tools for Your Environment

Build Fast, Fail Fast, and Enable Detailed Monitoring

Some Additional Useful Tips

Conclusion

Creating a CICD Pipeline using Jenkins on AWS EC2, Monitoring using Prometheus, and Grafana

Prerequisite

Why Jenkins

Connect GitHub to Jenkins

Connecting Prometheus as a Data Source to Grafana

Configure the Prometheus Data Source

Conclusion

GitHub Repo

Other Relevant links

How to deploy a containerized app on AWS EKS clusters with Ingress-NGINX enabled

Prerequisite

Set up roles and user

Setup Local Command Line user

Setup EKS role

Navigate to your IAM dashboard from the search box

Setup EC2 Nodegroup role

Set up infrastructure and platform

How to create a publicly available bucket on AWS using Terraform

Prerequisites

What is Terraform

Why use Terraform

Create an AWS IAM user

Conclusion