DEV Community: Utibe

Ingress Is Fading Away: But Where There Is A Will, There Is A Gateway API

Utibe — Thu, 04 Dec 2025 09:10:41 +0000

Following the recent announcement of the retirement of the popular Kubernetes Ingress controller, Ingress-Nginx, it is advisable that administrators explore alternatives. While other controllers like Traefik, nginx-ingress, are still good options at the moment, it is clear the community is moving away from Ingress as Kubernetes have made it known that the API itself is no longer actively developed.

The Will

Kubernetes is a popular cloud-native platform for deploying, scaling, and managing containerised applications. By default, applications deployed in a Kubernetes cluster are not exposed to the internet, so you need a way to make them accessible and a central way to route traffic to the specific services running in the cluster. This is the solution that Ingress provides.

For years, Ingress has handled routing external traffic to services in a Kubernetes cluster well enough, but it has always had certain limitations that become hard to ignore as your cluster grows and administrative needs expand.

For instance, Ingress natively supports only HTTP(S) routing and TLS termination. Without vendor-specific features, it does not support many advanced traffic management needs like support for other Layer 7 protocols (udp, grpc), content-based routing, session affinity, etc.
To implement any of this, you end up being drowned in a sea of annotations that are non-standard and vary between controllers.

Additionally, while you can restrict access to Ingress via RBAC, there's no native way for, let's say, an admin to manage TLS and a developer to manage routing in the same ingress. The dev would need access to the whole Ingress spec, which could lead to misconfigurations that affects others sharing the controller in a multi-tenant environment.

Not being able to standardise configuration across clusters has become a pain point, and administrators need a way to ensure teams have only the necessary access to perform their jobs, while relying less on other teams.

This is why the development for the Ingress API is being abandoned in favour of the Gateway API (whose idea was first introduced as Ingress 2.0, before that, too, was abandoned).

The Gateway API

In October 2023, the Gateway API was announced. It is meant to replace Ingress in the long run and not be an upgrade or new version of the Ingress API.

The Gateway API offers a more structured and extensible traffic management API with clear separation of concerns and standardization across providers of the underlying controllers.

Gateway API breaks traffic management into distinct Kubernetes objects, something Ingress never properly achieved. Instead of one object carrying both infra-level settings and app-level routing with a sea of annotations, Gateway API separates responsibilities cleanly.

The three core objects are:
GatewayClass – defines the implementation (controller)
Gateway – defines the entry point
Route resources – define how traffic should be forwarded (e.g., HTTPRoute, GRPCRoute, UDPRoute)

This structure gives clearer boundaries between infra teams and application teams, and removes the annotation-driven configuration style that made Ingress brittle and inconsistent across controllers.

GatewayClass
Ingress uses annotations to bind an Ingress object to a controller. Gateway API formalises this into a dedicated object.

A GatewayClass declares which controller will implement a Gateway. It’s purely infrastructure-level and usually immutable once defined.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx
spec:
  controllerName: k8s.nginx.org/nginx

Gateway
A Gateway object represents the actual data-plane listener — the equivalent of the load balancer or proxy entrypoint. This is separate from routing logic, so infra teams control where traffic enters and how it is exposed (ports, protocols, hostnames).

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP

In Ingress, this is similar to the Ingress controller + service load balancer abstraction, but explicitly modeled instead of implicit.

HTTPRoute
Routes define how traffic is matched and forwarded. HTTPRoute replaces the routing rules you’d normally place under spec.rules in an Ingress. The difference is that Gateway API supports richer matching and isn’t tied to the limitations of annotations.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: books
spec:
  parentRefs:
  - name: shop
  hostnames:
  - "shop.books.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: books
      port: 80

After years of Ingress, you would realise Ingress puts the controller, entry point, and routing logic into a single object, with most controller-specific behaviour hidden behind annotations.

In contrast, Gateway API exposes these responsibilities as objects, resulting in consistent behaviour across controllers, better separation of duties, and routing rules that are easier to reason about.

Conclusion

Ingress is not going away soon, but the ecosystem is already adjusting to a reality where Gateway API becomes the standard way to manage traffic in Kubernetes. Its clearer design, stronger separation of roles, and consistent cross-implementation behaviour make it a more practical long-term choice. Migrating to the Gateway API might be hard, but it should be done gracefully. Analyse your setup, understand your routes and watch out for controller support maturity.

Building and Deploying An API With Python & Azure

Utibe — Mon, 24 Mar 2025 11:35:02 +0000

Introduction

As a cloud engineer, working with APIs and serverless services will almost always come into play at some point in your journey. I recently completed the LearnToCloud Phase 2 guide and took on the capstone project. In this article, I'll walk you through a version of the project where I built a FastAPI, leveraging Azure Blob Storage for storage, CosmosDB for the database, and Terraform for Infrastructure as Code (IaC), all deployed using Azure Functions.

Project Overview

The API serves data on clubs that participate in the Nigerian Professional Football League, including their short name, nickname, home stadium, link to their logo image, and number of titles they have won. It also has a fun feature that generates fun facts about a club when requested using the OpenAI API.

Tools and services used:

Terraform is used to provison resources on Azure.
Azure Blob storage is used to save image files.
Azure CosmosDB serves as the database which FastAPI interacts with to retrieve and serve the data
OpenAI API
Azure Functions App to host the API as a serverless function

Architecture diagram:

Setting Up The Project

Prerequisites:

Azure CLI
Python Installed
Knowledge of Terraform
Basic knowledge of Python and FastAPI
Familiarity with Azure CosmosDB, Blob Storage, Azure Functions, and Azure Core Tools

You can either run the API locally or deploy using Azure Functions. The former is just the basic steps of running a FastAPI application using uvicorn and does not leverage the full potential of the setup. So I will walk you through the full setup. First, you should clone the repository from Github here.

Terraform
Once you are in the project folder, cd into the infra directory and update the necessary variables and state information, then run:

terraform apply -auto-approve

Once done, Terraform will create a:

Storage account and blob container
Upload logo images to the blob storage
Azure CosmosDB account
Azure Functions App

Cosmos DB
Next, access the data.json file and populate Azure CosmosDB with the JSON data. If you want to learn a bit more about CosmosDB SQL server you can use this link.

FastAPI
Before we proceed, I would like to hint at some parts of the main API code. The API has 4 prominent endpoints and they serve data stored in Azure CosmosDB.

GET /clubs: Get all clubs.
GET /clubs/{club_name}: Get a particular club details by name.
GET /clubs/by-titles?min_titles=5: Get clubs with at least 5 titles.
GET /clubs/fun-fact?club_name=Enyimba: Get a fun fact about a club.

The part of the code that interacts with CosmosDB looks like this:

from azure.cosmos import CosmosClient
from .config import settings

class CosmosDB:
    """class to handle cosmosdb connection and queries"""
    def __init__(self):
        self.client = CosmosClient(settings.cosmos_endpoint, settings.cosmos_key)
        self.database = self.client.get_database_client(settings.cosmos_database)
        self.container = self.database.get_container_client(settings.cosmos_container)

    def get_clubs(self):
        query = """
        SELECT 
            c.id, 
            c.club, 
            c.full_name, 
            c.short_name, 
            c.nickname, 
            c.stadium, 
            c.titles_won, 
            c.logo
        FROM c
        """
        try:
            items = list(self.container.query_items(query, enable_cross_partition_query=True))
            return items
        except Exception:
            return {"Internal Server Error"}

