Ubuntu VPS-ის გამართვა პირველი HTTPS-საიტისთვის
ახალ Ubuntu 24.04 LTS VPS-ზე განათავსეთ მცირე სტატიკური საიტი Nginx-ითა და HTTPS-ით. შექმენით ცალკე ადმინისტრატორი, გამართეთ SSH-გასაღები და შეამოწმეთ სერტიფიკატის განახლება და საიტის მუშაობა გადატვირთვის შემდეგ.
VPSuntu · განახლებულია · წაკითხვა დაახლოებით 6 წუთში
გზამკვლევის შინაარსი
მოამზადეთ სერვერი, დომენი და აღდგენის წვდომა
საჭიროა ახალი Ubuntu 24.04 VPS, public IPv4, SSH პორტი 22, საწყისი sudo-ანგარიში და თქვენი დომენი. SSH-გასაღები შექმენით სერვერამდე. თუ ცარიელი VM უკვე არსებობს, გამოიყენეთ შემდეგი სექციის ალტერნატიული გზა მოქმედი წვდომის შენარჩუნებით.
კლიენტის ბრძანებები Bash-ში, Linux/macOS/WSL-ზე სრულდება; სერვერის ბრძანებები — SSH-სესიაში. შეჩერდით, თუ მაგალითის paths უკვე მოქმედ განთავსებას ეკუთვნის. 203.0.113.10 და app.example.com დოკუმენტაციის მაგალითებია: ყველგან შეცვალეთ რეალური მისამართითა და hostname-ით. ubuntu შეცვალეთ პროვაიდერის საწყისი username-ით, თუ ის განსხვავდება.
წვდომის ან firewall-ის შეცვლამდე გახსენით recovery console. გადაამოწმეთ იმიჯის firewall-ის მოთხოვნები: Oracle Cloud Ubuntu-ს განსხვავებული გზა სჭირდება.
შექმენით გასაღები ან დაამატეთ მოქმედი წვდომით
თქვენს კომპიუტერში შექმენით ცალკე key და დააყენეთ passphrase. თუ ფაილი უკვე არსებობს, სხვა სახელი აირჩიეთ და ყველგან შეცვალეთ. .pub საჯაროა; private key კომპიუტერში შეინახეთ.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubახალი VPS: ახლა შექმენით Ubuntu 24.04 სერვერი და public key შესაბამის SSH ველში ჩასვით. გადაამოწმეთ username და გადადით host fingerprint-ის შემოწმებაზე; არსებული სერვერის ნაბიჯები გამოტოვეთ.
უკვე შექმნილი ცარიელი VPS: მოქმედი SSH-სესია ღია დატოვეთ. კომპიუტერის სხვა ტერმინალიდან ატვირთეთ public key იმ authentication-ით, რომელიც უკვე მუშაობს. existing_vps_key თქვენი მიმდინარე private key-ის სახელით შეცვალეთ. თუ password ან SSH agent გამოიყენება, გამოტოვეთ -i ~/.ssh/existing_vps_key; სერვერის authentication policy არ შეცვალოთ.
scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubარსებულ სერვერის სესიაში გადაამოწმეთ ატვირთული public key და დაამატეთ თქვენი საწყისი ანგარიშის authorized_keys-ს. append ძველ ჩანაწერებს ინარჩუნებს, დამატებითი newline კი ბოლო ხაზის გამოტოვებულ დასრულებას ითვალისწინებს. მოქმედი წვდომის არქონისას ჯერ პროვაიდერის recovery პროცესი გაიარეთ.
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ორივე გზაზე პირველი კავშირის მიღებამდე fingerprint შეადარეთ სანდო recovery console-ში ნაჩვენებ შესაბამის public host key-ს. Ed25519-ისთვის კონსოლში გაუშვით:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubკომპიუტერიდან ახალი გასაღებით ცალკე კავშირი გახსენით. ძველი წვდომა წარმატებამდე შეინარჩუნეთ.
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10კომპიუტერის სხვა ტერმინალიდან ატვირთეთ public key შემდეგი ადმინისტრატორისთვის. დროებითი public-key ფაილის ხელახლა კოპირება დასაშვებია.
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubშექმენით ადმინისტრატორი და ცალკე შეამოწმეთ
სერვერზე ჯერ გაუშვით getent passwd deploy. პასუხში ანგარიში არ უნდა ჩანდეს. თუ deploy არსებობს, აირჩიეთ თავისუფალი username და წინასწარ შეცვალეთ ყველა სახელი, home path და ჯგუფი, რათა სხვისი გასაღები არ გადაიწეროს.
შეამოწმეთ სისტემა და რესურსები, გადახედეთ updates-ს და შექმენით ადმინისტრატორი. sudo-სთვის ძლიერი password დააყენეთ. install ბრძანებები ფაილს სწორ მფლობელსა და შეზღუდულ permissions-ს ანიჭებს.
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თქვენი კომპიუტერის ახალ ტერმინალში შედით ახალ ანგარიშში:
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10ახალ სერვერის სესიაში შეამოწმეთ sudo. deploy-ის password-ის მიღების შემდეგ უნდა გამოჩნდეს root. აქ განაგრძეთ, როცა login და sudo ორივე მუშაობს; საწყისი წვდომაც შეინარჩუნეთ.
sudo whoamiდააყენეთ Nginx და იმიჯისთვის მხარდაჭერილი firewall
სერვერზე ჯერ დააყენეთ Nginx. წვდომაზე გავლენას ახდენს როგორც guest firewall, ისე პროვაიდერის ქსელური წესები. ცვლილებებისას console და მოქმედი SSH დატოვეთ.
sudo apt install nginx
sudo systemctl enable --now nginxპროვაიდერის firewall-ში დაუშვით TCP 22 თქვენი ადმინისტრირების მისამართიდან და TCP 80/443 საიტის ვიზიტორებისთვის. თუ SSH სხვა პორტზეა, შესაბამისი წესი შეინარჩუნეთ. ქსელური წესი guest firewall-ის ბლოკს არ ხსნის.
Oracle Cloud Ubuntu: სრულად გამოტოვეთ ქვემოთ მოცემული UFW ბლოკი. UFW-მ შეიძლება აუცილებელი წესები დააზიანოს და ჩატვირთვაც შეაფერხოს. შეინარჩუნეთ იმიჯის iptables წესები, მათ შორის iSCSI boot/block ტომების დაცვა. გამოიყენეთ OCI security lists ან NSG და HTTP/HTTPS-ის დოკუმენტირებული guest წესები. არ გაასუფთაოთ არსებული წესები და არ შეცვალოთ იმიჯის firewall packages.
სხვა ახალი Ubuntu იმიჯები: ეს ბლოკი მხოლოდ მაშინ გამოიყენეთ, როცა პროვაიდერი UFW-ს უჭერს მხარს და განსხვავებული managed firewall არ არის საჭირო. ჩართვამდე დაუშვით რეალური SSH პორტი; მაგალითში ის 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რომელი გზაც აირჩიეთ, შეამოწმეთ ახალი SSH login. ძველი სესიის მუშაობა ახალი კავშირის ტესტი არ არის. სერტიფიკატის მოთხოვნამდე უნდა გაიაროს შემდეგი გარე HTTP შემოწმებაც.
განათავსეთ გვერდი ცალკე Nginx საიტში
სერვერზე შექმენით ახალი document root და configuration. hostname ბლოკშიც შეცვალეთ. EOF-ის ბრჭყალები შეინარჩუნეთ, რათა shell-მა Nginx-ის $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 -tNginx მხოლოდ წარმატებული configuration test-ის შემდეგ გადატვირთეთ reload-ით:
sudo systemctl reload nginxთქვენი კომპიუტერიდან hostname სერვერის IP-ზე DNS-ის შეცვლამდე მოითხოვეთ. უნდა გამოჩნდეს თქვენი სათაური და არა Nginx-ის საწყისი მისალმება.
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/დააკავშირეთ DNS და მიიღეთ HTTPS სერტიფიკატი
შექმენით A ჩანაწერი VPS-ის IPv4-ზე. AAAA მხოლოდ გამართული IPv6-ისას დაამატეთ; ძველმა AAAA-მ ვიზიტორი და certificate validation სხვაგან შეიძლება გაგზავნოს. აქ DNS პირდაპირ VPS-ზე მიუთითებს, proxy-ის გარეშე.
კომპიუტერიდან მოითხოვეთ http://app.example.com/ --resolve-ის გარეშე. როცა თქვენი გვერდი დაბრუნდება, სერვერზე დააყენეთ Certbot და Nginx plugin Ubuntu archive-იდან. საჭიროა Universe repository; package-not-found შეცდომა გაგრძელებამდე გამოასწორეთ.
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გაიარეთ email-ისა და პირობების მოთხოვნები. Certbot საიტის configuration-ს ცვლის და HTTP→HTTPS redirect-ს ამატებს. გადაამოწმეთ renewal timer; თუ გამორთულია, გამოიყენეთ sudo systemctl enable --now certbot.timer. HTTP validation-ისა და renewal-ისთვის პორტი 80 ხელმისაწვდომი დატოვეთ.
შეამოწმეთ გარედან და reboot-ის შემდეგ
კომპიუტერიდან შეამოწმეთ redirect, certificate და ტექსტი. HTTP უნდა გადავიდეს HTTPS-ზე, HTTPS კი წარმატებით აჩვენებდეს სათაურს. curl-ს -k არ დაამატოთ: ის სერტიფიკატის შემოწმების შეცდომებს მალავს.
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/ჯერ კიდევ სატესტო სერვერზე გაუშვით sudo reboot. SSH განზრახ გაითიშება. დაბრუნების შემდეგ შედით deploy-ით, შეამოწმეთ systemctl is-active nginx და გაიმეორეთ გარე HTTPS მოთხოვნა. თუ სერვერი არ დაბრუნდა, გამოიყენეთ console.
გამოასწორეთ შეფერხება და შეინახეთ აღდგენის მასალა
პატარა ეკრანზე ყველა სვეტის სანახავად ცხრილი ჰორიზონტალურად გადაახვიეთ.
| სიმპტომი | პირველი შემოწმება |
|---|---|
| SSH timeout | მისამართი, ორივე firewall და recovery console |
| Permission denied (publickey) | username, private key და authorized_keys permissions |
| Nginx-ის საწყისი გვერდი | DNS destination, server_name და enabled site |
| სერტიფიკატის შეცდომა | public A/AAAA და პორტი 80 |
| Nginx-ის შეცდომა ცვლილების შემდეგ | sudo nginx -t და sudo journalctl -u nginx -n 50 --no-pager |
წვდომის შეცვლამდე SSH-ის დიაგნოსტიკით გამოყავით ქსელის, სერვისისა და გასაღების პრობლემა. საიტის ფაილები, Nginx configuration, DNS და rebuild ნაბიჯები VPS-ის გარეთ შეინახეთ და სხვა machine-ზე აღადგინეთ. სერტიფიკატის private keys-ის ასლს დაცული საცავი სჭირდება.
დააყენეთ ხელმისაწვდომობისა და სერტიფიკატის ვადის შეტყობინებები. ერთი წარმატებული ტესტი ხვალინდელ renewal-ს არ აკონტროლებს. დაიწყეთ ფაილების აღდგენის სავარჯიშოთი, რომელიც მოქმედ საიტს არ გადაწერს. სრული recovery მოიცავს დარჩენილ assets-ს, certificates-სა და სერვისების configuration-საც.
ეს განთავსება სტატიკურ ფაილებს ემსახურება. აპლიკაციის runtime-სა და ბაზას საკუთარი configuration და backup სჭირდება. დამატებისას გამოიყენეთ რესურსების გაზომვის გზამკვლევი.
ხშირი კითხვები
შემიძლია ბრძანებები მოქმედ საიტზე გავუშვა?
ჯერ ცალკე სატესტო VPS გამოიყენეთ. მაგალითი ქმნის ფაილებს, რთავს firewall-ს და Certbot-ს Nginx-ის შეცვლის უფლებას აძლევს. მოქმედ სერვერზე ჯერ არსებული sites, access rules და recovery შეამოწმეთ.
ეს WordPress-ს, Node.js-ს ან ბაზასაც აყენებს?
არა. შედეგი სტატიკური HTTPS-საიტია. შეინარჩუნეთ ეს მოქმედი საწყისი მდგომარეობა, შემდეგ დაამატეთ runtime და გამოსცადეთ startup, health checks და data recovery.