Ubuntu VPS setup para sa unang HTTPS website

Ihanda ang server, domain at recovery access

Para ito sa bagong Ubuntu 24.04 VPS na may public IPv4, SSH sa port 22, paunang account na may sudo at domain na kontrolado mo. Gumawa muna ng SSH key bago mag-provision. Kung mayroon nang bakanteng server, gamitin ang hiwalay na paraan sa susunod na seksyon habang gumagana pa ang kasalukuyang access.

Ang client commands ay para sa Bash sa Linux, macOS o WSL; ang server commands ay sa loob ng SSH. Huminto kung ginagamit na ng ibang deployment ang mga halimbawang path. Palitan ang 203.0.113.10 at app.example.com ng iyong address at hostname; mga documentation example ang mga ito. Palitan din ang ubuntu kung iba ang paunang username ng provider.

Buksan ang recovery console bago baguhin ang access o firewall. Basahin ang firewall requirements ng provider: may hiwalay na paraan para sa Oracle Cloud Ubuntu images.

Gumawa ng key o idagdag ito gamit ang umiiral na access

Sa sarili mong computer, gumawa ng key at pumili ng passphrase. Kung mayroon nang file na ganito ang pangalan, pumili ng iba at gamitin iyon sa lahat ng hakbang. Public ang .pub; panatilihin sa iyong computer ang private key.

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

Bagong VPS: ilagay ang public key sa SSH-key field habang ginagawa ang Ubuntu 24.04 server. Tiyakin ang username at dumiretso sa fingerprint verification sa ibaba. Laktawan ang mga command para sa mayroon nang server.

Mayroon nang bakanteng VPS: panatilihing bukas ang gumaganang SSH session. Sa isa pang terminal ng iyong computer, kopyahin ang bagong public key gamit ang kasalukuyang authentication. Palitan ang existing_vps_key ng pangalan ng iyong private key. Kung password o SSH agent ang gumaganang paraan, alisin ang -i ~/.ssh/existing_vps_key; huwag baguhin ang authentication policy.

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

Sa umiiral na server session, patunayan ang na-upload na public key at idagdag ito sa authorized_keys ng sarili mong paunang account. Pinapanatili ng append ang mga lumang entry; ang dagdag na newline ay para sa file na walang newline sa dulo. Kung wala kang gumaganang access, gamitin muna ang recovery procedure ng provider.

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

Sa parehong paraan, bago tanggapin ang unang SSH connection, ihambing ang host fingerprint sa katumbas na public host key sa pinagkakatiwalaang recovery console. Para sa Ed25519, patakbuhin ito sa console:

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

Sa iyong computer, magbukas ng bagong connection gamit ang bagong key. Panatilihin ang lumang access hanggang magtagumpay ito.

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

Sa isa pang client terminal, kopyahin ang public key para sa hiwalay na administrator na gagawin sa susunod. Ayos lang na kopyahin muli ang pansamantalang public-key file kung na-upload na ito.

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

Gumawa at subukan ang hiwalay na administrator

Sa server, patakbuhin muna ang getent passwd deploy. Dapat walang ibalik na account. Kung mayroon nang deploy, pumili ng ibang username at palitan ito sa lahat ng home paths at group names bago magpatuloy, upang hindi mapalitan ang key file ng ibang tao.

Tiyakin ang image at resources, suriin ang upgrades, at gumawa ng administrator. Magtakda ng malakas na password para sa sudo. Ibinibigay ng install commands ang tamang ownership at limitadong permissions sa key file.

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

Mula sa isa pang terminal sa iyong computer, kumonekta bilang bagong administrator:

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

Sa bagong server session, subukan ang sudo. Dapat lumabas ang root pagkatapos tanggapin ang password ng deploy. Magpatuloy sa session na ito kapag parehong gumagana ang login at sudo; panatilihin ang unang access.

sudo whoami

I-install ang Nginx at gamitin ang tamang firewall

Sa server, i-install muna ang Nginx. Parehong nakaaapekto sa access ang guest firewall at network firewall ng provider. Panatilihin ang console at gumaganang SSH habang nagbabago ng rules.

sudo apt install nginx
sudo systemctl enable --now nginx

Sa provider firewall, payagan ang TCP 22 mula sa iyong administration location at TCP 80/443 para sa website visitors. Panatilihin ang tamang rule kung ibang SSH port ang gamit mo. Hindi binubuksan ng network rule ang port na hinaharang pa rin ng guest firewall.

