Ubuntu VPS paruošimas pirmai svetainei

Pasiruoškite serverį, domeną ir atkūrimo prieigą

Reikia naujo Ubuntu 24.04 VPS, viešo IPv4, SSH 22 prievado, pradinės paskyros su sudo ir jūsų valdomo domeno. SSH raktą sugeneruokite kitame žingsnyje prieš kurdami VM. Jei tuščias serveris jau sukurtas, naudokite veikiančios prieigos šaką. Kliento komandos skirtos Bash aplinkai Linux, macOS arba WSL; serverio komandos vykdomos SSH sesijoje. Jei pavyzdžio keliai jau priklauso kitai svetainei, sustokite.

Visur pakeiskite 203.0.113.10 savo IP, o app.example.com — savo domeno vardu. Tai dokumentacijos pavyzdžiai. ubuntu yra pavyzdinė pradinė paskyra; naudokite tiekėjo nurodytą. Prieš keisdami prieigą ar ugniasienę atidarykite atkūrimo konsolę. Oracle Ubuntu atvaizdams taikoma atskira ugniasienės tvarka.

Sukurkite SSH raktą ir patikrinkite pirmą prisijungimą

Savo kompiuteryje sukurkite raktų porą su slaptafraze. Jei toks failas jau yra, visame gide pasirinkite kitą vardą. Viešąjį .pub failą galima įkelti tiekėjui; privatusis lieka jūsų kompiuteryje.

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

Naujam VPS: dabar sukurkite Ubuntu 24.04 serverį ir pateikite .pub failą tiekėjo SSH rakto lauke. Patvirtinkite pradinį vartotojo vardą. Praleiskite kitus du jau sukurto serverio blokus ir pereikite prie serverio rakto kontrolinio atspaudo patikros.

Jau sukurtam tuščiam VPS: neuždarykite veikiančios SSH sesijos. Kitame savo kompiuterio terminale nukopijuokite viešąjį raktą naudodami veikiančią autentifikaciją. existing_vps_key pakeiskite savo turimo privačiojo rakto failu. Jei prieiga naudoja slaptažodį ar SSH agentą, praleiskite -i ~/.ssh/existing_vps_key nekeisdami serverio autentifikacijos taisyklių.

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

Veikiančioje serverio sesijoje patikrinkite įkeltą viešąjį raktą ir pridėkite jį prie savo pradinės paskyros authorized_keys. Esami įrašai išlieka. Jei veikiančios prieigos neturite, pirmiausia naudokite tiekėjo atkūrimą.

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

Abiem atvejais prieš priimdami pirmą ryšį palyginkite serverio rakto kontrolinį atspaudą su patikimos atkūrimo konsolės rezultatu. Ed25519 serverio raktui konsolėje vykdykite:

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

Savo kompiuteryje atidarykite naują ryšį su sukurtu raktu. Pradinę prieigą išsaugokite, kol naujas prisijungimas bus patikrintas.

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

Kitame kompiuterio terminale nukopijuokite viešąjį raktą atskiram administratoriui, kurį sukursite toliau. Šį laikiną viešojo rakto failą galima nukopijuoti pakartotinai.

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

Sukurkite atskirą administratorių

Serveryje pirmiausia vykdykite getent passwd deploy. Jei paskyra jau egzistuoja, pasirinkite kitą vardą ir pakeiskite visas jo nuorodas, įskaitant namų katalogą bei grupę. Taip neperrašysite kito vartotojo rakto failo.

Patikrinkite atvaizdą ir išteklius, peržiūrėkite atnaujinimus, tada sukurkite paskyrą. sudo užklausoms nustatykite stiprų slaptažodį. install komandos suteikia vartotojui rakto failo nuosavybę ir ribotas teises.

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

Naujame savo kompiuterio terminale prisijunkite kaip naujasis administratorius:

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

Šioje naujoje serverio sesijoje patikrinkite sudo. Įvedus deploy slaptažodį, rezultatas turi būti root. Tęskite tik kai abu bandymai sėkmingi; pradinę prieigą išsaugokite.

sudo whoami

Įdiekite Nginx ir pasirinkite tinkamą ugniasienę

Serveryje įdiekite Nginx. Prieigą veikia ir tiekėjo tinklo taisyklės, ir pačios operacinės sistemos ugniasienė. Keisdami jas išsaugokite konsolę bei SSH sesiją.

sudo apt install nginx
sudo systemctl enable --now nginx

