Tutorial CI/CD dengan GitHub Actions dan AWS OIDC untuk Multi-Environment Deployment

Artikel ini membahas implementasi CI/CD menggunakan GitHub Actions dengan AWS OIDC untuk deployment multi-environment (Local, Staging, Production). Anda akan mempelajari konfigurasi GitHub Actions workflow, setup AWS OIDC authentication, dan strategi deployment otomatis dengan auto-commit yang aman. Cocok untuk developer yang ingin mengotomasi proses deployment Docker container ke AWS dengan zero credential storage.

Dalam pengembangan aplikasi modern, proses deployment manual dari local ke staging, kemudian ke production, tidak hanya memakan waktu tetapi juga rawan human error. Menurut State of DevOps Report 2024, organisasi dengan praktik CI/CD yang mature mengalami 208 kali lebih cepat dalam deployment frequency dan 106 kali lebih cepat dalam lead time dari commit ke production.

Deployment otomatis dengan GitHub Actions dan AWS OIDC (OpenID Connect) menjadi solusi untuk menghilangkan kebutuhan menyimpan AWS credentials di repository. OIDC memungkinkan GitHub Actions mengakses AWS resources secara temporary dan secure melalui trust relationship, mengurangi risiko credential leakage yang menjadi salah satu attack vector paling umum dalam software supply chain.

Artikel ini ditujukan untuk developer pemula hingga menengah yang ingin membangun pipeline CI/CD profesional untuk aplikasi berbasis Docker, PostgreSQL, dan AWS. Anda akan mempelajari setup GitHub Actions workflow, konfigurasi AWS OIDC provider, strategi branching untuk multi-environment, dan implementasi auto-commit untuk version tracking yang dapat langsung diterapkan pada project real-world.

Pembahasan akan mencakup persiapan infrastruktur AWS, konfigurasi GitHub repository secrets, pembuatan workflow file untuk automated testing dan deployment, hingga best practices untuk monitoring dan rollback strategy, disertai dengan command-line yang siap digunakan dan troubleshooting common issues.

Persiapan Infrastruktur dan Prerequisite

Sebelum memulai implementasi CI/CD, ada beberapa komponen yang harus disiapkan terlebih dahulu untuk memastikan workflow berjalan lancar.

Setup AWS Infrastructure

Infrastructure Anda sudah memiliki komponen dasar yang solid dengan Nginx Proxy Manager sebagai reverse proxy, EC2 untuk Docker host, RDS PostgreSQL untuk database, dan S3 untuk storage. Namun, untuk CI/CD pipeline, Anda memerlukan beberapa resource tambahan di AWS.

Pertama, pastikan Anda memiliki IAM user dengan permission yang cukup untuk membuat IAM Role dan OIDC provider. Login ke AWS Console dan navigasi ke IAM service untuk memverifikasi access level Anda.

Resource AWS yang Diperlukan:

IAM OIDC Identity Provider untuk GitHub
IAM Role dengan trust policy untuk GitHub Actions
ECR (Elastic Container Registry) untuk menyimpan Docker images
Systems Manager Parameter Store atau Secrets Manager untuk menyimpan environment variables
CloudWatch Log Group untuk monitoring deployment logs

Verifikasi Environment Lokal

Di environment lokal, pastikan tools berikut sudah terinstall dan berfungsi dengan baik.

bash

# Verifikasi Docker
docker --version
docker-compose --version

# Verifikasi AWS CLI
aws --version
aws sts get-caller-identity

# Verifikasi Git
git --version

Jika AWS CLI belum dikonfigurasi, jalankan setup dengan access key yang memiliki permission untuk membuat IAM resources.

bash

aws configure
# Masukkan: AWS Access Key ID, Secret Access Key, Region (misal: ap-southeast-1), Output format (json)

Struktur Repository Git

Untuk mendukung multi-environment deployment, gunakan branching strategy yang jelas. Struktur yang direkomendasikan menggunakan Git Flow dengan modifikasi untuk tiga environment.

Branch Strategy:

main → Production environment
staging → Staging environment
develop → Development environment (optional, untuk kolaborasi tim)
feature/* → Feature branches (merge ke staging untuk testing)

Create branch staging jika belum ada:

bash

# Dari branch main
git checkout -b staging
git push -u origin staging

Konfigurasi AWS OIDC Provider

OIDC provider memungkinkan GitHub Actions untuk authenticate ke AWS tanpa menyimpan long-term credentials. Ini adalah foundational step yang paling krusial dalam setup CI/CD yang secure.

Membuat OIDC Provider di AWS

Langkah 1: Create Identity Provider

Via AWS Console:

Provider type: OpenID Connect
Provider URL: https://token.actions.githubusercontent.com
Audience: sts.amazonaws.com

Via AWS CLI:

bash

aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1

Thumbprint 6938fd4d98bab03faadb97b34396831e3780aea1 adalah certificate fingerprint untuk GitHub’s OIDC provider yang valid hingga 2031.

Membuat IAM Role untuk GitHub Actions

IAM Role ini akan diassume oleh GitHub Actions workflow untuk mengakses AWS resources.

Langkah 2: Create IAM Role dengan Trust Policy

Buat file github-actions-trust-policy.json:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:YOUR_GITHUB_USERNAME/YOUR_REPO_NAME:*"
        }
      }
    }
  ]
}

Ganti YOUR_AWS_ACCOUNT_ID, YOUR_GITHUB_USERNAME, dan YOUR_REPO_NAME dengan nilai aktual Anda.

Create role menggunakan AWS CLI:

bash

aws iam create-role \
  --role-name GitHubActionsDeployRole \
  --assume-role-policy-document file://github-actions-trust-policy.json

Langkah 3: Attach Policies ke IAM Role

Role memerlukan permissions untuk deploy ke EC2, push ke ECR, dan akses S3. Buat custom policy atau gunakan managed policies.

Buat file github-actions-permissions.json:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:PutImage",
        "ecr:InitiateLayerUpload",
        "ecr:UploadLayerPart",
        "ecr:CompleteLayerUpload"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ssm:SendCommand",
        "ssm:GetCommandInvocation"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::YOUR_BUCKET_NAME/*",
        "arn:aws:s3:::YOUR_BUCKET_NAME"
      ]
    }
  ]
}

Attach policy ke role:

bash

aws iam put-role-policy \
  --role-name GitHubActionsDeployRole \
  --policy-name GitHubActionsDeployPolicy \
  --policy-document file://github-actions-permissions.json

Membuat ECR Repository

ECR akan menyimpan Docker images yang dihasilkan dari build process.

bash

# Create ECR repository untuk staging
aws ecr create-repository \
  --repository-name your-app-staging \
  --region ap-southeast-1

# Create ECR repository untuk production
aws ecr create-repository \
  --repository-name your-app-production \
  --region ap-southeast-1
```

Catat repository URI yang muncul di output, Anda akan membutuhkannya untuk workflow configuration.

---

## Konfigurasi GitHub Repository

GitHub repository memerlukan beberapa secrets dan environment setup untuk workflow berjalan dengan aman.

### Setup GitHub Secrets

Navigate ke repository Anda di GitHub → Settings → Secrets and variables → Actions → New repository secret.

**Required Secrets:**

1. **AWS_ROLE_ARN**: ARN dari IAM Role yang dibuat sebelumnya
```
   arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/GitHubActionsDeployRole
```

2. **AWS_REGION**: Region AWS Anda (misal: `ap-southeast-1`)

3. **ECR_REGISTRY**: ECR registry URL
```
   YOUR_AWS_ACCOUNT_ID.dkr.ecr.ap-southeast-1.amazonaws.com
```

4. **STAGING_EC2_INSTANCE_ID**: Instance ID EC2 staging (misal: `i-0abc123def456789`)

5. **PRODUCTION_EC2_INSTANCE_ID**: Instance ID EC2 production

6. **DATABASE_URL_STAGING**: Connection string PostgreSQL staging
```
   postgresql://username:password@rds-endpoint:5432/dbname

DATABASE_URL_PRODUCTION: Connection string PostgreSQL production

Untuk secrets yang environment-specific, gunakan GitHub Environments feature sebagai alternative yang lebih terorganisir.

Setup GitHub Environments

GitHub Environments memungkinkan Anda mengelola secrets per environment dan menambahkan approval gates.

Navigate ke Settings → Environments → New environment.

Create Two Environments:

staging
- Environment secrets: DATABASE_URL, EC2_INSTANCE_ID
- Environment protection rules: None (auto-deploy on push to staging branch)
production
- Environment secrets: DATABASE_URL, EC2_INSTANCE_ID
- Environment protection rules: Required reviewers (pilih reviewer yang harus approve sebelum deploy)
- Wait timer: 5 minutes (optional, untuk memberikan window untuk cancel deployment)

Pendekatan dengan Environments lebih clean dan memudahkan management secrets per environment dibandingkan menggunakan repository secrets dengan suffix.

Membuat GitHub Actions Workflow

Workflow file adalah jantung dari CI/CD pipeline yang mendefinisikan langkah-langkah dari code commit hingga deployment.

Struktur Workflow untuk Multi-Environment

Buat directory .github/workflows/ di root repository Anda jika belum ada.

bash

mkdir -p .github/workflows

Langkah 1: Workflow untuk Staging Environment

Buat file .github/workflows/deploy-staging.yml:

yaml

name: Deploy to Staging

on:
  push:
    branches:
      - staging
  workflow_dispatch:

env:
  AWS_REGION: ap-southeast-1
  ECR_REPOSITORY: your-app-staging

permissions:
  id-token: write
  contents: read

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    environment: staging
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}
          
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2
        
      - name: Build, tag, and push image to ECR
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker tag $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG $ECR_REGISTRY/$ECR_REPOSITORY:latest
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:latest
          
      - name: Deploy to EC2
        env:
          IMAGE_TAG: ${{ github.sha }}
        run: |
          aws ssm send-command \
            --instance-ids ${{ secrets.STAGING_EC2_INSTANCE_ID }} \
            --document-name "AWS-RunShellScript" \
            --parameters commands="[
              'aws ecr get-login-password --region ${{ env.AWS_REGION }} | docker login --username AWS --password-stdin ${{ steps.login-ecr.outputs.registry }}',
              'docker pull ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:$IMAGE_TAG',
              'docker stop your-app-container || true',
              'docker rm your-app-container || true',
              'docker run -d --name your-app-container -p 3000:3000 -e DATABASE_URL=${{ secrets.DATABASE_URL }} ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:$IMAGE_TAG'
            ]" \
            --output text
            
      - name: Auto-commit deployment info
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          echo "Deployed to staging at $(date)" >> deployments.log
          echo "Image: ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ github.sha }}" >> deployments.log
          git add deployments.log
          git commit -m "chore: update staging deployment log [skip ci]" || echo "No changes to commit"
          git push origin staging

Langkah 2: Workflow untuk Production Environment

Buat file .github/workflows/deploy-production.yml:

yaml

name: Deploy to Production

on:
  push:
    branches:
      - main
  workflow_dispatch:

env:
  AWS_REGION: ap-southeast-1
  ECR_REPOSITORY: your-app-production

permissions:
  id-token: write
  contents: read

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    environment: production
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}
          
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2
        
      - name: Build, tag, and push image to ECR
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker tag $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG $ECR_REGISTRY/$ECR_REPOSITORY:latest
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:latest
          
      - name: Deploy to EC2
        env:
          IMAGE_TAG: ${{ github.sha }}
        run: |
          aws ssm send-command \
            --instance-ids ${{ secrets.PRODUCTION_EC2_INSTANCE_ID }} \
            --document-name "AWS-RunShellScript" \
            --parameters commands="[
              'aws ecr get-login-password --region ${{ env.AWS_REGION }} | docker login --username AWS --password-stdin ${{ steps.login-ecr.outputs.registry }}',
              'docker pull ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:$IMAGE_TAG',
              'docker stop your-app-container || true',
              'docker rm your-app-container || true',
              'docker run -d --name your-app-container -p 3000:3000 -e DATABASE_URL=${{ secrets.DATABASE_URL }} ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:$IMAGE_TAG'
            ]" \
            --output text
            
      - name: Auto-commit deployment info
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          echo "Deployed to production at $(date)" >> deployments.log
          echo "Image: ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ github.sha }}" >> deployments.log
          git add deployments.log
          git commit -m "chore: update production deployment log [skip ci]" || echo "No changes to commit"
          git push origin main

Penjelasan Komponen Workflow

Triggers (on): Workflow dijalankan saat ada push ke branch tertentu atau manual via workflow_dispatch.

Permissions: id-token: write diperlukan untuk OIDC authentication dengan AWS.

Environment: Menggunakan GitHub Environments untuk isolasi secrets dan approval gates.

Checkout: Action actions/checkout@v4 mengambil code dari repository.

AWS Authentication: Action aws-actions/configure-aws-credentials@v4 melakukan OIDC authentication ke AWS menggunakan IAM Role.

ECR Login: Action amazon-ecr-login@v2 mendapatkan temporary credentials untuk push Docker images.

Build & Push: Docker image di-build dengan tag berdasarkan commit SHA dan di-push ke ECR dengan dua tags: commit SHA untuk traceability dan latest untuk convenience.

Deploy: SSM Send Command menjalankan deployment script di EC2 instance, menghindari kebutuhan SSH keys di GitHub.

Auto-commit: Git commands menambahkan deployment log dan commit kembali ke repository dengan [skip ci] tag untuk menghindari infinite loop.

Optimasi Workflow dengan Caching

Untuk mempercepat build time, tambahkan Docker layer caching.

Tambahkan step setelah checkout:

yaml

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
        
      - name: Cache Docker layers
        uses: actions/cache@v3
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-buildx-

Modifikasi build step untuk menggunakan cache:

yaml

      - name: Build, tag, and push image to ECR
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker buildx build \
            --cache-from type=local,src=/tmp/.buildx-cache \
            --cache-to type=local,dest=/tmp/.buildx-cache-new,mode=max \
            -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG \
            -t $ECR_REGISTRY/$ECR_REPOSITORY:latest \
            --push .

Persiapan EC2 Instance untuk Deployment

EC2 instance memerlukan beberapa konfigurasi agar dapat menerima deployment commands dari GitHub Actions via SSM.

Install SSM Agent

SSM Agent biasanya sudah terinstall di Amazon Linux 2 AMI. Untuk Ubuntu, install secara manual.

Untuk Ubuntu 20.04/22.04:

bash

# Connect ke EC2 via SSH
ssh -i your-key.pem ubuntu@ec2-instance-ip

# Download dan install SSM Agent
wget https://s3.ap-southeast-1.amazonaws.com/amazon-ssm-ap-southeast-1/latest/debian_amd64/amazon-ssm-agent.deb
sudo dpkg -i amazon-ssm-agent.deb

# Start dan enable SSM Agent
sudo systemctl start amazon-ssm-agent
sudo systemctl enable amazon-ssm-agent

# Verify status
sudo systemctl status amazon-ssm-agent

Install Docker di EC2

Jika Docker belum terinstall di EC2 instance:

bash

# Update package index
sudo apt update

# Install prerequisites
sudo apt install -y apt-transport-https ca-certificates curl software-properties-common

# Add Docker GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Add Docker repository
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install Docker
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io

# Add current user to docker group
sudo usermod -aG docker $USER

# Start Docker
sudo systemctl start docker
sudo systemctl enable docker

Install AWS CLI di EC2

AWS CLI diperlukan untuk pull images dari ECR.

bash

# Download AWS CLI v2
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

# Unzip
sudo apt install -y unzip
unzip awscliv2.zip

# Install
sudo ./aws/install

# Verify
aws --version

Konfigurasi IAM Role untuk EC2

EC2 instance memerlukan IAM Role dengan permissions untuk pull dari ECR dan receive SSM commands.

Langkah 1: Create IAM Role untuk EC2

Buat file ec2-trust-policy.json:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Create role:

bash

aws iam create-role \
  --role-name EC2DeploymentRole \
  --assume-role-policy-document file://ec2-trust-policy.json

Langkah 2: Attach Managed Policies

bash

# Untuk SSM access
aws iam attach-role-policy \
  --role-name EC2DeploymentRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

# Untuk ECR pull
aws iam attach-role-policy \
  --role-name EC2DeploymentRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly

Langkah 3: Create Instance Profile dan Attach ke EC2

bash

# Create instance profile
aws iam create-instance-profile \
  --instance-profile-name EC2DeploymentProfile

# Add role to instance profile
aws iam add-role-to-instance-profile \
  --instance-profile-name EC2DeploymentProfile \
  --role-name EC2DeploymentRole

# Attach instance profile ke EC2
aws ec2 associate-iam-instance-profile \
  --instance-id YOUR_STAGING_EC2_INSTANCE_ID \
  --iam-instance-profile Name=EC2DeploymentProfile

# Repeat untuk production instance
aws ec2 associate-iam-instance-profile \
  --instance-id YOUR_PRODUCTION_EC2_INSTANCE_ID \
  --iam-instance-profile Name=EC2DeploymentProfile

Setelah attach instance profile, restart SSM Agent atau reboot instance untuk changes take effect.

Testing dan Deployment Workflow

Setelah semua konfigurasi selesai, saatnya testing workflow secara end-to-end.

Testing Deployment ke Staging

Langkah 1: Buat Perubahan di Branch Staging

bash

# Pindah ke branch staging
git checkout staging

# Buat perubahan sederhana (misal edit README)
echo "Testing CI/CD deployment" >> README.md

# Commit dan push
git add README.md
git commit -m "test: trigger staging deployment"
git push origin staging

Langkah 2: Monitor Workflow Execution

Navigate ke GitHub repository → Actions tab. Anda akan melihat workflow “Deploy to Staging” sedang berjalan.

Klik workflow run untuk melihat detail setiap step. Jika ada error, log akan menampilkan detail message yang membantu troubleshooting.

Langkah 3: Verifikasi Deployment di EC2

SSH ke EC2 staging instance dan verify container berjalan:

bash

# Check running containers
docker ps

# Check container logs
docker logs your-app-container

# Test application endpoint
curl http://localhost:3000/health

Jika berhasil, Anda akan melihat auto-commit dari github-actions bot yang menambahkan entry ke deployments.log.

Promoting ke Production

Setelah testing di staging selesai dan tidak ada issues, promote changes ke production.

Langkah 1: Merge Staging ke Main

bash

# Pindah ke branch main
git checkout main

# Merge dari staging
git merge staging

# Push ke main
git push origin main

Langkah 2: Approve Production Deployment

Jika Anda setup required reviewers di production environment, navigate ke Actions tab. Workflow akan pause dan menunggu approval.

Reviewer yang ditunjuk akan menerima notification dan dapat review changes sebelum approve deployment.

Langkah 3: Monitor dan Verify Production

Setelah approved, workflow akan continue dan deploy ke production EC2. Monitor logs dan verify deployment sama seperti staging.

Rollback Strategy

Jika deployment menyebabkan issues di production, rollback dapat dilakukan dengan beberapa cara.

Option 1: Rollback via Git Revert

bash

# Revert commit yang menyebabkan issue
git revert HEAD

# Push revert commit
git push origin main

Workflow akan otomatis deploy reverted version.

Option 2: Manual Rollback di EC2

bash

# SSH ke production EC2
ssh -i your-key.pem ubuntu@production-ec2-ip

# Stop current container
docker stop your-app-container
docker rm your-app-container

# Pull previous working image (ganti IMAGE_TAG dengan commit SHA sebelumnya)
docker pull YOUR_ECR_REGISTRY/your-app-production:PREVIOUS_WORKING_TAG

# Run previous version
docker run -d --name your-app-container -p 3000:3000 \
  -e DATABASE_URL=$DATABASE_URL \
  YOUR_ECR_REGISTRY/your-app-production:PREVIOUS_WORKING_TAG

Option 3: Rerun Previous Successful Workflow

Navigate ke Actions → Select previous successful workflow run → Re-run all jobs. Ini akan deploy version yang sama seperti previous run.

Analisis Mendalam dan Rekomendasi Strategis

Evaluasi Pendekatan OIDC vs Long-term Credentials

Implementasi OIDC untuk AWS authentication merepresentasikan shift paradigm dalam security posture untuk CI/CD pipelines. Traditional approach menggunakan IAM user access keys yang disimpan sebagai GitHub secrets memiliki beberapa kelemahan fundamental: credentials bersifat long-lived, tidak ada automatic rotation, dan jika leaked, attacker memiliki persistent access hingga credentials di-revoke.

OIDC federation mengeliminasi risks tersebut dengan memberikan temporary credentials yang hanya valid selama workflow execution, typically 1 hour. Trust relationship didefinisikan secara eksplisit di IAM Role trust policy, membatasi access hanya dari repository tertentu dan bahkan branch tertentu jika dikonfigurasi dengan condition yang lebih strict.

Namun, OIDC approach memerlukan learning curve yang lebih tinggi untuk developer yang terbiasa dengan traditional credential-based authentication. Documentation dan error messages dari AWS tidak selalu intuitif, terutama saat troubleshooting trust policy misconfigurations.

Tren Industri dan Masa Depan

Cloud-native deployment patterns semakin bergerak menuju ephemeral infrastructure dan immutable deployments. Container orchestration platforms seperti ECS Fargate atau EKS akan menjadi natural evolution dari manual EC2 deployment dengan Docker, memberikan benefits seperti automatic scaling, health checks, dan rolling deployments out of the box.

GitOps principles, dimana Git repository menjadi single source of truth untuk desired state infrastructure, semakin mature dengan tools seperti ArgoCD dan Flux. Ini membawa deployment automation ke level selanjutnya dimana bukan hanya application code, tetapi juga infrastructure configuration di-version control dan automatically reconciled.

Progressive delivery techniques seperti canary deployments dan blue-green deployments akan menjadi standard practice, bukan advanced features. GitHub Actions sudah support complex deployment strategies ini melalui custom actions dan workflow orchestration.

Pertimbangan untuk Developer Pemula:

Jangka Pendek (0-6 bulan): Focus pada stabilizing current Docker-based deployment, implement comprehensive monitoring dengan CloudWatch atau Datadog, dan establish clear runbooks untuk common deployment issues
Jangka Menengah (6-18 bulan): Evaluate migration path ke container orchestration (ECS/EKS), implement automated testing dalam CI pipeline (unit tests, integration tests), dan adopt infrastructure as code dengan Terraform atau CloudFormation
Jangka Panjang (18+ bulan): Explore advanced deployment strategies (canary, blue-green), implement observability stack (logs, metrics, traces), dan consider multi-region deployment untuk high availability

Rekomendasi Berdasarkan Skala

Untuk Skala Kecil (Personal Projects/MVP):

Current approach dengan GitHub Actions + EC2 sudah cukup cost-effective dan maintainable
Prioritize simplicity over sophistication; avoid over-engineering dengan tools yang terlalu complex
Use managed services seperti RDS daripada self-hosted database untuk reduce operational burden
Consider serverless options (Lambda + API Gateway) jika traffic patterns tidak predictable

Untuk Skala Menengah (Growing Startups):

Migrate ke ECS Fargate untuk better resource utilization dan automatic scaling
Implement proper secrets management dengan AWS Secrets Manager dan automatic rotation
Setup multi-environment infrastructure dengan Terraform modules untuk consistency
Invest dalam observability: structured logging, APM tools, dan custom metrics dashboards

Untuk Skala Enterprise:

Adopt microservices architecture dengan service mesh (Istio/App Mesh) untuk advanced traffic management
Implement multi-region active-active deployment untuk disaster recovery dan low latency globally
Use advanced deployment strategies dengan gradual rollouts dan automated rollback based on SLO violations
Establish dedicated platform engineering team untuk maintain internal developer platforms

Kesalahan Umum yang Harus Dihindari

Hardcoding Secrets dalam Workflow Files: Seringkali developer baru accidentally commit API keys atau database credentials dalam workflow YAML karena tidak familiar dengan GitHub Secrets. Selalu gunakan ${{ secrets.SECRET_NAME }} syntax dan never commit sensitive data, bahkan dalam private repositories karena git history permanent.
Tidak Menggunakan [skip ci] Tag: Auto-commit deployment logs tanpa skip CI tag dapat menyebabkan infinite loops dimana commit trigger workflow, workflow commit log, commit trigger workflow lagi. Selalu include [skip ci]atau [ci skip] dalam commit message untuk commits yang dibuat oleh automation.
Mengabaikan Database Migration Strategy: Deployment aplikasi baru sering kali memerlukan database schema changes. Jika migration tidak di-handle dengan proper, bisa menyebabkan application crashes atau data corruption. Implement migration tools seperti Flyway atau Liquibase yang run sebagai separate step sebelum application deployment, dan selalu test migrations di staging environment terlebih dahulu.

Kesimpulan

Ringkasan Poin-Poin Utama:

OIDC Authentication dengan AWS: Mengeliminasi kebutuhan menyimpan long-term credentials dan meningkatkan security posture secara signifikan melalui temporary, scoped access tokens.
Multi-Environment Workflow dengan Branch-based Deployment: Menggunakan Git branches sebagai trigger untuk different environments memberikan clear separation of concerns dan memudahkan tracking deployment history.
Infrastructure Automation dengan GitHub Actions dan SSM: Kombinasi GitHub Actions untuk orchestration dan AWS Systems Manager untuk remote execution menghilangkan dependency pada SSH keys dan menyederhanakan access management.
Auto-commit untuk Deployment Tracking: Automated logging deployment information ke Git repository memberikan audit trail yang valuable dan memudahkan correlation antara code changes dan deployment events.
Comprehensive EC2 Setup dengan IAM Roles: Proper IAM configuration untuk EC2 instances memastikan principle of least privilege dan memudahkan credential management tanpa storing secrets di instance.

Manfaat Keseluruhan:

Implementasi CI/CD pipeline dengan GitHub Actions dan AWS OIDC tidak hanya mengotomasi deployment process dan mengurangi human error, tetapi juga establish foundation untuk scaling development practices seiring pertumbuhan team dan product complexity. Security improvements dari OIDC adoption, combined dengan traceability dari auto-commit logs dan flexibility dari multi-environment workflow, memberikan confidence untuk iterate faster pada aplikasi sambil maintaining stability di production environment.

Referensi dan Sumber

GitHub Actions Documentation – https://docs.github.com/en/actions
AWS IAM OIDC Identity Providers – https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html
AWS Systems Manager Run Command – https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html
Docker Best Practices – https://docs.docker.com/develop/dev-best-practices/
Amazon ECR User Guide – https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html

Share the Post:

Membangun Frontend Vendor-Agnostic yang Tahan Perubahan

Artikel ini membahas pendekatan arsitektur frontend yang berfokus pada kontrak internal agar aplikasi web tetap stabil, mudah di-upgrade, dan tidak

CI/CD: Continuous Integration dan Continuous Deployment untuk Developer Modern

membahas konsep CI/CD (Continuous Integration/Continuous Deployment) dengan fokus pada implementasi praktis dan real-world workflow. Anda akan mempelajari prinsip-prinsip dasar CI/CD,

Tutorial CI/CD dengan GitHub Actions dan AWS OIDC untuk Multi-Environment Deployment

Persiapan Infrastruktur dan Prerequisite

Setup AWS Infrastructure

Verifikasi Environment Lokal

Struktur Repository Git

Konfigurasi AWS OIDC Provider

Membuat OIDC Provider di AWS

Membuat IAM Role untuk GitHub Actions

Membuat ECR Repository

Setup GitHub Environments

Membuat GitHub Actions Workflow

Struktur Workflow untuk Multi-Environment

Penjelasan Komponen Workflow

Optimasi Workflow dengan Caching

Persiapan EC2 Instance untuk Deployment

Install SSM Agent

Install Docker di EC2

Install AWS CLI di EC2

Konfigurasi IAM Role untuk EC2

Testing dan Deployment Workflow

Testing Deployment ke Staging

Promoting ke Production

Rollback Strategy

Analisis Mendalam dan Rekomendasi Strategis

Evaluasi Pendekatan OIDC vs Long-term Credentials

Tren Industri dan Masa Depan

Rekomendasi Berdasarkan Skala

Kesalahan Umum yang Harus Dihindari

Kesimpulan

Referensi dan Sumber

Related Posts

Membangun Frontend Vendor-Agnostic yang Tahan Perubahan

CI/CD: Continuous Integration dan Continuous Deployment untuk Developer Modern