DevOps Project Ideas 💡 with Solutions: Intermediate Level

Hello everyone 👋, In this article, I will share with you some project ideas I practiced during my DevOps learning journey. All the project ideas you are going to try will be at an intermediate level. In this article, I will share Project ideas with a Repository Links so you can easily try all three by yourself. You can find all the Source code in the Repository.

I have also shared steps on how to build each project in the Repository as well as on the blogs. I am sure the steps will give you a good understanding of how to actually build that project. You can easily build these projects by following the steps section in the blogs.

All of them will be at an intermediate level, I think each will take at most three days only. So, try to implement them yourself from scratch. I hope it will help in your learning journey as well as improve your hands-on skills.

If you can’t develop these projects, don’t worry. Let me know in the comments where you are getting stuck or you can also reach me on LinkedIn. I am happy to help you.

1. End-to-End CI/CD Pipeline for Flask Application Based on GitOps

Architecture Overview:

We are going to build a CI/CD pipeline that will be triggered by a push to the main branch of the repository. The pipeline will build the application, run the tests, and deploy the application to a Kubernetes cluster based on GitOps. The pipeline will be implemented using GitHub Actions and ArgoCD.

The Architecture of the project is explained below:

• First, We have a GitHub repository that contains the source code of the application. The repository is connected to GitHub Actions, which will be used to build and deploy the application.
• The GitHub Actions workflow will be triggered by a push to the main branch of the repository. The workflow will build the application, run the tests, and Push the Docker image to Docker Hub. And then It will Update the Image tag in the Manifest Repository.
• The Manifest Repository is a separate GitHub repository that contains the Kubernetes manifests for the application. And our Argo CD will be watching this repository for changes. Once the image tag is updated in the Manifest Repository, Argo CD will automatically deploy the new version of the application to the Kubernetes cluster.

Application Source Code Repository link: Click here

Manifest Repository: Click here

Blog Link: Click here

2. Dynamic Inventory Load balancing with Ansible

Architecture Overview:

We are going to use Ansible to provision our EC2 instances. Once the instances are up, we’ll install Httpd (a web server) on it. For load balancing, we’ll utilize HAProxy. Everything will be automated, so all we have to do is run the playbooks.

This project is about creating a dynamic inventory for load balancing using Ansible. In this architecture, I have used the AWS EC2 instances as the inventory servers and HAProxy as the load balancer. This Workflow is divided into two parts.

i) The first part is about creating the dynamic inventory hosts.

ii) The second part is about dynamically updating the HAProxy configuration file.

Repository link: Click here

Blog Link: Click here

3. Build a Voting App using Kustomize and Kubernetes

Architecture Overview:

In this Project, We are going to build a Simple Voting App that allows users to vote for their favorite pets (cats or dogs). This is an example provided by Docker officials. For some purposes I believe it’s the most appropriate one to understand Kustomize. You can also check out Docker’s official example using Docker Swarm.

The Voting App consists of the following components:

• A Frontend Service that serves the web application to users to vote for their favorite pets (cats or dogs). It is Developed using Python Flask.
• A Redis Service that stores the votes.
• A Worker Service that processes the votes and stores them in the Postgres database.
• A Postgres Service that stores the details of the votes such as the pet name and the number of votes.
• A Result Service that displays the results of the votes. It is Written in Node.js.

Repository link: Click here

Blog Link: Click here

4. Building a Helm Chart for MongoDB Admin Interface Application from Scratch

Architecture Overview:

The MongoDB Admin Interface is a web-based application that allows users to interact with a MongoDB database via a web interface. This web interface provides a user-friendly interface for performing common database operations such as querying, inserting, updating, and deleting data.

The architecture of the MongoDB Admin Interface deployment using Kubernetes is as follows:

• We are going to Create two deployments one for the application and one for the database.

Web Application Deployment:

• We are using the mongo-express:latest image for creating the application.
• We will use deployment to create the pods because if the pod goes down, the deployment will create a new pod, Deployment will help us manage the lifecycle of the pod. It also gives us the feature of scaling the application and high availability.
• For exposing the Web to the outside world, We are using the service with NodePort Type.
• Nodeport: It is a service type that exposes the deployment outside the cluster.

Database Deployment:

• We are using the mongo:5.0 image for creating a deployment for the database.
• We are again using deployment to create the pods because if the pod goes down, the deployment will create a new pod.
• For communication of DB with the frontend/backend, we are using the ClusterIP service.
• ClusterIP: It is a service type that exposes the deployment within the cluster.

Other Kubernetes Resources Used:

• Secrets: To store sensitive information like username and password.
• ConfigMap: To store the non-sensitive data in key-value pairs, In our case we are using it to store the database URL.
• PersistentVolume and PersistentVolumeClaim: To store the data in the database, So that if our pod goes down, the data will be safe.

Repository link: Click here

Blog Link: Click here

5. End-to-End CI/CD Pipeline for Node.js Web Application using AWS CI/CD Services

Architecture Overview

The architecture of the CI/CD pipeline is as follows:

• Users start by pushing a new commit to the GitHub repository. This triggers the pipeline, which consists of three stages: Source, Build, and Deploy.
• The Source stage pulls the source code from the GitHub repository.
• The Build stage uses AWS CodeBuild to Test the Node.js web application.
• The Deploy stage uses AWS CodeDeploy to deploy the Node.js web application to an Elaastic Beanstalk environment.

Note: The build stage in this project is used to test the Node.js web application. In a real-world scenario, you would also include the build process in this stage.

Repository link: Click here

Blog Link: Click here

👏 If you find this article as helpful, Don’t forget to give applause and follow my profile. I’ll be sharing more projects and ideas about Cloud and DevOps. If you have any doubts, Let me know in the comments or reach me on LinkedIn.

Let’s Connect on LinkedIn: LinkedIn Profile

Explore more Hands-On Projects(If you found my Repositories as helpful; Don’t forget to Follow me on GitHub): My GitHub Account