Project MyCuan(PPOB) Cloud Deploy Flow

Published by Ardhi Ramadhani on June 13, 2022

Introduction

MyCuan is an application for bill payment services and online transactions available in real-time 24/7, known for its speed and security. MyCuan provides several product categories, including Top-up, bills, entertainment, and digital wallets.

Note: This post focuses on the cloud deployment flow and REST API design.
Configuration and schema deployment design for the REST API was implemented by me.

Technical Implementation

Schema Deploy the REST API

Our schema illustrates a comprehensive CI/CD pipeline that leverages GitHub for version control and AWS for cloud infrastructure. It's designed to support both development and production environments, ensuring smooth transitions from code commits to live deployments.

GitHub: The Source of Truth

At the heart of our schema is GitHub, serving as our central code repository. We've implemented a branching strategy that includes:

• BRANCH DEVELOP: This is where active development happens. It's the playground for our developers to implement new features and fixes.
• BRANCH MASTER: This represents our production-ready code. Only thoroughly tested and approved code makes it here. The arrows between these branches represent our merge and review processes, ensuring code quality at every step.

AWS: Our Cloud Infrastructure Backbone

Our schema heavily relies on Amazon Web Services (AWS) for both development and production environments. Let's break down each component:

Production Environment (mycuan-security-prod)

1. Amazon EC2 (43.218.13.128): This is our production server, hosting the live application.
2. Tech Stack:

• Ubuntu: Our chosen operating system
• Nginx: Web server for handling HTTP requests
• Docker: For containerizing our application (running on port 8080)

3. Amazon S3 (mycuanbucket): Used for object storage in production, perfect for storing user uploads or static assets.
4. Amazon RDS (mycuandb): Our production database, ensuring data persistence and scalability.

Production Environment (mycuan-security-prod)

1. Amazon EC2 (108.136.220.111): This server hosts our development environment.
2. Tech Stack: Identical to production (Ubuntu, Nginx, Docker), ensuring consistency across environments.
3. Amazon S3 (testingmycuans3): A separate bucket for development, allowing us to test S3-related features safely.
4. Amazon RDS (dbmycuan-dev): A dedicated database for development, preventing any accidental interactions with production data.

The Deployment Flow

1. Developers work on features in the DEVELOP branch.
2. Code is automatically deployed to the development environment for testing.
3. Once approved, code is merged into the MASTER branch.
4. The CI/CD pipeline then deploys the code to the production environment.

Development Deployment Workflow

name: Deploy Dev
on:
  pull_request:
    types:
      - closed
    branches:
      - develop
    paths-ignore:
      - '**.md'
  push:
    branches:
      - develop
    paths-ignore:
      - '**.md'
jobs:
  build:
    if: github.event.pull_request.merged == true
    name: Build
    runs-on: ubuntu-latest
    steps:
      - name: pull-test-deploy
        uses: appleboy/ssh-action@master
        with:
          proxy_timeout: 60m
          host: ${{secrets.HOST_DEV }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.KEY }}
          port: ${{ secrets.PORT }}
          script: |
            cd app
            git pull origin develop
            docker-compose down && docker-compose up --build -d

This workflow is triggered when:

• A pull request to the develop branch is closed and merged
• A push is made directly to the develop branch The workflow ignores changes to Markdown files (.md).

Production Deployment Workflow

name: Deploy Prod
on: 
  pull_request:
    types:
      - closed
    branches:
      - master
    paths-ignore:
      - '**.md'
  push:
    branches:
      - master
    paths-ignore:
      - '**.md'
jobs:
  build:
    if: github.event.pull_request.merged == true
    name: Build
    runs-on: ubuntu-latest
    steps:
      - name: pull-test-deploy
        uses: appleboy/ssh-action@master
        with:
          proxy_timeout: 60m
          host: ${{secrets.HOST_PROD }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.KEY }}
          port: ${{ secrets.PORT }}
          script: |
            cd app
            git pull origin master
            docker-compose down && docker-compose up --build -d

This workflow is similar to the development workflow but is triggered for the master branch instead.

How These Workflows Work

1. Trigger: Both workflows are triggered on pull request merges or direct pushes to their respective branches (develop for development, master for production).
2. Environment: The workflows run on the latest Ubuntu environment provided by GitHub Actions.
3. SSH Action: We use the appleboy/ssh-action to connect to our servers securely.
4. Deployment Script: Once connected, the workflow:

• Navigates to the app directory
• Pulls the latest code from the appropriate branch
• Rebuilds and restarts the Docker containers using Docker Compose

5. Security: Sensitive information like hostnames, usernames, and SSH keys are stored as GitHub secrets, ensuring they're not exposed in the workflow file.

Dockerfile

FROM golang:1.19
 
RUN mkdir /app
 
WORKDIR /app
 
COPY go.mod /app
COPY go.sum /app
RUN go mod download
 
ADD . /app
 
RUN go build -o main .
 
CMD ["/app/main"]

This Dockerfile sets up our Go application:

• It starts with the official Go 1.19 image
• Creates and sets the working directory to /app
• Copies the Go module files and downloads dependencies
• Adds the entire application code to the container
• Builds the Go application
• Sets the command to run our compiled application

DockerCompose

services :
  app:
    build: .
    environment:
      HTTP_PORT: 8080
    ports:
      - 8080:8080

Our Docker Compose file:

• Defines a service named 'app'
• Builds the image using the Dockerfile in the current directory
• Sets the HTTP_PORT environment variable to 8080
• Maps the container's port 8080 to the host's port 8080
• This configuration ensures that our Go application is consistently built and run across different environments, making it easier to manage and deploy.

Why This Schema Works

1. Environment Isolation: Separate development and production setups prevent cross-contamination of data and allow for thorough testing.
2. Consistency: Using Docker ensures that our application behaves the same way in both development and production.
3. Scalability: AWS services can easily scale as our application grows.
4. Security: By using separate S3 buckets and RDS instances, we maintain strict data segregation between environments.
5. Flexibility: Developers can experiment freely in the development environment without risking the stability of the production system.
6. Automated Deployment: The clear path from GitHub to AWS environments supports automated deployments, reducing human error and speeding up the release process.

Addition : Picture the success of flow Deployment In EC2 & Github Action

Conclusion

In conclusion, the MyCuan (PPOB) deployment process integrates a robust CI/CD pipeline with GitHub Actions and AWS infrastructure, effectively balancing development agility with production stability. Through environment isolation, automated workflows, and Dockerized consistency, our schema enhances security, scalability, and workflow efficiency. This setup empowers developers to focus on innovation while maintaining a seamless, secure, and reliable deployment process that ensures a high-quality service for end-users.