Forem: chauhoangminhnguyen

Kubernetes Horizontal Pod Autoscaling

chauhoangminhnguyen — Tue, 24 Sep 2024 14:00:00 +0000

Introduction

There are two common scaling methods: Vertical scaling and Horizontal scaling.

Vertical scaling involves adding more hardware, such as RAM or CPU, or increasing the number of server nodes. Horizontal scaling, on the other hand, means adding more instances of an app to fully utilize the available resources on a node or server.

However, horizontal scaling has its limits. Once a node's resources are maxed out, vertical scaling becomes necessary. This article will focus on horizontal scaling using Kubernetes Horizontal Pod Autoscaling (HPA), which automatically scales resources up or down based on system demands.

Implementation Process

1. Build a Docker image for your application.

2. Deploy the image using a Deployment and LoadBalancer service.

3. Configure HPA to automatically scale resources.

To use HPA for auto-scaling based on CPU/Memory, Kubernetes must have the metrics-server installed. If you’re using a cloud provider, the metrics-server is usually installed by default. For local Kubernetes setups, you need to manually install the metrics-server.

If you’re using Kind for a local Kubernetes setup, follow these steps to install the metrics-server after successfully creating the cluster:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Or install with Helm

helm repo add k8s-dashboard https://kubernetes.github.io/dashboard
helm upgrade --install kubernetes-dashboard k8s-dashboard/kubernetes-dashboard

1. Build a Docker Image for the Application

Use the following code block to create a NodeJS Express Server:

import express from 'express'

const port = 3000
const app = express()

app
  .get('/', (_, res) => {
    res.send('This is NodeJS Typescript Application! Current time is ' + Date.now())
  })
  .get('/sum', (req, res) => {
    const value = +req?.query?.value
    const start = Date.now()
    const result = Array(+value)
      .fill(0)
      .map((_, i) => i)
      .reduce((a, b) => a + b)
    const now = Date.now()
    const duration = now - start
    res.json({duration, now, result})
  })
  .listen(port, () => {
    console.log(`Server is running http://localhost:${port}`)
  })

Next, let's build the Docker image and push it to Google Artifact Registry or Docker Hub. You can refer to my guide on how to do this here.

2. Deploy the image using a Deployment and a LoadBalancer service

Create a deployment.yml\ file that includes the configuration for the Deployment to deploy the image you built, along with a LoadBalancer service, as shown below:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-name
  labels:
    name: label-name
spec:
  selector:
    matchLabels:
      app: label-name
  template:
    metadata:
      labels:
        app: label-name
    spec:
      restartPolicy: Always
      containers:
        - name: express-ts
          image: express-ts
          resources:
            requests: # min
              memory: "100Mi"
              cpu: "100m"
            limits: # max
              memory: "300Mi"
              cpu: "300m"
---
apiVersion: v1
kind: Service
metadata:
  name: service-name
  labels:
    service: label-name
spec:
  selector:
    app: label-name
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80 # port service
      targetPort: 3000 # port pod

I've explained the details about deployment and the LoadBalancer service in this article.

Here, we also cover resource configuration. You can choose to configure CPU, Memory, or both, depending on which parameters you want to scale.

If you define resource values, you can scale by a percentage of the initially defined resources.
If you don't define resource values, you must specify the exact resource values to scale.

3. Configuring HPA for Auto-scaling Resources

You can include the HPA configuration either in your deployment.yml\ file or in a separate file with the following content:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-name
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: deployment-name # target to deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu # scale base on CPU
        target:
          type: Utilization
          averageUtilization: 80 # target 80%
  behavior:
    scaleDown:
      policies:
        - type: Pods
          periodSeconds: 30
          value: 3
      stabilizationWindowSeconds: 120

