Docker LCMP Multisite WordPress Minimal

Giới thiệu Docker LCMP Multisite WordPress Minimal, bash script giúp đơn giản hóa việc triển khai và cấu hình các trang web WordPress trong môi trường docker, bằng cách tự động tạo và cấu hình các thư mục, tệp cấu hình riêng biệt cho từng trang. Khá hữu ích cho các nhà phát triển và quản trị viên hệ thống đang tìm kiếm một giải pháp hiệu quả để quản lý nhiều trang web WordPress trên Docker

Docker LCMP Multisite WordPress Minimal là một cấu hình docker tối giản, sử dụng các thành phần cơ bản để đảm bảo hiệu suất và khả năng mở rộng. “LCMP” là viết tắt của các thành phần chính trong cấu hình này: Linux, Caddy, MariaDB và PHP.

Tính năng chính

• Tạo Thư Mục và Cấu Hình Tự Động:
  Script tự động tạo cấu trúc thư mục cần thiết cho một trang web WordPress mới, bao gồm thư mục cho cơ sở dữ liệu, mã nguồn web, và các cấu hình khác.
  Tạo các tệp cấu hình cho Docker Compose, PHP, và MariaDB.
• Hỗ Trợ Tùy Chỉnh Domain:
  Cho phép bạn chỉ định domain mới cho từng trang web và tự động cấu hình các tệp môi trường và cấu hình cần thiết.
• Tạo Mật Khẩu Ngẫu Nhiên:
  Script tự động tạo mật khẩu ngẫu nhiên cho cơ sở dữ liệu, giúp nâng cao bảo mật.
• Tạo Alias Dễ Dàng Sử Dụng:
  Cung cấp alias “lcmp” cho phép bạn gọi script một cách nhanh chóng từ bất kỳ đâu trong hệ thống.
• Tính Tương Thích Cao:
  Hỗ trợ chạy trong môi trường Docker với tùy chọn cấu hình chi tiết cho MariaDB, PHP và PHP-FPM, dễ dàng điều chỉnh cho nhiều cấu hình phần cứng khác nhau.

Ưu điểm

• Tiết Kiệm Thời Gian: Tự động hóa quá trình tạo và cấu hình môi trường WordPress, tiết kiệm thời gian và giảm thiểu lỗi.
• Bảo Mật Tốt: Tạo mật khẩu ngẫu nhiên và cấu hình bảo mật cao cho cơ sở dữ liệu và WordPress.
• Dễ Dàng Tùy Chỉnh: Cho phép tùy chỉnh cấu hình PHP, MySQL theo domain và nhu cầu cụ thể của từng trang web.
• Hỗ Trợ Đa Nền Tảng: Hoạt động trên các hệ điều hành hỗ trợ Docker và bash.

Khuyết điểm

• Yêu Cầu Kỹ Năng Kỹ Thuật: Cần có kiến thức cơ bản về Docker, Docker Compose và Bash để cấu hình và sử dụng script một cách hiệu quả.
• Phụ Thuộc Vào Bash Shell: Script yêu cầu môi trường Bash shell để thực thi, không tương thích hoàn toàn với các shell khác.
• Tạo Alias Không Được Áp Dụng Ngay Lập Tức: Các thay đổi alias chỉ có hiệu lực sau khi tải lại cấu hình shell hoặc khởi động lại terminal.

Vâng, đoạn trên mình nhờ AI viết, đọc thấy khét lẹt =)) thực tế các bản đầu tiên script chạy lỗi bét nhè, mở script ra nhìn như tờ giấy lộn, so với trình viết bash script của tác giả Webinoly thì chỉ ở tầm học việc 🐷 không đùa đâu, chứ Webinoly viết bash script mà hơn 20.000 dòng lận ấy 💑 phiên bản Docker LCMP Multisite WordPress Minimal này bạn nào thích em yêu khoa học, dùng cá nhân thì có thể thử 👮

