In an era dominated by personalized experiences, recommendation systems have become essential for businesses seeking to engage and retain customers. Amazon Personalize is a leading solution, offering advanced machine learning capabilities to tailor recommendations based on individual preferences. This article explores the transformative power of Amazon Personalize, delving into its ability to drive user engagement, boost conversions, and foster long-term customer loyalty. Join us as we uncover the key principles and benefits of building recommendation systems with Amazon Personalize.

In this article, you will learn how to use the Amazon Personalize service to create Recommendation systems for your applications. For the demonstration, we are going to use the popular MovieLens dataset. You can download the dataset from this link.

Creating Dataset Groups

A dataset group is a container for Amazon Personalize resources, including datasets, domain recommenders, and custom resources.

To create a Dataset Group, click on the "Create Dataset Group" button.

Mention the name of the Dataset Group and click "Next". This will create the new Dataset Group.

Once the Dataset Group creation is complete, select it to see the dashboard:

First, we are going to focus on the "Upload Datasets" section. Before continuing, please download the dataset from the link attached above.

Uploading the Datasets

We will start with uploading the User-item interaction data. Click on the "Import" button adjacent to it. This will open the "Configure Schema" form.

Mention the name of the dataset. Then move to the "Schema Details" section.

Select the "User Existing Schema" option, as we will use the existing "movie-ratings" schema for this project and modify it to create a new schema. The column names need to be updated based on our dataset. We can fix this in the code editor below.

In the Dataset you downloaded, there will be 4 .csv files. To decide the column names, open the links.csv file. Update the schema accordingly. After that, copy the JSON and paste it into the code editor after you select the "Create New Schema" radio button along with a new name of the schema. Hit the "Next" button.

On the next page, you need to upload the .csv file in an S3 bucket and mention the file location along with an IAM policy name to access the bucket.

Once completed, it will complete the uploading of the user-item interaction dataset.

In the same way, upload the users.csv and movies.csv in User and Item Data respectively.

This will complete the Uploading of all datasets required for the tutorial.

Solutions and Recipes

In the next step, we need to create a solution and attach a recipe to it. There are many recipes provided by the service. We can create multiple Solutions using different recipes to test out the performance between them.

You can create the solutions using the "Create Solution" form. Just mention a unique name to the solution and attach a recipe to it.

Creating a Campaign

Our tutorial's final step is creating a campaign to test the recommendation.

Select the name of the new campaign and select a solution you had created in the earlier step. Click on the "Create Campaign" button.

This will create the campaign. Once created, click on the newly created Campaign name and go to the "Personalization API" tab. To test the recommendation, go to the "Test Campaign Results" section.

Open the users.csv file and select a USER_ID and 4 MOVIE_IDs and paste them in the User ID and Item IDs field respectively. After that, click the "Get Personalized Rankings" button.

You should see the Item ranking table.

Thus, we have successfully got the order of personalization of movies for an user using the Amazon Personalize Service.

Conclusion

Amazon Personalize stands as a formidable tool for businesses looking to stay ahead in the competitive landscape of personalized experiences. By harnessing its advanced machine learning algorithms, companies can not only deliver tailored recommendations but also foster deeper connections with their audience. As we wrap up our exploration, it's evident that the implementation of recommendation systems powered by Amazon Personalize not only enhances user engagement and satisfaction but also drives tangible business growth. Embracing this technology enables businesses to stay agile, adaptive, and responsive to the evolving needs and preferences of their customers, ultimately securing a strong position in the digital marketplace.

In today's digital landscape, the proliferation of online transactions has brought immense convenience but also heightened risks of fraud. Recognizing the critical need for businesses to protect themselves and their customers, Amazon introduced the Fraud Detection Service (AFD). This innovative solution leverages advanced machine learning algorithms and real-time monitoring to detect and prevent fraudulent activities swiftly and effectively.

In this article, you will learn how you can use the Amazon Fraud Detection service to detect fraudulent entries during registration. We will be using the example dataset provided by Amazon to train our model. You can find the training dataset from this link.

Creating an event

First, let's start by creating an event. Open your AWS console and search for Amazon Fraud Detection service. Once on the page, click on the "Create event" button.

This will open the "Create Event Type" form. An event type defines the structure for an event sent to the service. In the Event Type Details section, enter a name and a description of the event. Next, we need to create an entity for the event. An entity represents who is performing the event. In the Entity creation form, enter the entity type name and description and create the entity. Select the newly created entity in the main form.

In the next section of the form, we need to provide the Training Data. But first, we need to select how do we want to define the event variables. In our case, we want to select the variables from the Training Dataset. The very important thing to note that for this demo, we are going to upload the training dataset file to a S3 storage bucket, which needs to be created in the same region of the Fraud Detection Service. In this form, we are going to create an IAM role which will give the service, the permission to access the S3 bucket. Then we are going to specify the location of the file. Before doing this, please create an S3 bucket and upload the dataset into it.

Once you paste the proper location of the dataset file, you will see the Variables and Variable Type table. In this table, you need to map each variable to an known variable type.

Next, in the Labels Section, please mention at least 2 labels: Fraud and Legit.

Finally, you can submit the form.

Specifying Model Details

Once the event is created, lets move to the Model section, where we are going to select the suitable model for our use-case and train it with the training dataset.

Click on the "Add your first model" button. In the "Define Model Details", mention the model name and select the "Online Fraud Insights" model type. Finally select the event you had previously created in this form.

This will open the "Historical event data" section. Here, you need to select the event source as data stored in S3. For the IAM role, mention the same bucket name if you want to keep the model output files in the same bucket. Then, again mention the location of the training dataset and click Next.

In the next page, you need to select a specific label for Fraud and Legitimate.

Clicking "Next" will take you to the review page. Finally you can click the "Create and Train Model" button to start the training process.

Now, we need to wait for sometime to complete the model training process. Once completed, you can see the model performance metrics.

Finally, you can deploy the model version.

Create the Detector

Detectors are comprised of Models and rules that evaluates the event for fraud.

Click on the "Create Detector" button to open the form. Fill in the name, description and the event type for the detector and Click "Next".

In the following page, you need to add the Model you created in the earlier section.

After that, you need to add the rules for the detector. We are going to make 3 rule: fraud_rule, legit_rule & review_rule.

In the "Add Rules" page, mention the name and description of the respective rules. Then, you need to add the Expression using the Service's Expression language. The expression generally consists of some event variables or model output scores. In this scenario, we will be using the model output score.

For the fraud_rule, the output score should be greater than 900. The outcome should be risk_high.

For the legit_rule, the output score should be less than 700. The outcome should be risk_low.

For the review_rule, the output score should be greater than 700 but less than 900. The outcome should be risk_medium.

Finally you will see 3 rules listed in the page.

In the next step, you need to configure the order of the rule execution. For the Execution mode, select the "First Matched" option and continue.

Finally review the information and submit the form to create the detector.

This completes all the steps that are required to setup the Fraud Detection service for our application.

Testing the Model

To test the model, you can take some data from the dataset and paste it in the fields of the "Run Tests" section. Once entered, you can see the prediction at the bottom.

Conclusion

As businesses navigate the complex and ever-evolving landscape of online transactions, the importance of robust fraud detection and prevention measures cannot be overstated. Amazon's Fraud Detection Service emerges as a powerful ally in this endeavor, offering advanced technology and real-time insights to safeguard against fraudulent activities. By leveraging AFD, businesses can not only protect themselves and their customers but also enhance their overall operational efficiency and reputation. As we conclude our exploration of AFD, it's clear that investing in such cutting-edge solutions is not just a proactive step—it's a fundamental necessity in today's digital economy.

GitOps modernizes software management and operations by allowing developers to declaratively manage infrastructure and code using a single source of truth, usually a Git repository. Many development teams and organizations have adopted GitOps procedures to improve the creation and delivery of software applications.

For a GitOps initiative to work, an orchestration system like Kubernetes is crucial. The number of incompatible technologies needed to develop software makes Kubernetes a key tool for managing infrastructure. Without Kubernetes, implementing infrastructure-as-code (IaC) procedures is inefficient or even impossible. Fortunately, the wide adoption of Kubernetes has enabled the creation of tools for implementing GitOps.

One of these tools, ArgoCD, is a Kubernetes-native continuous deployment (CD) tool. It can deploy code changes directly to Kubernetes resources by pulling it from Git repositories instead of an external CD solution. Many of these solutions support only push-based deployments. Using ArgoCD gives developers the ability to control application updates and infrastructure setup from a unified platform. It handles the latter stages of the GitOps process, ensuring that new configurations are correctly deployed to a Kubernetes cluster.

In this tutorial, you will learn how to deploy a Node.js application on Azure Kubernetes Service (AKS) using a CI/CD pipeline and ArgoCD.

Prerequisites

To follow along with this tutorial, you will need a few things first.

Accounts for:

• Docker Hub

• GitHub

• Microsoft Azure

• CircleCI

These tools installed on your system:

• Kubectl

• ArgoCD CLI

• Azure CLI

• Node JS

• Docker Engine

After you have all the prerequisites complete you are ready to go to the next section.

Cloning the Node.js application

In this tutorial, the main focus is on deploying the application on Kubernetes. You can directly clone the Node.js application to your GitHub and continue with the rest of the process.

To clone the project, run:

git clone https://github.com/CIRCLECI-GWP/aks-nodejs-argocd.git

There are 2 branches in this repository:

• main branch contains only the Node.js Application code

• circleci-project-setup branch contains the application codes along with all YAML files that you will create

Check out to the main branch.

The Node.js application lives in the app.js file and contains:

const express = require("express");
const path = require("path");
const morgan = require("morgan");
const bodyParser = require("body-parser");
/* eslint-disable no-console */
const port = process.env.PORT || 1337;
const app = express();
app.use(morgan("dev"));
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: "true" }));
app.use(bodyParser.json({ type: "application/vnd.api+json" }));
app.use(express.static(path.join(__dirname, "./")));
app.get("*", (req, res) => {
  res.sendFile(path.join(__dirname, "./index.html"));
});
app.listen(port, (err) => {
  if (err) {
    console.log(err);
  } else {
    console.log(`App at: http://localhost:${port}`);
  }
});
module.exports = app;

The key takeaway from this code is the port number, This is where the application will be running, which is 1337 for this tutorial.

You can run the application locally by first installing the dependencies. In the project’s root, type:

npm install

Then run the application with the command:

node app.js

The application should now be up and running at the address http://localhost:1337.

Containerizing the Node.js application

To deploy the application of Kubernetes you need to containerize it. To containerize applications using Docker as the container runtime tool, you will create a Dockerfile. A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image.

Create a new file in the root directory of the project and name it Dockerfile. Copy the following content in the file:

# Set the base image to use for subsequent instructions
FROM node:alpine
# Set the working directory for any subsequent ADD, COPY, CMD, ENTRYPOINT,
# or RUN instructions that follow it in the Dockerfile
WORKDIR /usr/src/app
# Copy files or folders from source to the dest path in the image's filesystem.
COPY package.json /usr/src/app/
COPY . /usr/src/app/
# Execute any commands on top of the current image as a new layer and commit the results.
RUN npm install --production
# Define the network ports that this container will listen to at runtime.
EXPOSE 1337
# Configure the container to be run as an executable.
ENTRYPOINT ["npm", "start"]

If you have Docker installed, you can build and run the container locally for testing. Later on in this tutorial, you will learn how to automate this process with CircleCI orbs.

To build and tag the container, enter:

docker build -t aks-nodejs-argocd:latest .

Confirm that the image was successfully created by running this command from your terminal:

docker images

Then run the container using the command:

docker run -it -p 1337:1337 aks-nodejs-argocd:latest

The application should now be up and running at the address http://127.0.0.1:1337.

Commit and push the changes to your GitHub repository.

Configuring Kubernetes manifests for deployment

To deploy containers on Kubernetes, you will have to configure Kubernetes to incorporate all the settings required to run your application. Kubernetes uses YAML for configuration.

Create a directory named manifests in the root directory of the project. Then create these files in the newly created folder:

• namespace.yaml

• deployment.yaml

• service.yaml

• kustomization.yaml

In Kubernetes, namespaces provide a mechanism for isolating groups of resources within a single cluster. The contents of the namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: nodejs
  labels:
    name: nodejs

This file would create a namespace named nodejs inside the Kubernetes cluster. All the resources would be created in this namespace.

Kubernetes Deployments manage stateless services running on your cluster. Their purpose is to keep a set of identical pods running and upgrade them in a controlled way – performing a rolling update by default. The contents of the deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nodejs
  namespace: nodejs
  labels:
    app: nodejs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nodejs
  template:
    metadata:
      labels:
        app: nodejs
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": linux
      containers:
        - name: aks-nodejs-argocd
          image: aks-nodejs-argocd
          ports:
            - name: http
              containerPort: 1337