minReplicas, maxReplicas: min and max scaling resource
metrics: Define the type of resource you want to scale; in this case, it's the CPU.
averageUtilization: This is a percentage. When it exceeds this value, the system will scale up.
behavior: This is optional. Here, it's used to define the scale-down behavior, allowing a maximum of 3 Pods to scale down in 30 seconds.
stabilizationWindowSeconds: When the system remains stable for this duration, it will scale down (the default value is 5 minutes).

Next, apply to create the resource as follows:

kubectl apply -f deployment.yml

Note: I've defined all resources in a single file for simplicity, but in practice, you should separate each resource into individual YAML files for better management.

Information on the resource once created:

Please ensure that this API is working so we can continue testing the HPA.

Testing HPA

You can test the API using any method you know. Here, I provide a code block to send 10 requests every second. Replace the URL with the EXTERNAL-IP of the LoadBalancer service.

const numOfRequest = 10
const url = 'http://172.23.0.3/sum?value=10000000'
let idx = 0

setInterval(() => {
  Promise.all(
    Array(numOfRequest)
      .fill(0)
      .map(() =>
        fetch(url)
          .then(res => res.json())
          .then(data => console.log('Completed', ++idx, data.duration))
          .catch(console.error)
      )
  )
}, 1000)

After executing, the server resources will gradually increase, triggering the auto-scaling process.

You can check if HPA has performed the auto-scaling as follows:

You will notice that the number of Replicas will gradually increase when the CPU usage exceeds the 80% target (field value averageUtilization) and will gradually decrease after a period of time (field value stabilizationWindowSeconds) when the system stabilizes.

See you in the next articles!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting:

SSH to Google Compute Engine

chauhoangminhnguyen — Mon, 23 Sep 2024 14:00:00 +0000

Introduction

I previously wrote a guide on creating a Virtual Machine (VM) instance on Google Cloud and accessing it via gcloud. However, if your Google Cloud account lacks permission to manage VM instances, or if you want to create a VM instance that allows SSH for easy sharing with other users and compatibility with various SSH tools, follow the steps below.

Configure SSH access for VM instance

Firstly, you need to create a compute instance as follows:

gcloud compute instances create {instance name} \
  --zone={zone} \
  --machine-type={machine type}

# ex:
gcloud compute instances create instance-1 \
  --zone=asia-southeast1-a \
  --machine-type=e2-micro

Next, SSH into this VM to perform the necessary configurations.

Typically, a Google VM instance will have a Distributor ID of Debian. Use the following command to check this before proceeding with the next steps.

lsb_release -a

Next, set the password for the root account as follows:

sudo passwd

Next, use the Vim editor to change the settings in the sshd_config file.

vi /etc/ssh/sshd_config

Find and change the following fields to the following values:

PermitRootLogin yes
PasswordAuthentication yes

If you're not familiar with using the Vim editor, you can use the following commands to edit the sshd_config file:

- i: Switch to interactive mode (allows editing)

- Esc: Switch to normal mode (allows using commands)

- :wq: Write then quit (saves and closes the file)

After successfully updating the configuration, restart the service.

systemctl restart sshd.service

SSH to a VM Instance

First, you need to obtain the External IP of the VM instance.

To SSH into the VM instance, use the following command:

ssh root@34.126.104.206

After entering your password, the SSH connection will be successful.

You can also use SSH tools or file managers like WinSCP, PuTTY, or Remmina, depending on your needs. These tools make it easy to work with your VM and allow you to save your SSH info for future connections.

Feel free to leave your thoughts in the comments, and don’t forget to like, share, and follow for more great content!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting:

Setting Up an EXTERNAL-IP for Local LoadBalancer Service

chauhoangminhnguyen — Sun, 22 Sep 2024 14:00:00 +0000

Introduction

If you've used a LoadBalancer service from a Cloud Provider, you'll know how convenient it is to have an EXTERNAL-IP assigned automatically. However, when using local Kubernetes, the default setting doesn't provide an EXTERNAL-IP. Building on our previous discussion, this guide will show you how to use cloud-provider-kind to assign an EXTERNAL-IP to your local LoadBalancer service.

