Mukadimah

Assalamualaikum dan salam sejahtera.

Terima kasih kerana memilih untuk membaca buku ini. Kalau anda sedang pegang buku ini, kemungkinan besar anda sudah pun berjaya membina homelab sendiri. Anda sudah tahu pasang Proxmox, deploy container dengan Docker, dan setup rangkaian asas. Tahniah, itu bukan pencapaian kecil.

Tapi sekarang, anda mungkin tertanya-tanya, “Lepas ni apa?”

Itulah soalan yang saya sendiri pernah tanya bertahun-tahun lalu.

Perjalanan Saya

Saya bermula sebagai seorang yang suka “utak-atik” server di rumah. Satu PC lama jadi hypervisor, pasang pfSense untuk firewall, buat NAS dengan TrueNAS, dan main-main dengan Docker container. Semuanya berjalan dalam homelab kecil di bilik tidur.

Dari pengalaman saya, homelab itu sebenarnya sekolah terbaik. Di situ saya belajar tentang Linux, networking, virtualization, dan containerization tanpa perlu risau kalau server crash. Kalau rosak, format dan mula semula. Tiada siapa marah, tiada downtime yang menjejaskan pelanggan.

Tapi apabila saya mula bekerja dalam industri, saya sedar ada satu jurang yang besar. Skill teknikal homelab memang berguna, tetapi dunia production jauh lebih kompleks. Bukan sekadar “benda jalan”, tetapi bagaimana nak pastikan benda itu jalan secara konsisten, boleh dipercayai, dan boleh diskala.

Di sinilah DevOps masuk.

Saya mula belajar tentang CI/CD pipeline, Infrastructure as Code, monitoring, dan automation. Saya sedar bahawa banyak konsep DevOps sebenarnya sudah saya praktikkan dalam homelab, cuma saya tak tahu namanya dan tak tahu cara buat secara profesional.

Kenapa Buku Ini Wujud

Buku ini adalah sambungan kepada panduan homelab yang saya tulis sebelum ini. Kalau buku pertama mengajar anda cara membina homelab, buku ini akan membawa anda ke langkah seterusnya, iaitu menggunakan kemahiran homelab anda untuk memulakan kerjaya dalam DevOps.

Saya tulis buku ini kerana saya percaya ramai di luar sana yang berada dalam situasi yang sama. Anda sudah ada asas yang kukuh, tetapi perlukan panduan untuk menjembatani jurang antara homelab dan dunia profesional.

Siapa Patut Baca Buku Ini

Buku ini ditulis khas untuk:

• IT professional yang sudah ada pengalaman dengan homelab dan ingin upgrade ke DevOps
• System administrator yang ingin beralih ke peranan yang lebih moden
• Developer yang ingin memahami sisi operations dan deployment
• Pelajar IT yang sudah bermain dengan homelab dan ingin tahu arah kerjaya DevOps

Saya andaikan anda sudah selesa dengan:

• Linux command line
• Docker dan konsep containerization
• Asas networking (IP, DNS, firewall)
• Virtualization (Proxmox, VirtualBox, atau seumpamanya)

Kalau anda belum selesa dengan perkara di atas, saya cadangkan baca dulu buku homelab sebelum ini.

Bagaimana Membaca Buku Ini

Setiap bab dalam buku ini dibina atas bab sebelumnya. Saya cadangkan anda membaca secara berurutan, terutamanya jika ini kali pertama anda berjinak dengan DevOps.

Setiap bab akan bermula dengan pengenalan ringkas dan senarai perkara yang anda akan belajar. Di penghujung setiap bab, ada ringkasan untuk membantu anda mengingat perkara penting.

Anda akan jumpa banyak contoh praktikal, kod, dan konfigurasi yang boleh terus digunakan. Saya juga sertakan “Nota Beginner” untuk menerangkan konsep yang mungkin baru bagi sesetengah pembaca.

Saya harap buku ini dapat membantu anda dalam perjalanan DevOps anda. Ingat, semua pakar pernah bermula sebagai beginner. Yang penting, terus belajar dan terus cuba.

Semoga berjaya.

Syafiyullah Yahya www.notainfra.com

Syarat dan Penafian

DevOps: Dari Homelab ke Production

Hak Cipta (c) 2026 Syafiyullah Yahya. Hak cipta terpelihara.

Laman web: www.notainfra.com

Tiada mana-mana bahagian dalam buku ini boleh diterbitkan semula, disimpan dalam sistem simpanan data, atau dipindahkan dalam apa jua bentuk atau cara, sama ada secara elektronik, mekanikal, fotokopi, rakaman, atau sebaliknya, tanpa kebenaran bertulis terlebih dahulu daripada penulis.

Penafian:

Buku ini ditulis untuk tujuan pendidikan dan panduan sahaja. Penulis dan penerbit tidak bertanggungjawab ke atas sebarang kerosakan, kehilangan data, atau masalah teknikal yang mungkin timbul daripada penggunaan maklumat dalam buku ini.

Semua contoh kod, konfigurasi, dan arahan dalam buku ini disediakan “seadanya” tanpa jaminan dalam apa jua bentuk. Pembaca bertanggungjawab sepenuhnya untuk menguji dan mengesahkan semua arahan sebelum menggunakannya dalam persekitaran production.

Nama produk, jenama, dan tanda dagangan yang disebut dalam buku ini adalah hak milik pemilik masing-masing dan digunakan untuk tujuan pengenalan sahaja.

Versi: 1.0 Tarikh Terbit: 2026

Ditulis dengan penuh dedikasi oleh Syafiyullah Yahya.

Untuk maklum balas, pertanyaan, atau pembetulan, sila hubungi melalui www.notainfra.com.

Bab 1: Apa Itu DevOps?

Anda mungkin pernah dengar perkataan “DevOps” berpuluh kali. Mungkin dalam iklan kerja, dalam artikel teknologi, atau dalam perbualan dengan rakan sekerja. Tapi apa sebenarnya DevOps? Adakah ia satu jawatan? Satu perisian? Satu budaya?

Jawapan ringkasnya: semua sekali. Dan dalam bab ini, kita akan kupas satu persatu supaya anda betul-betul faham apa yang anda sedang masuki.

Apa yang anda akan belajar:

• Definisi DevOps dan kenapa ia wujud
• Perbezaan antara DevOps dan IT tradisional
• Tiang-tiang utama budaya DevOps
• Peranan dan laluan kerjaya dalam DevOps
• Bagaimana kemahiran homelab anda boleh diterjemahkan ke DevOps

1.1 Definisi DevOps

DevOps adalah gabungan dua perkataan: Development dan Operations. Pada asasnya, ia adalah satu set amalan, budaya, dan alatan yang menyatukan pasukan pembangunan perisian (Dev) dan pasukan operasi IT (Ops) supaya mereka boleh bekerja bersama dengan lebih cekap.

Dalam model tradisional, developer menulis kod dan kemudian “lempar” kepada pasukan operations untuk di-deploy. Kalau ada masalah, kedua-dua pihak saling menuding jari. Developer kata “Di mesin saya jalan,” dan Ops kata “Itu bukan masalah server.”

Nota Beginner: Istilah “Dev” merujuk kepada sesiapa yang menulis kod atau membina aplikasi. “Ops” merujuk kepada sesiapa yang menguruskan server, rangkaian, dan infrastruktur. DevOps menyatukan kedua-dua dunia ini.

DevOps menyelesaikan masalah ini dengan menghapuskan “tembok” antara kedua-dua pasukan. Dalam persekitaran DevOps, semua orang berkongsi tanggungjawab dari menulis kod sehingga memastikan ia berjalan dengan baik dalam production.

Secara praktikal, DevOps melibatkan:

• Automation untuk proses berulang seperti testing dan deployment
• CI/CD pipeline untuk menghantar kod dari development ke production secara konsisten
• Infrastructure as Code (IaC) untuk menguruskan infrastruktur seperti menulis perisian
• Monitoring dan observability untuk mengesan masalah sebelum pengguna merasakannya
• Collaboration antara semua pihak yang terlibat dalam pembangunan perisian

1.2 DevOps vs IT Tradisional

Untuk benar-benar memahami DevOps, kita perlu bandingkan dengan cara kerja tradisional. Saya akan gunakan analogi yang mudah difahami.

Model Tradisional (Waterfall)

Bayangkan anda sedang membina rumah. Dalam model tradisional, prosesnya seperti ini:

1. Arkitek lukis pelan (Planning)
2. Tukang bina, bina rumah (Development)
3. Inspektor periksa rumah (Testing)
4. Pemilik terima kunci (Deployment)

Setiap langkah mesti selesai sebelum langkah seterusnya bermula. Kalau inspektor jumpa masalah struktur, tukang bina kena buat semula. Proses ini lambat dan mahal.

Dalam IT tradisional, developer menulis kod selama berbulan-bulan, kemudian serahkan kepada QA team untuk diuji, dan akhirnya Ops team deploy ke production. Keseluruhan proses boleh mengambil masa berminggu-minggu atau berbulan-bulan.

Model DevOps

Sekarang bayangkan pendekatan berbeza. Anda bina rumah satu bilik dulu, periksa, dan biarkan orang duduk. Kemudian tambah bilik lagi, periksa, dan bukakan untuk penghuni. Setiap penambahan kecil tetapi kerap.

Inilah intipati DevOps. Kod dihantar dalam bahagian kecil (small batches), diuji secara automatik, dan di-deploy dengan cepat. Kalau ada masalah, ia dikesan awal dan diperbaiki segera.

Berikut perbandingan ringkas:

Nota Beginner: “Snowflake server” bermaksud server yang dikonfigurasi secara manual sehingga setiap satu unik seperti kepingan salji. Ini menyukarkan penyelenggaraan. DevOps menggantikan ini dengan server yang boleh dibina semula secara automatik menggunakan kod.

1.3 Budaya DevOps

DevOps bukan sekadar alatan. Saya ulang: DevOps bukan sekadar alatan. Ramai orang tersalah faham bahawa dengan memasang Jenkins atau menggunakan Kubernetes, mereka sudah “buat DevOps.” Itu tidak benar.

DevOps pada terasnya adalah satu budaya. Alatan hanyalah pemudah cara. Tanpa budaya yang betul, alatan terbaik dunia pun tidak akan membantu.

Mari kita lihat tiang-tiang utama budaya DevOps.

Collaboration (Kerjasama)

Dalam budaya DevOps, tembok antara pasukan diruntuhkan. Developer, Ops, QA, Security, semuanya bekerja bersama dari awal projek. Bukan lagi “saya buat bahagian saya, anda buat bahagian anda.”

Dari pengalaman saya, perubahan budaya ini selalunya yang paling susah. Teknikal boleh dipelajari dalam beberapa bulan, tetapi mengubah cara orang bekerja bersama boleh mengambil masa bertahun-tahun.

Automation (Automasi)

Kalau sesuatu tugas perlu dilakukan lebih dari sekali, ia patut diautomasi. Ini adalah prinsip asas DevOps.

Anda mungkin sudah mengamalkan ini dalam homelab anda. Mungkin anda tulis script Bash untuk backup, atau guna Docker Compose supaya tak perlu taip arahan Docker yang panjang setiap kali. Itu sudah automation.

Dalam dunia DevOps profesional, automation dibawa ke tahap seterusnya:

• Build automation: Kod dikompil secara automatik setiap kali ada perubahan
• Test automation: Ujian dijalankan secara automatik tanpa campur tangan manusia
• Deployment automation: Aplikasi di-deploy ke production secara automatik selepas lulus ujian
• Infrastructure automation: Server dan rangkaian dibina menggunakan kod

CI/CD (Continuous Integration / Continuous Delivery)

CI/CD adalah nadi DevOps. Ia adalah amalan menghantar perubahan kod secara kerap dan automatik.

Continuous Integration (CI) bermaksud setiap developer menggabungkan (merge) kod mereka ke repository utama secara kerap, biasanya beberapa kali sehari. Setiap penggabungan mencetuskan automated build dan test untuk mengesan masalah awal.

Continuous Delivery (CD) bermaksud kod yang telah lulus semua ujian sentiasa dalam keadaan sedia untuk di-deploy ke production. Deployment boleh dilakukan pada bila-bila masa dengan satu klik butang.

Continuous Deployment (juga CD) pergi satu langkah lebih jauh. Setiap perubahan yang lulus ujian akan secara automatik di-deploy ke production tanpa campur tangan manusia.

Nota Beginner: Jangan keliru antara Continuous Delivery dan Continuous Deployment. Delivery bermaksud kod sedia untuk di-deploy (tetapi manusia masih klik butang). Deployment bermaksud ia secara automatik di-deploy. Kebanyakan organisasi bermula dengan Delivery sebelum beralih ke Deployment.

