Deep Dive Hạ Tầng Kioskgaming
Từ Cloudflare đến Nginx và toàn bộ backend services

1. Tổng quan kiến trúc

Toàn bộ traffic public của platform đi qua 3 tầng: Cloudflare (DNS + CDN + TLS termination) → nginx-lb (một container nginx làm reverse proxy / load balancer, định tuyến theo server_name) → app servers / data services / tools trên mạng nội bộ 10.0.0.0/24. Mọi thành phần đều chạy Docker, mỗi service một file docker-compose riêng ở root repo.

Cấu hình Nginx minh hoạ theo từng chặng

Các đoạn cấu hình thật tương ứng với từng mũi tên trong sơ đồ trên — chi tiết đầy đủ xem mục 3–5.

set_real_ip_from 173.245.48.0/20;
… (15 dải CIDR của Cloudflare) …
set_real_ip_from 131.0.72.0/22;
real_ip_header CF-Connecting-IP;

upstream backend {
    least_conn;
    server 10.0.0.5:3001 max_fails=3 fail_timeout=30s;
    …(8 instance: 10.0.0.5 + 10.0.0.4, :3001–3004)…
}

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

worker_processes auto;
worker_connections 1024;
gzip on; gzip_comp_level 6;
include conf.d/*.conf;

image: nginx:alpine
restart: always
network_mode: host

22/tcp  ← Any IPv4/IPv6 (không giới hạn)
80/tcp  ← 5/15 dải Cloudflare (thiếu 10 dải!)
443/tcp ← 15/15 dải (nginx không listen 443)

Điểm mấu chốt cần nắm trong 60 giây

• Một cửa ngõ duy nhất: mọi domain public đều trỏ về container nginx-lb chạy trên V1-Kiosk (178.156.194.24) — vừa reverse proxy vừa load balancer, và là điểm lỗi đơn (SPOF): V1 chết là cả hệ mất, dù các server khác vẫn sống.
• Cloudflare Flexible mode: client ↔ Cloudflare là HTTPS, Cloudflare ↔ origin là HTTP thuần :80. Origin không có TLS. Backend phân biệt HTTPS nhờ header X-Forwarded-Proto do Cloudflare gắn.
• 2 tầng lọc source-IP đang lệch nhau: nginx tin 15 dải Cloudflare, nhưng Hetzner Firewall ở cổng :80 chỉ whitelist 5/15 dải — request thật từ 10 dải còn lại có thể bị chặn trước khi tới nginx. SSH (:22) lại mở cho toàn Internet. Xem mục 13.
• API production chạy 8 instance (2 server × 4 port), cân bằng tải least_conn.
• Data tập trung trên 10.0.0.2 (Server 3): Redis master + Postgres 16 master; replicate sang 10.0.0.3 / Server 4 (Redis slave + Postgres slave, xem mục 7). Redis/OpenSearch không có auth ứng dụng, nhưng Hetzner Firewall (firewall duy nhất trong project) không mở port của chúng ra Internet.
• Log 2 tầng: Dozzle xem nhanh per-server; Fluent Bit → OpenSearch → Dashboards để xem tập trung. Cả 4 container Dozzle (V1–V4) báo unhealthy do healthcheck của image sai — không phải sự cố, chỉ cần sửa/tắt healthcheck (rủi ro #11).
• Hostname không đáng tin để nhận diện server: V2 và V3 cùng trả về hostname ubuntu-8gb-ash-1 khi SSH — chỉ IP mới phân biệt chắc chắn.

2. Danh sách VPS

Nguồn: iplist, comment trong nginx/conf.d/*.conf, các file compose; tên server/plan/IP server 5: Hetzner Console (project "Kiosk VPS", region Ashburn VA / us-east, screenshot 2026-07-03). Vai trò từng server suy từ IP nội bộ mà nginx trỏ tới và comment trong conf.

* vCPU/RAM theo catalog plan CCX (dedicated vCPU) của Hetzner; disk theo giá trị hiển thị trong console. Server tạo cách đây 4–9 tháng (V1 lâu nhất). iplist trong repo thiếu Server 5 — nên bổ sung.

3. Tầng Cloudflare (edge) edge

3.1. SSL mode: Flexible

Toàn bộ domain *.kioskservice.club proxy qua Cloudflare với SSL mode Flexible:

Client ──HTTPS :443──▶ Cloudflare ──HTTP :80──▶ nginx-lb (origin)

• TLS kết thúc tại Cloudflare. Origin chỉ nghe HTTP :80 — không có listen 443 nào trong conf.d/.
• Cloudflare tự gắn X-Forwarded-Proto: https khi client dùng HTTPS; nginx forward nguyên giá trị này về backend qua proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto để app biết phiên gốc là HTTPS (cookie Secure, redirect…). Nguồn: nginx/conf.d/default.conf:46-54
• Riêng OmniDB có khối map fallback: nếu header rỗng thì ép thành https để tránh 403 sau login do cookie Secure. Nguồn: nginx/conf.d/omnidb.conf:6-10

3.2. Khôi phục IP thực của client

Vì mọi request tới origin đều xuất phát từ IP của Cloudflare, nginx dùng module realip: mỗi server block khai báo 15 dải IP Cloudflare qua set_real_ip_from và real_ip_header CF-Connecting-IP — nghĩa là: nếu request đến từ dải IP Cloudflare, lấy giá trị header CF-Connecting-IP làm $remote_addr. Nhờ đó log và rate-limit phía sau thấy đúng IP người dùng. Nguồn: nginx/conf.d/default.conf:28-43 (lặp lại trong mọi file conf)

set_real_ip_from 173.245.48.0/20;   set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;   set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;   set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;   set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;  set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;    set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;     set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
real_ip_header CF-Connecting-IP;

3.3. Header Cloudflare được chuyển tiếp về backend

3.4. Hệ quả kiến trúc của Flexible mode

• Không mã hoá chặng Cloudflare → origin: dữ liệu (kể cả token/credentials trong request) đi HTTP thuần trên Internet giữa POP Cloudflare và server. Nâng cấp lên Full (strict) cần origin có cert (Cloudflare Origin CA là đủ).
• Origin nghe :80: nginx không có cơ chế origin-check; việc chặn IP ngoài dải Cloudflare do Hetzner Firewall đảm nhiệm — rule :80 chỉ cho dải Cloudflare vào, nhưng đang thiếu 10/15 dải (rủi ro #13, mục 13).
• Bảo vệ WAF/Bot/CDN của Cloudflare chỉ có tác dụng khi traffic thực sự đi qua Cloudflare.

3.5. Mô hình DNS record (từ README trong repo)

Các README hướng dẫn map DNS theo nguyên tắc: mỗi domain là một A record (Proxied) trỏ thẳng vào IP public của server đích — ví dụ log-server1 → IP public Server 1, log-server2 → IP public Server 2, redisinsight/pgadmin → IP public Server 4. Nguồn: README-DOZZLE.md (mục "Map Domain trong Cloudflare"), README-REDISINSIGHT.md, README-OMNIDB.md.

4. Nginx gateway (nginx-lb) gateway

4.1. Triển khai container

Image

nginx:alpine

Container

nginx-lb, restart: always

Network

network_mode: host — để gọi thẳng các IP nội bộ 10.0.0.x không qua NAT/bridge

Mount

./nginx/nginx.conf → /etc/nginx/nginx.conf (ro)
./nginx/conf.d → /etc/nginx/conf.d (ro)
./nginx/logs → /var/log/nginx
./nginx/.htpasswd-redisinsight, ./nginx/.htpasswd-app-logs (ro)

Nguồn: nginx.yml:1-15. Repo gốc trên GitLab tên kiosk-deployments; thư mục deploy trên server là kiosk_deploy/kiosk_deployments (suy từ prefix tên volume trong các lệnh backup của README). Host: V1-Kiosk (178.156.194.24 / 10.0.0.5); xem mục 3.5.

4.2. Cấu hình lõi (nginx/nginx.conf)

Nguồn: nginx/nginx.conf:1-37. Lưu ý: chưa bật keepalive tới upstream (dòng keepalive 32 đang comment trong default.conf:15) — mỗi request tạo kết nối TCP mới tới backend.

4.3. Log & logrotate

• Access/error log ghi ra nginx/logs/ trên host, mỗi domain một cặp file riêng (dev-api-access.log, api-gamify-pro-access.log…).
• Logrotate: hàng ngày, giữ 7 bản, nén (delaycompress), sau khi rotate gửi nginx -s reopen vào container. Cài qua setup-nginx-logrotate.sh → /etc/logrotate.d/nginx-kiosk. Nguồn: nginx/logrotate.conf

4.4. Quy trình thay đổi cấu hình (bắt buộc)

# 1. Sửa file trong nginx/conf.d/ (repo local chỉ là nơi soạn — phải đồng bộ lên server)
# 2. Kiểm tra cú pháp TRƯỚC khi reload:
docker exec nginx-lb nginx -t
# 3. Reload không downtime:
docker exec nginx-lb nginx -s reload

5. Domain routing & upstream

5.1. Bảng định tuyến đầy đủ

5.2. Upstream API production — phân tích

upstream backend {
    least_conn;                                    # chọn server ít kết nối nhất
    server 10.0.0.5:3001 weight=1 max_fails=3 fail_timeout=30s;
    server 10.0.0.5:3002 weight=1 max_fails=3 fail_timeout=30s;
    server 10.0.0.5:3003 weight=1 max_fails=3 fail_timeout=30s;
    server 10.0.0.5:3004 weight=1 max_fails=3 fail_timeout=30s;
    server 10.0.0.4:3001 weight=1 max_fails=3 fail_timeout=30s;
    server 10.0.0.4:3002 weight=1 max_fails=3 fail_timeout=30s;
    server 10.0.0.4:3003 weight=1 max_fails=3 fail_timeout=30s;
    server 10.0.0.4:3004 weight=1 max_fails=3 fail_timeout=30s;
}

• 8 instance backend Node.js (4 port × 2 server), trọng số bằng nhau.
• least_conn phù hợp API có thời gian xử lý không đều — request mới dồn về instance đang rảnh nhất, thay vì xoay vòng mù như round-robin.
• Health check bị động: instance bị đánh dấu down sau 3 lần lỗi liên tiếp (max_fails=3) và bị loại khỏi pool trong 30 giây (fail_timeout=30s), sau đó được thử lại. Không có active health check (cần nginx Plus hoặc module ngoài — đã ghi chú trong file). Nguồn: nginx/conf.d/default.conf:1-16, README-NGINX.md
• Riêng gamify-pro dùng round-robin mặc định (không khai báo least_conn). api-gamify-pro.conf:1-6

5.3. Tham số proxy chung của mọi server block

6. Luồng request mẫu (API production)

7. Data services data

Mỗi service một file compose ở root repo, chạy độc lập: docker compose -f <file>.yml up -d.

7.1. Redis 7.2 — master / slave / dev

Nguồn: redis-master.yml, redis-slave.yml, redis-dev.yml; host slave xác nhận qua redis-cli info replication (slave0:ip=10.0.0.3,state=online,lag=0). Replication một chiều master→slave; repo không có Sentinel/Cluster ⇒ không tự động failover — slave chỉ dùng đọc/dự phòng thủ công.

7.2. PostgreSQL 16 — streaming replication

• Master (postgres-master.yml): db kiosk, user postgres (mật khẩu plaintext trong yml — không nêu ở đây), network_mode: bridge, volume postgres-master-data, init script setup-master.sh mount vào docker-entrypoint-initdb.d.
• Archive WAL bật (archive_mode=on, copy vào /var/lib/postgresql/archive/ trong container) — hỗ trợ PITR, nhưng archive nằm cùng máy nên không chống được mất cả server.
• Slave publish cổng host 5433 (không phải 5432) — kết nối đọc từ app phải trỏ <host-slave>:5433. hot_standby_feedback=on giảm lỗi query bị hủy trên slave, đổi lại có thể giữ bloat trên master.

7.3. RabbitMQ 3.13

File

rabbitmq.yml — image rabbitmq:3.13-management, host 10.0.0.3 (Server 4)

Port

5672 (AMQP) · 15672 (Management UI — không thấy expose qua nginx, truy cập trực tiếp/SSH tunnel)

Tài khoản

user kiosk, vhost / (mật khẩu plaintext trong yml)

Giới hạn

memory 1024M; healthcheck rabbitmq-diagnostics ping/10s; volume rabbitmq-data

8. Log & Observability observability

8.1. Kiến trúc 2 tầng

1. Xem nhanh per-server: mỗi server chạy 1 container Dozzle (:8080, host network, đọc docker.sock read-only, chỉ hiện container đang chạy, tail 1000 dòng) — truy cập qua log-server1…4.kioskservice.club.
2. Tập trung: Fluent Bit trên 10.0.0.6 gom log → OpenSearch → xem bằng OpenSearch Dashboards tại app-logs.kioskservice.club (basic auth ở nginx).

8.2. Quy tắc đặt tên index (Lua filter)

fluent-bit/tag_prefix.lua (hàm append_fluentbit_tag) gán 2 field cho mỗi record: docker_log_tag (tag gốc) và logstash_prefix. Quy tắc chuyển tag → prefix:

• Tag fluentd dạng docker.kiosk-gaming-backend.dev → chuẩn hoá lowercase, .→-, bỏ tiền tố docker-, thêm hậu tố -logs ⇒ index kiosk-gaming-backend-dev-logs-YYYY.MM.DD.
• Tag từ INPUT tail (chứa var.lib.docker.containers hoặc /) → gộp chung docker-tail-logs-* (tránh mỗi container ID thành một index riêng).
• Tag rỗng/không hợp lệ → misc-logs. Prefix cắt tối đa 120 ký tự.

8.3. Chống phình log ở tầng Docker

• docker-daemon.json (áp bằng setup-docker-logs.sh): mặc định toàn daemon json-file, max-size 10m, max-file 3, compress — mỗi container tối đa ~30MB log trên đĩa.
• Các compose quan trọng cũng khai báo lặp lại cùng logging options ở mức service.
• Script kiểm tra: check-logs.sh, check-dozzle.sh, check-redisinsight.sh. README khuyến nghị đặt cron 0 2 * * * chạy check-logs.sh, log giám sát ghi ra /var/log/kiosk-logs-check.log.
• Dung lượng dự kiến sau khi setup đầy đủ (theo README-LOG-MANAGEMENT.md): mỗi container ~30MB (10m×3), log nginx ~70–100MB/7 ngày — tổng ~100–150MB/server, tự xoá. Lưu ý: đổi daemon.json phải restart Docker và restart từng container mới có hiệu lực.

8.4. Chi tiết setup & giới hạn (đúc kết từ các README)

• Prerequisite kernel cho OpenSearch: host phải đặt vm.max_map_count=262144 (sysctl, persist qua /etc/sysctl.d/99-opensearch.conf) — thiếu cái này OpenSearch không lên. README-OPENSEARCH-SETUP.md §1
• Cách một service mới gửi log vào pipeline: join network external kiosk-logging + khai báo logging driver trong compose:

  networks:
    kiosk-logging: { external: true, name: kiosk-logging }
  services:
    ten-service:
      networks: [default, kiosk-logging]
      logging:
        driver: fluentd
        options:
          fluentd-address: tcp://fluent-bit:24224   # cùng host
          tag: docker.ten-service.env               # tag → tên index

  Service ở máy khác thì trỏ tcp://10.0.0.6:24224 (cần firewall nội bộ cho phép; tuyệt đối không mở 24224 ra Internet). README-OPENSEARCH-SETUP.md §5
• Xem log trên Dashboards: Discover → Create index pattern (vd kiosk-*-logs-*), field thời gian @timestamp.
• Sự cố lịch sử đáng nhớ: file Lua từng tên add_log_tag.lua bị Docker mount nhầm thành thư mục trên host → Fluent Bit lỗi "Is a directory"; đã đổi tên thành tag_prefix.lua. Nếu gặp lại: rm -rf fluent-bit/add_log_tag.lua rồi git pull. README-OPENSEARCH-SETUP.md §8
• Khuyến nghị production chưa làm (từ README-OPENSEARCH-PRODUCTION.md): bật security plugin + đặt admin password qua env file không commit; retention bằng ISM hoặc cron xoá index theo ngày (hiện chưa có — disk Server 5 sẽ đầy dần); backup index bằng Snapshot API; heap giữ 512m–1g khi host còn chạy service khác, chỉ tăng 2–4g nếu OpenSearch là workload chính.

9. Gamification engine

Thư mục gamify-engine/ chứa script + env deploy backend gamification trên server 10.0.0.6 (code nằm ở repo GitLab riêng kiosk_gamification_engine, không phải trong repo nginx).

10. Bảng port tổng hợp

11. Playbook kiểm tra hạ tầng (health-check)

Mục này gộp lại cách xác minh từng tầng đang sống hay chết, đi từ ngoài (Cloudflare) vào trong (data server) — dùng khi nghi ngờ sự cố, trước/sau khi reload nginx, hoặc kiểm tra định kỳ. Nguyên tắc: luôn kiểm tra từ layer gần user nhất trước (domain public) rồi mới đi sâu vào server nội bộ, để khoanh vùng nhanh layer nào đang lỗi.

11.1. Bảng tra nhanh theo server

11.2. Layer 1 — Edge & gateway (từ máy bất kỳ, không cần SSH)

# Domain có trả lời qua Cloudflare không (chú ý header cf-ray = đã qua Cloudflare)
curl -sI https://api.kioskservice.club | grep -i "cf-ray\|http"

# Cú pháp nginx hiện tại có hợp lệ không (chạy TRÊN V1, trước khi reload)
docker exec nginx-lb nginx -t

# nginx-lb có đang chạy, container nào restart gần đây (dấu hiệu crash loop)
docker ps --filter name=nginx-lb --format "table {{.Names}}\t{{.Status}}"

Kết quả lần chạy gần nhất trên V1 và V2: cả hai nginx -t OK (V1, gateway); 4/4 instance API prod (:3001–3004) + 1 dev (:4001) đều healthy trên mỗi server; CPU/RAM thấp, còn nhiều headroom trên cả hai (~90-100MB/container / 8GB RAM). Riêng dozzle unhealthy trên cả hai — xem 11.4.

11.3. Layer 2 — Data server (V3-Kiosk, 10.0.0.2)

# Redis master
docker exec -it redis-master redis-cli ping                     # → PONG
docker exec -it redis-master redis-cli info replication          # connected_slaves khớp số slave đang trỏ về 10.0.0.2
docker exec -it redis-master redis-cli info memory | grep used_memory_human

# Postgres master
docker exec -it postgres-master pg_isready
docker exec -it postgres-master psql -U postgres -d kiosk -c "SELECT * FROM pg_stat_replication;"
# mỗi dòng trả về = 1 slave đang replicate; state "streaming" là khỏe, thiếu dòng ⇒ slave rớt kết nối

Tên container thực tế tuỳ container_name khai báo trong redis-master.yml / postgres-master.yml — dùng docker ps để xác nhận nếu lệnh trên báo "No such container".

Kết quả lần chạy gần nhất: Redis PONG, replica online lag=0; Postgres pg_isready OK, replica streaming. Server chạy đúng 3 container (postgres-master, redis-master, dozzle). Riêng dozzle unhealthy — xem 11.4.

11.4. Layer 2 — Tools server (V4-Kiosk, 10.0.0.3)

V4 chạy 7 container: postgres-slave, redis-slave, redis-dev, redisinsight, omnidb, dozzle, rabbitmq.

docker ps --format "table {{.Names}}\t{{.Status}}"
# kỳ vọng cả 7 container "Up"; chú ý cột STATUS có "(healthy)" / "(unhealthy)" / không có gì (container không khai báo healthcheck)

• RedisInsight (redisinsight.kioskservice.club, basic auth) — dùng để xem trực quan Redis master/slave đang sống, số key, memory realtime, thay cho gõ lệnh redis-cli thủ công.
• OmniDB / pgadmin (pgadmin.kioskservice.club) — xem Postgres master :5432 và slave :5433 qua UI, chạy query kiểm tra trực tiếp.
• Cả hai đứng sau nginx nên cũng gián tiếp xác nhận layer gateway + routing tới 10.0.0.3 còn thông.

11.5. Layer 2 — Gamify + Log hub (10.0.0.6)

# OpenSearch cluster (chạy trên chính server 10.0.0.6, hoặc qua SSH tunnel)
curl -s localhost:9200/_cluster/health?pretty          # status: green/yellow/red
curl -s localhost:9200/_cat/indices?v                  # danh sách index, phát hiện index phình bất thường

# Fluent Bit — có đang nhận/đẩy log không
curl -s localhost:2020/api/v1/metrics | head -50        # HTTP monitor plugin, :2020

# Gamify backend
docker ps --filter name=app --format "table {{.Names}}\t{{.Status}}"   # đủ 4 instance :7003-7006 (pro) / 1 instance :4003 (dev)

Kết quả lần chạy gần nhất: V5 chạy đúng 8 container — gamify deployments_app_1..4 (prod) + deployments_app-dev_1 (dev, đủ 5 healthy, khớp scale compose mục 9), opensearch (healthy), opensearch-dashboards, fluent-bit. Chi tiết OpenSearch/Fluent Bit xem mục 8.4.

11.6. Kiểm tra end-to-end (checklist nhanh khi nghi có sự cố)

1. curl -sI https://api.kioskservice.club — có cf-ray + status 2xx/3xx? Không có ⇒ dừng ở DNS/Cloudflare, chưa cần SSH vào server nào.
2. SSH V1 → docker exec nginx-lb nginx -t && docker ps — gateway sống, cú pháp hợp lệ?
3. docker logs --tail 100 nginx-lb — có lỗi connect() failed tới backend không (chỉ điểm app server nào chết)?
4. SSH vào app server bị nghi (V1/V2) → docker ps đủ 4 instance API + docker stats không có container OOM/restart loop.
5. Nếu API trả lỗi liên quan dữ liệu → SSH V3, chạy 11.3 (Redis ping, Postgres pg_isready).
6. Cần log chi tiết để debug tiếp → Dozzle (log-server1…4) cho log tức thời, hoặc Dashboards (app-logs) để tra theo thời gian/từ khoá trên toàn hệ.

12. Vận hành thường gặp

13. Rủi ro & khuyến nghị

14. Phụ lục

14.1. Cấu trúc repo nginx/

nginx/                          # repo hạ tầng (infra/ops), KHÔNG chứa code app
                                # tên gốc GitLab: kiosk-deployments (dustin.le)
├── nginx.yml                   # compose container nginx-lb
├── nginx/
│   ├── nginx.conf              # cấu hình lõi
│   ├── conf.d/                 # 8 file conf ↔ 10 domain (mục 5)
│   └── logrotate.conf
├── redis-master.yml / redis-slave.yml / redis-dev.yml
├── postgres-master.yml / postgres-slave.yml
├── rabbitmq.yml
├── opensearch.yml              # OpenSearch + Dashboards + Fluent Bit
├── fluent-bit/                 # fluent-bit.conf + tag_prefix.lua
├── dozzle.yml / redisinsight.yml / omnidb.yml
├── gamify-engine/              # script + env deploy (dev/, production/)
├── setup-*.sh, check-*.sh      # script vận hành
├── docker-daemon.json          # giới hạn log Docker toàn daemon
├── iplist                      # IP public 4 server
├── env, env-dev                # ⚠ env thật chứa secret
└── README-*.md                 # tài liệu từng thành phần

14.2. Tài liệu tham chiếu trong repo

Tài liệu lập từ repo /Users/nhim/dev/2026/kiosk/nginx + khảo sát trực tiếp 5 server, cập nhật 2026-07-04. Mật khẩu/token trong các file cấu hình được cố ý lược bỏ. Sơ đồ blueprint: So-Do-He-Thong.html · kế hoạch xử lý các rủi ro mục 13: so-sanh-va-ke-hoach-chuyen-doi.html · kiến trúc đích: he-thong-dich.html.