First, make sure you've set up your local Kubernetes using Kind as outlined in my previous guide. This is necessary to proceed with the next steps.

Installing cloud-provider-kind

Since this is a Go package, you'll need to install Go first. Then, you can install the package with the following steps:

go install sigs.k8s.io/cloud-provider-kind@latest

Then execute command to use:

cloud-provider-kind

Keep in mind that you need to keep the terminal running while using Kubernetes to create the EXTERNAL-IP.

Testing with local EXTERNAL-IP

Create a deployment and expose a LoadBalancer service to check if the EXTERNAL-IP has been generated.

kubectl create deploy whoami --image traefik/whoami
kubectl expose deploy whoami --port 80 --type LoadBalancer

The results will be as follows:

You can access the EXTERNAL-IP to use it locally.

Using cloud-provider-kind as a service

If you're on Ubuntu, there's a way to automatically run cloud-provider-kind when you start your machine as a service, so you don't have to manually start it every time you want to use it.

First, navigate to the directory /etc/systemd/system and create a file called cloud-provider-kind.service with the following content:

cd /etc/systemd/system
touch cloud-provider-kind.service

[Unit]
Description = Your description
After = docker.service

[Service]
Type = simple
ExecStart = {direction to cloud-provider-kind}
StandardOutput = journal
User = {user id}
Group = {group id}

[Install]
WantedBy=multi-user.target

ExecStart: Use the command which cloud-provider-kind to replace your directory.
User, Group: Use the command id to get the appropriate values.

To start the service:

sudo systemctl enable --now cloud-provider-kind

Then check status:

If you have any suggestions or questions regarding the content of the article, please don't hesitate to leave a comment below!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting:

Setting up Kubernetes Dashboard with Kind

chauhoangminhnguyen — Sat, 21 Sep 2024 14:00:00 +0000

Introduction

In a previous article, I guided you through using Helm to deploy on Google Kubernetes Engine. However, if you want to cut down costs by using Kubernetes in your local environment instead of relying on a cloud provider during development, then Kind is your go-to.

There are several tools to help set up Kubernetes locally, such as MiniKube, Kind, K3S, KubeAdm, and more. Each tool has its own pros and cons. In this article, I'll walk you through using Kind to quickly set up a Kubernetes cluster on Docker. Kind stands out for its compactness, making Kubernetes start up quickly, being user-friendly, and supporting the latest Kubernetes versions.

Working with Kind

Firstly, follow the instructions here to install Kind according to your operating system.

If you're using Ubuntu, execute the command:

[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.23.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

After successfully installing Kind, you can check its version with the following command:

To create a cluster, use this command:

kind create cluster --name {cluster name}

# ex
kind create cluster --name local

Use Helm to set up the Kubernetes Dashboard

The Kubernetes Dashboard is a tool for managing Kubernetes clusters with an easy-to-use web UI.

First, add the Kubernetes Dashboard repository:

helm repo add {repo name} https://kubernetes.github.io/dashboard

# ex
helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard

Next, install the chart:

helm upgrade --install {release name} k8s-dashboard/kubernetes-dashboard --create-namespace -n {namespace}

# ex
helm upgrade --install kubernetes-dashboard k8s-dashboard/kubernetes-dashboard --create-namespace -n kubernetes-dashboard

Please note that you need to successfully create a Kubernetes cluster before you can install a Helm chart.

-n {namespace}: Setting a namespace is optional, but organizing resources by namespace can be helpful, especially if you need to install multiple Helm charts.

Once you've successfully installed the Helm chart, the result will be as follows:

You can check if the resources were created successfully like this:

kubectl get all -n {namespace}

# ex
kubectl get all -n kubernetes-dashboard

Next, forward the port for the service so it can be accessed from localhost.

As a result, you can access the Kubernetes Dashboard like this:

To generate a token, create a file named service-account.yml with the following content:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: admin-user
    namespace: kube-system

Apply to Create Resources:

Next, generate a token like this:

Use that token to login to the Kubernetes Dashboard.

See you again in the next articles!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting:

Helm for beginer - Deploy nginx to Google Kubernetes Engine

chauhoangminhnguyen — Fri, 20 Sep 2024 14:00:00 +0000

Introduction

Helm is a package manager for Kubernetes, which simplifies the process of deploying and managing applications on Kubernetes clusters. Helm uses a packaging format called charts, which are collections of files that describe a related set of Kubernetes resources.

Key Components of Helm

Charts: Helm packages are called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
Values: Charts can be customized with values, which are configuration settings that specify how the chart should be installed on the cluster. These values can be set in a values.yaml file or passed on the command line.
Releases: When you install a chart, a new release is created. This means that one chart can be installed multiple times into the same cluster, and each can be independently managed and upgraded.

Prerequisites

To get started, you'll need to:

Have some knowledge about Kubernetes. You can check out this article for basic information.
A Google Account with the necessary permissions to use Kubernetes.
Installed gcloud and kubectl

Practical Steps

First, use gcloud to create a cluster like this:

gcloud container clusters create {cluster name} \
  --project {project id} \
  --zone {zone id} \
  --machine-type {machine type id} \
  --num-nodes {number of node}

# ex:
gcloud container clusters create k8s-cluster \
  --project project-id \
  --zone asia-southeast1-a \
  --machine-type e2-micro \
  --num-nodes 1

To install helm, use the following command:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

To create a helm chart, use the following command:

helm create chart-name

After executing, a template is created that includes files like development.yaml, service.yaml, and others, similar to working with Kubernetes. Among these files, pay special attention to values.yaml. The values in this file are bound to the template when Helm is installed. By simply changing these values according to your needs, you can easily modify the deployment configuration.

Next, in the values.yaml file, look for the following information:

image:
  repository: nginx

service:
  type: ClusterIP
  port: 80

The repository is a Docker image used for deployment, which you can customize as needed.
The current service type is ClusterIP, using port 80.

Here, you can change the service type to LoadBalancer. Then, install helm chart as follows:

The change to a LoadBalancer service type allows your cloud provider to supply an EXTERNAL-IP. You can then retrieve the EXTERNAL-IP information as follows:

If you keep the original content of the values.yaml file, you can install helm chart and change the service type to LoadBalancer like this:

Access the EXTERNAL-IP to see the following results:

Result
To uninstall helm chart and clear up resources, you can use the following command:

Feel free to share your thoughts in the comments!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting:

Setup Gitlab CI

chauhoangminhnguyen — Thu, 19 Sep 2024 14:00:00 +0000

Introduction

Gitlab is a comprehensive platform designed for software development and version control using git. It provides a user-friendly web interface that enhances the speed of working with git, making it easier to manage Git repositories. Gitlab offers a range of features including:

Free public and private repositories: You can host your code securely and privately or share it with the world.
Continuous Integration/Continuous Deployment (CI/CD): Automate the testing and deployment of your code.
Free private docker image storage on Container Registry

In this article, I'll guide you on how to push a Docker image to the Gitlab Container Registry and set up CI to automatically build and push Docker images when you push code to a Gitlab repository.

Pushing a Docker Image to the Gitlab Container Registry

First, you'll need a Gitlab account and a repository (either public or private will work).

Use the NodeJS Typescript Server project I introduced earlier, or any project you have that includes a Dockerfile for building a Docker image.

Next, create a Personal Access Token to prepare for pushing the image to the Container Registry.

After building your Docker image, tag the image appropriately to ensure it can be pushed to the Container Registry.

docker tag {image name after build} registry.gitlab.com/{gitlab username}/{repository}:{version}

#ex:
docker tag express-ts registry.gitlab.com/username/express-ts:latest

Logging into the Gitlab Container Registry

docker login -u {gitlab username} -p {access token} registry.gitlab.com

Push image to Registry Container

docker push registry.gitlab.com/{gitlab username}/{repository}:{version}

#ex:
docker push registry.gitlab.com/username/express-ts:latest

The results are as follows:

Setting up Gitlab CI

To set up steps that run whenever you push code to your Gitlab repository, add a .gitlab-ci.yml file to your project with the following content:

image: docker:24.0.7

services:
  - docker:24.0.7-dind

stages:
  - build

before_script:
  - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

build:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -t $CI_REGISTRY_IMAGE:latest .
    - docker image push --all-tags $CI_REGISTRY_IMAGE

Explanation:

- image and services: Define the Docker environment to execute Docker commands.

- stages: Specify the stages that will execute when code is pushed. Here, there's only one stage: build.

- before_script: Runs before each stage. This step logs into the Container Registry.

- stage build: Builds the image with two tags: the SHA commit ID and "latest", then pushes all tags to the Container Registry.

Gitlab provides environment variables, which are information that can be used when stages are executed:

CI_REGISTRY_USER: username
CI_REGISTRY_PASSWORD: password
CI_REGISTRY: Gitlab register
CI_REGISTRY_IMAGE: image name
CI_COMMIT_SHA: SHA commit id

After that, just push the code to the Gitlab repository to automatically trigger the CI process.

See you in the next articles!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting:

Github CI/CD with Google Cloud Build

chauhoangminhnguyen — Wed, 18 Sep 2024 14:00:00 +0000

Introduction

Continuous Integration (CI): This is the process of building, testing, and performing necessary actions to ensure code quality before it gets merged into the main branch for deployment.
Continuous Delivery (CD): This usually happens after CI and includes steps to deploy the source code to various environments like staging and production.

This guide will show you how to set up CI/CD on Github using Google Cloud Build. While Github provides shared runners, if you or your organization have many jobs that need executing during development, setting up your own runner is a better choice.

Before proceeding, you should understand some basics about Google Cloud Run to build and deploy Docker images. You can refer to this article for more details: Build Docker image for NodeJS Typescript Server.

Setting Up GitHub CI/CD

First, create a Github repository. You can choose either a public or private repository.

You can use a NodeJS TypeScript application, following my guide on building a Docker image, or use your existing source code (make sure to include a Dockerfile to build the Docker image).

Next, in your source code, create a cloudbuild.yaml file as follows:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '.', '-t', 'gcr.io/project-id/express-ts:$SHORT_SHA', '-t', 'gcr.io/project-id/express-ts:latest']
- name: 'gcr.io/cloud-builders/docker'
  args: ['image', 'push', '--all-tags', 'gcr.io/project-id/express-ts']
