DEV Community: Alfred Valderrama

CloudCycle - Set lifecycle for your cloud resources to avoid surprising costs

Alfred Valderrama — Sat, 25 May 2024 14:48:41 +0000

The Problem

I have recently forgot to Turn off / Terminate two ec2 instances running m5x.large and t3.medium that runs about 1 month and I just received a notification of my AWS monthly bill and shocked me!

At the first place I thought my account was hacked, But turns out that I just left two AWS EC2 Instances running. 🥲😔

The Solution (CloudCycle)

So, that's why I came up with a basic solution and share it. So now, whether I forgot to turn it off / terminate a running AWS Resources, I don't have to worry about it anymore, if I have properly set the desired lifecycle of my cloud resources.

I have created a lambda function which get's executed every 15 minutes to check if the supported resources are due to termination or not.

Now, if you or your team forgot to terminate cloud resources, the CloudCycle will do the job for you.

Tools & Language used

Golang - Since lambda function bills will be based on the duration of execution. At first, I developed this by using python and I have realized that I need to consider it's performance and execution time.
Terraform - Used only for deployment and examples.

Architecture

This setup will utilized the schedule expression of event bridge, In which event bridge get's executed every 15 minutes. In doing so, lambda function get validate if the supported resources is valid for termination.

But why termination? Instead of turning it off?

Of course there's a free tool available called Cloud-Custodian. But still, sometimes turning it off isn't enough and it can lead to lots of unused resources and can still occur minimal cost.

Sample Code for EC2 Instance Service

Below are the sample codes for EC2 Instance service.

package services

import (
    "context"
    "github.com/aws/aws-sdk-go-v2/service/ec2"
    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/service/ec2/types"
    "github.com/redopsbay/cloudcycle/internal"
    "github.com/redopsbay/cloudcycle/internal/schedule"
    "fmt"
)

type EC2 struct {
    InstanceId         string
    CloudCycle         string
    MarkForTermination bool
}

type EC2Instances struct {
    Instances []EC2
}

func GetEC2Instances(ctx context.Context, client *ec2.Client) ([]types.Reservation, error) {
    filters := []types.Filter{{
        Name:   aws.String("tag-key"),
        Values: []string{internal.TagKey},
    },
    }

    DescribeInputs := ec2.DescribeInstancesInput{
        Filters: filters,
    }

    instances, err := client.DescribeInstances(ctx, &DescribeInputs)

    if err != nil {
        panic(err)
        return []types.Reservation{}, err
    }

    return instances.Reservations, nil
}

func MarkInstancesForTermination(reservations []types.Reservation) (EC2Instances, error) {
    var instances EC2Instances

    for _, reservation := range reservations {
        for _, instance := range reservation.Instances {
            for _, tag := range instance.Tags {
                if *tag.Key == internal.TagKey {
                    Lifecycle, err := schedule.GetLifeCycle(instance.LaunchTime, *tag.Value)
                    if err != nil {
                        return EC2Instances{}, err
                    }

                    if schedule.ValidForTermination(Lifecycle) {
                        ec2instance := EC2{
                            InstanceId:         *instance.InstanceId,
                            CloudCycle:         *tag.Value,
                            MarkForTermination: true,
                        }
                        instances.Instances = append(instances.Instances, ec2instance)

                    } else {
                        ec2instance := EC2{
                            InstanceId:         *instance.InstanceId,
                            CloudCycle:         *tag.Value,
                            MarkForTermination: false,
                        }
                        instances.Instances = append(instances.Instances, ec2instance)
                    }
                }
            }
        }
    }
    return instances, nil
}

func StartEC2InstanceTermination(ctx context.Context, client *ec2.Client) error {
    var instanceIds []string

    reservations, err := GetEC2Instances(ctx, client)
    if err != nil {
        fmt.Println("Unable to get instances.")
        return err
    }

    instances, err := MarkInstancesForTermination(reservations)
    if err != nil {
        fmt.Println("Unable to mark instances for termination.")
        return err
    }

    for _, instance := range instances.Instances {
        if instance.MarkForTermination {
            instanceIds = append(instanceIds, instance.InstanceId)
            fmt.Printf("\nInstanceID: %s, ForTermination: %t, CloudCycle: %s\n",
                instance.InstanceId,
                instance.MarkForTermination,
                instance.CloudCycle)
        }
    }

    TerminatedOutput, err := client.TerminateInstances(ctx, &ec2.TerminateInstancesInput{
        InstanceIds: instanceIds,
    })

    for _, state := range TerminatedOutput.TerminatingInstances {
        if *state.CurrentState.Code == 0 {
            fmt.Printf("InstanceID: %s, State: Pending for Termination", *state.InstanceId)
        } else if *state.CurrentState.Code == 32 {
            fmt.Printf("InstanceID: %s, State: Shutting down", *state.InstanceId)
        } else if *state.CurrentState.Code == 48 {
            fmt.Printf("InstanceID: %s, State: Shutting down", *state.InstanceId)
        } else if *state.CurrentState.Code == 16 {
            fmt.Printf("InstanceID: %s, State: Still running", *state.InstanceId)
        } else if *state.CurrentState.Code == 64 {
            fmt.Printf("InstanceID: %s, State: Stopping", *state.InstanceId)
        } else if *state.CurrentState.Code == 80 {
            fmt.Printf("InstanceID: %s, State: Stopped", *state.InstanceId)
        } else {
            fmt.Printf("InstanceID: %s, State: Unknown", *state.InstanceId)
        }
    }

    return nil

}

Objective

My objective with CloudCycle is to automatically cleanup supported resources based on the specified duration or lifecycle through resource tagging, And to support the commonly used resources that causes AWS Bills to grow even though the cloud resources is not needed anymore.

No more story telling!

For complete documentation and project link, you can proceed directly to my GitHub repo below.

https://github.com/redopsbay/cloudcycle

This repo is open for contributors!!! Some documents and cloud resources are currently WORK-IN-PROGRESS

Usage

Just specify that tag and set your desired lifecycle for supported resources with CloudCycle Key. Below are the supported duration.

Suffixes	Detail	Sample Value
`m`	Minutes	`60m`
`h`	Hours	`2h`
`d`	Days	`7d`

How does it works?

CloudCycle will get all the supported resources with a tagged key CloudCycle and it will simply compare the current time vs launch time of the supported resources with the specified key/value pair resource tag if the supported resources are valid for termination.

Below are the sample terraform code.

Specify ec2 lifecycle by 24 hours from it's launch date.

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # Canonical
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"

  tags = {
    CloudCycle = "1d" // This ec2 instance will be terminated within 24 hours from it's launch date.
  }
}

Sample Terraform Deployment Usage

For deployment, you can refer to the github repo Deployment Page

Benefit's

Sometimes it's better to let go than stay strong. Leaving up unused resources will incur costs.

And lastly, No nightmare's, No poverty! 😂🤣

Reference

https://github.com/redopsbay/cloudcycle

Observability with OpenTelemetry

Alfred Valderrama — Sat, 23 Dec 2023 01:47:39 +0000

As the continuous growth and adoption of cloud native and distributed systems due to it's flexibility and high availability, It is also becoming a continuous increase of complexities, specially for IT Teams to properly operate and monitor these distributed systems.

But what the hell is observability? Why is it important, and How it can actually help organizations?

What is Observability?

Observability is the ability to measure the internal states of a system by examining its outputs. A system is considered “observable” if the current state can be estimated by only using information from outputs, namely sensor data.

You simply put it as a KPI. You'll never know if the current state is abnormal or stable if you don't have the historic data or a state that can be estimated based on it's outputs (Performance).

For example, How can you tell if your employee is performing well without him/her reporting his/her daily activities or tasks? Can you tell if your employee is working well just by looking at him/her work? Nah,

The same goes to your applications, You cannot tell if your application is properly performing well just by looking at the cpu / memory utilization without knowing it's internal state.

But how can you tell to your application to become observable to report and allow you to validate it's Key Performance Indicator's (KPI)?

Instrumentation

This is where instrumentation comes in, Instrumentation is a method or modifying your source code to give you an output to validate if your application is currently performing well.

But how can we instrument it?

OpenTelemetry

OpenTelemetry allows us to achieve our goal to tell our application to give us the right output to validate it's performance.

OpenTelemetry or OTel is an open source observability framework made up of a collection of tools, APIs, and SDKs.

OTel enables IT teams to instrument, generate, collect, and export telemetry data for analysis and to understand software performance and behavior.

Back to Basic

Now, we have a basic picture on how observability works and how instrumentation will bring something to the table. For our example, we will be using the ff. tech:

Signoz (Open Source Observability Tool)
Opentelemetry (Open Source Telemetry Instrumentation Framework)
Golang
Gin Gonic (REST API Framework for Go)