Trước đây mình có làm 1 bash script đơn giản cài đặt LCMP trên Debian ☝️ dạo này có hứng chuyển sang dùng docker nên viết bài này 🤲 ban đầu chỉ muốn viết 1 bài giới thiệu cấu hình nhiều domain chạy qua docker, mà nhiều thao tác vụn vặt quá, rất dễ nhầm các cấu hình nhỏ trong các file compose.yml, nên cố gắng viết thành bash script giúp tự động các quá trình

Cấu trúc chính như sau

Xuất phát ban đầu của Docker LCMP Multisite WordPress Minimal là 1 file lcmp.sh, thêm và xóa các trang, hoạt động xoay quanh 1 container Caddy duy nhất, vừa dùng làm Webserver cho mọi trang, vừa dùng làm Reverse Proxy cho mọi dịch vụ phụ khác

Ý tưởng của mình là tách Caddy + PHP + Mariadb mỗi trang, tách biệt hoàn toàn ra 3 container khác nhau, mà làm thế vấn đề tùy chỉnh port khá mệt người vì mỗi trang phải dùng 1 port khác nhau, một Caddy nhiều PHP + Mariadb chỉ dùng port mặc định 80/443 là đủ, cấu hình lại nhanh hơn nên sau cùng mình chọn cách này

Mỗi domain sẽ là một thư mục riêng, cụ thể như sau

Docker_LCMP_Multisite_WordPress/
├── 📜 lcmp.sh # Script tự động hóa
├── 📁 reverse_proxy/ # Thư mục cấu hình Caddy
│   ├── 📄 Caddyfile # Cấu hình máy chủ proxy Caddy
│   └── 📄 compose.yml # Cấu hình Docker Compose cho Caddy
├── 📁 bibica.net/ # Thư mục cho trang WordPress bibica.net
│   ├── 📁 database/ # Dữ liệu cơ sở dữ liệu
│   ├── 📁 www/ # Mã nguồn và tệp của trang WordPress
│   ├── 📁 config/ # Cấu hình chung
│   │   ├── 📄 bibica.net.conf # Cấu hình domain cho bibica.net
│   │   ├── 📄 bibica.net.env # Chứa thông tin database
│   │   ├── 📁 ssl/ # Chứng chỉ SSL
│   │   │   ├── 🔑 bibica.net.key.pem # Khóa riêng SSL
│   │   │   └── 🔑 bibica.net.pem # Chứng chỉ SSL
│   │   ├── 📁 php/ # Cấu hình PHP
│   │   │   ├── 📄 php-ini-bibica.net.ini # Cấu hình PHP tùy chỉnh
│   │   │   └── 📄 zz-docker-bibica.net.conf # Cấu hình PHP-FPM
│   │   ├── 📁 mariadb/ # Cấu hình MariaDB
│   │   │   └── 📄 mariadb-bibica.net.cnf # Cấu hình MariaDB
│   │   └── 📁 build/ # Thư mục cấu hình build riêng image
│   │       └── 📁 php/ # Thư mục cấu hình PHP build
│   │           └── 📄 Dockerfile # Dockerfile cho cấu hình PHP
│   └── 📄 compose.yml # Cấu hình Docker Compose cho bibica.net
├── 📁 domain.com/ # Thư mục cho trang WordPress domain.com
├── 📁 domain2.com/ # Thư mục cho trang WordPress domain2.com
└── 📁 domain3.com/ # Thư mục cho trang WordPress domain3.com

Mình cố gắng tách nhỏ các phần cho dễ quản lý và cấu hình, bên trong mỗi cấu hình PHP, Mariadb đều có giải thích khá cụ thể, các file đặt tên kèm theo theo domain để thi thoảng ngồi sửa còn biết đang sửa file của domain nào

Cài đặt cấu hình VPS

Trên 1 VPS mới nếu chưa cài gì thì update, upgrade, sau đó reboot lại OS 1 phát cho sạch sẽ là được, nếu chạy trên hệ điều hành Ubuntu, Debial, có thể dùng bash script cấu hình tự động

sudo wget https://go.bibica.net/system_optimization -O system_optimization.sh && sudo chmod +x system_optimization.sh && sudo ./system_optimization.sh

Các bước bao gồm

