DEV Community: Harsh Makwana

Setting Up a Monolith Application with Kubernetes

Harsh Makwana — Thu, 06 Jul 2023 15:48:21 +0000

Kubernetes is a powerful container orchestration tool that can help you manage and deploy your monorepo application. This blog covers the basics of Kubernetes and how to use it for application deployment. By the end of this blog, you should understand Kubernetes well and be able to deploy your application using it.

Introduction

Kubernetes, an open-source platform, simplifies managing and scaling containerized applications. By automating deployment, scaling, and management across multiple hosts, it enhances infrastructure efficiency and reliability. Kubernetes ensures containers run where they should and maintain the desired application state.

Kubernetes creates a cluster of nodes, with a master node controlling and managing the entire cluster. The master node makes decisions about deploying, scaling, and scheduling containers.

Kubernetes supports automatic scaling, load balancing, and self-healing, efficiently managing multiple containers and services. Developers can focus on building and delivering applications while Kubernetes manages containers at scale.

Now, let’s dive deep into Kubernetes architecture.

Key Components of Kubernetes

Pod

The smallest component of Kubernetes is the pod. A pod serves as a wrapper for a Docker container, representing a single instance of a running process in a cluster. Pods are designed to be ephemeral, meaning they can be created, destroyed, and replaced as needed.

Node

A node, also known as a worker node, is a space within a cluster where multiple instances of pods are deployed. Each node has limited capacity based on its storage and memory allocation.

Node Group

A collection of nodes forms a node group. Node groups are used in cluster deployments to organize and manage worker nodes based on specific criteria such as hardware specifications, availability zones, regions, or other desired attributes.

Service

In Kubernetes, a service routes traffic from outside the node to multiple pods running the same application containers. It acts as an internal load balancer, distributing network traffic across the pods that are part of the service.

There are different types of services in Kubernetes:

NodePort: This service type exposes the service on a specified port on each selected node in the cluster. It creates a port range and forwards traffic to the service.

ClusterIP: This default service type exposes the service on an internal cluster IP address, making it accessible only within the cluster.

LoadBalancer: This service type creates an external load balancer and assigns a unique IP address. It automatically routes and distributes incoming traffic.

Ingress: Ingress manages external traffic (traffic coming from outside the cluster) and provides a way to configure routes to handle services based on defined rules. It acts as an entry point for incoming traffic into the cluster. However, ingress does not handle load balancing by itself; it relies on an ingress controller, which continuously monitors resources within the cluster and manages external traffic.

For more understanding, refer to the image below.

Deployment

A Deployment is an API object in Kubernetes that provides a declarative YAML configuration specifying parameters such as the desired number of replicas, the container image to use, environment variables, resource limits, and more. This configuration allows you to deploy and manage the lifecycle of your applications.

To increase the number of replicas for the same container, you simply change the value of the “replicas” key in the configuration file. This will create additional pods of the same container, ensuring scalability and availability of your application.



apiVersion: apps/v1
kind: Deployment
metadata:
  name: server-deployment
  labels:
    app: server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: server
  template:
    metadata:
      labels:
        app: server
    spec:
      containers:
        - name: server
          image: server:latest
          imagePullPolicy: Never
          ports:
            - containerPort: 3000
          resources:
            limits:
              memory: "256Mi"
              cpu: "1000m"
          envFrom:
            - secretRef:
                name: secret

In addition to the Deployment YAML file, there is a standard way to manage environment variables using Secrets. Secrets store sensitive information, such as passwords and tokens, in a secure format. For more information on how to manage Secrets with kubectl, check out this page.



apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: secret
data:
  NODE_ENV: ZGV2ZWxvcG1lbnQ=
  PORT: MzAwMA==

To deploy your application, you will also need a Service file. This file ensures that the deployment works correctly by attaching the same metadata and selector names used in the Deployment file. This consistency allows the master node to identify the application’s resources accurately.



apiVersion: v1
kind: Service
metadata:
  name: server-service
spec:
  selector:
    app: server
  type: NodePort
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000
      nodePort: 31110

Conclusion

Kubernetes offers horizontal scalability, enabling you to scale your applications by easily adding or removing pods. It ensures application availability by distributing pods across multiple nodes using services, and supports minimal downtime through rolling upgrades, automatic rescheduling, and replacement on healthy nodes in the event of node failure.

In the next blog, we will explore the usage of Helm charts and their application in microservices.

Thanks for reading! If you have any queries, feel free to email me at harsh.make1998@gmail.com.

