36 TECH

21/01/2026

Bàn về Tự động hóa trong DevOps Engineering

Khi nghĩ về DevOps, hoặc mới tìm hiểu về DevOps, mình đoán là ai trong chúng ta cũng sẽ nghĩ về CICD đầu tiên. CICD hiểu theo đúng nghĩa của nó là tích hợp liên tục và phân phối/triển khai liên tục, để đạt được điều đó thì chúng ta (là các DevOps Engineer) sẽ phải viết các scripts tự động hóa việc clean, build, test, deploy. Nhưng thực tế, trong DevOps Engineering thì "tự động hóa" được thực hành không chỉ trong CICD mà trong mọi ngóc ngách của toàn bộ vòng đời của hệ thống (SDLC).

CI/CD chủ yếu giải quyết câu hỏi: làm thế nào để đưa code từ tay developer lên production nhanh hơn và ít lỗi hơn. Nhưng khi hệ thống lớn dần, câu hỏi quan trọng hơn lại là: làm thế nào để hệ thống đó tồn tại, tin cậy, mở rộng và tự phục hồi trong thời gian dài mà không tiêu tốn nhiều nỗ lực của con người. Ngay từ bước khởi tạo hạ tầng, Infrastructure as Code (IaC) đã là một hình thức tự động hóa mang tính nền tảng. Việc sử dụng IaC giúp đảm bảo tính tái lập, khả năng audit, rollback và giảm phụ thuộc vào trí nhớ con người. Một hạ tầng mà không thể được tái lập lại một cách xác định thì sớm muộn cũng sẽ trở thành rủi ro vận hành.

Khi hệ thống đi vào vận hành, tự động hóa lúc này sẽ xoay quanh việc quản lý failure. Failure là trạng thái mặc định của distributed system, là DevOps Engineer thì chúng ta phải chấp nhận Failure như một điều bình thường. Tự động hóa lúc này xuất hiện dưới các hình thức như health check, auto-healing, auto-scaling, failover, traffic shifting. Điểm mấu chốt là: con người không nên là thành phần nằm trong critical path của các thao tác lặp đi lặp lại và có thể mô tả bằng logic rõ ràng. Nếu mỗi lần server "oẳng" đều cần con người SSH vào để xử lý và khôi phục thủ công, thì đó không phải là vấn đề kỹ năng, mà là vấn đề thiết kế.

Một tầng sâu hơn nữa của tự động hóa trong DevOps là giảm toil*. Rất nhiều công việc vận hành không khó, nhưng lặp đi lặp lại, không tạo ra giá trị lâu dài và tỷ lệ thuận với quy mô hệ thống: xử lý alert, chạy script, chỉnh config, restart service. Nếu những việc này không được tự động hóa, chúng sẽ âm thầm ăn mòn thời gian, động lực và chất lượng kỹ thuật của đội ngũ. DevOps Engineer lúc này không còn làm “engineering” nữa, mà trông giống như một nhân viên trực tổng đài. Tự động hóa, ở góc nhìn này, là cách để bảo vệ năng lực tư duy dài hạn của con người, chứ không chỉ là tiết kiệm vài phút thao tác.

Tuy nhiên, không phải mọi thứ đều nên được tự động hóa một cách mù quáng. Một bài học lớn từ thực tế là: tự động hóa tệ nguy hiểm hơn làm thủ công. Một script sai chạy trên một máy là sự cố nhỏ; script đó chạy trên toàn bộ production có thể là thảm họa. Vì vậy, DevOps Engineering đòi hỏi tự động hóa phải có kỷ luật: idempotent, có guardrail, có rate limit, có quan sát được trạng thái và có khả năng dừng lại khi mọi thứ đi chệch hướng. Viết automation không phải là “xong là chạy”, mà là thiết kế một hệ thống nhỏ với đầy đủ trách nhiệm như bất kỳ phần mềm production nào khác.