The key takeaway from this code is the containerPort. This is where the application will be running and where the container-image will be pulled and deployed in the namespace on the Kubernetes cluster.

Kubernetes Service is an abstraction that defines a logical set of pods and a policy for accessing them. You need the Kubernetes Service type LoadBalancer to make the deployment accessible to the outside world.
The contents of the service.yaml are:

apiVersion: v1
kind: Service
metadata:
  name: nodejs
  namespace: nodejs
  labels:
    app: nodejs
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 1337
  selector:
    app: nodejs

The key takeaway from this code is the targetPort, port and type:

• targetPort is the container port

• port is where the application will be running

• type is the type of service

To deploy the latest version of the application on the Kubernetes cluster, the resources have to be customized to maintain the updated information. You can use Kustomize, which is a tool for customizing Kubernetes configurations.

The contents of the kustomization.yaml are:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml
  - namespace.yaml
namespace: nodejs
images:
  - name: aks-nodejs-argocd
    newName: aks-nodejs-argocd
    newTag: v1

The key takeaway from this code is newName and newTag, which will be updated with the latest Docker image information as part of the continuous integration process.

Commit and push these files into the main branch of the GitHub repository you had cloned earlier.

Launching the Azure Kubernetes Service (AKS) cluster

In this tutorial, you will be deploying the application on the AKS cluster. To create the AKS cluster, the Azure CLI should be connected to your Azure account.

To launch an AKS cluster using the Azure CLI, create a Resource Group with this command:

az group create --name NodeRG --location eastus

Launch a two-node cluster:

az aks create --resource-group NodeRG --name NodeCluster --node-count 2 --enable-addons http_application_routing

Note: If you generated any SSH keys in your system previously, you need to add the optional --generate-ssh-keys parameter to this command. This auto-generates SSH public and private key files if they are missing. The keys are stored in the ~/.ssh directory.

The AKS cluster will take 10 to 15 minutes to launch.

Installing ArgoCD in the AKS Cluster

Once the cluster is up and running, you can install ArgoCD inside the cluster. You will use ArgoCD for deploying your application.

To install the application, use the Azure CLI. Configure kubectl to connect to AKS using this command:

az aks get-credentials --resource-group NodeRG --name NodeCluster

To install ArgoCD, use these commands:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

ArgoCD will be installed in the argocd namespace. To get all the resources in the namespace enter:

kubectl get all --namespace argocd

Exposing the ArgoCD API server

By default, the ArgoCD API server is not exposed to an external IP. Because you will access the application from the internet during this tutorial, you need to expose the ArgoCD server with an external IP via Service Type Load Balancer.

Change the argocd-server service type to LoadBalancer:

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

Note: You can also use Kubectl port forwarding to connect to the API server without exposing the service. Use this command: kubectl port-forward svc/argocd-server -n argocd 8080:443

You can now access the API server using https://localhost:8080.

Accessing the ArgoCD Web Portal

Once you have exposed the ArgoCD API server with an external IP, you can now access the portal with the external IP address you generated.

ArgoCD is installed in the argocd namespace. Use this command to get all the resources in the namespace:

kubectl get all --namespace argocd

Copy the External-IP corresponding to service/argocd-server.

You can access the application at http://<EXTERNAL-IP>.
In my case, that was http://20.237.108.112/

To log into the portal, you will need the username and password. The username is set as admin by default.

To fetch the password, execute this command:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

Use this username/password combination to log into the ArgoCD portal.

Configuring Kubernetes manifests for ArgoCD

To configure ArgoCD to deploy your application on Kubernetes, you will have to set up ArgoCD to connect the Git Repository and Kubernetes in a declarative way using YAML for configuration.

Apart from this method, you can also set up ArgoCD from the Web Portal or use the ArgoCD CLI. Because this tutorial is following GitOps principles, we are using the Git repository as the sole source of truth. Therefore the declarative method using YAML files works best.

One of the key features and capabilities of ArgoCD is to sync via manual or automatic policy for the deployment of applications to a Kubernetes cluster.

To get started, create a directory named argocd in the root directory of the project. Create a new file in the new directory and name it config.yaml.

Manual Sync Policy

Use this policy to manually synchronize your application by way of your CI/CD pipelines. Whenever a code change is made, the CI/CD pipeline is triggered and calls the ArgoCD server APIs to start the sync process based on the changes you will commit. For communicating with the ArgoCD server APIs, you can use the ArgoCD CLI. You can also use one of the SDKs available for various programming languages.

For setting up the Manual Sync policy for ArgoCD, paste this in the config.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: aks-nodejs-argocd
  namespace: argocd
spec:
  destination:
    namespace: nodejs
    server: "https://kubernetes.default.svc"
  source:
    path: manifests
    repoURL: "https://github.com/Lucifergene/aks-nodejs-argocd"
    targetRevision: circleci-project-setup
  project: default

Automated Sync policy

ArgoCD can automatically sync an application when it detects differences between the desired manifests in Git and the live state in the cluster.

A benefit of automatic sync is that CI/CD pipelines no longer need direct access to the ArgoCD API server to perform the deployment. Instead, the pipeline makes a commit and pushes to the Git repository with the changes to the manifests in the tracking Git repo.

If you want to set to the Automated Sync policy, you need to paste this in the config.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: aks-nodejs-argocd
  namespace: argocd
spec:
  destination:
    namespace: nodejs
    server: "https://kubernetes.default.svc"
  source:
    path: manifests
    repoURL: "https://github.com/Lucifergene/aks-nodejs-argocd"
    targetRevision: circleci-project-setup
  project: default
  syncPolicy:
    automated:
      prune: false
      selfHeal: false

Commit and push these files into the main branch of the GitHub repository you cloned earlier.

Creating the continuous integration pipeline

The objective of this tutorial is to show how you can deploy applications on Kubernetes through continuous integration (CI) using CircleCI and continuous deployment (CD) via ArgoCD. The CI pipeline should trigger the process of building the container and pushing it to Docker Hub, and the CD should deploy the application on Kubernetes.

To create the CI pipeline, you will be using CircleCI integrated with your GitHub account. CircleCI configuration is named config.yml and lives in the .circleci directory in the project’s root folder. The path to the configuration is .circleci/config.yml.

The content config.yml is:

version: 2.1

orbs:
  docker: circleci/docker@2.1.1
  azure-aks: circleci/azure-aks@0.3.0
  kubernetes: circleci/kubernetes@1.3.0

jobs:
  argocd-manual-sync:
    docker:
      - image: cimg/base:stable
    parameters:
      server:
        description: |
          Server IP of of ArgoCD
        type: string
      username:
        description: |
          Username for ArgoCD
        type: string
      password:
        description: |
          Password for ArgoCD
        type: string
    steps:
      - run:
          name: Install ArgoCD CLI
          command: |
            URL=https://<< parameters.server >>/download/argocd-linux-amd64
            [ -w /usr/local/bin ] && SUDO="" || SUDO=sudo
            $SUDO curl --insecure -sSL -o /usr/local/bin/argocd $URL
            $SUDO chmod +x /usr/local/bin/argocd
      - run:
          name: ArgoCD CLI login
          command: argocd login << parameters.server >> --insecure --username << parameters.username >> --password << parameters.password >>
      - run:
          name: Manual sync
          command: argocd app sync $APP_NAME
      - run:
          name: Wait for application to reach a synced and healthy state
          command: argocd app wait $APP_NAME

  argocd-configure:
    executor: azure-aks/default
    parameters:
      cluster-name:
        description: |
          Name of the AKS cluster
        type: string
      resource-group:
        description: |
          Resource group that the cluster is in
        type: string
    steps:
      - checkout
      - run:
          name: Pull Updated code from repo
          command: git pull origin $CIRCLE_BRANCH
      - azure-aks/update-kubeconfig-with-credentials:
          cluster-name: << parameters.cluster-name >>
          install-kubectl: true
          perform-login: true
          resource-group: << parameters.resource-group >>
      - kubernetes/create-or-update-resource:
          resource-file-path: argocd/config.yaml

  bump-docker-tag-kustomize:
    docker:
      - image: cimg/base:stable
    steps:
      - run:
          name: Install kustomize
          command: |
            URL=https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v4.5.2/kustomize_v4.5.2_linux_amd64.tar.gz
            curl -L $URL | tar zx
            [ -w /usr/local/bin ] && SUDO="" || SUDO=sudo
            $SUDO chmod +x ./kustomize
            $SUDO mv ./kustomize /usr/local/bin
      - checkout
      - run:
          name: Bump Docker Tag
          command: |
            cd manifests
            kustomize edit set image $APP_NAME=$DOCKER_LOGIN/$APP_NAME:$CIRCLE_SHA1
      - add_ssh_keys:
          fingerprints:
            - "$SSH_FINGERPRINT"
      - run:
          name: Commit & Push to GitHub
          command: |
            git config user.email "$GITHUB_EMAIL"
            git config user.name "CircleCI User"
            git checkout $CIRCLE_BRANCH           
            git add manifests/kustomization.yaml
            git commit -am "Bumps docker tag [skip ci]"
            git push origin $CIRCLE_BRANCH

workflows:
  Deploy-App-on-AKS:
    jobs:
      - docker/publish:
          image: $DOCKER_LOGIN/$APP_NAME
          tag: $CIRCLE_SHA1,latest
      - bump-docker-tag-kustomize:
          requires:
            - docker/publish
      - argocd-configure:
          cluster-name: $CLUSTER_NAME
          resource-group: $RESOURCE_GROUP
          requires:
            - bump-docker-tag-kustomize
      # Paste the following only when you opt for the ArgoCD manual-sync-policy:
      - argocd-manual-sync:
          server: $ARGOCD_SERVER
          username: $ARGOCD_USERNAME
          password: $ARGOCD_PASSWORD
          requires:
            - argocd-configure

The CI workflow consists of three jobs:

• docker/publish builds and pushes the container to Docker Hub.

• bump-docker-tag-kustomize updates the Docker Image Tag and generates a consolidated Kubernetes configuration file.

• argocd-configure applies the ArgoCD Configuration on the AKS cluster.

• argocd-manual-sync is needed only when you will be opting for the manual sync policy. For automatic sync, you can omit this job from the file.

In this workflow, we have extensively used CircleCI orbs. Orbs are open-source, shareable packages of parameterizable, reusable configuration elements, including jobs, commands, and executors. The orbs have been used directly or are used in creating custom jobs.

Commit and push the changes to your GitHub repository.

Setting up the project on CircleCI

The next step to deploying your application to AKS is connecting the application in your GitHub repository to CircleCI.

Go to your CircleCI dashboard and select the Projects tab on the left panel. Click the Set Up Project button for the GitHub repository containing the code (aks-nodejs-argocd).

When prompted to select your config.yml file, click the Fastest option and type main the branch name. CircleCI will automatically locate the config.yml file. Click Set Up Project.

The workflow will run, but will soon display an status of Failed. This is because you need to set up a user key and configure the environment variables.

To set up the user key, go to Project Settings and click SSH Keys from the left panel. In the User Key section, click Authorize with GitHub. The user key is needed by CircleCI to push changes to your GitHub account on behalf of the repository owner during the execution of the workflow.

To configure the environment variables, click Environment Variables. Select the Add Environment Variable option. On the next screen, type the environment variable and the value you want to assign to it.

The environment variables used in the file are:

• APP_NAME : Container Image Name (aks-nodejs-argocd)

• ARGOCD_PASSWORD : ArgoCD portal password

• ARGOCD_SERVER : ArgoCD Server IP Address

• ARGOCD_USERNAME : ArgoCD portal username (admin)

• AZURE_PASSWORD : Azure Account Password

• AZURE_USERNAME : Azure Account Username

• CLUSTER_NAME : AKS Cluster Name (NodeCluster)

• DOCKER_LOGIN : Docker Hub Username

• DOCKER_PASSWORD : Docker Hub Password

• GITHUB_EMAIL : GitHub Account Email Address

• RESOURCE_GROUP : AKS Resource Group (NodeRG)

• SSH_FINGERPRINT : SSH Fingerprint of User Key used for pushing the updated Docker tag to GitHub

To locate the SSH Fingerprint, go to Project Settings and select SSH Keys from the sidebar. Scroll down to the User Key section and copy the key.

Re-run the workflow. This time the status will show Success.

You will also find another pipeline having the status as Not Run. That is because you have explicitly instructed CircleCI to skip the pipeline by including [skip ci] it in the commit message. When CircleCI commits the updated configuration files to GitHub, [skip ci] prevents a self-triggering loop of the workflow.

Monitoring the application on ArgoCD Dashboard

A status that shows Success when the workflow is re-run means that the application has been deployed on the AKS cluster.

