Tweet
DevSecOps (Phần 16): Admin Processes – Vì sao không nên SSH vào Production để chạy lệnh thủ công?
Một tối cuối tuần, hệ thống cần cập nhật cấu trúc cơ sở dữ liệu.
Một kỹ sư SSH vào máy chủ Production và chạy lệnh:
python migrate.py
Lệnh chạy thành công.
Một tháng sau, cần triển khai lại phiên bản cũ để khắc phục sự cố.
Lần này, ứng dụng không khởi động được vì cấu trúc cơ sở dữ liệu đã thay đổi, nhưng không ai nhớ chính xác đã chạy những lệnh gì.
Đây là một vấn đề rất phổ biến trong các hệ thống vận hành thủ công.
Đó cũng là lý do Yếu tố thứ 12 – và cũng là yếu tố cuối cùng của 12-Factor App đưa ra nguyên tắc:
Hay nói cách khác:
Admin Processes là gì?
Ngoài các Process phục vụ người dùng như:
ứng dụng còn có rất nhiều tác vụ quản trị chỉ chạy một lần hoặc theo yêu cầu.
Ví dụ:
Đây chính là Admin Processes.
One-off Process là gì?
Khác với Web Server luôn hoạt động liên tục, Admin Process chỉ tồn tại trong thời gian ngắn:
Start
│
Thực hiện công việc
│
Finish
Ví dụ:
python manage.py migrate
python cleanup.py
python seed.py
Sau khi hoàn thành nhiệm vụ, Process sẽ kết thúc.
Đó là lý do chúng còn được gọi là One-off Processes.
Phải chạy trong cùng môi trường với ứng dụng
Đây là điểm quan trọng nhất của yếu tố này.
Một Admin Process phải sử dụng:
với phiên bản ứng dụng đang chạy.
Nếu Production đang chạy Release v2.1.0, thì Database Migration cũng phải được thực hiện bằng Release v2.1.0, không phải bằng một script cũ hay một phiên bản đang phát triển trên máy cá nhân.
Nhờ vậy, các tác vụ quản trị luôn tương thích với ứng dụng hiện tại và giảm nguy cơ phát sinh lỗi do chênh lệch phiên bản.
Script quản trị cũng phải được quản lý như Source Code
Một sai lầm phổ biến là lưu các script quản trị ở nhiều nơi:
12-Factor App khuyến nghị tất cả các script quản trị phải nằm trong cùng repository với ứng dụng.
Điều này mang lại nhiều lợi ích:
Nói cách khác, script quản trị cũng là một phần của ứng dụng.
REPL hỗ trợ các tác vụ đặc biệt
Nhiều ngôn ngữ lập trình cung cấp REPL (Read–Eval–Print Loop), cho phép chạy nhanh các đoạn mã để kiểm tra hoặc thực hiện các thao tác quản trị.
Ví dụ, Python có thể sử dụng REPL để:
Đây là công cụ hữu ích cho việc vận hành và xử lý sự cố, miễn là nó được sử dụng trong cùng môi trường và cùng phiên bản ứng dụng.
Production không đồng nghĩa với SSH thủ công
Trong môi trường phát triển, bạn có thể chạy trực tiếp:
python migrate.py
Tuy nhiên, trong Production, các tác vụ quản trị nên được thực hiện thông qua cơ chế điều khiển từ xa hoặc công cụ quản lý của nền tảng, thay vì đăng nhập và thao tác tùy ý trên máy chủ.
Mục tiêu là:
DevSecOps và Admin Processes
Một hệ thống DevSecOps hiện đại không chỉ tự động hóa Build, Test và Deploy, mà còn tự động hóa cả các tác vụ quản trị.
Các công việc như:
đều nên được thực hiện như One-off Processes, sử dụng cùng codebase, cùng release và cùng môi trường với ứng dụng đang chạy.
Đây cũng là mảnh ghép cuối cùng của 12-Factor App. Khi kết hợp với các nguyên tắc trước như Configuration, Backing Services, Build–Release–Run, Stateless Processes, Port Binding, Concurrency, Disposability, Dev/Prod Parity và Logs, doanh nghiệp sẽ xây dựng được một ứng dụng Cloud Native dễ triển khai, dễ mở rộng, dễ vận hành và phù hợp với quy trình CI/CD và DevSecOps hiện đại.
Một tối cuối tuần, hệ thống cần cập nhật cấu trúc cơ sở dữ liệu.
Một kỹ sư SSH vào máy chủ Production và chạy lệnh:
python migrate.py
Lệnh chạy thành công.
Một tháng sau, cần triển khai lại phiên bản cũ để khắc phục sự cố.
Lần này, ứng dụng không khởi động được vì cấu trúc cơ sở dữ liệu đã thay đổi, nhưng không ai nhớ chính xác đã chạy những lệnh gì.
Đây là một vấn đề rất phổ biến trong các hệ thống vận hành thủ công.
Đó cũng là lý do Yếu tố thứ 12 – và cũng là yếu tố cuối cùng của 12-Factor App đưa ra nguyên tắc:
Run admin and management tasks as one-off processes.
Hay nói cách khác:
Các tác vụ quản trị phải được thực hiện như những Process độc lập, có thể lặp lại, có thể kiểm soát và được quản lý giống như chính ứng dụng.
Admin Processes là gì?
Ngoài các Process phục vụ người dùng như:
- Web Server
- API Service
- Worker
- Scheduler
ứng dụng còn có rất nhiều tác vụ quản trị chỉ chạy một lần hoặc theo yêu cầu.
Ví dụ:
- Database Migration
- Import hoặc Export dữ liệu
- Dọn dẹp dữ liệu cũ
- Chạy Script bảo trì
- Khởi tạo dữ liệu ban đầu (Seed Data)
- Thực hiện các lệnh quản trị thông qua REPL (Read–Eval–Print Loop)
Đây chính là Admin Processes.
One-off Process là gì?
Khác với Web Server luôn hoạt động liên tục, Admin Process chỉ tồn tại trong thời gian ngắn:
Start
│
Thực hiện công việc
│
Finish
Ví dụ:
python manage.py migrate
python cleanup.py
python seed.py
Sau khi hoàn thành nhiệm vụ, Process sẽ kết thúc.
Đó là lý do chúng còn được gọi là One-off Processes.
Phải chạy trong cùng môi trường với ứng dụng
Đây là điểm quan trọng nhất của yếu tố này.
Một Admin Process phải sử dụng:
- Cùng Source Code.
- Cùng Release.
- Cùng Dependency.
- Cùng Configuration.
với phiên bản ứng dụng đang chạy.
Nếu Production đang chạy Release v2.1.0, thì Database Migration cũng phải được thực hiện bằng Release v2.1.0, không phải bằng một script cũ hay một phiên bản đang phát triển trên máy cá nhân.
Nhờ vậy, các tác vụ quản trị luôn tương thích với ứng dụng hiện tại và giảm nguy cơ phát sinh lỗi do chênh lệch phiên bản.
Script quản trị cũng phải được quản lý như Source Code
Một sai lầm phổ biến là lưu các script quản trị ở nhiều nơi:
- Máy cá nhân.
- USB.
- Email.
- Thư mục dùng chung.
12-Factor App khuyến nghị tất cả các script quản trị phải nằm trong cùng repository với ứng dụng.
Điều này mang lại nhiều lợi ích:
- Được quản lý phiên bản bằng Git.
- Theo dõi được lịch sử thay đổi.
- Đồng bộ với từng Release.
- Có thể review và kiểm thử như các thành phần khác của dự án.
Nói cách khác, script quản trị cũng là một phần của ứng dụng.
REPL hỗ trợ các tác vụ đặc biệt
Nhiều ngôn ngữ lập trình cung cấp REPL (Read–Eval–Print Loop), cho phép chạy nhanh các đoạn mã để kiểm tra hoặc thực hiện các thao tác quản trị.
Ví dụ, Python có thể sử dụng REPL để:
- Kiểm tra dữ liệu.
- Chạy thử một đoạn mã.
- Thực hiện các tác vụ nhỏ mà không cần tạo chương trình mới.
Đây là công cụ hữu ích cho việc vận hành và xử lý sự cố, miễn là nó được sử dụng trong cùng môi trường và cùng phiên bản ứng dụng.
Production không đồng nghĩa với SSH thủ công
Trong môi trường phát triển, bạn có thể chạy trực tiếp:
python migrate.py
Tuy nhiên, trong Production, các tác vụ quản trị nên được thực hiện thông qua cơ chế điều khiển từ xa hoặc công cụ quản lý của nền tảng, thay vì đăng nhập và thao tác tùy ý trên máy chủ.
Mục tiêu là:
- Kiểm soát được ai thực hiện.
- Biết chính xác đã chạy lệnh gì.
- Có thể lặp lại khi cần.
- Giảm rủi ro do thao tác thủ công.
DevSecOps và Admin Processes
Một hệ thống DevSecOps hiện đại không chỉ tự động hóa Build, Test và Deploy, mà còn tự động hóa cả các tác vụ quản trị.
Các công việc như:
- Database Migration.
- Seed Data.
- Cleanup.
- Maintenance Script.
đều nên được thực hiện như One-off Processes, sử dụng cùng codebase, cùng release và cùng môi trường với ứng dụng đang chạy.
Đây cũng là mảnh ghép cuối cùng của 12-Factor App. Khi kết hợp với các nguyên tắc trước như Configuration, Backing Services, Build–Release–Run, Stateless Processes, Port Binding, Concurrency, Disposability, Dev/Prod Parity và Logs, doanh nghiệp sẽ xây dựng được một ứng dụng Cloud Native dễ triển khai, dễ mở rộng, dễ vận hành và phù hợp với quy trình CI/CD và DevSecOps hiện đại.
Attached Files