DEV Community

Cover image for Nginx Load Balancing with DNS-Based Service Discovery on Incus
hardyweb
hardyweb

Posted on

Nginx Load Balancing with DNS-Based Service Discovery on Incus

#infrastructure #networking #architecture #devops

Nginx Load Balancing with DNS-Based Service Discovery on Incus

Hari ini saya buat satu practical lab untuk memahami Nginx Load Balancing, DNS-based Service Discovery, dan operational logging dalam persekitaran self-hosted menggunakan Incus.

Lab ini bermula dengan architecture yang simple:

Client
   │
   ▼
Nginx LB
   │
   ├──► web01
   └──► web02
Enter fullscreen mode Exit fullscreen mode

Kemudian saya tambah satu DNS server supaya backend tidak perlu bergantung sepenuhnya kepada hard-coded IP address.

1. Architecture

Final architecture:

                         DNS
                    dns / dnsmasq
                    10.107.109.18
                         ▲
                         │
                  DNS lookup:
                   web.incus
                         │
                         │
                    Nginx LB
                   10.107.109.69
                         │
                  Load Balancing
              ┌──────────┼──────────┐
              ▼          ▼          ▼
            web01      web02      web03
            .100        .253        .xxx
Enter fullscreen mode Exit fullscreen mode

Ada dua jenis communication flow dalam architecture ini.

DNS resolution 

Nginx LB ──────► DNS
                  │
                  └── web.incus
                       ↓
                  .100, .253, .xxx
Enter fullscreen mode Exit fullscreen mode

DNS hanya digunakan untuk mengetahui IP address backend.

HTTP traffic 

Client
  │
  ▼
Nginx LB
  │
  ├────► web01
  ├────► web02
  └────► web03
Enter fullscreen mode Exit fullscreen mode

DNS tidak membawa HTTP traffic.

DNS hanya menjawab:

Where is web.incus?

Nginx kemudian menggunakan IP yang diperoleh daripada DNS untuk melakukan load balancing.

2. Static / Hard-Coded Upstream

Cara paling mudah untuk configure Nginx Load Balancer ialah dengan meletakkan IP backend secara terus.

Contoh:

upstream backend {
    server 10.107.109.100;
    server 10.107.109.253;
}
Enter fullscreen mode Exit fullscreen mode

Architecture:

Nginx LB
   │
   ├──► 10.107.109.100
   │
   └──► 10.107.109.253
Enter fullscreen mode Exit fullscreen mode

Kelebihan

  • Simple
  • Mudah difahami
  • Predictable
  • Sesuai untuk environment kecil
  • Tidak memerlukan DNS service discovery

Kekurangan

Kalau tambah web03:

web01
web02
web03
Enter fullscreen mode Exit fullscreen mode

Nginx configuration perlu diubah:

upstream backend {
    server 10.107.109.100;
    server 10.107.109.253;
    server 10.107.109.xxx;
}
Enter fullscreen mode Exit fullscreen mode

Kemudian configuration perlu divalidasi dan biasanya Nginx perlu di-reload.

3. DNS-Based Service Discovery

Pendekatan kedua ialah menggunakan hostname sebagai service identity.

Contohnya:

web.incus
Enter fullscreen mode Exit fullscreen mode

DNS:

web.incus
 ├── 10.107.109.100
 ├── 10.107.109.253
 └── 10.107.109.xxx
Enter fullscreen mode Exit fullscreen mode

Nginx tidak perlu mengetahui backend IP secara hard-coded.

Contoh:

resolver 10.107.109.18 valid=5s;

upstream backend {
    zone backend 64k;
    server web.incus resolve;
}
Enter fullscreen mode Exit fullscreen mode

Konsepnya:

             DNS
              │
              │ web.incus
              ▼
         ┌─────────────┐
         │  Nginx LB   │
         └──────┬──────┘
                │
       ┌────────┼────────┐
       ▼        ▼        ▼
     web01    web02    web03
Enter fullscreen mode Exit fullscreen mode

4. Why Use DNS?

DNS memberikan abstraction layer antara Load Balancer dan backend server.