Monitoring dan Observability

Dalam DevOps, kerja anda tidak tamat selepas deploy. Anda perlu sentiasa memantau aplikasi dan infrastruktur untuk memastikan semuanya berjalan lancar.

Monitoring bermaksud mengumpul data seperti penggunaan CPU, memori, masa tindak balas (response time), dan kadar ralat (error rate). Observability pergi lebih jauh dengan memberikan anda keupayaan untuk memahami keadaan dalaman sistem berdasarkan data luaran.

Kalau anda pernah guna Grafana atau Prometheus dalam homelab, anda sudah ada asas yang baik. Dalam production, monitoring menjadi lebih kritikal kerana downtime boleh menjejaskan ribuan pengguna dan menyebabkan kerugian wang.

Infrastructure as Code (IaC)

IaC bermaksud menguruskan infrastruktur (server, rangkaian, firewall) menggunakan fail konfigurasi yang boleh disimpan dalam version control. Ini bermaksud anda boleh membina semula seluruh infrastruktur anda dari kosong hanya dengan menjalankan satu arahan.

Alatan popular untuk IaC termasuk Terraform, Ansible, dan Pulumi. Kalau anda pernah guna Docker Compose atau menulis Ansible playbook untuk homelab, anda sudah mula dengan IaC tanpa menyedarinya.

1.4 Peranan dan Laluan Kerjaya DevOps

Salah satu soalan yang sering ditanya ialah, “Apa sebenarnya kerja seorang DevOps engineer?” Jawapannya bergantung kepada organisasi, tetapi secara umum, terdapat beberapa peranan utama dalam ekosistem DevOps.

DevOps Engineer

Ini adalah peranan yang paling umum. DevOps engineer bertanggungjawab membina dan menyelenggara CI/CD pipeline, mengurus infrastruktur menggunakan IaC, dan memastikan proses deployment berjalan lancar.

Kemahiran utama yang diperlukan:

• Linux administration
• Scripting (Bash, Python)
• CI/CD tools (Jenkins, GitLab CI, GitHub Actions)
• Containerization (Docker, Podman)
• Container orchestration (Kubernetes)
• IaC tools (Terraform, Ansible)
• Cloud platforms (AWS, Azure, GCP)

Site Reliability Engineer (SRE)

SRE adalah pendekatan Google terhadap DevOps. SRE memberi tumpuan kepada kebolehpercayaan (reliability) sistem. Mereka menetapkan Service Level Objectives (SLO) dan menggunakan error budget untuk mengimbangi antara kelajuan pembangunan dan kestabilan sistem.

Platform Engineer

Platform engineer membina dan menyelenggara platform dalaman yang memudahkan developer melakukan deployment sendiri. Mereka membina “jalan raya” supaya developer boleh fokus memandu tanpa perlu risau tentang infrastruktur.

Cloud Engineer

Cloud engineer fokus kepada pengurusan infrastruktur dalam persekitaran cloud. Mereka mereka bentuk, membina, dan mengoptimumkan sumber cloud untuk prestasi dan kos.

Security Engineer (DevSecOps)

Dalam DevSecOps, keselamatan diintegrasikan ke dalam setiap peringkat pipeline DevOps. Security engineer memastikan kod dan infrastruktur mematuhi piawaian keselamatan secara automatik.

Nota Beginner: Anda tidak perlu kuasai semua peranan ini. Pilih satu yang menarik minat anda dan fokus di situ. Kebanyakan profesional bermula sebagai DevOps engineer sebelum mengkhusus dalam bidang tertentu.

1.5 Kemahiran Homelab Anda Sudah Relevan

Ini bahagian yang saya paling suka. Kalau anda sudah ada pengalaman homelab, anda sebenarnya sudah ada banyak kemahiran yang diperlukan dalam DevOps. Anda cuma perlu tahu cara menterjemahkannya.

Mari kita lihat:

Nampak tak? Anda sudah ada asas yang kukuh. Yang anda perlukan sekarang adalah untuk memformalkan kemahiran ini dan belajar cara menggunakannya dalam konteks profesional.

Dari pengalaman saya, orang yang datang dari latar belakang homelab selalunya lebih cepat memahami konsep DevOps berbanding orang yang belajar teori sahaja. Ini kerana anda sudah “kotor tangan” dan tahu perasaan bila server crash tengah malam.

Perbezaan utama antara homelab dan production ialah skala, kebolehpercayaan, dan kerjasama pasukan. Dalam homelab, kalau server mati, anda sahaja yang terjejas. Dalam production, ribuan pengguna mungkin terkesan. Dalam homelab, anda bekerja seorang diri. Dalam production, anda bekerja dalam pasukan.

Tetapi jangan risau. Buku ini akan membimbing anda melalui peralihan ini langkah demi langkah. Kita akan bermula dengan asas yang paling penting dalam DevOps, iaitu version control dengan Git, dan kemudian bergerak ke CI/CD, containerization, IaC, dan seterusnya.

1.6 Peralatan Yang Anda Perlukan

Sebelum kita mula bab seterusnya, pastikan anda mempunyai perkara berikut:

1. Komputer dengan Linux (atau WSL2 pada Windows). Homelab anda boleh digunakan.
2. Git dipasang pada mesin anda.
3. Docker dipasang dan berjalan.
4. Akaun GitHub atau GitLab (atau Gitea dalam homelab anda).
5. Text editor yang anda selesa, sama ada VS Code, Vim, atau Nano.

Untuk memasang Git dan Docker pada Ubuntu/Debian:

# Pasang Git
sudo apt update
sudo apt install git -y

# Sahkan pemasangan
git --version

# Pasang Docker
sudo apt install docker.io -y
sudo systemctl enable docker
sudo systemctl start docker

# Tambah user anda ke docker group
sudo usermod -aG docker $USER

Nota Beginner: Kalau anda guna homelab, anda boleh buat satu VM khas untuk belajar DevOps. Saya cadangkan Ubuntu Server 22.04 LTS atau lebih baru. Beri sekurang-kurangnya 2 CPU, 4GB RAM, dan 40GB disk.

Selepas pasang, konfigurasikan Git dengan identiti anda:

git config --global user.name "Nama Anda"
git config --global user.email "email@anda.com"

Senarai DevOps Tools dan Fungsinya

Sebelum kita masuk ke bab seterusnya, saya nak bagi gambaran besar tentang tools yang akan kita guna sepanjang ebook ini. Tak perlu hafal semua sekarang. Anggap ini sebagai rujukan pantas yang boleh anda kembali bila-bila masa.

Source Control (Urus Kod)

CI/CD (Automate Build, Test, Deploy)

Containerization (Pakej Aplikasi)

Orchestration (Urus Container Berskala)

Infrastructure as Code (Provision dan Configure)

Monitoring (Pantau Kesihatan Sistem)

Logging (Kumpul dan Analisa Log)

Security (Keselamatan Pipeline)

Cloud Providers

Testing (Uji Kualiti)

Nota Beginner: Jangan rasa overwhelmed tengok senarai ni. Anda tak perlu belajar semua sekarang. Dalam ebook ini, kita akan fokus kepada tools yang paling penting dan praktikal. Mulakan dengan Git, Docker, dan GitHub Actions, kemudian tambah satu persatu mengikut keperluan anda.

Tools Mana Nak Mula Dulu?

Kalau anda baru nak bermula, ini susunan yang saya cadangkan:

1. Git + GitHub (Bab 2). Ini asas. Tanpa ini, semua yang lain tak boleh berfungsi.
2. Docker (Bab 4). Anda dah biasa dari homelab, sekarang bawa ke level production.
3. GitHub Actions (Bab 3). Automate deployment pertama anda.
4. Ansible (Bab 6). Automate server configuration.
5. Prometheus + Grafana (Bab 7). Pantau apa yang anda deploy.
6. Kubernetes (Bab 5). Bila anda dah selesa dengan semua di atas.

Selebihnya, tambah mengikut keperluan projek anda.

Ringkasan

Dalam bab ini, kita telah belajar:

• DevOps ialah gabungan budaya, amalan, dan alatan yang menyatukan development dan operations
• DevOps bukan sekadar alatan, ia adalah budaya yang menekankan kerjasama, automasi, dan penambahbaikan berterusan
• Tiang utama DevOps termasuk CI/CD, automation, monitoring, dan Infrastructure as Code
• Terdapat pelbagai laluan kerjaya dalam DevOps termasuk DevOps engineer, SRE, platform engineer, dan lain-lain
• Kemahiran homelab anda sudah relevan dan boleh diterjemahkan terus ke dunia DevOps profesional

Anda sudah ada asas yang kukuh dari pengalaman homelab anda. Sekarang tiba masanya untuk membina di atas asas itu. Dalam bab seterusnya, kita akan mula dengan kemahiran yang paling fundamental dalam DevOps: Git dan version control.

Jom teruskan perjalanan ini bersama.

Bab 2: Git dan Version Control

Kalau DevOps ada satu kemahiran yang anda wajib kuasai sebelum yang lain, ia adalah Git. Serius, tanpa Git, anda tidak boleh melangkah lebih jauh dalam dunia DevOps. Setiap CI/CD pipeline bermula dengan Git. Setiap Infrastructure as Code disimpan dalam Git. Setiap kerjasama pasukan bergantung kepada Git.

Berita baiknya, Git tidak susah. Ia cuma perlu masa untuk menjadi selesa. Dan kalau anda pernah self-host Gitea dalam homelab anda, anda sudah pun berjinak dengannya.

Apa yang anda akan belajar:

• Kenapa Git penting dalam DevOps
• Arahan asas Git yang anda perlukan setiap hari
• Strategi branching untuk pasukan (GitFlow dan trunk-based)
• Pull request dan code review
• Platform Git hosting (GitHub, GitLab, Gitea)
• Penggunaan .gitignore dan Git hooks
• Workflow praktikal yang boleh terus digunakan

2.1 Kenapa Git Penting

Sebelum Git, developer menyimpan kod dengan cara yang mengerikan. Ada yang guna folder bernama projek_v1, projek_v2, projek_v2_final, projek_v2_final_BETUL. Ada yang email fail zip kepada rakan sekerja. Ada yang guna shared drive dan berdoa tiada siapa tulis ganti fail mereka.

Git menyelesaikan semua masalah ini. Ia adalah sistem version control yang menjejaki setiap perubahan pada kod anda. Setiap perubahan dicatat dengan siapa yang buat, bila, dan kenapa. Anda boleh kembali ke mana-mana versi terdahulu pada bila-bila masa.

Dalam konteks DevOps, Git bukan sekadar tempat simpan kod. Ia adalah:

• Sumber kebenaran tunggal (single source of truth) untuk semua kod dan konfigurasi
• Pencetus (trigger) untuk CI/CD pipeline. Bila anda push kod, pipeline bermula
• Alat kerjasama yang membolehkan ramai orang bekerja pada kod yang sama tanpa konflik
• Audit trail yang merekodkan siapa ubah apa dan bila

Nota Beginner: Version control bukan hanya untuk developer. Sebagai DevOps engineer, anda akan simpan Terraform files, Ansible playbooks, Dockerfile, Kubernetes manifests, dan pelbagai konfigurasi dalam Git. Kalau ia boleh ditulis sebagai teks, ia patut disimpan dalam Git.

2.2 Arahan Asas Git

Mari kita mula dengan arahan yang anda akan guna setiap hari. Saya andaikan anda sudah pasang Git seperti yang ditunjukkan dalam bab sebelumnya.

Mencipta Repository Baru

# Buat direktori baru untuk projek
mkdir projek-devops
cd projek-devops

# Inisialisasi Git repository
git init

# Anda akan nampak mesej:
# Initialized empty Git repository in /home/user/projek-devops/.git/

Arahan git init mencipta folder .git tersembunyi yang menyimpan semua sejarah dan metadata repository anda. Jangan sesekali padam folder ini secara manual.

Aliran Kerja Asas: Add, Commit, Push

Inilah aliran kerja Git yang paling asas. Anda akan ulang proses ini berpuluh kali sehari.

# 1. Buat atau ubah fail
echo "# Projek DevOps Pertama" > README.md

# 2. Semak status - lihat apa yang berubah
git status

# Output akan tunjukkan README.md sebagai "untracked file"

# 3. Tambah fail ke staging area
git add README.md

# 4. Commit perubahan dengan mesej yang bermakna
git commit -m "Tambah README untuk projek"

# 5. (Selepas setup remote) Push ke server
git push origin main

Mari kita fahamkan setiap langkah:

git status menunjukkan keadaan semasa working directory anda. Fail boleh berada dalam tiga keadaan: untracked (Git belum jejak), modified (sudah diubah tetapi belum staged), atau staged (sedia untuk commit).