Tracing with Golang

First, Imagining we have a microservice application that contains, product-service, reviews-service, ratings-service. Each one of them are integrated or calling each other to get needed information requested by rest client.

Let's assume that we already build our basic rest application, since it will become a huge discussion if we will start from scratch.

.
├── Makefile
├── README.md
├── docker-compose.yaml
├── k8s
├── load-gen
│   ├── Dockerfile
│   ├── go.mod
│   ├── main.go
│   └── seed
│       ├── products.json
│       ├── ratings.json
│       └── reviews.json
├── product-service
│   ├── Dockerfile
│   ├── Makefile
│   ├── README.md
│   ├── controller
│   │   ├── CheckEnv.go
│   │   ├── DefaultResponseController.go
│   │   ├── FeatureProductController.go
│   │   ├── ProductController.go
│   │   ├── RatingsController.go
│   │   ├── ReviewsController.go
│   │   └── UserController.go
│   ├── crypt
│   │   └── passwdhash.go
│   ├── db
│   │   ├── database.go
│   │   └── setup.go
│   ├── go.mod
│   ├── go.sum
│   ├── logging
│   │   └── logging.go
│   ├── main.go
│   ├── models
│   │   └── models.go
│   ├── routes
│   │   └── routes.go
│   └── tracer
│       └── tracer.go
├── ratings-service
│   ├── Dockerfile
│   ├── Makefile
│   ├── controller
│   │   ├── RatingsController.go
│   │   └── RestAPIResponseController.go
│   ├── db
│   │   ├── database.go
│   │   └── setup.go
│   ├── docker-compose.yaml
│   ├── go.mod
│   ├── go.sum
│   ├── logging
│   │   └── logging.go
│   ├── main.go
│   ├── models
│   │   └── model.go
│   ├── routes
│   │   └── routes.go
│   └── tracer
│       └── tracer.go
└── reviews-service
    ├── Dockerfile
    ├── Makefile
    ├── controller
    │   ├── RestAPIResponseController.go
    │   └── ReviewsController.go
    ├── db
    │   ├── database.go
    │   └── setup.go
    ├── docker-compose.yaml
    ├── go.mod
    ├── go.sum
    ├── logging
    │   └── logging.go
    ├── main.go
    ├── models
    │   └── model.go
    ├── routes
    │   └── routes.go
    └── tracer
        └── tracer.go

25 directories, 57 files

Now, Let's look with an example by creating tracer.go under product-service. This file will contain the initialization of our global trace. That contains, trace provider, OTEL Endpoint and our Service Name (product-service).

package tracer 

import (
    "context"
    "log"
    "os"
    "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
    "google.golang.org/grpc/credentials"
    "go.opentelemetry.io/otel/exporters/otlp/otlptrace"
    "strings"
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/propagation"
    "go.opentelemetry.io/otel/sdk/resource"
    "go.opentelemetry.io/otel/attribute"
    sdktrace "go.opentelemetry.io/otel/sdk/trace"
)

var (
    collectorURL = os.Getenv("OTEL_EXPORTER_OTLP_ENDPOINT")
    insecure     = os.Getenv("INSECURE_MODE")
    ServiceName  = os.Getenv("SERVICE_NAME")
    Tracer = otel.Tracer("gin-server")
)

func InitTracer() (*sdktrace.TracerProvider, error) {

    var secureOption otlptracegrpc.Option

    if strings.ToLower(insecure) == "false" || insecure == "0" || strings.ToLower(insecure) == "f" {
        secureOption = otlptracegrpc.WithTLSCredentials(credentials.NewClientTLSFromCert(nil, ""))
    } else {
        secureOption = otlptracegrpc.WithInsecure()
    }

    exporter, err := otlptrace.New(
        context.Background(),
        otlptracegrpc.NewClient(
            secureOption,
            otlptracegrpc.WithEndpoint(collectorURL),
        ),
    )

    if err != nil {
        log.Fatalf("Failed to create exporter: %v", err)
    }

    resources, err := resource.New(
        context.Background(),
        resource.WithAttributes(
            attribute.String("service.name", ServiceName),
            attribute.String("library.language", "go"),
        ),
    )

    traceProvider := sdktrace.NewTracerProvider(
        sdktrace.WithSampler(sdktrace.AlwaysSample()),
        sdktrace.WithBatcher(exporter),
        sdktrace.WithResource(resources),
    )
    otel.SetTracerProvider(traceProvider)
    otel.SetTextMapPropagator(propagation.NewCompositeTextMapPropagator(propagation.TraceContext{}, propagation.Baggage{}))
    return traceProvider, nil
}

Injecting traces with Contexts

We have provided the tracer.go, Now let's start by injecting trace from our Gin Context from our ProductController.go:

func GetProducts(c *gin.Context) {
    dbInstance, err := db.SetupDatabase()

        // Inject Gin Context
    otel.GetTextMapPropagator().Inject(c.Request.Context(), propagation.HeaderCarrier(c.Request.Header))

        // Start Tracing

    _, span := tracer.Tracer.Start(c.Request.Context(), "GetProducts")

        // End Span when function ends,
    defer span.End()


    if err != nil {
        ServerError(c)
    }

    sql := db.MySQLDB{DBhandler: dbInstance}

    products, err := sql.GetProducts(c)
    if err != nil {
        ServerError(c)
    }

    c.JSON(http.StatusOK, products)
}

Next, lets initialize our trace on our main.go file:

package main

import (
    "github.com/gin-gonic/gin"
    "productservice/routes"
    "productservice/tracer"
    "go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin"
    "log"
    "context"
)

func main() {

    tp, err := tracer.InitTracer()
    if err != nil {
        log.Fatal(err)
    }
    defer func() {
        if err := tp.Shutdown(context.Background()); err != nil {
            log.Printf("Error shutting down tracer provider: %v", err)
        }
    }()


    router := gin.New()
    router.Use(otelgin.Middleware(tracer.ServiceName))
    routes.SetupRoute(router)
    router.Run(":8000")
}

Wrap

We don't have to go deeper on how to implement observability, Since, there's tons of ways to implement it and different kinds of use cases. But one thing to note is that, Do not ever Operate an application on PRODUCTION without knowing it's internal state. 👌😁

References

GitHub Repo: https://github.com/redopsbay/sample-apps/tree/master/Observability/Opentelemetry

Production grade CI/CD Pipeline with GitLab and JIRA powered by mydevopsteam.io sorcery

Alfred Valderrama — Thu, 18 Aug 2022 14:29:05 +0000

GitLab Project Setup
JIRA Setup
Setup GitLab runner on Kubernetes
JIRA issue integration on GitLab.
Setup Traefik Proxy (optional) for edge routing experience
Containerized the sample django application
Populate containerized application to helm chart
GitLab CI/CD Pipeline setup via .gitlab-ci.yaml
Demonstration

Hey there again! In this post. I will demonstrate on how you can setup a production grade CI/CD pipeline for your production workloads with mydevopsteam.io sorcery. 😅😅😅

Overview

Most of the time, organizations struggles to implement CI/CD pipeline. Specially on a critical systems or infrastructures. Some organizations already implemented it and some organizations are not familiar with it. But most of it fails. That's why MyDevOpsTeam was created to help SME's to properly implement DevOps methodologies in able for them to stay focus on the business instead of the technicalities. In this demo we will explore how CI/CD pipeline help newbies learn how to basically implement it.

Prerequisites

GitLab Account
Atlassian Account with JIRA
Existing Kubernetes Cluster
kubectl (Kubernetes Client)

Note: We will use only Minikube as a kubernetes cluster. Because I've forgot to terminate my EKS Cluster running an m5a.2xlarge worker nodes after my demonstration last June 2022 🤣. I just terminated it yesterday after I notice something isn't right before going to sleep. 🤣 🤣 🤣

GitLab Project Setup

Overview

GitLab is one of the available devops platform with free and premium features. It offers a lot of features and lots of integrations.

and enter the necessary details for your project.

JIRA Setup

Overview

JIRA is one of the leading Project Management and Bug tracking tools. It also has a free and premium features in able for you to create and track ongoing Bug/Issues. Also, The most common use cases of JIRA is the ability to integrate it to a CI/CD pipeline for automatic transitioning once the bug has been fixed and deployed to production environment.

Assuming that you have already an account on JIRA. Now it's time to create your first JIRA project.

And select Bug Tracking.

Then enter your project details.

Setup GitLab runner on Kubernetes

There is a few options to setup a Gitlab runner.

Run the Gitlab runner on single linux instances.
Run the Gitlab runner on a docker container via docker API
Run the Gitlab runner as a kubernetes pod.

Advantage

Running Gitlab runner on single linux instances let's you easily manage your gitlab runner and quick setup.