Tanpa DNS:

Nginx
  │
  ├── 10.107.109.100
  ├── 10.107.109.253
  └── 10.107.109.xxx
Enter fullscreen mode Exit fullscreen mode

Dengan DNS:

Nginx
  │
  └── web.incus
         │
         ├── .100
         ├── .253
         └── .xxx
Enter fullscreen mode Exit fullscreen mode

Ini bermaksud service identity dipisahkan daripada server identity.

Contohnya, kalau web01 mendapat IP baru:

web.incus
    ↓
10.107.109.200
Enter fullscreen mode Exit fullscreen mode

Nginx tidak perlu mempunyai IP tersebut secara hard-coded.

DNS menjadi source of information mengenai lokasi service.

5. dnsmasq

Dalam lab ini saya menggunakan dnsmasq sebagai DNS service.

DNS server:

10.107.109.18
Enter fullscreen mode Exit fullscreen mode

Nginx LB menggunakan DNS tersebut:

resolver 10.107.109.18 valid=5s;
Enter fullscreen mode Exit fullscreen mode

Test DNS:

dig @10.107.109.18 web.incus
Enter fullscreen mode Exit fullscreen mode

Contoh result:

web.incus.    0    IN    A    10.107.109.100
web.incus.    0    IN    A    10.107.109.253
Enter fullscreen mode Exit fullscreen mode

Apabila web03 ditambah:

web.incus.    0    IN    A    10.107.109.100
web.incus.    0    IN    A    10.107.109.253
web.incus.    0    IN    A    10.107.109.xxx
Enter fullscreen mode Exit fullscreen mode

6. Dynamic DNS Resolution in Nginx

Bahagian penting dalam configuration ialah:

resolver 10.107.109.18 valid=5s;
Enter fullscreen mode Exit fullscreen mode

dan:

server web.incus resolve;
Enter fullscreen mode Exit fullscreen mode

resolver memberitahu Nginx DNS server yang perlu digunakan.

valid=5s menentukan tempoh DNS result dianggap valid oleh Nginx.

resolve membolehkan Nginx resolve hostname backend secara dynamic.

Konsep:

DNS changes
     │
     ▼
web.incus
     │
     ▼
Nginx re-resolves
     │
     ▼
Backend pool updated
Enter fullscreen mode Exit fullscreen mode

Ini lebih flexible berbanding hard-coded IP.

7. Adding a New Backend

Salah satu test penting ialah menambah web03.

Sebelum:

web.incus
 ├── web01
 └── web02
Enter fullscreen mode Exit fullscreen mode

Selepas:

web.incus
 ├── web01
 ├── web02
 └── web03
Enter fullscreen mode Exit fullscreen mode

Yang menarik ialah Nginx configuration tidak perlu ditukar untuk menambah backend baru.

DNS yang berubah.

Kemudian Nginx akan mendapatkan DNS information yang baru berdasarkan konfigurasi resolver.

Ini menunjukkan salah satu kelebihan utama DNS-based service discovery.

8. Important Lesson: DNS Discovery Is Not Health Checking

Satu perkara yang saya belajar ialah:

DNS Service Discovery ≠ Health Checking

DNS memberitahu:

web.incus
    ↓
IP addresses
Enter fullscreen mode Exit fullscreen mode

Tetapi DNS tidak semestinya tahu sama ada HTTP service pada IP tersebut sedang berfungsi.

Contohnya:

web.incus
 ├── web01 ✅
 ├── web02 ❌
 └── web03 ✅
Enter fullscreen mode Exit fullscreen mode

DNS mungkin masih return:

.100
.253
.xxx
Enter fullscreen mode Exit fullscreen mode

walaupun web02 tidak boleh menerima HTTP connection.

Oleh itu, production architecture mungkin memerlukan additional health-checking atau failure-handling mechanism.

9. Load Balancing vs High Availability

Saya juga belajar bahawa Load Balancing dan High Availability bukan perkara yang sama.

Load Balancing

Tujuan:

Client
  │
  ▼
