Install Using GitHub Actions in AWS

Overview

This guide provides step-by-step instructions for installing DIGIT using GitHub Actions in an AWS environment.

This guide provides step-by-step instructions for installing DIGIT using GitHub Actions in an AWS environment.

Pre-requisites

• Github account - signup

• Kubectl installed in the system - installation guide

• AWS account - signup

• Install AWS CLI locally - installation guide

• Postman - installation guide

• A domain host

Install

• Prepare AWS IAM User

• Create an IAM User in your AWS account - official document

• Generate ACCESS_KEY and SECRET_KEY for the IAM user - AWS document

• Assign administrator access to the IAM user for necessary permissions.

• Set up the AWS profile locally by running the following commands

  • aws configure --profile {profilename}

  • fill in the key values as they are prompted

    • AWS_ACCESS_KEY_ID: <GENERATED_ACCESS_KEY>

    • AWS_SECRET_ACCESS_KEY: <GENERATED_SECRET_KEY>

    • AWS_DEFAULT_REGION: ap-south-1

  • export AWS_PROFILE={profilename}

• Fork the following Repositories with all the branches into your organisation account on GitHub - official documentation.

  • Health-campaign-devops

  • Master data

  • configs

Adding AWS keys to the repository

• Go to the forked health-campaign-devops repository

• Navigate to the repository settings

• Then to Secrets and Variables

• Then click on actions options below secrets and variables

• On the new page, choose the new Repository secret option in Repository secrets and add the following keys mentioned below

  • AWS_ACCESS_KEY_ID: <GENERATED_ACCESS_KEY>

  • AWS_SECRET_ACCESS_KEY: <GENERATED_SECRET_KEY>

  • AWS_DEFAULT_REGION: ap-south-1

  • AWS_REGION: ap-south-1

Changes to be made in the repository

• Navigate to the Kubernetes-1.27 branch in the forked DevOps Repository

• Enable GitHub Actions

  • Click on Actions then click on I understand my workflows, go ahead and enable them

How to edit the GitHub files

• The following steps can be done either directly in the browser or the local system if you are familiar with git usage

• Before following any of the steps switch to the kubernetes-1.27 branch

1. Steps to edit the git repository in the browser - Git guide

2. Steps to edit in the local system if you are familiar with Git basics

   1. Git clone {forked DevOps repolink}

   2. Follow the below steps and make changes

   3. Then commit and push to the kubernetes-1.27 branch

   4. NOTE: Complete all changes at once then commit and push the code to remote to trigger the installation.

Replace the master and config repositories

• Note: - make these repository/Branch changes before installation, changes to the config repository link in the DevOps Repository after installation without working understanding will lead to failure in the application functionality.

• Navigate to egov-demo.yaml (config-as-code/environments/egov-demo.yaml)

• Under the egov-mdms-service: initContainers: change the gitsync repository link of master data to the master data repository you forked and the branch to DEMO (The branch also can be changed based on your choice).

• Under the egov-persister: change the gitsync link of the health-campaign-config repository to the forked config repository and the branch to DEMO

• Under the egov-indexer: change the gitsync link of the health-campaign-config repository to the forked config repository and the branch to DEMO

Configure Infrastructure-as-code

• Navigate to infra-as-code/terraform/sample-aws.

• Open input.yaml and enter details such as domain_name, cluster_name, bucket_name, and db_name.

Configure application secrets

• Generate SSH key pair

• How to Generate SSH Key Pair - choose one of the following methods to generate an SSH key pair:

  • Method a: Use an online website. (Note: This is not recommended for production setups, only for demo purposes): https://8gwifi.org/sshfunctions.jsp

  • Method b: Use OpenSSL commands:

    • OpenSSL genpkey -algorithm RSA -out private_key.pem

    • openssl rsa -pubout -in private_key.pem -out public_key.pem

    • To view the key run the commands or use any text editor to open the files

      • vi private_key.pem

      • vi public_key.pem

• Once generated Navigate to config-as-code/environments

• Open egov-demo-secrets.yaml

• Replace ssh_private_key (note: please make sure the private key is indented as given)

• Add the public_key to your GitHub account - Git guide

Finalise Installation

• Once all details are entered, push these changes to the remote GitHub repository. Open the Actions tab in your GitHub account to view the workflow. You should see that the workflow has started, and the pipelines are completed successfully.

Configure domain name

• Once the deployment is done get the CNAME of the nginx-ingress-controller

kubectl get svc nginx-ingress-controller -n egov

• The output of this will be something like this:

  ae210873da6ff4c03bde2ad22e18fe04-233d3411.ap-south-1.elb.amazonaws.com

• Add the displayed CNAME to your domain provider against your domain name.

Create superuser

• Connect to the Kubernetes cluster, from your local machine by using the following cmd

aws eks update-kubeconfig --region ap-south-1 --name $CLUSTER_NAME

• Check if all the egov-user service is up and running by the following cmd

kubectl get pods -n egov | grep egov-user

If all the egov-user service is running with Ready 1/1, then connect to it by port forwarding

kubectl port-forward svc/egov-user -n egov 8080:8080

• Import the below curl in Postman or execute it in another terminal window

curl --location 'http://localhost:8080/user/users/_createnovalidate'
--header 'Content-Type: application/json'
--data-raw '{ "requestInfo": { "apiId": "Rainmaker", "ver": ".01", "ts": null, "action": "_update", "did": "1", "key": "", "msgId": "20170310130900|en_IN", "authToken": "51e00caf-3218-4f15-ba70-a45f7d40abc1" }, "user": { "userName": "<>", "name": "Admin User", "gender": null, "mobileNumber": "9898989898", "type": "EMPLOYEE", "active": true, "password": "<>", "roles": [ { "name": "Super User", "code": "SUPERUSER", "tenantId": "mz" } ], "emailId": "xyz@gmail.com", "tenantId": "mz" } }'

• Replace the username, password, and tenantId with proper values (keep tenantid as 'mz' if master data is unchanged).

Restart Zuul service

• Check if all the services are up and running by using the following cmd

kubectl get pods -n egov

• If all the services are running with Ready 1/1, then restart the Zuul service by using the below cmd

kubectl delete pods {zuul-pod-name} -n egov

DIGIT Infrastructure - Cleanup & Uninstallation

As you wrap up your work with DIGIT, ensuring a smooth and error-free cleanup of the resources is crucial. The regular monitoring of the GitHub Actions workflow's output is essential during the destruction process. Watch out for any error messages or signs of issues. A successful job completion will be confirmed by a success message in the GitHub Actions window, indicating that the infrastructure has been effectively destroyed.

When you're ready to remove DIGIT and clean up the resources it created, proceed with executing the terraform_infra_destruction job. This action is designed to dismantle all setup resources, clearing the environment neatly. We hope your experience with DIGIT was positive and that this guide makes the uninstallation process straightforward.

Steps to destroy the server

To initiate the destruction of a Terraform-managed infrastructure, follow these steps:

• Navigate to Actions.

• Click DIGIT-Install workflow.

• Select Run workflow.

• When prompted, type "destroy". This action starts the terraform_infra_destruction job.

• You can observe the progress of the destruction job in the actions window.