Deploy Aplikasi Container ke AWS ECS Fargate: Menjalankan Service tanpa Mengelola Server

Memahami Kapan Fargate Lebih Tepat daripada EC2 atau Lambda

AWS ECS Fargate adalah mode launch pada Amazon ECS yang menjalankan container tanpa perlu memprovisioning atau mengelola instance EC2. AWS yang menangani patch OS, penambahan host, dan kapasitas. We cukup fokus pada container dan konfigurasi service.

AWS menyediakan tiga jalur utama untuk menjalankan workload. EC2 launch type memberi kendali penuh atas instance, tetapi We harus mengurus patch OS, pengaturan kapasitas, dan draining saat host diperbarui. Fargate bersifat serverless, dan biaya dihitung per task berdasarkan vCPU dan memori yang dikonsumsi. Lambda bersifat event-driven dengan batas durasi 15 menit per invocation.

Kriteria pemilihannya dapat dipetakan dengan jelas. Workload long-running seperti web server atau queue worker cocok berjalan di Fargate. Aplikasi yang membutuhkan kontrol runtime penuh, misalnya binary khusus atau library yang bergantung pada fitur sistem tertentu, lebih tepat di EC2. Proses background singkat yang reaktif terhadap event paling efisien di Lambda. Beberapa proses seperti stream consumer atau job panjang tidak muat pada batas durasi Lambda, dan di sinilah Fargate menjadi pilihan yang masuk akal.

Satu konsep yang perlu diingat sejak awal: Fargate tetap merupakan bagian dari ECS. Konsep cluster, task definition, task, dan service tetap berlaku sama persis. Yang hilang hanyalah pekerjaan mengelola host.

Anatomi Cluster, Task Definition, dan Service di ECS

ECS mengatur sumber daya dalam hierarki yang berlapis. Cluster adalah wadah logis untuk kumpulan service dan task. Task definition adalah blueprint yang mendeskripsikan bagaimana satu container berjalan: berapa cpu, berapa memory, image apa yang dipakai, dan port mana yang dibuka. Setiap kali blueprint dijalankan, hasilnya adalah sebuah task. Service menjaga jumlah task sesuai desiredCount dan mengganti task yang tidak sehat secara otomatis.

Alokasi cpu dan memory pada Fargate terjadi di level task, bukan per container. Alasannya, Fargate menjalankan satu task di dalam satu sandbox yang terisolasi, sehingga semua container di dalam task berbagi alokasi yang sama.

Execution role adalah IAM role yang dipakai task saat proses start. Role ini memberi izin untuk menarik image dari ECR dan menulis log ke CloudWatch Logs. Role ini berbeda dari task role, yang dibahas pada bagian biaya dan keamanan.

Fargate memakai network mode awsvpc secara default. Setiap task mendapat network interface sendiri, sehingga Security Group berlaku per task. Mode host dan bridge tidak diterima oleh Fargate karena keduanya membutuhkan berbagi network stack dengan host, dan akses ke host tersebut memang tidak tersedia.

Gambar: Deretan server rack di data center modern tempat workload container berjalan — Sumber: Unsplash/imgix

Berikut task definition untuk satu container web dengan port 80:

{
  "family": "fargate-web-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "web-app",
      "image": "123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/fargate-web-app:1.0.0",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 80,
          "protocol": "tcp"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/fargate-web-app",
          "awslogs-region": "ap-southeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

File di atas siap didaftarkan dengan aws ecs register-task-definition --cli-input-json file://task-definition.json. Output yang We harapkan berupa ARN task definition untuk revisi pertamanya.

Membangun Image dan Mendorongnya ke Amazon ECR

Ukuran image langsung memengaruhi waktu start task. Semakin besar image, semakin lama Fargate menariknya dari ECR sebelum container berjalan. Base image minimal seperti node:20-alpine menurunkan ukuran dari ratusan MB ke puluhan MB. Urutan instruksi di dalam Dockerfile juga menentukan kecepatan build. Perintah COPY package*.json diletakkan sebelum COPY . . agar proses install dependency tidak diulang setiap kali kode aplikasi berubah. Pola ini disebut _layer caching_.

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --omit=dev

COPY . .

ENV NODE_ENV=production
EXPOSE 80
CMD ["node", "server.js"]

Setelah image jadi, alur kerjanya berurutan: authenticate ke ECR, build, lalu tag dan push. Perintah berikut menjalankan seluruh alur tersebut dari nol:

aws ecr create-repository --repository-name fargate-web-app --region ap-southeast-1

aws ecr get-login-password --region ap-southeast-1 \
  | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-southeast-1.amazonaws.com

docker build -t fargate-web-app:1.0.0 .

docker tag fargate-web-app:1.0.0 123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/fargate-web-app:1.0.0

docker push 123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/fargate-web-app:1.0.0

Penamaan tag menentukan ketertelusuran. Tag :latest praktis tetapi ambigu saat kita perlu rollback. Tag versi seperti :1.0.0 atau hash commit membuat setiap deployment dapat ditelusuri ke kode yang menghasilkannya. Output yang diharapkan dari push berupa baris digest: sha256:..., dan image langsung muncul di console ECR.

Gambar: Tumpukan container kargo di pelabuhan, analogi image container berversi yang dikirim ke registry — Sumber: Wikimedia Commons/Igor Ovsyannykov.jpg)