Ở mức độ cao nhất, tự động hóa trong DevOps không còn tồn tại như một tập hợp script bên ngoài hệ thống, mà được nội tại hóa vào chính hệ thống. Hệ thống tự biết khi nào cần scale, khi nào cần reschedule, khi nào cần tự điều chỉnh. Lúc này, DevOps Engineer không còn “chạy automation” nữa, mà tập trung vào việc thiết kế hệ thống sao cho automation trở thành hành vi tự nhiên. Đây là bước chuyển từ automation sang autonomous system (hệ thống tự trị), và cũng là ranh giới giữa vận hành thủ công ở quy mô lớn và vận hành bền vững.

CI/CD chỉ là cánh cửa đầu tiên dẫn vào thế giới tự động hóa của DevOps. Là những DevOps Engineer, chúng ta cần áp dụng tự động hóa xuyên suốt SDLC: từ thiết kế, triển khai, vận hành cho tới tiến hóa hệ thống; dùng phần mềm để quản lý phần mềm, và giải phóng con người khỏi những công việc mà máy móc làm tốt hơn.

(*) toil ở đây là thuật ngữ của Google SRE, chỉ các công việc thủ công, lặp đi lặp lại, có thể tự động hóa được và không mang lại giá trị lâu dài.

07/01/2026

Ghi chép về Mạng Máy Tính 🌐
Internet vận hành dựa trên các quy tắc, và bạn càng hiểu rõ chúng, kỹ năng lập trình của bạn sẽ càng trở nên mạnh mẽ hơn.

Đằng sau mỗi cú nhấp chuột, mỗi yêu cầu gọi API hay mọi tương tác thời gian thực, mạng máy tính chính là bộ động cơ vô hình thúc đẩy tất cả.

Nếu bạn là một nhà phát triển (developer), việc thấu hiểu cách thức hoạt động của IP, DNS, HTTP, định tuyến (routing), phiên (sessions), gói tin (packets) và các giao thức (protocols) không còn là một lựa chọn phụ — đó là điều bắt buộc.

Những khái niệm này điều khiển:

📡 Cách các thiết bị giao tiếp với nhau.

🌍 Cách các trang web được tải lên.

🔐 Cách các kết nối bảo mật được thiết lập.

⚙️ Cách các máy chủ xử lý các yêu cầu.

Đó chính là sự khác biệt giữa việc chỉ "xây dựng ứng dụng" và thực sự "thiết kế nên những hệ thống kỹ thuật".

Hiểu biết về mạng giúp bạn:

Kiểm lỗi (debug) nhanh hơn.

Thiết kế các ứng dụng có khả năng mở rộng.

Viết các API bảo mật.

Hiểu cách trình duyệt, máy chủ và cơ sở dữ liệu giao tiếp với nhau.

Xây dựng các hệ thống duy trì được sự ổn định dưới lưu lượng truy cập thực tế.

Dù bạn là người mới bắt đầu hay đã là một nhà phát triển lâu năm, việc nắm vững kiến thức về mạng sẽ giúp bạn nâng tầm kỹ năng thông qua việc xử lý lỗi nhanh chóng, xây dựng ứng dụng an toàn và hiểu rõ cách thức dữ liệu di chuyển trên toàn cầu.

09/12/2025