Running your gitlab runner as a docker container let's you dynamically run gitlab job without worrying about software installation. And the container will be automatically deleted after job run.

Running your gitlab runner as a kubernetes pod let's you run a complete dynamic jobs like run as you go. And the pod will automatically be deleted after the pipeline execution.

Disadvantage

It's problematic to run a Gitlab runner on an ec2 or single linux instance due to a limitations like software installations during job run. And it might cause your instance to life or death scenario. 🤣

It's also problematic to run a Gitlab runner on a docker container. Since, Docker will be running also in a single instance. So what if your job requires a high memory/cpu capacity? And you have a multiple jobs running simultaneously?

Key Notes: My recommended option is always implement a dynamic pipeline/infrastructure etc.. So you can just plug/play your solutions in any platform just like a template. And you will not worry about vendor lock-in sh*t.

Installation of GitLab runner via Helm.

Assuming you have a minikube or any kubernetes cluster running. First, create values.yaml file.

Note: Make sure to get the gitlab runner registration token residing on the settings of your project.

# The GitLab Server URL (with protocol) that want to register the runner against
# ref: https://docs.gitlab.com/runner/commands/index.html#gitlab-runner-register
#
gitlabUrl: https://gitlab.com

# The Registration Token for adding new runners to the GitLab Server. This must
# be retrieved from your GitLab instance.
# ref: https://docs.gitlab.com/ee/ci/runners/index.html
#
runnerRegistrationToken: "<your-gitlab-registration-token>"

# For RBAC support:
rbac:
    create: true

# Run all containers with the privileged flag enabled
# This will allow the docker:dind image to run if you need to run Docker
# commands. Please read the docs before turning this on:
# ref: https://docs.gitlab.com/runner/executors/kubernetes.html#using-dockerdind
runners:
    privileged: true

Add the helm repository via:

helm repo add gitlab https://charts.gitlab.io
helm repo update

Installation

helm upgrade --install gitlab-runner gitlab/gitlab-runner \
    -n gitlab --create-namespace \
    -f ./values.yaml --version 0.43.1

After a few seconds, Gitlab runner should be available at your cluster and Gitlab Project.

JIRA issue integration on GitLab

Integration with JIRA and GitLab is easy. But for a long run like expanding your project. It would be a problematic. But for this one, We will only perform a quick way to integrate GitLab and JIRA software.

Generate JIRA API Token

Proceed to https://id.atlassian.com/manage-profile/security/api-tokens and generate your JIRA token.

Now, you have your API token. Proceed to your GitLab Project -> Settings -> Integrations -> JIRA. Then enter the necessary details.

So for now, We can automatically transition reported bug issues or tickets assigned to us via commit message. But let's test it first. So we can assure it's actually working.

Open a sample JIRA issue

Open a sample JIRA issue on your JIRA software. To simulate if automatic transition is working.

Next, Update the issue status from 'To Do' -> 'InProgress'.

Next, Try to edit some files on your repository and try to commit the changes. Also, Don't forget to get the issue key in reference for your commit message. Refer to this guide on transitioning a JIRA issue with GitLab JIRA issue transitioning

Go back to your JIRA Software and check out the previously opened issue. As you can see. The issue is automatically transitioned from 'InProgress' to 'Done'.

Why automatic ticket transitioning is important?

It keeps your project more manageable.
Clean issue tracking.
Allow you to easily generate a release notes and associate each issues and commits to your release notes or CHANGELOG.md files after production deployment.

Setup Traefik Proxy (optional) for edge routing experience

Overview

Traefik is an open-source Edge Router that makes publishing your services a fun and easy experience. It receives requests on behalf of your system and finds out which components are responsible for handling them.

Install Traefik Proxy via Helm

First, Add the traefik repository via:

helm repo add traefik https://helm.traefik.io/traefik
helm repo update

Next, Create values.yaml file. If you want to know all the available parameters in values.yaml you can use. helm show values traefik/traefik command.

values.yaml

service:
  enabled: true
  type: LoadBalancer
  externalIPs:
    - <your-server-ip> # if you are using minikube on a single ec2 instance.

podDisruptionBudget:
  enabled: true
  maxUnavailable: 0
  #maxUnavailable: 33%
  minAvailable: 1
  #minAvailable: 25%

additionalArguments:
  - "--log.level=DEBUG"
  - "--accesslog=true"
  - "--accesslog.format=json"
  - "--tracing.jaeger=true"
  - "--tracing.jaeger.traceContextHeaderName=x-trace-id"

tracing:
  serviceName: traefik
  jaeger:
    gen128Bit: true
    samplingParam: 0
    traceContextHeaderName: x-trace-id

autoscaling:
  enabled: true
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 60
  - type: Resource
    resource:
      name: memory
      targetAverageUtilization: 60

Setup Traefik Proxy via Helm via:

helm upgrade --install traefik traefik/traefik \
    --namespace=traefik --create-namespace  \
    -f ./values.yaml --version 10.24.0

After a few seconds, You can now see traefik running on your cluster.

Next, We need to enable traefik dashboard via traefik-dashboard.yaml:

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: dashboard
  namespace: traefik
spec:
  entryPoints:
    - web
    - websecure
  routes:
    - match: Host(`traefik.gitops.codes`) && (PathPrefix(`/dashboard`) || PathPrefix(`/api`))
      kind: Rule
      services:
        - name: api@internal
          kind: TraefikService

Then apply it:

kubectl apply -f ./traefik-dashboard.yaml

Then you can now visit your traefik dashboard via: http://traefik.gitops.codes/dashboard/#/

Containerized the sample django application

Next, we already have a sample Django Python application. But you can prepare yours if you want. In this case, We will containerized a sample django application. So let's start modifying the settings.py to make the credentials able to pass as environment variables.

"""
Django settings for ecommerce project.

Generated by 'django-admin startproject' using Django 3.0.5.

For more information on this file, see
https://docs.djangoproject.com/en/3.0/topics/settings/

For the full list of settings and their values, see
https://docs.djangoproject.com/en/3.0/ref/settings/
"""

import os

# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
TEMPLATE_DIR = os.path.join(BASE_DIR,'templates')
STATIC_DIR=os.path.join(BASE_DIR,'static')


# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/3.0/howto/deployment/checklist/

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = '#vw(03o=(9kbvg!&2d5i!2$_58x@_-3l4wujpow6(ym37jxnza'

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True

ALLOWED_HOSTS = ['*']


# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'ecom',
    'widget_tweaks',
    'mathfilters'

]

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',

]

ROOT_URLCONF = 'ecommerce.urls'

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [TEMPLATE_DIR,],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

WSGI_APPLICATION = 'ecommerce.wsgi.application'


# Database
# https://docs.djangoproject.com/en/3.0/ref/settings/#databases

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': os.environ['DATABASE_NAME'],
        'USER': os.environ['DATABASE_USER'],
        'PASSWORD': os.environ['DATABASE_PASSWORD'],
        'HOST': os.environ['DATABASE_HOST'],
        'PORT': os.environ['DATABASE_PORT']
    }
}

# Password validation
# https://docs.djangoproject.com/en/3.0/ref/settings/#auth-password-validators

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]


# Internationalization
# https://docs.djangoproject.com/en/3.0/topics/i18n/

LANGUAGE_CODE = 'en-us'

TIME_ZONE = 'UTC'

USE_I18N = True

USE_L10N = True

USE_TZ = True


# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/3.0/howto/static-files/

STATIC_URL = '/static/'

STATICFILES_DIRS=[STATIC_DIR,]

MEDIA_ROOT=os.path.join(BASE_DIR,'static')



LOGIN_REDIRECT_URL='/afterlogin'

#for contact us give your gmail id and password
EMAIL_BACKEND ='django.core.mail.backends.smtp.EmailBackend'
EMAIL_HOST = ''
EMAIL_USE_TLS = True
EMAIL_PORT = 465
EMAIL_HOST_USER = 'from@gmail.com' # this email will be used to send emails
EMAIL_HOST_PASSWORD = 'xyz' # host email password required
# now sign in with your host gmail account in your browser
# open following link and turn it ON
# https://myaccount.google.com/lesssecureapps
# otherwise you will get SMTPAuthenticationError at /contactus
# this process is required because google blocks apps authentication by default
EMAIL_RECEIVING_USER = ['to@gmail.com'] # email on which you will receive messages sent from website

Next, Save it. And create a new file Dockerfile.

FROM python:3.8.13-buster

WORKDIR /opt/ecommerce-app

ADD ./ /opt/
ADD ./docker-entrypoint.sh /

# install mysqlclient
RUN apt update -y \
    && apt install libmariadb-dev -y

# Install pipenv and required python packages