• Cập nhập hostname (vài nhà cung cấp VPS mình dùng như UpCloud, đôi lúc cài vào nó hostname nó không tự đưa vào file hosts, đôi lúc chạy nó cứ hiện cảnh báo)
• Update và nâng cấp hệ thống, sử dụng ở chế độ DEBIAN_FRONTEND=noninteractive để không cần trả lời yes/no gì cả
• Tắt firewall nếu đã cài đặt (vì mặc định Oracle Ubuntu 22.04 chặn hết các ports)
• Tắt IPv6 vì mình không thấy bất cứ lợi ích nào
• Cài đặt múi giờ Việt Nam
• DNS Server dùng DNS của Cloudflare, Google, thông dụng, nhanh, an toàn
• Bật TCP BBR
• Tạo swapfile và tùy chỉnh Sysctl dựa theo dung lượng RAM của VPS
• Cài đặt các ứng dụng cơ bản curl wget git htop unzip nano zip zstd
• Cài đặt Docker và tối ưu hóa hiệu suất Docker

Các bước cấu hình đều khá cơ bản, chỉ cài những thứ theo mình là hiệu quả, bạn nào cài Docker LCMP Multisite WordPress Minimal có thể cấu hình VPS theo bash script ở trên

Cài đặt Docker LCMP Multisite WordPress Minimal

Mặc định vị trí ban đầu chạy lcmp.sh là nơi bạn muốn chứa tất cả trang, muốn chứa ở thư mục nào thì ban đầu cd chuyển tới vị trí đó rồi chạy lệnh bên dưới với quyền root

sudo wget https://go.bibica.net/docker-lcmp-multisite-wordPress-minimal -O lcmp.sh && sudo chmod +x lcmp.sh && sudo ./lcmp.sh

Ấn phím 1 trên bàn phím để tạo domain mới

Chọn hành động:
1. Tạo domain mới
2. Xóa domain
3. Liệt kê các domain đã tạo
4. Quản lý Docker Container
0. Thoát

Bạn muốn dùng domain nào? bibica.net

Cấu hình cho domain bibica.net đã được thêm vào Caddyfile.
[+] Running 1/1
✔ Container caddy Started 0.6s
Đã khởi động lại Caddy để áp dụng cấu hình mới.
[+] Running 2/2
✔ Container database.bibica.net Started 0.4s
✔ Container wordpress.bibica.net Started 0.8s
Đã khởi động lại container bibica.net để áp dụng cấu hình mới.

Docker nếu đã pull cái images về (nói dễ hiểu là đã cài domain đầu tiên, sau tạo domain mới, sẽ dùng lại images có sẵn trên máy) việc cài đặt domain mới, tốn vài giây, phần minh họa bên trên dùng từ lần tạo domain thứ 2 để hiện thị ngắn bớt =))

Lúc này chỉ cần đổi DNS về IP của VPS, Caddy hỗ trợ tạo SSL qua Let’s Encrypt, ZeroSSL và ACME, việc tạo SSL rất nhanh, trừ khi bạn nghịch xóa domain, tạo mới lại SSL trong 1 ngày quá 5 lần, sẽ bị hạn chế tạo key ssl mới, còn lại thì ổn, nếu dùng Cloudflare DNS bật đám mây màu cam lên cũng được, Caddy hỗ trợ hết, chờ xíu để ssl cập nhập, vào trang là thấy đã cài đặt mặc định sẵn WordPress mới nhất từ hãng 💭

Cá nhân mình luôn dùng SSL từ Cloudflare, nên tạo sẵn thư mục cấu hình ssl, bỏ 2 file pem và key.pem vào thư mục ssl, sau đó bỏ dấu thăng đằng trước file cấu hình domain đi

tls /data/bibica.net/ssl/bibica.net.pem /data/bibica.net/ssl/bibica.net.key.pem

Khởi động lại Caddy bằng câu lệnh bên dưới (hoặc dùng tùy chọn 4 -> 1)

docker restart cadddy

