Praktični vodnik / Prva spletna stran

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.

· 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.pub

Za 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.pub

V 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
fi

Pri 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.pub

Na 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.10

Iz 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.pub

Ustvarite 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_keys

V novem terminalu svojega računalnika se prijavite kot novi skrbnik:

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

V 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 whoami

Namestite 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 nginx

V 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 verbose

Po 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 -t

Konfiguracijo ponovno naložite samo po uspešnem preverjanju:

sudo systemctl reload nginx

Na 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.timer

Sledite 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.

SimptomPrva preverjanja
SSH potečeNaslov, oba požarna zida in konzola
Permission denied (publickey)Uporabnik, ključ in pravice authorized_keys
Prikaže se privzeti NginxDNS, server_name in omogočena konfiguracija
Izdaja potrdila ne uspeJavna A/AAAA in dosegljivost vrat 80
Nginx po spremembi ne delujesudo 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.

Primer velja za nov Ubuntu 24.04, neposreden DNS in SSH 22. Uporabite le požarni zid, ki ga podpira slika ponudnika; pri Oracle preskočite UFW. Postopek ni bil preizkušen na vseh ponudnikovih slikah.

Povezani vodniki