RUN pip3 install pipenv && \
    pipenv install && chmod +x /docker-entrypoint.sh

EXPOSE 8000/tcp
EXPOSE 8000/udp

ENTRYPOINT ["/docker-entrypoint.sh"]

Finally, Create a docker-entrypoint.sh:

#!/bin/bash

pipenv run python3 manage.py runserver 0.0.0.0:8000

Save it. Then start building the application via docker:

docker build -t <your-container-registry-endpoint> .

Note: I assume that you have a basic familiarity on Django Application Structure. So we can make the story short. 😁😁

Populate containerized application to helm chart

Next, We will populate our application to helm chart. First, Create a helm chart via:

helm create ecommerce-app

Next, Modify the helm chart. Let's start with the templates/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "ecommerce-app.fullname" . }}
  labels:
    {{- include "ecommerce-app.labels" . | nindent 4 }}
spec:
  {{- if not .Values.autoscaling.enabled }}
  replicas: {{ .Values.replicaCount }}
  {{- end }}
  selector:
    matchLabels:
      {{- include "ecommerce-app.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      {{- with .Values.podAnnotations }}
      annotations:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      labels:
        {{- include "ecommerce-app.selectorLabels" . | nindent 8 }}
    spec:
      imagePullSecrets:
        - name: {{ include "ecommerce-app.fullname" . }}
      serviceAccountName: {{ include "ecommerce-app.serviceAccountName" . }}
      securityContext:
        {{- toYaml .Values.podSecurityContext | nindent 8 }}
      containers:
        - name: {{ .Chart.Name }}
          securityContext:
            {{- toYaml .Values.securityContext | nindent 12 }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          env:
            {{- toYaml .Values.deployment.env | nindent 12}}
          {{- if .Values.persistentVolume.enabled }}    
          volumeMounts:
            - name: {{ include "ecommerce-app.fullname" . }}-uploads
              mountPath: /opt/ecommerce-app/static/product_image
          {{- end }}
          ports:
            - name: http
              containerPort: {{ .Values.deployment.containerPort }}
              protocol: TCP
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
      {{- if .Values.persistentVolume.enabled }}
      volumes:
        - name: {{ include "ecommerce-app.fullname" . }}-uploads
          persistentVolumeClaim:
            claimName: {{ include "ecommerce-app.fullname" . }}-pvc
      {{- end }}
      {{- with .Values.nodeSelector }}
      nodeSelector:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with .Values.affinity }}
      affinity:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with .Values.tolerations }}
      tolerations:
        {{- toYaml . | nindent 8 }}
      {{- end }}

Next, Create a PersistentVolume and PersistentVolumeClaim so our uploaded files will not lost if the pod get's reprovisioned.
pv.yaml:

{{- if .Values.persistentVolume.enabled -}}
{{- $fullName := include "ecommerce-app.fullname" . -}}
apiVersion: v1
kind: PersistentVolume
metadata:
  name: {{ $fullName }}
  labels:
    {{- include "ecommerce-app.labels" . | nindent 4 }}
spec:
  capacity:
    storage: {{ .Values.persistentVolume.storageSize }}
  volumeMode: {{ .Values.volumeMode }}
  {{- with .Values.persistentVolume.accessModes }}
  accessModes:
    {{- toYaml . | nindent 4 }}
  {{- end }}
  persistentVolumeReclaimPolicy: {{ .Values.persistentVolume.persistentVolumeReclaimPolicy }}
  storageClassName: {{ .Values.persistentVolume.storageClassName }}
  hostPath:
    path: {{ .Values.persistentVolume.hostPath.path }}
{{- end }}

pvc.yaml

{{- if .Values.persistentVolume.enabled -}}
{{- $fullName := include "ecommerce-app.fullname" . -}}
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: {{ $fullName  }}-pvc
  labels:
    {{- include "ecommerce-app.labels" . | nindent 4 }}
spec:
  {{- with .Values.persistentVolume.accessModes }}
  accessModes:
    {{- toYaml . | nindent 4 }}
  {{- end }}
  storageClassName: {{ .Values.persistentVolume.storageClassName }}
  resources:
    requests:
      storage: {{ .Values.persistentVolume.storageSize }}
{{- end }}

Save it. Then create a createuser-job.yaml and migratedata-job.yaml to automatically seed data to MySQL database during deployment and also to create django admin user.

createuser-job.yaml

{{- if .Values.createUser.enabled -}}
{{- $superuser_username := .Values.createUser.username -}}
{{- $superuser_password := .Values.createUser.password -}}
{{- $superuser_email := .Values.createUser.userEmail -}}
apiVersion: batch/v1
kind: Job
metadata:
  name: {{ include "ecommerce-app.fullname" . }}-create-superuser-job
spec:
  backoffLimit: 1
  ttlSecondsAfterFinished: 10
  template:
    metadata:
      labels:
        identifier: ""
    spec:
      imagePullSecrets:
        - name: {{ include "ecommerce-app.fullname" . }}
      containers:
        - name: data-migration
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          command: ["/bin/sh","-c"]
          args:
            - > 
              /bin/bash <<EOF
                export DJANGO_SUPERUSER_USERNAME="{{ $superuser_username }}"
                export DJANGO_SUPERUSER_PASSWORD="{{ $superuser_password }}"
                pipenv run python3 manage.py createsuperuser --noinput --email "{{ $superuser_email }}"
              EOF
          env:
            {{- toYaml .Values.deployment.env | nindent 12 }}
      restartPolicy: Never
{{- end }}

migratedata-job.yaml

{{- if .Values.migrateData.enabled -}}
apiVersion: batch/v1
kind: Job
metadata:
  name: {{ include "ecommerce-app.fullname" . }}
spec:
  backoffLimit: 2
  ttlSecondsAfterFinished: 10
  template:
    metadata:
      labels:
        identifier: ""
    spec:
      imagePullSecrets:
        - name: {{ include "ecommerce-app.fullname" . }}
      containers:
        - name: data-migration
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          command: ["/bin/sh","-c"]
          args:
            - > 
              /bin/bash <<EOF
                pipenv run python3 manage.py makemigrations
                pipenv run python3 manage.py migrate
              EOF
          env:
            {{- toYaml .Values.deployment.env | nindent 12 }}
{{- end }}

Next, Create ecommerce-app-ingressroute.yaml inside the templates folder on your helm chart.

{{- $targetHost := .Values.traefik.host -}}
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: {{ include "ecommerce-app.fullname" . }}
spec:
  {{- with .Values.traefik.entrypoints }}
  entryPoints:
    {{- toYaml . | nindent 4 }}
  {{- end }}
  routes:
  - match: Host(`{{ $targetHost }}`)
    kind: Rule
    services:
    - name: {{ include "ecommerce-app.fullname" . }}
      port: {{ .Values.service.port }}

Finally, the values.yaml file that will hold all of our values.

# Default values for ecommerce-app.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 2

image:
  repository: registry.gitlab.com/redopsbay/my-devops-journey
  pullPolicy: Always
  # Overrides the image tag whose default is the chart appVersion.
  tag: "latest"

dockerSecret: ""
nameOverride: ""
fullnameOverride: ""

deployment:
  env:
  - name: DATABASE_NAME
    value: "ecommerce-app"
  - name: DATABASE_USER
    value: "ecommerce"
  - name: DATABASE_PASSWORD
    value: "ecommerce-secure-password"
  - name: DATABASE_HOST
    value: "mysql-server.mysql.svc.cluster.local"
  - name: DATABASE_PORT
    value: "3306"
  containerPort: 8000

traefik:
  host: ecommerce-app.gitops.codes
  entrypoints:
    - web
    - websecure

serviceAccount:
  # Specifies whether a service account should be created
  create: false
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: ""

podAnnotations: {}

podSecurityContext: {}
  # fsGroup: 2000

securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false
  className: "nginx"
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: ecommerce-app.gitops.codes
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  #limits:
  #  cpu: 200m
  #  memory: 200Mi
  #requests:
  #  cpu: 150m
  #  memory: 150Mi

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 100
  targetCPUUtilizationPercentage: 50
  # targetMemoryUtilizationPercentage: 80

nodeSelector: {}

tolerations: []

affinity: {}

# Specify values for Persistent Volume
persistentVolume:
  # Specify whether persistent volume should be enabled
  enabled: true
  # Specify storageClassName
  storageClassName: "ecommerce-app"
  # Specify volumeMode defaults to Filesystem
  volumeMode: Filesystem
  # Specify the accessModes for this pv
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageSize: 5Gi
  hostPath:
    path: /data/ecommerce-app/

createUser:
  enabled: false
  userEmail: "alfredvalderrama@gitops.codes"
  username: "admin"
  password: "admin"

migrateData:
  enabled: true

