#Caddy
Jika Anda sudah memiliki nama domain dan ingin mengonfigurasi HTTPS sesegera mungkin, nb proxy caddy biasanya merupakan metode masuk yang paling bebas kekhawatiran.
Daripada mempertahankan konfigurasi sertifikat Nginx sendiri, Caddy lebih seperti pintasan default untuk "menjalankan lapisan entri terlebih dahulu".
Kapan sebaiknya menggunakan Caddy?
Secara umum, Caddy diberikan prioritas dalam situasi berikut:
- Anda sudah memiliki nama domain dan ingin mengakses HTTPS sesegera mungkin
- Anda tidak ingin menyimpan terlalu banyak detail sertifikat dan TLS
- Yang Anda butuhkan hanyalah lapisan masuk yang sederhana dan stabil
Jika Anda sudah menggunakan Nginx untuk mengelola banyak situs di server, atau Anda perlu melakukan caching yang lebih berat, kontrol akses, dan aturan penyesuaian nanti, maka akan lebih lancar untuk terus melihat Nginx.
Pertama ikuti ketiga perintah ini.
Jika Anda hanya ingin menjalankan lapisan entri Caddy terlebih dahulu, cukup mengingat tiga perintah berikut secara default:
Jika Caddy sudah diinstal secara lokal, ubah saja entri pertama menjadi nb proxy caddy use local.
Di sebagian besar skenario, cukup mengeksekusi use terlebih dahulu, lalu generate, dan terakhir reload. Untuk detail lainnya dan perintah lainnya, lihat bab berikut atau referensi CLI.
Langkah 1: Pilih sendiri cara menjalankan Caddy
Jika Caddy sudah terinstal di mesin saat ini, gunakan saja use local.
Jika Anda ingin menggunakan Caddy versi Docker, gunakan use docker.
local / docker di sini mengacu pada cara Caddy beroperasi.
Menggunakan Caddy versi Docker:
Menggunakan instalasi lokal Caddy:
Jika nanti Anda lupa metode mana yang sedang dipilih, Anda dapat menjalankan:
Langkah 2: Jalankan generate
generate digunakan untuk menghasilkan konfigurasi Caddy sesuai dengan env yang ditentukan. Cara paling umum untuk menulisnya adalah:
Jika Anda juga ingin menentukan port masuk, Anda juga dapat menulisnya bersama-sama:
Maksud dari parameter disini adalah:
--env: Tentukan env CLI mana yang akan menghasilkan konfigurasi--host: Tentukan nama domain untuk akses eksternal--port: Tentukan port entri proxy
Bagi Caddy, --host sangat penting. Dalam lingkungan formal, cobalah untuk meneruskan nama domain yang telah diselesaikan ke server saat ini secara default, sehingga akses HTTPS akan lebih natural.
Jika perintah meminta env tidak ada appPort, jalankan terlebih dahulu:
Jika nanti Anda mengubah konfigurasi seperti app-port dan app-public-path yang akan mempengaruhi hasil proxy, ingatlah untuk menjalankan kembali generate.
Langkah 3: Jalankan reload
Setelah membuat konfigurasi, langsung jalankan:
Di sebagian besar skenario, cukup gunakan perintah ini secara langsung. Jika belum berjalan maka startup akan diproses secara internal terlebih dahulu; jika sudah berjalan maka akan di-reload sesuai konfigurasi terbaru.
File apa yang akan dikelola CLI?
Mengambil test2 sebagai contoh, perintah terkait Caddy biasanya memelihara file dan direktori berikut:
di dalam:
NB_CLI_ROOT/.nocobase/proxy/caddy/...Berikut ini adalah file tambahan agen yang dikelola oleh CLINB_CLI_ROOT/test2/storage/...Berikut ini adalah sumber daya statis dan direktori unggahan milik aplikasinocobase.caddyadalah file entri tingkat penyedia dan biasanya tidak perlu diubah secara manual.app.caddyadalah konfigurasi situs Caddy lengkap dari env tertentu. Mengeksekusi ulanggenerateakan menimpa keseluruhannya
:::catatan peringatan
Jika Anda ingin mengimbangi konfigurasi tingkat situs Caddy, seperti header tambahan, autentikasi, pembatasan kecepatan, atau strategi kompresi, Anda dapat menyesuaikan terlebih dahulu berdasarkan app.caddy; namun, perlu diketahui bahwa eksekusi ulang generate berikutnya akan menimpa file ini.
:::
Konfigurasi tulisan tangan: apa yang harus dilakukan tanpa CLI
Jika aplikasi Anda tidak dihosting CLI, atau Anda secara eksplisit ingin mempertahankan sendiri konfigurasi Caddy yang lengkap, Anda juga dapat menulisnya dengan tangan.
Namun, untuk NocoBase, entri lingkungan produksi biasanya bukan sekadar reverse_proxy. Selain meneruskan permintaan API ke aplikasi backend, konfigurasi Caddy yang lengkap dan berfungsi biasanya juga perlu menangani direktori unggahan, sumber daya statis front-end, perutean .well-known, WebSocket, dan halaman fallback SPA.
Mengambil test2 sebagai contoh, direktori utama yang terkait dengan Caddy biasanya mencakup:
- Direktori halaman cadangan SPA:
NB_CLI_ROOT/.nocobase/proxy/caddy/test2/public - Direktori produk build front-end:
NB_CLI_ROOT/test2/storage/dist-client - Unggah direktori:
NB_CLI_ROOT/test2/storage/uploads
Dengan kata lain, konfigurasi tulisan tangan biasanya perlu mencakup setidaknya jenis entri berikut:
v: Alihkan/vke/v/uploads: Buka direktori unggahandist: Mengekspos direktori produk build front-endoauth well-known: Menangani jalur penemuan OAuthopenid well-known: Menangani jalur penemuan OpenIDapi: meneruskan permintaan/api/ke aplikasi backendws: meneruskan permintaan WebSocket ke aplikasi backendspa v2: Menyediakan entri front-end dan halaman kembali untuk/v/spa v1: Menyediakan entri front-end dan halaman kembali untuk/
Oleh karena itu, konfigurasi Caddy lengkap biasanya tidak hanya ditulis dengan cara umum berikut:
Untuk aplikasi yang dihosting CLI seperti test2, struktur yang mendekati penerapan sebenarnya biasanya akan terlihat seperti ini:
Ada juga dua poin penting di sini:
NB_CLI_ROOT/.nocobase/proxy/caddy/...Berikut ini adalah direktori halaman rollback SPA yang dikelola oleh CLINB_CLI_ROOT/test2/storage/...Berikut ini adalah penggunaan direktori produk build dan direktori unggahan Anda sendiri
Jika aplikasi Anda menggunakan penerapan sub-jalur, atau sumber daya front-end, direktori unggahan, dan lapisan entri tidak berada dalam perspektif jalur yang sama, konfigurasi tulisan tangan akan lebih rentan terhadap kesalahan. Dalam skenario ini, biasanya lebih disarankan untuk mengeksekusi:
Kemudian melakukan penyesuaian berdasarkan hasil yang dihasilkan.
Jika Anda ingin CLI membantu Anda menjalankan jalur dan rute terlebih dahulu, maka struktur yang dihasilkan biasanya adalah:
di dalam:
nocobase.caddybertanggung jawab untuk menyatukanimport */app.caddytest2/app.caddyadalah konfigurasi situs lengkap dari env initest2public/index-v1.htmldanpublic/index-v2.htmladalah halaman cadangan SPA yang dihasilkan CLI
Pendekatan yang lebih bijaksana biasanya adalah:
- Pertama biarkan CLI menghasilkan konfigurasi Caddy
- Konfirmasikan struktur perutean dan jalur sebenarnya berdasarkan hasil yang dihasilkan.
- Kemudian lakukan penyesuaian manual sesuai dengan nama domain Anda, mode pengoperasian, dan jalur pemasangan.
Hal ini biasanya lebih kecil kemungkinannya untuk melewatkan detail terkait WebSockets, sumber daya statis, direktori unggahan, rute .well-known, atau halaman cadangan SPA dibandingkan dengan menulis konfigurasi dari awal dengan tangan.
Periksa dan muat ulang konfigurasi
Jika Anda menulis atau menyesuaikan konfigurasi Caddy secara manual, verifikasi terlebih dahulu setelah melakukan perubahan, lalu muat ulang:
Jika Anda tidak menggunakan systemd untuk mengelola Caddy, Anda dapat menggunakan metode startup dan reload Anda sendiri.
Jika Anda mengelola lapisan entri melalui nb proxy caddy, biasanya lebih disukai menggunakan:
Jika Anda ingin melihat driver saat ini, total jalur entri file, direktori root runtime dan kontainer atau informasi biner lokal, Anda dapat menjalankan:
Jika Anda hanya ingin segera mengonfirmasi apakah ini sedang berjalan, Anda dapat menjalankan:
Instruksi umum
nb proxy caddy generateuntuk aplikasi yang diinstal olehnb init- Jika Anda sudah memiliki nama domain yang dapat diselesaikan ke server secara normal, Caddy sering kali merupakan cara tercepat untuk mendapatkan HTTPS.
- Jika Anda kemudian mengubah konfigurasi seperti
app-portdanapp-public-pathyang akan mempengaruhi hasil proxy, ingatlah untuk menjalankan kembaligenerate