git add memindahkan fail dari working directory ke staging area. Staging area adalah seperti “ruang menunggu” sebelum perubahan disimpan secara rasmi.

git commit menyimpan snapshot semua perubahan dalam staging area ke dalam sejarah Git. Setiap commit mempunyai ID unik (hash), mesej, penulis, dan cap masa.

git push menghantar commit tempatan anda ke repository remote (seperti GitHub atau GitLab).

Nota Beginner: Fikirkan Git seperti sistem “save game.” git add ialah memilih apa yang nak disimpan. git commit ialah menekan butang save. git push ialah upload save file ke cloud supaya tidak hilang.

Melihat Sejarah

# Lihat senarai commit
git log

# Lihat log dalam format ringkas (satu baris per commit)
git log --oneline

# Lihat log dengan graf visual untuk branches
git log --oneline --graph --all

# Lihat perubahan yang belum di-commit
git diff

# Lihat perubahan yang sudah di-stage
git diff --staged

Clone Repository Sedia Ada

Kebanyakan masa, anda tidak akan mula dari kosong. Anda akan clone repository yang sudah wujud.

# Clone dari GitHub
git clone https://github.com/username/repo-name.git

# Clone dari Gitea homelab anda
git clone https://gitea.homelab.local/username/repo-name.git

# Clone dan beri nama direktori berbeza
git clone https://github.com/username/repo-name.git nama-baru

Pull Perubahan Terkini

Sebelum mula bekerja setiap hari, pastikan anda pull perubahan terkini dari remote.

# Pull perubahan terkini
git pull origin main

# Atau kalau anda sudah set upstream
git pull

Saya cadangkan jadikan ini tabiat pertama setiap pagi sebelum mula menulis kod. Ini mengelakkan konflik yang tidak perlu.

2.3 Branching: Bekerja Secara Selari

Branching adalah salah satu ciri paling berkuasa dalam Git. Ia membolehkan anda bekerja pada ciri baru atau pembetulan pepijat tanpa mengganggu kod utama.

Bayangkan kod utama anda seperti jalan raya utama. Branch adalah jalan keluar sementara. Anda keluar dari jalan utama, buat kerja anda, dan apabila siap, anda masuk semula ke jalan utama.

# Lihat semua branch
git branch

# Buat branch baru
git branch feature/tambah-login

# Tukar ke branch baru
git checkout feature/tambah-login

# Atau buat dan tukar sekaligus (cara lebih ringkas)
git checkout -b feature/tambah-login

# Selepas siap, kembali ke main
git checkout main

# Gabungkan branch ke main
git merge feature/tambah-login

# Padam branch yang sudah digabung
git branch -d feature/tambah-login

Nota Beginner: Penamaan branch yang baik sangat penting. Gunakan format seperti feature/nama-ciri, bugfix/nama-pepijat, atau hotfix/nama-pembetulan. Ini memudahkan semua orang dalam pasukan memahami tujuan setiap branch.

2.4 Strategi Branching

Apabila anda bekerja dalam pasukan, anda perlukan strategi branching yang jelas supaya semua orang tahu cara bekerja bersama. Dua strategi yang paling popular ialah GitFlow dan trunk-based development.

GitFlow

GitFlow adalah strategi yang lebih berstruktur. Ia menggunakan beberapa jenis branch:

• main (atau master): Kod production yang stabil
• develop: Branch integrasi untuk ciri-ciri baru
• feature/*: Branch untuk setiap ciri baru
• release/*: Branch untuk menyediakan release baru
• hotfix/*: Branch untuk pembetulan segera di production

main ──────●──────────────────●──────────── (production)
            \                /
develop ─────●───●───●───●──● ───────────── (integration)
              \     / \     /
feature/a ─────●───●   \   /
                    feature/b ──●───●

Aliran kerja GitFlow:

# Mula ciri baru dari develop
git checkout develop
git checkout -b feature/user-auth

# Buat kerja, commit...
git add .
git commit -m "Tambah fungsi login"

# Selesai, gabung balik ke develop
git checkout develop
git merge feature/user-auth

# Sedia untuk release
git checkout -b release/1.0.0
# Buat testing, fix bugs...

# Deploy ke production
git checkout main
git merge release/1.0.0
git tag v1.0.0

GitFlow sesuai untuk projek yang mempunyai jadual release yang tetap, contohnya release sebulan sekali atau setiap sprint.

Trunk-Based Development

Trunk-based development adalah pendekatan yang lebih ringkas dan digemari dalam budaya DevOps moden. Semua developer bekerja pada satu branch utama (trunk), biasanya main.

main ──●──●──●──●──●──●──●──●──●── (semua kerja di sini)
        \   /       \   /
    short-lived   short-lived
     branch        branch

Prinsip utama:

• Branch hidup tidak lebih dari satu atau dua hari
• Perubahan dibuat dalam bahagian kecil
• Feature flags digunakan untuk menyembunyikan ciri yang belum siap
• CI/CD pipeline berjalan pada setiap commit ke main

# Buat branch pendek untuk satu tugas kecil
git checkout -b fix/typo-readme

# Buat perubahan kecil
git add .
git commit -m "Betulkan typo dalam README"

# Push dan buat pull request
git push origin fix/typo-readme

# Selepas di-review dan di-merge, padam branch
git branch -d fix/typo-readme

Nota Beginner: Kalau anda baru bermula, saya cadangkan trunk-based development. Ia lebih mudah difahami dan lebih sesuai dengan amalan CI/CD. GitFlow cenderung menjadi terlalu kompleks untuk pasukan kecil.

Dari pengalaman saya, kebanyakan pasukan DevOps yang matang menggunakan trunk-based development kerana ia menggalakkan perubahan kecil dan kerap, yang sememangnya nadi DevOps.

2.5 Pull Request dan Code Review

Pull request (PR) atau merge request (MR) adalah mekanisme untuk meminta rakan sepasukan menyemak kod anda sebelum ia digabungkan ke branch utama. Ini adalah amalan penting dalam DevOps kerana ia:

• Menangkap pepijat awal sebelum masuk ke production
• Berkongsi pengetahuan dalam pasukan
• Mengekalkan kualiti kod yang konsisten
• Mencipta dokumentasi tentang kenapa perubahan dibuat

Aliran Kerja Pull Request

# 1. Buat branch untuk tugasan anda
git checkout -b feature/tambah-health-check

# 2. Buat perubahan dan commit
# Katakan anda tambah health check endpoint
git add .
git commit -m "Tambah /health endpoint untuk monitoring"

# 3. Push branch ke remote
git push origin feature/tambah-health-check

# 4. Buat pull request melalui GitHub/GitLab/Gitea
# Biasanya melalui web interface, atau guna CLI:

# Untuk GitHub CLI
gh pr create --title "Tambah health check endpoint" \
  --body "Menambah /health endpoint supaya monitoring tools boleh periksa status aplikasi"

# Untuk GitLab CLI
glab mr create --title "Tambah health check endpoint" \
  --description "Menambah /health endpoint untuk monitoring"

Tips Code Review Yang Baik

Sebagai reviewer, fokus pada perkara berikut:

1. Logik kod: Adakah kod ini betul? Ada edge case yang terlepas?
2. Keselamatan: Ada credential yang terdedah? Input yang tidak disahkan?
3. Kebolehbacaan: Bolehkah orang lain faham kod ini tanpa penjelasan?
4. Testing: Ada ujian untuk perubahan ini?
5. Dokumentasi: Perlu ke kemaskini dokumentasi?

Sebagai penulis PR, bantu reviewer anda:

• Tulis deskripsi yang jelas tentang apa dan kenapa
• Pastikan PR bersaiz kecil (kurang 400 baris kalau boleh)
• Sertakan screenshot kalau ada perubahan UI
• Jalankan semua ujian sebelum minta review

2.6 Platform Git Hosting

Anda perlukan tempat untuk menyimpan repository Git anda secara remote. Berikut adalah pilihan utama.

GitHub

Platform paling popular. Percuma untuk repository awam dan peribadi. Dilengkapi dengan GitHub Actions untuk CI/CD.

# Setup SSH key untuk GitHub
ssh-keygen -t ed25519 -C "email@anda.com"
cat ~/.ssh/id_ed25519.pub
# Salin dan tampal ke GitHub Settings > SSH Keys

# Uji sambungan
ssh -T git@github.com

GitLab

Platform lengkap dengan CI/CD terbina dalam. Boleh di-self-host. Sangat popular dalam organisasi enterprise.

Gitea (Dari Homelab Anda)

Kalau anda sudah self-host Gitea dalam homelab, tahniah. Anda sudah ada platform Git hosting sendiri. Ini sangat bagus untuk belajar kerana anda mempunyai kawalan penuh.

# Clone dari Gitea homelab
git clone git@gitea.homelab.local:username/projek.git

# Tambah remote untuk GitHub sebagai backup
git remote add github git@github.com:username/projek.git

# Push ke kedua-dua remote
git push origin main
git push github main

Nota Beginner: Saya cadangkan anda guna GitHub untuk projek awam dan portfolio, dan Gitea dalam homelab untuk eksperimen peribadi. Mempunyai profil GitHub yang aktif adalah aset besar apabila memohon kerja DevOps.

2.7 Fail .gitignore

Fail .gitignore memberitahu Git fail mana yang tidak perlu dijejaki. Ini sangat penting kerana anda tidak mahu commit perkara seperti password, API key, atau fail yang dijana secara automatik.

Buat fail .gitignore di root repository anda:

# Buat .gitignore
cat > .gitignore << 'EOF'
# Fail persekitaran dan rahsia
.env
.env.local
.env.production
*.pem
*.key
credentials.json

# Fail sistem operasi
.DS_Store
Thumbs.db

# Dependencies
node_modules/
vendor/
__pycache__/
*.pyc

# Fail yang dijana
*.log
*.tmp
dist/
build/
*.o
*.class

# Fail IDE
.vscode/
.idea/
*.swp
*.swo

# Fail Docker yang tidak perlu
docker-compose.override.yml

# Terraform state (mengandungi maklumat sensitif)
*.tfstate
*.tfstate.backup
.terraform/
EOF

Ini adalah antara kesilapan yang paling biasa saya nampak. Developer baru sering terlupa untuk setup .gitignore dan akhirnya commit fail .env yang mengandungi password database ke GitHub. Kalau ini berlaku, anggap password itu sudah terdedah dan tukar segera, walaupun anda padam fail itu kemudian. Sejarah Git menyimpan segala-galanya.

Nota Beginner: Kalau anda sudah tersilap commit fail sensitif, gunakan git filter-branch atau alat seperti BFG Repo Cleaner untuk membuangnya dari sejarah. Tetapi langkah pertama tetap menukar semua credential yang terdedah.

2.8 Git Hooks

Git hooks adalah script yang berjalan secara automatik pada titik-titik tertentu dalam aliran kerja Git. Ia adalah bentuk automation yang paling asas dan sangat berguna.

Hooks disimpan dalam folder .git/hooks/. Berikut adalah beberapa hooks yang berguna.

Pre-commit Hook

Berjalan sebelum commit dibuat. Sesuai untuk memeriksa kualiti kod.

# Buat pre-commit hook
cat > .git/hooks/pre-commit << 'HOOK'
#!/bin/bash

echo "Menjalankan pemeriksaan sebelum commit..."

# Semak kalau ada fail .env yang cuba di-commit
if git diff --cached --name-only | grep -q '\.env'; then
    echo "AMARAN: Anda cuba commit fail .env!"
    echo "Sila keluarkan fail .env dari staging area."
    exit 1
fi

# Semak kalau ada TODO yang tertinggal
if git diff --cached | grep -q 'TODO'; then
    echo "AMARAN: Terdapat TODO dalam kod anda."
    echo "Pastikan ini disengajakan."
    # Tidak block commit, hanya amaran
fi

echo "Pemeriksaan selesai. Meneruskan commit."
HOOK

# Jadikan boleh dilaksanakan
chmod +x .git/hooks/pre-commit

Commit-msg Hook

Berjalan selepas mesej commit ditulis. Sesuai untuk memastikan format mesej commit konsisten.

# Buat commit-msg hook
cat > .git/hooks/commit-msg << 'HOOK'
#!/bin/bash

commit_msg=$(cat "$1")

# Pastikan mesej commit bermula dengan huruf besar
if ! echo "$commit_msg" | head -1 | grep -qE '^[A-Z]'; then
    echo "RALAT: Mesej commit mesti bermula dengan huruf besar."
    echo "Contoh: 'Tambah fungsi login' bukan 'tambah fungsi login'"
    exit 1
fi

# Pastikan mesej commit sekurang-kurangnya 10 aksara
if [ ${#commit_msg} -lt 10 ]; then
    echo "RALAT: Mesej commit terlalu pendek (minimum 10 aksara)."
    exit 1
fi
HOOK

chmod +x .git/hooks/commit-msg

Nota Beginner: Hooks dalam folder .git/hooks/ tidak dikongsi melalui Git. Untuk berkongsi hooks dengan pasukan, simpan mereka dalam folder seperti scripts/hooks/ dan buat setup script yang mencipta symlink. Atau lebih baik lagi, gunakan alat seperti pre-commit framework.

Berkongsi Hooks Dengan Pasukan

Cara yang lebih praktikal untuk menguruskan hooks dalam pasukan:

# Simpan hooks dalam repo
mkdir -p scripts/hooks

# Pindahkan hooks ke folder yang dijejak Git
cp .git/hooks/pre-commit scripts/hooks/pre-commit
cp .git/hooks/commit-msg scripts/hooks/commit-msg

# Buat setup script
cat > scripts/setup-hooks.sh << 'SETUP'
#!/bin/bash
echo "Memasang Git hooks..."

HOOK_DIR=".git/hooks"
SCRIPT_DIR="scripts/hooks"

for hook in "$SCRIPT_DIR"/*; do
    hook_name=$(basename "$hook")
    ln -sf "../../$SCRIPT_DIR/$hook_name" "$HOOK_DIR/$hook_name"
    echo "  Dipasang: $hook_name"
done

echo "Semua hooks telah dipasang."
SETUP

chmod +x scripts/setup-hooks.sh

# Setiap ahli pasukan hanya perlu jalankan:
# ./scripts/setup-hooks.sh

2.9 Workflow Praktikal: Dari Mula Hingga Akhir

Mari kita gabungkan semua yang telah kita belajar dalam satu contoh workflow yang lengkap. Katakan anda bekerja dalam pasukan dan perlu menambah ciri health check pada aplikasi.

# 1. Pastikan anda berada di branch main dan up to date
git checkout main
git pull origin main

# 2. Buat branch baru untuk tugasan
git checkout -b feature/health-check

# 3. Buat perubahan
cat > healthcheck.py << 'EOF'
from flask import Flask, jsonify
import datetime

app = Flask(__name__)

@app.route('/health')
def health():
    return jsonify({
        "status": "healthy",
        "timestamp": datetime.datetime.now().isoformat(),
        "version": "1.0.0"
    })

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)
EOF

# 4. Semak apa yang berubah
git status
git diff

# 5. Stage dan commit
git add healthcheck.py
git commit -m "Tambah health check endpoint untuk monitoring"

# 6. Push ke remote
git push origin feature/health-check

# 7. Buat pull request (guna GitHub CLI)
gh pr create \
  --title "Tambah health check endpoint" \
  --body "## Perubahan
- Tambah /health endpoint yang mengembalikan status, timestamp, dan versi
- Endpoint ini akan digunakan oleh monitoring system

## Cara Uji
1. Jalankan: python healthcheck.py
2. Buka: http://localhost:5000/health
3. Pastikan response JSON dikembalikan"

# 8. Selepas PR di-approve dan di-merge, kemas kini local
git checkout main
git pull origin main

# 9. Padam branch yang sudah selesai
git branch -d feature/health-check

2.10 Situasi Biasa dan Penyelesaian

Berikut adalah beberapa situasi yang anda pasti akan hadapi dan cara menanganinya.

Merge Conflict

Merge conflict berlaku apabila dua orang mengubah bahagian yang sama dalam fail yang sama.

# Apabila pull atau merge menyebabkan conflict
git pull origin main
# CONFLICT (content): Merge conflict in config.yml

# Buka fail yang bermasalah
# Anda akan nampak penanda seperti ini:
# <<<<<<< HEAD
# port: 8080
# =======
# port: 3000
# >>>>>>> origin/main

# Edit fail, pilih versi yang betul, buang penanda
# Kemudian:
git add config.yml
git commit -m "Selesaikan merge conflict pada config.yml"

Undo Perubahan

# Buang perubahan pada fail yang belum di-stage
git checkout -- nama-fail.txt

# Buang fail dari staging area (tetapi kekalkan perubahan)
git reset HEAD nama-fail.txt

# Kembali ke commit sebelumnya (buat commit baru yang membatalkan)
git revert HEAD

# Lihat fail pada commit tertentu
git show abc1234:nama-fail.txt

Stash: Simpan Kerja Sementara

# Anda tengah coding, tapi perlu tukar branch segera
git stash

# Tukar branch, buat kerja lain
git checkout main
# ... buat sesuatu ...

# Kembali dan ambil semula kerja yang di-stash
git checkout feature/my-feature
git stash pop

Nota Beginner: git stash sangat berguna apabila anda perlu tukar konteks dengan cepat. Fikirkan ia seperti meletakkan kerja anda dalam laci sementara. git stash pop mengeluarkan semula dari laci.

Ringkasan

Dalam bab ini, kita telah belajar:

• Git adalah asas DevOps. Setiap pipeline, setiap IaC, setiap kerjasama pasukan bergantung kepada Git.
• Arahan asas (init, add, commit, push, pull, clone) adalah rutin harian anda.
• Branching membolehkan kerja selari tanpa mengganggu kod utama.
• GitFlow sesuai untuk release berjadual. Trunk-based development sesuai untuk CI/CD yang kerap.
• Pull request dan code review mengekalkan kualiti kod dalam pasukan.
• .gitignore melindungi fail sensitif daripada masuk ke repository.
• Git hooks menjalankan pemeriksaan secara automatik untuk mengekalkan standard.

Git mungkin kelihatan mudah pada permulaan, tetapi ia mempunyai kedalaman yang luar biasa. Jangan risau kalau anda belum ingat semua arahan. Dengan masa dan amalan, ia akan menjadi sebahagian daripada memori otot anda.

Saya cadangkan anda luangkan masa beberapa hari untuk bermain dengan Git. Buat repository dalam homelab Gitea anda, cuba buat branch, simulate merge conflict, dan praktik workflow yang kita bincangkan. Lebih banyak anda praktik, lebih selesa anda akan jadi.

Dalam bab seterusnya, kita akan melihat bagaimana Git menjadi pencetus kepada CI/CD pipeline, iaitu jantung DevOps automation.

Teruskan belajar, anda sedang berada di landasan yang betul.

Bab 3: CI/CD Pipeline

Bayangkan situasi ini. Anda baru sahaja siapkan satu feature baru untuk aplikasi web anda. Anda test di local, semua berjalan lancar. Kemudian anda SSH ke server, pull code terbaru, restart service, dan harap semuanya okay. Dua jam kemudian, ada bug. Rupanya anda terlupa run test sebelum deploy. Pernah tak jadi macam ni?

Kalau pernah, anda bukan seorang. Ini adalah masalah klasik yang hampir setiap developer pernah hadapi. Dan inilah sebab CI/CD wujud.

Dalam bab ini, kita akan belajar bagaimana automate keseluruhan proses dari code commit hingga deployment. Tak perlu lagi SSH manual ke server. Tak perlu lagi harap dan doa setiap kali deploy. Semuanya automatic, consistent, dan boleh dipercayai.

Apa yang anda akan belajar:

• Konsep CI/CD dan kenapa ia penting untuk production
• Menulis GitHub Actions workflow dari awal untuk Node.js, Python, dan Docker
• Asas GitLab CI sebagai alternatif
• Pipeline stages: build, test, dan deploy
• Menguruskan environment variables dan secrets dengan selamat
• Deployment strategies: blue-green, rolling, dan canary
• Hands-on: set up CI/CD untuk projek sebenar

Apa Itu CI/CD?

CI/CD adalah singkatan untuk Continuous Integration dan Continuous Delivery (atau Continuous Deployment). Mari kita pecahkan satu per satu.

Continuous Integration (CI) bermaksud setiap kali developer push code ke repository, code tersebut akan di-build dan di-test secara automatik. Kalau ada masalah, anda akan tahu dalam beberapa minit, bukan beberapa hari kemudian bila ada orang lain complain.

Continuous Delivery (CD) pula bermaksud code yang sudah lulus semua test sedia untuk di-deploy pada bila-bila masa. Anda cuma perlu klik satu butang (atau dalam kes Continuous Deployment, ia terus deploy tanpa perlu klik apa-apa).

Nota Beginner: Fikirkan CI/CD macam assembly line di kilang kereta. Setiap bahagian kereta melalui inspection station yang berbeza sebelum sampai ke customer. Kalau satu bahagian tak pass inspection, kereta tak akan keluar dari kilang. Sama juga dengan code anda.

Kenapa Perlu Automate?

Mungkin anda fikir, “Saya seorang je yang kerja kat projek ni. Perlu ke CI/CD?” Jawapan pendek: ya. Sebab manusia buat silap. Kita lupa run test. Kita lupa build Docker image. Kita lupa update environment variable. Machine tak lupa.

Berikut beberapa sebab utama kenapa CI/CD penting:

1. Consistency - Setiap deployment melalui proses yang sama. Tak ada variasi “oh hari tu saya deploy cara lain.”
2. Kelajuan - Deployment yang dulu ambil 30 minit manual boleh jadi 5 minit automatic.
3. Keyakinan - Anda tahu code yang di-deploy sudah lulus semua test.
4. Audit trail - Setiap deployment ada rekod. Siapa deploy, bila, apa yang berubah.
5. Rollback mudah - Kalau ada masalah, boleh revert ke version sebelumnya dengan cepat.

GitHub Actions: Bermula dengan CI/CD

GitHub Actions adalah pilihan paling popular untuk CI/CD sekarang, terutama kalau code anda sudah ada di GitHub. Ia percuma untuk public repository dan ada free tier yang generous untuk private repository.

Struktur Asas

GitHub Actions menggunakan YAML files yang disimpan dalam folder .github/workflows/ di repository anda. Setiap file adalah satu workflow.

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup environment
        run: echo "Kita bermula di sini!"

Mari fahamkan setiap bahagian:

• name - Nama workflow anda. Akan dipaparkan di GitHub UI.
• on - Bila workflow ini perlu run. Di sini, setiap kali ada push ke branch main atau develop, dan setiap kali ada pull request ke main.
• jobs - Senarai kerja yang perlu dilakukan.
• runs-on - Machine apa yang digunakan. ubuntu-latest adalah pilihan paling common.
• steps - Langkah demi langkah apa yang perlu dilakukan.

Workflow untuk Node.js

Ini contoh workflow lengkap untuk aplikasi Node.js:

# .github/workflows/node-ci.yml
name: Node.js CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x, 22.x]

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run tests
        run: npm test

      - name: Run build
        run: npm run build

  security-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20.x'
      - run: npm ci
      - name: Security audit
        run: npm audit --audit-level=high

Perhatikan penggunaan strategy.matrix. Ini bermaksud workflow akan run pada tiga versi Node.js secara selari. Kalau aplikasi anda perlu support multiple versions, ini cara terbaik untuk pastikan semuanya berjalan lancar.

Nota Beginner: npm ci berbeza daripada npm install. Ia lebih strict dan sesuai untuk CI environment kerana ia install dependencies berdasarkan package-lock.json sahaja, tanpa modify apa-apa.

Workflow untuk Python

# .github/workflows/python-ci.yml
name: Python CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        python-version: ['3.10', '3.11', '3.12']

    steps:
      - uses: actions/checkout@v4

      - name: Setup Python ${{ matrix.python-version }}
        uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}

      - name: Cache pip dependencies
        uses: actions/cache@v4
        with:
          path: ~/.cache/pip
          key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
          pip install -r requirements-dev.txt

      - name: Lint with flake8
        run: |
          flake8 . --count --select=E9,F63,F7,F82 --show-source
          flake8 . --count --max-line-length=120 --statistics

      - name: Run tests with coverage
        run: |
          pytest --cov=app --cov-report=xml --cov-report=html

      - name: Upload coverage report
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report-${{ matrix.python-version }}
          path: htmlcov/

Workflow untuk Docker Build dan Push

Ini adalah workflow yang paling anda perlukan untuk production. Ia build Docker image, tag dengan betul, dan push ke container registry.

# .github/workflows/docker-publish.yml
name: Docker Build and Publish

on:
  push:
    branches: [main]
    tags: ['v*']

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-push:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - uses: actions/checkout@v4

      - name: Setup Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=sha,prefix=

      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Workflow ini akan automatically tag image anda berdasarkan Git tag. Kalau anda push tag v1.2.3, image akan di-tag sebagai 1.2.3 dan 1.2. Sangat kemas untuk version management.

GitLab CI: Alternatif yang Mantap

Kalau anda menggunakan GitLab, ia mempunyai CI/CD yang built-in. Anda cuma perlu create file .gitlab-ci.yml di root repository.

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

variables:
  NODE_VERSION: "20"

cache:
  paths:
    - node_modules/

build:
  stage: build
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

test:
  stage: test
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm test
  coverage: '/Lines\s*:\s*(\d+\.?\d*)%/'

deploy-staging:
  stage: deploy
  image: alpine:latest
  script:
    - echo "Deploying to staging..."
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.myapp.com
  only:
    - develop

deploy-production:
  stage: deploy
  image: alpine:latest
  script:
    - echo "Deploying to production..."
    - ./deploy.sh production
  environment:
    name: production
    url: https://myapp.com
  only:
    - main
  when: manual

Perbezaan utama GitLab CI dengan GitHub Actions ialah GitLab menggunakan konsep stages dengan lebih explicit. Setiap stage mesti selesai sebelum stage seterusnya bermula. Perhatikan juga when: manual pada deploy-production. Ini bermaksud production deployment memerlukan seseorang untuk klik butang deploy secara manual. Ini adalah good practice untuk mengelakkan accidental deployment.

Pipeline Stages: Build, Test, Deploy

Sebuah CI/CD pipeline yang baik biasanya mempunyai beberapa stage yang jelas.

Stage 1: Build

Pada stage ini, code anda di-compile atau di-bundle. Untuk aplikasi Node.js, ini mungkin npm run build. Untuk Go, go build. Untuk Docker, docker build.

Tujuan utama stage ini adalah untuk pastikan code anda boleh di-build tanpa error. Kalau ada syntax error atau missing dependency, ia akan gagal di sini.

Stage 2: Test

Stage test biasanya terbahagi kepada beberapa jenis:

• Unit tests - Test fungsi individual. Paling cepat.
• Integration tests - Test bagaimana komponen berbeza berinteraksi.
• End-to-end tests - Test keseluruhan flow dari perspektif pengguna.
• Security scanning - Scan untuk known vulnerabilities.
• Linting - Pastikan code style consistent.

# Contoh test stage yang comprehensive
test:
  runs-on: ubuntu-latest
  services:
    postgres:
      image: postgres:16
      env:
        POSTGRES_DB: testdb
        POSTGRES_USER: testuser
        POSTGRES_PASSWORD: testpass
      ports:
        - 5432:5432
      options: >-
        --health-cmd pg_isready
        --health-interval 10s
        --health-timeout 5s
        --health-retries 5

  steps:
    - uses: actions/checkout@v4
    - name: Run unit tests
      run: npm run test:unit
    - name: Run integration tests
      run: npm run test:integration
      env:
        DATABASE_URL: postgresql://testuser:testpass@localhost:5432/testdb
    - name: Run e2e tests
      run: npm run test:e2e

Perhatikan bagaimana kita boleh spin up PostgreSQL sebagai service dalam GitHub Actions. Ini bermaksud integration test anda boleh test dengan database sebenar, bukan mock.

Stage 3: Deploy

Stage deploy adalah tempat code anda sampai ke server. Bergantung pada setup anda, ini boleh jadi SSH ke server, push ke Kubernetes cluster, atau update cloud service.

Environment Variables dan Secrets

Ini bahagian yang ramai orang buat silap. Jangan sesekali hardcode passwords, API keys, atau credentials dalam code anda. Pernah nampak tak orang push AWS keys ke GitHub? Dalam beberapa minit, bots sudah guna keys tersebut untuk spin up crypto miners.

GitHub Actions Secrets

GitHub menyediakan cara yang selamat untuk menyimpan secrets:

1. Pergi ke repository Settings > Secrets and variables > Actions
2. Klik “New repository secret”
3. Masukkan nama dan value

Kemudian dalam workflow:

steps:
  - name: Deploy to production
    run: |
      ssh -i key.pem ${{ secrets.DEPLOY_USER }}@${{ secrets.DEPLOY_HOST }} \
        "cd /app && docker compose pull && docker compose up -d"
    env:
      API_KEY: ${{ secrets.API_KEY }}
      DATABASE_URL: ${{ secrets.DATABASE_URL }}

Environment-Specific Variables

Untuk projek yang mempunyai multiple environments (staging, production), gunakan GitHub Environments:

deploy-staging:
  runs-on: ubuntu-latest
  environment: staging
  steps:
    - name: Deploy
      run: ./deploy.sh
      env:
        APP_URL: ${{ vars.APP_URL }}
        API_KEY: ${{ secrets.API_KEY }}

deploy-production:
  runs-on: ubuntu-latest
  environment: production
  needs: [deploy-staging]
  steps:
    - name: Deploy
      run: ./deploy.sh
      env:
        APP_URL: ${{ vars.APP_URL }}
        API_KEY: ${{ secrets.API_KEY }}

Setiap environment boleh mempunyai set secrets dan variables yang berbeza. Staging guna staging database, production guna production database. Simple dan selamat.

Nota Beginner: Jangan sesekali log atau print secrets dalam pipeline output. Walaupun GitHub akan cuba mask secrets secara automatik, lebih baik berjaga-jaga.

Deployment Strategies

Okay, code anda sudah lulus semua test. Sekarang, macam mana nak deploy? Ada beberapa strategi yang biasa digunakan.

Rolling Deployment

Ini adalah strategi paling simple. Server anda di-update satu per satu. Kalau anda ada 4 server, server pertama akan di-update dulu. Selepas ia siap dan healthy, server kedua pula. Dan seterusnya.

Kelebihan: Mudah difahami, tiada downtime. Kekurangan: Untuk seketika, ada dua versi aplikasi running serentak.

# Contoh rolling deployment dengan Docker Compose
deploy:
  runs-on: ubuntu-latest
  steps:
    - name: Rolling deploy
      run: |
        for server in ${{ secrets.SERVER_LIST }}; do
          echo "Deploying to $server..."
          ssh deploy@$server "
            cd /app &&
            docker compose pull &&
            docker compose up -d --no-deps --build web &&
            sleep 10 &&
            docker compose exec web curl -f http://localhost:3000/health
          "
          echo "$server deployed successfully"
        done

Blue-Green Deployment

Bayangkan anda ada dua set server yang identical. Satu dipanggil “blue” (version semasa), satu lagi “green” (version baru). Anda deploy version baru ke green. Test. Kalau okay, tukar traffic dari blue ke green. Kalau ada masalah, tukar balik ke blue. Senang.

# Contoh blue-green dengan Nginx
deploy-blue-green:
  runs-on: ubuntu-latest
  steps:
    - name: Deploy to green environment
      run: |
        ssh deploy@${{ secrets.DEPLOY_HOST }} "
          cd /app &&
          docker compose -f docker-compose.green.yml pull &&
          docker compose -f docker-compose.green.yml up -d &&
          sleep 15 &&
          curl -f http://localhost:3001/health
        "

    - name: Switch traffic to green
      run: |
        ssh deploy@${{ secrets.DEPLOY_HOST }} "
          cp /etc/nginx/conf.d/green.conf /etc/nginx/conf.d/active.conf &&
          nginx -s reload
        "

    - name: Stop blue environment
      run: |
        ssh deploy@${{ secrets.DEPLOY_HOST }} "
          docker compose -f docker-compose.blue.yml down
        "

Canary Deployment

Canary deployment adalah strategi di mana anda deploy version baru kepada sebahagian kecil users dulu. Mungkin 5% dulu. Monitor. Kalau tak ada masalah, naikkan ke 25%, 50%, dan akhirnya 100%.

Nama “canary” datang dari amalan pelombong yang bawa burung kenari ke dalam lombong. Kalau burung mati, bermaksud ada gas berbahaya. Sama juga dengan canary deployment. Kalau 5% users mengalami masalah, anda tahu ada issue sebelum ia menjejaskan semua users.

Strategi ini lebih sesuai untuk aplikasi berskala besar dan biasanya memerlukan load balancer yang menyokong traffic splitting seperti Nginx, HAProxy, atau Kubernetes Ingress.

Perbandingan Deployment Strategies

Untuk kebanyakan projek homelab-to-production, rolling deployment sudah memadai. Ia simple, berkesan, dan tidak memerlukan infrastructure tambahan. Anda boleh upgrade ke blue-green atau canary bila keperluan anda bertambah.

Nota Beginner: Jangan terus jump ke canary deployment hanya kerana Netflix atau Google gunakannya. Mulakan dengan rolling deployment. Bila anda faham betul-betul bagaimana ia berfungsi, barulah pertimbangkan strategi yang lebih advanced.

Praktikal: Set Up CI/CD untuk Projek Sebenar

Mari kita buat end-to-end. Katakan anda ada sebuah Node.js API yang menggunakan Docker. Ini complete setup.

Langkah 1: Struktur Projek

my-api/
  src/
    index.js
    routes/
    middleware/
  tests/
    unit/
    integration/
  Dockerfile
  docker-compose.yml
  docker-compose.prod.yml
  .github/
    workflows/
      ci.yml
      deploy.yml
  package.json

Langkah 2: CI Workflow

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    needs: [lint]
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_DB: testdb
          POSTGRES_USER: testuser
          POSTGRES_PASSWORD: testpass
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
      redis:
        image: redis:7
        ports:
          - 6379:6379

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - name: Run tests
        run: npm test
        env:
          DATABASE_URL: postgresql://testuser:testpass@localhost:5432/testdb
          REDIS_URL: redis://localhost:6379

  build-image:
    runs-on: ubuntu-latest
    needs: [test]
    if: github.ref == 'refs/heads/main'
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            ghcr.io/${{ github.repository }}:latest
            ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Langkah 3: Deploy Workflow

# .github/workflows/deploy.yml
name: Deploy

on:
  workflow_run:
    workflows: [CI]
    types: [completed]
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    environment: production
    steps:
      - name: Deploy to production server
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.DEPLOY_HOST }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.DEPLOY_KEY }}
          script: |
            cd /opt/my-api
            export IMAGE_TAG=${{ github.sha }}
            docker compose -f docker-compose.prod.yml pull
            docker compose -f docker-compose.prod.yml up -d
            sleep 10
            curl -f http://localhost:3000/health || exit 1
            echo "Deployment successful!"

      - name: Notify on success
        if: success()
        run: |
          curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
            -H 'Content-Type: application/json' \
            -d '{"text":"Deployment successful! Version: ${{ github.sha }}"}'

      - name: Rollback on failure
        if: failure()
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.DEPLOY_HOST }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.DEPLOY_KEY }}
          script: |
            cd /opt/my-api
            docker compose -f docker-compose.prod.yml down
            export IMAGE_TAG=$(docker images --format '{{.Tag}}' | head -2 | tail -1)
            docker compose -f docker-compose.prod.yml up -d
            echo "Rolled back to previous version"

Perhatikan beberapa perkara penting di sini. Pertama, deploy workflow hanya run selepas CI workflow berjaya. Kedua, ia menggunakan environment production yang boleh dikonfigurasi untuk memerlukan approval. Ketiga, ada step untuk rollback kalau deployment gagal. Dan keempat, ada notification ke Slack supaya team tahu status deployment.

Nota Beginner: Untuk permulaan, anda mungkin tak perlukan semua ini. Mulakan dengan CI sahaja dulu (lint + test). Selepas selesa, tambah Docker build. Kemudian baru tambah automated deployment. Jangan cuba buat semua sekaligus.

Langkah 4: Dockerfile untuk Projek

Untuk melengkapkan setup, ini Dockerfile yang sesuai untuk production:

# Dockerfile
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
RUN npm prune --production

FROM node:20-alpine
RUN addgroup -g 1001 -S appgroup && \
    adduser -S appuser -u 1001 -G appgroup
WORKDIR /app
COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:appgroup /app/package.json ./
USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1
CMD ["node", "dist/index.js"]

Langkah 5: Docker Compose untuk Production

# docker-compose.prod.yml
services:
  web:
    image: ghcr.io/username/my-api:${IMAGE_TAG:-latest}
    restart: always
    ports:
      - "3000:3000"
    env_file:
      - .env.production
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M

  db:
    image: postgres:16-alpine
    restart: always
    volumes:
      - pgdata:/var/lib/postgresql/data
    env_file:
      - .env.db

  redis:
    image: redis:7-alpine
    restart: always
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru

volumes:
  pgdata:

Langkah 6: Test Keseluruhan Flow

Sekarang, mari test keseluruhan flow ini.

1. Buat satu perubahan kecil dalam code anda.
2. Push ke branch develop dan create pull request ke main.
3. Perhatikan CI workflow bermula secara automatik di GitHub Actions tab.
4. Tunggu lint dan test selesai. Kalau ada error, fix dan push lagi.
5. Merge pull request ke main.
6. Perhatikan CI workflow run lagi, kali ini termasuk Docker build dan push.
7. Selepas CI selesai, deploy workflow akan bermula secara automatik.
8. Check server anda untuk pastikan deployment berjaya.

Proses ini mungkin nampak banyak langkah, tapi sebenarnya selepas setup awal, anda hanya perlu buat langkah 1 hingga 5. Selebihnya berlaku secara automatik. Itulah keajaiban CI/CD.

Tips dan Best Practices

Sebelum kita tutup bab ini, beberapa tips yang saya pelajari dari pengalaman.

Cache dependencies. Setiap kali pipeline run, ia perlu download semua dependencies. Gunakan caching untuk speed up proses ini. GitHub Actions dan GitLab CI kedua-duanya menyokong caching.

Keep pipelines fast. Kalau pipeline ambil 30 minit untuk complete, developer akan mula skip CI. Idealnya, pipeline sepatutnya selesai dalam 5 hingga 10 minit. Gunakan parallel jobs dan caching untuk achieve ini.

Protect main branch. Set up branch protection rules supaya code tak boleh di-merge ke main tanpa CI passing. Ini adalah safety net yang paling penting.

Version your artifacts. Setiap Docker image, setiap build artifact, perlu ada unique version. Gunakan Git SHA atau semantic versioning. Jangan guna latest tag sahaja untuk production.

Monitor your pipelines. Set up notifications untuk pipeline failures. Kalau pipeline gagal dan tak ada siapa perasan, ia sama sahaja macam tak ada pipeline.

Don’t test in production. Gunakan staging environment yang mirror production. Deploy ke staging dulu, test, baru deploy ke production. Ini nampak macam common sense, tapi anda akan terkejut berapa ramai orang skip langkah ini.

Use branch naming conventions. Standardize nama branch dalam team anda. Contohnya, feature/add-login, fix/broken-auth, hotfix/critical-bug. Ini memudahkan pipeline untuk trigger berdasarkan jenis perubahan. Anda juga boleh configure workflow untuk run different stages bergantung pada branch pattern.

Fail fast. Letakkan checks yang paling cepat di awal pipeline. Linting biasanya selesai dalam beberapa saat, jadi letakkan ia sebelum tests yang mungkin ambil beberapa minit. Kalau linting gagal, developer tahu dalam masa yang singkat tanpa perlu tunggu semua test selesai.

Pipeline sebagai dokumentasi. Pipeline anda sebenarnya adalah dokumentasi yang hidup tentang bagaimana projek anda di-build, di-test, dan di-deploy. Developer baru boleh baca workflow files untuk faham keseluruhan proses. Pastikan ia jelas dan well-commented.

Troubleshooting CI/CD yang Common

Sebelum kita tutup, beberapa masalah yang sering saya jumpa dan cara mengatasinya.

Pipeline pass locally tapi fail di CI. Ini biasanya disebabkan oleh perbezaan environment. Pastikan Node.js/Python version yang sama digunakan. Check juga sama ada ada dependencies yang depend pada OS-specific packages. Satu tip: gunakan Docker dalam CI supaya environment sentiasa consistent.

Pipeline terlalu lambat. Audit setiap step dan tengok mana yang paling lama. Biasanya install dependencies dan Docker build yang paling lambat. Gunakan caching aggressively. Untuk Docker, gunakan BuildKit cache. Untuk npm, cache node_modules. Untuk pip, cache pip download directory.

Flaky tests. Tests yang kadang pass, kadang fail tanpa code change. Ini biasanya disebabkan oleh race conditions, external API dependencies, atau timezone issues. Fix root cause, jangan cuma retry. Tapi kalau memang perlu, kebanyakan CI platforms ada retry mechanism.

# GitHub Actions: retry step
- name: Run flaky test
  uses: nick-invision/retry@v2
  with:
    timeout_minutes: 5
    max_attempts: 3
    command: npm run test:e2e

Secrets not available. Kalau anda nampak error berkaitan secrets kosong, pastikan anda sudah add secrets di Settings. Untuk pull requests dari forked repositories, secrets tidak available secara default kerana security reasons. Ini adalah behavior yang dijangkakan.

Ringkasan

Dalam bab ini, kita telah belajar bahawa CI/CD bukan sekadar tool. Ia adalah satu amalan yang mengubah cara kita deliver software. Dengan CI, setiap code change di-validate secara automatik. Dengan CD, deployment menjadi proses yang boleh dipercayai dan repeatable.

Kita telah explore GitHub Actions dan GitLab CI sebagai platform CI/CD. Kedua-duanya mempunyai kelebihan masing-masing, tetapi konsep asasnya sama. Kita juga telah belajar tentang pipeline stages (build, test, deploy), cara menguruskan secrets dengan selamat, dan pelbagai deployment strategies.

Yang paling penting, kita telah set up satu CI/CD pipeline yang complete untuk projek sebenar. Dari lint dan test, hingga Docker build dan automated deployment dengan rollback.

Dalam bab seterusnya, kita akan mendalami Docker untuk production. Bukan basics lagi, tetapi teknik-teknik advanced seperti multi-stage builds, image optimization, dan security hardening yang anda perlukan untuk run containers dengan yakin di production.

Bab 4: Docker untuk Production

Anda sudah tahu Docker. Anda boleh tulis Dockerfile, run docker compose up, dan deploy aplikasi di homelab anda. Itu bagus. Tapi production adalah binatang yang berbeza sama sekali.

Di homelab, kalau container crash tengah malam, anda bangun esok pagi dan restart. Di production, kalau container crash tengah malam, customer call support, support escalate ke manager, manager call anda. Tidak fun.

Bab ini bukan tentang belajar Docker dari awal. Anda sudah lepas tahap itu. Bab ini tentang bagaimana run Docker dengan yakin di production. Bagaimana buat image yang kecil dan selamat. Bagaimana monitor containers. Bagaimana pastikan semuanya berjalan walaupun anda sedang tidur.

Apa yang anda akan belajar:

• Multi-stage builds untuk image yang optimized
• Teknik optimization Docker image (saiz, layers, security)
• Docker registry: Harbor dan GitHub Container Registry
• Docker Compose untuk production vs development
• Docker networking dalam konteks production
• Container health checks yang berkesan
• Strategi logging untuk containers
• Docker security best practices
• Resource limits dan kenapa ia penting

Multi-Stage Builds

Ini adalah teknik pertama yang anda perlu kuasai untuk production. Multi-stage builds membolehkan anda gunakan satu Dockerfile untuk build dan hasilkan image yang kecil.

Masalah dengan Dockerfile biasa: anda install build tools (compiler, dev dependencies) untuk build aplikasi, tetapi tools ini tak diperlukan untuk run aplikasi. Hasilnya? Image yang besar tanpa sebab.

Contoh: Node.js

# Stage 1: Build
FROM node:20-alpine AS builder

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build
RUN npm prune --production

# Stage 2: Production
FROM node:20-alpine AS production

RUN addgroup -g 1001 -S appgroup && \
    adduser -S appuser -u 1001 -G appgroup

WORKDIR /app

COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:appgroup /app/package.json ./

USER appuser

EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1

CMD ["node", "dist/index.js"]

Perhatikan apa yang berlaku di sini. Stage pertama install semua dependencies (termasuk devDependencies), build aplikasi, kemudian prune devDependencies. Stage kedua hanya copy files yang diperlukan. Hasilnya? Image yang jauh lebih kecil.

Contoh: Go

Go adalah contoh terbaik untuk multi-stage builds kerana Go binary adalah standalone. Anda boleh compile di satu stage dan copy binary ke image yang sangat minimal.

# Stage 1: Build
FROM golang:1.22-alpine AS builder

WORKDIR /app

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

COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app/server ./cmd/server

# Stage 2: Production
FROM scratch

COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /app/server /server

EXPOSE 8080

ENTRYPOINT ["/server"]

Image dari scratch hanya mengandungi binary anda dan SSL certificates. Saiznya boleh jadi serendah 10 hingga 15 MB berbanding ratusan MB kalau guna image biasa.

Nota Beginner: scratch adalah “empty” image. Ia betul-betul kosong, tiada shell, tiada tools, tiada apa-apa. Sesuai untuk Go, Rust, atau mana-mana compiled language yang menghasilkan static binary. Tapi kalau anda perlu debug, gunakan alpine sebagai base image.

Contoh: Python

# Stage 1: Build
FROM python:3.12-slim AS builder

WORKDIR /app

RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Stage 2: Production
FROM python:3.12-slim AS production

RUN groupadd -r appgroup && useradd -r -g appgroup appuser

COPY --from=builder /opt/venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"

WORKDIR /app
COPY --chown=appuser:appgroup . .

USER appuser

EXPOSE 8000

CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--workers", "4", "app:create_app()"]

Docker Image Optimization

Image size bukan sekadar soal disk space. Image yang kecil bermaksud pull lebih cepat, deploy lebih cepat, dan attack surface yang lebih kecil.

Pilih Base Image yang Sesuai

node:20          ~ 1.1 GB
node:20-slim     ~ 200 MB
node:20-alpine   ~ 130 MB

Perbezaan ini significant. Kalau anda deploy 10 kali sehari, bayangkan berapa bandwidth yang anda jimat dengan alpine.

Namun, alpine menggunakan musl dan bukannya glibc. Sesetengah native dependencies mungkin tidak serasi. Kalau anda menghadapi masalah compatibility, slim adalah pilihan yang baik sebagai jalan tengah.

Optimumkan Layer Caching

Docker build setiap instruction dalam Dockerfile sebagai satu layer. Kalau satu layer berubah, semua layer selepasnya perlu rebuild. Jadi, susun instructions anda supaya yang jarang berubah berada di atas.

# BAIK: Dependencies dulu, source code kemudian
COPY package*.json ./
RUN npm ci
COPY . .

# KURANG BAIK: Semua sekali
COPY . .
RUN npm ci

Dalam contoh pertama, kalau anda hanya ubah source code tanpa ubah dependencies, Docker boleh guna cached layer untuk npm ci. Ini boleh jimat beberapa minit dalam setiap build.

Gunakan .dockerignore

Sama macam .gitignore, tapi untuk Docker. Pastikan anda tak copy file yang tak perlu ke dalam image.

# .dockerignore
node_modules
.git
.gitignore
*.md
docker-compose*.yml
.env*
tests/
coverage/
.github/

Docker Registry

Di homelab, mungkin anda cuma buat docker build dan terus run. Di production, anda perlukan registry untuk simpan dan distribute images.

GitHub Container Registry (GHCR)

Kalau code anda di GitHub, GHCR adalah pilihan paling mudah. Ia integrate terus dengan GitHub Actions dan menggunakan GITHUB_TOKEN yang sedia ada.

# Login
echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin

# Tag dan push
docker tag my-app:latest ghcr.io/username/my-app:v1.0.0
docker push ghcr.io/username/my-app:v1.0.0

Harbor: Self-Hosted Registry

Untuk organisasi yang memerlukan lebih kawalan, Harbor adalah pilihan yang excellent. Ia open source, mempunyai vulnerability scanning built-in, dan boleh di-host sendiri.

# docker-compose untuk Harbor (simplified)
# Untuk production, gunakan installer rasmi dari Harbor
version: '3'
services:
  registry:
    image: goharbor/harbor-core:v2.10.0
    ports:
      - "443:8443"
    volumes:
      - harbor-data:/data

Nota Beginner: Untuk permulaan, GHCR sudah lebih dari cukup. Anda cuma perlukan self-hosted registry bila ada keperluan specific seperti compliance, air-gapped environment, atau anda perlu vulnerability scanning yang lebih mendalam.

Image Tagging Strategy

Bagaimana anda tag images sangat penting untuk production. Ini beberapa pendekatan yang biasa digunakan.

Semantic Versioning menggunakan format v1.2.3. Major version untuk breaking changes, minor untuk features baru, patch untuk bug fixes. Ini paling mudah difahami oleh manusia.

Git SHA menggunakan commit hash sebagai tag, contohnya abc123f. Setiap image boleh di-trace balik ke exact commit. Sangat berguna untuk debugging.

Gabungan kedua-duanya adalah pendekatan terbaik. Tag image anda dengan kedua-dua semantic version dan Git SHA.

# Tag dengan multiple tags
docker tag my-app:latest ghcr.io/username/my-app:v1.2.3
docker tag my-app:latest ghcr.io/username/my-app:abc123f
docker tag my-app:latest ghcr.io/username/my-app:latest

# Push semua tags
docker push ghcr.io/username/my-app:v1.2.3
docker push ghcr.io/username/my-app:abc123f
docker push ghcr.io/username/my-app:latest

Untuk production deployment, selalu guna specific version tag. Gunakan latest hanya untuk development atau testing.

Cleanup Old Images

Registry boleh membesar dengan cepat kalau anda tidak cleanup. Set up retention policy untuk automatically delete old images.

# Untuk GHCR, boleh guna GitHub Actions
# Delete images yang lebih dari 30 hari dan bukan tagged version
- uses: snok/container-retention-policy@v2
  with:
    image-names: my-app
    cut-off: 30 days ago UTC
    keep-at-least: 5
    account-type: personal
    token: ${{ secrets.GITHUB_TOKEN }}

Docker Compose: Production vs Development

Anda mungkin sudah biasa dengan satu docker-compose.yml. Untuk production, anda patut ada setup yang berbeza.

Development

# docker-compose.yml (development)
services:
  app:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - .:/app
      - /app/node_modules
    environment:
      - NODE_ENV=development
      - DEBUG=app:*
    command: npm run dev

  db:
    image: postgres:16
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_PASSWORD=devpassword
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Production

# docker-compose.prod.yml
services:
  app:
    image: ghcr.io/username/my-app:${IMAGE_TAG:-latest}
    restart: always
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
    env_file:
      - .env.production
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 128M
    healthcheck:
      test: ["CMD", "wget", "--spider", "-q", "http://localhost:3000/health"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 15s
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

  db:
    image: postgres:16-alpine
    restart: always
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 1G

secrets:
  db_password:
    file: ./secrets/db_password.txt

volumes:
  pgdata:
    driver: local

Nampak perbezaan? Production version tidak mount source code (guna pre-built image), tidak expose database port ke host, mempunyai resource limits, health checks, proper logging configuration, dan menggunakan secrets untuk sensitive data. Ini semua perkara kecil yang membezakan homelab setup dengan production setup.

Docker Networking dalam Production

Di homelab, semua container biasanya dalam satu network yang sama. Di production, anda perlu lebih berhati-hati.

services:
  nginx:
    image: nginx:alpine
    networks:
      - frontend
    ports:
      - "80:80"
      - "443:443"

  app:
    image: my-app:latest
    networks:
      - frontend
      - backend

  db:
    image: postgres:16
    networks:
      - backend

  redis:
    image: redis:7-alpine
    networks:
      - backend

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true

Perhatikan internal: true pada network backend. Ini bermaksud containers dalam network ini tidak boleh access internet secara langsung. Database dan Redis hanya boleh diakses oleh app container melalui internal network. Nginx boleh access app melalui frontend network, tapi tidak boleh access database secara langsung. Ini adalah prinsip least privilege yang penting untuk security.

Container Health Checks

Health checks adalah cara Docker (atau orchestrator) tahu sama ada container anda sihat. Tanpa health check, Docker hanya tahu container running atau tidak. Ia tak tahu kalau aplikasi anda stuck dalam infinite loop atau database connection putus.

# Dalam Dockerfile
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1

Dan endpoint health check anda perlu bermakna:

// Node.js health check endpoint
app.get('/health', async (req, res) => {
  try {
    // Check database connection
    await db.query('SELECT 1');

    // Check Redis connection
    await redis.ping();

    res.status(200).json({
      status: 'healthy',
      timestamp: new Date().toISOString(),
      uptime: process.uptime(),
      checks: {
        database: 'connected',
        redis: 'connected'
      }
    });
  } catch (error) {
    res.status(503).json({
      status: 'unhealthy',
      error: error.message
    });
  }
});

Nota Beginner: Parameter --start-period penting untuk aplikasi yang mengambil masa untuk start up. Selama tempoh ini, health check failures tidak dikira. Tanpa ini, Docker mungkin restart container sebelum ia sempat start.

Strategi Logging

Di homelab, anda mungkin cuma docker logs dan scroll. Di production, anda perlukan logging yang lebih terstruktur.

Structured Logging

Tulis log dalam format JSON supaya mudah di-parse oleh tools seperti ELK Stack atau Loki.

// Daripada ini:
console.log('User logged in: john@example.com');

// Gunakan ini:
logger.info({
  event: 'user_login',
  email: 'john@example.com',
  ip: req.ip,
  timestamp: new Date().toISOString()
});

Docker Logging Drivers

# docker-compose.prod.yml
services:
  app:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"
        labels: "app"
        tag: "{{.Name}}"

Untuk setup yang lebih advanced, anda boleh forward logs ke centralized logging system:

services:
  app:
    logging:
      driver: "fluentd"
      options:
        fluentd-address: "localhost:24224"
        tag: "app.{{.Name}}"

Penting untuk set max-size dan max-file. Tanpa limit ini, log files boleh memenuhi disk anda. Saya pernah lihat server yang disk penuh kerana log files. Semua services down hanya kerana tak ada disk space. Jangan jadi macam tu.

Log Levels

Pastikan anda gunakan log levels yang betul. Ini memudahkan filtering di production.

// Gunakan library seperti winston atau pino
const logger = require('pino')({
  level: process.env.LOG_LEVEL || 'info'
});

logger.debug('Detailed debugging info');    // Hanya untuk development
logger.info('User created successfully');    // Normal operations
logger.warn('Disk usage above 80%');         // Perlu perhatian
logger.error('Database connection failed');  // Ada masalah
logger.fatal('Application crashed');         // Kritikal

Di production, set log level ke info atau warn. Jangan gunakan debug di production kerana ia akan menghasilkan terlalu banyak log dan boleh menjejaskan performance.

Centralized Logging dengan Loki

Untuk setup yang lebih lengkap, anda boleh gunakan Grafana Loki untuk centralized logging. Ia lebih lightweight berbanding ELK Stack dan integrate dengan baik bersama Grafana untuk visualization.

services:
  loki:
    image: grafana/loki:2.9.0
    ports:
      - "3100:3100"
    volumes:
      - loki-data:/loki

  promtail:
    image: grafana/promtail:2.9.0
    volumes:
      - /var/log:/var/log
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
    command: -config.file=/etc/promtail/config.yml

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

Nota Beginner: Kalau anda baru bermula, json-file logging driver dengan max-size limit sudah memadai. Anda boleh upgrade ke centralized logging bila anda ada multiple servers atau bila anda rasa sukar untuk troubleshoot issues dengan docker logs sahaja.

Docker Security Best Practices

Security di production bukan optional. Ini checklist yang anda perlu ikut.

1. Jangan Run sebagai Root

# Buat user baru
RUN addgroup -g 1001 -S appgroup && \
    adduser -S appuser -u 1001 -G appgroup

# Tukar kepada user tersebut
USER appuser

2. Gunakan Read-Only Filesystem

services:
  app:
    read_only: true
    tmpfs:
      - /tmp
      - /app/temp

Ini memastikan tiada siapa (termasuk attacker) boleh write ke filesystem container. Kalau aplikasi anda perlu write ke temporary files, gunakan tmpfs.

3. Drop Unnecessary Capabilities

services:
  app:
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true

4. Scan Images untuk Vulnerabilities

# Gunakan Docker Scout
docker scout cves my-app:latest

# Atau Trivy (open source)
trivy image my-app:latest

Integrate scanning ini dalam CI/CD pipeline supaya setiap image di-scan sebelum deploy:

# Dalam GitHub Actions
- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }}
    exit-code: '1'
    severity: 'CRITICAL,HIGH'

5. Gunakan Specific Tags, Bukan Latest

# KURANG BAIK
FROM node:latest

# BAIK
FROM node:20.11-alpine

latest boleh berubah pada bila-bila masa. Satu hari semuanya berjalan lancar, hari berikutnya image berubah dan aplikasi anda rosak. Pin your versions.

6. Jangan Simpan Secrets dalam Image

Ini kesilapan yang kerap berlaku. Jangan copy .env file atau secrets ke dalam Docker image. Walaupun anda delete file tersebut dalam layer seterusnya, ia masih boleh diakses melalui layer sebelumnya.

# SALAH - secret masih ada dalam image layers
COPY .env .
RUN source .env && npm run build
RUN rm .env

# BETUL - guna build arguments untuk build-time secrets
ARG API_ENDPOINT
ENV API_ENDPOINT=$API_ENDPOINT
RUN npm run build

# LEBIH BETUL - guna Docker BuildKit secrets
RUN --mount=type=secret,id=env,target=/app/.env npm run build

Untuk runtime secrets, gunakan environment variables atau Docker secrets, bukan files yang di-copy ke dalam image.

7. Keep Images Updated

Set up automated process untuk rebuild images bila base image ada security update. Tools seperti Dependabot atau Renovate boleh bantu automate ini. Anda juga boleh schedule weekly rebuilds dalam CI/CD pipeline untuk pastikan base images sentiasa up to date.

Resource Limits

Ini adalah satu perkara yang sering diabaikan tetapi sangat kritikal. Tanpa resource limits, satu container yang leak memory boleh menjatuhkan keseluruhan server.

services:
  app:
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 128M

limits bermaksud maximum resources yang container boleh guna. Kalau container cuba guna lebih dari 512MB memory, Docker akan kill container tersebut (OOM kill).

reservations bermaksud minimum resources yang dijamin untuk container. Docker akan pastikan sekurang-kurangnya resources ini tersedia.

Untuk menentukan resource limits yang sesuai, monitor aplikasi anda terlebih dahulu. Jalankan ia tanpa limits di staging environment, perhatikan berapa banyak CPU dan memory ia guna dalam keadaan normal dan di bawah load. Kemudian set limits dengan buffer yang munasabah, mungkin 1.5 hingga 2 kali ganda penggunaan normal.

Nota Beginner: Kalau anda nampak container anda kerap di-OOM kill, jangan terus naikkan memory limit. Mungkin ada memory leak dalam aplikasi anda. Check dan fix root cause dulu.

Container Restart Policies

Di homelab, kalau container crash, anda mungkin manually restart. Di production, anda perlukan restart policy yang automatik.

services:
  app:
    restart: always          # Sentiasa restart, kecuali manually stopped
  worker:
    restart: on-failure      # Restart hanya kalau exit code bukan 0
  migration:
    restart: "no"            # Jangan restart (untuk one-off tasks)

Bila guna yang mana?

• always sesuai untuk long-running services seperti web server dan API. Ia akan restart walaupun selepas server reboot.
• on-failure sesuai untuk background workers yang mungkin crash sesekali. Ia akan restart kalau process exit dengan error, tapi tidak kalau ia exit secara normal.
• no sesuai untuk tasks yang hanya perlu run sekali, seperti database migration atau data seeding.

Ada juga unless-stopped yang sama macam always, tapi tidak restart selepas anda manually stop container. Ini berguna kalau anda perlu stop container untuk maintenance tanpa risau ia restart sendiri.

Docker Image Layers dan Build Cache

Memahami bagaimana Docker layers berfungsi boleh menjimatkan banyak masa build. Setiap instruction dalam Dockerfile menghasilkan satu layer. Docker cache setiap layer. Kalau instruction dan semua layers sebelumnya tidak berubah, Docker guna cached version.

Ini bermaksud susun atur instructions anda sangat penting:

# Optimized layer ordering
FROM node:20-alpine

WORKDIR /app

# Layer 1: Jarang berubah
COPY package.json package-lock.json ./

# Layer 2: Hanya rebuild bila dependencies berubah
RUN npm ci --production

# Layer 3: Berubah setiap kali ada code change
COPY . .

# Layer 4: Build step
RUN npm run build

Kalau anda cuma ubah source code tanpa ubah dependencies, Docker hanya perlu rebuild Layer 3 dan 4. Layer 1 dan 2 guna cache. Ini boleh jimat beberapa minit dalam setiap build, terutama kalau projek anda ada banyak dependencies.

Satu lagi tip: gunakan .dockerignore yang comprehensive. Setiap file yang di-COPY ke build context boleh invalidate cache. Kalau anda accidentally copy node_modules atau .git folder, cache akan invalidate setiap kali walaupun dependencies tidak berubah.

Backup dan Disaster Recovery

Ini satu topik yang ramai orang abaikan sehingga terlambat. Di production, anda perlu plan untuk worst case scenario.

Backup Database Volumes

# Backup PostgreSQL data
docker compose exec db pg_dump -U postgres mydb > backup_$(date +%Y%m%d).sql

# Atau backup volume secara langsung
docker run --rm \
  -v pgdata:/data \
  -v $(pwd)/backups:/backup \
  alpine tar czf /backup/pgdata_$(date +%Y%m%d).tar.gz -C /data .

Automated Backup dengan Cron

services:
  backup:
    image: postgres:16-alpine
    entrypoint: /bin/sh
    command: >
      -c "while true; do
        PGPASSWORD=$$POSTGRES_PASSWORD pg_dump -h db -U postgres mydb
          > /backups/backup_$$(date +%Y%m%d_%H%M%S).sql;
        find /backups -name '*.sql' -mtime +7 -delete;
        sleep 86400;
      done"
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - ./backups:/backups
    secrets:
      - db_password
    depends_on:
      - db

Script ini akan backup database setiap hari dan delete backups yang lebih dari 7 hari. Simple tapi berkesan. Untuk production yang lebih serius, pertimbangkan untuk upload backups ke cloud storage seperti S3 atau MinIO supaya backups anda tidak hilang kalau server mati.

Nota Beginner: Test restore process anda secara berkala. Backup yang tidak boleh di-restore bukan backup. Set up schedule untuk test restore sekurang-kurangnya sebulan sekali.

Production Checklist

Sebelum deploy sebarang container ke production, pastikan anda sudah check perkara berikut:

[ ] Multi-stage build digunakan
[ ] Base image menggunakan specific version tag
[ ] Container tidak run sebagai root
[ ] Health check dikonfigurasi
[ ] Resource limits ditetapkan
[ ] Logging dikonfigurasi dengan size limits
[ ] .dockerignore wujud dan lengkap
[ ] Secrets tidak di-hardcode dalam image
[ ] Image sudah di-scan untuk vulnerabilities
[ ] Network segmentation ditetapkan
[ ] Restart policy dikonfigurasi
[ ] Volumes untuk persistent data dikonfigurasi

Ringkasan

Dalam bab ini, kita telah melangkah jauh dari Docker basics ke Docker production. Multi-stage builds membantu kita buat image yang kecil dan efficient. Proper networking dan security practices memastikan containers kita selamat. Health checks dan resource limits memastikan containers kita reliable.

Perkara yang paling penting untuk diingat adalah ini: production Docker bukan sekadar tentang membuat sesuatu berfungsi. Ia tentang membuat sesuatu berfungsi dengan selamat, efficient, dan boleh dipercayai walaupun pada jam 3 pagi.

Kita telah melihat perbezaan antara Docker Compose untuk development dan production. Kita telah belajar tentang container registries, logging strategies, dan security hardening. Semua ini adalah building blocks yang anda perlukan sebelum kita masuk ke topik seterusnya: Kubernetes.

Bab 5: Kubernetes Asas

Ada satu titik dalam perjalanan DevOps anda di mana Docker Compose mula terasa tidak cukup. Mungkin anda perlu deploy ke multiple servers. Mungkin anda perlu auto-scaling. Mungkin anda perlu zero-downtime deployment tanpa perlu tulis skrip yang rumit. Di situlah Kubernetes masuk.

Kubernetes (atau K8s, kerana ada 8 huruf antara K dan s) pada mulanya mungkin nampak menakutkan. Banyak terminologi baru, banyak YAML files, banyak moving parts. Tapi kalau anda sudah faham Docker, anda sebenarnya sudah mempunyai 60% daripada pengetahuan yang diperlukan. Bab ini akan bawa anda melalui 40% yang tinggal.

Kita tak akan cover semuanya. Kubernetes adalah ecosystem yang sangat luas. Tapi selepas habis bab ini, anda akan mempunyai pemahaman yang kukuh tentang core concepts dan boleh deploy aplikasi pertama anda ke K8s cluster.

Apa yang anda akan belajar:

• Kenapa Kubernetes wujud dan masalah apa yang ia selesaikan
• Arsitektur K8s: control plane, worker nodes, pods, services
• Setup K3s di homelab anda (step by step)
• Kubectl commands yang anda perlu tahu
• Deploy aplikasi pertama ke K8s
• Services dan Ingress untuk expose aplikasi
• ConfigMaps dan Secrets
• Persistent storage
• Scaling aplikasi
• Asas Helm
• Bila guna K8s vs Docker Compose

Kenapa Kubernetes?

Sebelum kita terjun ke technical details, mari faham masalah yang Kubernetes selesaikan. Bayangkan anda ada 5 aplikasi microservices, setiap satu memerlukan 2 replicas, dan anda ada 3 servers.

Dengan Docker Compose, anda perlu manually decide: service A dan B di server 1, service C di server 2, dan seterusnya. Kalau server 2 mati, anda perlu manually pindahkan services ke server lain. Kalau traffic meningkat, anda perlu manually tambah replicas.

Kubernetes automate semua ini. Anda cuma perlu cakap: “Saya nak 2 replicas untuk service A.” Kubernetes akan decide di mana nak letak, dan kalau satu replica mati, ia akan automatically create yang baru.

Ini dipanggil declarative configuration. Anda declare apa yang anda nak, bukan bagaimana nak achieve ia.

Selain itu, Kubernetes memberikan anda beberapa superpower yang Docker Compose tidak ada:

• Self-healing: Kalau container crash, K8s automatically restart. Kalau node mati, K8s pindahkan workload ke node lain.
• Auto-scaling: K8s boleh tambah atau kurangkan replicas berdasarkan CPU/memory usage secara automatik.
• Rolling updates: Deploy version baru tanpa downtime. K8s akan slowly replace pods lama dengan pods baru.
• Service discovery: Setiap service dapat DNS name secara automatik. Tak perlu hardcode IP addresses.
• Load balancing: Traffic diagihkan secara automatik antara semua replicas.

Nota Beginner: K8s bukan penyelesaian untuk semua masalah. Ia menambah complexity yang significant. Pastikan anda benar-benar perlukan features di atas sebelum adopt K8s. Banyak aplikasi berjaya dengan Docker Compose sahaja.

Arsitektur Kubernetes

Untuk faham K8s, anda perlu faham beberapa komponen utama.

Control Plane

Control plane adalah “otak” K8s. Ia terdiri daripada beberapa komponen.

API Server adalah pintu masuk utama. Semua arahan kepada K8s melalui API server, termasuk arahan dari kubectl.

etcd adalah database yang simpan semua state cluster. Ia tahu berapa replicas setiap service ada, di mana ia running, dan apa configuration mereka.

Scheduler bertanggungjawab untuk decide di mana nak run pods baru. Ia mempertimbangkan resource availability, constraints, dan affinity rules.

Controller Manager menjalankan pelbagai controllers yang memastikan actual state cluster sepadan dengan desired state. Kalau anda kata nak 3 replicas tapi hanya 2 yang running, controller manager akan buat satu lagi.

Worker Nodes

Worker nodes adalah machines yang actually run containers anda. Setiap worker node mempunyai beberapa komponen penting.

kubelet adalah agent yang run di setiap node. Ia menerima arahan dari control plane dan memastikan containers running seperti yang dikehendaki.

kube-proxy menguruskan network rules supaya traffic boleh sampai ke pods yang betul.

Container Runtime (biasanya containerd) adalah software yang actually run containers.

Pods

Pod adalah unit terkecil dalam Kubernetes. Satu pod boleh mengandungi satu atau lebih containers. Dalam kebanyakan kes, satu pod mengandungi satu container sahaja.

Nota Beginner: Fikirkan pod macam wrapper di sekeliling container anda. Kenapa perlu wrapper? Kerana K8s perlu tempat untuk letak metadata, health check info, restart policy, dan networking config. Pod menyediakan semua ini.

Services

Service dalam K8s bukan service dalam Docker Compose. Di sini, service adalah abstraksi yang menyediakan stable network endpoint untuk satu set pods. Pods boleh datang dan pergi (dihapus, dicipta semula), tetapi service address kekal sama.

Setting Up K3s di Homelab

K3s adalah lightweight Kubernetes distribution dari Rancher. Ia sesuai untuk homelab kerana ia menggunakan kurang resources berbanding full K8s, tetapi masih production-ready.

Keperluan

• Satu atau lebih machines (boleh VMs) dengan minimum 2GB RAM dan 2 CPU cores
• Ubuntu 22.04 atau mana-mana Linux distribution yang supported
• Network connectivity antara semua nodes

Install K3s Server (Control Plane)

# Di server utama (control plane)
curl -sfL https://get.k3s.io | sh -

# Check status
sudo systemctl status k3s

# Dapatkan kubeconfig
sudo cat /etc/rancher/k3s/k3s.yaml

Itu sahaja. Serius. K3s boleh di-install dalam satu command. Selepas install, anda sudah ada functional Kubernetes cluster dengan satu node.

Tambah Worker Nodes

# Di server utama, dapatkan token
sudo cat /var/lib/rancher/k3s/server/node-token

# Di worker node, join cluster
curl -sfL https://get.k3s.io | K3S_URL=https://CONTROL_PLANE_IP:6443 \
  K3S_TOKEN=TOKEN_DARI_SERVER sh -

Setup kubectl di Local Machine

# Copy kubeconfig dari server
scp user@server:/etc/rancher/k3s/k3s.yaml ~/.kube/config

# Edit server address (tukar 127.0.0.1 ke server IP)
# Dalam ~/.kube/config, cari line "server:" dan tukar ke IP server

# Test connection
kubectl get nodes

Output yang anda sepatutnya nampak:

NAME        STATUS   ROLES                  AGE   VERSION
server-01   Ready    control-plane,master   10m   v1.28.5+k3s1
worker-01   Ready    <none>                 5m    v1.28.5+k3s1
worker-02   Ready    <none>                 3m    v1.28.5+k3s1

Nota Beginner: Kalau anda cuma ada satu machine, tak perlu risau. K3s boleh run semua workloads di control plane node juga. Untuk belajar, satu node sudah cukup.

Kubectl Commands yang Anda Perlu Tahu

kubectl adalah CLI tool untuk interact dengan Kubernetes cluster. Ini commands yang paling kerap digunakan.

# Lihat semua resources
kubectl get pods                    # Senarai pods
kubectl get services                # Senarai services
kubectl get deployments             # Senarai deployments
kubectl get all                     # Senarai semua resources
kubectl get all -n kube-system      # Resources dalam namespace tertentu

# Maklumat terperinci
kubectl describe pod POD_NAME       # Detail sesuatu pod
kubectl describe service SVC_NAME   # Detail sesuatu service

# Logs
kubectl logs POD_NAME               # Lihat logs
kubectl logs -f POD_NAME            # Follow logs (live)
kubectl logs POD_NAME -c CONTAINER  # Logs dari specific container

# Debug
kubectl exec -it POD_NAME -- /bin/sh    # Shell ke dalam pod
kubectl port-forward POD_NAME 8080:80   # Forward port ke local

# Apply configuration
kubectl apply -f manifest.yaml      # Create atau update resource
kubectl delete -f manifest.yaml     # Delete resource

Tips berguna: set alias supaya hidup lebih mudah.

# Tambah dalam ~/.bashrc atau ~/.zshrc
alias k='kubectl'
alias kgp='kubectl get pods'
alias kgs='kubectl get services'
alias kgd='kubectl get deployments'
alias kd='kubectl describe'
alias kl='kubectl logs'
alias ka='kubectl apply -f'

Deploy Aplikasi Pertama

Mari deploy satu aplikasi web yang simple. Dalam K8s, anda define apa yang anda nak dalam YAML files yang dipanggil manifests.

Deployment

# app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
  labels:
    app: my-web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-web-app
  template:
    metadata:
      labels:
        app: my-web-app
    spec:
      containers:
        - name: web
          image: ghcr.io/username/my-app:v1.0.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 20

YAML ini memberitahu K8s: “Saya nak 3 replicas aplikasi saya, setiap satu guna image ini, expose port 3000, dan ini resource limits yang saya nak.”

# Apply deployment
kubectl apply -f app-deployment.yaml

# Check status
kubectl get deployments
kubectl get pods

# Tunggu sehingga semua pods Ready
kubectl rollout status deployment/my-web-app

Perhatikan dua jenis probes. readinessProbe menentukan sama ada pod sedia menerima traffic. Kalau fail, pod akan dikeluarkan dari service (tak terima traffic baru, tapi tidak di-kill). livenessProbe menentukan sama ada pod masih hidup. Kalau fail beberapa kali berturut-turut, K8s akan restart pod tersebut.

Services dan Ingress

Pods sudah running, tapi bagaimana nak access mereka? Di sinilah Services dan Ingress masuk.

ClusterIP Service

# app-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-web-app
spec:
  selector:
    app: my-web-app
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP

ClusterIP service hanya boleh diakses dari dalam cluster. Ia menyediakan stable IP address dan DNS name (my-web-app.default.svc.cluster.local). Sesuai untuk internal services seperti API yang diakses oleh services lain.

NodePort Service

apiVersion: v1
kind: Service
metadata:
  name: my-web-app-nodeport
spec:
  selector:
    app: my-web-app
  ports:
    - port: 80
      targetPort: 3000
      nodePort: 30080
  type: NodePort