Khai trương trang web nền ESI-Press

ESI Website

Ngày hôm nay - 21/07/2017, sau một thời gian tinh chỉnh và cập nhật, chúng tôi chính thức đã đưa ESI-Press vào áp dụng trên trang web của ESI, quá lâu rồi nó chưa được cập nhật gì. Đằng sau sự kiện này là cả một câu chuyện dài, mà bây giờ tôi chỉ kể một phần thôi.
Mời các bạn đọc tiếp

ESI-Press, sự khởi đầu mới

Chúng ta đã quá quen thuộc với nhiều hệ thống xuất bản web mã mở, từ xa xưa như Joomla, Drupal, php-fox, rồi đến sự vươn lên mạnh mẽ của WordPress nhờ vào chính sự hosting của trang WordPress.org. Nhiều phần mềm nổi tiếng xây dựng dựa trên nền PHP, được gọi cái tên chung là Content Management System (CMS).

Sự lên ngôi mạnh mẽ của mô hình phân phối mã nguồn mở miễn phí và hosting giá rẻ, nhu cầu xuất bản cá nhân khiến bùng nổ số lượng web site chạy các CMS trên, muôn hình vạn trạng, các kiểu thiết kế, đối tượng từ cá nhân cho đến công ty. Nhiều CMS software đã sinh ra, biến mất đi, dù loại nào, nguồn mở, thương mại, dịch vụ miễn phí (như Google Sites) hay có phí đắt đỏ xây dựng riêng, để lại bức tranh thị trường đầy màu sắc, cạnh tranh khốc liệt.

Bên cạnh CMS, thị trường template và plug-in cho các CMS, đặc biệt là cho WordPress, cũng phát triển mạnh mẽ tạo công ăn việc làm cho vô số web dev, muôn hình từ miễn phí (CC License) cho đến mất phí mua. Chuẩn HTML5 được chuẩn hoá, và trào lưu smartphone phát triển, responsive web design đã thổi một luồng khí mới vào web site, rồi sau đó trào lưu single-page web manh nha nhen nhóm… Bức tranh trở nên ổn định với các CMS hiện tại, responsive ư? quá dễ, single page web ư? có vẻ hơi rắc rối chút nhưng không sao, có plug-in là ok.

Thị trường nhiều, tại sao tôi vẫn làm ESI-Press?

ESI-Press được phối thai ý tưởng, khi mà tôi tìm kiếm một giải pháp cho phép khách hàng của mình an toàn hơn với web xuất bản cài trên máy của tôi, giảm bớt sức lực của tôi (devops) trong vấn đề an toàn bảo mật, lẫn hiệu năng của website. Để nhằm mục đích dù sử dụng các bộ template kém an toàn, không rõ nguồn gốc trên Internet, hay kể cả sự ác ý từ chính họ thì server của tôi hoặc các khách hàng virtual-host khác cùng web-instance vẫn an toàn.

Setup một virtual - hosting cho web-site để nó đảm bảo an toàn cho chính hosting và website đó, là một việc ác mộng, rất tốn công sức của sysadmin, lại phải hi sinh quá nhiều về hiệu năng, chi phí tăng lên. Sự giúp sức của SELinux, độc lập về MySQL DB Host, kiểm soát ngặt nghèo đối tượng đưa code lên server, ảo hoá từng khu vực, hay đóng container, dù vẫn chạy mod_php, đã giúp tôi phần nào trong việc đó. Chả có cái lý nào mà CMS lại đi “ping” hay “telnet” một host bên ngoài cả, audit log của selinux là thứ phải theo dõi thường xuyên, tốn thì giờ.

Việc update code của CMS đang vận hành là một việc bắt buộc, thường xuyên, tốt nhất nên update qua repository của Linux distro. Nhưng mô hình xây dựng site do dev thực hiện, ví dụ site với WordPress, là lấy source code từ site nhà sản xuất, cài lên host, thêm plugin vào, thêm template. Nó bắt buộc tôi phải cho phép apache process được “write” vào chính thư mục chứa nó (để tự update code, thêm được các module..) khiến việc kiện toàn bảo mật trở nên khó khăn (tôi làm sao chặn được up code do hacker hay do admin làm đây?). Các include của WP khá lằng nhằng nên việc setup nhiều site dùng chung 1 code base bất khả thi. Kết quả 100 site bạn sẽ có 100 thư mục, 100 code base, rất vất vả trong việc update chúng, mà phải có admin của site mới làm việc đó dễ dàng được.