Until next time!

Centralised logging in microservices using Grafana stack and Fluent-bit

Harsh Makwana — Wed, 15 Mar 2023 16:13:06 +0000

In this blog, we will explore how to set up a Grafana stack and Fluent-bit on Docker, alongside a Node.js application.

Introduction to the Stack:

The Grafana stack includes three main components: Grafana (an admin web portal), Loki (a datastore for logs), and Fluent-bit (a log collector). Here’s a brief overview of their purposes:

Fluent-bit: Fetches logs from the origin server, applies filters, and sends them to the datastore.

Loki: Stores logs with indexing and metadata.

Grafana: Analyzes, queries, and monitors your service via an Admin UI running on an individual system.

Additionally, the ELK stack (Elasticsearch, Logstash, Kibana) can be used for log aggregation and monitoring in microservices applications. Let’s compare these two stacks.

Elasticsearch:

Elasticsearch is a search engine tool built with Lucene. It stores unstructured data as JSON objects in its datastore, collected from Logstash, and visualizes logs through Kibana.

Elasticsearch indexes all contents provided by Logstash and stores them as documents. This makes all keys in the document searchable, requiring more storage space.

Loki:
Loki is a log aggregation tool that stores data as key-value pairs and includes labels with the log data.

Data Storage: Data in Loki is searchable by labels, resulting in lower indexing and more efficient storage.

What to use:
Loki: Ideal for storage efficiency and handling fewer log streams, as it uses less storage space and fetches logs based on labels.

Elasticsearch: Suitable for large datasets with detailed logs, as it indexes all fields and allows quick searchability.

Integration of the Grafana Stack with Docker

 fluent-bit:
    environment:
      LOG_LEVEL: debug
      LOKI_URL: http://loki:3100/loki/api/v1/push
    build:
      context: ./fluent-bit
      dockerfile: Dockerfile
    ports:
      - "24224:24224"
      - "24224:24224/udp"
    networks:
      - backend
  loki:
    image: grafana/loki:latest
    expose:
      - "3100"
    networks:
      - backend
  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      GF_RENDERING_SERVER_URL: http://renderer:8081/render
      GF_RENDERING_CALLBACK_URL: http://grafana:3000/
      GF_LOG_FILTERS: rendering:debug
    networks:
      - backend
  renderer:
    image: grafana/grafana-image-renderer:latest
    expose:
      - "8081"
    environment:
      ENABLE_METRICS: "true"
    networks:
      - backend
networks:
  backend:
    driver: bridge

Here, we’re using the custom image of Fluent-bit as we’re using it for the Grafana stack. Grafana provides its Fluent-bit image for integration with Loki. You can check out the documentation here.

Create a fluent-bit folder at the root of your project, and within that folder, create a Dockerfile.

FROM grafana/fluent-bit-plugin-loki:latest
COPY ./conf/fluent.conf /fluent-bit/etc/fluent-bit.conf

Create a fluent-bit folder at the root of your project. Within that folder, create a Dockerfile, and a conf folder to hold the configuration files.

[INPUT]
    Name        forward
    Listen      0.0.0.0
    Port        24224
[Output]
    Name grafana-loki
    Match *
    Url ${LOKI_URL}
    RemoveKeys source
    Labels {job="fluent-bit"}
    LabelKeys container_name
    BatchWait 1s
    BatchSize 1001024
    LineFormat json
    LogLevel ${LOG_LEVEL}

We're passing LOKI_URL here as an environment variable.

To update the logging in the docker container update the docker-compose configuration for the server in your docker-compose.yml file.

 order-service:
    build:
      context: ./order-service
      dockerfile: Dockerfile
    restart: on-failure
    ports:
      - "9001:9001"
    env_file:
      - ./order/.env
    networks:
      - backend
    volumes:
      - ./order:/app/order
      - /app/order/node_modules
    logging:
      driver: fluentd
      options:
        fluentd-async: "true"
        fluentd-address: localhost:24224
        tag: order-service

In the Docker Compose configuration, the logging driver used is fluentd since Fluent-bit is part of the Fluentd ecosystem. The option fluentd-async: true enables an asynchronous connection with the Fluent-bit instance within the Docker environment, ensuring that the order service starts without errors. The tag option will be used in the Grafana UI to identify each service.

To start your microservice application, run the command docker-compose up in the terminal. This will start all Docker containers simultaneously.