Cấu hình sai gây lỗi, hay nghịch chán muốn xóa domain đó ra làm lại, sử dụng tùy chọn 2. Xóa domain, nhập domain vào là xóa, nếu quên tên domain thì dùng tùy chọn 3 để xem các domain đã tạo

Mình cũng làm sẵn 1 số câu lệnh cho docker ở mục 4. Quản lý Docker Container, đỡ mất công gõ tay

Chọn hành động quản lý Docker:
1. Khởi động lại Caddy - Reverse Proxy
2. Khởi động lại container domain để áp dụng cấu hình mới
3. Đặt quyền truy cập và quyền user cho WordPress bên trong domain
4. Xóa các container, images, và networks không sử dụng
5. Truy cập vào container, ưu tiên bằng bash -> sh
6. Theo dõi cụ thể tình trạng container theo domain
7. Khởi động lại tất cả các container
8. Xóa toàn bộ các container và tất cả mọi thứ liên quan
0. Quay lại menu chính

Người dùng thông thường chủ yếu dùng tùy chọn 1, 2, 3

1. Khởi động lại Caddy – Reverse Proxy khi chỉnh lại các cấu hình Caddy
2. Khởi động lại container khi tùy chỉnh lại các cấu hình PHP, Mariadb
3. chown và chmod lại thư mục WordPress, giúp sửa các lỗi nếu upload file, phân quyền lung tung

Có thể xem lướt tình trạng các container ngay tại đây, muốn xem cụ thể 1 domain đang chạy dùng bao nhiêu % CPU, RAM … có thể dùng tùy chọn 6. Theo dõi cụ thể tình trạng container theo domain (muốn thoát ra thì Ctrl + C vài lần)…. tổng thể là thế, phần này mình bổ xung các tính năng thi thoảng dùng, chủ yếu tạo domain xong script này cũng ít còn tác dụng :]]

Các lỗi có thấy mình đã sửa cơ bản (không chắc 100% còn sót lỗi nào không, vì lần đầu viết bash script dạng này 🐖), ban đầu phiền nhất là cái tùy chọn 1. Tạo domain mới, đọc file, sửa dòng khá lú, tùy chọn 2-3-4 làm râu ria bổ xung thêm, vì trên docker hỗ trợ các container tiện lắm, trên Linux cài PHP, Mariadb hay gì mà xóa sạch ra mới phiền

Lựa chọn phiên bản images

Vẫn thích quan điểm của tác giả Webinoly, anh ấy chỉ dùng các phiên bản hay nguồn chính thức, chứ chẳng tin bố con thèng nào quảng cáo bản này của teo mod miếc xịn xò, ảnh cứ bản chính thức từ hãng ⚽ mình không quan điểm gắt tới thế, bản images nào dùng ngon, tích hợp nhiều tính năng phù hợp thì dùng thôi

Caddy: caddy:2.8.4-alpine
Mariadb: mariadb:10.11.8-ubi9
WordPress: wordpress:php8.3-fpm-alpine

3 phiên bản images sử dụng trên Docker LCMP Multisite WordPress Minimal đều là bản chính thức từ chính hãng, cá nhân mình luôn duy trì quan điểm dùng 1 phiên bản cố định, không dùng bản cập nhập tự động

Ở phiên bản v1.1 dùng cố định các phiên bản như bên dưới

Server	Caddy/v2.8.4
PHP	v8.3.10
MYSQL	v10.11.8-MariaDB
WP-CLI 2.11.0

[PHP Modules]
bcmath
Core
ctype
curl
date
dom
exif
fileinfo
filter
gd
hash
iconv
imagick
intl
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcre
PDO
pdo_sqlite
Phar
posix
random
readline
Reflection
session
SimpleXML
sodium
SPL
sqlite3
standard
tokenizer
xml
xmlreader
xmlwriter
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache

Thứ duy nhất là cài thêm WP-CLI, còn lại dùng như mặc định 🦚

Tạo images riêng

