Panduan praktikal / Penerbitan pertama

Tetapan Ubuntu VPS untuk laman web pertama

Tetapan Ubuntu VPS ini membawa pelayan Ubuntu 24.04 baharu daripada akses SSH kepada laman statik Nginx dengan HTTPS. Sediakan pentadbir berasingan, sahkan sijil dan uji laman selepas reboot sebelum bergantung pada pelayan tersebut.

· Dikemas kini · Anggaran bacaan 5 minit

Dalam panduan ini

Sediakan persekitaran yang betul

Gunakan VPS Ubuntu 24.04 baharu, IPv4 awam, SSH port 22, akaun awal yang boleh menggunakan sudo dan domain milik anda. Cipta kunci pada langkah seterusnya sebelum provisioning. Jika VPS kosong sudah wujud, gunakan cabang akses sedia ada. Arahan klien menggunakan Bash Linux, macOS atau WSL; arahan server dijalankan dalam SSH. Berhenti jika laluan contoh sudah digunakan oleh deployment lain.

Gantikan setiap 203.0.113.10 dan app.example.com dengan alamat serta nama hos anda. Akaun ubuntu ialah contoh akaun awal penyedia. Buka konsol pemulihan sebelum mengubah akses atau firewall. Imej Oracle Ubuntu mesti mengikuti cabang khususnya, bukan arahan UFW umum.

Cipta kunci dan uji akses awal

Pada komputer anda, cipta pasangan kunci dengan passphrase. Jika fail sudah wujud, pilih nama lain sepanjang panduan. Fail .pub boleh dimuat naik; fail peribadi kekal pada komputer anda.

mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pub

VPS baharu: cipta pelayan Ubuntu 24.04 dengan fail .pub dalam medan SSH key penyedia. Sahkan akaun awal, langkau dua blok untuk server sedia ada dan teruskan ke pengesahan fingerprint hos.

VPS kosong yang sudah dicipta: kekalkan sesi SSH yang berfungsi. Dari terminal komputer lain, salin kunci awam menggunakan kaedah pengesahan sedia ada. Gantikan existing_vps_key dengan nama kunci peribadi sebenar. Jika akses menggunakan kata laluan atau SSH agent, abaikan argumen -i ~/.ssh/existing_vps_key tanpa mengubah polisi server.

scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Di dalam sesi server yang masih berfungsi, sahkan fail awam dan tambahkan pada authorized_keys akaun awal anda. Entri lama dikekalkan. Jika tiada akses berfungsi, gunakan pemulihan penyedia dahulu.

if ssh-keygen -lf ~/ubuntu-vps-admin.pub; then
    mkdir -p ~/.ssh
    chmod 700 ~/.ssh
    printf '\n' >> ~/.ssh/authorized_keys
    cat ~/ubuntu-vps-admin.pub >> ~/.ssh/authorized_keys
    chmod 600 ~/.ssh/authorized_keys
fi

Bagi kedua-dua laluan, bandingkan fingerprint sebelum menerima sambungan pertama. Untuk kunci hos Ed25519, jalankan ini dalam konsol pemulihan yang dipercayai:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Pada komputer anda, buka sambungan baharu dengan kunci tadi. Kekalkan akses asal sehingga berjaya.

ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Dari terminal komputer yang lain, salin kunci awam untuk pentadbir berasingan yang akan dicipta. Menyalin semula fail sementara ini dibenarkan jika cabang tadi sudah memuat naiknya.

scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Cipta pentadbir berasingan

Pada server, jalankan getent passwd deploy dahulu. Jika akaun itu sudah wujud, pilih nama belum digunakan dan tukar semua rujukan termasuk laluan home serta kumpulan. Ini mengelakkan fail kunci pengguna lain diganti.

Semak imej dan sumber, teliti kemas kini, kemudian cipta pentadbir. Gunakan kata laluan kukuh untuk prompt sudo. Arahan install menetapkan pemilikan dan kebenaran fail kunci.

cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keys

Pada terminal baharu komputer anda, sambung sebagai pentadbir:

ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10

Dalam sesi server baharu itu, uji sudo. Selepas kata laluan deploy diterima, output sepatutnya root. Teruskan dalam sesi ini apabila kedua-dua ujian berjaya; kekalkan akses asal.

sudo whoami

Pasang Nginx dan pilih cabang firewall

Pada server, pasang Nginx. Firewall penyedia dan firewall dalam sistem sama-sama mempengaruhi akses. Kekalkan konsol pemulihan serta sesi SSH.

sudo apt install nginx
sudo systemctl enable --now nginx

Di rangkaian penyedia, benarkan TCP 22 dari lokasi pentadbiran serta TCP 80/443 untuk pelawat. Jika SSH menggunakan port lain, kekalkan peraturan port itu. Peraturan rangkaian tidak membuka port yang disekat dalam sistem.