- name: 'gcr.io/cloud-builders/gcloud'
  args:
    - run
    - deploy
    - --region=asia-southeast1
    - --image=gcr.io/project-id/express-ts:latest
    - --max-instances=1
    - --platform=managed
    - --port=3000
    - --allow-unauthenticated
    - express-ts

This file outlines the steps that Google Cloud Build will take when you push code to a specified branch on Github:

- 'gcr.io/cloud-builders/docker' and 'gcr.io/cloud-builders/gcloud' are used to execute Docker and Google Cloud commands.

- $SHORT_SHA represents the short commit ID.

- The first step is to build a Docker image with two tags: the short commit ID and 'latest'.

- Step 2 involves pushing the Docker image with both tags to Google Artifact Registry.

- Step 3 is deploying via Google Cloud Run, as instructed in the previous article.

Note: Remember to replace the project ID and other parameters according to your project.

Create a Trigger

Next, navigate to Google Cloud Build > Create trigger. Then, input the required information, paying attention to the following fields:

- Repository: Connect to your repository, supporting both Github and Bitbucket. After successful account connection, you can configure for both public and private repositories.

- Branch: Specify the branch name that will trigger Cloud Build upon action. Branch names support regex.

- Cloud Build Configuration File Location: Specify the file name used to define the steps Cloud Build will execute. You can use the default or customize it as needed.