🚀🚀🚀 THÔNG NÃO DEPLOY WEB TỪ A-Z: HIỂU BẢN CHẤT ĐỂ KHÔNG SỢ, KHÔNG LÀM MÙ
Chào anh em, làm dev mà nhắc đến Deploy là nhiều ông "rén". Cứ nghĩ đến màn hình đen xì với dòng lệnh Linux là toát mồ hôi, toàn copy-paste tutorial mà không hiểu gì, lỗi cái là tịt.
Post này sẽ giúp anh em hiểu bản chất gốc rễ của quy trình Deploy (không dùng Vercel, Netlify...) áp dụng cho mọi ngôn ngữ.
💡 TƯ DUY CỐT LÕI: DEPLOY = "CHUYỂN NHÀ"
Hãy tưởng tượng:
* Dự án của bạn = Đồ đạc nội thất.
* Máy Local (Máy tính bạn) = Nhà cũ.
* Server = Nhà mới (mà bạn thuê).
* Tên miền = Địa chỉ nhà.
Deploy đơn giản là bê đồ từ nhà cũ sang nhà mới, lắp điện nước để người khác đến chơi. Quy trình chuẩn 6 bước như sau:
BƯỚC 1: THUÊ NHÀ & LẤY CHÌA KHÓA (SERVER)
Server thực chất là một máy tính chạy 24/7, thường dùng Linux (không có chuột, chỉ có dòng lệnh).
* Hành động: Thuê 1 con VPS (AWS, DigitalOcean, Vultr, hay Contabo...).
* Chìa khóa vào nhà: Chính là SSH. Bạn dùng terminal để chui vào điều khiển cái máy đó.
* Lệnh thần thánh: ssh root@IP_Của_Server
* Output: Đăng nhập thành công, thấy dòng "Welcome..." là coi như đã đứng trong nhà mới.
BƯỚC 2: CHUYỂN ĐỒ ĐẠC (ĐƯA CODE LÊN SERVER)
Nhà có rồi, giờ phải mang đồ (Source Code) sang.
* Cách làm: Đừng dùng USB hay gửi file zip. Hãy dùng Git.
* Thao tác: Cài Git trên server → Clone code về (Giống hệt cách bạn làm ở máy local).
* Output: Thư mục code đã nằm yên vị trên server.
BƯỚC 3: LẮP ĐẶT ĐIỆN NƯỚC (LÀM APP CHẠY ĐƯỢC)
Đồ đạc mang sang rồi nhưng chưa cắm điện thì chưa dùng được. Bước này chia làm 2 trường hợp:
👉 Trường hợp 1: Frontend Tĩnh (React, Vue, HTML/CSS)
* Bản chất: Chỉ cần file HTML/CSS/JS.
* Hành động: Chạy lệnh build (ví dụ npm run build) để ra thư mục dist hoặc build. Đây là cái chúng ta cần phục vụ khách.
👉 Trường hợp 2: Backend / Web Động (NodeJS, Python, NextJS)
* Bản chất: Cần môi trường để chạy process.
* Hành động:
* Cài môi trường (Cài Node, Python...).
* Cài Database (nếu cần).
* Cài thư viện (npm install...).
* Tạo file .env chứa biến môi trường.
* Chạy thử (npm run start...).
Output: App chạy được trên server (ví dụ localhost:3000 trên server).
BƯỚC 4: GẮN BIỂN SỐ NHÀ (TÊN MIỀN & DNS)
Server có địa chỉ IP (ví dụ: 123.456...) nhưng nó quá khó nhớ. Bạn cần một cái địa chỉ đẹp (ví dụ: mywebsite.com).
* Hành động: Mua tên miền.
* Cấu hình DNS (Danh bạ): Vào trang quản lý tên miền, tạo A Record:
* Tên: @
* Giá trị: IP_Của_Server_Bạn
* Output: Gõ tên miền, trình duyệt biết đường tìm đến cái Server của bạn.
BƯỚC 5: THUÊ BÁC BẢO VỆ (REVERSE PROXY - NGINX)
Đây là bước quan trọng nhất mà nhiều người không hiểu.
* Vấn đề: Khách đến nhà (User) đi vào cửa chính (Cổng 80). Nhưng cái App của bạn lại đang chạy ở phòng ngủ (Cổng 3000). Khách không biết đường vào.
* Giải pháp: Cần một bác bảo vệ (Nginx hoặc Apache) đứng ở cửa chính.
* Kịch bản:
* Khách gõ domain → Gặp Nginx.
* Nginx: "À, muốn gặp thằng App Nodejs đúng không? Nó ở phòng 3000, để tôi dẫn vào".
* Hành động: Cài Nginx và cấu hình proxy_pass trỏ vào cổng app đang chạy (hoặc trỏ vào thư mục build nếu là web tĩnh).
BƯỚC 6: AN NINH & THẨM MỸ
Để nhà uy tín hơn:
* SSL (Ổ khóa xanh): Dùng Certbot (miễn phí). Nó tự động xin chứng chỉ bảo mật và cài vào Nginx. Web sẽ có https://.
* Firewall (Tường lửa): Mở cổng 80, 443 để đón khách. Đóng các cổng lạ.
* PM2 (Cho Backend): Nếu app lỗi bị tắt, cài PM2 để nó tự động bật lại app (giữ app sống 24/7).
🔥 TÓM LẠI:
Deploy không đáng sợ. Nó chỉ là:
Thuê máy (Server) → Kéo code (Git) → Cài môi trường → Trỏ tên miền (DNS) → Điều hướng (Nginx) → Bảo mật (SSL).
Hiểu bản chất từng bước, lỗi ở đâu sửa ở đó. Chúc anh em thành công!

