Sau bài này bạn làm được: giải thích cho đồng đội (hoặc cho chính mình sau sáu tháng) vì sao “Linux trên laptop” và “Linux trên máy chủ” là hai bức tranh khác nhau; biết chỗ đứng của kernel, userland, init và package manager trong vòng đời một node; chọn được hướng đọc tiếp theo trong loạt (FHS, systemd, firewall…) mà không bị lạc trong tài liệu man page.
Vì sao “yêu Linux” lại dẫn tới “phải học vận hành”
Nhiều người tới Linux qua con đường lập trình: shell tiện, package đủ, Docker chạy mượt. Tình yêu đó là chính đáng — nhưng máy chủ đặt thêm các câu hỏi mà desktop hiếm khi hỏi:
- Ai khởi động dịch vụ khi máy reboot, và theo thứ tự nào?
- Log nằm ở đâu, rotate thế nào, ai trả tiền cho IOPS của ổ khi log vỡ trận?
- Bản vá security tới từ đâu — và khi nào ta chấp nhận reboot?
- Khi incident xảy ra, bạn có một playbook hay chỉ có muscle memory từ năm 2017?
Loạt bài Linux & vận hành máy chủ không cố dạy lại ls hay grep. Nó giả định bạn đã ở lại với Linux đủ lâu để muốn hệ thống hoá: biến kinh nghiệm thành mô hình có thể nhân rộng cho nhiều máy, nhiều đồng đội, nhiều năm.
Kernel, userland và “Linux” mà ta gọi tên
Kernel (Linux proper) là phần đàm phán trực tiếp với phần cứng: scheduler, bộ nhớ, mạng, filesystem, cgroup… Mọi syscall từ process đều đi qua đây.
Userland là thế giới bên trên: shell, thư viện C (glibc, musl), systemd, sshd, nginx, interpreter… Đây là nơi chính sách vận hành (ai được chạy gì, log đi đâu, cập nhật ra sao) được cài vào bằng package và file cấu hình.
Khi nói “Ubuntu 24.04 trên server”, ta đang nói tới một bản phối (distribution): kernel (thường được distro vá và build lại) + bộ package mặc định + quy ước đường dẫn + công cụ quản trị. Hai distro có thể dùng cùng họ kernel nhưng khác nhau ở phiên bản systemd, thư viện SSL, và cả triết lý (ví dụ immutable OS như Fedora CoreOS so với “classic” Debian/Ubuntu server).
Bài học ops: đừng tranh luận “distro nào bá nhất” trong phòng incident. Hãy biết phiên bản kernel, init system, và nguồn package của đúng node đang cháy.
# Kernel và hostname — thông tin tối thiểu khi vào máy lạ
uname -a
cat /etc/os-release
# Ví dụ output quan trọng: VERSION_ID, ID_LIKE, PRETTY_NAME
Máy chủ không phải máy tính để bạn “nghịch theme”
| Khía cạnh | Desktop / laptop | Máy chủ (typical) |
|---|---|---|
| Người dùng | Một người (bạn), GUI | Không GUI; nhiều service account |
| Khởi động | Bạn bấm nút | Remote datacenter; serial/IPMI đôi khi là cứu cánh |
| Thay đổi | Cài gói thoải mái | Thay đổi = rủi ro; cần thay đổi có kiểm soát |
| Hiệu năng | Latency cảm nhận | Throughput, tail latency, SLA |
| Bảo mật | VPN, browser | Biên mạng, key-only SSH, patch cadence |
“Server mindset” không có nghĩa là nhàm chán — nó có nghĩa là mỗi thay đổi đều có chi phí rollback. Đó là lý do ta học systemd (bài 5), snapshot/backup (bài 12), và firewall (bài 9) như một hệ thống chứ không phải mẹo rời rạc.
Pets vs cattle — ẩn dụ có thật trên hoá đơn cloud
- Pets: máy được “vuốt ve” tay; cấu hình tích luỹ theo năm; không ai dám rebuild. Rủi ro: snowflake — không tái tạo được, không test được restore.
- Cattle: máy thay thế được; cấu hình từ cloud-init / Ansible / image; identity nằm ở dữ liệu và DNS chứ không nằm ở UUID của ổ cứng. Rủi ro: phải đầu tư IaC và kỷ luật không SSH vào “sửa nhanh” rồi quên commit.
Thực tế hầu hết team nằm giữa hai đầu: vài pets (DB chủ, bastion), phần còn lại cattle (app node). Bài học: đừng giả vờ mọi thứ đã cattle nếu restore drill chưa từng chạy thành công.
Vòng đời một node (từ bootstrap tới decommission)
[Provision] → [Bootstrap cấu hình] → [Join môi trường: DNS, NTP, repo]
→ [Hardening + monitoring agent] → [Chạy workload]
→ [Patch & rotate] → [Scale in / thay thế] → [Wipe & chứng minh xoá dữ liệu]
- Provision: VM trên cloud, bare metal qua kickstart, hoặc golden image.
- Bootstrap: user SSH, cloud-init chạy script đầu tiên — đây là chỗ dễ lộ secret nếu script log ra stdout.
- Join: hostname/FQDN, resolver, đồng bộ thời gian (bài 11) — sai NTP là chuyện “ma” cho TLS và log.
- Hardening: user/sudo (bài 4), SSH (bài 10), firewall (bài 9).
- Run: systemd quản unit (bài 5); cgroup giới hạn tài nguyên (bài 6).
- Patch: repo mirror, maintenance window, unattended-upgrades vs orchestrated reboot (bài 8).
- Thay thế: drain traffic, snapshot cuối, tắt máy, xác minh disk đã wipe nếu chứa dữ liệu nhạy cảm.
Container và VM: Linux vẫn là nền
Khi bạn chạy container, phần lớn “Linux bạn thấy” là namespace + cgroup trên một kernel host. Khi bạn chạy VM, mỗi guest có kernel riêng — hai lớp patch và hai lớp clock skew có thể xảy ra.
Không đào sâu Kubernetes trong loạt này, nhưng kiến thức cgroupv2, journald, iptables/nftables trên node là nền để đọc doc K8s mà không bị ngợp.
Liên hệ với loạt Mạng & DevOps
Bài Mạng Linux trên server là “tầng gói tin trên host”. Loạt linux-ops đi song song theo trục “OS & dịch vụ & đĩa”. Khi debug, bạn thường xoay hai trục:
- Mạng: có route không? có LISTEN không? firewall DROP không?
- OS: service có crash-loop không? disk full inode không? clock lệch không?
Câu hỏi hay gặp
1. “Tôi chỉ cần Docker, có bỏ qua systemd được không?”
Trên đa số distro hiện đại, container engine vẫn gắn với systemd (socket activation, unit restart policy). Bạn có thể không viết unit file, nhưng bạn vẫn cần đọc journalctl khi dockerd không lên.
2. “LTS kernel là gì và tôi có cần quan tâm?”
LTS (longterm) là nhánh kernel được backport vá dài hơn. Cloud provider thường build kernel riêng — điều quan trọng là phiên bản bạn đang chạy và CVE có ảnh hưởng module nào (ví dụ TCP, io_uring).
3. “Khi nào nên dùng minimal image?”
Khi bạn có pipeline cài đủ dependency tái lập được và muốn giảm bề mặt tấn công. Nếu chưa có pipeline đó, minimal image dễ biến thành máy mà mọi người apt install lung tung để “cho chạy được”.
Bài tiếp theo trong loạt
→ Phần 2: FHS và đường dẫn cấu hình thường gặp — đi sâu /etc, /var, và cách tìm file cấu hình trên máy lạ mà không đoán mò.