Cấu hình VPS Ubuntu cho website đầu tiên

Chuẩn bị máy mới, tên miền và đường phục hồi

Dùng Ubuntu 24.04 mới, IPv4 công khai, SSH cổng 22, tài khoản ban đầu có sudo và tên miền bạn kiểm soát. Tạo khóa trước khi cấp máy; nếu VPS trống đã tồn tại, dùng nhánh cài khóa qua quyền truy cập đang hoạt động. Lệnh máy cá nhân dùng Bash trên Linux, macOS hoặc WSL; lệnh server chạy trong SSH. Dừng nếu đường dẫn ví dụ thuộc một website đã triển khai.

Thay mọi 203.0.113.10 bằng IP máy và app.example.com bằng hostname của bạn. Tài khoản ubuntu cũng phải thay theo nhà cung cấp. Mở console phục hồi trước khi đổi truy cập hoặc firewall. Image Oracle Cloud Ubuntu phải dùng nhánh riêng, không dùng UFW bên dưới.

Tạo khóa mới hoặc thêm qua kết nối đang hoạt động

Trên máy cá nhân, tạo khóa riêng và đặt passphrase. Nếu tên đã có, chọn tên khác xuyên suốt. Chỉ tệp .pub được chia sẻ; giữ private key tại máy bạn.

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

VPS chưa tạo: tạo Ubuntu 24.04, điền public key vào mục SSH key và xác nhận tài khoản ban đầu. Bỏ qua các lệnh dành cho VPS đã tồn tại; tiếp tục xác minh host fingerprint.

VPS trống đã có: giữ phiên SSH đang hoạt động. Từ terminal khác trên máy cá nhân, sao chép public key bằng cách xác thực hiện đang dùng. Thay existing_vps_key bằng private key cũ; nếu dùng mật khẩu hoặc SSH agent, bỏ -i ~/.ssh/existing_vps_key mà không thay chính sách đăng nhập của server.

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

Trong phiên server đang mở, kiểm tra public key đã tải và nối vào authorized_keys của tài khoản ban đầu của chính bạn. Lệnh giữ các khóa hiện có; ký tự xuống dòng thêm xử lý trường hợp dòng cuối thiếu newline. Nếu không còn quyền truy cập, dùng phục hồi của nhà cung cấp trước.

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

Với cả hai nhánh, so fingerprint của kết nối đầu tiên với public host key cùng loại trong console tin cậy. Với Ed25519, chạy ở console:

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

Trên máy cá nhân, mở kết nối mới bằng khóa vừa tạo; giữ quyền truy cập cũ đến khi thành công.

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

Từ terminal khác trên máy cá nhân, sao chép public key cho quản trị viên riêng ở bước sau. Có thể sao chép lại tệp public key tạm nếu nhánh VPS tồn tại đã tải nó.

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

Tạo quản trị viên và thử đăng nhập riêng

Trên server, chạy getent passwd deploy trước. Kết quả phải không có tài khoản này. Nếu deploy đã tồn tại, chọn tên chưa dùng và thay cả đường dẫn home lẫn nhóm trong mọi bước; không ghi đè tệp khóa của người khác.

Kiểm tra image, tài nguyên, xem nâng cấp rồi tạo quản trị viên. Đặt mật khẩu mạnh để dùng sudo. Các lệnh install đặt chủ sở hữu và quyền hạn chế cho tệp khóa.

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

Mở terminal mới trên máy cá nhân và đăng nhập bằng quản trị viên vừa tạo.

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

Trong phiên server mới, kiểm tra sudo: kết quả phải là root sau khi nhập mật khẩu của deploy. Chỉ tiếp tục tại đây khi cả đăng nhập lẫn sudo hoạt động; vẫn giữ đường truy cập cũ.

sudo whoami

Cài Nginx và dùng firewall được image hỗ trợ

Trên server, cài Nginx trước. Firewall trong guest và firewall mạng của nhà cung cấp đều ảnh hưởng truy cập; giữ console phục hồi và phiên SSH trong lúc chỉnh.

sudo apt install nginx
sudo systemctl enable --now nginx

Tại firewall nhà cung cấp, cho TCP 22 từ vị trí quản trị và TCP 80/443 cho khách website. Nếu SSH dùng cổng khác, giữ cổng thực đó. Quy tắc mạng không tự mở cổng bị guest chặn.