14/10/2025

Bruh 🥴

14/10/2025

Hết hồn má ơi

08/10/2025

🚀 Perplexity Pro FREE 12 tháng cho người dùng PayPal 🚀
Tin hot cho anh em mê AI: chỉ cần liên kết tài khoản PayPal, bạn sẽ nhận ngay 1 năm Perplexity Pro miễn phí (trị giá $240) 🤯.
👉 Sau 12 tháng free, nếu muốn tiếp tục thì phí là $20/tháng.
👉 Nhanh tay vì đây là ưu đãi độc quyền từ PayPal x Perplexity.
💡 Với Perplexity Pro, bạn sẽ có:
Truy vấn AI không giới hạn ⚡
Kết quả chuẩn xác, nhanh chóng hơn 🔎
Trợ lý học tập, nghiên cứu, làm việc cực hữu ích 📚
👉 Claim ngay tại đây:

Perplexity is a free AI-powered answer engine that provides accurate, trusted, and real-time answers to any question.

05/10/2025

🚀 HƯỚNG DẪN DOCKER TOÀN TẬP – Từ kiến trúc, cơ chế hoạt động đến các lệnh nâng cao cho System Admin và DevOps.

Nếu bạn đang triển khai ứng dụng, lab pentest hay môi trường CI/CD, việc hiểu rõ Docker sẽ giúp bạn kiểm soát tài nguyên và tái tạo môi trường cực kỳ nhanh chóng. 🐳⚙️

⸻

Giới thiệu về Docker

Docker là nền tảng ảo hóa cấp hệ điều hành (OS-level virtualization) cho phép đóng gói ứng dụng cùng toàn bộ thư viện, cấu hình và môi trường phụ thuộc vào các container độc lập.
Container nhẹ, khởi động nhanh và có thể chạy trên bất kỳ hệ thống nào có Docker Engine mà không lo xung đột môi trường.

Khác với máy ảo, Docker không tạo hệ điều hành riêng mà chia sẻ kernel của host. Nhờ đó, việc triển khai và mở rộng ứng dụng diễn ra linh hoạt, tiết kiệm tài nguyên đáng kể.

⸻

Kiến trúc Docker

Hệ thống Docker gồm ba thành phần chính:

1. Docker Client
Là giao diện dòng lệnh (CLI) cho phép người dùng thao tác bằng các lệnh như docker build, docker push, docker pull, docker run. Mọi yêu cầu được gửi đến Docker Daemon để xử lý.

2. Docker Host
Chứa Docker Daemon, chịu trách nhiệm quản lý images, containers, networks và volumes. Daemon cũng giao tiếp với client thông qua REST API hoặc Unix socket.

3. Docker Registry
Kho lưu trữ Docker images, nơi người dùng có thể tải (pull) hoặc đẩy (push) image. Phổ biến nhất là Docker Hub.

⸻

Docker Images

Docker Image là gói phần mềm độc lập chứa toàn bộ mã nguồn, thư viện và cấu hình cần thiết để chạy ứng dụng. Image được xây dựng từ Dockerfile — mỗi lệnh trong file tạo ra một lớp (layer) giúp dễ dàng tái sử dụng.

Các lệnh cơ bản:

# Tạo image từ Dockerfile
docker build -t ten_image .

# Tạo image không cache layer cũ
docker build -t ten_image . --no-cache

# Liệt kê danh sách images
docker images

# Xóa image
docker rmi ten_image

# Xóa image không dùng
docker image prune