- Service Account: Choose the account corresponding to the project ID used to push Docker images to Google Artifact Registry.

Note that currently, there are usage limits for Google Cloud Build based on region. Check here for more information. You can request an increase in quota or switch to a suitable region to use Cloud Build effectively.

Test CI/CD

Push your source code to Github to test the CI/CD process.

A successful result will be as follows:

You can also access Google Cloud Build to check the results.

Results after deployment:

See you again in the next articles!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting:

Using Google Cloud Run to Deploy Docker Image

chauhoangminhnguyen — Sat, 14 Sep 2024 14:00:00 +0000

Introduction

Google Cloud Run (GCR) makes deploying a Docker image as easy as running it locally. GCR also includes customizable configuration options for managing services, simplifying the deployment process significantly.

Build Docker Image

The key step in deploying with a Docker image is successfully building that image. In this guide, we’ll use a NodeJS server Docker image created in this article. Follow the steps to build your Docker image (or use an existing one), and push it to Google Artifact Registry before proceeding.

Deploy Docker Image

To deploy a Docker image using Google Cloud Run, simply use the following command:

gcloud run deploy express-ts --image {docker image} --port {port container} --region {region id} --max-instances {number of instance} --allow-unauthenticated

--image: is the link to the Docker image on Google Artifact Registry or Docker Hub
--port: is the container port you are exposing
--max-instances: is the number of instances

For example:

After a successful deployment, the Service URL will be created, and you can access it immediately to start using the service.

To list the available services, execute the following command:

To delete a service:

See you again in the next articles!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting:

Monitoring with Grafana

chauhoangminhnguyen — Fri, 13 Sep 2024 14:00:00 +0000

Introduction

In my previous article, I guided you through setting up cAdvisor, Prometheus and Grafana on Docker, which are widely used for system monitoring. Now that you've successfully started Grafana, follow these next steps to start using it.

Using Grafana

When you access the Grafana login page, use the following default credentials for your first login. You can change them later as needed.

username: admin
password: admin

Here's how the homepage looks.

First, you need to add Prometheus as a data source:

1. Go to Connections > Add new connection > select Prometheus.

2. Enter the Prometheus server URL that you defined when starting Docker Compose.

Once the data source is successfully added, create a new dashboard:

1. Click on New > New dashboard > Add visualization.

2. Select Prometheus as the data source and choose a metric to use, such as container_memory_cache.

After saving, you can view the results on your dashboard as follows:

Using Dashboard Templates

Grafana offers a variety of dashboard templates suitable for data sources like Prometheus. You can browse these templates to find one that fits your needs here.

Once you've found a suitable template, import it into Grafana as follows:

1. Go to Dashboards > New > Import

2. Enter the Dashboard URL or ID and click Load. For example, if the Dashboard URL is https://grafana.com/grafana/dashboards/14900-nginx, the ID would be 14900.

After successfully loading the dashboard template, save it for easy access in the future.

What do you think? Leave a comment below!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting:

Monitoring with cAdvisor, Prometheus and Grafana on Docker

chauhoangminhnguyen — Thu, 12 Sep 2024 14:00:00 +0000

Introduction

Monitoring a system is crucial after deploying a product to a production environment. Keeping an eye on system metrics like logs, CPU, RAM, disks, etc, helps identify the system's status, performance issues, and provides timely solutions to ensure stable operations.

While cloud providers like Google, Amazon, or Azure offer built-in monitoring systems, if your company needs to manage multiple applications/systems/containers and desires a centralized monitoring system for easier management, using cAdvisor, Prometheus, and Grafana is a sensible choice. These three popular open-source tools are widely used by DevOps teams, especially for monitoring container applications.

cAdvisor

Developed by Google, cAdvisor is an open-source project used to analyze resource usage, performance, and other metrics from container applications, providing an overview of all running containers.

Find more details here

Prometheus