That's it. Your container application is now able to run on kubernetes!!!

GitLab CI/CD Pipeline setup via .gitlab-ci.yml

We will now start setting up our pipeline. First, We have to determine what stages and how many environments our application will go through before going to the live production environment. As per common standard. There is 3 environments available which is:

Common environment workloads:

development
staging
production

Let's now create a .gitlab-ci.yml file. I will enter the complete source code file to make the story short. Refer to comments.

# Required Variables to properly setup each environment
variables:
  TARGET_IMAGE: "registry.gitlab.com/redopsbay/my-devops-journey"
  RAW_KUBECONFIG: ""
  DEV_HOST: "ecommerce-app-dev.gitops.codes"
  QA_HOST: "ecommerce-app-qa.gitops.codes"
  PROD_HOST: "ecommerce-app-qa.gitops.codes"
  TARGET_IMAGE_TAG: "latest"
  CHART: "${CI_PROJECT_DIR}/.helm/ecommerce-app"
  HOST: ""
  TARGET_ENV: ""
  USER_EMAIL: ""
  DJANGO_USERNAME: ""
  DJANGO_PASSWORD: ""
  DJANGODB_SEED: ""

## My Default Container tool containing helm and kubectl binaries etc.

default:
  image: alfredvalderrama/container-tools:latest

stages:
  - bootstrap
  - install
  - build
  - dev
  - staging
  - production
  - deploy
  - linter

# Set the KUBECONFIG based on commit branch / environment etc.

'setEnv':
  stage: bootstrap
  rules:
    - changes:
      - ".gitlab-ci.yml"
      when: never
  before_script:
    - |
      case $CI_COMMIT_BRANCH in
        "dev")
          RAW_KUBECONFIG=${DEV_KUBECONFIG}
          TARGET_ENV="dev"
          export RELEASE_CYCLE="alpha"
          HOST="${DEV_HOST}"
        ;;
        "staging")
          RAW_KUBECONFIG=${QA_KUBECONFIG}
          TARGET_ENV="prod"
          export RELEASE_CYCLE="beta"
          HOST="${QA_HOST}"
        ;;
        "master" )
          RAW_KUBECONFIG=${PROD_KUBECONFIG}
          TARGET_ENV="prod"
          HOST="${PROD_HOST}"
          export RELEASE_CYCLE="stable"
        ;;
      esac

    - export TARGET_IMAGE_TAG="${RELEASE_CYCLE}-$(cat release.txt)"
    - mkdir -p ~/.kube || echo "Nothing to create..."
    - echo ${RAW_KUBECONFIG} | base64 -d > ~/.kube/config
    - chmod 0600 ~/.kube/config
  script:
    - echo "[bootstrap] Setting up required environment variables...."

## Build image only for installation

'Build Image For Provisioning':
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  stage: install
  rules:
    - changes:
        - ".gitlab-ci.yml"
      when: never
    - if: $PROVISION == 'true'
      when: manual
  tags:
    - dev
    - staging
    - sandbox
    - prod
  extends:
    - 'setEnv'
  script:
    - mkdir -p /kaniko/.docker
    - |
       cat << EOF > /kaniko/.docker/config.json
        {
          "auths": {
            "registry.gitlab.com": {
              "username": "${REGISTRY_USER}",
              "password": "${REGISTRY_PASSWORD}"
            }
          }
        }
        EOF
    - |
        /kaniko/executor \
          --context "${CI_PROJECT_DIR}/" \
          --dockerfile "${CI_PROJECT_DIR}/Dockerfile" \
          --destination "${TARGET_IMAGE}:${TARGET_IMAGE_TAG}" \
          --cache=true

## Provision the environment. Since you provision the environment for the first time.
# Django needs to migrate the data and also create a superuser/administrator account.

'Provision':
  image: 
    name: alfredvalderrama/container-tools:latest
  stage: install
  rules:
    - changes:
        - ".gitlab-ci.yml"
      when: never
    - if: $PROVISION == 'true'
      when: manual
  needs:
    - "Build Image For Provisioning"
  tags:
    - dev
    - staging
    - sandbox
    - prod
  extends:
    - 'setEnv'
  script:
    - |
      helm upgrade --install ecommerce-app-${TARGET_ENV} ${CHART} \
            -n ${TARGET_ENV} \
            --create-namespace \
            --set createUser.enabled="true" \
            --set createUser.userEmail="${USER_EMAIL}" \
            --set createUser.username="${DJANGO_USERNAME}" \
            --set createUser.password="${DJANGO_PASSWORD}" \
            --set migrateData.enabled="${DJANGODB_SEED}" \
            --set traefik.host="${HOST}" \
            --set dockerSecret="${REGISTRY_CREDENTIAL}" \
            --set deployment.database_name="${DJANGO_DB}" \
            --set deployment.database_user="${DJANGO_DBUSER}" \
            --set deployment.database_password="${DJANGO_DBPASS}" \
            --set deployment.database_host="${DJANGO_DBHOST}" \
            --set image.tag="${TARGET_IMAGE_TAG}"

## Execute this job to validate a valid helm chart.

'Linter':
  image: 
    name: alfredvalderrama/container-tools:latest
  stage: linter
  rules:
    - changes:
        - ".gitlab-ci.yml"
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" && $PROVISION != 'true'
      when: always
  extends:
    - 'setEnv'
  tags:
    - dev
    - staging
    - sandbox
    - prod
  script:
    - echo "[$CI_COMMIT_BRANCH] Displaying incoming changes when creating a djando user..."
    - |
      helm upgrade --install ecommerce-app-${TARGET_ENV} ${CHART} \
            -n ${TARGET_ENV} \
            --create-namespace \
            --set createUser.enabled="true" \
            --set createUser.userEmail="${USER_EMAIL}" \
            --set createUser.username="${DJANGO_USERNAME}" \
            --set createUser.password="${DJANGO_PASSWORD}" \
            --set migrateData.enabled="${DJANGODB_SEED}" \
            --set traefik.host="${HOST}" \
            --set dockerSecret="${REGISTRY_CREDENTIAL}" \
            --set deployment.database_name="${DJANGO_DB}" \
            --set deployment.database_user="${DJANGO_DBUSER}" \
            --set deployment.database_password="${DJANGO_DBPASS}" \
            --set image.tag="${TARGET_IMAGE_TAG}" \
            --set deployment.database_host="${DJANGO_DBHOST}" --dry-run


    - echo "[$CI_COMMIT_BRANCH] Displaying incoming changes for normal deployment...."
    - |
      helm upgrade --install ecommerce-app-${TARGET_ENV} ${CHART} \
            -n ${TARGET_ENV} \
            --create-namespace \
            --set migrateData.enabled="${DJANGODB_SEED}" \
            --set traefik.host="${HOST}" \
            --set dockerSecret="${REGISTRY_CREDENTIAL}" \
            --set deployment.database_name="${DJANGO_DB}" \
            --set deployment.database_user="${DJANGO_DBUSER}" \
            --set deployment.database_password="${DJANGO_DBPASS}" \
            --set image.tag="${TARGET_IMAGE_TAG}" \
            --set deployment.database_host="${DJANGO_DBHOST}" --dry-run

## Build Docker image

'Build':
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  rules:
    - changes:
        - ".gitlab-ci.yml"
      when: never
    - if: $CI_COMMIT_BRANCH == "master" && $PROVISION != 'true'
    - if: $CI_COMMIT_BRANCH == "dev" && $PROVISION != 'true'
    - if: $CI_COMMIT_BRANCH == "staging" && $PROVISION != 'true'
      when: always
  stage: build
  tags:
    - dev
    - staging
    - sandbox
    - prod
  extends:
    - 'setEnv'
  script:
    - mkdir -p /kaniko/.docker
    - |
        cat << EOF > /kaniko/.docker/config.json
        {
          "auths": {
            "registry.gitlab.com": {
              "username": "${REGISTRY_USER}",
              "password": "${REGISTRY_PASSWORD}"
            }
          }
        }
        EOF
    - |
        /kaniko/executor \
          --context "${CI_PROJECT_DIR}/" \
          --dockerfile "${CI_PROJECT_DIR}/Dockerfile" \
          --destination "${TARGET_IMAGE}:${TARGET_IMAGE_TAG}" \
          --cache=true

## Deploy Dev Environment with Helm Chart

