1. Identifikasi Scaling: Up atau Out?

Banyak orang bingung kapan harus menambah kekuatan server yang ada (Scaling Up) dan kapan harus menambah jumlah server (Scaling Out). Inilah cara identifikasinya:

• Scaling Up (Vertical): Menambah CPU atau RAM pada server yang sudah ada. Lakukan ini jika satu kontainer kita membutuhkan resource besar untuk satu proses berat (misal: pengolahan video atau kalkulasi rumit).

• Scaling Out (Horizontal): Menambah jumlah replika kontainer atau menambah server Worker baru. Lakukan ini untuk menangani jumlah user yang banyak secara bersamaan (concurrent).

• Kapan Tambah Replika? Jika penggunaan CPU server masih di bawah 60%, tapi aplikasi mulai terasa lambat merespon request, tambahkan replika: docker service scale godocapi_backend=5.

• Kapan Tambah Worker? Jika total penggunaan CPU/RAM di seluruh server sudah menyentuh 70-80%, itulah saatnya Anda membeli server baru dan melakukan docker swarm join.

2. Zero Downtime Deployment: Update Tanpa Drama

Sebagai profesional, kita tidak boleh mematikan layanan hanya untuk update versi aplikasi. Kita akan menggunakan strategi Rolling Update dengan konfigurasi start-first.

Artinya: Swarm akan menyalakan kontainer versi baru terlebih dahulu sampai sehat, baru mematikan kontainer versi lama. User tidak akan pernah merasakan koneksi terputus.

Tambahkan ini di file docker-stack.yml :

services:
  backend:
    image: cehamot/godocapi:latest
    deploy:
      update_config:
        order: start-first
        parallelism: 1
        delay: 10s
      rollback_config:
        parallelism: 1
        order: stop-first

Pro Tip: Jika update versi baru ternyata buggy, Anda cukup jalankan docker service rollback godocapi_backend untuk kembali ke versi stabil sebelumnya secara otomatis.

3. Placement Constraint: Menjaga Docker Manager Tetap Dingin

Sesuai arsitektur yang Anda bangun, Manager (Server A) harus tetap fokus mengelola kluster dan tidak boleh terbebani oleh aplikasi berat. Kita akan "mengusir" backend agar hanya berjalan di Worker (Server B atau C).

Tambahkan ini di file docker-stack.yml

services:
  backend:
    deploy:
      placement:
        constraints:
          - node.role == worker

pastikan kembali backend berjalan di node worker

docker service ps godocapi_backend

terlihat untuk backend sudah pindah ke node docker worker dengan ini, Manager Anda akan selalu sehat untuk mengawasi jalannya kluster meskipun trafik sedang tinggi.

4. Integrasi HAProxy: The Front Gate

Di depan kluster Swarm, kita butuh HAProxy sebagai Reverse Proxy sekaligus penyeimbang beban (Load Balancer). HAProxy akan menerima trafik dari internet dan membaginya ke IP Server A, B, atau C.

Gunakan referensi artikel berikut ini untuk membuat server HAProxy.

Contoh Konfigurasi haproxy.cfg :

frontend http_front
   bind *:80
   default_backend swarm_cluster

backend swarm_cluster
   balance roundrobin
   option httpchk GET /health
   server manager_a 192.168.20.101:3000 check
   server worker_b 192.168.20.102:3000 check

Berkat teknologi Ingress Mesh, HAProxy tidak perlu pusing mencari di mana kontainer berada. Cukup tembak ke IP server mana pun di dalam kluster, Swarm yang akan mengurus sisanya.

5. Kesimpulan

• Ketika pengguna meledak, jangan panik identifikasi dulu apakah masalahnya butuh scaling up (vertical) atau scaling out (horizontal).

• Gunakan scaling up untuk kebutuhan proses tunggal yang berat (CPU/RAM per kontainer), dan scaling out untuk menangani banyak koneksi sekaligus (menambah replika atau worker).

• Praktik sederhana: jika CPU per server masih <~60% tapi respon melambat, tambah replika (mis. docker service scale godocapi_backend=5); jika total penggunaan cluster sudah ~7080%, tambahkan node worker dan docker swarm join.

• Pastikan monitoring dan alerting (CPU, RAM, latency, error rate) aktif supaya keputusan scaling didasarkan data, bukan tebak-tebakan.

• Siapkan proses deployment tanpa downtime (rolling updates, health checks, cukup replika saat update) agar skala naik/turun dan pembaruan versi tidak mengganggu user.

• Automasi (script/CI/CD, autoscaler, infrastruktur as code) dan perencanaan kapasitas membantu menghindari krisis saat lonjakan traffic berikutnya.

Intinya: ukur dulu, pilih strategi yang sesuai (up vs out), otomatisasi tindakan yang rutin, dan jaga pengalaman pengguna tetap mulus selama scaling atau update.

1. Persiapan Environment

Sebelum kita masuk ke konfigurasi masing-masing server, pastikan kamu sudah menyiapkan "bahan-bahan" berikut:

1. Virtualization Tool: Saya menggunakan Oracle VM VirtualBox.

2. Sistem Operasi: Image Ubuntu 24.04 LTS (Noble Numbat) untuk semua node server.

3. Spesifikasi Server:

   Docker Manager 4 GB RAM dan 15 GB Hardisk.

   Docker Worker 2 GB RAM dan 15 GB Hardisk.

4. Networking: Setiap VM dikonfigurasi dengan 2 Network Adapter:

   • Adapter 1 (NAT): Untuk akses internet (update package, install HAProxy, dll).

   • Adapter 2 (Host-Only): Digunakan untuk jaringan LAN antar VM (komunikasi internal agar IP 192.168.20.x bisa saling ping).

5. Source Code: Kita akan menggunakan API sederhana berbasis Go sebagai backend dan Frontend berbasis Nextjs. Kamu bisa melakukan clone dari repository ini:

   Backend https://github.com/mdrdani/GoDocAPI

   frontend https://github.com/mdrdani/frontend-GoDocAPI.

6. Docker: Dengan Docker, kita dapat dengan mudah mengatur dan mengelola environment yang diperlukan untuk menguji arsitektur yang telah dirancang.

7. DBeaver: Tambahkan DBeaver untuk akses dan manajemen database.

8. Koneksi Internet: Dibutuhkan selama proses instalasi dependency.

2. Persiapan Infrastruktur: The Blueprint

Sebelum mengetik perintah, kita butuh fondasi yang jelas.

• Server A (Manager): Otak dari operasi kita.

• Server B (Worker): Pasukan yang siap menjalankan beban kerja.

• Server C (Database & Storage): Rumah bagi data kita agar tetap aman jika kluster aplikasi di-reset.

Catatan : Jangan pernah mencampur Database di dalam kluster Swarm aplikasi jika Anda masih awam dengan shared storage. Biarkan DB berdiri di server sendiri agar data Anda tidak "hilang" saat kontainer berpindah-pindah.

3. Install Docker

Langkah pertama adalah memastikan Docker terpasang di semua server (A, B, dan C). Gunakan skrip otomatis agar standar versinya sama di setiap mesin:

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

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc 

echo "deb [arch=\((dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \)(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

sudo usermod -aG docker $user

4. Setup Server C PostgreSQL Database & RustFS Object Storage

Pada tahap ini, kita akan menyiapkan Server C (192.168.20.104) sebagai pusat penyimpanan data untuk kluster.
Server ini berperan sebagai:

• Database server menggunakan PostgreSQL

• Object storage menggunakan RustFS untuk menyimpan file aplikasi (assets, upload, dll)

Pastikan Anda sudah dapat mengakses server melalui SSH:

ssh user@192.168.20.104

Docker Compose

Selanjutnya, buat file docker-compose.yaml untuk menjalankan PostgreSQL dan RustFS dalam satu host.

services:
  postgres:
    image: postgres:16
    container_name: postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: app_user
      POSTGRES_PASSWORD: app_password
      POSTGRES_DB: app_db
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app_user -d app_db"]
      interval: 10s
      timeout: 5s
      retries: 5

  rustfs:
    image: rustfs/rustfs:latest
    container_name: rustfs
    restart: unless-stopped
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      RUSTFS_VOLUMES: /data/rustfs{0..3}
      RUSTFS_ADDRESS: 0.0.0.0:9000
      RUSTFS_CONSOLE_ADDRESS: 0.0.0.0:9001
      RUSTFS_CONSOLE_ENABLE: "true"
      RUSTFS_ACCESS_KEY: rustfsadmin
      RUSTFS_SECRET_KEY: rustfsadmin
    volumes:
      - rustfs_data:/data
      - rustfs_logs:/logs
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/"]
      interval: 15s
      timeout: 5s
      retries: 5
      start_period: 20s

volumes:
  postgres_data:
  rustfs_data:
  rustfs_logs:

Jalankan service

Setelah file dibuat:

mkdir -p data/rustfs0 data/rustfs1 data/rustfs2 data/rustfs3 logs
docker compose up -d

Cek container:

docker ps

Akses service:

• PostgreSQL 192.168.20.104:5432

• RustFS API http://192.168.20.104:9000

• RustFS Console http://192.168.20.104:9001

Server C kini siap menjadi storage layer untuk cluster Docker Swarm pada tahap berikutnya.

Test Akses PostgreSQL

jangan lupa untuk inisialisasi Database schema dahulu:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