Also, a basic FastAPI endpoint looks like this:

@app.get("/clubs/by-titles-won")
def get_clubs_by_titles(min_titles: int):
    """get clubs with titles won greater than or equal to min"""
    try:
        clubs = db.get_clubs()
        filtered_clubs = [club for club in clubs if int(club["titles_won"]) >= min_titles]
        return filtered_clubs
    except Exception:
        raise HTTPException(status_code=500, detail="Internal Server Error")

Tests are also written to test the endpoint to ensure it does what it should:

def test_get_club_by_name():
    response = client.get("/clubs/heartland")
    assert response.status_code == 200
    assert response.json()["club"] == "Heartland"

You can go through more parts of the API code at .api/WrapperFunction

Azure Functions
The configurations setup for Azure Functions are already available. If you want to learn how to setup Azure Functions using the Core Tools, you should use this link.

For specifically using Azure functions with FastAPI, this link will serve as a better guide.

Now, there are two ways to host your functions, locally (usually for testing your setup) and by publishing to Azure Functions App. To publish locally, run:

func start

To deploy to Azure Functions App, there are some considerations you should keep in mind. First of all, ensure your Python version used locally is compatible with the one you chose when creating the Functions App, also, ensure that the folder structure is properly set up and that environment variables are updated. After all this is done, run:

func azure functionapp publish <functionapp_name>

Upon successful deployment, Azure Functions will provide a link where you can access your API. You can access the API via the various available endpoints.

- GET /

- GET /clubs/by-titles?min_titles=5

Conclusion

Summary
In this project, I was able to build and deploy a FastAPI-based serverless API using Azure Functions, CosmosDB, Blob Storage, and Terraform. The API provides information on Nigerian football clubs and even generates fun facts using OpenAI.

Next Steps

Try extending the API by adding more endpoints, integrating authentication.
Explore other serverless compute options like AWS Lambda or Google Cloud Functions.

Call to Action
Feel free to check out the GitHub repo, experiment with the codebase ad drop some suggestions. If you found this helpful, don’t forget to share!

Happy Hacking!

Azure DevOps Explained: Services, Tools And Use Cases

Utibe — Fri, 31 Jan 2025 07:56:23 +0000

Introduction

I recently setup a deployment workflow for a microservices-based application. Faced with a client requirement to stay within the Azure ecosystem, I explored Azure DevOps to integrate modern DevOps practices seamlessly into the deployment workflow.

Azure DevOps is a set of cloud tools and services offered by Microsoft that helps streamline software development, collaboration, and deployment. While it is abstracted from the Azure platform itself, it is still tightly integrated with Azure services and they work seamlessly together, it also has great support for other third party DevOps tools, services and cloud platforms.

Over the next few paragraphs, I will be talking about the tools and services Azure DevOps offers, how I used some of these tools, and how they work with other Azure services.

Azure DevOps Core Services

Azure DevOps takes a modern approach to software development by emphasizing collaboration, automation, Infrastructure as Code (IaC), project management, product testing, Continuous Integration (CI), and Continuous Deployment (CD). This methodology streamlines the building, testing, and delivery of software, enabling teams to work more efficiently.

Additionally, Azure DevOps supports both cloud-hosted and on-premises solutions through Azure DevOps Services (cloud-based) and Azure DevOps Server (self-hosted).

These capabilities are made possible through a suite of integrated services and tools designed to enhance the entire development lifecycle.

Core Services

Azure Repos: This is one of its key services. Azure Repos provides a code repository for storing application code and configurations and offers source control with Git and TFVC.
Azure Pipelines: Modern DevOps does not come without support for CI/CD (Continuous Integration and Continuous Deployment) automation for faster and seamless deployments. Azure Pipelines is the Azure platform that makes this process possible. Like Github Actions, it uses a YAML file approach and has presets that can help you write pipeline jobs quickly and efficiently.
Azure Boards: This enables agile project tracking for development teams. With Azure boards, you can plan, track, and discuss jobs and tasks across teams.
Azure Test Plans: This is a test management and it comes with exploratory test toolkits that help you teams ship product with confidence. It has also has advanced testing features that are available on a paid plan.
Azure Artifacts: Package management to create, store and share dependencies, packages, builds and mods. Easily integrates with Azure Pipelines and other CI/CD pipelines and let's them use the stored artifacts.

Azure DevOps in Action - Using Azure DevOps

Having explored the services available on the Azure DevOps platform, let us now see how these services come together in a real-world deployment scenario.

I was tasked with implementing an end-to-end deployment pipeline for a microservices-based application on Kubernetes, leveraging Azure services. The application comprised services written in Python (FastAPI) and JavaScript (Node.js), with Redis and PostgreSQL as the databases.

The codebase was initially hosted on GitHub, so my first step was migrating it to Azure Repos. Following that, I designed a CI/CD workflow using Azure Pipelines to automate the build process, scan container images for vulnerabilities, and push them to Azure Container Registry (ACR). Unlike GitHub Actions, Azure Pipelines often requires self-hosted agents to execute workflows, which I set up accordingly. (For more details on self-hosted agents, see my article here.)

Next, I provisioned a test Kubernetes cluster using Azure Kubernetes Service (AKS) and deployed ArgoCD, a GitOps tool for Kubernetes. I then configured an ArgoCD application to continuously monitor a specific directory in Azure Repos containing Kubernetes manifests, ensuring that the cluster state always reflects the desired configuration.

This setup streamlined the deployment process by combining Azure DevOps, Kubernetes, and GitOps principles, resulting in a fully automated and scalable deployment pipeline.

Why Azure DevOps?

While there are more popular DevOps platforms and services, there are some specific reasons to choose Azure DevOps for your next project.

1. Integration with other Azure Services: Azure DevOps has a great integration with other Azure services like:

Azure Kubernetes Service (AKS) – Deploy containerized applications.
Azure Virtual Machines (VMs) – Host applications and automate deployments.
Azure Functions – Serverless automation in CI/CD workflows.
Azure Monitor & Log Analytics – Track and analyze CI/CD performance.
Azure Key Vault – Securely store secrets for pipelines.
(Use a diagram to show how Azure DevOps interacts with these services.)

2. Multi-cloud support: Azure DevOps provides robust multi-cloud support, making it a flexible choice for enterprises operating across OpenStack, AWS, and Google Cloud. It offers native integrations with major cloud providers, enabling seamless deployment to VMs, Kubernetes clusters (AKS, EKS, GKE), and serverless environments. With built-in Azure Pipelines, teams can use agent pools, Terraform, Ansible, and Bicep to automate infrastructure provisioning across multiple clouds while maintaining centralized governance.

Unlike other DevOps platforms that may be tightly coupled to a single cloud, Azure DevOps provides a vendor-agnostic CI/CD solution. It supports multi-cloud authentication, cross-cloud artifact storage, and hybrid deployments, allowing organizations to avoid vendor lock-in and optimize workloads based on cost, performance, and compliance needs.

