Tartalomjegyzék
Készíts kulcsot, és ellenőrizd a kiszolgálót
A saját Linux, macOS vagy WSL gépeden készíts kulcsot még a VPS létrehozása előtt. Ha a fájlnév foglalt, másikat használj végig, és adj meg jelmondatot.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubCsak a nyilvános kulcsot add meg az új gép létrehozásakor. Ellenőrizd a kezdeti felhasználónevet és SSH-portot; a példa ubuntu felhasználót és 22-es portot használ. A megbízható helyreállítási konzolban olvasd ki a kiszolgálókulcs ujjlenyomatát:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubA saját gépeden helyettesítsd a 203.0.113.10 dokumentációs címet és szükség esetén a felhasználót. A kulcs elfogadása előtt egyeztesd az algoritmust és a SHA256 ujjlenyomatot.
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Másik helyi terminálból másold fel a nyilvános kulcsot a következő adminisztrátori fiókhoz:
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubKülön adminisztrátort tesztelj új munkamenetben
Előbb ellenőrizd a getent passwd deploy paranccsal, hogy a deploy név nincs használatban. Ha létezik, válassz másik nevet, és a csoportokat, könyvtárakat is cseréld a példában. Ne írd felül más felhasználó kulcsfájlját.
A szerveren vizsgáld meg a rendszert, olvasd el a frissítéseket, majd hozd létre az adminisztrátort. A sudo-kérésekhez erős jelszót adj meg.
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_keysA saját gép új termináljában teszteld az új belépést:
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10Az új szerveres munkamenetben ellenőrizd a sudo-jogot; a parancsnak root értéket kell kiírnia:
sudo whoamiAz eredeti hozzáférés maradjon nyitva. Működő helyettesítés előtt ne tilts le belépési módot.
Telepíts Nginxet a megfelelő tűzfalággal
A szerveren, befejezett inicializálás után telepítsd és ellenőrizd a szolgáltatást:
sudo apt install nginx
sudo systemctl enable --now nginxA szolgáltatói tűzfalban engedélyezd a valódi SSH-portot a saját adminisztrációs helyedről, valamint TCP 80/443-at a webhelyhez. A vendégrendszer tűzfala ettől függetlenül is blokkolhat.
Oracle Cloud Ubuntu-képen az egész következő UFW-blokkot hagyd ki. Az UFW zavarhatja a szükséges tűzfalszabályokat, beleértve a boot- és blokk-kötetek iSCSI-hozzáférését. Ne ürítsd a szabályokat és ne cseréld a tűzfalcsomagokat; a szolgáltató dokumentált vendégszabályait használd.
Más új képen csak akkor használd ezt az ágat, ha a szolgáltató támogatja az UFW-t. Bekapcsolás előtt a tényleges SSH-portot engedélyezd; itt ez 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 verboseMindkét út után ellenőrizz új SSH-belépést. A meglevő kapcsolat önmagában nem igazolja, hogy új kapcsolat is létrejöhet.
Külön Nginx-webhelyen publikáld a mintát
Az új szerveren a first-site név és útvonalak legyenek szabadok. Az app.example.com helyére a saját DNS-neved kerüljön. Az idézőjeles EOF megőrzi az Nginx $uri változóját a fájlban.
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 -tCsak sikeres nginx -t után töltsd újra a beállítást:
sudo systemctl reload nginxA saját gépedről a DNS átállítása előtt kérd le a megfelelő hostnevet a szerver címén. Mind a címet, mind a nevet helyettesítsd:
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/A saját mintaoldalad címsorát keresd, ne csak a HTTP 200 kódot. Az alapértelmezett Nginx-oldal is visszaadhat sikeres választ.
Állítsd be a DNS-t és a HTTPS-t
Ez az útvonal közvetlen DNS-t feltételez, proxy nélkül. Az A rekord a VPS IPv4-címére mutasson. AAAA rekordot csak működő, ugyanezt a webhelyet elérő IPv6 mellé adj meg; egy régi rekord félreviheti a látogatót és a tanúsítvány ellenőrzését.
A saját gépen kérd a http://app.example.com/ címet a saját neveddel, --resolve nélkül. Ha a megfelelő oldal jelenik meg, a szerveren telepítsd az Ubuntu-tárolóból a Certbotot és Nginx-bővítményét. Universe szükséges; hiányzó csomagnál előbb a csomagforrást javítsd.
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.timerKövesd az e-mailre és feltételekre vonatkozó kérdéseket. A Certbot módosítja a webhely beállítását és HTTP → HTTPS átirányítást készít. Ellenőrizd a megújítási próbát és a certbot.timer ütemezést. Inaktív időzítőnél vizsgáld az okot, majd használd a sudo systemctl enable --now certbot.timer parancsot. A 80-as port maradjon elérhető a HTTP-alapú megújításhoz.
Kívülről és újraindítás után is tesztelj
A saját gépen ellenőrizd az átirányítást, tanúsítványt és tartalmat. Ne add hozzá a curl -k kapcsolóját: elrejtené a tanúsítványhibát.
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/HTTP-ről HTTPS-re átirányítás és ott érvényes tanúsítvánnyal a saját oldal várható. Publikált IPv6-nál azt az útvonalat is vizsgáld meg.
Még a tesztkörnyezetben futtasd a sudo reboot parancsot, majd lépj be deploy felhasználóként. Ellenőrizd a systemctl is-active nginx eredményét és ismételd a külső kérést. Ha nem tér vissza a hozzáférés, a konzolt és az SSH-hibakeresést használd.
Őrizd meg a működő alapot
Kis képernyőn görgesd oldalra a táblázatot a többi oszlophoz.
| Jelenség | Első ellenőrzés |
|---|---|
| Alapértelmezett Nginx-oldal | DNS cél, server_name, engedélyezett webhely |
| Tanúsítványhiba | Nyilvános A/AAAA és 80-as port |
| Nginx nem indul | nginx -t, szolgáltatási napló |
| SSH-kulcs elutasítva | Felhasználónév, kulcs és jogosultságok |
Ez statikus fájlokat szolgál ki, nem telepít WordPresst, Node.js-t vagy adatbázist. A futtatókörnyezetet az alkalmazáskompatibilitás ellenőrzése után add hozzá.
A fájlokat, DNS-beállításokat és újraépítési lépéseket a VPS-en kívül is tartsd meg. Végezz külön visszaállítási próbát, és állíts be elérhetőségi, mentési és tanúsítványlejárati riasztást. Egy sikeres kérés nem figyeli a holnapi szolgáltatást. Költözésnél a végső adatmásolást, levelezést, feladatokat és feltöltéseket is tervezd meg.
Új Ubuntu 24.04 géphez, közvetlen DNS-hez és a példában 22-es SSH-porthoz készült. OCI Ubuntu esetén az UFW-ág kihagyandó. Nem állítjuk, hogy az eljárást minden szolgáltatói képen lefuttattuk.
Gyakori kérdések
Használható a példa meglévő éles oldalon?
Először külön teszt-VPS-en próbáld. A parancsok fájlokat hoznak létre, tűzfalat kapcsolhatnak be, és a Certbot módosítja az Nginxet.
Az adatbázis is elkészül?
Nem, itt statikus HTTPS-webhely készül. Az alkalmazás szolgáltatásait és az adatbázis következetes mentését külön kell kialakítani.
Egy sikeres HTTPS-kérés után kész az üzemeltetés?
Még szükség van frissítésre, felügyeletre, helyreállításra és az alkalmazás fontos műveleteinek tesztelésére.