Tiekėjo tinkle leiskite TCP 22 iš administravimo vietos ir TCP 80/443 svetainės lankytojams. Jei SSH naudoja kitą prievadą, išsaugokite jo taisyklę. Tinklo leidimas nepanaikina blokavimo operacinėje sistemoje.

Oracle Cloud Ubuntu: praleiskite visą UFW bloką žemiau. UFW gali konfliktuoti su būtinosiomis atvaizdo taisyklėmis ir sutrukdyti sistemai paleisti. Išsaugokite tiekėjo iptables, įskaitant iSCSI įkrovos ir blokinių diskų taisykles. HTTP/HTTPS nustatykite per OCI security list arba NSG ir dokumentuojamas svečio ugniasienės taisykles. Neišvalykite esamų taisyklių ir nekeiskite atvaizdo ugniasienės paketų.

Kitiems naujiems Ubuntu atvaizdams: šis blokas tinka tik jei tiekėjas palaiko UFW ir nereikalauja kitokios valdomos ugniasienės. Prieš įjungdami leiskite tikrą SSH prievadą; pavyzdyje jis yra 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

Pasirinkę bet kurią šaką, patikrinkite naują SSH prisijungimą. Sena sesija to neįrodo. Prieš prašant sertifikato taip pat turi veikti toliau aprašytas HTTP bandymas iš išorės.

Paskelbkite puslapį atskiroje Nginx konfigūracijoje

Serveryje sukurkite naują svetainės katalogą ir konfigūraciją. Pakeiskite domeną bloko viduje. Išsaugokite kabutes ties EOF, kad shell neišplėstų Nginx kintamųjų, pavyzdžiui, $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

Konfigūraciją iš naujo įkelkite tik jei jos patikra sėkminga:

sudo systemctl reload nginx

Savo kompiuteryje patikrinkite domeną tiesiogiai serverio IP dar nekeisdami DNS. Turite gauti savo antraštę, o ne numatytąjį Nginx puslapį.

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

Nukreipkite DNS ir išduokite HTTPS sertifikatą

Sukurkite domeno A įrašą į VPS IPv4. AAAA skelbkite tik tada, kai šiame serveryje veikia IPv6. Senas AAAA gali nukreipti lankytojus ir sertifikato patikrą kitur. Pavyzdys numato tiesioginį DNS ryšį be tarpinio proxy.

Savo kompiuteryje atverkite http://app.example.com/ be --resolve. Tęskite gavę savo puslapį. Serveryje įdiekite Certbot ir Nginx papildinį iš Ubuntu saugyklų. Šiems paketams reikia Universe; pirmiausia išspręskite klaidą, jei paketas nerandamas.

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

Vykdykite el. pašto bei sąlygų užklausas. Certbot keičia svetainės konfigūraciją ir įjungia HTTP nukreipimą į HTTPS. Patikrinkite atnaujinimo laikmatį; jei jis neaktyvus, naudokite sudo systemctl enable --now certbot.timer. HTTP patikrai ir sertifikato atnaujinimui 80 prievadas turi likti pasiekiamas.

Patikrinkite iš išorės ir po perkrovimo

Kompiuteryje patikrinkite nukreipimą, sertifikatą ir turinį. HTTP turi nukreipti į HTTPS, o HTTPS — rodyti jūsų antraštę. Nepridėkite -k: ši parinktis paslepia sertifikato patikros klaidas.

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

Kol serveris dar bandomasis, jame vykdykite sudo reboot. Atsikūrus ryšiui prisijunkite kaip deploy, patikrinkite systemctl is-active nginx ir pakartokite išorinę HTTPS užklausą. Perkrovimas sąmoningai nutraukia SSH; jei serveris negrįžta, naudokite konsolę.

Išspręskite klaidą ir išsaugokite atkūrimo planą

Mažame ekrane slinkite lentelę į šoną, kad matytumėte visus stulpelius.

Prieigos klaidą tirkite pagal SSH diagnostiką. Failus, Nginx konfigūraciją, DNS įrašus ir atkūrimo veiksmus laikykite už VPS ribų. Išbandykite failų kopijos atkūrimą atskiroje aplinkoje. Sertifikatų privatieji raktai reikalauja apsaugoto saugojimo.

Nustatykite pasiekiamumo ir sertifikato galiojimo perspėjimus. Viena sėkminga patikra rytdienos atnaujinimo nestebi. Šis gidas skelbia statinius failus; duomenų bazei ar programai reikia savo paslaugų konfigūracijos ir kopijų metodo. Pridedamų komponentų apkrovą matuokite pagal išteklių patikros gidą.

Dažni klausimai