3. Enterprise security: Azure DevOps offers enterprise-grade security with built-in compliance, advanced identity management, and secure pipelines, making it a strong choice over other DevOps platforms. It integrates natively with Azure AD for SSO, MFA, and Conditional Access, enforces RBAC for granular permissions, and ensures end-to-end security with Azure Key Vault for secrets management, private networking (Private Link), and threat detection via Microsoft Defender and Sentinel. Additionally, its compliance with ISO 27001, SOC 2, and HIPAA simplifies governance for regulated industries.

Unlike other platforms that rely on third-party security add-ons, Azure DevOps provides seamless, built-in security features for code, artifacts, and CI/CD pipelines. With audit logging, policy enforcement, and real-time security scanning, it helps organizations proactively mitigate risks while maintaining high availability and compliance, making it ideal for enterprises with strict security requirements.

Conclusion

While Azure DevOps may not be the first choice for every DevOps engineer, its deep integration with Azure and strong security features make it a compelling solution for teams using Microsoft’s ecosystem.

Self-Hosted Runners in Azure Pipelines: The Why And The How

Utibe — Mon, 27 Jan 2025 22:38:41 +0000

While Azure DevOps have a generous free offering, running CI/CD pipelines with Azure Pipelines will require a paid plan to use Azure hosted runners, a cost effective solution would be to provision and configure your own runner.

If you're used to platforms like GitHub Actions or haven't worked with Jenkins, managing and configuring runners may feel unfamiliar. This rather brief piece aims to simplify the process and walk you through provisioning your own self-hosted agent for Azure Pipelines.

What is a Runner?

Although natively reffered to as "Agents" in the Azure ecosystem, the most common name for it would be "Runners".
When your pipeline runs, the system begins one or more jobs. A runner is a computing infrastructure that executes jobs defined in your continuous integration (CI) or continuous delivery (CD) pipelines. It’s the environment where tasks like building, testing, and deploying your application are carried out

Azure Devops offer other options for these "agents", there is the:

Microsoft-hosted
Self-hosted agents
Azure Virtual Machine Scale Set agents
Managed DevOps Pools agents

But we will focus on the Self-hosted agents as the other options might come at a pricey rate. You can learn more about the other options here.

Why Use Self-Hosted Runners?

As you can probably figure out by now, cost efficiency is just one of the many reasons to use self-hosted runners. Nearly all continuous integration platforms provide the option to utilize your own runners, and the benefits extend beyond saving money.

Here are some key advantages:

Data Security and Compliance: Self-hosted runners allow you to maintain tighter control over sensitive data and meet specific compliance requirements.
Faster Builds and Better Resource Management: With self-hosted runners, you can allocate resources according to your needs, leading to faster build times and greater flexibility in managing workloads.
Support for Special Scenarios and Legacy Systems: They are particularly useful for handling unique setups or supporting older systems that may not be compatible with shared runners.

If you have stuck around for this long, you probably are ready to dive into configuring your own self-hosted agent for Azure Pipelines so let's begin.

Step-by-Step Guide to Setting Up a Self-Hosted Agent

I will be using an Azure Virtual Machine (cool sticking to the eco-system) as the infrastructure for our agent. But you can use any virtual machine and even your local system. But before if you are not running linux, you might have to select a few different options aling the line.

1 - Create a Virtual Machine

Provision a virtual machine (VM) in Azure and ensure SSH access is enabled.

2 - Configure an Agent Pool in Azure DevOps

Navigate to Organization Settings > Agent Pools.
Click Add Pool, provide details, and select Grant access permission to all pipelines.
Open the newly created pool, go to the Agents tab, and click New Agent.

3 - Install and Configure the Agent on the VM

SSH into your virtual machine.
Run the following commands to set up the agent:

# create a new directory, downloads the agent and unpacks the files
mkdir myagent && cd myagent

wget https://vstsagentpackage.azureedge.net/agent/4.248.0/vsts-agent-linux-x64-4.248.0.tar.gz

tar zxvf vsts-agent-linux-x64-4.248.0.tar.gz

# configure the agent
./config.sh

During configuration, you’ll be prompted for:

Server URL: Use https://dev.azure.com/{yourorganization}.
Personal Access Token (PAT): Generate this from User Settings > - - Personal Access Token in Azure DevOps.
Agent Pool Name: Enter the name of your pool (if you did not use default).
Agent Name and Work Folder: Confirm these settings.

At this point the agent status will appear as "offline" on the Azure Devops platform, Run:

./run.sh

After this, your agent should now be online and ready to accept jobs.

Final words

With your self-hosted agent set up, remember that you are responsible for maintaining it. This includes applying patches, updates, and installing tools as needed. For example, if your pipeline requires Docker, you’ll need to install and configure Docker on the VM.

By following these steps, you now have a cost-effective and flexible agent for Azure Pipelines.
Keep building!

Advanced Kubernetes Deployment with GitOps: A Hands-On Guide To Terraform, Ansible, ArgoCD And Observability Tools

Utibe — Tue, 07 Jan 2025 16:05:53 +0000

Introduction
Overview
Infrastructure Provisioning
Application Management
Logging and Monitoring
Challenges and Lessons Learned
Conclusion and Final Thoughts

Introduction

GitOps is a modern approach to managing software applications and the infrastructure they run on, leveraging Git as the single source of truth for version control. It integrates seamlessly with practices like Continuous Integration/Continuous Deployment (CI/CD) and Infrastructure as Code (IaC) to ensure consistency, automation, and reliability. The core workflow involves developers committing code or configuration changes to a Git repository, which triggers automated pipelines to build, test, and deploy the updates to the target environment.

GitOps is often used to manage Kubernetes clusters and cloud-native app development.
Kubernetes itself is an orchestration system used to deploy and manage containerized applications.

I recently completed a project where I followed GitOps practices to deploy a microservices based applications managed with kubernetes.
This project is a demonstration of modern DevOps practices through the implementation of GitOps to deploy a Kubernetes-managed microservices application. By using Git as the single source of truth for both infrastructure and application state, the project highlights the power of version-controlled, automated, and auditable deployments. GitOps, being Kubernetes-native, aligns seamlessly with container orchestration and microservices architecture, showcasing scalability, resilience, and automation in cloud-native systems. Additionally, it embraces the "shift-left" approach by empowering developers to contribute to operations through simple Git workflows, fostering collaboration and reducing deployment errors. With its focus on observability, traceability, and the ability to scale across diverse environments, this project underscores key principles of modern DevOps, making it highly relevant in today's software delivery landscape.

Overview

The aim of this project is to create a fully automated setup for deploying a microservices based application using kubernetes (helm) and also deploy observability tools on the provisioned kubernetes cluster to both monitor the state of the cluster and retreive logs.
The following tools and services used in the project.

Terraform
Ansible
Azure Kubernetes Cluster
Docker/Dockerhub
Trivy
Helm
Kube-Prometheus Stack (monitoring)
EFK Stack (logging)

This diagram shows the full flow of the project:

A fully complete DevOps setup typically involves multiple integrated components. This project utilized three Git repositories to manage distinct aspects of the workflow:

Infrastructure Repository: Hosts Terraform and Ansible configurations for provisioning and configuring the Kubernetes cluster.
Application Repository: Contains the microservices application source code, including the Dockerfile for building container images.
Kubernetes Manifests Repository: Stores Kubernetes manifests and Helm charts for application deployment.