Sử dụng thực tế thì đôi khi chúng ta sẽ gặp tình huống các bản images WordPress thiếu extensions, addon nào đó, mình hay dùng WP-CLI mà bản images mặc định không có sẵn, ai dùng WordPress thì cũng nên cài WP-CLI, nó không dùng giao diện đồ họa, không cần gửi và nhận dữ liệu qua giao thức HTTP, quản lý bộ nhớ tối ưu … dùng tài nguyên cực ít, không bị các lỗi timeout, hiệu năng rất tốt

Ở bản v1.1, sử dụng trực tiếp image WordPress bibica/wordpress-wp-cli-php8.3-fpm-alpine, đã cài sẵn WP-CLI cho mọi domain, đỡ mất thời gian build lại mỗi khi tạo trang WordPress mới

Trong trường hợp mọi người thích tự build riêng thì sửa lại file compose.yml, đổi sang tự build là được

wordpress.bibica.net:
  image: bibica/wordpress-wp-cli-php8.3-fpm-alpine
  #build: ./config/build/php

Bên trong thư mục build đã tạo sẵn thư mục php, bên trong có sẵn Dockerfile nội dung như bên dưới

FROM wordpress:php8.3-fpm-alpine

# Add WP CLI
RUN curl -o /usr/local/bin/wp https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar   && chmod +x /usr/local/bin/wp

Thấy thiếu extensions nào thì bổ xung thêm vào rồi build lại, dùng 1 thời gian, nếu thấy ổn định, chạy ngon ở phiên bản đó, có thể dùng Docker Desktop build lại thành 1 bản images để dùng riêng tùy thích

Update v1.1

Tác dụng chủ yếu nhất của Docker LCMP Multisite WordPress Minimal giúp tạo nhanh cấu hình ban đầu, hỗ trợ nhiều domain, giúp tùy biến tẹt ga các cấu hình PHP, Mariadb …. các tính năng hay dùng nhất mình đã bổ xung khá đầy đủ, chắc sẽ không chỉnh chọt thêm gì ở phiên bản hiện tại nữa

Đây cũng là bản mình dùng trực tiếp hàng ngày cho thèng bibica.net, chạy khoảng 8 tuần nay thấy mọi thứ hoạt động bình thường

Bạn nào thích tùy biến thêm gì cứ wẩy 🐣 nghịch phá dữ quá gây lỗi thì cài mới lại OS rồi chạy lại lcmp là được

Chạy cron cho các container từ bên ngoài

Giải pháp để chạy các cron từ VPS vào thẳng bên trong từng container mà không phải cấu hình tùy chỉnh phức tạp (tạo các Dockerfile) theo mình vẫn là gửi thẳng lệnh vào container

• docker exec: chạy các lệnh bên trong một container đang chạy, nhưng không thể tương tác với nó như nhập dữ liệu hay nhận đầu ra tương tác (thường dùng khi chạy qua cron)
• docker exec -it: kết hợp -i và -t, cho phép tương tác gõ lệnh trong container giống như bạn đang làm việc trực tiếp trong một terminal trên hệ thống đó.

Nếu muốn chạy cài đặt, thêm xóa các thứ gì đó trên container chứa WordPress, ví dụ của thèng bibica.net là wordpress.bibica.net (trong trường hợp nhiều container quá, không nhớ có thể dùng tùy chọn 4 từ lcmp.sh, khi vào sẽ thấy container_name của tất các các container đang chạy)

docker exec -it wordpress.bibica.net bash

Lệnh này mình có bổ xung vào menu 4. Truy cập vào container, ưu tiên bằng bash -> sh

Trong trường hợp muốn chạy wp simply-static run để tạo trang tĩnh qua cron hàng ngày, sử dụng docker exec là đủ, vì cron không hỗ trợ tương tác

docker exec --user 82 wordpress.bibica.net bash -c "wp simply-static run"

Chú ý cần thêm PATH vào đầu script, đảm bảo rằng các lệnh có thể được tìm thấy chính xác khi cron chạy, vì cron trên docker container, thường nó không tìm thấy các biến môi trường

#!/bin/bash

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

start=`date +%s`

# Sử dụng WP-CLI để tạo các file tĩnh
chown -R 82:82 /home/bibica.net/www/vercel-simply-static
docker exec --user 82 wordpress.bibica.net bash -c "wp simply-static run"

