Belajar Floci - Layanan Berbasis Container (ECS, RDS, ElastiCache)

#Pendahuluan

Sampai episode 11, semua layanan adalah implementasi in-process di JVM. Tapi bagaimana meniru RDS — database sungguhan dengan engine Postgres/MySQL? Atau ElastiCache yang memang Redis asli?

Jawaban Floci berbeda dari pendekatan mana pun sebelumnya: untuk layanan stateful berbasis infrastruktur, ia tidak meniru API saja — ia menjalankan container Docker sungguhan melalui docker socket, lalu mengelola lifecycle-nya via API AWS. Ini fitur paling unik di kelasnya.

#Mekanisme

#Real Docker Integration via docker.sock

Ingat volume ini dari compose episode 3:

Kunci integrasi

services:
  floci:
    image: floci/floci:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Alurnya ketika kalian create-db-instance:

100%

Konsekuensi desain ini:

Fidelity penuh — yang jalan adalah image postgres resmi; perilaku SQL 100% nyata, bukan tiruan.
Endpoint nyata — instance mendapat host:port yang bisa diakses app kalian langsung.
Lifecycle dikelola AWS-style — status creating → available → deleting, snapshot, reboot: semuanya lewat API RDS.

Warning

Mounting docker.sock memberi floci kontrol penuh atas Docker Engine host — kuat tapi sensitif. Di shared runner pertimbangkan mitigasi (episode 24 membahas keamanannya).

#Layanan

#Tiga Keluarga Utama

Service	Yang Dijalankan	Use Case Uji
ECS	Task definition → container sesuai image & env	Orkestrasi job, service discovery lokal
RDS	Instance database (postgres/mysql) sebagai container	Integrasi ORM/migrasi/schema
ElastiCache	Cluster Redis/Memcached	Session cache, pub/sub, rate limiter

Untuk ECS: register-task-definition + run-task memicu floci membuat container sesuai spec (image, port, environment) — berguna menguji definisi job sebelum deploy ke cluster sungguhan.

#Praktik

Target outline: jalankan Postgres via RDS floci + app connect end-to-end.

export AWS_ENDPOINT_URL=http://localhost:4566
 
aws rds create-db-instance \
  --db-instance-identifier app-db \
  --engine postgres \
  --db-instance-class db.t3.micro \
  --master-username dev --master-user-password devpass123 \
  --allocated-storage 20
 
# tunggu sampai available - endpoint mengarah ke container postgres nyata
aws rds wait db-instance-available --db-instance-identifier app-db
aws rds describe-db-instances --db-instance-identifier app-db \
  --query 'DBInstances[0].Endpoint.[Address,Port]' --output text
docker ps --format '{{.Names}} {{.Image}}' | grep -i postgres # bukti fisiknya

import boto3, psycopg
 
rds = boto3.client("rds", endpoint_url="http://localhost:4566")
ep = rds.describe_db_instances(DBInstanceIdentifier="app-db")["DBInstances"][0]["Endpoint"]
conn = psycopg.connect(host=ep["Address"], port=ep["Port"],
                       user="dev", password="devpass123", dbname="postgres")
conn.execute("CREATE TABLE IF NOT EXISTS notes(id serial primary key, body text)")
conn.execute("INSERT INTO notes(body) VALUES (%s)", ("dibuat via RDS floci",))
print(conn.execute("SELECT count(*) FROM notes").fetchone()[0], "baris")
conn.commit(); conn.close()
print("app -> postgres (via API RDS floci): OK")

Perhatikan pola produksinya utuh: app tidak tahu database-nya berasal dari Docker — ia hanya membaca endpoint dari API RDS. Itu artinya kode konfigurasi yang sama persis dipakai saat pindah ke RDS sungguhan.

Tip

Bersihkan dengan delete-db-instance agar container postgres ikut dimatikan — atau biarkan persisten di compose dev untuk iterasi cepat.

#Penutup

Rangkuman episode ini:

Layanan stateful ditangani beda: real containers via docker.sock, lifecycle dikelola lewat API AWS.
ECS run-task, RDS instance, ElastiCache cluster = fidelity penuh karena engine-nya asli.
Praktik: Postgres provisioned via create-db-instance, app Python connect end-to-end tanpa tahu ada Docker.

Episode 13 naik level orkestrasi: Step Functions & EventBridge — state machine, event bus, pattern matching, scheduled events, dan saga order-processing lengkap. Sampai jumpa!