Beri API pertama Anda anggaran sumber daya dan rencana pemulihan.

Ini adalah skenario perencanaan ilustratif untuk pembangun independen, bukan kisah pelanggan atau hasil kapasitas yang terukur. Aplikasi mencatat peminjaman peralatan untuk klub kecil: anggota yang terautentikasi dapat melihat item yang tersedia, membuat peminjaman, dan mengembalikannya. Catatan lebih penting daripada diagram penerapan yang rumit, jadi desain pertama harus membuat penulisan gagal dan data hilang mudah diselidiki.

Pilih arsitektur minimum yang berguna

Gunakan satu proses API, satu database, dan reverse proxy untuk endpoint HTTPS publik. Jaga database hanya dapat dijangkau melalui jalur lokal atau privat yang dimaksudkan. Beri aplikasi identitas sistem operasinya sendiri, dengan akses ke file yang dibutuhkannya. Pisahkan file penerapan dari data persisten agar rilis tidak menggantikan database atau unggahan.

Berbagi instans menjaga konfigurasi dan investigasi tetap terkelola untuk penerapan pertama. Ini juga mengikat komponen ke batas mulai ulang, disk, dan kegagalan yang sama. Terima tradeoff itu secara sengaja. Jika aplikasi memerlukan pemulihan independen atau database terus-menerus bersaing dengan API, pertimbangkan memisahkannya sebelum meningkatkan semuanya sekaligus.

Anggarkan untuk momen sibuk

Jangan hanya menentukan ukuran untuk proses idle. Lembar kerja di bawah menggunakan tunjangan perencanaan yang dibuat-buat untuk menunjukkan perhitungan. Ini bukan pengukuran aplikasi ini, tolok ukur, atau persyaratan minimum. Ganti dengan observasi dari runtime dan database Anda, termasuk penerapan yang representatif.

Skenario Mulai rencana Build saat ini menentukan 2 vCPU, 2 GB RAM dan 50 GB SSD. Angka-angka itu menjadikannya konfigurasi untuk diselidiki dalam lembar kerja ini, bukan bukti bahwa stack cocok. GB katalog dan pembacaan MiB alat adalah unit yang berbeda; periksa total sistem yang sebenarnya. Estimasi memori tersedia Linux memperhitungkan memori yang dapat diklaim kembali yang relevan, jadi memori bebas rendah saja bukan vonis ukuran. Lihat penjelasan kernel tentang MemAvailable dan panduan pengukuran.

CPU dan disk memerlukan keputusan terpisah. Catat durasi permintaan dan waktu tunggu database sebelum menambahkan vCPU. Anggarkan disk untuk sistem operasi, rilis yang disimpan, pertumbuhan database, log, dan pekerjaan pemulihan sementara. Fitur unggahan menciptakan masalah penyimpanan yang berbeda dari catatan terstruktur kecil; beri batas ukuran dan keputusan retensi.

Ketahui biaya di muka

Contoh berikut menggunakan Build dengan sumber daya defaultnya dan tanpa opsi berulang tambahan. Subtotal bulanannya adalah $14.00 USD. Nilai dihasilkan dari katalog konfigurator saat ini sehingga tabel harga mengikuti checkout.

Periode enam bulan atau tahunan menurunkan total di muka katalog ini dibandingkan dengan membayar subtotal bulanan tanpa diskon untuk jumlah bulan yang sama. Ini tidak menambah sumber daya, menetapkan harga perpanjangan, atau membuat arsitektur yang belum teruji menjadi cocok. Pilih periode yang dapat Anda komitmenkan, tinjau detail layanan dan penagihan, dan sediakan secara terpisah untuk domain, layanan eksternal apa pun, dan biaya jaringan.

Verifikasi satu permintaan lengkap

Sebelum membuka aplikasi kepada pengguna yang dituju, konfirmasi akses server dan akses pemulihan, pasang runtime yang didukung, dan catat rilis yang Anda terapkan. Definisi layanan harus mengidentifikasi executable, direktori kerja, dan pengguna runtime. Systemd Restart= pengaturan mengontrol perilaku kegagalan yang ditentukan; loop mulai ulang tetap memerlukan diagnosis. Lihat panduan layanan dan panduan deployment.

Uji secara lokal terlebih dahulu, lalu melalui nama HTTPS yang sebenarnya dari koneksi lain. Dengan Caddy, manajemen sertifikat otomatis bergantung pada konfigurasi nama yang valid dan metode validasi yang berfungsi; tantangan HTTP dan TLS-ALPN umum memerlukan port masuk yang dapat dijangkau 80 dan 443. Lihat prasyarat HTTPS Caddy. Keberhasilan lokal tidak dapat menyingkirkan masalah DNS atau proxy, karena panduan jalur permintaan menjelaskan.

Buat pemeriksaan aplikasi menjadi spesifik: buat item peralatan sekali pakai, pinjamkan, pastikan permintaan kedua melihat hasil yang tersimpan, lalu kembalikan. Periksa otorisasi serta endpoint health sederhana. Catat respons yang diharapkan sebelum pengujian, dan jaga kredensial serta data anggota agar tidak masuk ke log yang dibagikan untuk pemecahan masalah.

Buktikan pemulihan kecil

Cadangkan basis data dengan metode yang sesuai dengan mesin dan tujuan pemulihan. PostgreSQL mendokumentasikan pendekatan logis, filesystem, dan pengarsipan berkelanjutan secara terpisah; pilihan yang tepat bergantung pada cara Anda perlu memulihkan. Lihat ikhtisar cadangannya. Jika foto item diunggah, sertakan file tersebut dan hubungannya dengan catatan basis datanya.

Jalankan latihan pemulihan ke basis data dan direktori pengujian terpisah. Temukan item yang diketahui dan file terkaitnya, lalu periksa bahwa aplikasi dapat membaca keduanya. Tuliskan cadangan yang dipilih, stempel waktu data, langkah yang diperlukan, dan hasil sebenarnya. panduan pemulihan pertama mengembangkan latihan ini. Pemilihan cadangan katalog opsional tidak membuktikan bahwa pemulihan tingkat aplikasi ini berfungsi.

Buat keputusan berikutnya dari bukti

Pertahankan desain sederhana selama perilaku terukurnya dan kebutuhan pemulihan masih sesuai. Selidiki aplikasi yang berhenti atau peringatan sumber daya sebelum mengasumsikan bahwa paket yang lebih besar adalah jawabannya. Pilih Malaysia, Romania, atau Switzerland untuk server, lalu konfirmasi alokasi sumber daya, lokasi cadangan, dan cakupan layanan. Skenario ini tidak menetapkan fasilitas, kapasitas permintaan, atau waktu pengiriman.

Konfigurasikan Build dan tinjau setiap opsi. Tautan membuka paket awal; periksa periode yang dipilih dan pilihan yang tersimpan sebelum melanjutkan. Memasukkan detail pembayaran tidak memasang aplikasi pinjaman peralatan.