Oracle Cloud Ubuntu images: laktawan ang buong UFW block. Maaaring masira ng UFW ang mahahalagang firewall rules ng image at pati ang pag-boot. Panatilihin ang ibinigay na iptables rules, kabilang ang proteksyon ng iSCSI boot at block volumes. Gamitin ang OCI security lists o NSGs at dokumentadong guest rules para sa HTTP/HTTPS. Huwag i-flush ang rules o palitan ang firewall packages.

Ibang bagong Ubuntu image: gamitin lamang ang sumusunod kung sinusuportahan ng provider ang UFW at walang ibang managed firewall requirements. Payagan muna ang aktuwal na SSH port bago paganahin ang firewall; port 22 ang halimbawa.

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

Sa alinmang paraan, subukan ang bagong SSH login. Hindi sapat na nananatiling bukas ang lumang session. Dapat pumasa rin ang external HTTP check bago humiling ng certificate.

Mag-publish sa sariling Nginx site

Sa server, gumawa ng bagong document root at configuration. Palitan ang hostname sa block. Panatilihin ang quoted EOF markers upang hindi palawakin ng shell ang Nginx variables gaya ng $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

I-reload lamang ang Nginx kapag matagumpay ang configuration test:

sudo systemctl reload nginx

Mula sa iyong computer, hilingin ang hostname sa server address bago baguhin ang DNS. Dapat ang sarili mong heading ang makita, hindi ang default Nginx welcome page.

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

Ikonekta ang DNS at kumuha ng HTTPS certificate

Gumawa ng DNS A record papunta sa IPv4 ng VPS. Maglagay lamang ng AAAA kung gumagana ang IPv6: maaaring ituro ng lumang AAAA ang mga bisita at certificate validation sa ibang lugar. Ipinagpapalagay dito na direktang nakaturo ang DNS sa VPS, walang proxy.

Sa iyong computer, buksan ang http://app.example.com/ nang walang --resolve. Kapag bumalik ang iyong page, i-install sa server ang Certbot at Nginx plugin mula sa Ubuntu archive. Kailangan ang Universe repository; ayusin muna ang package-not-found error bago magpatuloy.

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

Sundin ang email at terms prompts. Babaguhin ng Certbot ang configuration ng site at idaragdag ang HTTP-to-HTTPS redirect. Tiyaking naka-schedule ang renewal timer; kung inactive, gamitin ang sudo systemctl enable --now certbot.timer. Panatilihing naaabot ang port 80 para sa HTTP certificate validation at renewal.

Suriin mula sa labas at pagkatapos ng reboot

Sa iyong computer, suriin ang redirect, certificate at nilalaman. Dapat mag-redirect ang HTTP sa HTTPS at lumabas ang iyong heading. Huwag idagdag ang curl -k: itinatago nito ang certificate validation failures.

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

Habang test deployment pa lamang, patakbuhin ang sudo reboot sa server. Sadya nitong isinasara ang SSH. Pagbalik ng server, kumonekta bilang deploy, suriin ang systemctl is-active nginx at ulitin ang external HTTPS request. Gamitin ang console kung hindi bumalik ang machine.

Ayusin ang nabigong check at panatilihin ang recovery copy

Sa maliit na screen, i-scroll ang talahanayan pahalang upang makita ang lahat ng column.

Gamitin ang SSH diagnosis upang paghiwalayin ang network, service at key problems. Itago sa labas ng VPS ang site files, Nginx configuration, DNS records at rebuild steps. Subukan ang recovery sa hiwalay na machine. Kung ibi-backup ang certificate private keys, kailangan ng protektadong storage.

Maglagay ng availability at certificate-expiry alerts; hindi minomonitor ng isang matagumpay na check ang susunod na renewal. Simulan sa file recovery exercise, na hindi pinapatungan ang gumaganang site. Kailangan pa rin ng buong recovery ang iba pang assets, certificates at service configuration.

Static files lamang ang deployment na ito. May sariling configuration at backup method ang database at application runtime. Gamitin ang resource measurement guide kapag idinagdag ang mga iyon.

Mga karaniwang tanong

Mga opisyal na sanggunian

1. Dokumentasyon 1: ubuntu.com
2. Dokumentasyon 2: ubuntu.com
3. Dokumentasyon 3: ubuntu.com
4. Dokumentasyon 4: eff-certbot.readthedocs.io
5. Dokumentasyon 5: packages.ubuntu.com
6. Dokumentasyon 6: docs.oracle.com