Khởi chạy cục bộ trang web Ruby cũ (legacy) đã hoàn thành

Trang web cũ bizneshelper.ru đã được khởi chạy thành công cục bộ trong Docker.

Cấu hình môi trường legacy đã được xác nhận

• Ruby on Rails 3.2.21.
• Máy chủ gốc sử dụng Ruby 2.2.5 thông qua Passenger.
• Ruby 2.2.10 được sử dụng cho container như là một phiên bản tương thích của cùng nhánh đó.
• Bundler 1.15.4.
• MySQL được sử dụng như một dịch vụ bên ngoài đã được khởi chạy sẵn.
• Trang web được chạy trong môi trường production.

Những việc đã được thực hiện

• Chuẩn bị Dockerfile cho ngăn xếp (stack) Ruby cũ dựa trên Ruby 2.2.10.
• Chuyển đổi các nguồn apt cho Debian Jessie sang kho lưu trữ lưu trữ (archive repositories), vì các kho lưu trữ chính thức của phiên bản này không còn khả dụng.
• Cài đặt các phụ thuộc hệ thống cần thiết để biên dịch các gem legacy và vận hành MySQL/libv8.
• Thêm dịch vụ bizneshelper vào docker-compose và kết nối nó với dịch vụ MySQL hiện có thông qua các biến môi trường.
• Cấu hình một cổng cục bộ riêng để truy cập ứng dụng.
• Thêm hỗ trợ kết nối MySQL qua host thay vì sử dụng Unix socket cục bộ trong database.yml.
• Hạ cấp phiên bản ckeditor xuống nhánh tương thích với Rails 3.2.
• Xác nhận rằng sự hiện diện của các thư mục hướng Rails 5 là app/channels và app/jobs không chặn quá trình khởi động với cấu hình production hiện tại khi đã tắt tính năng tải trước lớp (class loading) chủ động.

Các đặc điểm và rủi ro đã phát hiện

1. Debian Jessie yêu cầu sử dụng kho lưu trữ lưu trữ và các tham số cài đặt gói đặc biệt.
2. Một số gem legacy không tương thích với các phiên bản thư viện hiện đại và yêu cầu cố định các phiên bản cũ.
3. mysql2 thuộc nhánh cũ rất nhạy cảm với môi trường và cách thức kết nối với MySQL.
4. ckeditor ở phiên bản mới hơn sử dụng API Rails 4+ và do đó phải được cố định ở phiên bản tương thích.
5. Dự án gốc chứa các thành phần (artifact) của các phiên bản Rails mới hơn, cho thấy các thay đổi mang tính lịch sử của dự án và đòi hỏi sự cẩn trọng khi tự động di chuyển mã nguồn.

Kết quả

Trang web legacy có thể tái tạo khởi chạy cục bộ và sẵn sàng làm tiêu chuẩn cho việc kiểm kê tiếp theo, so sánh hành vi và di chuyển sang haih-cms.

Những việc cần kiểm tra tiếp theo

• Tính đầy đủ của việc hiển thị các trang chính và biểu mẫu.
• Hoạt động tìm kiếm với Solr.
• Tính chính xác khi tải lên các tệp media cũ.
• Hoạt động của trang quản trị (admin panel).
• Các định tuyến thực tế, friendly_id và chuyển hướng (redirects).
• Sự phù hợp của cơ sở dữ liệu cục bộ với cấu trúc dữ liệu ban đầu.

Nhật ký công việc công khai (worklog) không ghi lại mật khẩu, đường dẫn tuyệt đối cục bộ và các tham số môi trường nhạy cảm khác.

Làm rõ về tính khả tái lập khi chạy Docker

Khi khởi động lại container, một sự cố điển hình của các ứng dụng Rails cũ (legacy) đã được phát hiện: ứng dụng ghi các tệp runtime trực tiếp vào cây thư mục dự án, vốn được gắn kết (bind-mount) toàn bộ vào container.

Lỗi được phát hiện

Rails từ chối khởi động với thông báo A server is already running vì tệp server.pid vẫn còn tồn tại trong tmp/pids/ từ lần chạy trước. Khi dừng đột ngột hoặc tạo lại container, tệp này vẫn nằm trên hệ thống tệp của host cùng với dự án.

Nguyên nhân

Toàn bộ thư mục trang web được mount vào container. Điều này tạo ra đồng thời hai hiệu ứng:

1. Nội dung được chuẩn bị trong image bên trong thư mục ứng dụng có thể bị ghi đè bởi nội dung bind-mount của host sau khi container khởi động. Do đó, việc cài đặt các phụ thuộc gắn liền với trạng thái của dự án được mount không thể được coi là hoàn tất một cách đáng tin cậy chỉ ở giai đoạn build Dockerfile.
2. Các tệp runtime của Rails (tmp/pids và có thể là dữ liệu tạm thời khác) được lưu bên trong thư mục được mount và tồn tại lâu hơn vòng đời của container. Tệp PID cũ sau đó sẽ chặn lần khởi động mới.

Giải pháp đã áp dụng

Lệnh khởi động dịch vụ đã được bổ sung thêm một bước chuẩn bị:

rm -rf /app/tmp/pids/ && (bundle check || bundle install --frozen) && bundle exec rails server -b 0.0.0.0

Logic khởi động hiện tại như sau:

• các tệp PID cũ của Rails bị xóa trước khi khởi động;
• bundle check nhanh chóng kiểm tra sự hiện diện của các gem cần thiết;
• bundle install --frozen chỉ được thực thi nếu các phụ thuộc còn thiếu hoặc chưa đầy đủ;
• sau khi chuẩn bị xong, Rails server được khởi chạy, lắng nghe trên giao diện của container.

Kết luận kiến trúc

Mô hình Docker hiện tại được định hướng để tái tạo trực tiếp nhất có thể một dự án legacy thông qua bind-mount mã nguồn, thay vì sử dụng một image hoàn toàn bất biến (immutable). Đối với môi trường di chuyển thử nghiệm, điều này có thể chấp nhận được, nhưng điều quan trọng cần lưu ý là trạng thái của dự án và container runtime bị trộn lẫn một phần.

Khi tiếp tục sử dụng môi trường này, cần quản lý riêng các thư mục tmp, log, các tệp tải lên và các phụ thuộc để các tệp tạm thời của ứng dụng legacy không ảnh hưởng đến tính lặp lại khi khởi động. Nếu môi trường cần được sử dụng lâu dài hoặc bàn giao cho các nhà phát triển khác, việc tách các thư mục runtime có thể thay đổi thành các volume riêng biệt hoặc loại khỏi cơ chế bind-mount là điều hợp lý.

Kết quả

Sau khi sửa đổi lệnh khởi động, container có thể sống sót qua các lần khởi động lại một cách chính xác và tự động khôi phục các phụ thuộc bị thiếu mà không cần xóa thủ công các tệp PID của Rails.