⸻

Docker Containers

Container là phiên bản runtime của một image. Khi container chạy, Docker thêm một lớp ghi tạm (writable layer) để lưu thay đổi.

Lệnh quản lý cơ bản:

# Tạo và chạy container
docker run --name ten_container ten_image

# Ánh xạ port từ container ra host
docker run -p 8080:80 ten_image

# Chạy container nền
docker run -d ten_image

# Dừng / khởi động container
docker stop ten_container
docker start ten_container

# Xóa container
docker rm ten_container

Lệnh nâng cao:

# Liệt kê toàn bộ container
docker ps -a

# Xem log container
docker logs ten_container

# Truy cập terminal container
docker exec -it ten_container /bin/bash

# Kiểm tra thông tin chi tiết
docker inspect ten_container

# Theo dõi tài nguyên
docker container stats

⸻

Docker Hub & Registry

# Đăng nhập Docker Hub
docker login -u username

# Push image lên Docker Hub
docker push username/ten_image

# Pull image từ Docker Hub
docker pull username/ten_image

# Đăng xuất
docker logout

⸻

Quy trình hoạt động của Docker

1. docker build tạo image từ Dockerfile.
2. docker push đưa image lên Docker Registry.
3. docker pull tải image về hệ thống khác.
4. docker run khởi tạo container từ image đó.

Tất cả đều được quản lý bởi Docker Daemon, đảm bảo container cách ly hoàn toàn về hệ thống file, process và network.

⸻

Các lệnh quản trị nâng cao

# Thông tin hệ thống Docker
docker info

# Phiên bản Docker
docker version

# Dọn toàn bộ tài nguyên không dùng
docker system prune -a

# Xuất container thành image
docker commit container_id new_image

# Lưu / nạp image qua file
docker save -o backup.tar image_name
docker load -i backup.tar

⸻

Docker giúp chuẩn hóa quá trình triển khai, tăng tốc phát triển và giảm thiểu sai khác môi trường. Từ việc đóng gói ứng dụng, triển khai dịch vụ microservice, cho đến môi trường test tự động — Docker đều là nền tảng không thể thiếu với mọi kỹ sư hệ thống hiện đại.

03/10/2025

Lỗ hổng Termix Docker cho phép truy cập SSH không cần xác thực
Docker image chính thức của Termix tồn tại một cấu hình sai nghiêm trọng, tạo điều kiện cho việc truy cập trái phép vào thông tin đăng nhập SSH.
Hệ quả là endpoint API nội bộ vốn lưu trữ thông tin máy chủ SSH bao gồm địa chỉ, tài khoản và mật khẩu có thể bị truy cập trực tiếp mà không cần cơ chế xác thực, tạo ra rủi ro bảo mật đặc biệt nghiêm trọng.
Chi tiết lỗi và phương án khắc phục tại:
https://devops.vn/new/cve-2025-59951-lo-hong-termix-docker-cho-phep-truy-cap-ssh-khong-can-xac-thuc/
Cre : DevopsVN

19/09/2025