Image Ubuntu trên Oracle Cloud: bỏ toàn bộ khối UFW tiếp theo. Giữ iptables do image cung cấp, nhất là quy tắc iSCSI cho boot/block volume. Cấu hình security list hoặc NSG của OCI và quy tắc guest theo tài liệu cho HTTP/HTTPS. Không flush quy tắc hoặc thay gói firewall; xung đột có thể ngăn máy khởi động.

Nhánh UFW cho image Ubuntu mới khác: chỉ dùng khi nhà cung cấp hỗ trợ và image không cần cấu hình firewall được quản lý riêng. Cho phép cổng SSH thực trước khi bật; ví dụ là 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

Sau mỗi nhánh, thử SSH bằng kết nối mới: phiên đang mở không kiểm tra việc mở kết nối. Kiểm tra HTTP ngoài ở bước sau phải thành công trước khi yêu cầu chứng chỉ.

Đưa trang lên một cấu hình Nginx riêng

Tạo document root và cấu hình mới trên server. Thay hostname trong khối. Giữ EOF có dấu nháy để shell không mở rộng biến Nginx như $uri.

sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="vi"><title>Lần triển khai đầu tiên</title><h1>Trang này được phục vụ từ VPS Ubuntu</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

Chỉ reload trên server khi nginx -t thành công.

sudo systemctl reload nginx

Từ máy cá nhân, yêu cầu hostname tại IP server trước khi đổi DNS. Kết quả phải là tiêu đề của bạn thay vì trang chào Nginx mặc định.

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

Trỏ DNS và cấp chứng chỉ HTTPS

Tạo bản ghi A của hostname trỏ IPv4 VPS. Chỉ thêm AAAA khi IPv6 hoạt động trên máy; AAAA cũ có thể đưa khách hoặc xác minh chứng chỉ đến nơi khác. Ví dụ dùng DNS trực tiếp, không qua proxy.

Từ máy cá nhân, mở http://app.example.com/ không có --resolve và xác nhận đúng trang. Trên server, cài Certbot và plugin Nginx từ kho Ubuntu. Các gói này cần Universe; xử lý lỗi không tìm thấy gói trước khi tiếp tục.

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

Làm theo yêu cầu email và điều khoản. Certbot sửa cấu hình site và chuyển HTTP sang HTTPS. Xác nhận timer gia hạn được lên lịch; nếu chưa hoạt động, bật bằng sudo systemctl enable --now certbot.timer. Giữ cổng 80 truy cập được cho xác minh HTTP và gia hạn.

Kiểm tra từ bên ngoài và sau reboot

Trên máy cá nhân, xác nhận HTTP chuyển sang HTTPS, HTTPS thành công và trả nội dung của bạn. Không thêm curl -k vì nó bỏ qua lỗi xác minh chứng chỉ.

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

Khi còn là môi trường thử, chạy sudo reboot trên server. Sau khi máy trở lại, đăng nhập deploy, kiểm tra systemctl is-active nginx và lặp yêu cầu HTTPS từ ngoài. Reboot ngắt SSH có chủ đích; dùng console nếu máy không trở lại.

Xử lý kiểm tra thất bại và giữ bản dựng lại

Cuộn bảng sang ngang để xem đủ các cột.

Với đăng nhập lỗi, dùng chẩn đoán SSH trước khi đổi chính sách. Giữ tệp website, cấu hình Nginx, DNS và các bước dựng lại ở ngoài VPS. Thử khôi phục trên máy riêng; private key chứng chỉ cần lưu trữ được bảo vệ nếu sao lưu.

Đặt cảnh báo khả dụng và ngày hết chứng chỉ. Một lần kiểm tra thành công không theo dõi lần gia hạn ngày mai. Bắt đầu bằng bài tập sao lưu tệp; khôi phục đầy đủ còn cần tài nguyên khác, chứng chỉ và cấu hình dịch vụ.

Quy trình này phục vụ tệp tĩnh. Runtime ứng dụng hoặc database cần thiết lập dịch vụ và phương pháp sao lưu riêng. Dùng đo tải ứng dụng khi thêm các thành phần đó.