Prometheus is a toolkit for system monitoring and alerting based on system metrics. It supports organizing data over time, sending alerts via email, SMS, etc. Prometheus can integrate with various tools, including cAdvisor.

While cAdvisor fetches system information, Prometheus provides functionalities to manipulate that information such as visualizing data and triggering alerts.

Find more details here

Grafana

Grafana is a platform specialized in data visualization, supporting the creation of beautiful dashboards for web viewing, facilitating professional data analysis. Grafana can integrate with various data sources like MySQL, MongoDB, and Prometheus, etc.

So, the combination of cAdvisor, Prometheus, and Grafana works like this:

cAdvisor gathers system info.
Prometheus scrapes data from cAdvisor.
Grafana is used to visualize data from Prometheus (while Prometheus has monitoring dashboards, Grafana excels in data visualization, hence the need for Grafana).

Setup Docker

First, let's create a docker-compose.yml file as follows:

services:
  cAdvisor:
    image: gcr.io/cadvisor/cadvisor
    container_name: cAdvisor
    ports:
      - 8080:8080
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /etc/machine-id:/etc/machine-id:ro
      - /var/lib/dbus/machine-id:/var/lib/dbus/machine-id:ro
  prometheus:
    image: prom/prometheus
    ports:
      - 9090:9090
    command:
      - --config.file=/etc/prometheus/prometheus.yml
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
    depends_on:
      - cAdvisor
  grafana:
    image: grafana/grafana
    ports:
      - 3000:3000
    restart: always
    depends_on:
      - prometheus

You can see that I’ve defined three services corresponding to cAdvisor, Prometheus, and Grafana. In this setup, Prometheus depends on cAdvisor, and Grafana depends on Prometheus.

Next, create a prometheus.yml file in the same location as your docker-compose.yml. This file will configure Prometheus to scrape data from cAdvisor.

scrape_configs:
- job_name: cAdvisor
  scrape_interval: 10s
  static_configs:
  - targets:
    - cAdvisor:8080

The content of this file defines a job where Prometheus will scrape data from cAdvisor every 10 seconds, using cAdvisor:8080 as defined in the docker-compose.yml file.

Next, start the services:

docker compose up -d

After successfully executing, you can access each service as follows:

However, the main platform you need to use is Grafana, so it's fine to just focus on learning how to use Grafana.

If you found this post helpful, please show your appreciation by sharing and commenting!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting:

Deploy React Application to Google Kubernetes Engine

chauhoangminhnguyen — Wed, 11 Sep 2024 14:00:00 +0000

Introduction

In this article, I will guide you through deploying a React Application to Google Kubernetes Engine (GKE). Previously, I wrote an article about deploying a NodeJS Application to GKE, which you can refer to for some basic information before continuing.

Steps to Follow

The process is quite similar to deploying a NodeJS Application and includes the following steps:

Create a React Application
Build a Docker image
Push the Docker image
Deploy the Docker image to GKE

You will notice that when working with Kubernetes, the main difference is in the step where you build the Docker image. Depending on the application you need to deploy, there are different ways to build the Docker image. However, the common point is that once you build the Docker image, you have completed almost half of the process. This is because the subsequent steps involving Kubernetes are entirely the same.

Detailed Process

1. Create a React Application

In this step, you can either use an existing React project or create a new one.

I will use Vite to create a React project as follows:

yarn create vite

Next, select the basic information to initialize the project. Once the project starts successfully, proceed to the next step.

2. Build Docker Image

First, create a Dockerfile:

FROM node:alpine as build-stage
WORKDIR /app
COPY package*.json yarn.lock ./
RUN yarn install --silent
COPY . .
RUN yarn build

FROM nginx:alpine as production-stage
COPY --from=build-stage /app/dist /usr/share/nginx/html
CMD ["nginx", "-g", "daemon off;"]

The image build process is divided into two stages. In the build step, pay attention to the line RUN yarn build to replace the command with the one that builds your source code into static files corresponding to your project.