🚀 Biến localhost thành public trong 1 nốt nhạc! 🚀
Mình hay nhiều bạn ở đây sẽ có nhiều người vừa code xong hay chạy xong một dự án của mình nhưng bối rối không biết làm thế nào để có thể public lên internet cả.
Hành trình tìm hiểu sau đó là một chuỗi các kiến thức phức tạp: phải cấu hình Port Forwarding/NAT, xử lý DDNS vì không có IP tĩnh vì nhà nghèo, và chật vật cài đặt SSL/TLS để có HTTPS... 😫 Chưa kể, với những bạn ở trọ như mình, việc có quyền truy cập vào router chính của chú chủ trọ để "mở port" gần như là bất khả thi.
---------------------------------------------------------
✨ Và đây là lúc "Traefik Tunnel Expose" tỏa sáng! ✨
Một đã nghĩ 1 sự kết hợp tuyệt vời giữa Traefik và Cloudflare Tunnel để giải quyết các vấn đề trên một cách tự động mọi thứ
Giới thiệu một chút về công nghệ
🛡️ Cloudflare Tunnel: Hãy tưởng tượng thay vì phải "mở cửa" (port forwarding) nhà bạn cho Internet, công nghệ này sẽ tạo một đường hầm riêng, được mã hóa và siêu an toàn từ máy tính của bạn đến mạng lưới toàn cầu của Cloudflare. Mọi traffic sẽ đi qua đường hầm này. Điều này có nghĩa là: Không cần mở port, không cần IP tĩnh, và mạng nội bộ của bạn luôn được an toàn tuyệt đối.
🚦 Traefik Proxy: Khi traffic đã an toàn vào tới máy bạn qua đường hầm, Traefik sẽ đóng vai trò như một "người điều phối" thông minh. Nó tự động phát hiện các dịch vụ đang chạy và điều hướng traffic từ subdomain tương ứng. Hơn thế nữa, Traefik còn là cung cấp với các cơ chế load balancing, middleware mạnh mẽ (như xác thực OIDC), và nhiều plugin hữu ích khác (nói chung là bá đạo)
Điểm đặc biệt của dự án
⭐ Tự động quản lý DNS: Mình đã tích hợp một cơ chế tự động "theo dõi" và tạo bản ghi subdomain trên Cloudflare DNS. Bạn sẽ không bao giờ cần phải đăng nhập vào trang quản trị của Cloudflare để cấu hình thủ công nữa.
🔄 Luôn luôn cập nhật: Dự án có cơ chế tự động kiểm tra và cập nhật Traefik cũng như Cloudflare Tunnel lên phiên bản mới nhất mỗi 6 giờ, giúp hệ thống của bạn luôn được vá lỗi và có những tính năng mới nhất.
Kết quả mà bạn nhận được:
✅ Triển khai trong vài phút: Tiết kiệm hàng giờ cấu hình mạng và máy chủ.
✅ Bảo mật tối đa: An tâm khi mạng nội bộ của bạn được "vô hình" trên Internet.
✅ Quản lý tập trung: Dễ dàng thêm/sửa/xóa dịch vụ chỉ bằng vài dòng khai báo.
✅ Tự động hóa 100%: Từ tạo subdomain đến có HTTPS, mọi thứ đều tự động.
Mình đã sử dụng giải pháp này cho homelab cá nhân hơn 2 tháng qua và mọi thứ hoạt động rất ổn định. Theo mình, đây là một lựa chọn tuyệt vời cho các máy chủ cá nhân, gia đình, hoặc môi trường staging/demo. (Lưu ý nhỏ là Cloudflare Tunnel miễn phí có thể không phải là giải pháp tối ưu cho các hệ thống chịu tải cực cao ạ).

Nếu mọi người thấy dự án này hữu ích, xin hãy ủng hộ mình bằng một nút sao ⭐ trên GitHub nhé.
Mình rất trân trọng mọi sự quan tâm và đóng góp từ cộng đồng!
Cảm ơn các bạn đã dành thời gian đọc bài viết này! ❤️

🔗 GitHub:
https://github.com/zenkiet/traefik-tunnel-expose

📦 DockerHub:
https://hub.docker.com/r/zenkiet/traefik-tunnel-expose

Exposing internal services securely via Traefik Proxy & Cloudflare Tunnel - zenkiet/traefik-tunnel-expose

17/09/2025

Lại 1 vụ tấn công nữa lợi dụng thư viện nodejs, và là lần thứ 3 trong 1 tuần trở lại đây

Rạng sáng 16/9 theo giờ VIệt Nam, thư viện /tinycolor với 2.2tr lượt tải trung bình hàng tuần đã bị push một bản update kèm với trojan trong script postinstall. Khi được chạy, script này sẽ tải chương trình dò key/env TruffleHog, scan toàn bộ máy tính để tìm kiếm env/key, sau đó sẽ gửi về webhook của kẻ tấn công.

http://socket.dev/blog/tinycolor-supply-chain-attack-affects-40-packages
Cre: J2TEAM

13/09/2025

Tự troll mình đc mấy năm rồi

12/09/2025

Có thể cười đến ch*t