The project workflow involves running terraform apply to provision or update an Azure Kubernetes Service (AKS) cluster and generate an Ansible hosts.ini file with cluster details. Once the cluster is ready, Terraform triggers Ansible to execute additional tasks, including:

Deploying the Kube-Prometheus stack for monitoring
Setting up the EFK stack for centralized logging
Installing ArgoCD using Helm
Configuring an ArgoCD application to sync with the Kubernetes Manifests repository, ensuring that the cluster state matches the repository's desired state

This setup streamlines the process of deploying applications and observability tools. With a single terraform apply command, the entire infrastructure, monitoring, logging, and GitOps deployment configuration is provisioned and operational.

Infrastructure Provisioning

Azure Kubernetes Cluster is a managed kubernetes cluster which is used as the main infrastructure for deploying our microservices applications. Provisioning of the cluster is managed using terraform, an infrastructure as code tool.

resource "azurerm_kubernetes_cluster" "app-cluster" {
  name                = "app-cluster"
  location            = data.azurerm_resource_group.default.location
  resource_group_name = data.azurerm_resource_group.default.name
  dns_prefix          = "app-k8s"
  kubernetes_version  = "1.30.6"

  default_node_pool {
    name            = "app"
    node_count      = 2
    vm_size         = "Standard_DS2_v2"
    os_disk_size_gb = 50
  }
}

This is a basic code structure that create an AKS cluster.

After cluster creation, terraform triggers ansible to run:

  provisioner "local-exec" {
    command = <<-EOT
      sleep 60 # wait for cluster to be ready
      KUBECONFIG=../ansible/kubeconfig \
      ansible-playbook \
        -i ../ansible/inventory/hosts.ini \
        ../ansible/playbook.yml \
        -e "kubernetes_cluster_name=${azurerm_kubernetes_cluster.app-cluster.name}" \
        -e "kubernetes_resource_group=${data.azurerm_resource_group.default.name}"
    EOT

    working_dir = "../ansible"
  }
}

Ansible setup has roles that use helm in installing ArgoCD, Kube-Prometheus stack and EFK stack. It also creates an ArgoCD appplication.

# playbook.yml

- name: Deploy tools on AKS
  hosts: localhost
  gather_facts: no
  vars:
    ansible_python_interpreter: /Library/Frameworks/Python.framework/Versions/3.12/bin/python3

  roles:
    - role: argocd_install
      vars:
        kubeconfig: "{{ kubeconfig_path }}"
      when: not node_status.failed

    - role: logging_stack
      vars:
        kubeconfig: "{{ kubeconfig_path }}"
      when: not node_status.failed

    - role: monitoring_stack
      vars:
        kubeconfig: "{{ kubeconfig_path }}"
      when: not node_status.failed

The roles configurations also contain the ArgoCd application manifest files. Complete configuration code can be found here.

Application Management

The application to be deployed is designed using microservices based architecture. The source codes and dockerfile for each microservice is being saved in a an application repo. A continous integration pipeline is also setup to handle code changes to the application code and dockerfile. The pipeline has jobs that:

Detect the services that has had changes
Build a new docker image and push it to dockerhub
Scan the docker images for vulnerability using Trivy
Update the manifest files in the manifest repository

The configuration codes for the workflow can be found here.

Kubernetes Manifests

Each services contains kubernetes manifest files for Deployment, Services and Service account. There is also an Ingress configuration file available. The manifest are also managed by a custom helm chart in the repository.

The Helm chart is being updated with current tags by the application repo workflow. It is the single source of truth used with ArgoCD in the kubernetes cluster.

GitOps Workflow

Argo CD is a continuous delivery (CD) tool for Kubernetes that uses GitOps to manage and deliver applications
It is synced to the manifests repo, and it ensures that the current state of the manifest repo is the deployed state in the kubernetes cluster.

ArgoCD is installed in the kubernetes cluster using Ansible, and an application that handles the manifest files is also created using ansible.

# infra-repo/ansible/roles/argocd_install/templates/application.yml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: {{ app_name }}
  namespace: {{ argocd_namespace }}
spec:
  project: default
  source:
    repoURL: {{ app_repo_url }}
    targetRevision: {{ app_target_revision }}
    path: {{ app_path }}
    helm:
      releaseName: {{ app_name }}
  destination:
    server: https://kubernetes.default.svc
    namespace: {{ app_namespace }}
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

---
# infra-repo/ansible/roles/argocd_install/templates/application.yml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-server-ingress
  namespace: {{ argocd_namespace }}
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: {{ argocd_host }}
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: {{ argocd_release_name }}-server
            port:
              number: 80

Logging and Monitoring

Metrcis, Logs and Alerts are pillars of observability. Deploying tools that simplify logging and monitoring our performance metrics is even more crucial in a microservices deployment where a single kubect logs on multiple pods and services might not suffice if you are trying to troubleshoot. This is where efficient and centralized metrics and log management tools like Kube-Prometheus (Prometheus, Grafana, Alert Manager) and EFK (Elasticsearch, Fluent Bit and Kibana) come in.

In this project setup, after terraform apply runs successfully, the Kube-prometheus stack and EFK stack are also deployed in the AKS cluster in the monitoring and logging namespaces respectively and with default configurations.
The configuration files that handles this can be accessed here.

Once the services are up, Kibana and Grafana UI can be accessed using their services via ingress or port-forwarding.

screenshot of deployed applications

screenshot of dashboards from kube-prometheus stack

screenshot of dashboard view with data on grafana

Challenges and Lessons Learned

Challenges:

Managing Repository Synchronization:
Ensuring consistent updates across the Infra, Application, and K8 Manifests repositories was complex, especially with multiple dependencies.
Tooling Compatibility:
Configuring Terraform and Ansible to work seamlessly required troubleshooting, particularly when passing dynamic values
ArgoCD Configuration:
Setting up ArgoCD applications to handle multiple microservices and ensuring proper synchronization posed a learning curve.
Docker Image Management:
Scanning and pushing Docker images while managing triggers for CI pipelines was challenging to automate effectively.
Debugging Deployment Failures:
Diagnosing deployment issues, such as misconfigured Kubernetes manifests or failed CI/CD pipelines, consumed significant time.

Lessons Learned:

Importance of GitOps:
GitOps principles simplify complex workflows by centralizing configurations in version-controlled repositories.
Toolchain Proficiency:
Cemented my understanding of tools like Terraform, Ansible, and ArgoCD significantly reduces setup time.
Iterative Approach:
Breaking down tasks into smaller, testable units (e.g., individual Ansible roles) improves development and debugging efficiency.
Documentation and Automation:
Comprehensive documentation and automation reduce the risk of misconfigurations during handoffs or scaling.

Conclusion

This project was a in-depth exploration of GitOps principles applied to a microservices based application deployment. By integrating Terraform, Ansible, and ArgoCD, I was able to streamline Kubernetes deployments while leveraging CI/CD pipelines with Github Actions for application management. Setting up logging and monitoring stacks ensured operational visibility while overcoming challenges deepened our understanding of Kubernetes and GitOps workflows.

