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.
VPSuntu · 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.pubVPS 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.pubDi 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
fiBagi 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.pubPada komputer anda, buka sambungan baharu dengan kunci tadi. Kekalkan akses asal sehingga berjaya.
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Dari 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.pubCipta 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_keysPada terminal baharu komputer anda, sambung sebagai pentadbir:
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10Dalam 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 whoamiPasang 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 nginxDi 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 verboseSelepas 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 -tMuat semula Nginx hanya jika ujian konfigurasi lulus:
sudo systemctl reload nginxDari 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.timerIkuti 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.
| Masalah | Semakan awal |
|---|---|
| SSH timeout | Alamat, firewall penyedia dan sistem, konsol |
| Permission denied (publickey) | Akaun, kunci dan kebenaran authorized_keys |
| Halaman Nginx lalai muncul | DNS, server_name dan konfigurasi aktif |
| Sijil gagal disahkan | Rekod A/AAAA awam dan port 80 |
| Nginx gagal selepas perubahan | sudo 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.