Cuprinsul ghidului
Pregătește cheia și verifică identitatea gazdei
Pe calculatorul tău Linux, macOS sau WSL creează cheia înainte de provizionarea VPS-ului. Dacă numele există, folosește altul consecvent, fără suprascriere. Introdu o frază de acces.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubÎncarcă numai cheia publică la crearea instanței. Verifică utilizatorul imaginii și portul SSH; exemplul folosește ubuntu și portul 22. În consola de încredere a instanței citește amprenta cheii de gazdă:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubDe pe calculator, înlocuiește adresa de documentație și utilizatorul după caz. Compară algoritmul și amprenta SHA256 înainte să accepți identitatea serverului.
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Tot de pe calculator copiază fișierul public, necesar contului de administrator separat:
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubCreează administratorul și păstrează sesiunea existentă
Confirmă că deploy este un cont nou, destinat acestui test. Dacă există deja, verifică configurația lui în loc să înlocuiești cheile. Comenzile de mai jos inspectează sistemul, actualizează pachetele și pregătesc contul; citește propunerile de upgrade înainte de acceptare.
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_keysDeschide alt terminal pe calculator și conectează-te cu noul cont:
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10În acea sesiune verifică drepturile administrative:
sudo whoamiNu închide sesiunea inițială și nu dezactiva o metodă de acces înainte de validarea celei noi. Păstrează consola furnizorului disponibilă.
Instalează Nginx și alege ramura corectă de firewall
În server, după terminarea inițializării imaginii, instalează Nginx și verifică serviciul:
sudo apt install nginx
sudo systemctl enable --now nginxPermite TCP 80 și 443 în firewall-ul furnizorului și păstrează portul SSH real. Pentru Ubuntu pe Oracle OCI nu instala și nu activa UFW: păstrează firewall-ul imaginii, inclusiv iSCSI, și configurează reguli compatibile după documentația furnizorului.
Pe altă imagine, dacă furnizorul acceptă UFW și SSH rulează pe 22 ca în exemplu, poți folosi blocul următor. Pentru alt port, permite portul real înainte de activare. Păstrează sesiunea existentă și verifică una nouă după schimbare.
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 verbosePublică pagina într-un site Nginx separat
Folosește un server nou și confirmă că numele first-site și căile nu sunt utilizate. Înlocuiește app.example.com cu numele DNS pe care îl controlezi. Delimitatorul EOF între ghilimele păstrează variabila Nginx $uri în fișier.
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 -tContinuă numai după ce nginx -t reușește. În caz de eroare corectează configurația înainte de reîncărcare:
sudo systemctl reload nginxDe pe calculator testează numele gazdei înainte de schimbarea DNS. Înlocuiește atât numele, cât și adresa:
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/Verifică textul paginii, nu numai codul HTTP 200; un alt site implicit poate răspunde la aceeași adresă.
Configurează DNS și certificatul
Acest traseu presupune DNS direct către VPS, fără proxy. Creează înregistrarea A spre IPv4 corect. Publică AAAA numai dacă IPv6 ajunge la același site; o înregistrare veche poate afecta vizitatorii și validarea certificatului.
De pe calculator cere http://app.example.com/ cu numele tău, fără --resolve. Continuă când apare pagina corectă. Instalează versiunea Certbot din arhiva Ubuntu; pachetele necesită Universe. Rezolvă eventualele erori de pachete lipsă înainte de pasul următor.
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.timerUrmează solicitările de e-mail și condiții. Certbot modifică site-ul Nginx și configurează redirecționarea HTTP → HTTPS. Verifică testul de reînnoire și programarea certbot.timer; dacă este inactiv, verifică instalarea și activează-l cu sudo systemctl enable --now certbot.timer. Păstrează portul 80 accesibil pentru validarea HTTP și reînnoire.
Testează din exterior și după repornire
De pe calculator verifică redirecționarea și certificatul. Nu adăuga -k la curl: ar ascunde erorile certificatului.
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/HTTP trebuie să trimită spre HTTPS, iar HTTPS să returneze pagina așteptată cu certificat valid. Dacă ai publicat IPv6, verifică și acel traseu.
Cât timp serverul este de test, rulează sudo reboot, reconectează-te ca deploy, verifică systemctl is-active nginx și repetă cererea externă. Dacă accesul nu revine, folosește consola și ghidul de diagnostic SSH.
Păstrează baza funcțională înainte de aplicație
Ai publicat un site static, nu WordPress, Node.js sau o bază de date. Adaugă mediul de execuție numai după verificarea compatibilității și testează pornirea, fluxurile și recuperarea datelor.
Păstrează o copie independentă verificată. La migrare planifică sincronizarea finală, DNS, e-mailul, sarcinile și fișierele încărcate. Nu publica secrete în rădăcina web și nu elimina vechiul serviciu până la validarea celui nou.
Traseu pentru Ubuntu 24.04 nou, DNS direct și SSH pe 22. Ramura de firewall depinde de imagine; Ubuntu în OCI trebuie să sară peste UFW. Nu este un test pe fiecare imagine de furnizor.
Întrebări frecvente
Pot urma pașii pe un server care găzduiește deja un site?
Exemplul creează fișiere și permite Certbot să editeze Nginx. Pentru un server existent verifică site-urile, conturile, rețeaua și recuperarea; începe pe un VPS de test separat.
Instalează ghidul și baza de date?
Nu. Rezultatul este un site static HTTPS. Mediul aplicației și recuperarea bazei de date se adaugă și se testează separat.
O conexiune HTTPS reușită înseamnă că totul este pregătit?
Confirmă doar traseul și certificatul testate. Mai sunt necesare întreținerea, monitorizarea, recuperarea și testele aplicației.