Imej Oracle Cloud Ubuntu: langkau keseluruhan blok UFW di bawah. UFW boleh mengganggu peraturan penting imej termasuk iSCSI dan menyebabkan masalah boot. Kekalkan iptables asal. Gunakan security list atau NSG OCI dan peraturan firewall tetamu yang didokumenkan untuk HTTP/HTTPS; jangan kosongkan peraturan atau ganti pakej firewall imej.

Imej Ubuntu baharu lain yang menyokong UFW: gunakan blok ini hanya jika penyedia menyokongnya dan tiada konfigurasi firewall terurus yang berbeza. Benarkan port SSH sebenar sebelum mengaktifkannya; contoh menggunakan 22.

sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Selepas mana-mana cabang, uji log masuk SSH baharu. Sesi yang sudah terbuka tidak membuktikan sambungan baharu berjaya. Ujian HTTP luar pada langkah seterusnya mesti lulus sebelum permintaan sijil.

Terbitkan halaman dalam konfigurasi sendiri

Pada server, cipta document root dan konfigurasi baharu. Gantikan nama hos di dalam blok. Kekalkan tanda petik pada EOF supaya shell tidak mengembangkan pemboleh ubah Nginx seperti $uri.

sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="en"><title>First deployment</title><h1>Ubuntu VPS is serving this page</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;
    root /var/www/first-site;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -t

Muat semula Nginx hanya jika ujian konfigurasi lulus:

sudo systemctl reload nginx

Dari komputer anda, uji nama hos pada IP server sebelum mengubah DNS. Jangka tajuk halaman anda, bukan halaman alu-aluan Nginx.

curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/

Sambungkan DNS dan keluarkan sijil

Cipta rekod A bagi nama hos menuju IPv4 VPS. Rekod AAAA hanya diterbitkan jika IPv6 benar-benar berfungsi. AAAA lama boleh menghantar pelawat atau pengesahan sijil ke lokasi lain. Contoh mengandaikan DNS terus ke VPS tanpa proxy.

Pada komputer, uji http://app.example.com/ tanpa --resolve. Apabila halaman anda dipaparkan, pasang Certbot dan plugin Nginx daripada arkib Ubuntu pada server. Pakej ini memerlukan repositori Universe; selesaikan ralat pakej tidak ditemui dahulu.

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timer

Ikuti prompt e-mel dan terma. Certbot mengubah konfigurasi laman dan menambah redirect HTTP ke HTTPS. Pastikan timer pembaharuan dijadualkan; jika tidak aktif, gunakan sudo systemctl enable --now certbot.timer. Port 80 perlu boleh dicapai untuk pengesahan dan pembaharuan HTTP.

Sahkan dari luar dan selepas reboot

Pada komputer, periksa redirect, sijil dan kandungan. HTTP sepatutnya menuju HTTPS; HTTPS mesti memaparkan tajuk anda. Jangan tambah pilihan -k yang menyembunyikan kegagalan sijil.

curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/

Ketika masih deployment ujian, jalankan sudo reboot pada server. Sambung semula sebagai deploy, semak systemctl is-active nginx dan ulang permintaan HTTPS luar. Reboot memang menutup SSH; gunakan konsol jika mesin tidak kembali.

Simpan laluan pemulihan

Pada skrin kecil, tatal jadual ke sisi untuk melihat semua lajur.

MasalahSemakan awal
SSH timeoutAlamat, firewall penyedia dan sistem, konsol
Permission denied (publickey)Akaun, kunci dan kebenaran authorized_keys
Halaman Nginx lalai munculDNS, server_name dan konfigurasi aktif
Sijil gagal disahkanRekod A/AAAA awam dan port 80
Nginx gagal selepas perubahansudo nginx -t dan log jurnal Nginx

Jika log masuk gagal, gunakan panduan masalah SSH. Simpan fail laman, konfigurasi, DNS dan langkah bina semula di luar VPS. Uji pemulihan fail berasingan sebelum bergantung pada sandaran. Lindungi kunci sijil jika disalin.

Tambah amaran ketersediaan dan tarikh tamat sijil. Satu ujian berjaya tidak memantau pembaharuan esok. Panduan ini menyediakan laman statik sahaja; runtime aplikasi dan pangkalan data memerlukan konfigurasi servis serta sandaran sendiri. Ukur semula sumber apabila komponen tersebut ditambah.

Soalan lazim

Bolehkah arahan ini digunakan terus pada laman sedia ada?

Cuba pada VPS ujian berasingan dahulu. Panduan mencipta fail, mengaktifkan firewall dan membenarkan Certbot menyunting Nginx. Server aktif memerlukan semakan konfigurasi dan pemulihan sendiri.

Adakah WordPress, Node.js atau pangkalan data turut dipasang?

Tidak. Hasilnya laman statik HTTPS. Tambah runtime yang diperlukan selepas itu dan uji startup, kesihatan serta pemulihan datanya.

Ikuti label komputer dan server serta cabang firewall yang sesuai dengan imej. Kekalkan akses pemulihan sepanjang perubahan.

Teruskan dengan panduan berkaitan