Nastavitev Ubuntu VPS za prvo spletno stran
Nastavitev Ubuntu VPS začnite z dostopom, ki ga lahko obnovite. Vodnik je namenjen novemu strežniku Ubuntu 24.04 LTS in statični strani z Nginx ter HTTPS. Na koncu preverite obnovo potrdila in delovanje po ponovnem zagonu.
VPSuntu · Posodobljeno · Branje: približno 5 min.
V tem vodniku
Pripravite strežnik, domeno in konzolo
Potrebujete nov VPS z Ubuntujem 24.04, javnim IPv4, SSH na vratih 22, začetnim računom s sudo in domeno, ki jo upravljate. Ključ ustvarite pred vzpostavitvijo VM. Če prazen strežnik že obstaja, uporabite spodnjo možnost prek delujočega dostopa. Ukazi odjemalca so za Bash na Linuxu, macOS ali WSL; strežniške ukaze izvajajte znotraj SSH. Če vzorčne poti pripadajo obstoječi strani, ne nadaljujte.
Vse pojavitve 203.0.113.10 zamenjajte s svojim IP, app.example.com pa z imenom gostitelja. To sta dokumentacijska primera. ubuntu je začetno uporabniško ime iz primera; uporabite račun ponudnika. Pred spreminjanjem dostopa ali požarnega zidu odprite obnovitveno konzolo. Slike Oracle Cloud z Ubuntujem zahtevajo posebno obravnavo požarnega zidu.
Ustvarite ključ in preverite prvo povezavo
Na svojem računalniku ustvarite namenski ključ z geslom. Če datoteka že obstaja, v celotnem postopku izberite drugo ime. Javni ključ ima končnico .pub, zasebni ostane na vašem računalniku.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubZa nov VPS: zdaj ustvarite strežnik Ubuntu 24.04 in javni ključ vnesite v ponudnikovo polje za SSH. Potrdite začetno uporabniško ime. Preskočite naslednja dva bloka za obstoječ strežnik in nadaljujte s preverjanjem prstnega odtisa strežnika.
Za že ustvarjen, prazen VPS: ohranite delujočo sejo SSH. V drugem terminalu svojega računalnika kopirajte novi javni ključ z obstoječo prijavo. existing_vps_key zamenjajte z imenom veljavnega zasebnega ključa. Pri prijavi z geslom ali agentom SSH izpustite -i ~/.ssh/existing_vps_key, ne da bi spreminjali pravila prijave strežnika.
scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubV obstoječi strežniški seji preverite preneseno datoteko in ključ dodajte v authorized_keys svojega začetnega računa. Dodajanje ohrani stare vnose. Brez delujočega dostopa najprej uporabite ponudnikov postopek obnove.
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
fiPri obeh možnostih pred prvo potrditvijo povezave primerjajte prstni odtis z ustreznim javnim ključem strežnika v zaupanja vredni konzoli. Za strežniški ključ Ed25519 v konzoli izvedite:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubNa svojem računalniku odprite novo povezavo z novim ključem. Prvotni dostop ohranite, dokler nova prijava ne uspe.
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Iz drugega terminala svojega računalnika prenesite javni ključ še za novega skrbnika. Ponovno kopiranje te začasne datoteke javnega ključa je dovoljeno.
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubUstvarite ločen skrbniški račun
Na strežniku najprej izvedite getent passwd deploy. Račun ne sme že obstajati. Če obstaja, izberite drugo ime in ga dosledno zamenjajte tudi v poteh ter imenih skupin. Tako ne prepišete datoteke ključev drugega uporabnika.
Preverite sliko in vire, preglejte posodobitve ter ustvarite skrbnika. Nastavite močno geslo za sudo. Ukazi install dodelijo lastništvo in omejene pravice datoteki ključa.
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_keysV novem terminalu svojega računalnika se prijavite kot novi skrbnik:
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10V tej novi strežniški seji preverite sudo. Po vnosu gesla računa deploy mora biti rezultat root. Nadaljujte šele, ko delujeta nova prijava in sudo; prvotni dostop pustite na voljo.
sudo whoamiNamestite Nginx in izberite ustrezen požarni zid
Na strežniku namestite Nginx. Dostop določata požarni zid ponudnika in požarni zid operacijskega sistema. Med spremembami ohranite konzolo in sejo SSH.
sudo apt install nginx
sudo systemctl enable --now nginxV omrežju ponudnika dovolite TCP 22 iz svoje skrbniške lokacije in TCP 80/443 za obiskovalce. Če SSH uporablja druga vrata, ohranite pravilo zanje. Omrežno dovoljenje ne odpre vrat, ki jih blokira sam sistem.
Oracle Cloud z Ubuntujem: v celoti preskočite naslednji blok UFW. UFW lahko poseže v bistvena pravila slike in prepreči zagon. Ohranite priložena pravila iptables, tudi tista za iSCSI in zagonske oziroma blokovne nosilce. HTTP/HTTPS nastavite prek OCI security list ali NSG in dokumentiranih pravil gostujočega sistema. Ne praznite pravil in ne zamenjujte paketov požarnega zidu.
Druge nove slike Ubuntu: spodnji blok uporabite samo, če ponudnik podpira UFW in ne zahteva drugačne upravljane ureditve. Pred vklopom dovolite dejanska vrata SSH; primer uporablja 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 verbosePo katerikoli veji preverite novo prijavo SSH. Odprta stara seja tega ne potrdi. Pred zahtevo za potrdilo mora uspeti tudi zunanji preizkus HTTP iz naslednjega koraka.
Objavite stran v lastni konfiguraciji Nginx
Na strežniku ustvarite nov korenski imenik strani in konfiguracijo. V bloku zamenjajte domeno. Ohranite narekovaje pri EOF, da lupina ne razširi spremenljivk Nginx, kot je $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 -tKonfiguracijo ponovno naložite samo po uspešnem preverjanju:
sudo systemctl reload nginxNa svojem računalniku preverite ime gostitelja neposredno na naslovu strežnika, še preden spremenite DNS. Pričakujte svojo vsebino, ne privzete pozdravne strani Nginx.
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/Usmerite DNS in izdajte potrdilo HTTPS
Ustvarite zapis A, ki kaže na IPv4 strežnika. AAAA objavite le, če IPv6 na tem strežniku deluje. Star AAAA lahko obiskovalce in preverjanje potrdila pošlje drugam. Primer predpostavlja neposreden DNS brez posredniškega strežnika.
Na svojem računalniku odprite http://app.example.com/ brez --resolve. Nadaljujte, ko dobite svojo stran. Na strežniku namestite Certbot in dodatek Nginx iz arhiva Ubuntu. Paketa potrebujeta repozitorij Universe; napako manjkajočega paketa najprej razrešite.
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.timerSledite vprašanjem o e-pošti in pogojih. Certbot spremeni konfiguracijo ter vklopi preusmeritev HTTP v HTTPS. Preverite časovnik obnove; če ni aktiven, uporabite sudo systemctl enable --now certbot.timer. Vrata 80 morajo ostati dosegljiva za preverjanje in obnovo potrdila.
Preverite od zunaj in po ponovnem zagonu
Na računalniku preverite preusmeritev, potrdilo in vsebino. HTTP mora preusmeriti v HTTPS, HTTPS pa prikazati vaš naslov. Ne dodajajte možnosti -k, ker prikrije napake preverjanja potrdila.
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/Dokler gre za preizkusni strežnik, na njem izvedite sudo reboot. Nato se ponovno prijavite kot deploy, preverite systemctl is-active nginx in ponovite zunanjo zahtevo HTTPS. Ponovni zagon namerno prekine SSH; če se strežnik ne vrne, uporabite konzolo.
Odpravite napako in shranite načrt obnove
Na majhnem zaslonu pomaknite preglednico vstran, da vidite vse stolpce.
| Simptom | Prva preverjanja |
|---|---|
| SSH poteče | Naslov, oba požarna zida in konzola |
| Permission denied (publickey) | Uporabnik, ključ in pravice authorized_keys |
| Prikaže se privzeti Nginx | DNS, server_name in omogočena konfiguracija |
| Izdaja potrdila ne uspe | Javna A/AAAA in dosegljivost vrat 80 |
| Nginx po spremembi ne deluje | sudo nginx -t in sudo journalctl -u nginx -n 50 --no-pager |
Napake prijave raziščite z diagnostiko SSH. Datoteke, konfiguracijo, DNS in korake ponovne postavitve hranite zunaj VPS. Preizkus obnove datotek je prvi korak; celotna storitev potrebuje tudi preostale odvisnosti in potrdila. Zasebne ključe potrdil posebej zaščitite.
Dodajte nadzor dosegljivosti in izteka potrdila. Ta postopek postavi statično stran, ne zbirke ali izvajalnega okolja aplikacije. Ko ju dodate, potrebujeta lastno konfiguracijo, preverjanje zagona in dosledno kopiranje podatkov.
Pogosta vprašanja
Ali lahko ukaze izvedem na obstoječi strani?
Najprej jih preizkusite na ločenem VPS. Primer ustvarja datoteke, spreminja požarni zid in dovoljuje Certbotu spremembe Nginx; obstoječa postavitev zahteva pregled dostopa, strani in obnove.
Ali postopek namesti WordPress ali Node.js?
Ne. Rezultat je statična stran HTTPS. Delujoče izhodišče ohranite in nato dodajte ter preverite svojo aplikacijo.