CREATE TABLE IF NOT EXISTS documents (
  id           UUID        PRIMARY KEY DEFAULT uuid_generate_v4(),
  filename     TEXT        NOT NULL,
  storage_path TEXT        NOT NULL UNIQUE,
  size         BIGINT      NOT NULL CHECK (size >= 0),
  content_type TEXT        NOT NULL,
  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX IF NOT EXISTS idx_documents_filename ON documents (filename);

Test Akses RustFS

jika ingin melihat logs dari docker container yang telah kita jalankan jalankan perintah

docker compose logs -f

5.Setup Server A & B Docker Swarm Manager dan Worker Node

Pada bagian ini kita akan menyiapkan Server A dan Server B sebagai node utama dalam kluster Docker Swarm. Pastikan kedua server sudah terinstall Docker Engine versi terbaru.

Inisialisasi Docker Swarm (Server A Manager)

Masuk ke Server A lalu jalankan:

docker swarm init --advertise-addr 192.168.20.101

Output akan menampilkan join token worker, contoh:

docker swarm join \
--token SWMTKN-1-xxxxx \
192.168.20.101:2377

Simpan token tersebut untuk Server B.

Cek status swarm:

docker node ls

Server A akan berstatus:

Leader

Join Worker ke Cluster (Server B)

Masuk ke Server B, lalu jalankan token join dari Server A:

docker swarm join \
--token SWMTKN-1-xxxxx \
192.168.20.101:2377

Jika berhasil:

This node joined a swarm as a worker.

Verifikasi dari Server A:

docker node ls

Output seharusnya:

Manager   Server A
Worker    Server B

6. Deploy Aplikasi GoDocAPI & Frontend ke Docker Swarm

Setelah Server B berhasil join ke Server A (Manager), tahap berikutnya adalah build image aplikasi dan melakukan deployment menggunakan docker stack.

Semua proses build dan deployment dilakukan dari Server A (Manager). Alternatifnya, build dapat dilakukan melalui Github Actions atau Jenkins.

Clone Repository

Masuk ke Server A:

ssh user@192.168.20.101

Clone kedua repository:

git clone https://github.com/mdrdani/GoDocAPI.git
git clone https://github.com/mdrdani/frontend-GoDocAPI.git

Konfigurasi Environment Backend (GoDocAPI)

Masuk ke folder backend:

cd GoDocAPI

Copy file .env.example Edit file .env dan sesuaikan dengan Server C (192.168.20.104):

SERVER_PORT=:8080
DB_URL=postgres://swarmuser:swarmpassword@192.168.20.104:5432/swarmdb?sslmode=disable
RUSTFS_ENDPOINT=http://192.168.20.104:9000
RUSTFS_ACCESS_KEY=admin
RUSTFS_SECRET_KEY=password123
RUSTFS_BUCKET=godoc-bucket
RUSTFS_REGION=us-east-1

Penting:

• Jangan gunakan localhost, karena backend berjalan di node berbeda.

• Gunakan IP Server C atau domain internal.

Build Image Backend (Golang)

Masih di folder GoDocAPI:

docker build -t godocapi:latest .

Verifikasi:

docker images | grep godocapi

Konfigurasi Environment Frontend (Next.js)

Masuk ke folder frontend:

cd ../frontend-GoDocAPI

Edit file .env:

API_URL=http://backend:8080

Penjelasan:

• Karena menggunakan Docker Swarm overlay network, service backend dapat diakses melalui service name (backend), bukan IP.

Build Image Frontend (Next.js)

docker build -t frontendgodocapi:latest .

Cek image:

docker images | grep frontendgodocapi

Login ke Docker Hub

docker login

Tag Image

docker tag godocapi:latest cehamot/godocapi:latest
docker tag fegodocapi:latest cehamot/fegodocapi:latest

Push ke Docker Hub

docker push cehamot/godocapi:latest
docker push cehamot/fegodocapi:latest

Buat File docker-stack.yaml

Kembali ke direktori utama (misalnya buat folder khusus deploy):

mkdir swarm-deploy
cd swarm-deploy

Buat file docker-stack.yaml:

version: '3.8'

services:
  frontend:
    image: cehamot/fegodocapi:latest
    ports:
        # Publish port menggunakan routing mesh (akses dari semua node)
      - "3000:3000"
    environment:
        # Mengakses backend via service name (internal DNS swarm)
      - API_URL=http://backend:8080
    deploy:
      # Menjalankan 2 instance container untuk high availability
      replicas: 2
      # Restart hanya jika container error
      restart_policy:
        condition: on-failure
      update_config:
        # Rolling update 1 container per batch
        parallelism: 1
        # Delay 10 detik antar update container
        delay: 10s
    networks:
        # Menggunakan overlay network antar node
      - app-net

  backend:
    image: cehamot/godocapi:latest
    ports:
        # Publish API via routing mesh swarm
      - "8080:8080"
    env_file:
        # File environment berisi DB & RustFS config (Server C)
      - ../GoDocAPI/.env
    deploy:
      # 2 instance backend untuk redundancy
      replicas: 2
      restart_policy:
        condition: on-failure
      update_config:
        # Rolling update satu per satu
        parallelism: 1
        delay: 10s
    networks:
        # Terhubung ke overlay network yang sama
      - app-net

networks:
  app-net:
    # Network multi-host (wajib untuk komunikasi antar node swarm)
    driver: overlay

Deploy ke Docker Swarm

Jalankan dari Manager:

docker stack deploy -c docker-stack.yaml godocapi

Cek service:

docker service ls

Cek detail task:

docker service ps godocapi_backend
docker service ps godocapi_frontend

cek detail logs:

docker service logs -f godocapi_backend
docker service logs -f godocapi_frontend

Verifikasi High Availability

Akses aplikasi melalui:

http://192.168.20.101:3000
atau
http://192.168.20.102:3000

Karena menggunakan:

• Replicas: 2

• Overlay network

• Routing mesh

Swarm akan mendistribusikan container ke Manager dan Worker secara otomatis.

7. Kesimpulan

Secara keseluruhan, pada Part 1 ini kita telah berhasil membangun fondasi arsitektur High Availability menggunakan Docker Swarm dengan pendekatan yang menyerupai lingkungan produksi nyata. Dimulai dari inisialisasi cluster dengan pemisahan peran Manager dan Worker, kemudian memisahkan application layer (frontend dan backend) dari data layer (PostgreSQL dan RustFS di Server C), hingga melakukan deployment menggunakan docker-stack.yaml dengan konfigurasi replication, overlay network, dan rolling update. Aplikasi yang bersumber dari repository GoDocAPI dan frontend-GoDocAPI kini berjalan secara terdistribusi, memiliki kemampuan self-healing, load balancing internal melalui routing mesh, serta siap untuk scaling horizontal. Dengan fondasi ini, cluster sudah memenuhi prinsip dasar sistem terdistribusi yang resilien dan siap dikembangkan lebih lanjut pada tahap optimasi dan hardening di bagian berikutnya.

selanjutnya kita akan membahas "Maintenance & Scaling: Ketika User Meledak"
1. Scaling Up vs Scaling Out: Kapan harus tambah replika, kapan harus tambah server Worker. 2. Zero Downtime Deployment: Cara update image aplikasi tanpa memutus koneksi user.
3. Integrasi HAProxy sebagai reverse proxy layer

Dulu, Docker hanya bisa berjalan di satu komputer. Jika trafik membludak atau server mati, selesailah riwayat aplikasi kita. Docker Swarm diciptakan sebagai jawaban atas kerumitan orkestrasi kontainer.

Swarm vs Kubernetes: Sebuah Perbandingan Jujur

Jika kita bandingkan keduanya, perbedaannya sangat mencolok:

• Kubernetes (K8s): Ibarat sebuah kota metropolitan yang canggih. Anda punya polisi (monitoring), pemadam kebakaran (auto-healing), dan sistem transportasi yang sangat rumit. Tapi, Anda butuh tim ahli untuk mengurus administrasinya setiap hari.

• Docker Swarm: Ibarat sebuah perumahan yang tertata rapi. Semua fitur penting sudah ada (Load Balancing, Scaling, High Availability) tanpa perlu pusing dengan konfigurasi yang berlembar-lembar. Jika kita sudah mengerti Docker Compose, kita sudah 90% mengerti Swarm.

2. Teknologi di Docker Swarm: Bagaimana Mereka Saling Bicara?

Mungkin kita bertanya, "Bagaimana server-server ini bisa kompak?" Ada dua teknologi utama yang menjadi "nyawa" di balik Docker Swarm:

A. Raft Consensus Algorithm

Bayangkan para Manager sedang duduk di meja bundar. Agar kluster tetap stabil, mereka harus punya satu pemimpin (Leader). Raft adalah protokol yang mereka gunakan untuk melakukan "voting". Jika Leader pingsan, Manager yang lain akan langsung berdiskusi dan memilih pemimpin baru dalam hitungan milidetik agar sistem tidak lumpuh.

B. Gossip Protocol

Seperti namanya (Gosip), ini adalah cara para Worker menyebarkan informasi. Mereka saling membisikkan status kesehatan satu sama lain secara cepat. Jadi, jika ada satu kontainer yang mati di pojok sana, kabar tersebut akan menyebar secepat kilat ke seluruh kluster sehingga Manager bisa segera mengambil tindakan.

C. Overlay Network & VXLAN

Secara fisik, server kita mungkin terpisah-pisah, namun Swarm menggunakan teknologi VXLAN untuk menciptakan Overlay Network.

• Analoginya: Seperti membangun terowongan rahasia di bawah tanah yang menghubungkan gedung-gedung berbeda.

• Kontainer di Server A bisa mengobrol dengan kontainer di Server B seolah-olah mereka berada di dalam satu kabel yang sama, tanpa Anda perlu repot mengatur IP publik atau rute jaringan yang rumit.

D. Ingress Routing Mesh & Internal DNS

Inilah teknologi yang membuat pengelolaan trafik menjadi sangat mudah:

• Ingress Mesh: Membuat Anda bisa mengakses aplikasi melalui IP server mana pun di dalam kluster. Jika aplikasi ada di Server B tapi Anda mengakses IP Server A, Swarm akan otomatis meneruskannya ke tempat yang benar.

• Service Discovery (Internal DNS): Anda tidak perlu menghafal IP kontainer yang sering berubah. Cukup panggil nama layanannya (misal: http://backend), dan DNS internal Swarm akan mencarikan kontainer mana yang sedang aktif dan sehat untuk Anda.

3. Glosarium Docker Swarm:

Agar tidak bingung, mari kita pelajari bahasa "keren" Docker Swarm:

• Manager Node: "Otak" dari kluster. Ia yang menerima perintah Anda dan membagi tugas ke server lain.

• Worker Node: "Buruh" pelaksana. Tugasnya hanya menjalankan kontainer aplikasi Anda tanpa ikut campur urusan administrasi.

• Service: Definisi dari aplikasi kita. Misal: "Saya mau menjalankan backend dengan 3 replika". Definisi inilah yang disebut Service.

• Task: Unit terkecil dalam Swarm. Jika Service minta 3 replika, maka akan ada 3 Task yang berjalan.

• Ingress Mesh: Fitur sakti yang membuat kita bisa mengakses aplikasi dari IP server mana saja di dalam kluster, dan trafiknya akan otomatis diarahkan ke server yang benar.

4. Perintah Docker Swarm

Berikut adalah daftar perintah Docker Swarm wajib bagi kita ketahui:

1. Pengelolaan Kluster (Node Management)

Digunakan untuk mengatur server-server (Manager & Worker) yang tergabung dalam kluster.

• docker swarm init --advertise-addr <IP> : Inisialisasi Manager pertama.

• docker swarm join-token worker : Menampilkan perintah/token agar server lain bisa bergabung sebagai Worker.

• docker swarm join-token manager : Menampilkan perintah/token agar server lain bisa bergabung sebagai Manager baru.

• docker node ls : Melihat daftar semua server di kluster beserta statusnya (Leader, Reachable, atau Ready).

• docker node update --availability drain <NODE_ID> : Menghentikan kontainer di node tertentu (berguna saat mau maintenance server tanpa mematikan layanan).

• docker node rm <NODE_ID> : Menghapus node dari kluster (pastikan node sudah down atau sudah di-drain).

2. Pengelolaan Stack (High-Level Deployment)

Ini adalah cara kita men-deploy aplikasi secara utuh menggunakan file docker-stack.yml.

%%[jagohosting2-mdrdani]

• docker stack deploy -c <FILE.yaml> <NAMA_STACK> : Deploy atau update aplikasi ke kluster.

• docker stack ls : Melihat daftar semua aplikasi (stack) yang sedang berjalan.

• docker stack services <NAMA_STACK> : Melihat status service di dalam stack (jumlah replika yang jalan vs diminta).

• docker stack ps <NAMA_STACK> : Melihat secara detail kontainer mana jalan di server mana.

• docker stack rm <NAMA_STACK> : Menghapus seluruh stack (mematikan semua layanan terkait).

3. Pengelolaan Service (Granular Control)

Digunakan jika kita ingin mengatur satu layanan spesifik tanpa menyentuh seluruh stack.

• docker service ls : Melihat semua layanan yang berjalan di seluruh kluster.

• docker service ps <NAMA_SERVICE> : Cek status spesifik satu layanan (misal godocapi_backend).

• docker service logs -f <NAMA_SERVICE> : Melihat log aplikasi secara real-time dari seluruh node sekaligus.

• docker service scale <NAMA_SERVICE>=<JUMLAH> : Menambah atau mengurangi jumlah kontainer secara instan tanpa edit file YAML.

• docker service update --image <IMAGE:TAG> <NAMA_SERVICE> : Mengupdate versi aplikasi (image) secara manual.

• docker service inspect --pretty <NAMA_SERVICE> : Melihat detail konfigurasi layanan (port, environment, dll) dalam format yang mudah dibaca.

4. Troubleshooting & Pemeliharaan

Perintah penyelamat saat aplikasi kita mulai bertingkah aneh.

• docker system df : Melihat penggunaan disk (penting karena Docker sering menyisakan image sampah).

• docker system prune -a : Menghapus container, network, dan image yang tidak terpakai (gunakan dengan hati-hati!).

• docker network ls : Melihat daftar network, cari yang bertipe overlay untuk komunikasi antar server.

• docker stats : Memantau penggunaan CPU dan RAM kontainer di server lokal secara real-time.

Kesimpulan

Docker Swarm adalah pilihan paling "waras" untuk tim kecil yang ingin mengejar target High Availability tanpa harus pusing dengan kurva belajar Kubernetes yang curam. Ia ringan, cepat, dan sudah ada di dalam instalasi Docker kita.

Di artikel berikutnya, kita akan langsung praktek membangun kluster pertama. Siapkan minimal dua server (Manager & Worker) dan mari kita mulai petualangan ini!

%%[nihbuatjajan2-mdrdani]

Inilah yang disebut sebagai Single Point of Failure. Untuk mengatasinya, kita akan melangkah ke tahap yang lebih tinggi: High Availability di level Load Balancer.

Apa yang Akan Kita Bangun?

Pada tahap ini, kita akan menyiapkan server HAProxy kedua (192.168.87.7) yang akan bertindak sebagai cadangan (Standby). Keduanya akan diikat menggunakan protokol VRRP (Virtual Router Redundancy Protocol) melalui layanan bernama Keepalived.

Hasil akhirnya adalah sebuah Virtual IP (VIP) atau Floating IP. User tidak lagi mengakses IP fisik server (192.168.87.6 atau 192.168.87.7), melainkan mengakses satu IP "keramat" yang akan selalu aktif selama salah satu dari kedua Load Balancer tersebut hidup. Jika Load Balancer utama mati, IP tersebut akan "berpindah" secara otomatis ke server cadangan dalam hitungan detik.

VM 2 Load Balancer Setup

Install HAProxy

Setelah berhasil menguji node pertama, langkah selanjutnya adalah menyiapkan VM kedua dengan alamat IP 192.168.87.7. VM ini akan berperan sebagai node cadangan yang siap mengambil alih trafik jika node utama bermasalah.

Agar performa dan fiturnya konsisten, kita akan menginstal versi HAProxy yang sama dengan node sebelumnya. Silakan SSH ke VM kedua dan jalankan rangkaian perintah berikut:

sudo apt update

sudo apt-get install --no-install-recommends software-properties-common

sudo add-apt-repository ppa:vbernat/haproxy-3.2

sudo apt-get install haproxy=3.2.\*

Pastikan versi yang terinstal sudah sesuai dengan menjalankan perintah:

haproxy -v

untuk memastikan HAProxy sudah berjalan dengan baik kita check dengan perintah

sudo systemctl status haproxy

Enable Dashboard

Modifikasi Konfigurasi HAProxy Buka file /etc/haproxy/haproxy.cfg dan tambahkan blok konfigurasi berikut untuk menentukan pada port dan alamat mana dashboard bisa diakses:

frontend stats
        mode http
        bind :8404
        stats enable
        stats refresh 10s
        stats uri /stats
        stats show-modules

Catatan: Di sini kita menggunakan port 8404. Pastikan port ini terbuka dan tidak terpakai oleh layanan lain.

Terapkan Perubahan Agar konfigurasi baru terbaca oleh sistem, lakukan restart pada layanan HAProxy dengan perintah berikut:

sudo systemctl restart haproxy.service

Akses Dashboard Sekarang, kita bisa melihat kondisi infrastruktur secara langsung melalui browser dengan mengakses alamat: http://192.168.87.7:8404/stats

Load Balancer Config

Setelah dashboard aktif, langkah selanjutnya adalah inti dari skenario kita: mengatur pembagian trafik. Di sini, HAProxy akan bertindak sebagai gerbang utama (port 80) yang akan meneruskan permintaan user ke dua server aplikasi (backend-1 dan backend-2) secara bergantian.

Silakan buka kembali file /etc/haproxy/haproxy.cfg dan tambahkan blok konfigurasi berikut di bagian bawah:

frontend docapi_front
        bind :80
        default_backend docapi_backend

backend docapi_backend
        balance roundrobin
        option httpchk GET /api/v1/health

        # Definisi server aplikasi dengan parameter health check yang presisi
        server backend-1 192.168.87.12:8080 check inter 5s fall 3 rise 2
        server backend-2 192.168.87.13:8080 check inter 5s fall 3 rise 2

Agar sistem benar-benar High Availability, kita tidak hanya sekadar mendaftarkan IP, tapi juga mengatur bagaimana HAProxy memantau "kesehatan" server tersebut:

• balance roundrobin: Trafik akan dibagi rata secara bergantian ke setiap server.

• option httpchk: HAProxy akan melakukan pengecekan ke endpoint /api/v1/health. Jika endpoint ini merespon dengan status 200 OK, maka server dianggap sehat.

• inter 5s: Pengecekan dilakukan setiap 5 detik sekali.

• fall 3: Jika server gagal merespon sebanyak 3 kali berturut-turut, HAProxy akan menandai server tersebut sebagai DOWN dan berhenti mengirim trafik ke sana.

• rise 2: Jika server yang sebelumnya mati kembali sehat dan berhasil merespon sebanyak 2 kali berturut-turut, HAProxy akan memasukkannya kembali ke dalam antrean trafik (UP).

Terakhir, simpan file tersebut dan jalankan perintah berikut untuk menerapkan konfigurasi baru:

sudo systemctl restart haproxy.service

Keepalived

Setelah memiliki dua node HAProxy yang identik, kita membutuhkan mekanisme untuk mengatur siapa yang menjadi "pemimpin" (Active) dan siapa yang menjadi "cadangan" (Standby). Di sinilah Keepalived berperan.

Keepalived adalah layanan berbasis Linux yang dirancang untuk menyediakan fitur High Availability melalui protokol VRRP (Virtual Router Redundancy Protocol). Tugas utamanya adalah mengelola Virtual IP (VIP)sebuah alamat IP "melayang" yang akan berpindah secara otomatis dari node utama ke node cadangan jika terdeteksi adanya kegagalan sistem. Dengan Keepalived, proses failover terjadi secara instan tanpa perlu campur tangan manual.

Install KeepAlived

Lakukan installasi keepalived dikedua VM Load Balancer (HAProxy-1 dan HAProxy-2) dengan perintah berikut.

sudo apt update

sudo apt install keepalived -y

Setelah proses instalasi selesai, kita perlu memastikan bahwa layanan Keepalived langsung berjalan dan otomatis aktif setiap kali server melakukan reboot (booting). Jalankan perintah berikut:

sudo systemctl enable keepalived --now

Untuk memastikan layanan sudah berjalan dengan benar di latar belakang, kamu bisa mengecek statusnya menggunakan perintah:

sudo systemctl status keepalived.service

Keepalived Configuration

Sekarang kita masuk ke tahap paling krusial, yaitu menentukan peran masing-masing node HAProxy. Kita akan membuat file konfigurasi /etc/keepalived/keepalived.conf pada kedua VM.

Meskipun isinya terlihat mirip, ada perbedaan parameter kunci antara HAProxy-1 (Master) dan HAProxy-2 (Backup) yang menentukan siapa yang berhak memegang Virtual IP pertama kali.

1. Konfigurasi pada HAProxy-1 (Node Master)

Node ini akan menjadi pemegang utama Virtual IP selama layanannya berjalan normal. Buat filenya dengan perintah sudo nano /etc/keepalived/keepalived.conf dan masukkan kode berikut:

vrrp_script chk_haproxy {
    # Mengecek apakah proses haproxy sedang berjalan
    script "pkill -0 haproxy"
    # Cek setiap 2 detik
    interval 2
    # Jika gagal 2x, anggap service mati
    fall 2
    # Jika sukses 1x, anggap service hidup kembali
    rise 1
    # Kurangi prioritas sebanyak 20 jika haproxy mati
    weight -20
}

vrrp_instance VI_1 {
    # Peran utama sebagai Master
    state MASTER
    # SESUAIKAN dengan nama interface jaringan VM kamu
    interface enp0s8
    # Harus sama di kedua node
    virtual_router_id 51
    # Prioritas lebih tinggi dari Backup
    priority 100
    # Interval pengiriman sinyal 'Heartbeat' (1 detik)
    advert_int 1

    authentication {
        auth_type PASS
        # Password sinkronisasi antar node
        auth_pass 1111
    }

    virtual_ipaddress {
        # Virtual IP (VIP) yang akan diakses user
        192.168.87.10
    }

    track_script {
        # Hubungkan dengan script monitoring di atas
        chk_haproxy
    }
}

2. Konfigurasi pada HAProxy-2 (Node Backup)

Node ini akan tetap dalam posisi standby dan hanya akan mengambil alih Virtual IP jika node Master mengalami gangguan. Gunakan konfigurasi yang sama, namun ubah bagian yang ditandai:

vrrp_script chk_haproxy {
    # Mengecek apakah proses haproxy sedang berjalan
    script "pkill -0 haproxy"
    # Cek setiap 2 detik
    interval 2
    # Jika gagal 2x, anggap service mati
    fall 2
    # Jika sukses 1x, anggap service hidup kembali
    rise 1
    # Kurangi prioritas sebanyak 20 jika haproxy mati
    weight -20
}

vrrp_instance VI_1 {
    # Peran sebagai cadangan (Backup)
    state BACKUP
    # SESUAIKAN dengan nama interface jaringan VM kamu
    interface enp0s8
    # Harus sama di kedua node
    virtual_router_id 51
    # Prioritas lebih rendah (90) dibanding Master (100)
    priority 90
    # Interval pengiriman sinyal 'Heartbeat' (1 detik)
    advert_int 1

    authentication {
        auth_type PASS
        # Password sinkronisasi antar node
        auth_pass 1111
    }

    virtual_ipaddress {
        # Virtual IP (VIP) yang akan diakses user
        192.168.87.10
    }

    track_script {
        # Hubungkan dengan script monitoring di atas
        chk_haproxy
    }
}

3. Terapkan Konfigurasi

Setelah file tersimpan di kedua VM, segera lakukan restart pada layanan Keepalived agar pengaturan baru tersebut aktif:

sudo systemctl restart keepalived.service

Pengujian Akhir: Uji Ketangguhan Infrastruktur (High Availability Test)

Setelah seluruh komponen terpasang, saatnya kita melakukan pengujian menyeluruh. Pada tahap ini, kita tidak lagi mengakses IP fisik server, melainkan menggunakan Virtual IP (VIP) yang telah kita konfigurasi. Silakan buka browser dan akses:

http://192.168.87.10/swagger/index.html

Skenario 1: Kegagalan di Level Aplikasi (Backend Failure)

Matikan salah satu server aplikasi (Backend 1 atau Backend 2).

• Cara Cek: Pantau melalui dashboard stats di http://192.168.87.10:8404/stats.

• Hasil: Kamu akan melihat salah satu baris berubah menjadi merah. Namun, saat kamu me-refresh halaman Swagger, aplikasi tetap berjalan normal karena HAProxy mengalihkan trafik ke node yang masih sehat.

  

  Skenario 2: Kegagalan di Level Load Balancer (Failover Test)

  Ini adalah pengujian paling krusial. Kita akan melihat bagaimana Virtual IP berpindah antar server Load Balancer.

  1. Buka terminal di VM 2 (Backup) dan jalankan perintah untuk memantau log secara real-time:

     sudo journalctl -u keepalived -f
     

  2. Saat ini, status VM 2 seharusnya masih berada pada BACKUP STATE.

     

  3. Sekarang, matikan VM 1 (Master) atau hentikan layanan HAProxy-nya.

  4. Perhatikan Log di VM 2: Kamu akan melihat log yang menyatakan bahwa VM 2 mendeteksi kegagalan Master dan segera berubah status menjadi MASTER STATE.

     

  5. Uji Akses: Akses kembali http://192.168.87.10/swagger/index.html.

  

  Hasil Akhir: Meskipun Load Balancer utama mati total, aplikasi tetap dapat diakses seolah-olah tidak terjadi apa-apa. Virtual IP telah berpindah ke VM 2 dalam hitungan detik. Inilah arsitektur High Availability yang Sebenarnya!

  Kesimpulan

• Membangun infrastruktur yang High Availability (HA) bukan berarti kita menciptakan sistem yang mustahil untuk rusak. Sebaliknya, HA adalah pengakuan bahwa kegagalanbaik itu hardware failure, network issue, maupun human erroradalah hal yang pasti akan terjadi suatu saat nanti.

  Melalui seri artikel ini, kita telah belajar bahwa arsitektur yang tangguh dibangun di atas tiga pilar utama:

  • Redundansi di Setiap Layer: Memastikan tidak ada satu pun komponen yang berdiri sendiri tanpa cadangan, mulai dari Load Balancer hingga server aplikasi.

  • Mekanisme Failover Otomatis: Menggunakan protokol seperti VRRP melalui Keepalived untuk memastikan perpindahan trafik terjadi dalam hitungan detik tanpa perlu campur tangan manual.

  • Pemisahan Data & State: Menjaga agar server aplikasi tetap stateless dengan memisahkan penyimpanan data ke PostgreSQL dan Rustfs, sehingga konsistensi data tetap terjaga meskipun node aplikasi berpindah-pindah.

  Dengan mengimplementasikan Beyond Load Balancing, kita telah berhasil mengeliminasi Single Point of Failure (SPOF). Kini, kamu bisa tidur lebih nyenyak karena tahu bahwa jika salah satu server atau load balancer kamu "pingsan" di jam 3 pagi, sistem kamu cukup cerdas untuk menyembuhkan dirinya sendiri dan tetap melayani pengguna dengan normal.

  Infrastruktur yang baik adalah infrastruktur yang tidak terlihat oleh pengguna karena ia selalu ada dan selalu bisa diandalkan.

  

Persiapan Environment

Sebelum kita masuk ke konfigurasi masing-masing server, pastikan kamu sudah menyiapkan "bahan-bahan" berikut:

1. Virtualization Tool: Saya menggunakan Oracle VM VirtualBox.

2. Sistem Operasi: Image Ubuntu 24.04 LTS (Noble Numbat) untuk semua node server.

   Spesifikasi Server: 2 GB RAM dan 15 GB Hardisk.

3. Networking: Setiap VM dikonfigurasi dengan 2 Network Adapter:

   • Adapter 1 (NAT): Untuk akses internet (update package, install HAProxy, dll).

   • Adapter 2 (Host-Only): Digunakan untuk jaringan LAN antar VM (komunikasi internal agar IP 192.168.87.x bisa saling ping).

4. Source Code: Kita akan menggunakan API sederhana berbasis Go sebagai bahan uji coba. Kamu bisa melakukan clone dari repository ini: https://github.com/mdrdani/GoDocAPI.

5. Docker: Dengan Docker, kita dapat dengan mudah mengatur dan mengelola environment yang diperlukan untuk menguji arsitektur yang telah dirancang.

6. DBeaver: Tambahkan DBeaver untuk akses dan manajemen database.

7. Koneksi Internet: Dibutuhkan selama proses instalasi dependency.

Topologi Lab Virtual

Berdasarkan diagram yang sudah kita bahas, kita akan membagi peran setiap VM sebagai berikut:

• Load Balancer 1 & 2: Menginstal haproxy dan keepalived.

• App Backend 1 & 2: Menjalankan GoDocAPI.

• Storage & DB: Menginstal postgresql dan setup Rustfs.

Dengan set-up ini, kita benar-benar mensimulasikan lingkungan pusat data (data center) nyata di dalam satu mesin lokal. Yuk, kita mulai dengan konfigurasi pertama!

Konfigurasi Single HAProxy (Basic Load Balancing)

Tujuan utama kita di tahap ini adalah memastikan bahwa layanan aplikasi tetap online selama setidaknya ada satu server backend yang hidup. HAProxy akan bertindak sebagai "polisi lalu lintas" yang memantau kesehatan setiap node aplikasi.

VM Database Postgres SQL dan RustFS Object Storage Setup

SSH Server IP Address 192.168.87.11

Install Docker

Jalankan perintah berikut untuk melakukan installasi Docker di VM.

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

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc 

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

sudo usermod -aG docker $user

silakan buatkan file docker-compose.yaml dengan konfigurasi sebagai berikut.

services:
  postgres:
    image: postgres:16
    container_name: postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: app_user
      POSTGRES_PASSWORD: app_password
      POSTGRES_DB: app_db
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app_user -d app_db"]
      interval: 10s
      timeout: 5s
      retries: 5

  rustfs:
    image: rustfs/rustfs:latest
    container_name: rustfs
    restart: unless-stopped
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      RUSTFS_VOLUMES: /data/rustfs{0..3}
      RUSTFS_ADDRESS: 0.0.0.0:9000
      RUSTFS_CONSOLE_ADDRESS: 0.0.0.0:9001
      RUSTFS_CONSOLE_ENABLE: "true"
      RUSTFS_ACCESS_KEY: rustfsadmin
      RUSTFS_SECRET_KEY: rustfsadmin
    volumes:
      - rustfs_data:/data
      - rustfs_logs:/logs
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/"]
      interval: 15s
      timeout: 5s
      retries: 5
      start_period: 20s

volumes:
  postgres_data:
  rustfs_data:
  rustfs_logs:

Jalankan service

Setelah file dibuat:

mkdir -p data/rustfs0 data/rustfs1 data/rustfs2 data/rustfs3 logs
docker compose up -d

Cek container:

docker ps

Akses service:

• PostgreSQL 192.168.20.104:5432

• RustFS API http://192.168.20.104:9000

• RustFS Console http://192.168.20.104:9001

Server C kini siap menjadi storage layer untuk cluster Docker Swarm pada tahap berikutnya.

Test Akses PostgreSQL

jangan lupa untuk inisialisasi Database schema dahulu:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

CREATE TABLE IF NOT EXISTS documents (
  id           UUID        PRIMARY KEY DEFAULT uuid_generate_v4(),
  filename     TEXT        NOT NULL,
  storage_path TEXT        NOT NULL UNIQUE,
  size         BIGINT      NOT NULL CHECK (size >= 0),
  content_type TEXT        NOT NULL,
  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX IF NOT EXISTS idx_documents_filename ON documents (filename);

Test Akses RustFS

jika ingin melihat logs dari docker container yang telah kita jalankan jalankan perintah

docker compose logs -f

VM Backend 1 dan 2 Setup

SSH Server IP Address 192.168.87.12

Install Docker

Jalankan perintah berikut untuk melakukan installasi Docker di VM.

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

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc 

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

sudo usermod -aG docker $user

Clone Repository

Lakukan clone repository dengna perintah berikut.

git clone https://github.com/mdrdani/GoDocAPI

Build Docker Image

Lakukan build image pada repository GoDocAPI.

cd GoDocAPI/

docker build -t godocapi .

Create Docker Compose

buatkan file docker-compose.yaml dengan konfigurasi sebagai berikut

services:
  app:
    image: godocapi:latest
    container_name: godocapi-app
    restart: unless-stopped
    ports:
      - 8080:8080
    env_file:
      - .env

Create .Env

buatkan satu buah file .env untuk menyimpan konfigurasi aplikasi seperti koneksi database dan object storage

SERVER_PORT=:8080
DB_URL=postgres://app_user:app_password@192.168.87.11:5432/app_db?sslmode=disable
RUSTFS_ENDPOINT=http://192.168.87.11:9000
RUSTFS_ACCESS_KEY=rustfsadmin
RUSTFS_SECRET_KEY=rustfsadmin
RUSTFS_BUCKET=docapi
RUSTFS_REGION=us-east-1

Running Docker Compose

jalankan Docker compose dengan perintah berikut

docker compose up -d

jika ingin melihat logs dari docker container yang telah kita jalankan jalankan perintah

docker compose logs -f

Ulangi di VM kedua menggunakan SSH ke IP address 192.168.87.13.

Load Balancer Setup

Pada tahap ini, kita akan menggunakan HAProxy Community Edition sebagai solusi load balancer. Saya menyiapkan satu Virtual Machine khusus dengan sistem operasi Ubuntu 24.04 LTS (Noble Numbat) untuk menjalankan tugas ini. Berikut adalah langkah-langkah instalasi dan konfigurasinya.

Install HAProxy

SSH ke VM IP Address 192.168.87.6, kemudian jalankan perintah berikut

sudo apt update

sudo apt-get install --no-install-recommends software-properties-common

sudo add-apt-repository ppa:vbernat/haproxy-3.2

sudo apt-get install haproxy=3.2.\*

untuk memastikan HAProxy sudah berjalan dengan baik kita check dengan perintah

sudo systemctl status haproxy

Enable Dashboard

Secara default, HAProxy bekerja di balik layar tanpa tampilan visual. Namun, HAProxy memiliki fitur dashboard bawaan yang sangat berguna untuk memantau status server backend, jumlah trafik, hingga mendeteksi secara visual jika salah satu node aplikasi sedang down.

Untuk mengaktifkan fitur ini, silakan ikuti langkah-langkah berikut:

Modifikasi Konfigurasi HAProxy Buka file /etc/haproxy/haproxy.cfg dan tambahkan blok konfigurasi berikut untuk menentukan pada port dan alamat mana dashboard bisa diakses:

frontend stats
        mode http
        bind :8404
        stats enable
        stats refresh 10s
        stats uri /stats
        stats show-modules

Catatan: Di sini kita menggunakan port 8404. Pastikan port ini terbuka dan tidak terpakai oleh layanan lain.

Terapkan Perubahan Agar konfigurasi baru terbaca oleh sistem, lakukan restart pada layanan HAProxy dengan perintah berikut:

sudo systemctl restart haproxy.service

Akses Dashboard Sekarang, kita bisa melihat kondisi infrastruktur secara langsung melalui browser dengan mengakses alamat: http://192.168.87.6:8404/stats

Load Balancer Config

Setelah dashboard aktif, langkah selanjutnya adalah inti dari skenario kita: mengatur pembagian trafik. Di sini, HAProxy akan bertindak sebagai gerbang utama (port 80) yang akan meneruskan permintaan user ke dua server aplikasi (backend-1 dan backend-2) secara bergantian.

Silakan buka kembali file /etc/haproxy/haproxy.cfg dan tambahkan blok konfigurasi berikut di bagian bawah:

frontend docapi_front
        bind :80
        default_backend docapi_backend

backend docapi_backend
        balance roundrobin
        option httpchk GET /api/v1/health

        # Definisi server aplikasi dengan parameter health check yang presisi
        server backend-1 192.168.87.12:8080 check inter 5s fall 3 rise 2
        server backend-2 192.168.87.13:8080 check inter 5s fall 3 rise 2

Agar sistem benar-benar High Availability, kita tidak hanya sekadar mendaftarkan IP, tapi juga mengatur bagaimana HAProxy memantau "kesehatan" server tersebut:

• balance roundrobin: Trafik akan dibagi rata secara bergantian ke setiap server.

• option httpchk: HAProxy akan melakukan pengecekan ke endpoint /api/v1/health. Jika endpoint ini merespon dengan status 200 OK, maka server dianggap sehat.

• inter 5s: Pengecekan dilakukan setiap 5 detik sekali.

• fall 3: Jika server gagal merespon sebanyak 3 kali berturut-turut, HAProxy akan menandai server tersebut sebagai DOWN dan berhenti mengirim trafik ke sana.

• rise 2: Jika server yang sebelumnya mati kembali sehat dan berhasil merespon sebanyak 2 kali berturut-turut, HAProxy akan memasukkannya kembali ke dalam antrean trafik (UP).

Terakhir, simpan file tersebut dan jalankan perintah berikut untuk menerapkan konfigurasi baru:

sudo systemctl restart haproxy.service

Testing Load Balancer

Setelah semua konfigurasi selesai, saatnya kita melakukan pembuktian. Tujuan pengujian ini adalah memastikan bahwa Load Balancer benar-benar mampu menjaga ketersediaan layanan meskipun salah satu server di belakangnya tumbang.

Pertama, pastikan aplikasi dapat diakses secara normal melalui alamat IP Load Balancer. Karena kita menggunakan GoDocAPI, silakan buka browser dan akses: http://192.168.87.6/swagger/index.html

Jika muncul tampilan dokumentasi Swagger, berarti HAProxy telah berhasil meneruskan trafik ke salah satu backend yang tersedia.

Sekarang, mari kita simulasikan kondisi error yang sebenarnya. Ikuti langkah berikut:

• Matikan Aplikasi: Masuk ke VM App Backend 2 (192.168.87.13) dan hentikan layanan aplikasinya (atau matikan VM tersebut).

• Pantau Dashboard: Jika kamu membuka dashboard stats di port 8404, kamu akan melihat baris backend-1 berubah menjadi warna merah (Status: DOWN).

  

• Uji Kembali: Coba refresh halaman Swagger tadi.

  

Hasilnya? Aplikasi tetap dapat diakses dan berfungsi dengan normal. Hal ini terjadi karena HAProxy secara otomatis mendeteksi kegagalan pada backend-1 dan mengalihkan seluruh permintaan user ke backend-2. Inilah esensi dari redundansi di level aplikasi.

Next Part 3 kita akan implementasikan 2 HAProxy.

Banyak dari kita mungkin merasa sudah aman ketika berhasil menerapkan load balancer di depan beberapa server backend. Rasanya seperti sudah punya asuransi; kalau satu server mati, yang lain masih bisa menopang. Tapi, pernahkah kamu bertanya-tanya: Bagaimana jika si pengatur lalu lintas itu sendiri yang pingsan?

Inilah jebakan Single Point of Failure (SPOF) yang sering terlupakan. Sebagus apapun backend yang kita bangun, jika pintu gerbang utamanya hanya satu dan ia tumbang, maka seluruh sistem kita akan ikut 'gelap'. Dalam artikel kali ini, saya ingin mengajak teman-teman untuk melihat lebih jauh melampaui konsep distribusi beban biasa. Kita akan membedah bagaimana membangun arsitektur High Availability yang sebenarnyasebuah sistem yang tidak hanya tangguh di level aplikasi, tapi juga memiliki mekanisme pertahanan diri saat infrastrukturnya mengalami kegagalan

Redundansi di Level Aplikasi

Pada tahap awal pengembangan, kita sering kali memulai dengan satu server tunggal. Namun, seiring bertambahnya trafik, kita mulai mengenal konsep redundansi. Mari kita perhatikan ilustrasi pertama di bawah ini:

Di sini, kita menempatkan HAProxy sebagai garda terdepan. Tugasnya sederhana namun krusial: menerima permintaan dari user dan membaginya ke App Backend 1 dan App Backend 2. Jika Backend 1 sedang sibuk atau mengalami crash, HAProxy secara cerdas akan mengalihkan trafik ke Backend 2. Inilah bentuk awal dari ketahanan sistem.

Mengapa Database dan Storage Harus Terpisah?

Satu hal yang menarik dari diagram di atas adalah pemisahan antara server aplikasi dengan PostgreSQL dan Rustfs (Object Storage). Mungkin ada yang bertanya, "Kenapa tidak dijadikan satu saja di dalam server aplikasi agar lebih hemat?" Ada dua alasan utama mengapa pemisahan ini wajib dilakukan dalam arsitektur High Availability:

• Data Consistency (Konsistensi Data): Jika setiap backend memiliki database lokal sendiri, maka data antara Backend 1 dan Backend 2 tidak akan pernah sinkron. Dengan memisahkan database ke server tersendiri, semua node aplikasi akan melihat dan menulis ke satu sumber kebenaran (single source of truth) yang sama.

• Stateless Application: Agar kita bisa menambah atau menghapus server aplikasi sesuka hati (scaling), server aplikasi tersebut tidak boleh menyimpan data permanen secara lokal. Semua file gambar atau dokumen harus dilempar ke Rustfs, dan semua data relasional disimpan di PostgreSQL. Dengan begini, server aplikasi menjadi statelessartinya, ia bisa diganti kapan saja tanpa takut kehilangan data user.

Arsitektur ini sudah cukup bagus, tapi masih menyimpan satu titik lemah yang fatal: Bagaimana jika HAProxy yang ada di tengah itu mati? Seluruh sistem akan lumpuh seketika. Masalah inilah yang akan kita pecahkan di bagian selanjutnya.

High Availability yang Sebenarnya

Jika pada diagram pertama kita merasa sudah aman dengan dua backend, sekarang mari kita hadapi kenyataan pahit: Bagaimana jika server HAProxy dengan IP 192.168.87.6 mati?

Meskipun kamu punya 100 backend yang sehat di belakangnya, user tetap tidak akan bisa mengakses aplikasi karena pintu masuknya terkunci. Di sinilah kita masuk ke level High Availability yang sebenarnya dengan memperkenalkan konsep Load Balancer Redundancy.

Mengenal Mekanisme Failover & Health Check

Pada diagram kedua, kita tidak lagi hanya mengandalkan satu HAProxy. Kita menambahkan satu lagi "penjaga" dengan IP 192.168.87.7. Perhatikan tanda panah dua arah bertuliskan "Health Check" di antara keduanya. Inilah rahasianya:

1. Saling Mengawasi (Heartbeat): Kedua node HAProxy ini saling mengirimkan sinyal "detak jantung" secara terus-menerus. Selama node utama (192.168.87.6) memberikan respon, node cadangan (192.168.87.7) akan tetap dalam posisi standby.

2. Deteksi Kegagalan: Begitu node utama berhenti merespon (mungkin karena hardware failure atau kernel panic), node cadangan akan langsung mendeteksinya dalam hitungan milidetik.

3. Pengambilalihan (Failover): Node cadangan akan segera mengambil alih tugas node utama. Di sinilah biasanya kita menggunakan teknologi seperti Keepalived atau VRRP.

Keajaiban Floating IP (Virtual IP)

Mungkin kamu bingung: "Kalau IP-nya ada dua (192.168.87.6 dan 192.168.87.7), lalu user tembak ke IP yang mana?"

Dalam arsitektur HA yang matang, kita menggunakan Floating IP atau Virtual IP (VIP). User tidak menembak langsung ke IP asli server, melainkan ke satu IP bayangan. IP bayangan ini secara dinamis akan "menempel" pada server HAProxy yang sedang aktif. Jika server A mati, IP bayangan itu akan "berpindah" secara otomatis ke server B tanpa user sadari.

Menghilangkan Single Point of Failure

Dengan konfigurasi ini, kita telah berhasil mengeliminasi titik lemah di setiap lapisan:

• Layer Traffic: Jika satu LB mati, ada LB cadangan.

• Layer Application: Jika satu backend mati, ada node lain yang siap sedia.

• Layer Data: Database dan Storage dipisahkan agar tetap persistent dan bisa diakses secara kolektif.

Inilah yang kita sebut sebagai infrastruktur yang memiliki daya tahan tinggi atau Resilient Infrastructure.

Kesimpulan

Setelah membedah diagram-diagram di atas, satu hal yang harus kita sadari adalah: High Availability (HA) bukanlah sebuah barang yang bisa kita beli jadi, lalu selesai. HA adalah sebuah perjalanan untuk terus mengidentifikasi dan mengeliminasi setiap kemungkinan titik kegagalan atau Single Point of Failure (SPOF).

Membangun infrastruktur seperti ini memang membutuhkan usaha ekstrakita harus mengonfigurasi dua HAProxy, mengatur protokol VRRP, hingga memastikan aplikasi kita bersifat stateless agar bisa berkomunikasi dengan PostgreSQL dan Rustfs secara lancar. Namun, imbalannya sebanding: sebuah sistem yang memiliki daya tahan tinggi (resilience) dan kepercayaan dari pengguna.

Ringkasnya, prinsip utama dalam membangun arsitektur HA adalah:

• Redundansi: Selalu miliki cadangan di setiap lapisan.

• Failover otomatis: Jangan biarkan proses perpindahan bergantung pada campur tangan manusia.

• Separation of Concerns: Pisahkan logika aplikasi dari penyimpanan data agar sistem lebih fleksibel.

Infrastruktur yang kuat bukan berarti infrastruktur yang tidak pernah mengalami kendala. Justru sebaliknya, infrastruktur yang hebat adalah yang sudah siap menghadapi kerusakan di bagian mana pun, namun tetap mampu melayani pengguna seolah-olah tidak terjadi apa-apa.

Next Part 2 kita implementasikan.

Dalam pengembangan aplikasi modern, arsitektur three-tier (tiga lapis) adalah pendekatan yang umum digunakan karena memisahkan logika aplikasi menjadi tiga komponen utama: frontend, backend, dan database. Namun, seiring bertambahnya kompleksitas sistem, kebutuhan akan pengelolaan infrastruktur yang otomatis dan konsisten menjadi semakin penting.

Melalui artikel ini, kita akan membahas implementasi arsitektur three-tier yang tidak hanya modular, tetapi juga sepenuhnya dapat diotomatisasi menggunakan Vagrant dan VirtualBox. Pendekatan ini sangat cocok untuk tim pengembang yang menginginkan lingkungan lokal yang stabil dan mudah direplikasi.

• Frontend: Dibangun dengan React.js

• Backend: Menggunakan Node.js

• Database: PostgreSQL

• Load Balancer: Dikelola oleh NGINX

• Virtualisasi: Semua komponen dijalankan dalam VM yang dikelola oleh Vagrant dan VirtualBox

Arsitektur Sistem

1. User (Client)

Pengguna mengakses aplikasi melalui browser. Semua permintaan dari client diarahkan terlebih dahulu ke server NGINX yang bertindak sebagai load balancer.

2. NGINX sebagai Load Balancer

NGINX berada di garis depan sistem dan berperan sebagai load balancer, yaitu komponen yang bertugas untuk mendistribusikan permintaan dari pengguna ke server tujuan yang sesuai. Dalam arsitektur ini, NGINX memiliki fungsi utama:

• Menerima request dari user

• Meneruskan permintaan ke Frontend VM jika permintaan adalah halaman UI

• Meneruskan permintaan ke Backend VM jika permintaan adalah API

• Menyediakan SSL termination (opsional, jika HTTPS digunakan)

• Menyembunyikan VM internal dari akses langsung pengguna

• Meningkatkan skalabilitas dan keandalan sistem dengan mengatur lalu lintas berdasarkan peran server

3. Frontend VM (React.js)

VM ini menjalankan aplikasi React yang merupakan antarmuka pengguna (UI). Semua aset statis seperti HTML, CSS, dan JavaScript di-serve dari sini. React akan mengirimkan permintaan API ke backend menggunakan endpoint yang sudah ditentukan.

4. Backend VM (Node.js)

VM ini menjalankan server aplikasi berbasis Node.js. Backend memproses logika bisnis, validasi, autentikasi, dan komunikasi dengan database.

Contoh fungsi backend:

• Login user

• Pemrosesan form

• Pengambilan data produk

• Penyimpanan data baru ke database

5. Database VM (PostgreSQL)

Menyimpan data aplikasi seperti user, transaksi, atau konten lainnya. Backend akan berkomunikasi langsung dengan VM ini melalui koneksi database.

6. Vagrant + VirtualBox

Seluruh komponen (Frontend, Backend, Database) dijalankan dalam virtual machine yang dikelola oleh Vagrant, dengan VirtualBox sebagai provider VM.

Keuntungan menggunakan Vagrant dengan VirtualBox:

• Automasi provisioning: Semua VM bisa dibuat dan dikonfigurasi hanya dengan satu perintah (vagrant up)

• Isolasi lingkungan: Setiap lapisan berjalan di VM terpisah

• Jaringan virtual: Dapat diatur menggunakan IP statis via private_network atau host-only

• Lingkungan konsisten: Developer tidak perlu menginstal layanan manual di OS host

• Portabilitas: Konfigurasi yang sama bisa dijalankan di mesin berbeda

Vagrantfile

Konfigurasi Vagrantfile di bawah adalah bagian dari arsitektur infrastruktur otomatis menggunakan Vagrant dan VirtualBox, yang menetapkan pengaturan umum untuk semua VM dalam proyek.

Vagrant.configure("2") do |config|
  # Configure common settings

  # Base box
  config.vm.box = "bento/ubuntu-22.04"

  # Configure VirtualBox related settings
  config.vm.provider "virtualbox" do |vb|
    # Set CPU and Memory of the VM
    vb.memory = "768"
    vb.cpus = 2
  end

  # I don't want to check for updates
  config.vm.box_check_update = false

  # Disable the default share of the current code directory
  # I don't want the guest to write to make changes to the code
  config.vm.synced_folder ".", "/vagrant", disabled: true

  # Common provisioning script for all VMs
  config.vm.provision "shell", inline: "apt update && apt install -y curl git gnupg net-tools"

  # Common provisioning script to install NodeJS v18
  # It will be used in frontend and backend VMs
  nodejs_install_script = <<-SHELL
    echo "Installing NodeJS v18"
    curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
    export NVM_DIR="$HOME/.nvm"
    [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
    [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"
    nvm install 18
    echo "NodeJS version: $(node -v)"
    echo "NPM version: $(npm -v)"
    sudo npm install -g pm2 npm
  SHELL
.......

Berikut penjelasan tiap bagian:

Vagrant.configure("2") do |config|

Menandakan kita menggunakan Vagrantfile format versi 2, yang merupakan standar saat ini.

config.vm.box = "bento/ubuntu-22.04"

Mengatur sistem operasi dasar semua VM menjadi Ubuntu 22.04 dari provider bento.

config.vm.provider "virtualbox" do |vb|
  vb.memory = "768"
  vb.cpus = 2
end

Mengatur resource untuk setiap VM:

• RAM: 768 MB

• CPU: 2 core

Ini memastikan semua VM berjalan ringan, cocok untuk lokal.

config.vm.box_check_update = false

Menonaktifkan pengecekan update box setiap kali vagrant up, agar lebih cepat.

config.vm.synced_folder ".", "/vagrant", disabled: true

Menonaktifkan folder sinkronisasi default antara host (.) dan guest (/vagrant), biasanya untuk mencegah tulisan tak diinginkan ke host, atau menjaga isolasi.

config.vm.provision "shell", inline: "apt update && apt install -y curl git gnupg net-tools"

Script shell ini akan dijalankan di semua VM, menginstal alat bantu dasar:

• curl, git, gnupg, dan net-tools untuk keperluan umum sistem

nodejs_install_script = <<-SHELL
    echo "Installing NodeJS v18"
    curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
    export NVM_DIR="$HOME/.nvm"
    [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
    [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"
    nvm install 18
    echo "NodeJS version: $(node -v)"
    echo "NPM version: $(npm -v)"
    sudo npm install -g pm2 npm
  SHELL

Script ini mendefinisikan instalasi Node.js versi 18 menggunakan NVM (Node Version Manager), dan akan digunakan dalam provisioning Frontend dan Backend VM.

Rincian tugas:

1. Install NVM

2. Install Node.js v18

3. Verifikasi versi node dan npm

4. Global install:

   • pm2: Untuk menjalankan proses Node.js sebagai background service

   • yarn: Sebagai alternatif npm yang populer dan cepat

Setelah itu file konfigurasi di bawah adalah lanjutan dari Vagrantfile diatas yang mendefinisikan VM untuk Load Balancer dengan peran sebagai NGINX load balancer.

.....
# Define Load Balancer VM
  config.vm.define "lb" do |lb|
    lb.vm.hostname = "lb"
    lb.vm.network "private_network", ip: "192.168.56.5"
    lb.vm.provision "shell", inline: <<-SHELL

    echo "Installing Nginx"
    apt install -y nginx

    echo "Configuring Nginx as a Load Balancer"
cat > /etc/nginx/sites-available/default << EOF
  server {
      listen 80;
      server_name _;

      # Forward requests to /api to the backend
      location ~* /api {
          proxy_pass http://192.168.56.3:3000;
      }

      # Forward other requests to the frontend
      location / {
          proxy_pass http://192.168.56.2;
      }
  }
EOF
    echo "Restart NGINX to apply changes"
    systemctl restart nginx
    SHELL
  end
.....

Menjadikan VM ini sebagai entry point untuk semua request pengguna. NGINX bertindak sebagai router yang mengarahkan request ke frontend atau backend sesuai path URL.

Singkatnya:
Automatisasi setup NGINX
Routing berdasarkan path
Terintegrasi dalam arsitektur 3-tier yang dijalankan via Vagrant

untuk menjalankan VM Load Balancer kita dapat menggunakan perintah

vagrant up lb

jika sudah running kita dapat check menggunakan browser dengan mengakses IP Address VM Load Balancer tersebut. status nya masih 502 Bad Gateway karena VM lain nya belum di aktifkan.

jika kita ingin mengakses VM Load Balancer dengan menggunakan SSH kita dapat menggunakan command

vagrant ssh lb

Selanjutnya kita konfigurasi VM Database masih lanjutan dari Vagrantfile . VM Database menggunakan PostgreSQL versi 16.

......
config.vm.define "db" do |db|
    db.vm.hostname = "db"
    db.vm.network "private_network", ip: "192.168.56.4"
    db.vm.provision "shell", inline: <<-SHELL
      sudo apt install -y postgresql-common
      sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh
      sudo apt -y install postgresql-16
      echo "Start PostgreSQL service"
      systemctl start postgresql

      echo "Enable PostgreSQL to start on boot"
      systemctl enable postgresql

      echo "Set postgres user password to postgres, for demonstration purposes"
      sudo -u postgres psql -c "ALTER ROLE postgres WITH password 'postgres'"

      echo "Create the conduit database owned by postgres"
      sudo -u postgres psql -c "CREATE DATABASE conduit OWNER postgres;"

      echo "Configure PostgreSQL to listen on all interfaces"
      sed -i "s/#listen_addresses = 'localhost'/listen_addresses = '*'/g" /etc/postgresql/16/main/postgresql.conf

      echo "Allow all connections in pg_hba.conf"
      echo "host    all             all             0.0.0.0/0               md5" | sudo tee -a /etc/postgresql/16/main/pg_hba.conf

      echo "Restart PostgreSQL to apply changes"
      systemctl restart postgresql
    SHELL
  end
.....

untuk menjalankan VM Database kita dapat menggunakan perintah

vagrant up db

untuk mengakses VM Database seperti biasa kita bisa gunakan command

vagrant ssh db

Selanjutnya kita konfigurasi VM Backend masih lanjutan dari Vagrantfile dengan IP 192.168.56.3 VM Backend ini bertugas menjalankan backend service node.js yang di ambil dari github https://github.com/gothinkster/node-express-realworld-example-app.git .

.....
config.vm.define "backend" do |backend|
    backend.vm.hostname = "backend"
    backend.vm.network "private_network", ip: "192.168.56.3"
    backend.vm.provision "shell", privileged: false, inline: nodejs_install_script
    backend.vm.provision "shell", privileged: false, inline: <<-SHELL
      echo "Begin installing Backend"
      export NVM_DIR="$HOME/.nvm"
      [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
      export DATABASE_URL=postgresql://postgres:postgres@192.168.56.4:5432/conduit
      export JWT_SECRET=6b350c623d150e8a07d36e963e1416079a7a322e8c04952d674fe607914d7b01
      export NODE_ENV=development
      echo "Cloning the backend repository"
      git clone https://github.com/gothinkster/node-express-realworld-example-app.git $HOME/backend

      echo "Writing environment variables to .env"
      cat > $HOME/backend/.env << EOF
DATABASE_URL=postgresql://postgres:postgres@192.168.56.4:5432/conduit
JWT_SECRET=6b350c623d150e8a07d36e963e1416079a7a322e8c04952d674fe607914d7b01
NODE_ENV=development
EOF

      echo "Installing dependencies"
      cd $HOME/backend
      npm install

      echo "Generating Prisma client, running migrations, and seeding the database"
      npx prisma generate
      npx prisma migrate deploy && npx prisma db seed

      echo "Starting the backend server using pm2"
      pm2 start npm --name "backend" -- start
    SHELL
  end
.....

untuk menjalankan VM Backend kita dapat menggunakan perintah

vagrant up backend

untuk mengakses VM Backend seperti biasa kita bisa gunakan command

vagrant ssh backend

Terakhir kita konfigurasi VM Frontend masih lanjutan dari Vagrantfile dengan IP 192.168.56.2. VM Frontend ini bertugas menjalankan frontend service React.js yang di ambil dari github https://github.com/khaledosman/react-redux-realworld-example-app.git.

......
config.vm.define "frontend", autostart: false do |frontend|
    frontend.vm.hostname = "frontend"
    frontend.vm.network "private_network", ip: "192.168.56.2"
    # Copy frontend directory to VM. 
    frontend.vm.provision "shell", inline: "apt install -y nginx"
    frontend.vm.provision "shell", privileged: false, inline: nodejs_install_script
    frontend.vm.provision "shell", privileged: false, inline: <<-SHELL
      echo "Begin installing Frontend"
      export NVM_DIR="$HOME/.nvm"
      [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

      echo "Cloning the frontend repository"
      git clone https://github.com/khaledosman/react-redux-realworld-example-app.git $HOME/frontend

      echo "Installing dependencies"
      cd $HOME/frontend/
      npm install

      echo "Building the frontend"
      REACT_APP_BACKEND_URL="http://192.168.56.5/api" NODE_ENV=production npm run build

      echo "Copying the build to /var/www/html to serve it using Nginx"
      sudo mv $HOME/frontend/build/* /var/www/html/ 
    SHELL
  end
end

untuk menjalankan VM Frontend kita dapat menggunakan perintah

vagrant up frontend

untuk mengakses VM Frontend seperti biasa kita bisa gunakan command

vagrant ssh frontend

setelah semua VM up maka kita akan check kembali ke browser dengan akses http://192.168.56.5/

Bagaimana kita tau bahwa three tier architecture kita berjalan?? cara nya gampang matikan salah satu VM apakah masih berjalan dengan baik, seharusnya tidak bisa di akses kita contoh kan di matikan VM Backend dengan perintah.

vagrant halt backend

terlihat VM Frontend tidak dapat mengakses API VM Backend.
untuk mematikan semua VM kita dapat dengan mudah menggunakan command

vagrant halt

Dengan menerapkan arsitektur three-tier menggunakan NGINX sebagai load balancer, Node.js untuk backend, React sebagai frontend, dan PostgreSQL sebagai database, kita telah membangun lingkungan aplikasi web yang modular, terstruktur, dan mudah dikembangkan.

Penggunaan Vagrant dan VirtualBox memungkinkan kita untuk mengotomasi infrastruktur secara konsisten, sehingga setiap anggota tim dapat mereplikasi lingkungan pengembangan dengan satu perintah. Hal ini sangat penting dalam pengembangan perangkat lunak modern yang menuntut efisiensi, konsistensi, dan skalabilitas.

Github : https://github.com/mdrdani/three-tier

Intructions

1. Configure resource limits for local group student, so that a maximum of 100 processes can be start.

2. Configure resource limits for local user student, so that a maximum open file is 3000, and configure current limit is 2000.

3. The above process limit should run when the student user logs in for the first time, ex: after rebooting

Configure resource limits for local group student, so that a maximum of 100 processes can be start.

Untuk konfigurasi resource limit group student langkah pertama kita check terlebih dahulu apakah group student sudah ada menggunakan command linux

getent group student

Jika sudah ada group student, maka selanjutnya edit file /etc/security/limits.conf dan tambahkan baris ini di dalamnya

#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#ftp             -       chroot          /ftp
#@student        -       maxlogins       4

@student        hard    nproc           100

Keterangan:

• @student Menunjukkan bahwa ini berlaku untuk grup student.

• hard nproc 100 Batas maksimal proses yang bisa dijalankan

Configure resource limits for local user student, so that a maximum open file is 3000, and configure current limit is 2000.

jika tadi kita konfigurasi untuk group nya maka selanjutnya kita konfigurasi untuk user nya. Langkah Pertama kita check apakah ada user student dan adakah user di dalam group student..

id student

uid=1000(student) gid=1000(student) groups=1000(student),100(users),117(admin)

jika tidak ada di dalam group student, kita bisa gunakan

sudo usermod -aG student student

selanjutnya untuk melimit akun student ini kita edit file /etc/security/limits.conf kembali dengan menambahkan baris berikut

#ftp             hard    nproc           0
#ftp             -       chroot          /ftp
#@student        -       maxlogins       4

@student        hard    nproc           100

student         soft    nofile          2000
student         hard    nofile          3000

Keterangan :

• soft nofile 2000 Batas awal (soft limit) untuk file terbuka.

• hard nofile 3000 Batas maksimal (hard limit) untuk file terbuka.

The above process limit should run when the student user logs in for the first time, ex: after rebooting

untuk memproses limit ketika user login pertama kali maka kita kita perlu mengedit file /etc/pam.d/common-session

session required pam_limits.so

# See "man pam_umask".
session optional                        pam_umask.so
# and here are more per-package modules (the "Additional" block)
session required        pam_unix.so
session optional        pam_systemd.so
session required        pam_limits.so
# end of pam-auth-update config

dan edit juga file /etc/pam.d/common-session-noninteractive

# See "man pam_umask".
session optional                        pam_umask.so
# and here are more per-package modules (the "Additional" block)
session required        pam_unix.so
session required        pam_limits.so
# end of pam-auth-update config

Ini memastikan bahwa batasan dari /etc/security/limits.conf diterapkan saat login.

Jika ingin mengatur nice value untuk pengguna student, dapat menambahkan baris

student hard priority 10
student soft priority 10

Apa Itu Nice Value?

nice value adalah tingkat prioritas suatu proses di sistem Linux. Nilai ini menentukan seberapa banyak CPU time yang diberikan ke proses tertentu dibandingkan dengan proses lain.

• Nilai rendah (misal -20) berarti proses memiliki prioritas tinggi (lebih diutamakan oleh CPU).

• Nilai tinggi (misal 19) berarti proses memiliki prioritas rendah (kurang diutamakan oleh CPU).

Secara default, nice value untuk proses yang berjalan adalah 0.

#@student        -       maxlogins       4

@student        hard    nproc           100

student         soft    nofile          2000
student         hard    nofile          3000

student         hard    priority        10
student         soft    priority        10

# End of file

Mengapa Mengatur Nice Value?

Mengatur nice value untuk pengguna bertujuan untuk:

• Mengontrol alokasi CPU untuk proses yang dibuat oleh user.

• Mencegah pengguna mengambil terlalu banyak CPU, sehingga proses penting lain tetap berjalan optimal.

• Membantu manajemen sumber daya dalam sistem multi-user.

Cek Nice Value Default
Jalankan perintah berikut sebagai student:

nice

Jika konfigurasi benar, outputnya harus:

10

Instructions

1. Enter the lab2 directory, see the contents in the directory.

2. Count the files by name and write to /home/student/lab2/lab2.txt
   example: client = 20

Hasilnya, saya berhasil membuat file lab2.txt yang berisi informasi jumlah file seperti yang diminta dengan menggunakan command linux :

echo "client = $(ls lab2 | grep '^client' | wc -l)" > lab2.txt && \
echo "manager = $(ls lab2 | grep '^manager' | wc -l)" >> lab2.txt && \
echo "ops = $(ls lab2 | grep '^ops' | wc -l)" >> lab2.txt

Penjelasan Perintah Secara Detail

1. $(...)

   • Ini adalah command substitution, yang menjalankan perintah di dalamnya dan menggantinya dengan hasilnya.

   • Contoh: Jika ada 4 file client, maka $(ls lab2 | grep '^client' | wc -l) akan menjadi 4.

2. ls lab2

   • Menampilkan daftar semua file dalam folder lab2.

3. grep '^client'

   • Menyaring hanya file yang namanya diawali dengan "client".

   • ^ adalah simbol regex yang berarti "diawali dengan".

   • Contoh: Jika ada client1, client2, client3, ini akan memilih ketiga file tersebut.

4. wc -l

   • Menghitung jumlah baris dari output grep.

   • Karena setiap file ditampilkan sebagai satu baris, ini berarti jumlah file yang cocok.

5. echo "client = ..." > lab2.txt

   • Menulis hasil ke dalam file lab2.txt, mengganti isi file jika sudah ada.

6. >> lab2.txt

   • Menambahkan hasil berikutnya ke file lab2.txt tanpa menghapus isi sebelumnya.

7. &&

   • Memastikan bahwa perintah berikutnya hanya dijalankan jika perintah sebelumnya sukses.

   • Jika ls lab2 gagal (misalnya folder tidak ada), maka perintah selanjutnya tidak akan

Nanti expetasi yang akan terlihat di file lab2.txt akan seperti ini

client = 4
manager = 3
ops = 3

Task 4.1: Use ping to check connectivity to google.com

ping google.com > ping_output.txt

Komando ini adalah kombinasi dari dua perintah Linux yang digunakan untuk menguji koneksi jaringan ke google.com dan menyimpan hasilnya ke dalam file bernama ping_output.txt.

• ping google.com: Perintah ping digunakan untuk menguji konektivitas jaringan dengan mengirimkan paket data ke alamat IP tertentu (dalam hal ini, alamat IP dari google.com) dan menunggu balasan. Tujuannya adalah untuk mengetahui apakah komputer kita dapat terhubung ke alamat IP tersebut dan berapa lama waktu yang dibutuhkan untuk menerima balasan.

• >: Tanda ini adalah redirection operator yang digunakan untuk mengalihkan output dari suatu perintah ke file. Dalam hal ini, output dari perintah ping google.com akan dialihkan ke file ping_output.txt

Kenapa pakai perintah ini?

Perintah ini sangat berguna untuk:

• Memeriksa Konektivitas: Kita bisa tahu apakah komputer kita terhubung ke internet atau tidak.

• Menguji Kecepatan Jaringan: Kita bisa melihat seberapa cepat koneksi internet kita berdasarkan waktu tempuh bolak-balik.

• Mencari Masalah Jaringan: Kalau ada masalah koneksi, kita bisa lihat dari output ping, misalnya apakah ada paket data yang hilang atau waktu tempuh bolak-balik yang terlalu lama.

Task 4.2: Use ping with 10 packets

ping -c 10 google.com > ping_10_packets.txt

-c 10: Opsi ini adalah yang bikin beda. -c adalah singkatan dari "count". Angka 10 di belakangnya berarti kita hanya ingin mengirimkan 10 paket ping saja. Jadi, ping tidak akan berjalan terus-menerus, tapi hanya 10 kali saja.

Task 4.3: Use ping with a packet size of 1000 Bytes

ping -s 1000 google.com > ping_large_packet.txt

-s 1000: Opsi ini adalah yang bikin beda. -s adalah singkatan dari "size". Angka 1000 di belakangnya berarti kita ingin mengirim paket ping dengan ukuran 1000 byte. Ukuran default paket ping biasanya lebih kecil dari ini.

Kenapa pakai perintah ini?

• Tes Ukuran Paket: Berguna untuk menguji kemampuan jaringan dalam menangani paket data berukuran besar.

• Masalah MTU: Bisa membantu mendeteksi masalah terkait MTU pada jaringan. Jika paket terlalu besar, router mungkin perlu memecahnya, yang bisa mempengaruhi performa.

Task 4.4: Use telnet to test port 80 on discord.com

sudo apt install telnet
telnet discord.com 80

telnet: Ini adalah nama perintahnya, yaitu program telnet itu sendiri. telnet adalah tool kuno, tapi masih berguna untuk beberapa tujuan.

Perlu diingat bahwa telnet adalah tool yang sangat sederhana. Ia hanya membuat koneksi TCP, tanpa memahami protokol yang lebih tinggi seperti HTTP.

Task 4.5: Use telnet to connect to the SMTP server on port 25

telnet smtp.gmail.com 25

Komando ini mencoba membuat koneksi ke server SMTP (Simple Mail Transfer Protocol) Gmail di smtp.gmail.com melalui port 25 menggunakan tool telnet.

Task 4.6: Use curl to fetch content of https://discord.com

curl https://discord.com -o discord.html

curl: Ini adalah nama perintahnya, yaitu program curl itu sendiri. curl adalah tool serbaguna yang digunakan untuk mentransfer data dari atau ke server menggunakan berbagai protokol, termasuk HTTP

Perintah ini sangat berguna untuk:

• Mengunduh Kode Sumber: Kita bisa melihat bagaimana sebuah halaman web dibuat dengan mengunduh kode sumbernya.

• Web Scraping: Kita bisa mengambil data tertentu dari sebuah halaman web secara otomatis.

• Debugging: Kita bisa melihat error atau masalah yang mungkin terjadi saat load halaman web.

Task 4.7: Use curl with a custom User-Agent

curl -H "User-Agent: MyBrowser" https://google.com
#or
curl -L -H "User-Agent: MyBrowser" https://google.com

-H "User-Agent: MyBrowser": Opsi -H digunakan untuk menambahkan atau memodifikasi header HTTP yang dikirim. Dalam hal ini, kita mengubah header User-Agent menjadi "MyBrowser". User-Agent adalah string yang diidentifikasi browser atau aplikasi yang digunakan untuk mengakses website. Dengan mengubahnya, kita "berpura-pura" menjadi browser lain

-L: Opsi ini adalah yang membedakan kedua perintah ini. -L adalah singkatan dari "location". Opsi ini akan membuat curl mengikuti redirect HTTP jika server mengembalikannya

Task 4.8: Use netstat to list active TCP connections

sudo apt install net-tools
netstat -at

• netstat: Ini adalah nama perintahnya, yaitu program netstat itu sendiri. netstat adalah tool klasik untuk melihat statistik jaringan.

• -a: Opsi ini berarti "all", yang akan menampilkan semua koneksi yang sedang aktif, baik yang berstatus listening (menunggu koneksi masuk) maupun established (sudah terhubung).

• -t: Opsi ini berarti "TCP", yang akan menampilkan koneksi yang menggunakan protokol TCP. TCP adalah protokol yang umum digunakan untuk komunikasi data di internet.

Kenapa pakai perintah ini?

Perintah netstat -at sangat berguna untuk:

• Memantau Koneksi: Kita bisa melihat koneksi apa saja yang sedang aktif di komputer kita, dan ke mana saja komputer kita terhubung.

• Mencari Masalah: Kalau ada masalah dengan jaringan, kita bisa cek dengan perintah ini, mungkin ada koneksi yang mencurigakan atau koneksi yang bermasalah.

• Keamanan: Kita bisa melihat apakah ada koneksi yang tidak dikenal atau mencurigakan, yang mungkin menandakan adanya aktivitas yang tidak diinginkan.

Task 4.9: Use netstat to display all ports that are in the listening state on your system.

netstat -l

-l: Opsi ini berarti "listening", yang akan menampilkan socket yang sedang dalam status listening. Artinya, socket ini sedang menunggu koneksi dari komputer lain.

Kenapa pakai perintah ini?

Perintah netstat -l sangat berguna untuk:

• Mencari Layanan yang Aktif: Kita bisa melihat layanan atau program apa saja yang sedang berjalan di komputer kita dan menunggu koneksi masuk.

• Keamanan: Kita bisa melihat apakah ada socket yang listening yang tidak kita kenal atau mencurigakan, yang mungkin menandakan adanya aktivitas yang tidak diinginkan.

• Troubleshooting: Kalau ada masalah dengan layanan jaringan, kita bisa cek dengan perintah ini, mungkin ada socket yang tidak seharusnya listening atau ada socket yang bermasalah.

Task 4.10: Use iperf in client mode to test the network bandwidth to a remote server (iperf-server.google.com).

sudo apt install iperf
iperf -c iperf.he.net

• iperf: Ini adalah nama perintahnya, yaitu program iperf itu sendiri. iperf adalah tool yang sangat berguna untuk mengukur bandwidth atau kecepatan transfer data dalam jaringan.

• -c: Opsi ini adalah singkatan dari "client". Artinya, kita menjalankan iperf dalam mode client, yaitu sebagai pengirim atau penerima data.

• iperf.he.net: Ini adalah alamat domain atau hostname dari server iperf. Dalam hal ini, kita menggunakan server iperf yang disediakan oleh Hurricane Electric (HE), sebuah penyedia layanan internet.

Task 4.11: Use iperf in server mode to listen for incoming connections on a remote machine (iperf-server.discord.com).

sudo apt install iperf3
iperf3 -s -p 8791

• -s: Opsi ini adalah singkatan dari "server". Artinya, kita menjalankan iperf3 dalam mode server, yaitu sebagai penerima data. Komputer yang menjalankan perintah ini akan menunggu koneksi dari client.

• -p 8791: Opsi ini digunakan untuk menentukan port yang akan digunakan oleh server. Secara default, iperf3 menggunakan port 5201, tapi di sini kita mengubahnya menjadi 8791. Ini berguna jika port default sedang digunakan oleh aplikasi lain, atau jika kita ingin menjalankan beberapa instance iperf3 secara bersamaan.

and client

iperf3 -c 192.168.1.14 -p 8791

• -c: Opsi ini adalah singkatan dari "client". Artinya, kita menjalankan iperf3 dalam mode client, yaitu sebagai pengirim data. Komputer yang menjalankan perintah ini akan terhubung ke server.

• 192.168.1.14: Ini adalah alamat IP dari komputer yang menjalankan server iperf3. Client perlu mengetahui alamat IP server agar bisa terhubung.

• -p 8791: Opsi ini harus sama dengan port yang digunakan oleh server. Karena server menggunakan port 8791, maka client juga harus menggunakan port 8791.

Task 4.12: Use nc (Netcat) to check if port 443 is open on discord.com.

nc -zv discord.com 443

• nc: Ini adalah nama perintahnya, yaitu program nc atau netcat itu sendiri. nc adalah tool serbaguna yang bisa digunakan untuk berbagai macam tugas terkait jaringan, termasuk membuat koneksi TCP atau UDP, listening di port tertentu, dan lain-lain.

• -z: Opsi ini berarti "zero-I/O mode". Artinya, nc tidak akan mengirim atau menerima data apa pun. Kita hanya ingin tahu apakah koneksi bisa dibuat atau tidak.

• -v: Opsi ini berarti "verbose". Artinya, nc akan menampilkan informasi yang lebih detail tentang proses koneksi.

• discord.com: Ini adalah alamat domain atau hostname yang ingin kita tuju. Dalam hal ini, kita mau coba koneksi ke Discord.

• 443: Ini adalah nomor port. Port 443 biasanya digunakan untuk HTTPS, yaitu protokol yang aman untuk browsing web.

Task 4.13: Use nc to send the message Hello, Server! to google.com on port 12345.

#listening
nc -l 12345
#send message
echo "Hello, Server!" | nc localhost 12345

Kedua perintah ini menunjukkan cara menggunakan nc (netcat) untuk komunikasi sederhana antar dua proses di Linux, mirip client-server. Perintah pertama menjalankan nc sebagai server yang "mendengarkan" di port 12345, dan perintah kedua menjalankan nc sebagai client yang mengirim pesan "Hello, Server!" ke server tersebut.

Task 4.14: Use nc to start a simple HTTP server on port 8080 and serve a static HTML file.

echo "<html><body><h1>Hi, mdrdani</h1></body></html>" > index.html

echo "<html><body><h1>Hi, mdrdani</h1></body></html>" > index.html: Perintah ini membuat file index.html dan menuliskan kode HTML sederhana di dalamnya. Tanda > mengalihkan output dari echo ke file index.html.

while true; do (echo -e "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n"; cat index.html) | nc -l 8791; done

• while true: Ini adalah loop tak terbatas. Artinya, web server ini akan terus berjalan sampai kamu hentikan secara manual (biasanya dengan Ctrl+C).

• do: Ini menandai awal dari blok perintah yang akan diulang dalam loop.

• (echo -e "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n"; cat index.html): Bagian ini membuat response HTTP yang akan dikirim ke client.

  • echo -e "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n": Perintah echo dengan opsi -e digunakan untuk menampilkan teks dengan interpretasi escape sequence. Ini membuat header HTTP. HTTP/1.1 200 OK menandakan response sukses. Content-Type: text/html memberitahu browser bahwa kontennya adalah HTML. \r\n adalah carriage return dan line feed, yang menandai akhir baris dalam header HTTP. Dua baris kosong setelah Content-Type menandai akhir header.

  • ;: Tanda titik koma memisahkan dua perintah dalam satu baris.

  • cat index.html: Perintah cat digunakan untuk membaca isi file index.html.

• |: Tanda pipa ini "menyalurkan" output dari perintah di dalam kurung ke perintah selanjutnya.

• nc -l 8791: Perintah nc (netcat) dijalankan dalam mode listening (-l) pada port 8791. Ini akan menerima koneksi dari client (misalnya, browser).

• done: Ini menandai akhir dari blok perintah yang diulang dalam loop.

Task 4.15: Manually query for the domain discord.com.

sudo apt install bind9-dnsutils
dig @8.8.8.8 discord.com

dig (domain information groper) untuk mencari informasi DNS (Domain Name System) tentang discord.com dengan bantuan DNS server publik Google di 8.8.8.8.

Task 3.1: Start a Long-Running Process

sleep 500 &

Jadi, gini, di dunia Linux, kadang kita perlu "menunda" sesuatu. Nah, perintah sleep ini gunanya buat itu, semacam ngasih "jeda" sementara. Angka 500 di sini artinya kita mau nunda selama 500 detik.

Terus, tanda & di belakangnya itu apa? Nah, ini yang bikin seru. Tanda ini artinya kita mau perintah sleep ini jalan di "latar belakang" atau background. Jadi, sementara dia lagi "tidur" selama 500 detik, kita masih bisa tetep ngapa-ngapain di terminal, nggak perlu nungguin dia selesai.

Task 3.2: Simulate CPU and memory usage

stress --cpu 1 --vm 1 --vm-bytes 512M --timeout 30s

Komando ini adalah cara buat "menyiksa" komputer Linux kita, alias memberikan tekanan atau stress test biar kita tahu seberapa kuat dia. stress adalah alat yang populer untuk melakukan pengujian semacam ini.

• stress: Ini adalah nama perintahnya, yaitu program stress itu sendiri.

• --cpu 1: Artinya, kita mau membebani CPU dengan 1 prosesor (atau core). Kalau komputer kamu punya banyak core, kamu bisa ganti angka 1 jadi angka lain sesuai kebutuhan.

• --vm 1: Artinya, kita mau membebani memori virtual (swap) dengan 1 proses.

• --vm-bytes 512M: Nah, ini yang menarik. Kita mau alokasikan 512 Megabyte (M) memori virtual untuk pengujian ini. Jadi, stress akan "pura-pura" menggunakan memori sebanyak ini.

• --timeout 30s: Artinya, kita mau batasi waktu pengujian hanya selama 30 detik. Jadi, setelah 30 detik, stress akan berhenti otomatis.

Kenapa pakai perintah ini?

• Uji Ketahanan: Buat lihat seberapa kuat komputer kita, apakah dia stabil kalau dipaksa kerja keras.

• Cari Masalah: Kadang, kalau ada masalah hardware atau software, baru ketahuan pas komputer lagi "stress".

• Benchmark: Buat membandingkan performa komputer yang berbeda.

Task 3.3: Monitor System Usage

top

sudo apt install htop
htop

Singkatnya, top dan htop adalah alat yang sangat berguna di Linux untuk memantau aktivitas sistem secara real-time. Keduanya menampilkan daftar proses yang sedang berjalan, penggunaan CPU, memori, dan informasi penting lainnya. Anggap saja mereka seperti "jendela" yang menunjukkan apa yang sedang terjadi di dalam komputer Linux kita.

Keduanya menampilkan informasi yang mirip, antara lain:

• Daftar Proses: Menampilkan semua proses yang sedang berjalan di sistem, lengkap dengan ID proses (PID), penggunaan CPU, memori, dan lain-lain.

• Penggunaan CPU: Menunjukkan berapa persen CPU yang sedang digunakan.

• Penggunaan Memori: Menunjukkan berapa banyak memori (RAM) yang sedang digunakan.

• Waktu Sistem: Menunjukkan sudah berapa lama sistem berjalan.

Task 3.4: Verify the sleep process

ps -aux | grep sleep

• ps -aux: Perintah ps digunakan untuk menampilkan informasi tentang proses yang sedang berjalan. Opsi -aux memberikan informasi yang lebih lengkap dan detail, termasuk semua proses (baik yang dimiliki oleh pengguna maupun sistem), dalam format yang mudah dibaca.

• grep sleep: Perintah grep digunakan untuk mencari pola teks tertentu dalam output dari perintah lain. Dalam hal ini, kita mencari kata "sleep".

• Tanda | (pipa) di antara kedua perintah tersebut berfungsi untuk "menyalurkan" output dari perintah ps -aux ke perintah grep sleep. Jadi, grep sleep akan mencari baris yang mengandung kata "sleep" dalam output dari ps -aux.

Kenapa pakai perintah ini?

Perintah ini sangat berguna untuk mencari proses yang berkaitan dengan perintah sleep. Misalnya, kamu ingin melihat apakah ada proses sleep yang sedang berjalan, atau kamu ingin mencari tahu berapa lama proses sleep tersebut sudah berjalan.

Task 3.5: Check disk space usage

df -h

du -h /home/sdb/ | sort -hr | head -n 10

• df -h: Perintah df digunakan untuk menampilkan informasi tentang penggunaan ruang disk pada sistem. Opsi -h membuat ukuran ditampilkan dalam format yang mudah dibaca (misalnya, KB, MB, GB). Namun, perintah ini tidak akan membantu kita melihat ukuran per folder.

• du -h /home/sdb/: Perintah du digunakan untuk menampilkan penggunaan ruang disk per file dan direktori. Opsi -h sama seperti di df, membuat ukuran ditampilkan dalam format yang mudah dibaca. /home/sdb/ adalah jalur folder yang ingin kita analisis.

• |: Tanda pipa ini berfungsi untuk "menyalurkan" output dari perintah sebelumnya ke perintah selanjutnya.

• sort -hr: Perintah sort digunakan untuk mengurutkan baris teks. Opsi -h mengurutkan berdasarkan ukuran yang mudah dibaca (misalnya, 10M lebih besar dari 2K), dan -r membalik urutan (dari terbesar ke terkecil).

• head -n 10: Perintah head digunakan untuk menampilkan beberapa baris pertama dari input. Opsi -n 10 berarti kita hanya ingin menampilkan 10 baris pertama.

Kenapa pakai perintah ini?

Perintah ini sangat berguna untuk mencari folder atau file mana yang memakan ruang disk paling banyak. Dengan begitu, kita bisa tahu folder atau file mana yang bisa dihapus atau dipindahkan untuk mengosongkan ruang disk.

Task 3.6: Monitor Memory Usage

free -h

Komando free -h adalah perintah sederhana di Linux yang digunakan untuk menampilkan informasi tentang penggunaan memori sistem, baik memori fisik (RAM) maupun memori swap. Opsi -h membuat outputnya lebih mudah dibaca oleh manusia.

Task 3.7: Log High CPU Usage Processes

while true; do ps -aux | awk '$3 > 10 {print $0}' >> high_cpu.log; sleep 5; done

• while true: Ini adalah awal dari loop tak terbatas. Artinya, perintah-perintah di dalam loop akan terus diulang sampai kita menghentikannya secara manual (biasanya dengan Ctrl+C).

• do: Ini menandai awal dari blok perintah yang akan diulang.

• ps -aux: Seperti yang sudah dibahas sebelumnya, perintah ini menampilkan informasi lengkap tentang semua proses yang sedang berjalan.

• |: Tanda pipa ini "menyalurkan" output dari ps -aux ke perintah selanjutnya.

• awk '$3 > 10 {print $0}': Perintah awk digunakan untuk memfilter dan memproses teks. Dalam hal ini, kita memfilter baris-baris dari output ps -aux yang kolom ketiganya ($3, yang biasanya menunjukkan persentase penggunaan CPU) lebih besar dari 10. {print $0} mencetak seluruh baris jika kondisinya terpenuhi.

• >> high_cpu.log: Tanda >> digunakan untuk append (menambahkan) output dari perintah awk ke file high_cpu.log. Jadi, setiap kali ada proses yang CPU-nya di atas 10%, informasinya akan ditambahkan ke file ini.

• sleep 5: Perintah ini akan menunda eksekusi selama 5 detik. Jadi, loop akan berjalan setiap 5 detik.

• done: Ini menandai akhir dari blok perintah yang akan diulang.

Kenapa pakai perintah ini?

Perintah ini berguna untuk memantau proses-proses yang "rakus" CPU. Kita bisa melihat proses mana saja yang menggunakan CPU di atas ambang batas tertentu (dalam hal ini 10%) dan menganalisisnya.

Task 3.8: Kill the long-running process

kill <PID>

Komando kill di Linux digunakan untuk mengakhiri atau "membunuh" sebuah proses yang sedang berjalan. <PID> adalah Process ID, yaitu nomor unik yang diberikan oleh sistem ke setiap proses yang sedang berjalan.

• kill: Ini adalah nama perintahnya, yaitu program kill itu sendiri.

• <PID>: Ini adalah Process ID dari proses yang ingin kita akhiri. Kita perlu mengganti <PID> dengan nomor PID yang sebenarnya.

Cara Mendapatkan PID

Sebelum menggunakan perintah kill, kita perlu tahu dulu PID dari proses yang ingin kita akhiri. Ada beberapa cara untuk mendapatkan PID, antara lain:

• Menggunakan perintah top atau htop: Kedua perintah ini menampilkan daftar proses yang sedang berjalan, lengkap dengan PID-nya.

• Menggunakan perintah ps aux: Perintah ini juga menampilkan daftar proses, dan kita bisa mencari PID dari proses yang ingin kita akhiri.

Task 2.1: Generate a Fake Log File

go install github.com/mingrammer/flog@latest

flog: Ini adalah nama aplikasi yang mau kita instal. flog adalah tool atau alat yang berguna untuk membuat fake log, alias log palsu. Biasanya dipakai untuk testing atau simulasi. Karena flog ini dibuat menggunakan bahasa pemrograman Go, maka kita butuh tool "Go" untuk memasangnya.

cd go/bin
./flog -s 10s -n 200 > /home/sdb/access.log

Bagian 1: cd go/bin

• cd: Ini singkatan dari "change directory" alias "pindah folder". Jadi, perintah ini digunakan untuk berpindah dari folder tempat kita berada sekarang ke folder lain.

• go/bin: Ini adalah "alamat" atau lokasi folder yang ingin kita tuju. Dalam hal ini, kita mau pindah ke folder bin yang ada di dalam folder go. Biasanya, di folder bin ini terdapat file-file program yang bisa dijalankan.

Jadi, bagian ini intinya adalah: Berpindah ke folder go/bin.

Bagian 2: ./flog -s 10s -n 200 > /home/sdb/access.log

• ./flog: Ini adalah perintah untuk menjalankan program flog. Tanda ./ di depan flog artinya program flog tersebut ada di folder tempat kita berada sekarang (yaitu folder go/bin).

• -s 10s: Opsi -s ini artinya "seconds" alias detik. Jadi, kita mau flog menghasilkan log setiap 10 detik.

• -n 200: Opsi -n ini artinya "number" alias jumlah. Jadi, kita mau flog menghasilkan 200 baris log.

• >: Nah, ini nih yang penting. Tanda > ini artinya kita mau "mengarahkan" output dari perintah flog ke sebuah file. Jadi, log yang dihasilkan tidak hanya ditampilkan di layar, tetapi juga disimpan di dalam sebuah file.

• /home/sdb/access.log: Ini adalah "alamat" lengkap file tempat kita menyimpan log yang dihasilkan oleh flog. Dalam hal ini, kita menyimpannya di dalam file access.log yang ada di folder sdb di dalam folder home.

Task 2.2: Extract unique IP Address

awk '{print $1}' access.log | sort | uniq

• awk: Ini adalah program yang sangat berguna untuk memproses teks. awk bekerja dengan membaca file baris per baris, dan kita bisa menentukan apa yang ingin kita lakukan untuk setiap barisnya.

• '{print $1}': Ini adalah "instruksi" untuk awk. print $1 artinya kita mau menampilkan kata pertama dari setiap baris. Dalam file access.log, biasanya kata pertama ini berisi IP address atau alamat server yang mengakses.

• access.log: Ini adalah nama file yang berisi log akses.

• sort: Ini adalah perintah untuk mengurutkan teks. Secara default, sort akan mengurutkan teks secara alfabetis.

• uniq: Ini adalah perintah untuk menampilkan baris-baris unik. Jadi, kalau ada IP address yang muncul berkali-kali, uniq hanya akan menampilkannya sekali.

Task 2.3: Count Accurrence of each IP Address

awk '{print $1}' access.log | sort | uniq -c | sort -nr > ip_counts.txt

• uniq: Ini adalah perintah untuk menampilkan baris-baris unik. Jadi, kalau ada IP address yang muncul berkali-kali, uniq hanya akan menampilkannya sekali.

• -c: Opsi -c ini artinya "count" alias hitung. Jadi, selain menampilkan IP address yang unik, uniq juga akan menampilkan berapa kali IP address tersebut muncul.

• sort: Sama seperti sebelumnya, ini adalah perintah untuk mengurutkan teks.

• -n: Opsi -n ini artinya "numeric" alias angka. Jadi, kita mau mengurutkan berdasarkan angka, bukan alfabet.

• -r: Opsi -r ini artinya "reverse" alias terbalik. Jadi, kita mau mengurutkan dari angka terbesar ke angka terkecil.

Task 2.4: Filter Log Entries with status Code 404

grep " 404 " access.log > errors.log

• grep: Nah, kalau grep ini kayak detektif yang lagi nyari sesuatu di dalam teks. Dia bakal nyari baris-baris yang mengandung kata atau pola tertentu.

• " 404 ": Ini adalah "target" yang mau dicari oleh grep. Dalam hal ini, kita mau mencari baris yang mengandung kode "404". Kode "404" ini biasanya muncul di log akses website dan menandakan bahwa halaman yang diminta tidak ditemukan alias "error".

• access.log: Ini adalah nama file yang akan "diperiksa" oleh grep. Jadi, grep akan mencari kode "404" di dalam file access.log.

• >: Nah, ini nih yang penting. Tanda > ini artinya kita mau "mengarahkan" output dari perintah grep ke sebuah file. Jadi, baris-baris yang mengandung kode "404" tidak hanya ditampilkan di layar, tetapi juga disimpan di dalam sebuah file.

• errors.log: Ini adalah nama file tempat kita menyimpan baris-baris yang mengandung kode "404".

Task 2.5: Replace Mozilla with BrowserX

sed 's/Mozilla/BrowserX/g' access.log > access_modified.log

• sed: Nah, kalau sed ini kayak editor teks otomatis. Dia bisa mencari dan mengganti teks di dalam file secara otomatis, tanpa perlu kita buka filenya satu per satu.

• 's/Mozilla/BrowserX/g': Ini adalah "instruksi" untuk sed. Mari kita pecah lagi:

  • s: Ini singkatan dari "substitute" alias "ganti". Jadi, kita mau mengganti teks.

  • /Mozilla/: Ini adalah teks yang mau kita cari atau ganti. Dalam hal ini, kita mau mencari kata "Mozilla".

  • /BrowserX/: Ini adalah teks penggantinya. Jadi, kata "Mozilla" akan diganti dengan "BrowserX".

  • g: Ini artinya "global". Jadi, semua kemunculan kata "Mozilla" di setiap baris akan diganti, bukan hanya yang pertama saja.

• access.log: Ini adalah nama file yang akan "diedit" oleh sed. Jadi, sed akan mencari dan mengganti teks di dalam file access.log.

• >: Nah, ini nih yang penting. Tanda > ini artinya kita mau "mengarahkan" output dari perintah sed ke sebuah file baru. Jadi, hasil editan tidak langsung mengubah file access.log aslinya, tetapi disimpan di file baru.

• access_modified.log: Ini adalah nama file baru yang akan berisi teks yang sudah dimodifikasi.

Task 2.6: Extract Log Entries froom a Spesific Date

 grep "06/Feb/2025" access.log > specific_date.log

• grep: Perintah untuk mencari pola teks dalam file.

• "06/Feb/2025": Pola teks yang dicari. Dalam hal ini, kita mencari baris yang mengandung tanggal "06/Feb/2025". Perhatikan bahwa format tanggal ini harus sama persis dengan yang ada di file access.log Anda.

• access.log: Nama file yang akan dicari.

• >: Operator redirection yang mengarahkan output dari perintah grep ke file lain.

• specific_date.log: Nama file baru yang akan berisi baris-baris yang cocok dengan pola yang dicari.

Task 2.7: Calculate Total Bytes Transferred

awk '{sum += $10} END {print sum}' access.log

• sum += $10: Ini artinya kita membuat sebuah variabel bernama sum dan menambahkan nilai dari kolom ke-10 ($10) ke variabel sum tersebut. Jadi, sum akan menyimpan total dari nilai-nilai di kolom ke-10.

• Kolom ke-10 di file access.log Anda kemungkinan besar berisi ukuran response dalam byte.

• 'END {print sum}': Ini juga "instruksi" untuk awk.

  • END: Ini artinya perintah di dalam kurung kurawal akan dieksekusi setelah awk selesai membaca seluruh file.

  • print sum: Ini artinya kita mau menampilkan nilai dari variabel sum, yaitu total dari ukuran response.

Task 2.8: Find IP with the Most 404 Errors

grep ' 404 ' access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 1 > top_404_ip.txt

• grep ' 404 ' access.log:

  • grep: Ini adalah perintah untuk mencari pola teks dalam file.

  • ' 404 ': Pola teks yang dicari. Kita mencari baris yang mengandung kode "404". Kode ini biasanya menunjukkan error "Not Found" di log akses web.

  • access.log: Nama file log yang akan dicari.

  • Intinya: Mencari semua baris di access.log yang mengandung "404".

• awk '{print $1}':

  • awk: Program untuk memproses teks per baris.

  • '{print $1}': Instruksi untuk awk. $1 artinya kolom pertama dari setiap baris. Biasanya, di log akses web, kolom pertama ini berisi alamat IP.

  • Intinya: Mengambil alamat IP dari setiap baris yang dihasilkan oleh grep.

• sort:

  • sort: Perintah untuk mengurutkan teks. Secara default, ia mengurutkan berdasarkan abjad.

  • Intinya: Mengurutkan daftar alamat IP.

• uniq -c:

  • uniq: Perintah untuk menampilkan baris-baris unik.

  • -c: Opsi untuk menghitung berapa kali setiap baris muncul.

  • Intinya: Menghitung berapa kali setiap alamat IP muncul (berapa kali setiap IP menghasilkan error 404).

• sort -nr:

  • sort: Perintah untuk mengurutkan teks.

  • -n: Opsi untuk mengurutkan secara numerik (bukan abjad).

  • -r: Opsi untuk membalik urutan (dari terbesar ke terkecil).

  • Intinya: Mengurutkan alamat IP berdasarkan jumlah kemunculannya, dari yang paling sering muncul.

• head -n 1:

  • head: Perintah untuk menampilkan beberapa baris pertama dari sebuah file atau output.

  • -n 1: Opsi untuk menampilkan hanya 1 baris.

  • Intinya: Mengambil alamat IP yang paling sering menghasilkan error 404.

• >:

  • >: Operator redirection untuk mengarahkan output ke sebuah file.

  • top_404_ip.txt: Nama file yang akan menyimpan output.

  • Intinya: Menyimpan alamat IP yang paling sering menghasilkan error 404 ke dalam file top_404_ip.txt.

Task 2.9: Anonymize All IP Address

sed -E 's/^[^ ]+/ANONYMIZED_IP/' access.log > access_anonymized.log

's/^[^ ]+/ANONYMIZED_IP/': Ini adalah "instruksi" untuk sed. Mari kita bedah lagi:

• s: Ini singkatan dari "substitute" alias "ganti". Jadi, kita mau mengganti teks.

• ^: Ini artinya "awal baris". Jadi, kita mau mencari teks yang ada di awal baris.

• [^ ]+: Ini adalah pola teks yang mau kita cari. [^ ] artinya "semua karakter kecuali spasi". + artinya "satu atau lebih kemunculan". Jadi, [^ ]+ artinya satu atau lebih karakter yang bukan spasi. Karena ada ^ di depannya, berarti kita mencari satu atau lebih karakter bukan spasi yang ada di awal baris. Biasanya, di log akses web, bagian ini adalah alamat IP.

• /ANONYMIZED_IP/: Ini adalah teks penggantinya. Jadi, teks yang cocok dengan pola ^[^ ]+ (yaitu alamat IP di awal baris) akan diganti dengan "ANONYMIZED_IP".

Task 2.10: Count Log Entries with 500 status code

grep " 500 " access.log | wc -l

• wc: Ini adalah perintah untuk menghitung jumlah kata, baris, dan karakter dalam sebuah file atau input.

• -l: Opsi untuk menghitung jumlah baris.

• Intinya: Menghitung jumlah baris yang diberikan sebagai input. Dalam hal ini, inputnya adalah output dari perintah grep.

Sebelum menjalankan perintah pertama, kita perlu memasang flog untuk menghasilkan log palsu dan stress untuk mensimulasikan beban CPU dan memori. Saya juga memasang tree untuk mempermudah visualisasi struktur direktori.

https://github.com/mingrammer/flog

sudo apt install stress
sudo apt install tree

Task 1.1: Create the following directory structure:

mkdir -p project/reports/2024 project/reports/2025 project/scripts project/data

Task 1.2: Create empty files in reports/2024

touch project/reports/2024/q1.txt
touch project/reports/2024/q2.txt
touch project/reports/2024/q3.txt

Kita bisa pakai perintah touch buat bikin file. Perintah ls digunakan untuk menampilkan daftar berkas dan direktori. Berikut penjelasan opsi yang digunakan:

• -l: Menampilkan daftar dalam format long listing (panjang), yang memberikan informasi detail seperti izin berkas, pemilik, grup, ukuran, tanggal modifikasi, dan nama berkas.

• -h: Menampilkan ukuran berkas dalam format human-readable (mudah dibaca manusia), misalnya KB, MB, atau GB, bukan dalam byte.

• -t: Mengurutkan daftar berdasarkan waktu modifikasi terakhir.

Jadi, ls -lht akan menampilkan daftar berkas dan direktori dalam format panjang, dengan ukuran yang mudah dibaca, dan diurutkan berdasarkan waktu modifikasi terakhir.

Penjelasan File Permission (Izin Berkas) di Linux:

Izin berkas di Linux mengatur siapa yang boleh melakukan apa terhadap suatu berkas. Izin ini direpresentasikan dalam sepuluh karakter, contohnya -rw-rw-r--.

• Karakter pertama (-): Menunjukkan jenis berkas. - berarti berkas biasa, d berarti direktori, l berarti symbolic link, dan lainnya.

• Sembilan karakter berikutnya dibagi menjadi tiga kelompok, masing-masing untuk owner (pemilik), group (kelompok), dan others (lainnya).

• Setiap kelompok memiliki tiga bit:

  • r: Read (baca) - Izin untuk membaca isi berkas.

  • w: Write (tulis) - Izin untuk mengubah atau menghapus isi berkas.

  • x: Execute (eksekusi) - Izin untuk menjalankan berkas (jika berkas tersebut adalah program yang dapat dieksekusi).

• Tanda - berarti izin tersebut tidak diberikan.

Dalam contoh -rw-rw-r--:

• Owner: Memiliki izin baca (r) dan tulis (w), tetapi tidak memiliki izin eksekusi (-).

• Group: Memiliki izin baca (r) dan tulis (w), tetapi tidak memiliki izin eksekusi (-).

• Others: Memiliki izin baca (r), tetapi tidak memiliki izin tulis (-) dan eksekusi (-).

Task 1.3: Move q1.txt to 2025

mv project/reports/2024/q1.txt project/reports/2025/

mv itu artinya "move" alias mindahin. Nah, biar nggak nyasar, mending tulis perintah lengkap sama alamat lengkap filenya, jangan cuma q1.txt doang. Kalau tiba-tiba muncul pesan "No such file or directory", itu biasanya gara-gara alamat filenya salah.

Task 1.4: Copy q2.txt to scripts dan rename menjadi analysis.txt

cp project/reports/2024/q1.txt project/scripts/analysis.txt

Task 1.5: list files in 2025 and save output to file file_list.log

ls project/reports/2025 > file_list.log

Task 1.6: Append Task Completed to q3.txt

echo "Task Completed" >> project/reports/2024/q3.txt
cat project/reports/2024/q3.txt

• echo "Task Completed": Nah, bagian ini artinya kita mau "ngomong" atau "nulis" kalimat "Task Completed". echo itu kayak perintah buat nampilin sesuatu di layar, tapi di sini kita mau tampilinnya di dalam file.

• >>: Tanda ini nih yang penting. Ini artinya kita mau "nambahin" tulisan "Task Completed" tadi ke dalam file. Jadi, kalau di file udah ada tulisan lain, tulisan "Task Completed" ini bakal ditaruh di baris baru, di bawah tulisan yang lama. Beda kalau kita pakai tanda >, kalau pakai ini, tulisan yang lama di file akan dihapus dan diganti dengan tulisan "Task Completed".

• cat: Nah, kalau cat ini kayak baca buku. Dia bakal nampilin isi file ke layar.

Task 1.7: Display directory structure and save to structure.log

tree project/ > structure.log

tree: Nah, perintah tree ini kayak tukang kebun yang rapi banget. Dia bakal nunjukin struktur folder dan file kita dalam bentuk pohon, lengkap dengan cabang-cabangnya. Jadi, kita bisa lihat dengan jelas, file ini ada di dalam folder apa, folder itu ada di dalam folder apa lagi, dan seterusnya.

Task 1.8: Delete analysis.txt and confirm

 rm project/scripts/analysis.txt

rm: Nah, kalau rm ini artinya "remove" alias hapus. Jadi, perintah ini digunakan untuk menghapus file atau folder.

Task 1.9: Copy the entire project directory

 cp -r project/ project-old

• cp: Nah, kalau cp ini artinya "copy" alias salin. Jadi, perintah ini digunakan untuk menyalin file atau folder.

• -r: Opsi -r ini singkatan dari "recursive". Artinya, kalau yang disalin itu folder, maka semua isinya (termasuk subfolder dan file-file di dalamnya) juga ikut disalin.

• project/: Ini adalah lokasi folder yang mau kita salin. Dalam contoh ini, kita mau menyalin folder project/ beserta seluruh isinya.

• project-old: Ini adalah nama folder baru hasil salinan. Jadi, kita akan membuat folder baru bernama project-old yang isinya sama persis dengan folder project/.

Task 1.10: Delete Original project

rm -ri project

• rm: Nah, kalau rm ini artinya "remove" alias hapus. Jadi, perintah ini digunakan untuk menghapus file atau folder.

• -r: Opsi -r ini singkatan dari "recursive". Artinya, kalau yang dihapus itu folder, maka semua isinya (termasuk subfolder dan file-file di dalamnya) juga ikut dihapus.

• -i: Opsi -i ini singkatan dari "interactive". Artinya, sebelum menghapus setiap file atau folder, perintah ini akan bertanya dulu ke kita, "Yakin mau dihapus nggak nih?". Jadi, kita punya kesempatan untuk berpikir ulang sebelum file atau folder benar-benar hilang.

• project: Ini adalah nama folder yang mau kita hapus beserta seluruh isinya.

Task 1.11: Create a 5GB file

truncate -s 5G large_file.dat

• truncate: Nah, kalau truncate ini artinya "memotong" atau "memangkas". Perintah ini digunakan untuk mengubah ukuran file, bisa memperbesar atau memperkecil.

• -s 5G: Opsi -s ini digunakan untuk menentukan ukuran file yang baru. Dalam contoh ini, kita mau membuat ukuran file menjadi 5 Gigabyte (5G). Kamu bisa menggunakan satuan lain seperti K (Kilobyte), M (Megabyte), atau G (Gigabyte).

• large_file.dat: Ini adalah nama file yang ukurannya mau kita ubah.

Tentang Traefik

Traefik adalah reverse proxy dan load balancer modern yang dirancang untuk mengelola lalu lintas web di dalam infrastruktur berbasis microservices. Traefik mendukung integrasi langsung dengan berbagai sistem orkestrasi seperti Docker, Kubernetes, dan lainnya, serta menyediakan fitur-fitur canggih untuk memudahkan pengelolaan lalu lintas aplikasi.

Apa itu Reverse Proxy

Reverse proxy adalah server yang duduk di depan satu atau lebih server backend. Tugasnya adalah menerima permintaan dari klien (misalnya, browser pengguna), meneruskannya ke server backend yang sesuai, dan mengirimkan respons kembali ke klien. Dengan reverse proxy, kita bisa:

• Menyembunyikan detail server backend.

• Membagi beban lalu lintas ke beberapa server backend.

• Menambahkan fitur keamanan seperti TLS/SSL.

Traefik bertindak sebagai reverse proxy untuk layanan-layanan Anda.

Fitur Utama Traefik

a. Integrasi Otomatis dengan Orkestrasi Kontainer

Traefik dapat secara otomatis mendeteksi dan mengatur rute untuk layanan yang berjalan di dalam sistem orkestrasi seperti Docker, Kubernetes, Nomad, atau Swarm. Anda tidak perlu secara manual mendefinisikan rute atau memuat ulang konfigurasinya.

b. TLS Termination (HTTPS)

Traefik mendukung TLS termination, yaitu proses mendekripsi lalu lintas HTTPS di sisi Traefik sebelum diteruskan ke server backend. Ini memungkinkan backend Anda tetap berjalan di HTTP biasa. Traefik juga mendukung integrasi dengan Let's Encrypt untuk mengelola sertifikat TLS otomatis.

c. Routing Dinamis

Traefik memungkinkan Anda untuk mendefinisikan rute secara dinamis menggunakan berbagai aturan:

• Berdasarkan host (contoh: Host(app.example.com)).

• Berdasarkan jalur (contoh: Path(/api)).

• Kombinasi aturan lainnya.

d. Middlewares

Middlewares memungkinkan Anda untuk memodifikasi lalu lintas sebelum diteruskan ke server backend. Contoh middleware:

• Redirect Scheme: Mengarahkan HTTP ke HTTPS.

• Rate Limiting: Membatasi jumlah permintaan.

• Authentication: Menambahkan otentikasi dasar untuk layanan tertentu.

e. Load Balancing

Traefik mendukung berbagai algoritma load balancing (round-robin, least connections, dll.) untuk mendistribusikan lalu lintas ke beberapa server backend.

f. Dashboard

Traefik menyediakan dashboard berbasis web yang memungkinkan Anda memantau status rute, middleware, dan layanan.

g. Plug-and-Play

Traefik mendukung banyak protokol seperti HTTP, HTTPS, TCP, dan UDP secara native, sehingga sangat fleksibel.

Setup Traefik in docker-compose

docker-compose.yaml

version: '3.9'

services:
  traefik:
    image: traefik:v2.10
    container_name: traefik
    command:
      - '--api.insecure=true' # Enables the Traefik dashboard
      - '--providers.docker=true'
      - '--providers.file.directory=/etc/traefik/dynamic'
      - '--entrypoints.web.address=:80'
      - '--entrypoints.websecure.address=:443'
      - '--entrypoints.websecure.http.tls=true'
    ports:
      - '80:80'
      - '443:443'
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./certs:/certs
      - ./dynamic:/etc/traefik/dynamic
    labels:
      - 'traefik.enable=true'
      - 'traefik.http.routers.traefik.rule=Host(`traefik.docker.localhost`)'
      - 'traefik.http.routers.traefik.service=api@internal'
      - 'traefik.http.routers.traefik.tls=true'
    networks:
      - frontend
    restart: always

  nginx:
    image: nginx:latest
    container_name: nginx
    labels:
      - 'traefik.enable=true'
      - 'traefik.http.routers.nginx.rule=Host(`app.docker.localhost`)'
      - 'traefik.http.routers.nginx.entrypoints=websecure'
      - 'traefik.http.routers.nginx.tls=true'
      - 'traefik.http.services.nginx.loadbalancer.server.port=80'
    networks:
      - frontend
    restart: always

  nginxtwo:
    image: nginx:latest
    container_name: nginxtwo
    labels:
      - 'traefik.enable=true'
      - 'traefik.http.routers.nginxtwo.rule=Host(`apptwo.docker.localhost`)'
      - 'traefik.http.routers.nginxtwo.entrypoints=websecure'
      - 'traefik.http.routers.nginxtwo.tls=true'
      - 'traefik.http.services.nginxtwo.loadbalancer.server.port=80'
    networks:
      - frontend
    restart: always

networks:
  frontend:
    external: true

buat networks agar semua aplikasi menjadi satu network

$ docker network create frontend

selanjutnya kita setting domain localhost

$ sudo nano /etc/hosts

tambahkan domain local

• traefik.docker.localhost

• app.docker.localhost

• apptwo.docker.localhost

Adding SSL certificates for localhost

Jika sudah setting domain local, selanjutnya generate local SSL dengan mkcert.

untuk ubuntu dapat menginstall dengan

$ sudo apt install mkcert libnss3-tools

$ mkdir cert
$ cd cert
$ mkcert -install
$ mkcert traefik.docker.localhost
$ mkcert app.docker.localhost
$ mkcert apptwo.docker.localhost

Basic Traefik configuration walkthrough

selanjutnya kita buat dynamic configuration file.

$ mkdir dynamic
$ touch tls.yml

# dynamic/tls.yml
tls:
  certificates:
    - certFile: /certs/traefik.docker.localhost.pem
      keyFile: /certs/traefik.docker.localhost-key.pem
    - certFile: /certs/app.docker.localhost.pem
      keyFile: /certs/app.docker.localhost-key.pem
    - certFile: /certs/apptwo.docker.localhost.pem
      keyFile: /certs/apptwo.docker.localhost-key.pem

Run Traefik

//jika ingin melihat log tidak berjalan di background
$ docker compose up
//jika ingin lgsung berjalan di background
$ docker compose up -d

kita check di browser

thanks

Dalam praktek lapangan kita akan banyak menjalankan banyak module/tugas sekaligus, di sini untuk mempermudah masalah ini kita bisa menggunakan Ansible Playbook dimana kita mendefinisikan banyak module dalam satu file YAML.

Oke selanjutnya kita coba buat file Ansible Playbook yang tugas awal ini kita menginstall Web server Nginx dan menjalankan file index.html,buatlah file dengan nama playbook-webserver.yaml.

- name: Playbook setup web server
  hosts: server_test
  become: true
  become_method: sudo
  tasks:
    - name: Update repository
      ansible.builtin.apt:
        update_cache: true
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
    - name: Start Nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
    - name: Copy file html
      ansible.builtin.copy:
        src: ./web/
        dest: /var/www/html/
        mode: '604'

jika sudah di buat jalankan dengan perintah

ansible-playbook playbook-webserver.yaml

Ansible Playbook Variables

Terkadang kita memerlukan konfigurasi kepada hal yang sama, contoh kita membuat nama user pada **task 1,**pada task ke 2 kita membuat grub dengan nama user yang sama kita dapat membuat nya sebagai variables untuk mendefinisikan sekali saja.

playbook-webserver-vars.yaml

- name: Playbook setup web server
  hosts: server_test
  become: true
  vars: # mendefinisikan variable
    user_app: ansibleweb
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
    - name: Buat User {{ user_app }}
      ansible.builtin.user:
        name: "{{ user_app }}"
        password: belajaransible
        shell: /bin/bash
    - name: Copy file html
      ansible.builtin.copy:
        src: ./web/
        dest: /var/www/html/
        mode: '604'
        owner: "{{ user_app }}"
        group: "{{ user_app }}"

ansible-playbook playbook-webserver-vars.yaml

terlihat file index.html sudah kita rubah owner menggunakan user ansibleweb dan group ansibleweb.

karena playbook menggunakan format YAML sebenarnya kita bisa menggunakan variable dalam bentuk boolean, list dan dictionary jika dibutuhkan.

Ansible Conditional

Terkadang pada kondisi tertentu kita menemui task yang bisa menyesuaikan keadaan yang kita tuliskan di playbook. Contoh menginstall Nginx di distro Ubuntu/debian menggunakan APT, namun jika di distro centos/redhat meggunakan YUM.

Ansible memiliki kemampuan untuk membuat semacam "if-else" di pemrograman yang bernama Conditional.

Sama seperti if conditionals pada umumnya kita dapat menggunakan operasi logical operator seperti and, or, not dan comparision operator seperti >=, <=,==

playbook-webserver-when.yaml

---
- name: Playbook setup web server
  hosts: server_test
  become: true
  gather_facts: true # defaultnya memang true
  vars: # mendefinisikan variable
    user_app: ansibleweb
  tasks:

    ## Install nginx
    - name: Install nginx (Debian)
      ansible.builtin.apt:
        name: nginx
        state: present
      when:
        - ansible_os_family == "Debian"
        - ansible_processor_cores >= 0.25 or ansible_memory_mb.real.total >= 512
    - name: Install nginx (Alpine)
      community.general.apk:
        name: nginx
        state: present
      when:
        - ansible_os_family == "Alpine"
        - ansible_processor_cores >= 0.25 or ansible_memory_mb.real.total >= 512

    ## Buat user
    - name: Buat user (Debian) {{ user_app }}
      ansible.builtin.user:
        name: "{{ user_app }}"
        password: belajaransible
        shell: /bin/bash
      when:
        - ansible_os_family == "Debian"
    - name: Buat user (Alpine) {{ user_app }}
      ansible.builtin.user:
        name: "{{ user_app }}"
        password: belajaransible
        shell: /bin/sh
      when:
        - ansible_os_family == "Alpine"

    ## Copy file html
    - name: Copy file html (Debian)
      ansible.builtin.copy:
        src: ./web/
        dest: /var/www/html/
        mode: '604'
        owner: "{{ user_app }}"
        group: "{{ user_app }}"
      when:
        - ansible_os_family == "Debian"
    - name: Copy file html (Alpine)
      ansible.builtin.copy:
        src: ./web/
        dest: /usr/share/nginx/html
        mode: '604'
        owner: "{{ user_app }}"
        group: "{{ user_app }}"
      when:
        - ansible_os_family == "Alpine"

ansible-playbook playbook-webserver-when.yaml

Secara default saat menjalankan playbook, Ansible akan mengambil informasi dari server tujuan terelebih dahulu sebelum mejalankan task yang akan dikerjakan.

Informasi tersebut diambil dan di simpan dalam sebuah variable yang dinamakan Facts. Jika ingin mengececek Facts secara manual untuk melihat informasi bisa menggunakan perintah ansible <pattern/host> -m ansible.builtin.setup.

ansible server_test -m ansible.builtin.setup

Terkadang kita hanya ingin menjalankan task task tersentu yang ada di suatu playbook. Misal kita sudah menginstall web server nginx, jadi kita hanya ingin menjalankan task copy file html untuk menghemat waktu.

Untuk mengatasi ini kita dapat menggunakan Tags.

untuk menjalankan nya kita dapat menggunakan command

ansible-playbook playbook-webserver-when.yaml --check --tags copy_file

atau bisa skip task selain yang di tentukan

ansible-playbook playbook-webserver-when.yaml --check --skip-tags copy_file

Ansible Loops

Pada ansible ada yang nama nya Loops, yang guna nya untuk menghindari duplikasi atau redundan dari konfigurasi YAML kita.

Contoh kita install php8.2, php8.2-cli, dll, nah ini kita membuat 3 task untuk menginstall 3 package tersebut.

playbook-php-loop.yaml

---
- name: Playbook setup PHP
  hosts: server_belajar
  become: true
  gather_facts: true # defaultnya memang true
  vars:
    taget_php_version: 8.2
  tasks:
    - name: Add repository for PHP
      ansible.builtin.apt_repository:
        repo: 'ppa:ondrej/php'
        state: present
      tags: prepare

    - name: Update repo
      ansible.builtin.apt:
        update_cache: true
      tags: prepare

    - name: Install php {{ taget_php_version }}
      ansible.builtin.apt:
        name: "{{ item }}"
        state: present
      with_items:
        - php{{ taget_php_version }}
        - php{{ taget_php_version }}-cli
        - php{{ taget_php_version }}-common
        - php{{ taget_php_version }}-imap
        - php{{ taget_php_version }}-redis
        - php{{ taget_php_version }}-xml
        - php{{ taget_php_version }}-zip
        - php{{ taget_php_version }}-mbstring
        - php{{ taget_php_version }}-curl
        - php{{ taget_php_version }}-gd
        - php{{ taget_php_version }}-bcmath
        - php{{ taget_php_version }}-gmp
        - php{{ taget_php_version }}-mysqli
      tags:
        - install

ansible-playbook playbook-php-loop.yaml

Ansible Vault

Pada Playbook sebelumnya kita membuat user beserta password secara transparan, menulis informasi yang sensitif tidak di izinkan apalagi jika di production.

Untuk memproteksi hal yang sifatnya sensitif sebaiknya kita menggunakan Vault di ansible. Dengan menggunakan Vault data2 yang senstif tersebut akan di enkripsi sehingga jauh lebih aman.

ansible-vault create secret-user.yaml

nanti akan terbentuk file baru dengan nama secret-user.yaml yang isinya akan angka acak seperti ini.

Setelah kita mendefinisikan varibale di encrypted file selanjutnya bagaimana kita memanggil variable tersebut di file playbook kita

Agar variable tersebut dapat digunakan di playbook kita perlu melakukan parsing variable tersebut dengan module ansible.builtin.include_vars.

playbook-vault.yaml

---
- name: Playbook buat user baru
  hosts: server_test
  become: true
  gather_facts: true # defaultnya memang true
  vars: # mendefinisikan variable
    user_app: userbaru
  tasks:

    - name: Parsing variable dari secret file
      ansible.builtin.include_vars:
        file: secret-user.yaml

    - name: Add new user
      ansible.builtin.user:
        name: "{{ user_app }}"
        # password: belajaransible # gak secure kita ganti pake Ansible Vault

        password: "{{ user_pass | password_hash('sha512') }}" # ambil value dari variable lalu lakukan hash
        shell: /bin/bash
      when:
        - ansible_os_family == "Debian"

ansible-playbook playbook-vault.yaml --ask-vault-pass

jika kita perlu mengedit isi dari file yang enkripsi bisa dengan command

ansible-vault edit secret-user.yaml

atau melihat isi dari file

ansible-vault view secret-user.yaml

Berangkat dari permasalahan kenapa Ansible di ciptakan dan kita butuh memakai nya? Ketika kita konfigurasi server Linux maka kita akan melakukan remote SSH lalu melakukan task yang ingin kita konfigurasi.

Bagaimana kalau server linux yang kita miliki berjumlah puluhan,dengan konfigurasi yang sama? ada beberapa permasalahan yang mungkin kita temui.

• Capek / Pegel

• Ada perintah command yang terlewat

• Perintah yang di jalankan tidak terdokumentasi dengan baik.

Ansible merupakan tools untuk mengotomatisasi tugas-tugas seperti membuat dan mengkonfigurasi resource linux, windows, database dll.

Kelebihan ansible adalah sifatnya agent-less, maksudnya itu tidak perlu menginsal agent di setiap server yang ingin di otomasti. cukup install ansible di laptop/komputer admin saja.

Cara kerja Ansible yaitu tugas tugas yang akan di jalankan dibungkus dalam sebuah module, setiap module mempunyai tugas kecil secara spesifik seperti copy file, install web server, atau create user.

Di Ansible juga ada nama nya konsep Inventory, yang dimana kita dapat mendefinisikan IP/Domain dalam satu file yang nanti nya Ansible akan membaca file Inventory tersebut sebelum membaca module.

Menginstall Ansible

Ansible berjalan diatas bahasa pemrograman Python. Khusus sistem operasi windows, Ansible menyarankan menggunakan WSL.

Untuk menginstall Ansible cukup ikuti dokumentasi ini.

Prepare Linux Server

untuk Server kita coba create melalui Terraform di Google Cloud Platform.

Jika sudah terbuat selanjutnya lakukan SSH ke server yang sudah dibuat.

Check apakah server sudah terinstall Python

$ python3 --version

Ansible Inventory

Seperti yang sudah di bahas sebelumnya ansible mengetahui server mana yang akan kita manage melalui file Inventory.

Ansible mendukung banyak sekali format penulisan file Inventory, yaitu format INI dan YAML.

Selanjutnya kita coba buat file dengan nama **Inventory,**dan isikan IP Public dari server yang akan di manage

inventory

//ip server dan private key
34.128.82.28 
ansible_user=muhamaddani3004 
ansible_ssh_private_key_file=./ssh-key/cehamot

lalu kita coba ping untuk memastikan koneksi ke server.

$ ansible 34.128.82.28 -i ./inventory -m ping

response yang di dapat adalah Success,berarti kita telah berhasil terhubung ke server melalui ansible.

Biasanya satu file inventory memiliki list ip/domain server, agar file inventory terlihat rapih kita dapat kelompokan dalam sebuah group.

Bahkan parameter yang sudah kita buat sebelumnya "sangat tidak clean" didefinisikan berulang-ulang, bagaimana kalau kita buat group variables.

[server_test]
34.128.82.28

[server_test:vars]
ansible_user=muhamaddani3004
ansible_ssh_private_key_file=./ssh-key/cehamot

dan command ping tetap

$ ansible 34.128.82.28 -i ./inventory -m ping

command sebelumnya menggunakan pattern ansible <pattern> <options>

-m atau -i itu adalah options

Pattern merupakan target host/group yang diinginkan.

ada beberapa cara penulisan pattern yang dapat di lihat disini

Ansible Config

Ansible config digunakan untuk mengkonfigurasi behavior ansible saat kita menjalankan perintah-perintah ansible.

Ansible config di tulis dengan format INI dengan nama ansible.cfg,dan ansible config ini memiliki hirarki dalam pembacaan nya. Disini

Penulisan konfigurasi di ansible config di kelompokan dalam sebuah Section.

jadi contoh nya seperti ini,

$ ansible server_test -i inventory -m ping

pada command sebelumnya kita selalu mendefinisikan option -i <file-inventory> saat memanggil file inventory, dengan menggunakan ansible.cfg kita bisa menyederhanakan dengan menambahkan key inventory di section defaults.

[default]
inventory=./inventory
host_key_checking=False

satu hal lagi yang cukup penting menambahkan line host_key_checking yang fungsinya untuk menghindari host key checking saat pertama kali konek ke server baru.

Ansible Module

Pada materi sebelumnya kita selalu menggunakan option -m ping, option yang kita gunakan tersebut nama nya module.

Module merupakan unit code untuk menjalankan suatu tugas tertentu.

Ansible punya banyak sekali module yang dapat kita gunakan dokumentasi.

Jika module di eksekusi langsung di sebut adhoc command.

• ansible.builtin.add_host Add a host (and alternatively a group) to the ansible-playbook in-memory inventory

• ansible.builtin.apt Manages apt-packages

• ansible.builtin.apt_key Add or remove an apt key

• ansible.builtin.apt_repository Add and remove APT repositories

• ansible.builtin.assemble Assemble configuration files from fragments

• ansible.builtin.assert Asserts given expressions are true

Setiap module dapat memiliki argument untuk kebutuhan module itu sendiri, argument ini juga sering di sebut sebagai parameter.

salah satu contoh seperti ini:

$ ansible server_test -m command "date"

$ ansible server_test -m copy -a "src=./file.txt dest=/tmp/"

Input Variables

untuk mendefinisikan value dari konfigurasi secara terpisah kita memerlukan Input Variables. Default dari Variables berupa string, namun ada jenis lainnya seperti list, map, dan boolean.

create file dengan nama variables.tf

variable "compute_zone" {
  type    = string
  default = "asia-southeast2-a"
}

pada file main.tf di rubah pada bagian Zone

resource "google_compute_instance" "VM-Satu" {
  name                      = "vm-satu"
  machine_type              = "e2-micro"
  zone                      = var.compute_zone
  allow_stopping_for_update = true

......
}

Selain variables berupa string,kita akan coba juga menggunakan variable berupa list ini mirip dengan array. Value pada list variable memiliki index dan index di mulai dari angka 0.

Contoh di sini jika kita ingin mengumpulkan beberapa zone yang ada di GCP.

pada file variables.tf kita bisa rubah seperti ini.

variable "compute_zone" {
  type = list(any)
  default = [
    "asia-southeast2-a",
    "asia-southeast2-b",
  "asia-southeast2-c"]
}

dan digunakan di main.tf akan seperti ini,

resource "google_compute_instance" "VM-Satu" {
  name                      = "vm-satu"
  machine_type              = "e2-micro"
  zone                      = var.compute_zone[0]
  allow_stopping_for_update = true

.....
}

Selain variables berupa list,kita akan coba juga menggunakan variable berupa map yang merupakan collection dari key dan string. untuk memanggil valuenya, kita dapat menggunakan key yang ada.

masih menggunakan contoh zone pada bagian variables.tf di rubah menjadi seperti ini

variable "compute_zone" {
  type = map(any)
  default = {
    "zone-1" = "asia-southeast2-a"
    "zone-2" = "asia-southeast2-b"
    "zone-3" = "asia-southeast2-c"
  }
}

pada bagian main.tf kita menggunakan nya seperti ini

resource "google_compute_instance" "VM-Satu" {
  name                      = "vm-satu"
  machine_type              = "e2-micro"
  zone                      = var.compute_zone["zone-1"]
  allow_stopping_for_update = true

.....
}

Selain variables berupa map,kita akan coba juga menggunakan variable berupa boolean yang kita definisikan true/false value.

contoh di sini pada file variables.tf

variable "allow_stop_vm" {
  type    = bool
  default = false
}

dan cara menggunakan nya di main.tf seperti ini

resource "google_compute_instance" "VM-Satu" {
  name                      = "vm-satu"
  machine_type              = "e2-micro"
  zone                      = var.compute_zone["zone-1"]
  allow_stopping_for_update = var.allow_stop_vm

.....
}

Tips: untuk melakukan override value variable pada saat terraform plan & apply , kita dapat passing options -var

ex: terraform plan -var allow_stop_vm=false

Jika ingin memasukan ssh-key langsung ke instance saat instance tersebut di create pertama kali kita bisa masukan ssh-key ke file variables.tf

contoh di sini pada file variables.tf

variable "ssh_keys" {
  type    = string
  default = "muhamaddani3004:ssh-rsa fdsfsf....."
}

dan cara menggunakan nya di main.tf seperti ini

resource "google_compute_instance" "VM-Satu" {
  name                      = "vm-satu"
  machine_type              = "e2-micro"
  zone                      = var.compute_zone["zone-1"]
  allow_stopping_for_update = var.allow_stop_vm

  metadata = {
    ssh-keys = var.ssh_keys
  }
.....
}

jika nanti kita akan lakukan ssh kita lgsung sudah bisa masuk ke instance.

Output Value

kita dapat menampilkan suatu argument dari sebuah Resource dari command line, kurang lebih contoh seperti menampilkan VM kita dapat IP Publik berapa agar kita tidak perlu lagi check console.

kita tempatkan output value di file outputs.tf

output "public_ip_vm_satu" {
  value       = google_compute_instance.VM-Satu.network_interface[0].access_config[0].nat_ip
  description = "IP Public VM Satu"
}

output "public_ip_vm_dua" {
  value       = google_compute_instance.VM-Dua.network_interface[0].access_config[0].nat_ip
  description = "IP Public VM Dua"
}

dan hasil output nya di dapat.

atau bisa dengan command

$ terraform output public_ip_vm_dua
$ terraform output public_ip_vm_satu

Backend

Sebelumnya kita sudah bahas apa itu State File. file tersebut secara default di letakan di folder konfigurasi Terraform dengan nama terraform.tfstate.

Dalam best practice file tersebut tidak di push ke VCS seperti git. Namun repot kalau jika file state tersebut hilang ya salah satunya broken deployment.

Pada umumnya kita letakan file tersebut di Object Storage seperti Google Cloud Storage atau S3 AWS.

Best practicenya kita tulis konfigurasi backend di file backend.tf

terraform {
  backend "gcs" {
    bucket = "mdrdani-tfstate"
  }
}

sebelumnya kita create terlbih dahulu Object Storage nya, masuk console Google Cloud.

karena konfigurasi Backend ini letaknya di **Terraform Blocks,**maka kita harus menjalankan ulang perintah terraform init.

Terraform State Command

State Command digunakan untuk melakukan manajemen state yang suda ada,yang umumnya di gunakan untuk melihat list, detail atau menghapus state resource.

$ terraform state list

$ terraform state show {state_name}

$ terraform state rm {state_name}

Terraform Destroy Command

jika resource tidak terpakai lagi seharusnya kan kita hapus agar tidak menambah beban cost yang dikeluarkan. Untuk menghapus resource dapat menggunakan destroy command.

//menghapus spesifik resource
$ terraform destroy -target <type>.<name>

//menghapus semua resource
$ terraform destroy

Tips: sebelumnya kita dapat menghapus secara spesifik resource mana yang ingin di hapus, ini juga berlaku untuk terraform plan & apply

//plan spesifik resource
$ terraform plan -target <type>.<name>

// apply spesifik resource
$ terraform apply -target <type>.<name>

Resource Lifecycle

Digunakan untuk mengontrol behavior dari sebuah resource saat dibuat,di update atau dihapus. Contoh kita bisa mencegah suatu resource terhapus secara tidak sengaja.

resource "google_compute_instance" "VM-Dua" {
  name                      = "vm-dua"
  machine_type              = "e2-micro"
  zone                      = var.compute_zone["zone-1"]
  allow_stopping_for_update = var.allow_stop_vm

 lifecycle {
    prevent_destroy = true
  }
  ....
}

Oke thanks yang sudah membaca materi nya.

Core Terraform Workflow

Write : menulis terraform configuration dan initialize

mendefinisikan infrastructure pada file konfigurasi

Plan : Preview

Sebelum dieksekusi ke infrastuk kita bisa melakukan preview terlebih dahulu apa yang akan di buat, ubah atau hapus sehingga bisa lebih aman saat di eksekusi ke infrastuktur.

Apply : Execution

Setelah tahap plan (preview) maka kita bisa eksekusi ke infrastucture yang sebenarnya.

Terraform Command

cukup banyak command yang dimiliki oleh terraform yang bisa digunakan, namun untuk awal kita hanya cukup mengetahui beberapa command yang biasa di pakai. Berikut ini beberapa command dasar :

• terraform init => inisialisasi

• terraform fmt=> merapihkan konfigurasi code file

• terraform validate => check apakah konfigurasi code sudah sesuai

• terraform plan => check apa saja yang akan di rubah

• terraform apply => menerapkan perubahan

• terraform destroy=> menghapus

Install Terraform

Download Terafform di situs ini https://developer.hashicorp.com/terraform/downloads. Pilih operating system menggunakan apa, di sini saya menggunakan windows.

Buka file zip nya copy terraform.exe ke drive C: dengan membuat folder terraform.

Update system global path pada windows di bagian Control Panel -> System -> System Settings-> Environment Variable

Oke Save, dan test buka CMD kembali.

Sukses terraform sudah terinstall di windows.

Setup gcloud CLI

Rekomendasi jika menggunakan PC/Laptop pribadi adalah dengan menggunakan gcloud. Kita akan menggunakan Application Default Credentials (ADC) dari google. install dahulu gcloud cli dari link ini https://cloud.google.com/sdk/docs/install

biasa nya instalasi memakan waktu sekitar 5 menitan.

# gcloud auth login

sukses authentikasi menggunakan account google cloud. selanjutnya login ADC agar terraform dapat berkomunikasi dengan Google Cloud.

# gcloud auth application-default login

Terraform Provider

Terraform provider digunakan sebagai penjembatan antara Terraform dengan remote system (Cloud / On-Premise). Didalam Terraform Block kita harus menentukan provider yang akan digunakan. Minimal kita definisikan source & version yang kita gunakan.

Dalam Visual studio code, create file dengan nama main.tf

terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = "5.24.0"
    }
  }
}

setelah itu pada bagian provider block kita dapat mendefinisikan konfigurasi dari provider namun ini optional di biarkan blank juga tidak apa, contoh

...
provider "google" {
  # Configuration options
  project = "development-m-dani"
  region = "asia-southeast2" //jakarta
}

tips :

• jika ingin merapihkan reformat konfigurasi file main.tf cukup ketikan perintah**terraform fmt.

• jika ingin melakukan pengecekan konfigurasi dapat memvalidasi menggunakan perintah terraform validate.

• jika pertama kali mendefinisikan Terraform Block atau ada perubahan gunakan perintah terraform init.

Resources Blocks

Resource blocks merupakan tempat kita mendefinisikan object dari infrastruktur. Contoh kita akan membuat VM atau istilah nya di GCP yaitu Google Compute Instance. Dokumentasi.

Tambahkan di main.tf

...
resource "google_service_account" "my_service_account" {
  account_id   = "mdrdani-sa"
  display_name = "mdrdani Service Account"
}

resource "google_compute_firewall" "http" {
  name    = "allow-http"
  network = "default"

  allow {
    protocol = "tcp"
    ports    = ["80"]
  }

  source_ranges = ["0.0.0.0/0"]
}

resource "google_compute_firewall" "https" {
  name    = "allow-https"
  network = "default"

  allow {
    protocol = "tcp"
    ports    = ["443"]
  }

  source_ranges = ["0.0.0.0/0"]
}

resource "google_compute_instance" "VM-Satu" {
  name         = "vm-satu"
  machine_type = "e2-micro"
  zone         = "asia-southeast2-a" //jakarta
  tags         = ["http-server", "https-server"]

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network = "default"

    access_config {
      // Ephemeral public IP
    }
  }

  #   metadata_startup_script = "echo hi > /test.txt"

  service_account {
    # Google recommends custom service accounts that have cloud-platform scope and permissions granted via IAM Roles.
    # email  = google_service_account.default.email
    scopes = ["cloud-platform"]
  }
}

jika sudah kita coba ketikan perintah terrafom plan

terlihat di bagian Plan ada 1 to add yang artinya kita akan membuat 1 VM. Jika sudah sesuai maka selanjutnya kita ketikan perintah terraform apply.

apply complete !! kita sudah sukses create VM Google CLoud lewat Terraform.

tips: jika kita auto melewati pertanyaan yes, maka bisa menggunakan perintah terraform apply -auto-approve

Data Sources

Untuk mendefinisikan informasi yang nanti nya dapat dipanggil dari Blocks lain kita gunakan Data Sources, biasa nya berdampingan dengan Resources Blocks. Contoh di sini kita definisikan image booting untuk VM. Dokumentasi

tambahkan di main.tf

....

data "google_compute_image" "my_image" {
  family  = "debian-11"
  project = "debian-cloud"
}

resource "google_compute_instance" "VM-Satu" {
  .....

  boot_disk {
    initialize_params {
      image = data.google_compute_image.my_image.self_link
    }
  }

  .....
  }

...

di sini ada kata self_link yang artinya merupakan link referensi unik suatu resource.

Tips: untuk mendapatkan list public image Google Cloud kita bisa mengetikan perintah gcloud compute images list

Accessing Resource Attributes

kita terkadang akan membutuhkan memanggil sebuah attribute suatu resource dari tempat lain, untuk memanggil nya kita dapat menggunakan format <TYPE>.<NAME>.<ATTRIBUTE>.

Dokumentasi1

Dokumentasi2

contoh kita akan membuat Service Account GCP dan menggunakan nya di VM yang telah kita buat.

tambahkan pada bagian main.tf

....

resource "google_service_account" "service_account" {
  account_id   = "service-account-id"
  display_name = "Service Account"
}

resource "google_compute_instance" "VM-Satu" {
....
service_account {
    # Google recommends custom service accounts that have cloud-platform scope and permissions granted via IAM Roles.
    email  = google_service_account.my_service_account.email
    scopes = ["cloud-platform"]
  }
....
}
...

jika terjadi error VM tidak dapat restart pada saat update Service Account kita dapat menambahkan allow_stopping_for_update = true

....

resource "google_compute_instance" "VM-Satu" {
    name                      = "vm-dua"
    machine_type              = "e2-micro"
    zone                      = "asia-southeast2-a" //jakarta
    allow_stopping_for_update = true
....
}

...

Set the base image

FROM node:20-alpine

Use the official Node.js container image in 𝘢𝘭𝘱𝘪𝘯𝘦 variant

Advantages of using minimal base images:

reduced attack surface thanks to fewer unnecessary packages and security vulnerabilities,
improved performance thanks to efficient disk space, memory and network utilization.

Set the working directory

WORKDIR /app

Set the working directory which defines the target location inside the container for all the subsequent instructions.

Copy and install depedencies

COPY package*.json /app

RUN npm install

Use 𝘯𝘱𝘮 to install dependencies. By separating the dependencies from application source code you can take advantage of container layer caching. As long as you do not change the versions of libraries used by your application, the cached version of previously built layers will be reused, which will significantly shorten the build time.

Copy the application code

COPY --chown=node:node app.js /app

Copy the source code of your application to the working directory configured in the second step.

Run as non-privileged user

USER node

Ensure that processes running in your container will be executed in non-privileged mode. Since a non-privileged user called 𝘯𝘰𝘥𝘦 is already registered in the base Node.js image, just use it.

Set the entry command

CMD ["node", "app.js"]

Finally, specify which application should be executed when the container starts.

complete Dockerfile

FROM node:20-alpine

WORKDIR /app

COPY package*.json /app
RUN npm install

COPY --chown=node:node app.js /app

USER node

CMD ["node", "app.js"]

Set the base image

FROM golang:1.21

use the official Go Docker image.

Set the working directory

WORKDIR /app

set the working directory which defines the target location inside the container for all the subsequent instructions.

Copy and install dependencies

COPY go.mod go.sum ./

RUN go mod download

Use 𝘨𝘰.𝘮𝘰𝘥 to manage dependencies. By separating the dependencies from application source code you can take advantage of container layer caching. As long as you do not change the versions of libraries used by your application, the cached version of previously built layers will be reused, which will significantly shorten the build time. Additionally, including 𝘨𝘰.𝘴𝘶𝘮 file with checksums of all direct and indirect dependencies ensures that their content has not been modified.

Copy the application code

COPY *.go ./

Copy the source code of your application to the working directory created in the second step.

Compile the application

RUN go build -o /myapp

Compile your application from the source code and

Run as non-privileged user

USER 1000

Ensure that processes running in your container will be executed in non-privileged mode. Since a non-privileged user with id 1000 is already registered in the base Go image, just use it.

Set the entry command

CMD ["/myapp"]

this complete Dockerfile

FROM golang:1.21

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download

COPY *.go ./

RUN go build -o /myapp

USER 1000

CMD ["/myapp"]