# Khởi động lại vercel cho bibica.net
docker exec vercel.bibica.net sh -c "vercel -t xxxxxxxxxxxxxxxx --yes --prod"

end=`date +%s`
runtime=$((end-start))

# Set up Telegram bot API and chat ID
BOT_API_KEY="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
CHAT_ID="xxxxxxxxx"

MESSAGE="Đã tạo trang tĩnh cho static.bibica.net, tổng thời gian: $runtime giây"
curl -s -X POST https://api.telegram.org/bot$BOT_API_KEY/sendMessage -d chat_id=$CHAT_ID -d text="$MESSAGE"

0 3 * * * /home/backup/vercel-simply-static.sh

Sử dụng Docker Network

Mặc định nếu Caddy chạy trên docker, sẽ không kết nối reverse proxy dạng localhost:ports như thông thường được, phải dùng trực tiếp IP public của VPS, mình không thích chuyện này, vì đổi VPS như cơm bữa, mỗi lần đổi VPS cứ phải đổi lại IP ở các dịch vụ thì phiền quá, google thì thấy lời khuyên của tác giả Nginx Proxy Manager là dùng Docker Network

Nôm na dễ hiểu là trên docker, các container ở cùng một mạng thì chúng có thể truy cập trực tiếp với nhau theo container_name, mình dùng theo cấu trúc này từ đầu, các trang WordPress được Docker LCMP Multisite WordPress Minimal tạo ra mặc định cũng đã kết nối trực tiếp vào database theo cách dùng tên container_name

Nếu bạn dùng thêm 1 số dịch vụ ngoài, như Artalk, file cấu hình compose.yaml ban đầu như sau

version: "3.5"
services:
  artalk:
    restart: unless-stopped
    container_name: artalk
    image: artalk/artalk-go
    ports:
      - 8181:23366
    volumes:
      - ./data:/data

Sửa lại 1 chút, bổ xung networks vào là có thể bỏ luôn phần ports đi

services:
  artalk:
    restart: unless-stopped
    container_name: artalk
    image: artalk/artalk-go:2.8.7
    networks:
      - reverse_proxy
    volumes:
      - ./data:/data
networks:
  reverse_proxy:
    external: true

Mình dùng tên mạng là reverse_proxy, ai dùng bản này chỉ cần bổ xung networks vào như các dòng highlight là được

Lúc này cấu hình subdomain cho dịch vụ phụ, chỉ cần vào file domain.com.conf nằm ở thư mục config, thêm thẳng theo container_name và ports của Artalk là 23366

comment.bibica.net {
  tls /data/bibica.net/ssl/bibica.net.pem /data/bibica.net/ssl/bibica.net.key.pem
  reverse_proxy artalk:23366 {
    header_up X-Forwarded-For {header.X-Forwarded-For}
  }
}

Nếu dùng reverse_proxy cho các dịch vụ từ bên ngoài như Jetpack, Cloudinary thì dùng theo IP hoặc domain của dịch vụ đó như thông thường

Sử dụng Docker Network trên Caddy theo mình rất tiện, mới dùng chưa quen hơi bỡ ngỡ, dùng quen rồi thêm vào vài dòng, lại không phải mở ports gì cả (khá tương tự Cloudflare Tunnels), tăng thêm 1 chút bảo mật cho VPS

Backup và restore

Trên Docker LCMP Multisite WordPress Minimal, mọi trang tạo ra đều nằm cùng thư mục với file lcmp.sh, chỉ cần backup nguyên cái thư mục này về, là coi như đã backup toàn bộ các trang đang chạy qua docker, bổ xung thêm cron /var/spool/cron/crontabs/root nữa là đầy đủ

Cụ thể có thể tham khảo bài này

Hiệu năng và bảo mật

Cấu hình Caddy, mình có thêm vào 1 chút ít rule, bảo mật cơ bản cho WordPress

