Thôi end cái seri ở đây =)) mình start nó vào ngày 3/9/2020 và tới hôm nay 7/9/2021. Tính ra là qua một năm, có khi chúng ta nên khai tử nó một cách thiếu chuyên nghiệp nhưng mà kệ thôi, cái blog này mình viết làm note chứ có để làm gì đâu.
Rồi, bài này về cái gì. Đây là một nguyên tắc thiết kế cơ bản đặc biệt khi bạn làm việc như một back-end developer, khi đạt tới một ngưỡng nhất định rồi chúng ta đều phải chú ý tới sigterm. Sigterm hiểu nôm na như cái lệnh bài cẩu đầu trảm của host truyền tới các threads, khi cái lệnh bài rơi xuống thread đơn giản là chết. Và việc của lập trình viên ở đây là người mà sẽ quy định xem, cái threads đó sẽ chết kiểu gì, chết ra sao, có được xóa lịch sử duyệt web trước khi chết không.
Thật ra nghiêm túc mà nói mình đủ khả năng để làm cho các bạn một cái demo nho nhỏ, nhưng mình không muốn, haha. Tự đọc đi.
Rồi, các bạn sẽ kiểu…. ây nó thật sự quan trọng thế à. Kiểu, nó đơn giản chỉ cần ra đi và thả hết phần cứng chiếm dụng là mình vui ý.
Không nhé các cháu nhỏ, nếu bạn chỉ làm một app trẻ con thì ừ, sao cũng được.
Nhưng hãy nghĩ thử, khi bạn có một hệ thống rắc rối, một app ngân hàng, một threads liên quan tới giao dịch cả ngàn tỉ đồng. Bỗng nhiên nó đang chạy, bạn bảo.. ê mày nặng quá đấy, rồi xóa bố nó đi trong khi nó đang thực hiện dở tác vụ ghi dữ liệu vào database. Và rồi kiểu ok, tiền thu của khách rồi nhưng mà trong cơ sở dữ liệu không tồn tại. Thế rồi tính sao? Bán mạng mà trả nợ hay là ra cái cầu nào đấy nhảy xuống chứ gì nữa.
.
Nên là kiểu, ừ cái việc control việc một thread hay ở đây là một container tồn tại ra sao rất là quan trọng. Bạn có thể để container nhận lệnh sau đó xóa file, gửi mail và thoát. Có thể tìm cách bỏ qua cho tới khi các tác vụ quan trọng hoàn thành rồi mới return 0. Ti tỉ quy trình cần làm để đảo bảo hệ thống của bạn không ra đi tìm đường cứu nước.
Kiểu. Mình viết cái này lúc 2h sáng và nghiêm túc thì mình chả muốn demo cái gì cả. Cơ mà mình sẽ viết vài cái idea code, để các bạn có thể hiểu và ừ sử dụng nó ở mức đơn giản.
RỒI VÍ DỤ.
Ví dụ nhá. Bạn tạo một file bash, để khởi chạy services của mình. Nó kiểu
#!/usr/bin/env bash
trap 'rm -rf folderphimcacthu' SIGTERM
while true; do :; doneRồi, cái ý tưởng là cái container sẽ chạy kiểu forever after, cơ mà khi bạn gửi tín yệu yêu cầu ngừng hoạt động, nó sẽ chạy lệnh “rm -rf folderphimcacthu” Sau đó thoát.
Demo trên mang ý nghĩa chúng ta có thể thêm thắt các tiến trình yêu cầu khi nhận các lệnh control. Cái này thì mỗi ngôn ngữ sẽ có một bộ control khác nhau, thế nên là các bạn nên tự thân, mình không có rảnh.
RỒI HẾT VÍ DỤ.
Lần này nó lại là nhanh. HAHA.
ANW ở đây chúng ta có một vài cái lưu ý, vì đăng nào cái này cũng là bài về docker. Mình sẽ nói cho các bạn một cái lỗi mà khi chạy viết dockerfile có thể bạn bỏ qua khiến cho code Sigterm của bạn vô hiệu.
Đây nó thế này.
CMD /start.shvà
CMD ["/start.sh"]Ở đây chúng ta có 2 dòng để dockerfile hiểu nó sẽ khởi chạy script làm thread của container.
Tuy nhiên có một khác biệt ở đây, đó là với lệnh 1, bản thân thứ được gọi thực sự sẽ là
bash -c /start.shLệnh này có nghĩa là chúng ta từ Docker gọi tới bash sau đó bash sẽ khởi chạy script start.sh . Downside ở đây đó chính là với lệnh trên khi muốn truyền một lệnh sys tới bản thân container, nó sẽ truyền tới đối tượng đầu là bash, bash không thể hiểu và truyền xuống dưới process con start.sh được. Ở đây bash và script ở 2 PID cách biệt. Và tất cả đống systerm bạn viết, vô nghĩa.
Lệnh 2, “CMD [“/start.sh”]” Script sẽ được gọi thẳng và có cùng PID với container khi view từ bên trong container nó sẽ có PID là 1. Yep, lúc trap command hoạt động.
Cảm ơn bất kì ai có rảnh nợ đọc tới đây vì đã quan tâm. HẾT.