To observe and monitor the resources that are currently running on the AKS Cluster, log in to the ArgoCD Web Portal.

Earlier in this tutorial, you learned how to fetch the ArgoCD Server IP, username, and password for logging in to the portal. After logging in, you will be on the Applications page.

Click the application name. You will be redirected to a page with the tree view of all resources running on the AKS Cluster and their real-time status.

Accessing the application on AKS

To access the application, you need the external IP address of the cluster. You can use the Azure CLI to find the External-IP.

Configure kubectl to connect to AKS using this command:

az aks get-credentials --resource-group NodeRG --name NodeCluster

You created all the resources in the nodejs namespace. To get all the resources in that namespace, use this command:

kubectl get all --namespace nodejs

Copy the External-IP corresponding to service/nodejs.

You can access the application at http://<EXTERNAL-IP>. In my case, that is http://20.121.253.220/.

Conclusion

In this tutorial, you learned how to deploy your applications continuously on a Kubernetes cluster following GitOps practices with ArgoCD. This included configuring an automated CI pipeline. With the pipeline properly configured, any changes made to the application code are instantly updated on the application URL. Say goodbye to manually configure and deploying applications on Kubernetes.

As a bonus, you can change the values of the environment variables to use the CircleCI configuration file for similar applications.

The complete source code for this tutorial can also be found here on GitHub.

Containers and microservices have revolutionized the way applications are deployed on the cloud. Since its launch in 2014, Kubernetes has become a standard tool for container orchestration. It provides a set of primitives to run resilient, distributed applications.

One of the key difficulties that developers face is being able to focus more on the details of the code than the infrastructure for it. The serverless approach to computing can be an effective way to solve this problem.

Serverless allows running event-driven functions by abstracting the underlying infrastructure. Compared to traditional Platform as a Service (PaaS), serverless allows your dev team to focus on the functionality of the service. Infrastructure issues, such as scaling and fault tolerance, are no longer a roadblock.

Knative is an open-source enterprise-level solution to build serverless and event-driven applications. Its components can be used to build and deploy serverless applications on Kubernetes. Originally developed by Google, Knative now has contributors from IBM, Red Hat, and VMWare.

ArgoCD is a Kubernetes-native continuous deployment (CD) tool. It deploys code changes directly to Kubernetes resources by pulling them from Git repositories. ArgoCD follows the GitOps pattern, unlike some external CD solutions, which can support only push-based deployments. This tool gives developers the ability to control application updates and infrastructure setup from a unified platform.

In this tutorial, you will learn how to deploy a Node.js application as a serverless workload with Knative on Azure Kubernetes Service (AKS) using CircleCI and ArgoCD. You will be creating a continuous integration pipeline with CircleCI orbs, which are reusable packages of YAML configuration that condense repeated pieces of config into a single line of code. The pipeline is triggered when you push the code into the GitHub repository. The result is an automated pipeline that triggers ArgoCD to deploy the latest version of the application on the Kubernetes cluster.

Prerequisites

To follow along with this tutorial, you will need:

• Docker Hub account

• GitHub account

• Microsoft Azure account

• CircleCI account

• Kubectl installed on your system

• ArgoCD CLI installed on your system

• Azure CLI installed on your system

• Node.js installed on your system

• Docker Engine installed on your system

After you have these items in a place you are ready to go to the next section.

Cloning the Node.js application

In this tutorial, our main focus is on deploying the application on Kubernetes. To save time, you can directly clone the Node.js application to your GitHub and continue with the rest of the process.

To clone the project, run:

git clone https://github.com/CIRCLECI-GWP/nodejs-knative-argocd.git

There are 2 branches in this repository:

• The main the branch contains only the Node.js application code.

• The circleci-project-setup the branch contains the application code, along with all YAML files that you will create in this tutorial.

Check out the main branch.

The Node.js application lives in the app.js file:

const express = require("express");
const path = require("path");
const morgan = require("morgan");
const bodyParser = require("body-parser");
/* eslint-disable no-console */
const port = process.env.PORT || 1337;
const app = express();
app.use(morgan("dev"));
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: "true" }));
app.use(bodyParser.json({ type: "application/vnd.api+json" }));
app.use(express.static(path.join(__dirname, "./")));
app.get("*", (req, res) => {
  res.sendFile(path.join(__dirname, "./index.html"));
});
app.listen(port, (err) => {
  if (err) {
    console.log(err);
  } else {
    console.log(`App at: http://localhost:${port}`);
  }
});
module.exports = app;

The key takeaway from this code is port number where the application will be running. In this case, it is 1337.

You can run the application locally by first installing the dependencies. In the project’s root, type:

npm install

Then run the application with the command:

node app.js

The application should now be up and running at the address http://localhost:1337.

Containerizing the Node.js application

The first step for deploying an application to Kubernetes is containerizing it. Containerizing applications that use Docker as the container runtime tool requires you to create a Dockerfile. A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image.

Create a new file in the root directory of the project and name it Dockerfile. Copy this content to the file:

# Set the base image to use for subsequent instructions
FROM node:alpine
# Set the working directory for any subsequent ADD, COPY, CMD, ENTRYPOINT,
# or RUN instructions that follow it in the Dockerfile
WORKDIR /usr/src/app
# Copy files or folders from source to the dest path in the image's filesystem.
COPY package.json /usr/src/app/
COPY . /usr/src/app/
# Execute any commands on top of the current image as a new layer and commit the results.
RUN npm install --production
# Define the network ports that this container will listen to at runtime.
EXPOSE 1337
# Configure the container to be run as an executable.
ENTRYPOINT ["npm", "start"]

If you have Docker installed, you can build and run the container locally for testing. Later in this tutorial, you will learn how to automate this process using CircleCI orbs.

To build and tag the container, you can type:

docker build -t nodejs-knative-argocd:latest .

Confirm that the image was successfully created by running this command from your terminal:

docker images

Then run the container with the command:

docker run -it -p 1337:1337 nodejs-knative-argocd:latest

The application should now be up and running at the address http://127.0.0.1:1337.

Commit and push the changes to your GitHub repository.

Configuring Knative Service manifests

In Knative, Services are used to deploy an application. To create an application using Knative, you must create a YAML file that defines a Service. This YAML file specifies metadata about the application, points to the hosted image of the app and allows the Service to be configured.

Create a directory named knative in the root directory of the project. Then, create a new file in the new directory and name it service.yaml.

The contents of the service.yaml are:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  creationTimestamp: null
  name: nodejs-knative-argocd
spec:
  template:
    metadata:
      creationTimestamp: null
      name: nodejs-knative-argocd
    spec:
      containerConcurrency: 0
      containers:
        - image: docker.io/avik6028/nodejs-knative-argocd:latest
          name: user-container
          ports:
            - containerPort: 1337
              protocol: TCP
          readinessProbe:
            successThreshold: 1
            tcpSocket:
              port: 0
          resources: {}
      enableServiceLinks: false
      timeoutSeconds: 300
status: {}

The key takeaway from this code block is the spec.template.metadata.name and spec.template.spec.containers[0].image. These denote the name of the template and the container image that will be pulled and deployed with Knative on the Kubernetes cluster. These values will be updated with the latest container image information during the continuous integration process.

Commit and push these files into the main branch of the GitHub repository you cloned earlier.

Launching the Azure Kubernetes Service (AKS) cluster

In this tutorial, you will be learning to deploy the application on the AKS cluster. To create the AKS cluster, you should have a Microsoft Azure account and the Azure CLI installed on your computer. Connect the CLI to your Azure account.

Now you can launch an AKS cluster with the help of Azure CLI.

Create a Resource Group using this command:

az group create --name NodeRG --location eastus

Launch a two-node cluster:

az aks create --resource-group NodeRG --name NodeCluster --node-count 2 --enable-addons http_application_routing

Note: If you generated any SSH keys in your system previously, you need to add the optional parameter --generate-ssh-keys to the command. This parameter will auto-generate SSH public and private key files if they are missing. The keys will be stored in the ~/.ssh directory.

The AKS cluster will take 10 to 15 minutes to launch.

Installing Knative in the Kubernetes cluster

Once the cluster is up and running, you need to install Knative inside the cluster to use it for deploying your serverless workload.

To install the application, use the Azure CLI once again.

Configure kubectl to connect to AKS using this command:

az aks get-credentials --resource-group NodeRG --name NodeCluster

To install the Knative core components and custom resources, execute these commands:

kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.7.1/serving-crds.yaml
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.7.1/serving-core.yaml

Knative also requires a networking layer for exposing its services externally. You need to install Kourier, a lightweight Knative Serving ingress.

kubectl apply -f https://github.com/knative/net-kourier/releases/download/knative-v1.7.0/kourier.yaml

Configure Knative Serving to use Kourier by default by running:

kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"ingress-class":"kourier.ingress.networking.knative.dev"}}'

You can configure DNS so you do not need to run curl commands with a host header. Knative provides a Kubernetes Job called default-domain that configures Knative Serving to use sslip.io as the default DNS suffix.

kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.7.1/serving-default-domain.yaml

Once you execute the commands, Knative will be installed in knative-serving namespace. To get all the resources into the namespace:

kubectl get all --namespace knative-serving

Installing ArgoCD in the AKS cluster

Once the cluster is up and running, you need to install ArgoCD inside the cluster to use it for deploying your application.

To install ArgoCD, enter:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

When you execute these commands, ArgoCD will be installed in the ‘argocd’ namespace. To get all the resources into the namespace:

kubectl get all --namespace argocd

Exposing the ArgoCD API server

By default, the ArgoCD API server is not exposed to an external IP. Because you will access the application from the internet during this tutorial, you need to expose the ArgoCD server with an external IP via Service Type Load Balancer.

Change the argocd-server service type to LoadBalancer:

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

Note: You can also use Kubectl port forwarding to connect to the API server without exposing the service. Use this command: kubectl port-forward svc/argocd-server -n argocd 8080:443

You can now access the API server using https://localhost:8080.

Accessing the ArgoCD web portal

Once you have exposed the ArgoCD API server with an external IP, you can access the portal with the external IP Address that was generated.

Because you installed ArgoCD in the argocd namespace, use this command to get all the resources for the namespace:

kubectl get all --namespace argocd

Copy the External-IP corresponding to service/argocd-server.

You can access the application at http://<EXTERNAL-IP>.
I used http://52.146.29.61/.

To log into the portal, you will need the username and password. The username is set as admin by default.

To fetch the password, execute this command:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

Use this username-password combination to log into the ArgoCD portal.

Configuring Kubernetes manifests for ArgoCD

To configure ArgoCD to deploy your application on Kubernetes, you will have to set up ArgoCD to connect the Git Repository and Kubernetes in a declarative way using YAML for configuration.

Apart from this method, you can also set up ArgoCD from the Web Portal or use the ArgoCD CLI. But since in this article, we are trying to follow the GitOps principles which state that the Git repository should act as the sole source of truth, the declarative method via YAML files serves best.

One of the key features and capabilities of ArgoCD is to sync via manual or automatic policy for the deployment of applications to a Kubernetes cluster.

To get started, create a directory named argocd in the root directory of the project. Create a new file in the new directory and name it as config.yaml.

Manual Sync Policy

As the name suggests, through this policy, you will be able to manually synchronize your application via the CI/CD pipelines.
Whenever a code change is made, the CI/CD pipeline is triggered and calls the ArgoCD server APIs to start the sync process based on the changes you will commit. For communicating with the ArgoCD server APIs, you can use the ArgoCD CLI. You can also use one of the SDKs available for various programming languages.

For setting up the Manual Sync policy for ArgoCD, paste this in the config.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nodejs-knative-argocd
  namespace: argocd
spec:
  destination:
    namespace: nodejs
    server: 'https://kubernetes.default.svc'
  source:
    path: knative
    repoURL: 'https://github.com/CIRCLECI-GWP/nodejs-knative-argocd'
    targetRevision: circleci-project-setup
  project: default

Automated Sync policy

ArgoCD can automatically sync an application when it detects differences between the desired manifests in Git and the live state in the cluster.

A benefit of automatic sync is that CI/CD pipelines no longer need direct access to the ArgoCD API server to perform the deployment. Instead, the pipeline makes a commit and pushes to the Git repository with the changes to the manifests in the tracking Git repo.

If you want to set to the Automated Sync policy, you need to paste this in the config.yaml.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nodejs-knative-argocd
  namespace: argocd
spec:
  destination:
    namespace: nodejs
    server: 'https://kubernetes.default.svc'
  source:
    path: knative
    repoURL: 'https://github.com/CIRCLECI-GWP/nodejs-knative-argocd'
    targetRevision: circleci-project-setup
  project: default
  syncPolicy:
    automated:
      prune: false
      selfHeal: false

