Nginx adalah web server yang paling sering dipilih jadi pintu depan server modern: melayani berkas statis dengan hemat sumber daya, sekaligus sanggup meneruskan trafik ke backend di belakangnya. Di Chapter Web Server kita sudah memahami bahasa yang dibicarakan — permintaan, kode status, virtual host, dan header Host — sekarang kita memasang penuturnya. Paket nginx tidak terpasang di lingkungan latihan, jadi perintah instalasi kita lihat dalam prosa sementara struktur berkas konfigurasinya — inti dari pekerjaan harian — kita bangun dan bedah sungguhan, dari peta direktori, server block untuk situs statis, hingga reverse proxy ke backend.

Instalasi dan Peta Konfigurasi #

Di keluarga Debian, Nginx dipasang dengan sudo apt install nginx — paket tersebut langsung menyala dan menyajikan halaman selamat datang bawaan begitu selesai. Seluruh keputusan hidupnya ada di direktori /etc/nginx/, dan satu berkas utama menjahit semuanya: nginx.conf. Di dalam blok http { } berkas itu terdapat dua directive penting: include /etc/nginx/conf.d/*.conf; dan include /etc/nginx/sites-enabled/*; — artinya, berkas-berkas di lokasi tersebut ditarik masuk seolah ditulis langsung di dalam nginx.conf. Ditambah directive worker_processes auto di puncak berkas, yang memerintahkan Nginx menjalankan satu worker process per inti CPU.

Pola Debian membagi konfigurasi situs ke dua folder: sites-available menampung semua berkas konfigurasi, dan sites-enabled berisi tautan simbolik (symlink) ke berkas yang benar-benar aktif. Kita bangun strukturnya:

bash 
mkdir -p nginx/sites-available nginx/sites-enabled
printf 'server {\n    listen 80;\n}\n' > nginx/sites-available/latihan.example.com
ln -s ../sites-available/latihan.example.com nginx/sites-enabled/latihan.example.com
tree nginx

Output yang Dihasilkan:

text 
nginx
├── sites-available
│   └── latihan.example.com
└── sites-enabled
    └── latihan.example.com -> ../sites-available/latihan.example.com

3 directories, 2 files

Mari kita bedah baris demi baris:

  1. Baris 1 (mkdir -p ...): membuat dua folder inti — sites-available sebagai gudang konfigurasi, sites-enabled sebagai etalase aktif.
  2. Baris 2 (printf 'server { ... }' > ...): menulis konfigurasi situs ke gudangnya — berkas hanya tersimpan, belum aktif.
  3. Baris 3 (ln -s ../sites-available/... sites-enabled/...): membuat symlink yang menunjuk kembali ke berkas di gudang. Karena nginx.conf meng-include sites-enabled/*, keberadaan tautan inilah yang mengaktifkan situs — dan rm tautan itu cukup untuk menonaktifkannya tanpa kehilangan berkas aslinya.
  4. Baris 4 (tree nginx): memetakan hasilnya — tampilan -> pada baris terakhir adalah symlink dan targetnya.

Mekanisme symlink ini persis gagasan a2ensite milik Apache yang akan kita jumpai di Chapter Apache HTTP Server — dua web server besar sama-sama memakai pola gudang-etalase. Situs bawaan bernama default juga hadir sebagai symlink di sites-enabled pada instalasi baru; situs itu menjadi default server penampung permintaan yang tidak cocok dengan server_name mana pun.

Server Block untuk Situs Statis #

Satu situs di Nginx berarti satu server block: kumpulan directive yang menjelaskan di pintu mana ia mendengarkan, nama apa yang dijawab, dan berkas mana yang dilayani. Kita tulis konfigurasi lengkap untuk situs statis latihan.example.com:

bash 
mkdir -p nginx/sites-available
cat > nginx/sites-available/latihan.example.com <<'EOF'
server {
    listen 80;
    server_name latihan.example.com;

    root /var/www/latihan;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
cat nginx/sites-available/latihan.example.com

Output yang Dihasilkan:

text 
server {
    listen 80;
    server_name latihan.example.com;

    root /var/www/latihan;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Mari kita bedah directive demi directive:

  1. listen 80: server block ini menangani koneksi pada port 80 dari semua interface — konsep binding dari Chapter Server Basics . Bentuk listen 127.0.0.1:80 akan membatasinya ke loopback saja.
  2. server_name latihan.example.com: nama yang dicocokkan dengan header Host — mekanisme virtual host yang kita saksikan langsung di Chapter Web Server .
  3. root /var/www/latihan: akar dokumen; semua path pada URL diterjemahkan relatif terhadap direktori ini di disk.
  4. index index.html: bila klien meminta sebuah direktori, Nginx mencoba berkas index.html di dalamnya.
  5. location / { ... }: blok aturan untuk seluruh path — tanda / berarti “semua yang diawali garis miring”.
  6. try_files $uri $uri/ =404: urutan percobaan saat permintaan datang — berkas persis dengan nama path ($uri), lalu path sebagai direktori ($uri/), dan bila dua-duanya tidak ada, jawab sendiri kode 404.

Enam baris itu sudah merupakan satu situs statis yang lengkap dan siap produksi: taruh berkas di /var/www/latihan, aktifkan dengan symlink di sites-enabled, uji, lalu muat ulang.

Menguji dan Me-reload Konfigurasi #

Setiap selesai mengedit, dua perintah menutup prosedurnya. Pertama, sudo nginx -t menguji seluruh rangkaian konfigurasi — sintaks tiap berkas, directive yang tidak dikenal, hingga tanda kurung yang tidak tertutup. Berikut contoh tampilannya saat lulus:

text 
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Kedua, sudo systemctl reload nginx menerapkan perubahan tanpa memutus koneksi yang sedang berjalan: master process membaca konfigurasi baru, melahirkan worker baru, lalu memberi tahu worker lama untuk berhenti setelah menyelesaikan koneksi yang sedang digendongnya. restart berbeda — seluruh proses dibunuh dan dibangkitkan, koneksi aktif terputus — jadi reload adalah pilihan untuk perubahan konfigurasi harian.

Reverse Proxy ke Backend #

Model ketiga dari Chapter Web Server — reverse proxy — adalah peran asli Nginx di banyak arsitektur. Satu directive proxy_pass cukup untuk meneruskan trafik yang jatuh pada sebuah location ke backend. Praktik yang baik mendahulukan satu langkah: mendefinisikan backend di blok upstream agar namanya bisa dirujuk, mudah diganti, dan kelak bisa ditambah rekan load balancing. Kita tulis konfigurasi untuk subdomain API:

bash 
mkdir -p nginx/sites-available
cat > nginx/sites-available/api.latihan.example.com <<'EOF'
upstream backend.example.com {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name api.latihan.example.com;

    location /api/ {
        proxy_pass http://backend.example.com/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}
EOF
cat nginx/sites-available/api.latihan.example.com

Output yang Dihasilkan:

text 
upstream backend.example.com {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name api.latihan.example.com;

    location /api/ {
        proxy_pass http://backend.example.com/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Mari kita bedah directive demi directive:

  1. upstream backend.example.com { server 127.0.0.1:8080; }: memberi nama pada backend — aplikasi yang berjalan di loopback port 8080, alamat yang tidak terjangkau dari luar mesin sehingga satu-satunya pintu masuknya adalah Nginx ini. Nama upstream hanyalah label pilihan kita, bukan alamat DNS.
  2. server_name api.latihan.example.com: subdomain berbeda pada mesin yang sama — virtual host memisahkan trafik situs utama dan API tanpa IP tambahan.
  3. location /api/: hanya permintaan di bawah path /api/ yang diteruskan; path lain pada situs ini tetap dilayani sendiri oleh Nginx.
  4. proxy_pass http://backend.example.com/: meneruskan permintaan ke backend bernama itu. Garis miring di ujung punya makna penting: bagian yang cocok dengan location (/api/) diganti dengan / — permintaan /api/pengguna tiba di backend sebagai /pengguna. Tanpa garis miring tersebut, path asli diteruskan utuh.
  5. proxy_set_header Host $host: nama domain asli yang diminta klien diteruskan ke backend, bukan nama upstream — penting bila backend juga memakai virtual host.
  6. proxy_set_header X-Real-IP $remote_addr: dari sudut pandang backend, semua koneksi datang dari loopback; header ini meneruskan IP klien asli agar aplikasi bisa mencatat dan membatasinya.

Dengan tiga konfigurasi ini — peta direktori, situs statis, dan proxy — siklus hidup Nginx kita sudah lengkap. Variasi lanjutannya seperti load balancing antar beberapa backend, buffering, dan timeout dibedah di Chapter Reverse Proxy , sementara jejak semua trafiknya dibaca di Chapter Web Server Logs . Sebelum itu, mari berkenalan dengan sejawat tuanya yang punya cara kerja sama sekali berbeda: Apache HTTP Server, di Chapter Apache HTTP Server .

Referensi lanjut: panduan awal Nginx untuk peta konsepnya, serta dokumentasi ngx_http_proxy_module untuk daftar lengkap directive proxy.