Chặn truy cập đến các tập tin và thư mục nhạy cảm
Chặn truy cập đến các tập tin với đuôi mở rộng cụ thể
Chặn truy cập đến các thư mục hoặc tập tin đặc biệt
Chặn truy cập đến các tập tin PHP backup và cấu hình
Một số tùy chỉnh header để cache file tĩnh

Các cấu hình MariaDB, PHP và PHP-FPM có thể chỉnh sửa thêm xóa tùy thích, cũng đã có chú thích khá đầy đủ để bạn nào không có kinh nghiệm đọc hiểu

Phiên bản cấu hình mặc định, set theo cấu hình thèng bibica.net đang dùng, thử các bài test chịu tải kiểu loader.io hay nhìn tốc độ database từ Query Monitor, mình nghĩ là ổn, không có sự chênh lệch so với cài đặt thông thường

Trên 1 số plugin đặc thù, kiểu Duplicator Pro để backup hệ thống, hiệu năng thọt đi 1 chút ~10%, vấn đề này do bản PHP đang dùng không cấu hình mysqldump (vì nó chỉ cài mỗi PHP), nên tốc độ backup database chậm xuống, làm tổng thời gian chậm đi, khá dễ hiểu

Đợt trước mình thử thời gian Simply Static tạo xong hoàn toàn các trang tĩnh chậm hẳn, dùng trên host thì trung bình 10 phút là xong, dùng qua docker gần 15 phút mới xong, tính theo thời gian thì giảm gần 50%, mà dùng phiên bản images chính thức từ hãng thì hiệu năng ngon, không rõ họ cập nhập thêm gì nữa 🐜

Chạy qua docker tốn RAM nhiều hơn (~50MB), có thể hạn chế phần nào bằng cách dùng các OS như Debian 11, chỉ dùng ~ 50 MB RAM khi vừa khởi tạo, phần vì khi chạy qua docker, mình xác định chạy trên VPS Oracle 24GB RAM, mấy vụ tốn thêm 1 ít RAM này không quan trọng 🔫

Bạn nào thích tùy biến MariaDB, PHP và PHP-FPM cho mỗi trang thì cứ vào cấu hình tương ứng sửa lại là được, xài docker chắc tiện nhất khoản này 💕

Bảo mật có lẽ là thứ nhàn nhất khi dùng docker, mỗi dịch vụ nhỏ chạy trên 1 container, chúng mặc định dùng quyền user, nên rất khó hack, một trang lỡ cài plugin, addon, theme crack vào, có bị hack hay phá thì cũng chỉ ở ảnh hưởng tới container đó, rất khó ảnh hưởng tới các trang khác …. vụ này thì mình nghĩ bạn nào làm dịch vụ, hay trang siêu to khổng lồ, mới lo có người phá, chứ kiểu thèng bibica.net, ngày có vài mạng vào nói thêm cho vui là chính 🌼

Sự đơn giản và phức tạp

Phiên bản Docker LCMP Multisite WordPress Minimal theo mình nó đơn giản, đơn giản từ chính cách vận hành, bản thân chạy qua docker, cũng đã ít phải quan tâm tới bảo mật, Caddy giúp tự tạo SSL, thêm 2-3 dòng cấu hình domain, WordPress thì họ đã tự download sẵn bản WordPress mới nhất, phân quyền các kiểu đầy đủ, hạn chế các rắc rối

Cấu hình cho cả Caddy, PHP, Mariadb rất ít nhưng vẫn đảm bảo đầy đủ các tùy chỉnh, và rất dễ đọc

Nếu bạn mới tìm hiểu về docker, sẽ thấy nó quá là phức phức tạp, mỗi container lại chạy theo 1 mạng, mỗi mạng lại loạn xà quần các IP, mình biết tới docker cũng 5-6 năm, dùng thì tầm cả năm rồi mà khi viết bài này mới hay hóa ra có thể tự login trực tiếp vào container, đụng vào thì cái gì cũng phải google hay xem help, doc … rất là mất thời gian

Nếu bạn không quan tâm cái gì, sau khi thêm domain, đổi DNS xong có thể quên luôn vấn đề này, quản lý mọi thứ qua giao diện trên WordPress là đủ 🍁 sẽ không gặp vấn đề gì