Commit and push these files into the main branch of the GitHub repository you had cloned earlier.

Creating the continuous integration pipeline

The objective of this tutorial is to show how you can deploy a serverless workload with Knative on Kubernetes through continuous integration (CI) via CircleCI and continuous deployment (CD) via ArgoCD.

To create the CI pipeline, we will be using CircleCI integrated with your GitHub account. CircleCI configuration lives in the .circleci directory in the project’s root folder in the form of config.yml file, i.e., the path to the configuration is .circleci/config.yml.

The contents of config.yml are:

version: 2.1

orbs:
  docker: circleci/docker@2.1.1
  azure-aks: circleci/azure-aks@0.3.0
  kubernetes: circleci/kubernetes@1.3.0

jobs:
  argocd-manual-sync:
    docker:
      - image: cimg/base:stable
    parameters:
      server:
        description: |
          Server IP of of ArgoCD
        type: string
      username:
        description: |
          Username for ArgoCD
        type: string
      password:
        description: |
          Password for ArgoCD
        type: string
    steps:
      - run:
          name: Install ArgoCD CLI
          command: |
            URL=https://<< parameters.server >>/download/argocd-linux-amd64
            [ -w /usr/local/bin ] && SUDO="" || SUDO=sudo
            $SUDO curl --insecure -sSL -o /usr/local/bin/argocd $URL
            $SUDO chmod +x /usr/local/bin/argocd
      - run:
          name: ArgoCD CLI login
          command: argocd login << parameters.server >> --insecure --username << parameters.username >> --password << parameters.password >>
      - run:
          name: Manual sync
          command: argocd app sync $APP_NAME
      - run:
          name: Wait for application to reach a synced and healthy state
          command: argocd app wait $APP_NAME

  argocd-configure:
    docker:
      - image: cimg/base:stable
    parameters:
      cluster-name:
        description: |
          Name of the AKS cluster
        type: string
      resource-group:
        description: |
          Resource group that the cluster is in
        type: string
    steps:
      - checkout
      - run:
          name: Pull Updated code from repo
          command: git pull origin $CIRCLE_BRANCH
      - azure-aks/update-kubeconfig-with-credentials:
          cluster-name: << parameters.cluster-name >>
          install-kubectl: true
          perform-login: true
          resource-group: << parameters.resource-group >>
      - kubernetes/create-or-update-resource:
          resource-file-path: argocd/config.yaml

  bump-docker-tag:
    docker:
      - image: cimg/base:stable
    steps:
      - run:
          name: Install yq - portable yaml processor 
          command: |
            URL=https://github.com/mikefarah/yq/releases/download/3.3.4/yq_linux_amd64
            [ -w /usr/local/bin ] && SUDO="" || SUDO=sudo
            $SUDO wget $URL
            $SUDO mv ./yq_linux_amd64 /usr/local/bin/yq
            $SUDO chmod +x /usr/local/bin/yq
      - checkout
      - run:
          name: Update Knative Service manifest
          command: |
            yq w -i knative/service.yaml spec.template.metadata.name "$APP_NAME-$CIRCLE_BUILD_NUM"
            yq w -i knative/service.yaml spec.template.spec.containers[0].image "docker.io/$DOCKER_LOGIN/$APP_NAME:$CIRCLE_SHA1"
      - add_ssh_keys:
          fingerprints:
            - "$SSH_FINGERPRINT"
      - run:
          name: Commit & Push to GitHub
          command: |
            git config user.email "$GITHUB_EMAIL"
            git config user.name "CircleCI User"
            git checkout $CIRCLE_BRANCH           
            git commit -am "Bumps docker tag [skip ci]"
            git push origin $CIRCLE_BRANCH

workflows:
  Deploy-App-on-AKS:
    jobs:
      - docker/publish:
          image: $DOCKER_LOGIN/$APP_NAME
          tag: $CIRCLE_SHA1,latest
      - bump-docker-tag:
          requires:
            - docker/publish
      - argocd-configure:
          cluster-name: $CLUSTER_NAME
          resource-group: $RESOURCE_GROUP
          requires:
            - bump-docker-tag
# Paste the following only when you opt for the ArgoCD manual-sync-policy:
      - argocd-manual-sync:
          server: $ARGOCD_SERVER
          username: $ARGOCD_USERNAME
          password: $ARGOCD_PASSWORD
          requires:
            - argocd-configure

The CI workflow consists of 3 jobs:

• The docker/publish the job builds and pushes the container to Dockerhub

• The bump-docker-tag job updates the Knative Service YAML with the latest container image tag

• The argocd-configure job applies the ArgoCD Configuration on the AKS cluster

• The argocd-manual-sync job is needed only when you will be opting for the manual-sync-policy. For automatic-sync, you can omit this job from the file.

In this workflow, we have extensively used CircleCI orbs, which are open-source, shareable packages of parameterizable reusable configuration elements, including jobs, commands, and executors. The orbs have been either used directly or are used in creating custom jobs.

Commit and push the changes to your GitHub repository.

Setting up the project on CircleCI

The next step to deploying your application to AKS is connecting the application in our GitHub repository to CircleCI.

Go to your CircleCI dashboard and select the Projects tab on the left panel. Now, you have to click on the Set Up Project button corresponding to the GitHub repository which contains the code (nodejs-knative-argocd).

On the Select, your config.yml file screen, select the Fastest option and type main the branch name. CircleCI will automatically locate the config.yml file. Click Set Up Project.

The workflow will start running automatically. But after some time, it will display the status as Failed. This is because you have to set up a User Key and configure the Environment Variables from Project Settings in CircleCI.

To set up the User Key, select the SSH Keys option from the left panel of the Project Settings. Under the User Key section, click Authorize with GitHub. The User Key is needed by CircleCI to push changes to your GitHub account on behalf of the repository owner, during the execution of the workflow.

To configure the Environment Variables, select the Environment Variables option from the left panel of the Project Settings. Select the Add Environment Variable option. On the next screen, type the environment variable and the value you want it to be assigned to.

The Environment Variables used in the file are listed below:

• APP_NAME : Container Image Name (nodejs-knative-argocd)

• ARGOCD_PASSWORD : ArgoCD portal password

• ARGOCD_SERVER : ArgoCD Server IP Address

• ARGOCD_USERNAME : ArgoCD portal username (admin)

• AZURE_PASSWORD : Azure Account Password

• AZURE_USERNAME : Azure Account Username

• CLUSTER_NAME : AKS Cluster Name (NodeCluster)

• DOCKER_LOGIN : Dockerhub Username

• DOCKER_PASSWORD : Dockerhub Password

• GITHUB_EMAIL : GitHub Account Email Address

• RESOURCE_GROUP : AKS Resource Group (NodeRG)

• SSH_FINGERPRINT : SSH Fingerprint of User Key used for pushing the updated Docker tag to GitHub

To locate the SSH Fingerprint, go to Project Settings and select SSH Keys from the sidebar. Scroll down to the User Key section and copy the key.

Re-run the workflow. This time the status will show Success.

You will also find another pipeline with the status as Not Run. That is because you have explicitly instructed CircleCI to skip the pipeline by including [skip ci] it in the commit message. When CircleCI commits the updated configuration files to GitHub, [skip ci] prevents a self-triggering loop of the workflow.

Monitoring the application on ArgoCD Dashboard

A status that shows Success when the workflow is re-run means that the application has been deployed on the AKS cluster.

To observe and monitor the resources that are currently running on the AKS Cluster, log in to the ArgoCD Web Portal.

Earlier in this tutorial, you learned how to fetch the ArgoCD Server IP, username, and password for logging in to the portal. After logging in, you be on the Applications page.

Click the application name. You will be redirected to a page with the tree view of all resources running on the AKS Cluster and their real-time status.

Accessing the application on AKS

To access the application, you will need the DNS name of the route created by the Knative Service.

You created all the resources in the nodejs namespace. To get all the resources in that namespace, use this command:

kubectl get all --namespace nodejs

Copy the URL for service.serving.knative.dev/nodejs-knative-argocd.

Use this URL to access the application. For me, the URL is http://nodejs-knative-argocd.nodejs.52.146.24.47.sslip.io/.

Conclusion

And that is the end of the tutorial. By following this guide, you learned how to develop an automated CI pipeline for deploying your serverless workload continuously on a Kubernetes cluster following GitOps practices with Knative and ArgoCD. Once the pipeline is properly configured, any changes made to the application code will be instantly reflected on the workload URL. There is no further need for configuring and deploying applications on Kubernetes manually. You can change the values of the environment variables to use the CircleCI configuration file for similar applications.

The complete source code for this tutorial can also be found here on GitHub.

Serverless is a way to describe the services, practices, and strategies that enable you to build more agile applications so you can innovate and respond to change faster. With serverless computing, infrastructure management tasks like capacity provisioning and patching are handled by AWS, so you can focus on only writing code that serves your customers.

Serverless Computing = FaaS [Functions as a Service] + BaaS [Backend as a Service]

Serverless Services of AWS:

• Compute: AWS Lambda, AWS Fargate

• Storage: Amazon DynamoDB, Amazon S3, etc.

• Application Integration: Amazon API Gateway, etc.

Introduction

In this walkthrough, we are going to develop an URL Shortener Service using various services of the AWS Serverless Ecosystem. We are going to focus mainly on the backend of the application.

To implement our project in a simplified way, we will use only the 2 most important services: the API Gateway and DynamoDB.

AWS Lambda

AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes. With Lambda, you can run code for virtually any type of application or backend service ΓÇö all with zero administration.

In this application, we are not going to use AWS Lambda, since our application runs on simpler logic ΓÇö i.e. to store short-URLs into the Database and re-direct to the long-URLs once we call the short-URL.

Amazon API Gateway

Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as the ΓÇ£front doorΓÇ¥ for applications to access data, business logic, or functionality from your backend services.

In our application, we are going to utilize the functionality of the API Gateway through which we can perform ETL operations during the transit of data between the API Gateway and DynamoDB.

Amazon DynamoDB

Amazon DynamoDB is a key-value and document database that delivers single-digit millisecond performance at any scale. ItΓÇÖs a fully managed, multi-region, multi-active, durable database with built-in security, backup and restores, and in-memory caching for internet-scale applications.

DynamoDB can handle more than 10 trillion requests per day and can support peaks of more than 20 million requests per second.

Getting Started

To follow this project, you only need to have an AWS account. The entire application would be developed within the AWS Web Console.

Let's understand the workflow of the application. We are currently focussing on 2 main features prevalent to all URL-Shorteners.

1. Storing the Short-URL, Long-URL and owner inside DynamoDB

In the backend, once a user sends a POST request to the Route, with all the required parameters, the API Gateway receives the data, transforms it and pushes it into the DynamoDB.

2. Redirecting to the Long-URL once the short-URL is hit

Once a user mentions the short-URL in the HTTP header, the API gateway receives the data, processes it and searches it inside DynamoDB. Once the corresponding Long URL is found, the API Gateway redirects to the Long URL.

Setting Up DynamoDB Database

First of all, we need to configure our Database. For that, we need to create a Table.

The table would be consisting of 3 Columns: longURL , shortId , owner . We would be using the shortId attribute as the Primary key of the table.

In the configuration, please use the exact names mentioned.

• Table Name: URL-Shortener

• Primary Key: shortId

• Table settings: Use Default Settings

Once you create the Table, you would land on the following page mentioning all the Table Details:

Setting up the API Gateway

This is the most important service in our architecture. Through this service, we are going to perform multiple operations.

1. Create API Endpoints for GET and POST requests.

2. Transform request parameters received from the API into DynamoDB understandable format.

3. Convert the response received from the DynamoDB into a format understandable by browsers for re-direction.

We need to create an API of the type Rest API from the API Gateway console.

After selecting the REST-API Gateway type, we need to select the following configurations.

• Protocol: REST

• Create a new API: New API

• API name: URLShortener

This would create a new API.

API Gateway Console

Now, we need to create an New Resource under the / route. The name of the resource is set as: url-shortener .

Under this resource, we need to create multiple methods for GET and POST requests.

Setting Up POST Request

Under the /url-shortener resource, we need to create a method named ΓÇ£POSTΓÇ¥. In this method, we are going to modify our POST request.

Once the POST Method is selected, we have to use the following information during its setup:

• Integration type: AWS Service

• AWS Region: ap-south-1 [region where the DynamoDB Instance would be running]

• AWS Service: DynamoDB

• HTTP method: POST

• Action: UpdateItem

• Execution role: [ IAM Role in which DynamoDB write permissions are given ]

Once the setup is completed, we land on the following page:

Now, we need to transform the request parameters received from the client into something that would be understood by DynamoDB.

For this, we are going to utilize the Integration Request feature of the API Gateway. Through this feature, we are going to add a Mapping Template based on which the transformation would take place.

