Caddy kontra Nginx egy VPS-en: a konfigurációsfájl-összehasonlítás

example.com {
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Az Nginx-blokk TLS-sorai feltételezik, hogy a Certbot már lefutott. A fentihez hasonló HTTP upstream esetén a Caddy átadja a bejövő Host fejlécet, és beállítja a X-Forwarded-For, X-Forwarded-Proto, és X-Forwarded-Host alapértelmezés szerint. Az Nginxnél általában explicit módon adja hozzá a proxy-fejléceket, amikor az upstreamnek szüksége van az eredeti hosztra, sémára és klienscím-láncra. Ez a kompromisszum kicsiben: a Caddy gyakorlatias proxy-alapértelmezésekkel érkezik, míg az Nginx explicitebbé tesz ebből a viselkedésből többet.

Statikus fájlok kiszolgálása:

Caddyfile

example.com {
    root * /var/www
    file_server
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

Alapszintű hitelesítés, mindent egy felhasználónév és jelszó mögé véd:

Caddyfile

example.com {
    basic_auth {
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Mindkét eszköz a jelszót külön csatornán hasheli. A Caddy a caddy hash-password-t használja; az Nginx a htpasswd -t használja a .htpasswd fájl felépítéséhez. A direktíva a basic_auth a jelenlegi Caddyben, egyébként. Ez basicauth volt, amíg a v2.8.0 át nem nevezte, ahogy azt a Caddy basic_auth dokumentációmegjegyzi, és a régi útmutatók még mindig megbotlasztják rajta az embereket.

Profi tipp: Az a hash a Caddyfile-ban nem a jelszó. Ez bcrypt-kimenet a caddy hash-password-ből. Futtassa a parancsot, illessze be, amit kiír. A Caddy elutasítja a nyílt szövegű jelszavakat a konfigurációban, ami a helyes alapértelmezés és egy kis meglepetés első alkalommal.

A konfigurációk maguk érvelnek. A Caddy néhány sorba hajtja össze a TLS-t, az ésszerű proxy-fejléceket és egy átirányítást; az Nginx explicit és terjengős, és minden gombot a kezébe ad. Ha éveket töltött Nginxben, a terjengősség izommemória, és a vezérlés a lényeg. Ha nem, a Caddyfile egy olyan konfiguráció, amelyet fejben tud tartani. A gyakorlati lényeg egyszerű: a Caddy konfigurációja egy pillantásra könnyebben olvasható, míg az Nginx explicitebb vezérlést ad.

Teljesítmény és memória: a benchmarkok gondos olvasása

A publikált tesztek ugyanabba az általános irányba mutatnak: az Nginx általában kevesebb memóriát használ, és gyakran vezet a nyers áteresztőképességben, de ennek az előnynek a mértéke erősen függ a környezettől.

In egy harmadik féltől származó, négymagos VM-tesztszerint az Nginx megközelítőleg 48 000 kérést ért el másodpercenként, szemben a Caddy körülbelül 42 000-ével. Ugyanez a teszt 2,1 ms HTTPS p99 késleltetést jelentett az Nginxnél és 2,4 ms-ot a Caddynél. Ezeket egyetlen beállítás eredményeként kezelje, ne univerzális teljesítménybeli különbségként.

Az összehasonlító táblázatban szereplő memóriatartományok egy külön VPS-tesztbőlszármaznak. Egy másik, 50 000 egyidejű kapcsolatnál végzett szintetikus teszt 145 MB-ot jelentett az Nginxnél és 520 MB-ot a Caddynél, de ez a teszt lényegesen eltérő hardver- és munkaterhelési körülményeket használt. Az abszolút értékeit nem szabad közvetlenül összehasonlítani a fenti VPS-számokkal.

A megbízható következtetés szűkebb: az Nginxnek általában kisebb a memórialábnyoma, és hajlamos vezetni nagy áteresztőképességű vagy nagy párhuzamosságú munkaterheléseknél. Egy szokásos kis-közepes VPS fordított proxyhoz mindkettő általában elég gyors, ezért az üzemeltetési egyszerűség gyakran a hasznosabb döntő tényező.

A szakasz tanulsága: válasszon az üzemeltetés alapján, hacsak a szervere nem memóriakorlátos, vagy a saját terheléses tesztjei nem mutatják, hogy a proxy áteresztőképessége a szűk keresztmetszet.

A helyettesítő tanúsítvány csapdája (a Caddy nem mindig konfigurációmentes)

A Caddy automatizálhatja a helyettesítő tanúsítványokat, de nem az alapértelmezett HTTP-01 vagy TLS-ALPN-01 kihívásaival. Egy tanúsítvány a *.example.com DNS-01 érvényesítést igényel, amelyet a Let's Encrypt kötelezővé tesz a helyettesítő tanúsítványokhoz. Ez egy DNS-szolgáltató bővítményt (a Caddy binárisába xcaddy-vel beépítve) plusz egy API-tokent jelent a DNS-hosztjához, a tls blokkban konfigurálva. Ez nem az az egy-sort-gépelek-és-elsétálok történet, amelyet a Caddy hirdet.

Ez megcsípi azokat a homelab-felhasználókat, akik sok szolgáltatást tesznek egy általuk vezérelt valódi domain alá, például *.home.example.com, és feltételezik, hogy a helyettesítő tanúsítvány kiállítása ugyanolyan automatikus, mint app.example.com. Tisztán belső neveknél, mint például *.homelab.internal, kezelje azt helyi/belső PKI-területként, ne nyilvános Let's Encrypt helyettesítőként. Pontosan fogalmazva: a Caddy jól kezeli a helyettesítőket, csak nem az alapértelmezett kihívásokkal teszi, és a beállítás egy lépcsőfokkal fentebb van az egydomaines esethez képest. Az Nginx itt ugyanabban a cipőben jár, mivel a DNS-01 követelmény a Let's Encrypttől ered, nem a szervertől.

Ha GUI-t szeretne: Nginx Proxy Manager (egy rövid kitérő)

Az Nginx Proxy Manager egy másik állatfaj a fenti két eszközhöz képest, és megér egy bekezdést, mert a név összezavarja az embereket. Az NPM egy GUI-burkolat az Nginx felett: fordított proxy szabályokat és Let's Encrypt tanúsítványokat kezel egy webes felületen keresztül a port 81-en. Nem az Nginx mag, és nem úgy konfigurálják, ahogy az Nginx magot.

A kompromisszum a szokásos kattintás kontra konfiguráció. Az NPM a könnyű gomb, amíg le nem lép a boldog ösvényről. A konfigurációját egy alkalmazás-adatbázison keresztül kezelik, nem pedig egyetlen kézzel szerkesztett konfigurációs fájlon keresztül. Az alapértelmezett Docker-beállítás SQLite-ot használ, míg a MySQL/MariaDB és a PostgreSQL támogatott külső adatbázis-lehetőségek. Ez a különbség a hordozhatóságot is befolyásolja: egy Caddy-beállítás gyakran áthelyezhető egyetlen Caddyfile másolásával, míg egy Nginx Proxy Manager telepítéshez meg kell őrizni annak alkalmazásadatait és adatbázisát . Az NPM jó választás, ha valóban jobban szereti a kattintást a szerkesztésnél, és a beállítása egyszerű marad. Rossz választás egy infrastruktúra-mint-kód munkafolyamathoz.

Migrálás Nginxről Caddyre (mi fordítható át és mi nem)

Ha már Nginxen van, és mérlegeli a váltást, kezdje az automatizálással kapcsolatos elvárásai csökkentésével: van egy Caddy NGINX-konfigurációadapter, de hiányos, és nem szabad megbízható, egylövéses migrációs útként kezelni. Egy Nginxről Caddyre való migráció többnyire kézi átírás, és a nagy része rövidebbé válik.

Ami átfordítható és egyszerűbbé válik, a Caddy közösség átalakítási útmutatója:

• szerint: HTTP upstreameknél a reverse_proxy átadja a bejövő Host fejlécet, és alapértelmezés szerint beállítja a szabványos X-Forwarded-* fejléceket, így azon proxy_set_header sorok többsége eltűnik.
• A PHP egy location blokkból, amely try_files plusz fastcgi_pass plusz egy csomó paramétert tartalmaz, egyetlen php_fastcgi direktívába zsugorodik össze.
• A WebSocket-kezelés automatikus a Caddy v2-ben. Ha egy útmutató azt mondja, hogy adjon hozzá egy külön websocket direktívát, az egy Caddy v1 maradvány. Hagyja figyelmen kívül.

Ami nem fordítható át automatikusan: bármi, ami egy adott Nginx-modulhoz kötődik, amellyel a Caddy nem rendelkezik, az összetett átírási és location-logika, amelyet inkább újra kell gondolnia, mintsem átültetnie, valamint a helyettesítő tanúsítványbeállítások, amelyek visszavezetik a fenti szakasz DNS-kihívás beállításához. Számoljon a modulokkal és az átírásokkal; a többi általában nettó sorcsökkenés.

Melyiket telepítse? (A döntés)

Látta a konfigurációkat, a számokat, a helyettesítő csapdát és a migráció költségét, tehát íme, hova jut ki a dolog. Telepítse a Caddyt, ha egyéni fejlesztő vagy kis csapat, ez egy friss VPS-telepítés, beállítom-és-elfelejtem TLS-t szeretne, egyszerű útválasztású Dockert futtat, vagy egyszerűen csak egy olyan konfigurációt szeretne, amely belefér az izommemóriába. Ez a legtöbb ember, aki ezt olvassa.

Telepítse az Nginxet, ha finomhangolt vezérlésre vagy a kiforrott ökoszisztémájából egy adott modulra van szüksége, ha teljesítményt sajtol ki egy memóriakorlátos szerverből, ha nagy párhuzamosságú statikusfájl-kiszolgálást végez, vagy ha a csapata már mély Nginx-szakértelemmel és egy halom működő konfigurációval rendelkezik. Ezek szilárd okok, és ha valamelyik az öné, az Nginx a helyes döntés. Ez nem az az eset, amikor a régebbi eszköz a rossz eszköz.

Bármelyiknél is köt ki, a következő lépés az, hogy felteszi a gépre. Mindkettő Caddy és Nginx elérhető egykattintásos telepítésként a piacterünkön, így átugorhatja a telepítési munkát, és egyenesen a Caddyfile-hoz vagy a szerverblokkhoz mehet. Egy 1 GB-os VPS ésszerű kiindulópont egy alacsony forgalmú, egyoldalas telepítéshez, de a szervert a proxy mögötti alkalmazáshoz és forgalomhoz méretezze, ne pusztán a proxyhoz. Ha a Caddyt önállóan üzemeltetett szolgáltatások bejárati ajtajaként használja, elhelyezkedhet egy Prometheus és Grafana monitorozó verem vagy egy Uptime Kuma telepítés előtt anélkül, hogy külön TLS-eszközkészletre lenne szükség.

A szakasz tanulsága: válassza a Caddyt, hacsak nincs konkrét oka, amely az Nginxre mutat.

Gyakran ismételt kérdések