'Deploy Dev':
  image: alfredvalderrama/container-tools:latest
  stage: dev
  rules:
    - changes:
        - ".gitlab-ci.yml"
      when: never
    - if: $CI_COMMIT_BRANCH == "dev" && $PROVISION != 'true'
      when: always
  extends:
    - 'setEnv'
  tags:
    - dev
    - staging
    - sandbox
    - prod
  script:
    - echo "[DEV] Deploying DEV application"
    - |
      helm upgrade --install ecommerce-app-${TARGET_ENV} ${CHART} \
            -n ${TARGET_ENV} \
            --create-namespace \
            --set migrateData.enabled="${DJANGODB_SEED}" \
            --set traefik.host="${HOST}" \
            --set dockerSecret="${REGISTRY_CREDENTIAL}" \
            --set deployment.database_name="${DJANGO_DB}" \
            --set deployment.database_user="${DJANGO_DBUSER}" \
            --set deployment.database_password="${DJANGO_DBPASS}" \
            --set deployment.database_host="${DJANGO_DBHOST}" \
            --set image.tag="${TARGET_IMAGE_TAG}"

    - kubectl rollout status deployment/ecommerce-app-${TARGET_ENV} -n ${TARGET_ENV}

## Deploy Staging Environment with Helm Chart

'Deploy Staging':
  image: alfredvalderrama/container-tools:latest
  stage: staging
  rules:
    - changes:
        - ".gitlab-ci.yml"
      when: never
    - if: $CI_COMMIT_BRANCH == "staging" && $PROVISION != 'true'
      when: always
  extends:
    - 'setEnv'
  tags:
    - dev
    - staging
    - sandbox
    - prod
  script:
    - echo "[STAGING] Deploying STAGING application"
    - |
      helm upgrade --install ecommerce-app-${TARGET_ENV} ${CHART} \
            -n ${TARGET_ENV} \
            --create-namespace \
            --set migrateData.enabled="${DJANGODB_SEED}" \
            --set traefik.host="${HOST}" \
            --set dockerSecret="${REGISTRY_CREDENTIAL}" \
            --set deployment.database_name="${DJANGO_DB}" \
            --set deployment.database_user="${DJANGO_DBUSER}" \
            --set deployment.database_password="${DJANGO_DBPASS}" \
            --set deployment.database_host="${DJANGO_DBHOST}" \
            --set image.tag="${TARGET_IMAGE_TAG}"

    - kubectl rollout status deployment/ecommerce-app-${TARGET_ENV} -n ${TARGET_ENV}

## Deploy Staging Environment with Helm Chart

'Deploy Production':
  image: alfredvalderrama/container-tools:latest
  stage: production
  rules:
    - changes:
        - ".gitlab-ci.yml"
      when: never
    - if: $CI_COMMIT_BRANCH == "prod" && $PROVISION != 'true'
      when: always
  extends:
    - 'setEnv'
  tags:
    - dev
    - staging
    - sandbox
    - prod
  script:
    - echo "[PROD] Deploying PROD application"
    - |
      helm upgrade --install ecommerce-app-${TARGET_ENV} ${CHART} \
            -n ${TARGET_ENV} \
            --create-namespace \
            --set migrateData.enabled="${DJANGODB_SEED}" \
            --set traefik.host="${HOST}" \
            --set dockerSecret="${REGISTRY_CREDENTIAL}" \
            --set deployment.database_name="${DJANGO_DB}" \
            --set deployment.database_user="${DJANGO_DBUSER}" \
            --set deployment.database_password="${DJANGO_DBPASS}" \
            --set deployment.database_host="${DJANGO_DBHOST}" \
            --set image.tag="${TARGET_IMAGE_TAG}"

    - kubectl rollout status deployment/ecommerce-app-${TARGET_ENV} -n ${TARGET_ENV}

The workflow of this pipeline is simple.

First, A manual intervention is needed when you just want to provision the environment for the first time.
Pipeline will execute when a change is committed to dev/staging/prod branches.
Next, Pipeline will use a linter when a merge requests is detected.
The image tag is determined via release.txt file. Which contains the semantic version of the release. But you can do other solutions like release version will be based on tags. But for now I only want the release.txt file.

After successfully creating a .gitlab-ci.yml file. You have the complete production grade CI/CD pipeline integrated with ISSUE tracking!!!

Demonstration

Finally, We were here at the demo part. I will try to create a changes on my code. Like, Just changing the release.txt file.

Note: We will not go deeper on the django app. The focus here is that we have a real working pipeline.

Now, That the changes has been committed. The pipeline is now started.

As you can see at my minikube-server. The gitlab-runner is now executing the jobs.

Now, As you can see. The deployment is now running and it's now replacing the old pods with the newly built docker image. ❤❤

That's all!!! The flow will be the same with the staging and prod environment. And you can just easily transition your JIRA Issues by committing your ISSUE ID with Git, And Gitlab will automatically finish the job.

Some key sorcery for starting DevOps career's

Make it simple!
Carefully plan your pipeline from the start. So, you don't have to recreate it from scratch.
Make it portable & readable, and also reusable!
Learn how to read codes from the others. So you have the ability to learn the infrastructure by just looking at the architecture & codes.
Be the entire IT Department. So you are the Lebron James of your team.

References

Setup Multi-Cluster ServiceMesh with Istio on EKS

Alfred Valderrama — Wed, 22 Jun 2022 12:53:53 +0000

1. Provisioning
2. Istio Setup with Helm chart
3. Cross network gateway validation

Hey! In this post, We will be exploring a technology called ServiceMesh powered by Istio.

Short Intro on Non-Istio users

Istio is an open source service mesh that layers transparently onto existing distributed applications.

Istio's powerful features provide a uniform and more efficient way to secure, connect, and monitor services. Its powerful control plane brings vital features, including:

Secure service-to-service communication in a cluster with TLS encryption, strong identity-based authentication and authorization.

Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic

Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection

A pluggable policy layer and configuration API supporting access controls, rate limits and quotas

Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress

Most of you are already familiar with Istio. Since, Kubernetes federation is currently not yet available and the latest version is on a Beta version and you want to distribute your traffic across different clusters with production grade deployment.

So, Let's quickly go through the Step-by-Step procedure to implement Multi Cluster Deployment with Istio.

This tutorial is highly based on AWS and Terraform and also Helm Charts.

Provisioning

Required resources

EKS Clusters

Security Group / Rule

S3 Bucket for terraform states

IAM Roles

IAM Permissions

AWS ALB (Application LoadBalancer)

IAM Role

Create your IAM Role for your EKS Cluster.

iam.tf



resource "aws_iam_role" "eks_iam_role" {
  name = "AmazonAwsEksRole"
  assume_role_policy = jsonencode({
    "Version" : "2012-10-17",
    "Statement" : [
      {
        "Effect" : "Allow",
        "Principal" : {
          "Service" : "eks.amazonaws.com"
        },
        "Action" : "sts:AssumeRole"
      }
    ]
  })
  tags = local.default_tags
}

resource "aws_iam_policy_attachment" "eksClusterPolicyAttachmentDefault" {
  name       = "eksClusterPolicyAttachmentDefault"
  roles      = [aws_iam_role.eks_iam_role.name]
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
}

resource "aws_iam_role" "eks_iam_node_role" {
  name = "AmazonAwsEksNodeRole"
  assume_role_policy = jsonencode({
    "Version" : "2012-10-17",
    "Statement" : [
      {
        "Effect" : "Allow",
        "Principal" : {
          "Service" : "ec2.amazonaws.com"
        },
        "Action" : "sts:AssumeRole"
      }
    ]
  })

  tags = local.default_tags
  depends_on = [
    aws_iam_role.eks_iam_role,
    aws_iam_policy_attachment.eksClusterPolicyAttachmentDefault
  ]
}
resource "aws_iam_policy_attachment" "AmazonEKSWorkerNodePolicyAttachment" {
  name       = "AmazonEKSWorkerNodePolicyAttachment"
  roles      = [aws_iam_role.eks_iam_node_role.name]
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
}

resource "aws_iam_policy_attachment" "AmazonEC2ContainerRegistryReadOnlyAttachment" {
  name       = "AmazonEC2ContainerRegistryReadOnlyAttachment"
  roles      = [aws_iam_role.eks_iam_node_role.name]
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
}

resource "aws_iam_policy_attachment" "AmazonEKSCNIPolicyAttachment" {
  name       = "AmazonEKSCNIPolicyAttachment"
  roles      = [aws_iam_role.eks_iam_node_role.name]
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
}

Security Group

AWS Security Group is required in able for your cluster to communicate.

securitygroup.tf



resource "aws_security_group" "cluster_sg" {
  name        = "cluster-security-group"
  description = "Communication with Worker Nodes"
  vpc_id      = var.vpc_id
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port = 0
    to_port   = 0
    protocol  = "-1"
    self      = true
  }

  ingress {
    from_port = 0
    to_port   = 0
    protocol  = "-1"
  }

  tags = local.default_tags
}


resource "aws_security_group" "cp_sg" {
  name        = "cp-sg"
  description = "CP and Nodegroup communication"
  vpc_id      = var.vpc_id
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "Allow all"
    cidr_blocks = ["0.0.0.0/0"]
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
  }

  tags = local.default_tags
}