On clicking the Integration Request from the above page, we would be landing on the following page:

Under the Mapping Templates section, we need to add the following code:

{% gist https://gist.github.com/Lucifergene/180738ec994ce28d4b4d8fa7c71bbab7 %}

Now, we have set up the process through which data would be saved into the DynamoDB. But now, we have to also format the Response that DynamoDB would be sending, to a format understandable by the Client.

For this, we need to set up another Mapping Template in the Integration Response section.

Under the Mapping Templates section, we need to add the following code:

{% gist https://gist.github.com/Lucifergene/39bf8dc169f4ca6d1f1d5eaa591f5e9e %}

Once this is set up, the response of the DynamoDB would be converted in a form understandable by the client.

Thus, we have set up our POST request, which would save the request parameters in the DynamoDB and would send the response back to the client. To test, we need to click on the TEST option from the above console.

In the Request Body, we need to type the following:

{
  "longURL": "[https://www.google.co.in](https://www.google.co.in)",
  "owner": "Avik",
  "shortURL": "Google"
}

On submitting the above JSON, we must receive a 200 Status code and a similar response body as the following. Thus we have successfully saved the contents to the DynamoDB.

Setting Up GET Request

The GET request is somewhat different from the POST request. Here, the user would be appending the short URL to the API endpoint. This shortURL would be sent to the DynamoDB by the API Gateway to perform the search operation. Once the associated long URL is found, the API Gateway automatically re-directs to the long URL.

Under the /url-shortener resource, we create another resource named as {shortURL}, which would be having a dynamic resource path, as it is the place where the short URLs would be appended.

Inside the newly created sub-resource, we create the GET request with the following settings:

• Integration type: AWS Service

• AWS Region: ap-south-1 [region where the DynamoDB Instance would be running]

• AWS Service: DynamoDB

• HTTP method: POST

• Action: GetItem

• Execution role: [ IAM Role in which DynamoDB write permissions are given ]

Once the setup is completed, we land on the following page:

Now, we have to perform 3 transformations while the data would be transferred back and forth between the API Gateway and DynamoDB.

A. Integration Request

First, we need to transform the request parameters received from the client into something that would be understood by DynamoDB. For this, we are going to utilize the Integration Request feature of the API Gateway. Through this feature, we are going to add a Mapping Template based on which the transformation would take place.

On clicking the Integration Request from the above page, we would be landing on the following page:

Under the Mapping Templates section, we need to add the following code:

{% gist https://gist.github.com/Lucifergene/ca5e96a9744d4eeecd478ba6d097600b %}

B. Method Response

We know that for URL redirections, 302 HTTP Status code is used. Therefore in the response header, we need to set the appropriate status code since by default 200is set.

In the Method Response section, we need to delete the 200 status code association and add the 302 HTTP Status Code. To instruct the API gateway to redirect to the URL set in the Location key in the Response header, we need to add it to the corresponding 302 Response Header.

C. Integration Response

After setting up the Method Response, now, we have to also format the Response that DynamoDB would be sending, to a format understandable by the Client.

For this, we need to set up another Mapping Template in the Integration Response section.

Under the Mapping Templates section, we need to add the following code:

{% gist https://gist.github.com/Lucifergene/b2be264e74bf4cb5c38bf57bd5f710af %}

Thus, we have set up our GET request, which would redirect the short URL to the actual LongURL after fetching it from DynamoDB.

To test, we need to click on the TEST option from the above console. In the {shortId} field, we need to enter the shortId of the URL and click on the TEST button.

Thus we have received a 302 response code and upon studying the response header, we see a location key that contains the actual Long URL.

And we reached the end of the solution!!!

You can visit the repository from below:

You can reach out on my Twitter, Instagram, or LinkedIn if you need more help. I would be more than happy.

You need to paste this script in the Index.JS file of your Cloudflare Worker

The Service: https://short-linker.lucifergene.workers.dev/

You can visit the repository below:

You can reach out on my Twitter, Instagram, or LinkedIn if you need more help. I would be more than happy.

The main reason as far I understand is the simplicity and fast development process. You do not have to be a Full Stack developer to create a website for a local grocery shop or a small business. WordPress is built in such a way that with a few button clicks, you are ready with a basic website. All these benefits portray how it is still the Market Leader among other Content Management Systems, even after nearly 2 decades of its launch.

A Move Towards Containerized Deployment

Containerization or the ability to build containers around any applications has changed the way deployment takes place in the age of Cloud-Ops. The concept of building containers has solved different kinds of problems faced in the traditional approach of deploying applications, mostly security and portability. Docker, Podman and Cri-o are some of the tools which manage the procedure of creating containers for applications. Once containers are created, they can be run on any system irrespective of their configuration apart from the hardware requirements. Running Dockerized applications requires just a single line of code to start the containers!

Till now, it seems nice! But now imagine a situation where you are building a large application, preferably a Web Application with a dedicated frontend and a backend. Now you wish to follow a micro-service based architecture where you will be dockerizing the frontend and backend of the applications separately in different containers and then connecting them with different REST APIs. At this time, you have to handle 2 containers simultaneously. You have to make sure both the containers are running all the time and if any container crashes, you have to manually restart the services. The process further complicates when you are trying to create some more microservices to add more features to your container. At last, you will find it very difficult to handle and manage all containers together.

The need for Container Orchestration Services

Wouldn’t be it better if there’s a service that is continuously running in the background and is managing all the containers together? Whenever a container crashes, it would automatically re-launch it and when the traffic to the website increases, instantly it will scale up the infrastructure by deploying more containers to balance the load.

In Kubernetes, the atomic unit of scheduling in Pod. Pods are slightly different from containers. We can run multiple containers in a single pod but not vice-versa. This comes very conveniently when we have containers that are fully dependent on each other, e.g. WordPress and MySQL are dependent since all data from WordPress would be stored in MySQL.

Understanding the Architecture of Kubernetes

Whenever we work with K8s, we at first have to create a cluster. A cluster contains a Master node and several Worker nodes or slaves.

The job of the Master Node is to schedule and monitor the logs of the containers running inside the pods, present inside the Worker Nodes. Whenever a client requests a Pod to be launched to the Master, the client connects to the API server at port 6443 of the master. Then the Master takes the client request to the Kubelet program present at the Worker Nodes. Based on the request, the Kubelet program communicates with internal docker engine to perform the required job.

Some of the other services running across the cluster:

On Master Nodes:

1. etc: It stores the configuration information which can be used by each of the nodes in the cluster. Here the Master store permanent data like secrets i.e key-value information, config files etc.
2. API Server: Kubernetes is an API server that provides all the operations on the cluster using the API.
3. Controller Manager: This component is responsible for most of the collectors that regulate the state of the cluster and performs a task.
4. Scheduler: Responsible for workload utilization and allocating pod to the new node.

On Worker Nodes:

1. Docker: The first requirement of each node is Docker which helps in running the encapsulated application containers in a relatively isolated but lightweight operating environment.
2. Kubelet Service: This is a small service in each node responsible for relaying information to and from the control plane service. It interacts with etc store to read configuration details and wright values.
3. Kubernetes Proxy Service: This is a proxy service that runs on each node and helps in making services available to the external host.

Kubernetes - Architecture

When running a Kubernetes cluster, one of the foremost challenges is deciding which cloud or datacenter it’s going to be deployed to. After that, you still need to filter your options when selecting the right network, user, storage, and logging integrations for your use cases.

Benefits of Amazon EKS: Why use EKS?

Through EKS, normally cumbersome steps are done for you, like creating the Kubernetes master cluster, as well as configuring service discovery, Kubernetes primitives, and networking. Existing tools will more than likely work through EKS with minimal mods, if any.

With Amazon EKS, the Kubernetes Control plane — including the backend persistence layer and the API servers — is provisioned and scaled across various AWS availability zones, resulting in high availability and eliminating a single point of failure. Unhealthy control plane nodes are detected and replaced, and patching is provided for the control plane. The result is a resilient AWS-managed Kubernetes cluster that can withstand even the loss of an availability zone.

And of course, as part of the AWS landscape, EKS is integrated with various AWS services, making it easy for organizations to scale and secure applications seamlessly. From AWS Identity Access Management (IAM) for authentication to Elastic Load Balancing for load distribution, the straightforwardness and convenience factor of using EKS can’t be understated.

What is Amazon Elastic Kubernetes Service (EKS)? | Sumo Logic

Getting Started

Some Pre-Requisites:

You need to have an AWS account. It cannot be the Starter Program since EKS is not supported there. Secondly, you must have a basic knowledge of AWS and Kubernetes. Third, you must have AWS CLI set up in your system with a dedicated profile allowing ADMIN Access so that it can directly use the EKS.

Although AWS CLI provides commands to manage EKS, but they are not efficient enough to perform complex tasks. Therefore, we are going to use another CLI built especially for EKS. You can download it from the GitHub link given below.

GitHub - Weaveworks/excel: The official CLI for Amazon EKS

Apart from that, we need to have kubectl installed in our system too, for communicating with the Pods running on EKS. It is a managed service so everything will be managed by it except kubectl command because it is a client program, which will help us to connect with the pods.

Install Tools

Starting the EKS Cluster

To start the EKS cluster, we need to set up a YAML file containing the infrastructure of the cluster. Information like the number of Worker Nodes, allowed EC2 instances, AWS key for connecting the instances with our local terminal and many more, are mentioned in this file.

After we write the desired infrastructure in our YAML file, we will have to execute the file with the EKSCTL CLI we have installed.

eksctl create a cluster -f cluster.yaml

This command will create the entire cluster in 1 click. The creation of the cluster would take a certain amount of time.

Setting up the kubectl CLI

After the cluster is launched, we need to connect our system with the pods so that we can work on the cluster. Kubernetes has been installed in the instances already by EKS. Therefore to connect our kubectl with the Kubernetes on the instances, we need to update the KubeConfiguration file first. For this, we use the following command:

aws eks update-kubeconfig --name cluster1

We can check the connectivity with the command: kubectl cluster-info

For finding the number of nodes: kubectl get nodes

For finding the number of pods: kubectl get pods

To get detailed information of the instances on which the pods are running: kubectl get pods -o wide

Before we work, we need to create a namespace for our application in the K8s.

For that we use the following command: kubectl create namespace wp-msql

Now we have to set it to be the default Namespace:

kubectl config set-context --current --namespace=wp-msql

For checking how many pods are running inside the namespace ‘kube-system’ we have to execute: kubectl get pods -n kube-system

Installing WordPress and MySQL

Now, we are ready to install WordPress and Mysql in our cluster. For that, we need to copy the 3 files given below in a folder.

This file contains information about the different settings to be applied to our MySQL pod.

Similarly, this file contains information about the different settings to be applied to our WordPress pod.

At last, we create a Kustomization file to specify the order of execution of the files along with the secret keys.

After putting the above scripts in a folder, we can build the infrastructure using the following command: kubectl create -k .

Our WordPress server along with MySQL is now launched in the EKS!

To customize the site, we need a URL to visit. For that, we will be using the Public DNS provided by the External Load Balancer (ELB).

On visiting the URL of the LB, we will reach this page.

After configuration and posting our first post, we will reach to this following page:

Shutting down EKS cluster

Since EKS is not a free service, it is better to shut down whenever it is not required. For that we use a simple command: eksctl delete cluster -f cluster1.yaml.
This will delete the entire cluster along with the EC2 instances, Load Balancers, etc. which were automatically created by EKS.

So, this was a basic walkthrough about the process of deploying applications on EKS easily.

Monitoring our Deployment

We can use the HELM to install monitoring tools like Prometheus and Grafana.

Helm is a tool for managing Charts. Charts are packages of pre-configured Kubernetes resources. It is a tool that streamlines installing and managing Kubernetes applications. It can be installed in the system with the following commands. A server-side tool called TILLER is also required.

Through HELM, it becomes easier to manage applications in Kubernetes on EKS. It has huge Libary of pre-configured code for various Softwares which can be installed with a single click.

Helm

For monitoring our Application, we need to install Prometheus and Grafana.

Prometheus

To install Prometheus through Helm, we use the following commands:

Since we have forwarded the port, visiting port 8888 will show the Prometheus screen.

Grafana

To install Grafana through Helm, we use the following commands:

To get the IP address where Grafana is running, we type the following: kubectl get svc -n grafana . By visiting the URL of the LoadBalancer, we see the Grafana screen.

Other Modifications

Amazon EFS

There are mainly 3 different types of storages available: File, Block and Object Storage. By default, EKS will set the storage system for the clusters as Block Storage and will be using EBS for that.

Instead of using EBS as our storage service for our data, we can use Amazon EFS or Elastic File Storage. EFS is highly preferred because it allows connecting to multiple instances at once, which EBS does not. For implementing EFS, we need a provisioner since it is not provided by default.

AWS EFS: Is It the Right Storage Solution for You?

Amazon Fargate

This is what AWS Fargate is about. It completely abstracts the underlying infrastructure, and we see every one of our containers as a single machine.

We just have to specify what resource we need for every container and it will do the heavy lifting for us. We don’t have to manage multi-layered access rules anymore. We can fine-tune the permissions between our containers like we would do between single EC2 instances.

We can launch a Fargate cluster similar to the EKS cluster. The configuration has to be set as the following:

We can launch the above cluster by executing the command: eksctl create cluster -f fargate_cluster.yaml

Since Fargate is more advanced than EKS, the charges are higher than EKS. We can shut down the entire Fargate Cluster by the command: eksctl delete cluster -f fargate_cluster.yaml

An intro to Amazon Fargate: what it is, why it's awesome (and not), and when to use it.

All codes for the walkthrough are published in the Github account.

You can reach out on my Twitter, Instagram, or on LinkedIn if you need more help. I would be more than happy.

If you have come up to this, do drop an 👏 if you liked this article.

Good Luck 😎 and happy coding 👨‍💻

There is unprecedented demand for resource provisioning due to COVID-19, these days. Various open-source technologies are being used to respond to the challenges faced by the business. Automation is the key requirement among various firms and companies to keep their business running.

Can you roll out fixes at scale ? Can you automate repeatable IT tasks without compromising compliance?

Remote workers are demanding self-service, can you give it to them? Without breaking the bank?

Ansible automation can be the answer to all the questions.

Ansible is the most popular automation tool in the Github today, with more than a quarter-million downloads per month. There are more than 3500 contributors submitting new modules all the time.

Ansible can help to keep the lights on by automating the remediation of problems before they affect the systems and how we can keep IT systems secure.

The basic use-cases of Ansible are Provisioning, Configuration Management(CM), Security Remediation, Application deployment, etc.

Getting Started

Why Ansible?

• Agentless: Unlike Puppet, Chef, Salt, etc. Ansible operates only over SSH
• Built with Python: It's a universal language these days.
• Self-documenting: Simple YAML files describing the playbooks and roles.
• Feature-rich: Some call these “batteries included”, but there are over 150 modules provided out of the box, and new ones are pretty easy to write.

Important Terms

1. PlayBook: Playbooks are the bread and butter of Ansible. They represent collections of ‘plays’, configuration policies which get applied to defined groups of hosts. Basically, it contains all the instructions we provide to the Ansible to perform the desired tasks. It is written in Declarative languages like YAML(preferred) or JSON. By constructing proper Playbooks, there’s almost no limit to what you can do with Ansible.
2. Collections: Playbooks, however, can get very complex. Ansible Collections are pre-packaged content that can be used as-is or modified to meet your needs. The content found in Ansible Collections includes those for specific purposes, tools, and even demos to help you learn the ins and outs of Ansible. They are certified by Redhat.

This is an intermediate level workshop where it is understood that the basics of the Ansible technology is known. Here we are going to focus more on Ansible Tower, which is an advanced tool.

The main question that brings us to the topic is:

What will happen, if the main server on which we are running Ansible, goes down, i.e. my control node goes down?

That's where Ansible Tower comes into the picture. It gives Clustering features. We can have multiple towers deployed and share a common database so that if one server goes down, others can continue the management.

Ansible Tower

One of the major gripes from Ansible users is that it didn’t have a proper GUI. This was an especially critical issue because good UI is important for occasional and new users to get comfortable and familiar with an application, before diving into the complexities of the CLI and playbook creation. Ansible itself was (and still is) rather new, so most of its users were by definition, new users.

Ansible Tower, previously called the AWX project, is the fix to this problem. It is a comprehensive web-based UI for Ansible, containing the most important Ansible features, especially those that render better as graphical rather than text-based output, such as real-time node monitoring.

Ansible vs Ansible Tower: What are The Key Differences | UpGuard

Some of the important features of Ansible Tower are listed below. The full feature list is available off the Ansible website.

1. Role-based access control: you can set up teams and users in various roles. These can integrate with your existing LDAP or AD environment.
2. Job scheduling: schedule your jobs and set repetition options
3. Portal mode: this is a simplified view of automation jobs for newbies and less experienced Ansible users. This is an excellent feature as it truly lowers the entry barriers to starting to use Ansible.
4. Fully documented REST API: allows you to integrate Ansible into your existing toolset and environment
5. Tower Dashboard: use this to quickly view a summary of your entire environment. Simplifies things for sysadmins while sipping their coffee.
6. Cloud integration: Tower is compatible with the major cloud environments: Amazon EC2, Rackspace, Azure.

Use-Cases

1. Provisioning

We can create an AWS instance using Ansible Tower using a pre-created Job Template.

First, we need to create the Playbook containing the infrastructure as code. We are going to create a VPC and an Internet Gateway. Inside the VPC, we create a Subnet and finally provision an RHEL 8 EC2 instance in it.

This use-case is an Example of CD, part of DevOps. These days once there is any code change in big firms, they re immediately deployed. Once deployed in a testing environment, it becomes easy to understand the potential errors and security flaws.

From the Ansible Tower GUI, we can build a job template to perform the desired task. In the template, we can add the playbook, credentials, etc. Tower has a database to securely store the credentials. After that, we select the Launch Button. Automatically we see the entire infrastructure is built on AWS.

2. ChatOps

We can integrate Slack with Ansible Tower so that any changes related to the production immediately updates all developers connected to the slack channel.

In Ansible Tower, we have the feature of creating Workflows, which helps to run multiple playbooks together. We can visualize it in the Visualizer and update the workflow.

Most companies set up a continuous delivery pipeline for testing the application in a Development environment. But the process of Deploying to the Production environment needs manual intervention. We can use Ansible Tower to do the approval of the workflow to pass the application to the production environment.

3. Extending Ansible Automations to 3rd-Party Tools

Since Ansible requires Python to run, we can leverage various features of Python in Ansible. For example, we can create virtual environments in python and install specific packages in it. We can later use the particular virtual environment in the Tower.

Oracle Cloud integration is not provided by Ansible Tower out of the box. But we can connect Ansible tower to the Oracle Cloud through the oci package provided by the latter. The package can be installed in the virtual environment and Tower can be instructed to use the environment. Also, we can create Credential Types to store the credentials, since the cloud is not having the support to store the Credentials by default in Ansible Tower.

Thus we can set up any of the Cloud Providers and use the existing tools and infrastructure and have them imported into Ansible Tower to securely perform the automation and orchestration.

You can reach out on my Twitter, Instagram, or on LinkedIn if you need more help. I would be more than happy.

If you have come up to this, do drop an 👏 if you liked this article.

Good Luck 😎 and happy coding 👨‍💻

Learning Kubernetes has been one of my top priorities this year. I spent quite a lot of time finding good resources to learn and have hands-on experience with the technology.

Finally, I came across Civo Kubernetes, when one of my seniors recommended the platform to me. Yeah, it was the one I was looking for!

The Civo Kubernetes Platform provided me with fully managed K3s clusters as well as high-quality learning videos about Kubernetes from the platform developers themselves. I instantly got a $250 credit in my Civo account once I signed up with my credit card.

Introduction

I am currently in the final year of my Bachelor's degree in Computer Engineering, from KIIT University, Bhubaneswar, India.

In fact, this is my 2nd victory in a nationwide hackathon this year. Earlier this year, I had finished as the First Runners-up at the TCS Inframinds Hackathon. Apart from that, I am currently a DevOps intern at Highradius Technologies and also an enthusiastic open-source contributor.

When I got to know about the Civo Hackathon, I planned to take part in it as I needed hands-on experience with Kubernetes. Also, the speaker line-up before the commencing of the hackathon was interesting. I got to know about the platform as well as about monitoring and profiling from the developer advocates of Civo.

The hackathon spanned over the 2nd weekend of November 2021, starting from Friday, when we had the speaker sessions till Sunday evening. The results were finally announced the very next Monday.

Much to my surprise, I finished up 2nd !!!!!!

My Project

The project I built is a Computer-Aided Diagnostic System that is used to predict whether a person has been infected with COVID-19.

The prediction is possible through the integration of the COVID-19 X-Ray Classifier into a Web Application. By uploading Frontal Chest X-Rays, the model can perform classification between COVID and non-COVID X-Rays using Modified DenseNet architectures.

The users are given the option to save the results to the Database to receive further advice from doctors. The data is stored securely in MongoDB. Apart from that, REST API has been provided for Developers to access the Deep Learning Model and get prediction data in their applications. I have also enabled monitoring facilities for the application.

The entire project was hosted on the Civo Kubernetes Platform.

How I built it

The project kickstarted with the Development of the Web Application. The UI was finalized and then the application was developed. Several open-source styles, libraries and toolkits were used during the development of the Frontend with HTML, CSS and JavaScript.

After completion, the backend of the application was developed with Python & Flask framework. The routes were created and mapped to the Frontend. The Deep Learning Model was integrated with the backend REST APIs. Various libraries such as Numpy, Pillow and Tensorflow was used to manage the model. Finally, MongoDB was integrated with the backend to save the Form data.

This completed the Web Application Development.

The next stage involved deploying the application on Civo K3s Cluster by developing an automated DevOps CI/CD Pipeline. First, the entire application code was pushed to a GitHub repository. Through this step, the code version control is ensured and any change in the code would automatically trigger the entire pipeline.

To deploy applications on K8s, the application needed to be containerized. The building of the Docker container should automatically take place once any code gets changed. After building the container, it needs to be pushed to a Docker Repository, here Dockerhub. Also, the old Docker Image Tag mentioned in the code would need to be replaced by the new Docker Image Tag. For automating all these, a Continuous Integration Pipeline was created with the help of Github Actions as the CI tool.

A workflow file was written to sequence the jobs that needed to be performed, once the code get changed in the repository. The jobs involved building and pushing the Docker container to Dockerhub. After pushing, the new container tag replaced the older one mentioned in the customization file automatically, with the help of Kustomize.io. The Deployment, Service and Ingress YAML files were pushed to the repository as K8s needed these files during deployment.

Github Actions Workflow file:

name: CIVO HACKATHON WORKFLOW

on: 
  push:
    branches: [ master ]

jobs:

  build:
    runs-on: ubuntu-latest    
    steps:      
      - uses: actions/checkout@v2
      - name: Build and push Docker image
        uses: docker/build-push-action@v1.1.0
        with:
          username: ${{ secrets.DOCKER_USER }}
          password: ${{ secrets.DOCKER_PASSWORD }}
          repository: ${{ secrets.DOCKER_USER }}/civo-hackathon
          tags: ${{ github.sha }}, latest


  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    needs: build

    steps:
    - name: Check out code
      uses: actions/checkout@v2

    - name: Setup Kustomize
      uses: imranismail/setup-kustomize@v1
      with:
        kustomize-version: "3.6.1"

    - name: Update Kubernetes resources
      env:
        DOCKER_USERNAME: ${{ secrets.DOCKER_USER }}
      run: |
       cd kustomize/base
       kustomize edit set image civo-hackathon=$DOCKER_USERNAME/civo-hackathon:$GITHUB_SHA
       cat kustomization.yaml

    - name: Commit files
      run: |
        git config --local user.email "action@github.com"
        git config --local user.name "GitHub Action"
        git commit -am "Bump docker tag"
    - name: Push changes
      uses: ad-m/github-push-action@master
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}

This completed the Continuous Integration process.

The final stage was to deploy the Docker Image pushed in DockerHub, into a CIVO k3s Cluster. For this, a K3s cluster was created on Civo. Due to CPU intensive nature of the application, the Largest Node configuration was selected. Then through the Civo CLI, the KubeConfig file was connected with the local KubeCTL tool.

Through KubeCTL, a namespace was created and ArgoCD was installed in it. Inside ArgoCD, the configuration was provided to continuously track the GitHub Repository for changes in the Kustomization file.

Since previously through CI, we had managed to update the Kustomization file after a new code change took place, this update in the Kustomization file triggered the ArgoCD to re-deploy the application based on the newer Docker Image Tag provided. Thus after an initial manual Sync, ArgoCD managed to complete the Continuous Deployment process.

The CI/CD Pipeline was successfully created which helped to automatically deploy code changes to production.

After the application was properly working, I proceeded with installing Prometheus and Grafana in a separate namespace in the cluster to fetch and visualize the metrics. For that, I edited the Flask application to make it generate metrics to be fed to Prometheus.

Then I developed a Service Monitor for exposing the metrics endpoint of the application which in turn would be automatically added to the Prometheus Target group. Now, I was able to fetch metrics into Prometheus from the Web application. After that, I set up the Grafana Dashboard to visualize the metrics.

This finally concluded the project.

My Experience

Overall, I had a great experience learning and executing new things within a short span of time. The process of deployment could not be made smoother without the Civo Platform. The fact that we can launch a cluster within a few minutes, along with having a marketplace from where we can pick services we want to preinstall in the cluster, really simplified the process for newbie Kubernetes developers like me.

Apart from that, the presence of the Kubernetes academy which contains beginner-friendly videos about all the different features of K8s, integrated into the platform, helped me to quickly navigate and get my doubts cleared before applying stuff on my cluster.

And of course, we had the option of directly contacting the Civo team via Slack to get out queries resolved. Special thanks to Saiyam Pathak, for his Monitoring video, which really helped me set up the monitoring stack easily.

What's next for the project

Although I tried my best to incorporate all the domains of DevOps into my application, still there are some places that need attention.

First and foremost, I tried to incorporate the GitOps principle as much as possible, which included pushing the application code, Kubernetes Manifests as well as Terraform scripts to the Git. But still, there were some settings that I had to manually set inside the cluster like setting up the ArgoCD. Since ArgoCD supports GitOps, I would be declaring the settings from Git itself.

Apart from that, I would be incorporating some Logging and Profiling tools in the cluster, that would give a better picture of the application deployment.

Last but not the least, the model which has been deployed can currently perform classification only. But recently, in some researches, it has been proved that through Instance Segmentation on the X-Rays, we can actually measure the severity of the spread of the virus by precisely identifying the locations of the GGOs. In the future, I want to integrate such a model with the application, so that users can also measure the severity of the virus instantly.

You can visit the repository from below:

Demo : https://covid-predictioned.herokuapp.com/

DevPost : https://devpost.com/software/covid-19-prognosis

Civo - https://www.civo.com/

You can reach out on my Twitter, Instagram, or LinkedIn if you need more help. I would be more than happy.

Introduction

AWS Amplify is a full suite of tools and services created to make it simple for developers to build and release apps. It was introduced in 2017. Additionally, it might have ready-to-use components, code libraries, and a built-in command-line interface (CLI). The ability to swiftly and securely integrate a variety of tasks, from API to AI, is this tool's most important asset.

The user experience is another factor in the introduction of AWS Amplify. User experience is the most crucial factor that must be taken into account while creating any programme. The user experience across many platforms, including online and mobile, was intended to be unified through AWS Amplify.

Amplify effortlessly scalable with your business from thousands of users to tens of millions of users and covers the entire mobile application development workflow from version control and code testing to production deployment.

The open source Amplify libraries and CLI, which are a component of the Amplify framework, provide a pluggable interface that you may personalise and develop your own plugins for.

Benefits

• Don't reinvent the wheel; instead, concentrate on your business. Why create your own authentication system when there are already ones out there that can handle MFA, social providers, and all business features?

• Use Amplify to prototype cool ideas and discard features one at a time if necessary. Why not take advantage of the high-quality proof of concept work Amplify makes possible? As an illustration, you could construct your API using produced AppSync resolvers and then gradually replace them with custom resolvers as needed (similarly to Create React App).

• Solid DevOps requires good multi-environment design. On-the-fly bootstrapping of new environments is possible. Additionally, the amplification environments can use the same git procedure.

Getting Started

In this article, you will be seeing how we can easily deploy any web application on AWS Amplify. For example, here we are going to deploy a React Application. The source code can be found on the following Github link.

Pre-requisites

• an AWS account (of course 🤪)
• Node.JS installed in your system
• a Github Account and Git CLI installed in your system
• Code Editor of your choice (VSCode preferred)

Cloning and Testing the Application Locally

First, we are going to clone the repository and run the application locally in our system. Create a directory in your system and open it with VSCode. You can use the in-app command terminal to execute the code snippets.

To start, clone the repository with the following command:

git clone https://github.com/aditya-sridhar/simple-reactjs-app

Once the repository is cloned, you will see a new directory inside the folder. Navigate inside the directory and type the following commands:

npm install

This will install all the dependencies required to run the application, in your system.

Once completed, you can run the application with the following command:

npm start

The web browser will pop up and you will be seeing the following page:

Thus, we have successfully cloned and tested the application in our local system.

Pushing the application code to your Github Account

Now, we have to upload the code to your Github account, so that you can use the code with AWS Amplify. For creating a repository, we are going to use the Github CLI.

First, delete the .git folder present in the root directory.

Then, initialize the directory with the following command:

git init

After that, lets create a repository with the Github CLI. Type the following command:

gh repo create aws-react-hosting

This will create a repository in your Github Account. Finally. we will be pushing the codes in this repository.

git add .
git commit -m "First Commit"
git remote add origin <link-to-your-github-repo>
git push -u origin main

Deploying on AWS Amplify

Now let's move on to deploy the application to AWS Amplify.

1. Open the AWS HomePage.

2. Login and visit the Console.

3. Select AWS Amplify from the List.

4. You will reach to the following page:

5. Select GitHub from the Options available.

6. Authorize the connection and select the repository you had created earlier.

7. Click Next and Save and Deploy.

8. Finally, you will come to the following page:

9. Once all the stages are completed, click on the link to see the live website.

Thus, we have successfully deployed a React application on AWS Amplify!!!

Conclusion

For web and mobile developers, Amazon Web Services Amplify can be quite helpful. For full-stack apps, all built-in authentication, alerts, and APIs may be implemented with a minimum of effort. Giving your clients the best value instead of wasting time managing the application infrastructure allows you to concentrate on your top priorities.

Moreover, the symptoms of novel coronavirus are quite similar to the general flu. Screening of infected patients is considered as a critical step in the fight against COVID-19. Therefore, it is highly relevant to recognize positive cases as early as possible to avoid further spreading of this epidemic. However, there are several methods to detect COVID-19 positive patients, which are typically performed based on respiratory samples and among them one of the critical approach which is treated as radiology imaging or X-Ray imaging. Recent findings from X-Ray imaging techniques suggest that such images contain relevant information about the SARS-CoV-2 virus.

Introduction

Deep learning is a popular area of research in the field of artificial intelligence. It enables end-to-end modelling to deliver promised results using input data without the need for manual feature extraction. The use of Machine Learning methods for diagnostics in the medical field has recently gained popularity as a complementary tool for doctors. Due to this, in recent times, many radiological images have been extensively used to detect COVID-19 confirmed cases.

Mask RCNN is a conceptually simple, flexible, and general framework for object instance segmentation. The approach efficiently detects objects in an image while simultaneously generating a high-quality segmentation mask for each instance. This method extends Faster R-CNN by adding a branch for predicting an object mask in parallel with the existing branch for bounding box recognition. Mask R-CNN is simple to train and adds only a small overhead to Faster R-CNN, running at 5 fps. Moreover, it is easy to generalize to other tasks.

Understanding Image Segmentation

Image segmentation is the process of partitioning a digital image into multiple segments. The goal of segmentation is to simplify and/or change the representation of an image into something that is more meaningful and easier to analyze.

Image segmentation is typically used to locate objects and boundaries (lines, curves, etc.) in images. More precisely, Image Segmentation is the process of assigning a label to every pixel in an image such that pixels with the same label share certain characteristics.

There are 2 types of Image Segmentation- Instance Segmentation and Semantic Segmentation.

Related Works

Sethy classified the properties obtained from different models of CNN with the SVM Classifier using X-Ray images. Besides, Wang suggested a Deep model for COVID19 patients recognition and achieved an accuracy of 92.4% in the classification of standard classes, non-COVID, and COVID-19 Pneumonia. In another study, a ResNet5026 model was proposed by Narin, and it achieved a COVID-19 detection accuracy of 98%. In terms of COVID-19 patients detection using X-Ray images, the Deep model of Ioannis reached a success rate of 98.75% for two classes and 93.48% for three classes. By comprising multiple CNN models, Hemdan has proposed a COVIDX-Net model that is capable of detecting confirmed cases of COVID-19. A transfer learning-based framework has been advised by Karmany to identify medical diagnoses and treatable diseases using image-based deep learning.

Understanding Ground Glass Opacity in X-Rays

The COVID-19 pandemic has brought radiologists’ penchant for descriptive terms front-and-centre, with frequent references to one feature in particular: ground-glass opacities.

The term refers to the hazy, white-flecked pattern seen on lung CT scans, indicative of increased density. It’s not quite as dense as the “crazy-paving” pattern, which looks like a mosaic or pavers, and less confounding than the “head cheese sign,” a juxtaposition of three or more densities present in the same lung.

Ground-glass opacities aren’t likely to be found in healthy lungs, though, and wouldn’t result from exposures like air pollution or smoking. There are a lot of diseases that can cause ground-glass opacities, but in COVID-19, there’s a distinct distribution, a preference for certain parts of the lung. COVID-related ground-glass opacities also have a very round shape that’s unusual compared with other ground-glass opacities.

Technologies Used

Supervisely

“Supervisely is a powerful platform for computer vision development, where individual researchers and large teams can annotate and experiment with datasets and neural networks.”

Supervisely provides the following advantages:

• Get from idea to a toy prototype in several minutes. It will take you 5 minutes to manually label 10 images, run data preparation script, train and apply the model.
• Leverage the largest Deep Learning models collection available. You can use Deep Learning models in a unified, framework-independent way. So the experiments are fast and cheap, it’s easy to compare the performance of different models on your task.
• Fast iterations. Active learning to improve your models continuously is a huge benefit to our platform.
• Get ready-to-use ecosystems. Organizing workflow of data annotators, reviewers, data scientists and domain experts in a way that results are sharable and available with the emphasis on fast iterations usually implies creating complex front-end/back-end infrastructure that we provide out of the box.

Getting Started

Requisites

We should have an active AWS account to connect our Supervisely account to an instance for training. We should know how to start an AMI Linux Instance there and install the software in it.

Working with Supervisely

First, we need to create an account in Supervisely. After creating the account, we need to create a Workspace and a team.

1. Uploading the dataset of Images

Then we need to create a Project. Inside the Project, we upload the dataset or images.

2. Annotating all Uploaded Images

After creating the project and uploading the images, we need to annotate the images, so that our model knows what exactly to look in the images.

3. Performing Data Augmentation

After annotation, we need to increase the number of images available in our dataset for getting accurate results. For this, we use a DTL code which would perform some necessary changes in our image to create some new versions of it. Some of the techniques we use are: rotating, increasing or decreasing contrast or the brightness of our images to create the new versions.

For this, We need to upload a DTL code shown below:

After completing up to this, we will find another folder automatically created which contains at least 4 times the images we originally provided.

5. Connecting to EC2 Instance to train the model

Now we need to select a Neural Network model from the list for training. In our case, we are going to use the Mask RCNN model.

Now is the time when we need to create an instance in AWS and connect it with the Supervisely to perform the training operations.

The pre-requisite for an instance by default set by Supervisely includes having a GPU. But since GPU are costly and we have to request AWS for increasing the limit, we will just train our model and download the weight file. After that, we would manually run the weight file in our local machine to view the output.

In AWS, we run an Amazon Linux instance and connect it with our local machine via ssh. After that, we install Docker inside the instance since Supervisely needs Docker as it will automatically download a Docker image of the program which will perform the training.

After we install Docker in the instance, we need to connect Supervisely with the instance, using the highlighted Bash Script.

This will download the Supervisely Docker image in our Instance. All the requires dependencies required for training our model are packaged in this Docker image.

After this, from the Neural Networks tab, we start the Training Process of our model.

Since we don't have any GPU in our instance, we would find this error:

But, we can still download the weights file in the following way:

6. Finding the Output

After downloading the weights file, we update the Mask RCNN demo code available at Matterplot Repository accordingly to accept this weight file.

Conclusion

Thus by the above process, we were able to perform instance segmentation on COVID Chest X-Rays. Our model confirmed that the X-ray provided was having Ground Glass Opacities, which in turn predicted that the associated person might be infected.

By more proper annotations on the training images, we can increase the accuracy of the model so that it can mask the exact area of the GGOs in the future. Moreover, we can provide a powerful remote instance having GPUs, which can automate the entire process remotely, rather than testing the weights manually.

You can reach out on my GitHub, Twitter, Instagram, or on LinkedIn if you need more help. I would be more than happy.

If you have come up to this, do drop an 👏 if you liked this article.

Good Luck 😎 and happy coding 👨‍💻

The modern-day game-changers spurred on by the Annual ImageNet Large Scale Visual Recognition Challenge (ILSVRC).

Source: anyconnect.com

In 2012, AlexNet, which was a deep convolutional neural net (CNN) bested that result by getting an error rate of 15.3%. This was a game-changer because it was the first time that such results were achieved.

Subsequent image processing solutions in the following years improved on results of AlexNet. In 2014, GooLeNet/Inception achieved an error rate of 6.67%. In 2015, ResNet further brought the error rate down to 3.6%.

Introduction

1. What do we mean by ML-Ops?

The process of integrating the tools and concepts of DevOps for solving the problems faced while training Machine Learning Models, by automatic adjustment of the Hyper-parameters, leading to increased accuracy, is the fundamental concept behind ML-Ops.

The most important factor from DevOps, i.e. a focus on Continuous Integration/Continuous Delivery (CI/CD) is applied directly to model generation, while regular deployment, diagnostics and further training can also be done on a frequent process, rather than waiting for one large upload at much slower intervals.

Check out this great Article to know more

https://neptune.ai/blog/mlops-what-it-is-why-it-matters-and-how-to-implement-it-from-a-data-scientist-perspective

2. Transfer-Learning in the world of CNN

It is a machine learning method where a model developed for a task is reused as the starting point for a model on a second task.

It is a popular approach in deep learning where pre-trained models are used as the starting point on Computer Vision(CV) and Natural Language Processing(NLP) tasks are given the vast compute and time resources required to develop neural network models on these problems.

Source: towardsdatascience.com

This method can give high accuracy with limited images and resources.

Synopsis

This project explains the process of automating the task of adjusting the Hyper-parameters of our Face Recognition Model, for attaining the perfect accuracy using Docker, Jenkins and Git/GitHub.

Briefing about the Face Recognition model

The Face Recognition model is built using the method of Transfer Learning. VGG16 pre-trained model is used for the purpose.

The possible Hyper-parameter Tunings here:

★ Adjusting the number of FC layers

★ Adjusting the Learning Rate

★ Choosing an optimizer and a loss function

★ Deciding on the batch size and number of epochs

The Code for the Face Recognition model can be downloaded from here.

Video Demonstration of the Model

Pre-requisites

First of all, we are assuming that Docker, Git, and Jenkins with the Git Plugin are installed in the system.

In this article, we are directly beginning with integrating our Face Recognition Model with DevOps tools.

In this article, we are going to RHEL 8.2 as our Host OS.

Getting Started

We are going to use Docker containers to build and run our Machine Learning Models. Different custom Docker containers will be built using the DockerFile to support different architectures of the ML models.

Through Jenkins, we are going to create multiple jobs as follows:

JOB#1: Pulling the Github repository automatically when some developers push the repository to Github.

JOB#2: By looking at the code or program file, Jenkins will automatically start the respective image containers to deploy code and start training.

( eg. If code uses CNN, then Jenkins should start the container that has already installed all the software required for the CNN processing)

JOB#3:Training the model and predicting the accuracy or metrics.

JOB#4: If the Metrics Accuracy is less than 90%, then tweaking the machine learning model architecture.

JOB#5: Retraining the model and notifying that the best model is being created.

JOB#6:(Monitoring) If container where the app is running, fails due to any reason then this job will automatically start the container again from the last trained model.

1. Setting up the Docker Containers

We are going to create 3 Docker containers for serving different ML models.

✓ CNN model

✓ ANN model

✓ Linear/Logistic Regression Models

1.1. Setting up the Docker container for CNN and ANN models

For setting up this container, we are going to use the tensorflow/tensorflow image from DockerHub.

To download the image to our local machine, we have to run the following command from the Command Line:

docker pull tensorflow/tensorflow

After installing the image, we need to modify the image so that we can run our CNN & ANN models in the container. We will be using Dockerfile to build our custom image.

To create the custom image, we need to create an empty file named Dockerfile anywhere in our host machine.

The contents of the Dockerfile will be as follows:

FROM tensorflow/tensorflow:latest

RUN pip3 install keras -y &&\
    pip3 install numpy -y &&\
    pip3 install pandas -y &&\
    pip3 install pillow -y &&\
    pip3 install scikit-learn -y &&\</span>

After making the Dockerfile we need to build it to create our image using:

docker build -t cnn_image:v1 . (from the same folder)

This would create our custom cnn_image image in the local machine.

1.2. Docker container for Linear/Logistic Regression Models

For setting up this container, we are going to use the centos image from DockerHub.

To download the image to our local machine, we have to run the following command from the Command Line:

docker pull centos

After installing the image, we need to modify the image so that we can run our Linear/Logistic Regression Models in the container. We will be using Dockerfile to build our custom image.

To create the custom image, we need to create an empty file named Dockerfile anywhere in our host machine.

The contents of the Dockerfile will be as follows:

FROM centos:latest

RUN yum install epel-release -y &&\
    yum update -y &&\
    yum install python36 -y &&\
    pip3 install scikit-learn -y &&\
    pip3 install numpy -y &&\
    pip3 install pandas -y &&\
    pip3 install matplotlib -y &&\
    pip3 install pillow -y &&\
    yum update -y</span>

After making the Dockerfile we need to build it to create our image using:

docker build -t regression_image:v1 . (from the same folder)

This would create our custom regression_image image in the local machine.

★ Thus we have successfully set up the Docker containers in our system. ★

To verify the installation of Docker images we can check the list of all images installed in our local machine: docker image ls

2. Building the Jenkins Pipeline

2.1. Job-1: Automatic Code Download

Before downloading the code, we need to create some folders on our local machine which would act as volumes for the Docker containers.

To create the folders in our local machine:

mkdir /root/Desktop/ml_models
cd /root/Desktop/ml_models/
mkdir cnn ann reg</span>

First, the downloaded codes would be copied in the ml_models directory.

For creating the Job for downloading codes:

1. Select new item option from the Jenkins menu.
2. Assign a name to the Job ( eg. model_download )and select it to be a Freestyle project.
3. From the Configure Job option, we set the configurations.
4. From the Source Code Management section, we select Git and mention the URL of our GitHub Repository and select the branch as master.
5. In the Build Triggers section, we select Poll SCM and set the value to * * * * *. This means that the Job would check any code change from GitHub every minute.
6. In the Build Section, we type the following script: sudo cp -v -r -f * /root/Desktop/ml_modelsThis command would copy all the content downloaded from the GitHub master branch to the specified folder for deployment.
7. On clicking the Save option, we add the Job to our Job List.

On coming back to the Job List page, we can see the Job is being built. If the colour of the ball turns blue, it means the Job has been successfully executed. If the colour changes to red, it means there has been some error in between. We can see the console output to check the error.

Till now, we have successfully downloaded the codes from GitHub to our Server System automatically.

2.2. Job-2: Classifying the files based on the architecture of the model

Once the files have been downloaded, we need to copy the files to their respective folders automatically.

For creating the Job for classifying the files:

1. Select new item option from the Jenkins menu.
2. Assign a name to the Job ( eg. model_classification )and select it to be a Freestyle project.
3. From the Configure Job option, we set the configurations.
4. From the Build Triggers section, we select Build after other projects are built and mention model_download as the project to watch. This is called a DownStreaming Job.
5. In the Build Section, we type the following script:

6. On clicking the Save option, we add the Job to our Job List.

Thus, we have successfully transferred the files to their respective folders. Also, we have set these folders as volumes of the Docker Containers and started the service.

2.3. Job-3: Training the model and predicting the accuracy or metrics

Now, we have to start training the model already loaded to the respective Docker container.

For creating the Job for Training the model:

1. Select new item option from the Jenkins menu.
2. Assign a name to the Job ( eg. model_training )and select it to be a Freestyle project.
3. From the Configure Job option, we set the configurations.
4. From the Build Triggers section, we select Build after other projects are built and mention model_classification as the project to watch. This is called a DownStreaming Job.
5. In the Build Section, we type the following script:

6. On clicking the Save option, we add the Job to our Job List.

By the end of this job, we have downloaded, classified and trained the model. We have also found out the accuracy of the model after training.

For this project, we are setting 90% as the needed Accuracy for the project.

Now, if we find the accuracy obtained is not sufficient, we have to do the Hyper-parameter tuning. This would start the Job-4.

Otherwise, a mail would be sent to the user stating the Desired accuracy has been reached. This would be done by Job-5.

2.4. Job-4: Retraining the model to increase the Accuracy

Suppose, after training the model, we find out the accuracy is below the desired amount. Thus, we have to adjust the hyper-parameters for increasing the accuracy of the models.

This is where DevOps steps in. With the help of Continuous Integration Pipeline (CI Pipeline), we can automate the process of Hyper-parameter tuning. Thus the work which would require a lot of days if done manually can be finished within a few hours without much human intervention.

Note: After training and testing our Face Recognition model locally, it has been found out that adding some extra Fully Connected Layers (FC Layer), increases the accuracy beyond our desired mark.

Thus we are focussing on adjusting a single hyperparameter for this article. Later on, we can easily add the function of checking other hyperparameters, if a specific model demands one.

For creating the Job for Retraining the model:

1. Select new item option from the Jenkins menu.
2. Assign a name to the Job ( eg. model_retrain)and select it to be a Freestyle project.
3. From the Configure Job option, we set the configurations.
4. From the Build Triggers section, we select Trigger builds remotely an option.
5. Provide an Authentication Token
6. In the Build Section, we type the following script:

7. On clicking the Save option, we add the Job to our Job List.

Thus, the Job has been setup. To Trigger the Build, the following command would run the job: curl --user "<username>:<password>" JENKINS_URL/view/Mlops-project-1/job/model_retrain/build?token=TOKEN_NAME

e.g. curl --user "admin:admin" http://192.123.32.2932:8080/view/Mlops-project-1/job/model_retrain/build?token=retraining_model

2.5. Job-5: Notifying that the best model is being created

If the trained model gives the desired accuracy at the beginning or by Hyper-parameter tuning, a mail is automatically sent to the user confirming the action.

For creating the Job for Notifying that the best model is being created:

1. Select new item option from the Jenkins menu.
2. Assign a name to the Job ( eg. model_notify)and select it to be a Freestyle project.
3. From the Configure Job option, we set the configurations.
4. From the Build Triggers section, we select Trigger builds remotely an option.
5. Provide an Authentication Token
6. In the Build Section, we type the following script:

sudo cp -rf /root/Desktop/ml_models/ *
sudo python3 sendmail.py</span>

7. On clicking the Save option, we add the Job to our Job List.

Thus, the Job has been setup. To Trigger the Build, the following command would run the job: curl --user "<username>:<password>" JENKINS_URL/view/Mlops-project-1/job/model_notify/build?token=TOKEN_NAME

e.g. curl --user "admin:admin" http://192.123.32.2932:8080/view/Mlops-project-1/job/model_notify/build?token=model_notification

Now, we have to introduce these remote triggers we have created in our Model file. For that, at the end of the code, we add a conditional statement:

2.5. Job-6: Additional Monitoring Job

If the container where the app is running, fails due to any reason then this job will automatically start the container again from the last trained model.

For monitoring the Jobs created:

1. Select a new item option from the Jenkins menu.
2. Assign a name to the Job ( eg. monitor_job )and select it to be a Freestyle project.
3. From the Configure Job option, we set the configurations.
4. From the Build Triggers section, we select Build after other projects are built and mention model_train & model_retrain as the project to watch.

It is important to select “Trigger even if the build fails” option from the drop-down list.

5. In the Build Section, we type the following script:

6. From the Post Build Actions dropdown, we select “Build Other Projects” and mention model_train as the project to build.

7. On clicking the Save option, we add the Job to our Job List.

Therefore, whenever a container stops due to some problems during training the model, Jobs#3 & Jobs#4 would fail. This would trigger this Job#6 to restart the containers and again start Job#3.

Understanding the Complete Workflow properly

When a user adds a new model in the connected GitHub account,

★ Jenkins would download the code into the local system.

★ Once the code is received, Job#2 would classify the model and add it to the respective folder and attach the folder as the volume of the Docker Container.

★ Job#3 would execute the file inside the Docker container and train the model and predict the accuracy or metrics.

★ Now, if the accuracy is below the desired, Job#4 would run. It would retrain the model by changing the hyper-parameters.

★ Once the accuracy becomes greater than the desired, Job#5 will be fired, resulting in the automatic sending of an e-mail to the Developer.

★ At last, Job#6 is set as a Monitoring Job. It would continuously check whether the container crashes during training and would restart them.

Conclusion

Previously, we had an additional 3 Dense layers attached to the pre-trained model of VGG16. We came to an accuracy of 86%.

After running this Pipeline, 2 more layers were added at the end through these automation tools, due to which the accuracy touched 92%.

This method of Automated Hyperparameter Tuning would help in adjusting the accuracy of Machine Learning models faster and efficiently. This is the main reason for using the power of ML-Ops to solve these real-life situations.

You can reach out on my Twitter, Instagram, or on LinkedIn if you need more help. I would be more than happy.

Good Luck 😎 and happy coding 👨‍💻