According to the Docker Compose configuration file, the Grafana instance should be running on port 3000. Open Grafana in any browser by visiting http://localhost:3000. Use the default username admin and password admin to access the portal. You will be prompted to set your preferred password after logging in.

After login, it will show the dashboard screen.

Click on add a data source.

Click on Loki and enter URL: http://loki:3100 as we're using loki in docker. so we can use the docker container name to access the service in localhost.

Click on save & test, it will save the data source in grafana admin. and then click on explore to open the query dashboard.

Click on run query to show logs for every job that is available in the grafana stack. if you're looking for specific logs of any service. you can query logs from the log browser.

To learn more about the query language, you can check out the documentation provided by grafana on logQL.

Conclusion:
Adding centralized logging simplifies debugging and monitoring of a microservice application by providing a single UI to oversee all services. This approach becomes increasingly beneficial as the number of services in the system grows, making it challenging to monitor them individually on a cloud platform. Choosing the right logging stack can significantly improve the debugging process, especially when dealing with production application crashes.

Thanks for reading this. If you have any queries, feel free to email me at harsh.make1998@gmail.com.

Until next time!

Create NestJS Microservices using RabbitMQ - Part 2

Harsh Makwana — Tue, 14 Mar 2023 18:48:31 +0000

In the previous blog, we learned the basics of communication between two services using NestJS and RabbitMQ. In this blog, we will explore another concept in NestJS: the Event pattern. Using event patterns, we can create a worker for a microservice that will handle jobs created by other services.

This example will help you understand basic communication using event patterns. We will use Prisma as an ORM for the PostgreSQL database. Prisma is a type-safe ORM that provides built-in support for TypeScript types and generates migrations. Check out the Prisma documentation for more details.

First, let’s start up the core services from the previous blog using the docker-compose.yml file.

docker-compose up

now, we can start creating forgot password APIs for user service.

Creating Forgot Password APIs for the User Service

In the main.ts file of the user service, update the bootstrap function:

const logger = new Logger();
const configService = new ConfigService();
app.connectMicroservice({
  transport: Transport.RMQ,
  options: {
    urls: [`${configService.get('rb_url')}`],
    queue: `${configService.get('auth_queue')}`,
    queueOptions: { durable: false },
    prefetchCount: 1,
  },
});
await app.startAllMicroservices();
await app.listen(9001);
logger.log('User service started successfully');

In the app.controller.ts file of the user service, create a controller for the forgot password API:

@Public()
@Post('/forgot-password')
forgotPassword(@Body() data: ForgotPasswordDto): Promise<void> {
  return this.appService.sendForgotPasswordEmail(data);
}

In the app.service.ts file of the user service, implement the sendForgotPasswordEmail function:

public async sendForgotPasswordEmail(data: ForgotPasswordDto) {
  try {
    const { email } = data;
    const user = await this.getUserByEmail(email);
    if (!user) {
      throw new HttpException('user_not_found', HttpStatus.NOT_FOUND);
    }
    const token = nanoid(10);
    await this.prisma.token.create({
      data: {
        expire: new Date(new Date().getTime() + 60000),
        token,
        user: {
          connect: {
            email,
          },
        },
      },
    });
    const payload: IMailPayload = {
      template: 'FORGOT_PASSWORD',
      payload: {
        emails: [email],
        data: {
          firstName: user.first_name,
          lastName: user.last_name,
        },
        subject: 'Forgot Password',
      },
    };
    this.mailClient.emit('send_email', payload);
  } catch (e) {
    throw e;
  }
}

Here, we use mailClient with the emit function to send a payload to the connected service. Unlike send, emit does not expect a response.

Creating the Mailer Service

Use the NestJS CLI to create a new mailer service. In the main.ts file of the mailer service, update the bootstrap function:

const logger = new Logger();
const configService = new ConfigService();
const app = await NestFactory.createMicroservice<MicroserviceOptions>(
  AppModule,
  {
    transport: Transport.RMQ,
    options: {
      urls: [`${configService.get('rb_url')}`],
      queue: `${configService.get('mailer_queue')}`,
      queueOptions: { durable: false },
      prefetchCount: 1,
    },
  },
);
await app.listen();
logger.log('Mailer service started successfully');

In the user service, define the mailer service dependency in the app.module.ts file:

ClientsModule.registerAsync([
  {
    name: 'MAIL_SERVICE',
    imports: [ConfigModule],
    useFactory: (configService: ConfigService) => ({
      transport: Transport.RMQ,
      options: {
        urls: [`${configService.get('rb_url')}`],
        queue: `${configService.get('mailer_queue')}`,
        queueOptions: {
          durable: false,
        },
      }),
    }),
    inject: [ConfigService],
  },
]),