Nginx LB
 ├──► web01
 ├──► web02
 └──► web03
Enter fullscreen mode Exit fullscreen mode

Ia mengagihkan traffic.

High Availability

Tujuan:

           LB / HA
          /       \
       LB01      LB02
Enter fullscreen mode Exit fullscreen mode

Ia memastikan service masih tersedia jika salah satu infrastructure component gagal.

Contohnya, Keepalived boleh digunakan untuk menyediakan virtual IP dan failover antara Load Balancer.

Jadi:

Load Balancing
    ≠
High Availability
Enter fullscreen mode Exit fullscreen mode

Tetapi kedua-duanya boleh digunakan bersama.

10. Nginx Operational Logging

Selepas Load Balancing berfungsi, saya tambah logging untuk melihat backend mana yang menerima request.

Contoh log format:

log_format lb '$remote_addr - $host [$time_local] '
              '"$request" $status $body_bytes_sent '
              'upstream=$upstream_addr '
              'upstream_status=$upstream_status '
              'request_time=$request_time '
              'upstream_response_time=$upstream_response_time';
Enter fullscreen mode Exit fullscreen mode

Kemudian:

access_log /var/log/nginx/lb_access.log lb;
Enter fullscreen mode Exit fullscreen mode

Log boleh mengandungi:

upstream=10.107.109.100:80
Enter fullscreen mode Exit fullscreen mode

atau:

upstream=10.107.109.253:80
Enter fullscreen mode Exit fullscreen mode

atau:

upstream=10.107.109.xxx:80
Enter fullscreen mode Exit fullscreen mode

Ini memberikan visibility kepada Load Balancer behaviour.

11. Testing

Test DNS 

dig @10.107.109.18 web.incus
Enter fullscreen mode Exit fullscreen mode

Test backend 

curl --noproxy '*' http://10.107.109.100/
curl --noproxy '*' http://10.107.109.253/
curl --noproxy '*' http://10.107.109.xxx/
Enter fullscreen mode Exit fullscreen mode

Test Nginx configuration 

nginx -t
Enter fullscreen mode Exit fullscreen mode

Inspect effective configuration 

nginx -T
Enter fullscreen mode Exit fullscreen mode

Test Load Balancer 

curl --noproxy '*' http://10.107.109.69/
Enter fullscreen mode Exit fullscreen mode

Watch Load Balancer logs 

tail -f /var/log/nginx/lb_access.log
Enter fullscreen mode Exit fullscreen mode

12. Troubleshooting Lesson

Satu masalah yang berlaku dalam lab ialah default Nginx configuration masih aktif.

Contohnya:

/etc/nginx/conf.d/default.conf
Enter fullscreen mode Exit fullscreen mode

Configuration tersebut menyebabkan Nginx default welcome page dipaparkan.

Walaupun Load Balancer configuration telah dibuat dengan betul, request masih boleh masuk ke default server.

Penyelesaian ialah memastikan hanya configuration yang diperlukan digunakan.

Ini mengajar satu perkara penting:

Jangan hanya melihat configuration file yang kita edit. Periksa effective configuration yang sebenarnya digunakan oleh Nginx.

Command yang berguna:

nginx -T
Enter fullscreen mode Exit fullscreen mode

Kemudian:

nginx -t
Enter fullscreen mode Exit fullscreen mode

sebelum reload.

13. Configuration Validation Workflow

Workflow yang saya gunakan:

Edit Configuration
       │
       ▼
    nginx -t
       │
       ▼
   Configuration OK?
      /       \
    NO         YES
    │           │
    ▼           ▼
 Fix config   Reload
                │
                ▼
             Test
                │
                ▼
              Logs
                │
                ▼
            Verify
Enter fullscreen mode Exit fullscreen mode

Ini lebih baik daripada terus restart service setiap kali membuat perubahan.

14. Security Perspective

Walaupun lab ini fokus kepada Load Balancing, terdapat beberapa security principles yang boleh dipelajari.

Configuration Management

Configuration perlu:

  • dikenal pasti
  • diubah secara terkawal
  • divalidasi
  • diuji
  • didokumentasikan