This experience underscores the value of automation and iterative problem-solving in managing modern cloud-native architectures. Focusing more on the overall workflow and how the many different parts come together has been the biggest success of the project for me. As a next step, enhancing scalability, enhancing security, improving the overall continous integegration pipelines and exploring advanced GitOps practices, such as automated rollbacks and canary deployments, could further refine the workflow.

Continous Integration And Continous Deployment Of A Full-Stack Docker-Compose Application

Utibe — Tue, 17 Dec 2024 00:36:32 +0000

Achieving a fully automated setup for infrastructure and application deployment is usually not complete without a proper Continuous Integration and Continuous Deployment (CI/CD) setup. Previously, I had a setup where Docker Compose was leveraged to deploy a full satck application (Python, React, MySQL) and a corresponding monitoring stack (Prometheus, Grafana, Loki and CAdvisor) for monitoring the server and container metrics and logs. Terraform (IAC) and Ansible (Configuration management) was used together to quickly spin up the services.

But to keep track of future updates to the application or state of infrastructure running the application, it’s crucial to leverage a version control system like GitHub. Also, changes to our code and configuration should be seamlessly integrated into the currently version. This is where using Github actions comes in.

GitHub Actions is a CI/CD platform provided by GitHub that enables you to automate, build, test, and deploy your code directly from your GitHub repository. It allows developers to define custom workflows using YAML files that respond to specific events in a repository, such as pushes, pull requests, or issues.

Setting up a deployment pipeline does not require a particularly steep learning curve, but as with many complicated things, requires good planning and proper design. This would ensure the many moving parts work together. To learn more about github actions, you can use this link.

Project Requirements

For this project, we will be setting up a CI/CD pipelines to automate infrastructure and application deployments and it will include:

Cloud cost optimization with cost estimation tools like InfraCost.
Terraform and Ansible integration for infrastructure management and monitoring stack setup.
Git branching strategies for streamlined CI/CD pipelines.

To be able to follow along the implementation, you should have:

Knowledge of Docker, Git, Terraform and Ansible
An Azure subscription

The application code, configuration and workflow files for this project can be found in this github repository.

Architectural Overview

Architecture Diagram of the Setup

Implementation Process

1. Clone the repository
The repository contains code and configurations setup in directories as follows:

.github/worflows - workflow files
terraform - configurations for provisioning infrastructure resources on Azure
ansible - ansible playbooks and roles for configuring the server and bringing up monitoring and application stack
docker-compose - docker compose configuration files for both application and monitoring stack
app - contains application code for frontend and backend with their corresponding dockerfiles

2. Workflow Configurations & branch setup
There are 6 github actions workflow files:

terraform-validate.yml
terraform-plan.yml
terraform-apply.yml
ansible-monitoring.yml
ci-application.yml
cd-application.yml

Create 4 branches:

infra_features
infra_main
integration
deployment

3. Infrastructure Workflow

Push to infra_features branch -- the validate branch runs to confirm validity of terraform code
On pull request to infra_main branch, the plan workflow runs and adds an infracost comment containing the estimated monthly cost of the new infrastructure updates

On merge to infra_main branch, the apply workflow runs, creating or updating resources on Azure (or cloud service provider of choice).
On successful completion of terraform apply, the ansible workflow runs. This workflow will run ansible to configure the created server infrastructure and deploy the monitoring stack on the server.

4. Deployment Workflow

For deploying the application stack, when changes are made to the application code and there is a push of the new code to the integration branch, a workflow is triggered. It:
builds new docker images
tags and pushes the images to dockerhub
updates docker compose files with the new tags
On successful merge from integration branch to deployment branch, ansible is once again used to deploy the new version of the update docker compose files on the server.

Challenges and Solutions

Managing and Authenticating with Multiple Tools, Platforms and Frameworks
Testing Pipeline updates

Results and Learnings

Streamlined Infrastructure Management: The infrastructure pipeline automated the provisioning of cloud resources and deployed a monitoring stack efficiently.
Cost Transparency: Using InfraCost provided visibility into cloud expenses, enabling better decision-making.
Improved CI/CD Efficiency: The application pipeline successfully automated Docker image builds, updates, and deployments, significantly reducing manual efforts and errors.
End-to-End Automation: Combined workflows for infrastructure and application deployments achieved a fully automated system with minimal downtime during updates.

Conclusion

This project demonstrated the power of CI/CD pipelines in automating both infrastructure and application deployments. By integrating multiple tools into a cohesive workflow, the team achieved faster deployments, better cost control, and a more reliable system overall. The challenges provided valuable lessons on tool integration, branching strategies, and automation best practices, making future projects more efficient and scalable.

Automating the Deployment of a Docker-Powered Full-Stack Application with Terraform and Ansible

Utibe — Sun, 01 Dec 2024 22:53:10 +0000

Introduction

In a previous project, "Docker to the Rescue: Deploying React and FastAPI App With Monitoring", I explored Docker's transformative power in simplifying application deployment.

However as deployment requirements grow, automation becomes essential to ensure consistency, efficiency, and scalability. Manual deployments, particularly during updates, are prone to inefficiencies and inconsistencies, this is a significant challenge in software delivery. Automation addresses this by enabling seamless rollouts of application and infrastructure changes, reducing downtime and human errors.

In this article, I will go through a project where I leveraged automation to deploy a React and FastAPI application by:

Provisioning Azure resources with Terraform.
Integrate Ansible into Terraform to configure infrastructure
Orchestrating application deployment using Docker Compose.

Terraform provisions the server infrastructure required to host the application, while Ansible manages the configuration and setup of the provisioned server. The application (complete application and monitoring stack) is containerized and orchestrated using Docker Compose, ensuring seamless deployment and efficient resource management.
By integrating these tools, the setup becomes repeatable, robust, and adaptable to evolving deployment needs.

Architecture Overview

overview of complete architecture

Implementation Steps

I will walk you through the steps I took to set up this automation process. You can find the application configuration code on my github.

Docker and Dockerhub:
First I took the steps to push my custom application pre-built docker images to dockerhub:

docker tag utibeokon/frontend:v2.0 frontend
docker tag utibeokon/backend:latest backend

docker push utibeokon/frontend:v2.0
docker push utibeokon/backend:latest

The respective images can be found here.

Frontend: https://hub.docker.com/r/utibeokon/frontend
Backend: https://hub.docker.com/r/utibeokon/backend

Docker-Compose
I have my docker-compose configuration files in the project folder. Two docker compose files and other service specific config files properly named according the their respective services. The docker compose files contain declarations for the following services:
docker-compose.yml

Frontend
Backend
Postgres
Adminer
Traefik

monitoring/docker-compose.yml

Prometheus
Grafana
Loki
Promtail
Cadvisor

An overview of how the services interact within a shared docker network.

service interaction diagram

Frontend connects with Backend
Backend connects with Postgres for database interaction
Adminer serves as a database dashboard for administration
Traefik (running on ports 80 and 443) handles reverse-proxy within the network, handling routing, HTTPS redirecting and loadbalancing of requests received by the server
Cadvisor gathers container metrics and sends it to prometheus
Promtail gathers logs for Loki
Prometheus and Loki stores metrics and logs
Grafana accepts Prometheus and Loki as data source and display the data in graphical form using dahsboards.