In the app.service.ts file of the user service, inject and connect the mailer service:

constructor(
  @Inject('MAIL_SERVICE') private readonly mailClient: ClientProxy,
  private prisma: PrismaService,
) {
  this.mailClient.connect();
}

In the app.controller.ts file of the mailer service, define the send_email event pattern:

@EventPattern('send_email')
public sendEmailPattern(@Payload() data): void {
  this.appService.sendEmail(data);
}

In the app.service.ts file of the mailer service, create an AWS SES instance and a function for sending emails. Update the templatePath as per your project structure:

 private ses: SES;
constructor(private configService: ConfigService) {
  this.logger = new Logger();
  this.ses = new SES({
    ...this.configService.get('aws'),
  });
}

async function sendEmail(job: {
  data: { template: EmailTemplates; payload: any };
}) {
  const { template, payload } = job.data;
  const templatePath = join(
    __dirname,
    './templates/',
    `${EmailTemplates[template]}.html`,
  );
  let _content = readFileSync(templatePath, 'utf-8');
  const compiled = _.template(_content);
  _content = compiled(payload.data);
  this.ses
    .sendEmail({
      Source: this.configService.get('sourceEmail'),
      Destination: {
        ToAddresses: payload.emails,
      },
      Message: {
        Body: {
          Html: {
            Charset: 'UTF-8',
            Data: _content,
          },
        },
        Subject: {
          Charset: 'UTF-8',
          Data: payload.subject,
        },
      },
    })
    .promise()
    .catch((error) => this.logger.error(error));
}

The mailer service does not have any open ports since it does not expose any APIs. This service will send forgot password token links to users via email.

Scalability Considerations

Using RabbitMQ as the connection between services, we can scale RabbitMQ on AWS to handle increased incoming requests. This ensures sufficient computing power is available to process the mailer queue’s requests.

Complete Example

I have created a complete example of microservices using NestJS and RabbitMQ on Github. If you have any suggestions or issues, feel free to create issues/PRs on GitHub.

Thanks for reading this. If you have any queries, feel free to email me at harsh.make1998@gmail.com.

Until next time!

Create NestJS Microservices using RabbitMQ - Part 1

Harsh Makwana — Sun, 06 Feb 2022 18:05:12 +0000

In this tutorial, we will build a microservices architecture using NestJS and RabbitMQ. We’ll also demonstrate how to containerize the NestJS microservice application with Docker and Docker Compose.

Technology Stack Overview
We will use the following technology stack:

NestJS: A progressive Node.js framework that adopts a structure similar to Angular. It provides features like dependency injection, TypeScript support, internal microservices, and communication protocol support. For more details, check out the NestJS documentation.

RabbitMQ: A reliable and efficient message broker that uses the AMQP protocol to facilitate communication between microservices.

Postgres with TypeORM: Our database solution, with built-in support in NestJS for TypeORM.

We will follow a specific pattern for the microservices architecture to ensure scalability and maintainability.

main repo
- user (NestJS project)
  - Dockerfile
- token (NestJS project)
  - Dockerfile
.gitsubmodules - contains configs of git submodules used in main repo
docker-compose.yml - contains runtime environment configurations

Let's configure the docker-compose file,

version: "3"
services:
  postgres:
    image: postgres:latest
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=admin
      - POSTGRES_PASSWORD=master123
      - POSTGRES_DB=postgres
    volumes:
      - pg_data:/var/lib/postgresql/data
    networks:
      - backend

  rabbitmq:
    image: rabbitmq:3-management
    volumes:
      - rabbit_data:/var/lib/rabbitmq
    ports:
      - "5672:5672"
      - "15672:15672"
    networks:
      - backend

  user-service:
    build:
      context: ./user
      dockerfile: Dockerfile
    ports:
      - "3001:3000"
    environment:
      - NODE_ENV=development
      - DATABASE_URL=postgres://admin:master123@postgres:5432/postgres
      - RABBITMQ_URL=amqp://rabbitmq
    depends_on:
      - postgres
      - rabbitmq
    networks:
      - backend

  token-service:
    build:
      context: ./token
      dockerfile: Dockerfile
    ports:
      - "3002:3000"
    environment:
      - NODE_ENV=development
      - DATABASE_URL=postgres://admin:master123@postgres:5432/postgres
      - RABBITMQ_URL=amqp://rabbitmq
    depends_on:
      - postgres
      - rabbitmq
    networks:
      - backend