Network Security

Perlu memahami:

Client
  ↓
Load Balancer
  ↓
Backend network
Enter fullscreen mode Exit fullscreen mode

dan service mana yang boleh berkomunikasi antara satu sama lain.

Logging

Load Balancer logs membantu:

  • troubleshooting
  • monitoring
  • incident investigation
  • performance analysis
  • verification

Availability

Multiple backend servers boleh mengurangkan dependency kepada single server.

15. ISO/IEC 27001 Perspective

Lab ini bukan implementation penuh ISO/IEC 27001.

Sebaliknya, ISO/IEC 27001 digunakan sebagai reference framework untuk memahami bagaimana technical infrastructure berkait dengan information security.

Beberapa control yang relevan untuk pembelajaran:

Control Relevance
A.8.9 Configuration Management Nginx, DNS dan network configuration
A.8.15 Logging Nginx Load Balancer logs
A.8.16 Monitoring Activities Monitoring behaviour dan troubleshooting
A.8.20 Networks Security Network architecture dan communication
A.8.21 Security of Network Services DNS, HTTP dan Load Balancing services
A.8.32 Change Management Controlled configuration changes
A.5.30 ICT Readiness for Business Continuity Redundancy dan availability concepts

Penting untuk difahami bahawa control mapping sahaja tidak bermaksud sesuatu environment itu compliant.

Dalam audit sebenar, auditor masih memerlukan:

Risk
 ↓
Control
 ↓
Implementation
 ↓
Evidence
 ↓
Monitoring
 ↓
Review
 ↓
Improvement
Enter fullscreen mode Exit fullscreen mode

16. Key Lessons

Antara perkara utama yang saya pelajari:

  1. Load Balancing dan High Availability adalah dua fungsi yang berbeza.
  2. Nginx boleh digunakan sebagai HTTP Load Balancer.
  3. Backend boleh dirujuk menggunakan IP secara static.
  4. Backend juga boleh ditemui menggunakan DNS-based service discovery.
  5. DNS memberikan abstraction layer antara service dan server IP.
  6. resolver dan resolve membolehkan Nginx menggunakan dynamic DNS resolution.
  7. DNS discovery tidak sama dengan health checking.
  8. Logging penting untuk visibility dan troubleshooting.
  9. nginx -T sangat berguna untuk melihat effective configuration.
  10. Configuration changes perlu divalidasi sebelum reload.
  11. Redundancy pada backend membantu meningkatkan availability.
  12. Technical implementation boleh dianalisis menggunakan perspektif ISO/IEC 27001 tanpa mendakwa bahawa lab tersebut sendiri merupakan ISMS.

17. Final Architecture 

                         DNS
                    dns / dnsmasq
                    10.107.109.18
                         ▲
                         │
                  DNS lookup
                   web.incus
                         │
                         │
                    Nginx LB
                   10.107.109.69
                         │
                  Load Balancing
              ┌──────────┼──────────┐
              ▼          ▼          ▼
            web01      web02      web03
            .100        .253        .xxx
Enter fullscreen mode Exit fullscreen mode

The key concept is:

DNS = Service Discovery

Nginx = Load Balancer

Web01/Web02/Web03 = Backend Services

Nginx Logs = Operational Visibility
Enter fullscreen mode Exit fullscreen mode

Conclusion

The practical exercise demonstrated two fundamental approaches to Nginx Load Balancing.

The first approach uses static IP addresses, which is simple and suitable for small, stable environments.

The second approach uses DNS-based service discovery, where Nginx resolves a service name such as web.incus to determine the backend servers.

The second approach introduces additional flexibility but also introduces dependencies on DNS availability, DNS caching, TTL behaviour and backend health handling.

The most important lesson is that infrastructure components should not be viewed independently. DNS, Load Balancing, networking, configuration management, logging, availability and security all interact with each other.

From an ISO/IEC 27001 perspective, the exercise demonstrates how technical controls can be understood through the broader cycle of risk, control, implementation, evidence, monitoring and continual improvement.

Top comments (0)