Do well to confirm the routing configurations for Traefik. You can modify this to fit your routing needs.

Terraform:
In the terraform directory, there are configurations to provision a virtual network, a network security group and a virtual machine on azure. These configs are spread into two modules, network and vm. Also, the terraform setup uses azure blob storage as the remote backend.

# main.tf file
# provision a virtual network from the network module
module "network" {
  source              = "./modules/network"
  resource_group_name = var.resource_group_name
  location            = var.location
  vnet_name           = "server-vnet"
  subnet_name         = "server-subnet"
  nsg_name            = "server-nsg"
  allowed_ports       = ["22", "80", "443"]
}

# provision a virtual machine instance from vm module
module "vm" {
  source              = "./modules/vm"
  resource_group_name = var.resource_group_name
  location            = var.location
  vm_name             = "server"
  vm_size             = "Standard_B2s"
  admin_username      = var.admin_username
  ssh_public_key      = file(var.ssh_key_path)
  subnet_id           = module.network.subnet_id
}

# dynamically create an inventory file for ansible
resource "local_file" "inventory" {
  content = <<EOT
[servers]
${module.vm.public_ip} ansible_user=${var.admin_username} ansible_ssh_private_key_file=~/.ssh/id_rsa
EOT

  filename = "../ansible/inventory.ini"
}

# trigger the vm configuration with ansible
resource "null_resource" "ansible_provisioner" {
  depends_on = [
    local_file.inventory,
    module.vm,
    module.network
  ]

  triggers = {
    always_run = timestamp()
  }

  provisioner "local-exec" {
    command = <<-EOT
      sleep 60 # allow time for public ip to update
      ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook \
        -i ../ansible/inventory.ini \
        ../ansible/playbook.yml
    EOT
  }
}

# dns record for the server
# dns zone (slready created manually)
data "azurerm_dns_zone" "domain" {
  name                = var.domain_name
  resource_group_name = var.resource_group_name
}

resource "azurerm_dns_a_record" "domain" {
  name                = "@"
  zone_name           = data.azurerm_dns_zone.domain.name
  resource_group_name = var.resource_group_name
  ttl                 = 3600
  records             = [module.vm.public_ip]
}

Upon running terraform apply Terraform will:

Provision the resources on azure
Retrieve the public ip and create an inventory.ini file in the ansible directory with the public ip details
Trigger ansible to start configuring the server once it is ready

After inspecting the configurations, you can cd into the terraform directory and run

terraform init
terraform apply -auto-approve

Ansible:
The ansible setup consists of a single playbook and 3 roles. The roles are responsible for:

Preparing the server
Copying necessary files
Deploying the application

The playbook is a simple playbook that calls all three roles.

# playbook.yml
- name: Deploy Docker-based application
  hosts: servers
  become: yes
  become_user: root
  gather_facts: yes
  roles:
    - server-setup
    - copy-files
    - deploy-app

Deployed Application:
On a successful run of terraform apply -auto-approve, you will get a similar output as this:

If you used the the DNS configuration for Azure DNS, you can access the application via the domain name.
Else, you should copy the IP address, and create an A record the details on your DNS service provider website that maps to the IP address.

Challenges Faced

Ensuring Seamless Integration Between Terraform and Ansible
Managing sensitive data like SSH keys, credentials, and API tokens securely across both Terraform and Ansible.
Debugging Ansible Playbooks: Playbook errors due to mismatched dependencies or configurations on the target VMs slowed down the deployment.

Best Practices

-Automation workflow
Automate every step of the process—from provisioning to configuration—to reduce human error and improve reliability.

State Management
Use remote backends for Terraform state files to enable team collaboration and state consistency.
Testing and Validation
Validate Terraform configurations with terraform validate and terraform plan.
Test Ansible playbooks in isolated environments using Molecule before running them in production.

Conclusion

This project demonstrates the power of combining Terraform and Ansible to achieve seamless automation for infrastructure provisioning and application deployment. By leveraging Infrastructure as Code (IaC) and Configuration Management, it’s possible to create a repeatable, reliable pipeline that significantly reduces manual effort.

The challenges encountered, such as ensuring integration between tools and managing sensitive data, provided invaluable learning opportunities. Following best practices like modular design, robust state management, and automated testing ensures that the solution is both scalable and secure.

As a next step, this workflow could be extended by incorporating CI/CD pipelines, adding alerting mechanisms for monitoring, or scaling to multi-cloud environments. Automation isn’t just about efficiency—it’s about building systems that evolve with your needs.

Docker to the Rescue: Deploying React And FastAPI App With Monitoring

Utibe — Tue, 26 Nov 2024 23:12:52 +0000

Mary, a software developer in training and the owner of a small online retail business, found herself in a bind. A viral Instagram post about her products caused a sudden surge in orders, and her manual order tracking system couldn’t keep up.

Fortunately, she had been building a web app to manage her business, featuring a React frontend and a FastAPI backend. But there was one problem, she did not know how to deploy it. She needed a scalable, robust system, complete with monitoring to handle future traffic spikes and prevent downtime.

That’s where I came in. Together, we embarked on a journey to transform her project into a fully deployed application with a stack that included Docker Compose, Traefik, Prometheus, Grafana, and Loki. In this article, I’ll walk you through the process we followed to:

Containerize and orchestrate a full-stack app.
Configure a reverse proxy for secure routing.
Set up real-time monitoring for metrics and logs.
Deploying the stack to a cloud platform with a custom domain and HTTPS.

Let’s dive in.

Overview
The Process
Challenges
Lessons
Conclusion

Overview

To acomplish this, the following tools/services are employed:

Application Stack Services:

React Frontend: A dynamic and responsive UI powered by Chakra UI
FastAPI Backend: Provides REST APIs and Swagger documentation and using Poetry as package manager.
PostgreSQL: A robust database for persistent storage.
Traefik: Reverse Proxy fpr routing traffic seamlessly to appropriate services.

Monitoring Stack Services:

Prometheus: Collects and stores real-time metrics and provides querying abilities
Grafana: Visualizes performance and logs using data from prometheus and Loki
Loki & Promtail: Promtail collects logs, and Loki stores them for querying and visualization.
cAdvisor: Monitors container resource usage and forwards metrics to promethues

The Process

The application code to be deployed can be found here.

First I retreived the application:
git clone https://github.com/The-DevOps-Dojo/cv-challenge01

The repository is organized as follows:
Frontend: Contains the ReactJS application.
Backend: Contains the FastAPI application and PostgreSQL database integration.

I explored the codebase, I discovered a few uncommon aspects. First, I was unfamiliar with Poetry as a package manager for python, so I did some research on it and how to deploy Poetry applications. I tested the steps locally and was sure it was working fine before moving to the next step, containerization.

🖥️ Containerization
I wrote docker files for both frontend and backend code.

Frontend:

FROM node:16-alpine AS build

WORKDIR /app

COPY package.json package-lock.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["npm", "run", "dev", "--", "--host", "0.0.0.0"]

This docker file is responsible for building an image for the frontend application code.

Backend:

# Build stage
FROM python:3.10-slim as builder

RUN pip install poetry

WORKDIR /app
COPY poetry.lock pyproject.toml /app/