Menjalankan Service dengan Load Balancer dan Auto Scaling

Service mengikat task definition ke traffic nyata. Saat membuat service dengan --launch-type FARGATE, ECS menjalankan task pada kapasitas Fargate dan menjaga desiredCount tetap terpenuhi. Application Load Balancer duduk di depan service. Traffic masuk melalui listener, diteruskan ke target group, dan target group meneruskan request ke task yang sehat.

Health check pada target group menentukan momen sebuah task dianggap siap. Jika path /health belum merespons dengan status 200, task tidak menerima traffic sama sekali. Health check grace period memberi waktu aplikasi untuk start sebelum pemeriksaan dimulai.

Auto scaling menjaga performa saat beban berubah. Konsepnya sederhana: seperti menambah kasir saat antrian memanjang. We mendaftarkan service sebagai scalable target, lalu menetapkan target rata-rata CPU sebesar 60 persen. Saat beban naik, ECS menambah task secara otomatis. Saat sepi, jumlah task dikurangi kembali.

aws ecs create-cluster --cluster-name fargate-cluster

aws ecs create-service \
  --cluster fargate-cluster \
  --service-name fargate-web-service \
  --task-definition fargate-web-app:1 \
  --desired-count 2 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-abc123],securityGroups=[sg-abc123],assignPublicIp=ENABLED}" \
  --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:ap-southeast-1:123456789012:targetgroup/fargate-tg/abc123,containerName=web-app,containerPort=80" \
  --health-check-grace-period-seconds 60

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/fargate-cluster/fargate-web-service \
  --min-capacity 2 \
  --max-capacity 6

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/fargate-cluster/fargate-web-service \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration "TargetValue=60.0,PredefinedMetricSpecification={PredefinedMetricType=ECSServiceAverageCPUUtilization}"

Output yang We harapkan berupa serviceArn pada perintah pembuatan service. Setelah deployment stabil, runningCount akan menunjukkan dua task. Ketika beban CPU melonjak di atas target, angka tersebut naik hingga batas max-capacity.

Memantau Log dan Metrik dengan CloudWatch

Log task mengalir otomatis ke CloudWatch Logs. Driver awslogs yang dikonfigurasi di logConfiguration mengirim setiap baris stdout dan stderr ke log group yang kita tentukan. We tidak perlu masuk ke server mana pun. Cukup tarik stream log dari terminal:

aws logs tail /ecs/fargate-web-app --follow --since 15m

aws ecs describe-services \
  --cluster fargate-cluster \
  --services fargate-web-service \
  --query "services[0].{status:status,running:runningCount,events:events[:5]}"

aws ecs update-cluster-settings \
  --cluster fargate-cluster \
  --settings name=containerInsights,value=enabled

Perintah pertama menampilkan log terbaru secara real time, cocok untuk mencari stack trace saat deployment berjalan. Perintah kedua mengembalikan status service beserta lima event terakhir. Perintah ketiga mengaktifkan Container Insights, yang menambahkan metrik tingkat cluster dan service seperti pemakaian CPU, memori, dan jumlah task aktif di dashboard terpisah.

ECS events menyimpan riwayat setiap deployment. Ketika task berhenti mendadak atau health check gagal, event mencatat alasannya, misalnya Essential container in task exited atau Target did not pass health check. Informasi ini menghemat waktu diagnosis karena penyebabnya sudah tercatat.

Mengendalikan Biaya dan Mengamankan Task Fargate

Biaya Fargate dihitung dari vCPU dan memori per detik selama task berjalan. Alokasi 0.5 vCPU dengan 1 GB memori adalah titik awal yang wajar untuk web service berskala kecil. Naikkan kapasitas hanya setelah metrik Container Insights menunjukkan kebutuhan nyata. Untuk workload yang toleran terhadap interupsi, _Fargate Spot_ menawarkan potongan harga besar dengan catatan bahwa task dapat dihentikan AWS saat kapasitas dibutuhkan kembali.

Keamanan bertumpu pada dua prinsip utama. Pisahkan execution role dari task role. Task role diberi izin minimal hanya untuk layanan yang memang diakses aplikasi, misalnya membaca satu entry dari Secrets Manager. Jangan menyimpan kredensial sebagai environment variable biasa atau di dalam image, karena keduanya mudah bocor lewat console dan riwayat layer.

Menjaga image tetap diperbarui sama pentingnya. Rebuild image secara berkala agar patch keamanan dari base image ikut terpakai. Terakhir, aktifkan deployment circuit breaker dengan opsi rollback saat membuat service. Fitur ini menghentikan deployment yang gagal lolos health check dan mengembalikan revisi sebelumnya secara otomatis, sehingga satu rilis buruk tidak berdampak lama ke produksi.

Ingin menguasai container orchestration dan deployment di AWS secara terstruktur? Ikuti bootcamp Cloud Computing dan DevOps di Rumah Coding, dan bangun portofolio deployment Fargate pertama Anda dari nol.