resource "aws_security_group" "wrkr_node" {
  name        = "worker-sg"
  description = "Worker Node SG"
  vpc_id      = var.vpc_id
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "Allow All"
    cidr_blocks = ["0.0.0.0/0"]
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
  }

  ingress {
    description = "Self Communication"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    self        = true
  }

  tags = local.default_tags
}

EKS Clusters

In this section, you will provision the 2 EKS Cluster.

eks.tf



locals {
  default_tags = {
    Provisioner = "Terraform"
    Environment = "Testing"
  }
}

resource "aws_eks_cluster" "istio_service_mesh_primary_1" {
  name     = "istio-service-mesh-primary-1"
  role_arn = aws_iam_role.eks_iam_role.arn

  vpc_config {
    subnet_ids          = var.subnet_ids
    public_access_cidrs = ["0.0.0.0/0"]
    security_group_ids = [
      aws_security_group.cluster_sg.id,
      aws_security_group.cp_sg.id
    ]
  }
  version = "1.21"

  timeouts {
    create = "15m"
  }
  depends_on = [
    aws_iam_role.eks_iam_role,
    aws_iam_role.eks_iam_node_role,
    aws_security_group.cluster_sg,
    aws_security_group.cp_sg,
    aws_security_group.wrkr_node
  ]
}

resource "aws_eks_cluster" "istio_service_mesh_primary_2" {
  name     = "istio-service-mesh-primary-2"
  role_arn = aws_iam_role.eks_iam_role.arn

  vpc_config {
    subnet_ids          = var.subnet_ids
    public_access_cidrs = ["0.0.0.0/0"]
    security_group_ids = [
      aws_security_group.cluster_sg.id,
      aws_security_group.cp_sg.id
    ]
  }
  version = "1.21"

  timeouts {
    create = "15m"
  }
  tags = local.default_tags
  depends_on = [
    aws_iam_role.eks_iam_role,
    aws_iam_role.eks_iam_node_role,
    aws_iam_policy_attachment.eksClusterPolicyAttachmentDefault,
    aws_security_group.cluster_sg,
    aws_security_group.cp_sg,
    aws_security_group.wrkr_node
  ]
}


resource "aws_eks_addon" "eks_addon_vpc-cni" {
  cluster_name = aws_eks_cluster.istio_service_mesh_primary_1.name
  addon_name   = "vpc-cni"
  depends_on = [
    aws_iam_role.eks_iam_role,
    aws_iam_role.eks_iam_node_role,
    aws_security_group.cluster_sg,
    aws_security_group.cp_sg,
    aws_security_group.wrkr_node,
    aws_eks_cluster.istio_service_mesh_primary_1
  ]
}

resource "aws_eks_addon" "eks_addon_vpc-cni_2" {
  cluster_name = aws_eks_cluster.istio_service_mesh_primary_2.name
  addon_name   = "vpc-cni"
  depends_on = [
    aws_iam_role.eks_iam_role,
    aws_iam_role.eks_iam_node_role,
    aws_security_group.cluster_sg,
    aws_security_group.cp_sg,
    aws_security_group.wrkr_node,
    aws_eks_cluster.istio_service_mesh_primary_2
  ]
}

resource "aws_eks_node_group" "istio_service_mesh_primary_worker_group_1" {
  cluster_name    = aws_eks_cluster.istio_service_mesh_primary_1.name
  node_group_name = "istio-service-mesh-primary-worker-group-1"
  node_role_arn   = aws_iam_role.eks_iam_node_role.arn
  subnet_ids      = var.subnet_ids

  remote_access {
    ec2_ssh_key               = var.ssh_key
    source_security_group_ids = [aws_security_group.wrkr_node.id]
  }

  scaling_config {
    desired_size = 2
    max_size     = 3
    min_size     = 2
  }
  instance_types = ["t3.medium"]

  update_config {
    max_unavailable = 1
  }
  depends_on = [
    aws_iam_role.eks_iam_role,
    aws_iam_role.eks_iam_node_role,
    aws_security_group.cluster_sg,
    aws_security_group.cp_sg,
    aws_security_group.wrkr_node,
    aws_eks_cluster.istio_service_mesh_primary_1,
    aws_eks_addon.eks_addon_vpc-cni
  ]

  timeouts {
    create = "15m"
  }
  tags = local.default_tags

}


resource "aws_eks_node_group" "istio_service_mesh_primary_worker_group_2" {
  cluster_name    = aws_eks_cluster.istio_service_mesh_primary_2.name
  node_group_name = "istio-service-mesh-primary-worker-group-2"
  node_role_arn   = aws_iam_role.eks_iam_node_role.arn
  subnet_ids      = var.subnet_ids
  remote_access {
    ec2_ssh_key               = var.ssh_key
    source_security_group_ids = [aws_security_group.wrkr_node.id]
  }

  scaling_config {
    desired_size = 2
    max_size     = 3
    min_size     = 2
  }
  instance_types = ["t3.medium"]
  update_config {
    max_unavailable = 1
  }
  depends_on = [
    aws_eks_cluster.istio_service_mesh_primary_2
  ]

  timeouts {
    create = "15m"
  }
  tags = local.default_tags
}

After creating necessary tf configuration. It's now time to apply it.

First, Create a tf workspace.



terraform workspace new istio-service-mesh

Next, Verify if your tf configuration is smooth.



terraform init
terraform workspace select istio-service-mesh
terraform fmt
terraform validate
terraform plan -out='plan.out'

Then, Apply it.



terraform apply 'plan.out'

It is now provisioning:

After 20 minutes or more, Your cluster's is ready!

2. Istio Setup with Helm chart

It's now time to install Istio on both clusters.

Required Charts

Istio Base helm chart
Istiod helm chart
Istio ingress gateway helm chart

First, Add the helm istio repository via:



helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update

Cluster1

Installing Istio Base helm chart via:



helm upgrade --install istio-base istio/base \
    --create-namespace -n istio-system \
    --version 1.13.2 --wait

Now, Istio based is now installed. Next one is the Istio Control Plane.
Note: You must specify the meshID, clusterName and network to uniquely identify your clusters when installing Istio control Plane.



helm upgrade --install istiod istio/istiod -n istio-system --create-namespace \
    --wait --version 1.13.2 \
    --set global.meshID="cluster1" \
    --set global.multiCluster.clusterName="cluster1" \
    --set global.network="cluster1"

Now, It's time to expose the cluster with ingress or what so called edge router by installing istio ingressgateway. In my case, I prepare to use ALB instead of prepared loadbalancer by Istio 😆.



kubectl create namespace istio-ingress
kubectl label namespace istio-ingress istio-injection=enabled

helm upgrade --install istio-ingressgateway istio/gateway \
     -n istio-ingress --create-namespace \
     --version 1.13.2 --set service.type="NodePort"

Finally, create an ingress resource then associate the ingress to istio-ingressgateway NodePort service.

ingress.yaml



apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: istio-alb-ingress
  namespace: istio-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/healthcheck-path: /healthz/ready
    alb.ingress.kubernetes.io/healthcheck-port: traffic-port
    alb.ingress.kubernetes.io/certificate-arn: "<your-certificate-arn>"
    alb.ingress.kubernetes.io/listen-ports: '[{ "HTTP": 80 }, { "HTTPS": 443 }]'
    alb.ingress.kubernetes.io/security-groups: <your-security-group-id>
    alb.ingress.kubernetes.io/scheme: internet-facing
    #alb.ingress.kubernetes.io/target-type: instance
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
    alb.ingress.kubernetes.io/tags: Environment=Test,Provisioner=Kubernetes
  labels:
    app:  "Istio"
    ingress: "Istio"