networks:
  backend:
    driver: bridge

volumes:
  pg_data:
    driver: local
  rabbit_data:
    driver: local

Setting Up the User Service:
Create a fresh NestJS project for the user service using the Nest CLI. In the main.ts file, configure the microservice:

app.connectMicroservice({
  transport: Transport.RMQ,
  options: {
    urls: [`${configService.get('rb_url')}`],
    queue: `${configService.get('user_queue')}`,
    queueOptions: { durable: false },
    prefetchCount: 1,
  },
});

await app.startAllMicroservices();
await app.listen(configService.get('servicePort'));
logger.log(`User service running on port ${configService.get('servicePort')}`);

Next, in the controller file, develop the routing:

@Post('/signup')
signup(@Body() data: CreateUserDto): Promise<IAuthPayload> {
  return this.appService.signup(data);
}

Now, create token service in another NestJs project. and in the main.ts file

const app = await NestFactory.createMicroservice<MicroserviceOptions>(
  AppModule,
  {
    transport: Transport.RMQ,
    options: {
      urls: [`${configService.get('rb_url')}`],
      queue: `${configService.get('token_queue')}`,
      queueOptions: { durable: false },
    },
  },
);
await app.listen();
logger.log('Token service started');

In the app.controller.ts file, add message patterns to communicate between services:

@MessagePattern('token_create')
public async createToken(@Payload() data: any): Promise<ITokenResponse> {
  return this.appService.createToken(data.id);
}

@MessagePattern('token_decode')
public async decodeToken(
  @Payload() data: string,
): Promise<string | JwtPayload | IDecodeResponse> {
  return this.appService.decodeToken(data);
}

In app.service.ts, add the generate token function:

public createToken(userId: number): ITokenResponse {
  const accessExp = this.configService.get('accessExp');
  const refreshExp = this.configService.get('refreshExp');
  const secretKey = this.configService.get('secretKey');
  const accessToken = sign({ userId }, secretKey, { expiresIn: accessExp });
  const refreshToken = sign({ userId }, secretKey, { expiresIn: refreshExp });
  return {
    accessToken,
    refreshToken,
  };
}

public async decodeToken(
  token: string,
): Promise<string | JwtPayload | IDecodeResponse> {
  return decode(token);
}

Connecting User Service to Token Service
Add the following lines to app.module.ts to inform the user service that we are using the token service:

import: [
  ClientsModule.registerAsync([
    {
      name: 'TOKEN_SERVICE',
      imports: [ConfigModule],
      useFactory: (configService: ConfigService) => ({
        transport: Transport.RMQ,
        options: {
          urls: [`${configService.get('rb_url')}`],
          queue: `${configService.get('token_queue')}`,
          queueOptions: {
            durable: false,
          },
        },
      }),
      inject: [ConfigService],
    },
  ]),
]

In app.service.ts of the user service, connect to the token service:

constructor(
  @Inject('TOKEN_SERVICE') private readonly tokenClient: ClientProxy,
) {
  this.tokenClient.connect();
}

Implement the signup function in app.service.ts of the user service:

public async signup(data: CreateUserDto) {
  try {
    const { email, password, firstname, lastname } = data;
    const checkUser = await this.userRepository.findUserAccountByEmail(email);
    if (checkUser) {
      throw new HttpException('USER_EXISTS', HttpStatus.CONFLICT);
    }
    const hashPassword = this.createHash(password);
    const newUser = new User();
    newUser.email = data.email;
    newUser.password = hashPassword;
    newUser.firstName = firstname.trim();
    newUser.lastName = lastname.trim();
    newUser.role = Role.USER;
    const user = await this.userRepository.save(newUser);
    const createTokenResponse = await firstValueFrom(
      this.tokenClient.send('token_create', JSON.stringify(user)),
    );
    delete user.password;
    return {
      ...createTokenResponse,
      user,
    };
  } catch (e) {
    throw new InternalServerErrorException(e);
  }
}

Using RabbitMQ, the token client is a client proxy that is linked to the token service microservice instance. The ‘token_create’ message pattern response from the token service is handled using the Rxjs firstValueFrom method to transform the response from an observable to a promise.

For more examples and event patterns, check out the next part of the blog.

Thanks for reading this. If you have any queries, feel free to email me at harsh.make1998@gmail.com.

Until next time!