Lỗi nghiêm trọng? 🐛

Ban đầu mình setting thủ công, thử nghiệm trên 3 bản images chính thức, cấu hình, tùy chỉnh mọi thứ xoay quanh 3 bản này, đảm bảo hiệu năng, tính năng và bảo mật cơ bản, vấn đề là sau khi viết tới đây, mình tính thử dùng lại nhiều phiên bản images của nhiều người khác, cứ cài vào là lỗi tung nóc?

Nếu bạn nào dùng bản script này, dùng theo các images set sẵn mặc định là đủ, cần custom thêm gì thì tạo các Dockerfile tùy chỉnh như đã nói ở trên, đỡ phải đi giải quyết các lỗi (nếu có) xảy ra

Cá nhân mình cũng không có nhu cầu dùng images từ các nguồn khác, nghịch vui chẳng sao, chứ lâu lâu tác giả bon mồm thêm tính năng này nọ vào, chạy lỗi với cấu hình đang dùng thì ngồi xử lý vật vã lắm, cứ bản mặc định từ chính hãng cho lành, lỗi gì google cũng tiện

Độ ổn định

Sau khi dùng 3-4 tháng thì khá hài lòng, do mọi thứ đều chạy thông qua docker, VPS gốc gần như không cài gì, rất sạch sẽ, và dễ quan sát, các trang đều dùng Cloudflare cache, VPS thường dùng ~1-5% CPU

Chạy qua docker, nó đã tự lưu các log liên quan tới traffic, kiếm tra tình trạng trên domain bibica.net thì thấy lượng traffic ra vào khá phù hợp, không có gì đặc biệt

Về lượng RAM sử dụng, do đang dùng trên 1 VPS có tới 24GB RAM, nên lượng RAM dùng khá nhiều, bạn nào chạy trên các VPS 1-2GB RAM, sẽ thấy sự tối ưu liên quan tới RAM nhiều hơn

Thực tế sử dụng, sau khi cấu hình domain, cài đặt mọi thứ ban đầu, gần như không cần nhìn vào VPS nữa, đa phần chỉ quản lý trực tiếp từ WordPress, có lẽ trừ trường hợp bạn dùng trên các shop bán hàng, có vài trăm, vài ngàn sản phẩm, tương tác qua lại với khách hàng nhiều, sau 1-2 năm hoạt động, mới cầu cấu hình bổ xung database lại 1 chút, với các blog cơ bản, 1 tháng vài bài viết mới, chắc chạy 3-5 năm không cần nhìn vào server là thường

Kết luận

Tổng thể các ưu điểm của docker rất tuyệt vời, nhưng mình gần như không dùng tới, thứ khả dĩ nhất mình có thể dùng thường xuyên là set giới hạn RAM, CPU và tùy chỉnh cấu hình cho PHP, Mariadb trên từng trang nhỏ, có điều cũng vẽ vời cả, đa phần giờ chúng ta đều dùng Cloudflare Cache, user hiếm khi nào truy xuất trực tiếp tới VPS để lo lắng vấn đề này

Các phiên bản images mặc định từ hãng chạy tốt, các cấu hình Caddy, PHP, Mariadb thêm vào cũng chạy tốt, không gặp vấn đề gì, độ ổn định cao

Vấn đề bảo mật thì không quá chắc chắn, lỗi gì thì kiếm Docker với hãng chửi thôi, nói chứ mình nghĩ tay nào hack nổi các trang chạy thuần qua docker trình cũng thần thánh cmnr, không rảnh hack trang bạn đâu mà lo 🦂

Tổng thể thì khá vui, ít nhất thì cũng đã có bản docker mà mình tự tin vác ra dùng và giới thiệu trên thèng bibica.net, hiệu năng, tốc độ, sự chịu tải đều khá tương đồng với cấu hình thông thường 🍋

Sau khoảng 1 tháng sử dụng trực tiếp trên thèng bibica.net thì khá hài lòng, quyết định đưa nó lên bài viết giới thiệu ở right sidebar, khuyến khích mọi người dùng thử