spec:
  rules:
    - http:
        paths:
          - path: /*
            backend:
              serviceName: ssl-redirect
              servicePort: use-annotation
          - path: /healthz/ready
            backend:
              serviceName: istio-ingressgateway
              servicePort: 15021
          - path: /*
            backend:
              serviceName: istio-ingressgateway
              servicePort: 443

Cluster2

Same steps applied to cluster2. But you must change the meshID, clusterName and network values on Istio Control plane chart.

Installing Istio base chart via:



helm upgrade --install istio-base istio/base \
    --create-namespace -n istio-system \
    --version 1.13.2 --wait

Installing Istio Control Plane:



helm upgrade --install istiod istio/istiod \
    -n istio-system --create-namespace \
    --wait --version 1.13.2 \
    --set global.meshID="cluster2" \
    --set global.multiCluster.clusterName="cluster2" \
    --set global.network="cluster2"

On cluster2, We don't have to setup additional edge ingressgateway. Since, the connection will be started from cluster1. But, How can we distribute the traffic from cluster1 to cluster2 ?

Answer: By exposing cluster services 💡

On cluster1, Create additional Loadbalancer by installing additional istio-ingressgateway.



helm upgrade --install istio-crossnetworkgateway istio/gateway \
     -n istio-system --create-namespace --version 1.13.2

For cluster2:



helm upgrade --install istio-crossnetworkgateway istio/gateway \
     -n istio-system --create-namespace --version 1.13.2

Exposing services for both cluster.
istio-exposeservice.yaml



apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cross-network-gateway
  namespace: istio-system
spec:
  selector:
    app: istio-crossnetworkgateway
  servers:
    - port:
        number: 15443
        name: tls
        protocol: TLS
      tls:
        mode: AUTO_PASSTHROUGH
      hosts:
        - "*.local"

Now, Services are now exposed. But how does istio identify or discover resources from the other cluster?

We need to enable Endpoint Discovery.

On cluster1, I assume that your kubeconfig file is pointed to cluster1 context. This way, We can create istio secret file that can give access on both clusters in able for them to discover resources.

Create an istio secret for cluster2. This command should be done on cluster1 context:



istioctl x create-remote-secret --name=cluster1 > cluster2-secret.yaml

On cluster2, Create an istio secret for cluster1. This command should be done on cluster2 context:



istioctl x create-remote-secret --name=cluster2 > cluster1-secret.yaml

If you view the file, It's just a kubeconfig context from both cluster contexts enabling API Access.

Next, We should apply the secret to both clusters.
Cluster1:


 apply -f cluster1-secret.yaml

Cluster2:


 apply -f cluster2-secret.yaml

Last, but not least. Verify if your clusters has already a trust configuration.



diff \
   <(export KUBECONFIG=$(pwd)/kubeconfig_cluster1.yaml && kubectl -n istio-system get secret cacerts -ojsonpath='{.data.root-cert\.pem}') \
   <(export KUBECONFIG=$(pwd)/kubeconfig_cluster2.yaml && kubectl -n istio-system get secret cacerts -ojsonpath='{.data.root-cert\.pem}')

If there's no certificate found on both clusters. You can generate a self-signed root CA certificate.

Kindly, visit for more info: Generating self-signed root CA certificates

Generate Certificates

Istio provides basic security by default in able for the services not being accidentally exposed publicly. Istio will automatically drop client connection if the TLS handshake doesn't meet the requirements.

Because Istio verifies service-to-service communication by using Trust Configurations.

Creating a root-ca certificate.



cd istio-tool
mkdir -p certs
pushd certs
make -f ../Makefile.selfsigned.mk root-ca

Generate a cluster1 certificate.



make -f ../Makefile.selfsigned.mk cluster1-cacerts

Generate a cluster2 certificate.



make -f ../Makefile.selfsigned.mk cluster2-cacerts

Now, apply both the certificates on both cluster.
For Cluster1:



kubectl create secret generic cacerts -n istio-system \
      --from-file=cluster1/ca-cert.pem \
      --from-file=cluster1/ca-key.pem \
      --from-file=cluster1/root-cert.pem \
      --from-file=cluster1/cert-chain.pem

For Cluster2:



kubectl create secret generic cacerts -n istio-system \
      --from-file=cluster2/ca-cert.pem \
      --from-file=cluster2/ca-key.pem \
      --from-file=cluster2/root-cert.pem \
      --from-file=cluster2/cert-chain.pem

After applying all the necessary steps. The cluster1 and cluster2 should now be able to distribute traffic on both clusters.

3. Cross network gateway validation

After applying the necessary steps. Of course, you need to verify if it's actually working. I've created a basic application called MetaPod that allows you to extract the pod information or metadata through the web. So you can determine if your traffic is actually being forwarded to the 2nd cluster.

MetaPod sample deployment manifest.

For Cluster1, Try to deploy the test deployment.
Note: You must change the hosts values to make it work on your end.



---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: metapod-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "metapod.example.com"
    tls:
      mode: PASSTHROUGH
      httpsRedirect: true # sends 301 redirect for http requests
  - port:
      number: 443
      name: http-443
      protocol: HTTP  # http only since tls certificate is came from upstream (LoadBalancer) Level
    hosts:
    - "metapod.example.com"
    tls:
      mode: PASSTHROUGH
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: metapod
spec:
  hosts:
  - "metapod.example.com"
  - "metapod.default.svc.cluster.local"
  gateways:
  - metapod-gateway
  http:
  - route:
    - destination:
        host: metapod.default.svc.cluster.local
        port:
          number: 80
    retries:
      attempts: 5
      perTryTimeout: 5s

---
apiVersion: v1
kind: Service
metadata:
  name: metapod
  labels:
    app: metapod
    service: metapod
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: metapod
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: metapod
spec:
  replicas: 2
  selector:
    matchLabels:
      app: metapod
      version: v1
  template:
    metadata:
      labels:
        app: metapod
        version: v1
    spec:
      containers:
      - image: docker.io/redopsbay/metapod:latest
        imagePullPolicy: IfNotPresent
        name: metapod
        ports:
        - containerPort: 8080
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName
        - name: POD_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: metapod
              resource: requests.cpu
        - name: POD_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: metapod
              resource: limits.cpu
        - name: POD_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: metapod
              resource: requests.memory
        - name: POD_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: metapod
              resource: limits.memory
        - name: CLUSTER_NAME
          value: "Cluster1"
        - name: GIN_MODE
          value: "release"

For Cluster2:



---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: metapod
spec:
  hosts:
  - "metapod.example.com"
  - "metapod.default.svc.cluster.local"
  gateways:
  - metapod-gateway
  http:
  - route:
    - destination:
        host: metapod.default.svc.cluster.local
        port:
          number: 80
---
apiVersion: v1
kind: Service
metadata:
  name: metapod
  labels:
    app: metapod
    service: metapod
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: metapod
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: metapod
spec:
  replicas: 2
  selector:
    matchLabels:
      app: metapod
      version: v1
  template:
    metadata:
      labels:
        app: metapod
        version: v1
    spec:
      containers:
      - image: docker.io/redopsbay/metapod:latest
        imagePullPolicy: IfNotPresent
        name: metapod
        ports:
        - containerPort: 8080
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName
        - name: POD_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: metapod
              resource: requests.cpu
        - name: POD_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: metapod
              resource: limits.cpu
        - name: POD_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: metapod
              resource: requests.memory
        - name: POD_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: metapod
              resource: limits.memory
        - name: CLUSTER_NAME
          value: "Cluster2"
        - name: GIN_MODE
          value: "release"

After a few seconds, Try to visit the registered gateway on your end.

In my case, https://metapod.example.com and it should look like this:

As you can see under the CLUSTER NAME. Your traffic is forwarded to Cluster1. If you constantly refresh your browser page. You'll notice that your traffic is being forwarded also to Cluster2. See below:

Alright! That's it. You may encounter a lot of problems during your journey. But it's worth to try.

You can message me directly here or on my twitter account https://twitter.com/redopsbay if you need help.

I will try my best to help you out to fix it. 😅😅😅
Hope you like it. Cheers!!!🍻🍻 Thanks!!!

DEV Community: Alfred Valderrama

CloudCycle - Set lifecycle for your cloud resources to avoid surprising costs

The Problem

The Solution (CloudCycle)

Tools & Language used

Architecture

Sample Code for EC2 Instance Service

Objective

Usage

How does it works?

Sample Terraform Deployment Usage

Benefit's

Reference

Observability with OpenTelemetry

What is Observability?

Instrumentation

OpenTelemetry

Back to Basic

Tracing with Golang

Injecting traces with Contexts

Wrap

References

Production grade CI/CD Pipeline with GitLab and JIRA powered by mydevopsteam.io sorcery

Overview

Prerequisites

GitLab Project Setup

Overview

JIRA Setup

Overview

Setup GitLab runner on Kubernetes

Advantage

Disadvantage

Installation of GitLab runner via Helm.

JIRA issue integration on GitLab

Generate JIRA API Token

Open a sample JIRA issue

Why automatic ticket transitioning is important?

Setup Traefik Proxy (optional) for edge routing experience

Overview

Install Traefik Proxy via Helm

Containerized the sample django application

Populate containerized application to helm chart

GitLab CI/CD Pipeline setup via .gitlab-ci.yml

Demonstration

Some key sorcery for starting DevOps career's

References

Setup Multi-Cluster ServiceMesh with Istio on EKS

Short Intro on Non-Istio users

Provisioning

IAM Role

Security Group

EKS Clusters

2. Istio Setup with Helm chart

Cluster1

Cluster2

Generate Certificates

3. Cross network gateway validation

Quick References