Tuần vừa rồi mình gặp một case khá thú vị, nghĩ lại thấy đáng để ghi lại như một case study cho chính bản thân và biết đâu sẽ giúp được ai đó sau này.

Khoảng 2 năm trước, mình có xây dựng một website cho một đơn vị nhà nước. Dự án cũ được viết bằng Laravel 5.x, nhưng lần này mình quyết định sử dụng WordPress. Với một website dạng này, mình thấy không cần thiết phải bê cả Laravel vào chỉ để tốn thêm thời gian và công sức.

Lúc đó, tổng dung lượng backup của cả server khoảng 300GB. Sau khi dọn dẹp dữ liệu, loại bỏ các file trùng lặp và những phần không còn cần thiết, mình giảm xuống chỉ còn khoảng 7GB. Sau đó mình xây dựng một custom theme cho WordPress và chuẩn bị deploy lên server.

Những lần deploy đầu tiên

Ban đầu server đặt tại Viettel nên việc triển khai khá đơn giản. Bên Viettel cung cấp tài khoản root, mình cài đặt các service cần thiết rồi chạy là xong.

Thời điểm đó mình vẫn chưa xây dựng Kumix.Cloud. Nếu có rồi thì chắc mọi thứ còn đơn giản hơn rất nhiều.

Sau khoảng 5 lần chuyển VPS, cứ lặp đi lặp lại việc cài đặt môi trường khiến mình khá “thuộc bài”, nhưng cũng bắt đầu thấy hơi nhàm chán. Vì vậy mình chuyển toàn bộ hệ thống sang Docker.

Ý tưởng rất đơn giản:

• Build một lần.
• Đem nguyên Docker sang server mới.
• Chạy lại là xong.

Mình cũng từng cân nhắc dùng một số panel quản lý server, nhưng cuối cùng vẫn không chọn. Lý do là mình không biết họ cài thêm những gì vào hệ thống, và khi cần tùy chỉnh hoặc xử lý sự cố lại phải phụ thuộc vào họ. Mình thích tự kiểm soát toàn bộ hệ thống hơn.

Không còn SSH trực tiếp

Sau một thời gian, đơn vị được chuyển sang sử dụng hạ tầng của một đơn vị khác trong cùng khối.

Máy chủ mới có RAM và ổ cứng rất dư dả, nhưng cách quản lý thì hoàn toàn khác.

• Không thể SSH trực tiếp từ Internet.
• Muốn truy cập phải kết nối qua Check Point Endpoint Security VPN.
• Sau đó còn phải chỉnh file hosts để trỏ đúng domain nội bộ.

Việc quản trị chủ yếu thông qua VMware® vSphere.

Trong terminal của máy ảo gần như không có copy/paste, cũng không có chỗ để upload file trực tiếp.

Lúc đó mình chọn cách “cổ điển” nhất.

Upload file ZIP lên một server khác, sau đó dùng wget để tải về máy chủ nội bộ rồi chạy Docker.

Và mọi thứ hoạt động rất tốt.

Nhưng lần này mọi chuyện đã khác

Một thời gian sau, đơn vị muốn xây dựng thêm một hệ thống quản lý dữ liệu mới.

Hệ thống này có API cho bên thứ ba sử dụng, có người nhập liệu hằng ngày, nhưng không muốn ảnh hưởng đến hệ thống đăng bài hiện tại. Dữ liệu chỉ cần đồng bộ để hiển thị lên website.

Mình xây dựng toàn bộ bằng Laravel và tiếp tục đóng gói bằng Docker để đồng bộ với hệ thống đang chạy.

Đến tuần trước mình quyết định deploy.

Và ngay lập tức gặp vấn đề.

Lần này không thể dùng wget nữa.

Không ping được Google.

Không thể truy cập Internet theo cách bình thường.

Có vẻ như sau lần triển khai đầu tiên, đơn vị đã tăng cường chính sách bảo mật. Máy chủ gần như bị chặn toàn bộ truy cập Internet, chỉ cho phép một số kết nối cần thiết như HTTP/HTTPS phục vụ hệ thống đang chạy.

Lúc đó đã là nửa đêm, lại đúng cuối tuần.

Mình hoàn toàn có thể gọi đội quản lý hạ tầng, nhưng thật lòng thì mình không muốn. Nhiều khi phải chờ, rồi chuyển qua chuyển lại giữa các bộ phận, rất dễ mất cả cuối tuần và có khi phải sang tuần mới triển khai được.

Thế là mình quyết định tự tìm cách xử lý.

Tận dụng chính website đang chạy

Sau một hồi suy nghĩ, mình thử upload file thông qua Media Library của WordPress.

Thật bất ngờ là upload thành công, file không quá nặng nên hoàn toàn upload được như một file zip của bài viết.

Kết hợp với terminal có sẵn trong VMware, mình có thể unzip toàn bộ source code ngay trên server.

Giải quyết được phần source, nhưng Docker lại phát sinh vấn đề mới.

Docker đã được cài sẵn, nhưng không thể docker pull bất kỳ image nào vì toàn bộ kết nối ra Internet đều bị chặn.

Lúc đó mình hỏi AI một câu rất đơn giản:

Liệu có thể export toàn bộ Docker image và mang sang server khác để chạy không?

Và câu trả lời là hoàn toàn có thể.

Mình export toàn bộ Docker image từ máy đang chạy, upload các file thông qua website WordPress hiện tại, sau đó import lại vào server mới.

Ứng dụng lần này mình cũng deploy dưới dạng subfolder chứ không phải domain mới, nên không cần chờ thêm bất kỳ ai cấu hình DNS hay web server.

Sau khoảng 3 tiếng, mọi thứ chạy ổn định.

Không cần nhờ đội quản lý hạ tầng, không cần mở Internet, không cần thay đổi chính sách bảo mật của hệ thống.

Điều mình học được

Có những vấn đề ban đầu nhìn rất đáng sợ, và tưởng rằng không thể nào làm được.

Máy chủ không có Internet, không SSH trực tiếp, không wget. không docker pull.

Tưởng như không còn cách nào để triển khai.

Nhưng khi bình tĩnh phân tích từng bước, tận dụng những gì mình đang có và kết hợp với AI để tìm hướng giải quyết, mọi thứ dần dần được tháo gỡ.

Đôi khi khó không phải vì vấn đề quá lớn.

Mà vì mình chưa nghĩ tới một hướng khác. Và cũng may nữa là mình dùng docker, nên việc có cài thêm service (ví dụ redis chẳng hạn) mình chỉ việc export image ở máy mình rồi upload lên server qua cái trang WordPress đó rồi restore lại là xong. Đúng là trong cái lọ lại có cái chai 🙂 

TL;DR

• Deploy website lên máy chủ của một đơn vị nhà nước.
• Lần đầu triển khai thành công vì chính sách bảo mật chưa quá chặt.
• Lần triển khai thứ hai, máy chủ gần như không thể truy cập Internet, không ping được, không wget, không docker pull.
• Tận dụng website WordPress đang chạy để upload source và Docker image.
• Export/import Docker image thay vì pull từ Docker Hub.
• Deploy thành công sau khoảng 3 tiếng mà không cần nhờ đội quản lý hạ tầng.

Một case nhỏ nhưng khá thú vị.

Mình ghi lại ở đây để sau này nếu gặp lại, hoặc ai đó rơi vào tình huống tương tự, biết đâu sẽ có thêm một hướng để thử.