Các CMS trên nền PHP đều gặp phải 1 vấn đề lớn nữa về bảo mật. Kèm theo khả năng hỗ trợ upload nội dung (ảnh, video) lên là khả năng up cả mã độc, làm sao up được nội dung lên mà không nhằm “shell-code”, nhất là user upload? Rất khó và mất thì giờ. Các biện pháp như kiểm soát đuôi file, check nội dung, resize ảnh… được các CMS áp dụng triệt để, nhưng đâu đó vẫn để lọt. Thảm hoạ bị hạn chế bởi các kỹ thuật do việc tải lên thì do script đảm nhiệm, nhưng tải xuống thì do web server (apache) thực hiện, khiến cho việc kiểm soát nội dung là “thực thi” hay “không thực thi” được trở nên khó khăn hơn.

Giá bán hosting và làm web càng ngày càng giảm, cạnh tranh giá đến mức … vô lý. Ấy vậy mà vẫn diễn ra. Tôi gặp hàng chục khách hàng đã làm web, kêu ca về chất lượng kém của web dev cho site họ, đề nghị nhưng tôi lại không thể nhận hợp đồng với giá đó được, nếu vẫn chạy WP, vẫn Drupal… Phải có cách nào khác để tốn ít công sức hơn, hiệu năng cao hơn và an toàn hơn.

Phát triển front-end - giai đoạn 1

Tôi quyết định viết dòng code đầu tiên vào cuối năm 2014. ESI-Press dựa trên framework ESI-Apps, đã được phát triển trước đó trên Java cho tất cả các kiểu ứng dụng web có back-end là RDBMS (viết lệnh SQL với JDBC). Công đoạn viết code cho front site (phần trang cho khách hàng truy cập tự do) chỉ chiếm ít thời gian, nhưng thời gian làm một số mẫu template cho nó quá lâu vì tôi không giỏi web design. Ngôn ngữ template tôi chọn sử dụng là XSLT vì nó rất an toàn, chuẩn mực, lại rất mạnh đủ để đáp ứng các yêu cầu web design phức tạp đến đâu (có thể nói là mạnh nhất trong các ngôn ngữ tôi từng biết). XSLT lại là ngôn ngữ duy nhất chạy cả trên browser một cách native (XSLT1.0), với ý định dùng nó render trên browser khi cần để giảm tải cho server.
Phần admin (web master) thì tôi đành tạm chưa làm, mọi update nội dung cho web tôi cập nhật thẳng vào DB. Thiết kế DB được học lại 1 phần từ WordPress, nhưng giảm độ flexible của nó đi nhằm tối ưu hoá lại cho phép query tối ưu hơn. Tôi bổ sung khả năng kiểm soát nhiều phiên bản cho mỗi bài, dự định thêm khả năng đa ngữ nữa.

Về viết bài cho trang web, tôi cũng đưa vào lưu trữ, render bài viết dạng markdown, một cách viết bài text format đơn giản qua đánh dấu vài ký tự. Không hẳn lúc nào dùng html với editor cũng đã hay bởi nó mạnh nhưng nó lại rắc rối cho người ít chuyên môn về web, sự hỗ trợ lại hạn chế.

Tôi cũng viết dòng code đầu tiên cho module EPFS, một servlet cho phép upload/download file qua REST hoặc form upload, với backend là GridFS của MongoDB. Upload sẽ mạnh mẽ hơn vì hỗ trợ PUT với REST (thay vì mỗi form), và quan trọng là nó an toàn. Nội dung bạn upload lên sẽ nằm nguyên si trong MongoDB, được lấy về chính xác từng byte khi tải xuống, chả bao giờ hệ thống coi đó là “file” thực thi cả, nó chỉ là 1 binary object trong DB mà thôi. Tuy nhiên hiệu năng chung có thể giảm vì GridFS chậm hơn file system, bù lại, nó chạy phân tán với khả năng lưu trữ phân tán, scale out vô tận của MongoDB, và replication của nó tuyệt vời. Bạn đã bao giờ vận hành server cho site có trên 1 triệu file hình ảnh chưa? bạn backup nó qua server khác hay replication thử xem. EPFS ra đời với mục đích như thế đó, xử lý vấn đề an toàn, hiệu năng và khả năng lưu trữ nhiều file.

Trang mcard.vn là web đầu tiên sử dụng phiên bản này. Tôi kiêm luôn web-master cập nhật nội dung cho trang, thêm bài mới, bởi việc cập nhật là phải làm trực tiếp vào cơ sở dữ liệu vì phần quản trị site chưa làm xong.

Phát triển code giai đoạn 2, xin đón đọc bài kế tiếp EP Master.