Next, in the production-stage, pay attention to the line COPY --from=build-stage /app/dist /usr/share/nginx/html to replace the directory with the static files after the build. In this case, my folder is dist. Here, I am copying the static files into the Nginx web server. If you need to learn the basics of Nginx, you can refer to this guide.

Next, create a .dockerignore file to ignore any files that should not be copied during the Docker image build process.

To build the image, execute the following command:

docker build . -t react-ts

3. Push Docker Image

To push your Docker image to Google Cloud Artifact Registry, check out this article I mentioned earlier. Alternatively, you can also push it to Docker Hub.

4. Deploy Docker Image to GKE

Now, let's create a cluster with the following command:

# gcloud container clusters create {cluster name} \
#   --project {project id} \
#   --zone {zone id} \
#   --machine-type {machine type}

# ex:
gcloud container clusters create k8s-cluster \
  --project project-id \
  --zone asia-southeast1-a \
  --machine-type e2-micro

Replace the placeholders for the cluster name, project ID, zone, and machine type as needed.

As mentioned earlier, when deploying projects to Kubernetes, the main difference lies in how you build the Docker image, which varies by project type. Once you have the Docker image, the content of the deployment.yml file will be similar to the one used for deploying a NodeJS application. You just need to update the image and port information accordingly.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-name
  labels:
    name: label-name
spec:
  replicas: 1
  selector:
    matchLabels:
      app: label-name
  template:
    metadata:
      labels:
        app: label-name
    spec:
      containers:
        - name: react-ts
          image: gcr.io/{project id}/react-ts # or use image from docker hub
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: service-name
  labels:
    service: label-name
spec:
  selector:
    app: label-name
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80 # port service
      targetPort: 80 # port pod

Note that if the Docker image built earlier uses Nginx, it will default to using port 80.

After that, apply to initialize the resources:

Wait a moment to check that the pod, service, and deployment have been successfully created:

Then, access the EXTERNAL-IP of the LoadBalancer to see the results.

To delete the resources, use the following command:

Conclusion

Through this article, you've learned how to deploy a React project to Google Kubernetes Engine. You can apply the same process to deploy other front-end projects like Angular and VueJS. Just build the project into static files and successfully build the Docker image. The following steps will be the same.

Feel free to share your thoughts in the comments!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting:

Using Nginx on Docker

chauhoangminhnguyen — Tue, 10 Sep 2024 14:00:00 +0000

Introduction

Nginx is a popular open-source web server known for its superior performance compared to the Apache web server. Nginx supports various functionalities, including deploying an API gateway (reverse proxy), load balancer, and email proxy. It was initially developed to build a web server capable of efficiently handling 10,000 concurrent connections with low memory usage.

Run Nginx with Docker

To use Nginx with Docker, simply execute the following command:

docker run -dp 8080:80 nginx:alpine

By default, Nginx uses port 80, but you can map it to a different port if needed.

Custom Nginx Configuration

To customize the Nginx configuration, first, create a docker-compose.yml file with the following content:

services:
  serviceName:
    image: nginx:alpine
    ports:
      - 8080:80
    volumes:
      - ./default.conf:/etc/nginx/conf.d/default.conf
      - ./index.html:/usr/share/nginx/html/index.html

In the volumes field, note that I have mapped two files: default.conf to change the default Nginx configuration and index.html to customize the default interface when accessing the Nginx web view.

The content of the default.conf file is as follows:

server {
  listen 80 default_server;
  listen [::]:80 default_server;

  server_name _;
  root /usr/share/nginx/html;

  location / {
  }
}

This is the content of the index.html file, which you can modify as needed:

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Nginx</title>
</head>

<body>
  <h1>This is custom index page</h1>
</body>

</html>

After that, run Docker Compose with the following command:

docker compose up -d

The result will be as follows:

If you found value in this post, show your appreciation by sharing and commenting!

If you found this content helpful, please visit the original article on my blog to support the author and explore more interesting content.

Some series you might find interesting: