ការដំឡើង Ubuntu VPS សម្រាប់គេហទំព័រ HTTPS
ចាប់ផ្ដើមពី Ubuntu 24.04 LTS VPS ថ្មី ហើយដាក់គេហទំព័រ static ជាមួយ Nginx និង HTTPS ។ អ្នកនឹងបង្កើតគណនីអ្នកគ្រប់គ្រងដាច់ដោយឡែក ប្រើ SSH key ពិនិត្យការបន្ត certificate និងសាកល្បងគេហទំព័រក្រោយ reboot ។
VPSuntu · កែថ្មី៖ · អានប្រហែល 7 នាទី
មាតិកាទំព័រ
រៀបចំម៉ាស៊ីនមេ domain និងផ្លូវសង្គ្រោះ
ត្រូវមាន Ubuntu 24.04 VPS ថ្មីដែលមាន public IPv4, SSH port 22, គណនីដំបូងដែលប្រើ sudo បាន និង domain ដែលអ្នកគ្រប់គ្រង។ បង្កើត SSH key នៅផ្នែកបន្ទាប់មុនបង្កើត VPS ។ បើម៉ាស៊ីនទទេមានរួចហើយ ប្រើការភ្ជាប់ដែលដំណើរការដើម្បីដាក់ key ថ្មី។ ពាក្យបញ្ជា client ប្រើ Bash លើ Linux, macOS ឬ WSL; ពាក្យបញ្ជា server រត់ក្នុង SSH ។ បើផ្លូវឯកសារគំរូជារបស់ការដំឡើងដែលមានរួច សូមឈប់សិន។
ប្ដូរ 203.0.113.10 ទៅ IP ម៉ាស៊ីនមេ និង app.example.com ទៅ hostname របស់អ្នក។ ទាំងពីរជាឧទាហរណ៍ឯកសារ។ ប្ដូរ username ubuntu តាមគណនីដែលអ្នកផ្ដល់សេវាផ្ដល់ឱ្យ។ បើក recovery console មុនកែការចូលប្រើឬ firewall ។ អានការណែនាំ firewall របស់ image មុនប្រើ UFW; Oracle Cloud Ubuntu ត្រូវការវិធីផ្សេង។
បង្កើត SSH key ហើយជ្រើសវិធីដាក់ key
នៅលើកុំព្យូទ័ររបស់អ្នក បង្កើត key ដាច់ដោយឡែក ហើយកំណត់ passphrase ។ បើឈ្មោះឯកសារមានរួច ចូរជ្រើសឈ្មោះថ្មីហើយប្រើវាឱ្យស្របគ្នា។ ឯកសារ .pub ជា public key; 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 key របស់អ្នកផ្ដល់សេវា។ បញ្ជាក់ username ដំបូង រួចទៅផ្ទៀងផ្ទាត់ host fingerprint ខាងក្រោម។ រំលងពាក្យបញ្ជាសម្រាប់ម៉ាស៊ីនដែលមានរួច។
បើ VPS ទទេមានរួចហើយ៖ រក្សា SSH session ដែលប្រើបាន។ ពី terminal ផ្សេងលើកុំព្យូទ័រ ចម្លង public key ថ្មីដោយប្រើវិធី authentication ចាស់។ ប្ដូរ existing_vps_key ទៅឈ្មោះ private key បច្ចុប្បន្ន។ បើប្រើ password ឬ SSH agent ចូរលុបជម្រើស -i ~/.ssh/existing_vps_key ចេញពីពាក្យបញ្ជា មិនចាំបាច់ប្ដូរគោលការណ៍ authentication របស់ server ទេ។
scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubក្នុង server session ចាស់ ពិនិត្យ public key ដែលបានផ្ទុកឡើង ហើយបន្ថែមទៅ authorized_keys របស់គណនីដំបូង។ ការបន្ថែមរក្សា key ចាស់ ហើយ newline បន្ថែមដោះស្រាយឯកសារដែលបន្ទាត់ចុងក្រោយគ្មាន newline ។ ប្រើតែគណនីដំបូងរបស់អ្នក។ បើគ្មានផ្លូវចូលដែលប្រើបាន ត្រូវប្រើដំណើរការសង្គ្រោះរបស់អ្នកផ្ដល់សេវាសិន។
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សម្រាប់វិធីទាំងពីរ មុនទទួលយកការភ្ជាប់ដំបូង ត្រូវប្រៀបធៀប host fingerprint ជាមួយ public host key ក្នុង recovery console ដែលទុកចិត្តបាន។ សម្រាប់ Ed25519 រត់ក្នុង console នោះ៖
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubនៅលើកុំព្យូទ័រ បើកការភ្ជាប់ថ្មីជាមួយ key ថ្មី។ រក្សាផ្លូវចូលចាស់រហូតដល់ការភ្ជាប់ថ្មីជោគជ័យ។
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10ពី terminal ផ្សេងលើកុំព្យូទ័រ ចម្លង public key សម្រាប់គណនីអ្នកគ្រប់គ្រងដែលនឹងបង្កើត។ អាចចម្លងឯកសារបណ្ដោះអាសន្ននេះម្ដងទៀតបាន បើបានផ្ទុកវាមុនរួច។
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubបង្កើតអ្នកគ្រប់គ្រង ហើយសាកល្បងដាច់ដោយឡែក
លើ server ពិនិត្យ getent passwd deploy ជាមុន។ លទ្ធផលមិនគួរបង្ហាញគណនីទេ។ បើ deploy មានរួច ជ្រើស username មិនទាន់ប្រើ ហើយប្ដូរគ្រប់ទីកន្លែង រួមទាំង home path និង group មុនបន្ត ដើម្បីកុំសរសេរជាន់ key របស់អ្នកផ្សេង។
ផ្ទៀងផ្ទាត់ image និងធនធាន ពិនិត្យ upgrades រួចបង្កើតអ្នកគ្រប់គ្រង។ កំណត់ password រឹងមាំសម្រាប់ sudo ។ ពាក្យបញ្ជា install កំណត់ម្ចាស់ key file និង 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ពី terminal ថ្មីលើកុំព្យូទ័រ ចូលជាគណនីអ្នកគ្រប់គ្រងថ្មី៖
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10ក្នុង session ថ្មីលើ server រត់ sudo ។ ក្រោយបញ្ចូល password របស់ deploy គួរឃើញ root។ បន្តនៅទីនេះពេលការចូលនិង sudo ដំណើរការ ហើយរក្សាផ្លូវចូលដើម។
sudo whoamiដំឡើង Nginx និងប្រើ firewall ដែល image គាំទ្រ
ដំឡើង Nginx លើ server ជាមុន។ Guest firewall និង firewall បណ្តាញរបស់អ្នកផ្ដល់សេវាសុទ្ធតែប៉ះពាល់ដល់ការចូលប្រើ។ រក្សា console និង SSH ដែលប្រើបាននៅពេលកែវា។
sudo apt install nginx
sudo systemctl enable --now nginxក្នុង provider firewall អនុញ្ញាត TCP 22 ពីទីតាំងអ្នកគ្រប់គ្រង និង TCP 80/443 សម្រាប់អ្នកចូលគេហទំព័រ។ បើ SSH ប្រើ port ផ្សេង ត្រូវរក្សា rule នោះ។ Network rule មិនបើក port ដែល guest firewall បិទទេ។
Oracle Cloud Ubuntu image ៖ រំលង UFW block ទាំងមូលខាងក្រោម។ Oracle ព្រមានថា UFW អាចរំខានដល់ rules ចាំបាច់របស់ image និងធ្វើឱ្យ boot មិនបាន។ រក្សា iptables rules ដែលផ្ដល់មក រួមទាំង iSCSI boot និង block volumes ។ ប្រើ OCI security lists ឬ NSGs និង guest rules តាមឯកសារសម្រាប់ HTTP/HTTPS ។ កុំ flush rules ឬជំនួស firewall packages របស់ image ។
UFW សម្រាប់ Ubuntu image ថ្មីផ្សេងទៀត៖ ប្រើតែពេលអ្នកផ្ដល់សេវាគាំទ្រ ហើយ image មិនត្រូវការ firewall ដែលគ្រប់គ្រងតាមវិធីផ្សេង។ អនុញ្ញាត SSH port ពិតមុន enable; ឧទាហរណ៍នេះប្រើ 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 ថ្មី។ Session ដែលនៅបើកមិនបញ្ជាក់ថាការភ្ជាប់ថ្មីប្រើបានទេ។ HTTP check ពីខាងក្រៅនៅផ្នែកបន្ទាប់ក៏ត្រូវជោគជ័យមុនស្នើ certificate ។ រក្សាវិធីចូលចាស់ពេលដោះស្រាយបញ្ហា។
ដាក់ឯកសារក្នុង Nginx site ដាច់ដោយឡែក
លើ server បង្កើត document root និង configuration ថ្មី។ ប្ដូរ hostname ក្នុង block ។ រក្សាសញ្ញាសម្រង់ជុំវិញ EOF ដើម្បីកុំឱ្យ shell ពង្រីក Nginx variables ដូចជា $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 -tReload លើ server តែពេល configuration test ជោគជ័យ៖
sudo systemctl reload nginxពីកុំព្យូទ័រ ស្នើ hostname នេះតាម IP ម៉ាស៊ីនមេមុនប្ដូរ DNS ។ គួរឃើញចំណងជើងរបស់អ្នក មិនមែន Nginx welcome page ទេ។
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/ភ្ជាប់ DNS ហើយចេញ HTTPS certificate
បង្កើត DNS A record ទៅ IPv4 របស់ VPS ។ បន្ថែម AAAA តែបើ IPv6 លើម៉ាស៊ីននេះដំណើរការ។ AAAA ចាស់ឬខុសអាចនាំអ្នកចូលនិង certificate validation ទៅកន្លែងផ្សេង។ ឧទាហរណ៍នេះសន្មតថា DNS ទៅ VPS ផ្ទាល់ គ្មាន proxy ។
ពីកុំព្យូទ័រ ស្នើ http://app.example.com/ ដោយគ្មាន --resolve ។ បន្តពេលទទួលបានទំព័ររបស់អ្នក។ លើ server ដំឡើង 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 និងលក្ខខណ្ឌតាម prompt ។ Certbot កែ site configuration និងបើក HTTP-to-HTTPS redirect ។ ពិនិត្យ renewal timer; បើអសកម្ម រត់ sudo systemctl enable --now certbot.timer។ រក្សា port 80 ឱ្យចូលបានសម្រាប់ validation និងការបន្ត certificate ។
ពិនិត្យពីខាងក្រៅ និងក្រោយ reboot
ពីកុំព្យូទ័រ ពិនិត្យ redirect, certificate និងមាតិកា។ HTTP គួរប្ដូរទៅ HTTPS ហើយ HTTPS ត្រូវបង្ហាញចំណងជើងរបស់អ្នក។ កុំបន្ថែម curl -k ព្រោះវាលាក់កំហុស certificate validation ។
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/ខណៈនៅជាការសាកល្បង រត់ sudo reboot លើ server ។ ពេលត្រឡប់មក ចូលជា deploy ពិនិត្យ systemctl is-active nginx ហើយស្នើ HTTPS ពីខាងក្រៅម្ដងទៀត។ Reboot ផ្ដាច់ SSH ដោយចេតនា; បើម៉ាស៊ីនមិនត្រឡប់មក ប្រើ console ។
រកមូលហេតុកំហុស និងរក្សាឯកសារសម្រាប់បង្កើតឡើងវិញ
លើអេក្រង់តូច អូសតារាងទៅចំហៀងដើម្បីមើលគ្រប់ជួរឈរ។
| រោគសញ្ញា | ពិនិត្យជាមុន |
|---|---|
| SSH timeout | IP, provider/guest firewall និង recovery console |
| Permission denied (publickey) | Username, private key និង authorized_keys permissions |
| បង្ហាញ Nginx default page | DNS, server_name និង enabled site |
| Certificate validation បរាជ័យ | Public A/AAAA និង port 80 |
| Nginx បរាជ័យក្រោយកែ | sudo nginx -t និង sudo journalctl -u nginx -n 50 --no-pager |
បើ login បរាជ័យ ប្រើការវិភាគ SSHដើម្បីបែងចែកបញ្ហាបណ្តាញ សេវា និង key មុនកែការចូលប្រើ។
រក្សា site files, Nginx config, DNS records និងជំហានបង្កើតឡើងវិញនៅក្រៅ VPS ហើយសាកល្បងស្ដារលើម៉ាស៊ីនផ្សេង។ បើ backup private certificate keys ត្រូវរក្សាទុកដោយមានការការពារ។ បន្ថែមការជូនដំណឹងអំពី availability និងថ្ងៃផុតកំណត់ certificate; check មួយមិនតាមដានការបន្តថ្ងៃក្រោយទេ។
ចាប់ផ្ដើមពីលំហាត់បម្រុងទុកនិងស្ដារឯកសារដែលមិនសរសេរជាន់គេហទំព័រកំពុងដំណើរការ។ ការស្ដារពេញលេញនៅតែត្រូវការ assets, certificates និង service configuration ផ្សេងទៀត។
នេះជាគេហទំព័រ static ។ Database ឬ runtime ត្រូវការ service និងវិធី backup ផ្ទាល់ខ្លួន។ ប្រើមគ្គុទ្ទេសក៍វាស់ធនធានពេលបន្ថែមវា។
សំណួរនិងចម្លើយ
អាចរត់លើគេហទំព័រដែលមានរួចបានទេ?
សាកល្បងលើ VPS ដាច់ដោយឡែកសិន។ ឧទាហរណ៍បង្កើតឯកសារ បើក firewall និងអនុញ្ញាតឱ្យ Certbot កែ Nginx ។ ម៉ាស៊ីនដែលមានរួចត្រូវពិនិត្យ sites, access rules និងផ្លូវសង្គ្រោះជាមុន។
តើបានដំឡើង WordPress, Node.js ឬ database ដែរឬទេ?
មិនទាន់ទេ។ លទ្ធផលជាគេហទំព័រ static HTTPS ។ រក្សាមូលដ្ឋាននេះឱ្យដំណើរការ រួចបន្ថែម runtime ហើយសាកល្បង startup, health checks និងការស្ដារទិន្នន័យ។