RUN poetry config virtualenvs.create false \
    && poetry install --no-interaction --no-ansi --no-root --no-dev

# Final stage
FROM python:3.10-slim

WORKDIR /app

RUN apt-get update \
    && apt-get install -y libpq-dev gcc \
    && rm -rf /var/lib/apt/lists/*

COPY --from=builder /usr/local/lib/python3.10/site-packages/ /usr/local/lib/python3.10/site-packages/
COPY --from=builder /usr/local/bin/ /usr/local/bin/

COPY . /app

RUN adduser --disabled-password --gecos "" appuser
RUN chown -R appuser:appuser /app
USER appuser

ENV PYTHONPATH=/app
ENV PORT=8000

CMD ["sh", "-c", "bash ./prestart.sh && uvicorn app.main:app --host 0.0.0.0 --port $PORT"]

EXPOSE 8000

This handles building the image for the FastAPI backend code. It looks more complicated becuase I used a multistage build to reduce file size due to the many layers involved with building an image for an app that requires Poetry for package management. If you are not familiar with multistage build, you can read more here.

The images for the other services I will be needing for this project will be retreived from Dockerhub.

🛳️ Docker Compose
Docker compose is an orchestration feature of docker where you can manage several containers running in a system. I will be using docker compose to manage my services. To accomplish this, I setup of folder structure and. created several YAML files for configuration.

docker-compose.yml - main configuration file
traefik.yml - traefik specific configurations
monitoring/docker-compose.yml - configuration file for monitoring stack
prometheus.yml - prometheus specific configs
promtail-config.yml - prometail specific configs
loki-config.yml - loki specific configs
.env - environment variables for the configurations

I setup the configuration for all 10 services that was earlier mentioned. A sample example of my Frontend configuration.

  frontend:
    build:
      context: ./frontend
      dockerfile: Dockerfile
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.frontend.rule=Host(`${DOMAIN}`)"
      - "traefik.http.routers.frontend.priority=1"
      - "traefik.http.routers.frontend.entrypoints=websecure"
      - "traefik.http.routers.frontend.tls=true"
      - "traefik.http.routers.frontend.tls.certresolver=myresolver"
      - "traefik.http.services.frontend.loadbalancer.server.port=3000"
    environment:
      - VITE_API_URL=https://${DOMAIN}/api
    networks:
      - app-network
    depends_on:
      - backend

Additonally, I ensured the the complete setup can be deployed by running docker compose up -d from the root directory. I did this by leveraging the extends feature and configuring all services to be on the same bridge network for easy service discovery and communication.

services:
  prometheus:
    extends:
      file: ./monitoring/docker-compose.yml
      service: prometheus

After some back and forth between documentations for traefik,Loki and Promtail trying to figure out routing and service discovery configurations, I was able to get the correct configurations and after running docker compose, all my service were up and running and working properly.

💭 Into the Cloud
Up to this point, I have been working on my local system. At this point, I had all my services runnign locally and was able to predict the compute power needed to run docker and the services, so I decided to move the application to a clpud server and complete the setup there.

First, I provisioned a virtual machine using Microsoft Azure and then I set up a simple deployment pipeline using Github Actions that will SSH into my VM, clone my repository (containing all my working configs) and then deploy the application using docker compose command.

On successful run of the pipeline, I had all my services up and running on my cloud server.

NB: If you are opting to do this manually, follow the follwing steps:

SSH into the VM
Install Docker
Clone the repository
cd into the project folder
run

touch acme.json
chmod 600 acme.json

The previous step creates a file that traefik and let's encrypt will use to store tls certificate details. This is crucial to be able to access application over HTTPS
run docker-compose up -d -build

Next, I accessed my DNS provider's website and added my vm's IP address to map to my domain name. This way, all requests to my domain name is forward to my server VM, and on hitting my server on port 80 or 443, the request is picked up by Traefik and re-routed to any of the services runninng on the VM depedning on the traefik configurations. At this point, the application is up and running and accessible via HTTPS, over the internet.

Traefik routing:

The application:

👁️ Monitoring
Now we have our application up and running. We should setup our monitoring stack.

Access prometheus and grafana UI using their specified paths.
Explore prometheus and confirm the service discovery.

Next, on grafana UI and added data sources, Loki and Prometheus. Then moved on to building dashboards to display metrics and logs. After a fair deal of time, PromQL queries and tweaks. I arrived on the following dashboards.

Logs:

Metrics:

Challenges

At this point, I had a good amount of headache, I called up Mary to remind her that I will not be maintaining or managing the applications and I took out time to discuss with her, the challenges I faced at different points of the setup hoping it will help her if she runs into a problem in the future.

1. Dockerizing the Frontend: I had successfully built the application and it was running locally, but the application was never accessible and therefore cannot be reached by other services in the network. I used the command docker exec -it -u root sh to access the container for troubleshooting. I also accessed the logs using docker logs. After some back and forth, I realized the issue was with the open ports, Vite by default runs on port 5173 but my container's open port was 3000. I had to perform a port forwarding internally to ensure the frontend service was accessible.

2. Traefik Routing & TLS Configurations
This was probably the most tasking and less fun part of the project.

3. Loki Version Issue
This was a minor issue, but it took a lot of back and forth with the documentation before I realized I was using a version that does not match with the configurations I had in my loki config file.

4. CORS Issue
This was not an issue I spent time with, as I was looking forward to it is a common one. But when I moved from localhost to the cloud, I forgot to update my .env and ran into this issue, so if you are ever changing DNS name, remember to make this updates.

Lessons

Managing multi-container applications with a single configuration file.
Networking containers and defining service dependencies.
Configuring Traefik for routing traffic, load balancing, and handling TLS certificates.
Understanding how reverse proxies improve scalability and security.
Visualizing container performance and debugging issues using dashboards.
Building Dashboards
Identifying and fixing container misconfigurations.
Diagnosing common issues like misaligned ports and CORS issues.
Leveraging monitoring and alerting to catch performance issues early.
When trying to troubleshoot, Spend ample time a lot with logs and error messages and always read the documentation!

Conclusion

Deploying Mary’s application was not just about putting code into production; it was a journey of learning, problem-solving, and implementing best practices to ensure scalability, reliability, and observability. By leveraging Docker Compose, Traefik, and a comprehensive monitoring stack, we transformed a simple project into a robust, cloud-deployed application capable of handling real-world demands.

This process highlights the importance of containerization, network orchestration, and monitoring in modern application deployment. From navigating configuration challenges to ensuring seamless service communication and building insightful dashboards, every step reinforced the value of preparation, testing, and documentation.

Now, Mary’s application is not only ready to support her growing business but also serves as a model for deploying scalable, well-monitored web applications in the cloud. Whether you're a developer building for a client or managing your own projects, this guide can help you tackle similar deployment challenges with confidence.

What’s next? Expand this setup with features like autoscaling, a more robust CI/CD process for automated deployments, or Kubernetes for more advanced container orchestration. The possibilities are endless!

Exploring Microsoft Azure AI Capabilities Using React, Github Actions, Azure Static Apps and Azure AI

Utibe — Fri, 14 Jun 2024 19:32:05 +0000

Lately, I've been dedicated to learning Microsoft Azure, and I've been using the Microsoft Learn platform extensively. I recently came across a challenge that requires utilizing Azure AI computer vision capabilities, specifically Azure AI Vision and Azure OpenAI cognitive services, to integrate image analysis and generation features into a product.

To complete this challenge, Microsoft Learn recommends that one should have experience using JavaScript and React or similar frameworks, experience using GitHub and Visual Studio Code and familiarity with REST APIs.

While my grasp of Javscript is quite solid and I know a little about React, I have not had any real development experience of it so my React code might look funny, bear with me.

By the way, If this challenge sounds interesting to you and you want to attempt it, but you are not confident of your frontend development skills, do not be discouraged, as I was not. In fact, my limited knowledge was even more motivation to challenge myself. You can go through the challenge here.
Like me, you might not get everything right, but do not hesitate to share your progress.

So, following the challenge requirements, I created a new Azure Static Web App resource and then built a CI/CD pipeline to deploy a React application on Azure, using Azure Static Web Apps service and GitHub Actions. This was my first time trying to automate a deployment pipeline and of course I struggled with this a bit. Next, I setup a react application and fixed up the GUI, spending a lot of time in the react docs and github copilot.

Up next, I had to implement the image analysis feature, after going back and forth with the documentation and some code tweaking, I arrived at this.

The code is quite straightforward, but just a little explanation:

Line 7 - 11:
Define useful variables.
Line 12 - 15:
Creates an array that holds the query parameters for analysis feedback that is required from the Azure AI engine. here, I need just the caption for the image, but there are many more options that can be requested.
Lines 17 - 26:
Declares an asynchronous function. This function takes in the image URL to be analysed as an argument, and then makes a request to the Azure AI engine with the image URL, the features, and the content type. Finally, the function returns the result gotten from the API call for processing and display on my user interface.

My version of the challenge has a fully functional Image analyses capability, but I was unable to complete the Image generation functionality because Azure OpenAI is not available in my region. To test the app, clone the repository and in the project directory run:

`npm start`

This will launch the react app.

The repository can be found here.
If you find it interesting, do not hesitate to leave a star and probably contribute to it. There are several other improvements that could be made, these inprovements can include...

Image Generation functionality using Open AI/Azure OpenAI
Better Security measures within the codebase
Error handling
Client side authentication
User Interface micro interactions
Add possible improvements and features to this README.

Any other ones that you can think of is welcomed, happy hacking!

Efficient GitHub Operations: Simplifying Repository Management using Github CLI

Utibe — Sun, 12 May 2024 08:12:24 +0000

Often, when we set up version control initial files for a project, we tend to log onto the Github website to create our repositories, clone, and push our projects. While this method works, it can be argued that it is not as efficient. We can manage our GitHub repositories, from creating the repo to maintaining the different versions, right from our terminal. In this article, we will go through the process of achieving this.

I will be attempting to create a repository for the Nextjs practice project I am currently working on and then push the files from my local machine to the the repository, and I will be doing all of it from my terminal.

All you need to acheive this is a basic knowledge of the command line interface, and of course a github account.

Step 1 - Install Github CLI

For Mac

brew install gh

For Linux (Ubuntu)

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key C99B11DEB97541F0 sudo apt-add-repository https://cli.github.com/packages sudo apt update sudo apt install gh

Step 2 - Authenticate with Github

Upon installation completion, you will need to authenticate with Github. Run the following command.

gh auth login

This will take you through series of authentication processes. You can choose to authenticate using a web browser or by pasting an authentication token. For any option you choose, just follow the prompts and you will be all set.
I will be using the web browser (for the last time).

To verify authentication status, run...

gh auth status

Step 3 - Create Repo

It's time to create the repo for our project. Do this using the command

gh repo create <repository-name> --public

Be sure to replace repository name with your choice repository name.
The public flag is usually required. It helps github decide if to make your repo public or private. Use --private id you want otherwise. There are other flags that you can use. Go through the documentaion to learn more about your options.

Step 3 - Clone the repository and add files locally

At this point, your repository is up on your github account. It can be accessed via the github url from the command output. We will have to clone the repository, and add our project files from our local machine. To do this, change directory to where you want to have your cloned repo and run the command.

gh repo clone <repository-url>

As usual, replace the repository-url with your repo url.

After cloning, if you had already started working locally ads in my case, move your project files to the cloned repo, if not, you can start working from your cloned repo.

Step 4 - Pushing files to github

Now we will have to push our initial project files to our remote github repository. But before then, let us quickly inspect our repo on github to be sure it was created and that it is empty.

Great!

Now run the follwoing commands to get your project files in.

git add . git commit -m "<commit message>" git push

If everything is okay and you have a successful push, your project files should be up on github and in the repository that you created earlier.

Access github via the browser to confirm you had a successful push.

Conclusion

**
At first, the process of setting up your working environment for seamless repository management using just the command line may seem intimidating. However, once you give it a try, you will realize that it is actually quite easy and straightforward. As you become more comfortable at using your terminal, you will begin to appreciate the efficiency of working mostly from the command line and the conveneince it gives your workflow.

There are many other powerful features and commands that the Github CLI offers. These features help us manage or repositories more efficiently. You can check a few other features that may fit your repository management needs on the Github CLI Documentation.

Happy Commits!

DEV Community: Utibe

Ingress Is Fading Away: But Where There Is A Will, There Is A Gateway API

The Will

The Gateway API

Conclusion

Building and Deploying An API With Python & Azure

Introduction

Project Overview

Setting Up The Project

Conclusion

Azure DevOps Explained: Services, Tools And Use Cases

Introduction

Azure DevOps Core Services

Core Services

Azure DevOps in Action - Using Azure DevOps

Why Azure DevOps?

Conclusion

Self-Hosted Runners in Azure Pipelines: The Why And The How

What is a Runner?

Why Use Self-Hosted Runners?

Step-by-Step Guide to Setting Up a Self-Hosted Agent

Final words

Advanced Kubernetes Deployment with GitOps: A Hands-On Guide To Terraform, Ansible, ArgoCD And Observability Tools

Table of Contents

Introduction

Overview

Infrastructure Provisioning

Application Management

Kubernetes Manifests

GitOps Workflow

Logging and Monitoring

Challenges and Lessons Learned

Challenges:

Lessons Learned:

Conclusion

Continous Integration And Continous Deployment Of A Full-Stack Docker-Compose Application

Project Requirements

Architectural Overview

Implementation Process

Challenges and Solutions

Results and Learnings

Conclusion

Automating the Deployment of a Docker-Powered Full-Stack Application with Terraform and Ansible

Introduction

Architecture Overview

Implementation Steps

Challenges Faced

Best Practices

Conclusion

Docker to the Rescue: Deploying React And FastAPI App With Monitoring

Table of Contents

Overview

The Process

Challenges

Lessons

Conclusion

Exploring Microsoft Azure AI Capabilities Using React, Github Actions, Azure Static Apps and Azure AI

npm start

Efficient GitHub Operations: Simplifying Repository Management using Github CLI

Step 1 - Install Github CLI

Step 2 - Authenticate with Github

Step 3 - Create Repo

Step 3 - Clone the repository and add files locally

Step 4 - Pushing files to github

Conclusion

`npm start`