Micro-DevOps với Systemd: Tăng tốc cho bất kỳ máy chủ Linux thông thường nào

Các nền tảng như Kubernetes, Nomad hoặc bất kỳ nền tảng dưới dạng dịch vụ (Paas) nào được lưu trữ trên đám mây đều cung cấp nhiều khả năng mạnh mẽ. Từ việc mở rộng quy mô khối lượng công việc đến quản lý bí mật cho đến chiến lược triển khai, các trình điều phối khối lượng công việc này đều được tối ưu hóa để giúp mở rộng quy mô cơ sở hạ tầng theo nhiều cách khác nhau.

Nhưng các nhà khai thác có luôn phải trả chi phí để có khả năng mở rộng tối đa không? Đôi khi, chi phí của sự phức tạp và tính trừu tượng cao hơn lợi ích của chúng. Thay vào đó, nhiều nhà xây dựng lại dựa vào các kiến trúc triển khai hoàn toàn đơn giản để dễ quản lý. Hai máy chủ riêng ảo phía sau bộ cân bằng tải là một ngăn xếp đơn giản hơn rất nhiều để quản lý so với một cụm máy chủ siêu nhỏ trải dài trên một nhóm máy chủ vùng chứa. Điều này có thể bắt đầu mang lại lợi ích khi có ít bộ phận chuyển động cần gỡ lỗi hơn khi có vấn đề phát sinh hoặc nâng cấp khi đến lúc phải bảo trì chúng.

Nền tảng cho nhiều bản phân phối Linux hiện đại là systemd và nó đi kèm với một bộ tính năng mạnh mẽ thường có thể so sánh với các bộ điều phối container hoặc hệ thống PaaS. Trong bài viết này, chúng ta sẽ khám phá cách bạn có thể tận dụng các tính năng systemd mới nhất để đạt được nhiều khả năng của các hệ thống lớn khác mà không phải đau đầu về quản lý và tăng tốc bất kỳ máy chủ Linux thông thường nào để trở thành một nền tảng ứng dụng rất có khả năng.

Một lớp sơn lót hệ thống

Trên một máy chủ duy nhất, việc ghi tệp .service systemd là một cách lý tưởng để chạy một quy trình được quản lý. Trong hầu hết các trường hợp, bạn thậm chí không cần phải thay đổi ứng dụng: systemd hỗ trợ nhiều loại dịch vụ khác nhau và có thể điều chỉnh cho phù hợp.

Ví dụ: hãy xem xét .service đơn giản này xác định cách chạy một dịch vụ web đơn giản:

 [Unit] Description=a simple web service [Service] ExecStart=/usr/bin/python3 -m http.server 8080

Khi được đặt vào một tệp như /etc/systemd/system/webapp.service , điều này sẽ tạo ra một dịch vụ mà bạn có thể kiểm soát bằng systemctl :

• systemctl start webapp sẽ bắt đầu quá trình.
• systemctl status webapp sẽ hiển thị xem dịch vụ có đang chạy hay không, thời gian hoạt động của dịch vụ và đầu ra từ stderr và stdout cũng như ID của quy trình và thông tin khác.
• systemctl stop webapp sẽ kết thúc dịch vụ.

Ngoài ra, tất cả đầu ra được in ra stderr và stdout sẽ được tổng hợp bởi tạp chí và có thể truy cập được thông qua tạp chí hệ thống (với journalctl ) hoặc được nhắm mục tiêu cụ thể bằng cờ --unit :

 journalctl --unit webapp

Bởi vì tạp chí xoay vòng và quản lý bộ nhớ của nó theo mặc định nên việc thu thập nhật ký qua nhật ký là một chiến lược tốt để quản lý bộ nhớ nhật ký.

Phần còn lại của bài viết này sẽ khám phá các tùy chọn để nâng cao dịch vụ như dịch vụ này.

Bí mật

Bộ điều phối vùng chứa như Kubernetes hỗ trợ khả năng chèn Bí mật một cách an toàn: các giá trị được lấy từ kho dữ liệu an toàn và tiếp xúc với khối lượng công việc đang chạy. Dữ liệu nhạy cảm như khóa API hoặc mật khẩu yêu cầu xử lý khác với các biến môi trường hoặc tệp cấu hình để tránh bị lộ do vô ý.

Tùy chọn LoadCredential=systemd hỗ trợ tải các giá trị nhạy cảm từ các tệp trên đĩa và hiển thị chúng cho các dịch vụ đang chạy một cách an toàn. Giống như các nền tảng được lưu trữ quản lý bí mật từ xa, systemd sẽ xử lý Thông tin xác thực khác với các giá trị như biến môi trường để đảm bảo rằng chúng được giữ an toàn.

Để đưa một bí mật vào dịch vụ systemd, hãy bắt đầu bằng cách đặt một tệp chứa giá trị bí mật vào một đường dẫn trên hệ thống tệp. Ví dụ: để hiển thị khóa API cho đơn vị .service , hãy tạo một tệp tại /etc/credstore/api-key để duy trì tệp qua các lần khởi động lại hoặc tại /run/credstore/api-key để tránh việc duy trì tệp vĩnh viễn ( đường dẫn có thể tùy ý, nhưng systemd sẽ coi các đường dẫn credstore này là mặc định). Trong cả hai trường hợp, tệp phải có quyền hạn chế bằng cách sử dụng lệnh như chmod 400 /etc/credstore/api-key .

Trong phần [Service] của tệp .service , hãy xác định tùy chọn LoadCredential= và chuyển cho nó hai giá trị được phân tách bằng dấu hai chấm ( : ): tên của thông tin xác thực và đường dẫn của nó. Ví dụ: để gọi tệp /etc/credstore/api-key của chúng tôi là “mã thông báo”, hãy xác định tùy chọn dịch vụ systemd sau:

 LoadCredential=token:/etc/credstore/api-key

Khi systemd khởi động dịch vụ của bạn, bí mật sẽ được hiển thị với dịch vụ đang chạy theo đường dẫn có dạng ${CREDENTIALS_DIRECTORY}/token trong đó ${CREDENTIALS_DIRECTORY} là biến môi trường do systemd điền. Mã ứng dụng của bạn phải đọc trong từng bí mật được xác định theo cách này để sử dụng trong các thư viện hoặc mã yêu cầu các giá trị bảo mật như mã thông báo API hoặc mật khẩu. Ví dụ: trong Python, bạn có thể đọc bí mật này bằng mã như sau:

 from os import environ from pathlib import Path credentials_dir = Path(environ["CREDENTIALS_DIRECTORY"]) with Path(credentials_dir / "token").open() as f: secret = f.read().strip()

Sau đó, bạn có thể sử dụng biến secret với nội dung bí mật của mình cho bất kỳ thư viện nào có thể yêu cầu mã thông báo API hoặc mật khẩu.

Khởi động lại

Một khả năng khác của người điều phối như Nomad là khả năng tự động khởi động lại khối lượng công việc đã bị lỗi. Cho dù do lỗi ứng dụng chưa được xử lý hay do một số nguyên nhân khác, việc khởi động lại các ứng dụng bị lỗi là một khả năng rất hữu ích và thường là tuyến phòng thủ đầu tiên khi thiết kế một ứng dụng có khả năng phục hồi.

Tùy chọn Restart= systemd kiểm soát xem systemd có tự động khởi động lại quá trình đang chạy hay không. Có một số giá trị tiềm năng cho tùy chọn này, nhưng đối với các dịch vụ cơ bản, cài đặt on-failure rất phù hợp để đáp ứng hầu hết các trường hợp sử dụng.

Một cài đặt khác cần xem xét khi định cấu hình tự động khởi động lại là tùy chọn RestartSec= , tùy chọn này cho biết systemd sẽ đợi bao lâu trước khi khởi động lại dịch vụ. Thông thường, giá trị này phải được tùy chỉnh để tránh khởi động lại các dịch vụ bị lỗi trong một vòng lặp chặt chẽ và có khả năng tiêu tốn quá nhiều thời gian CPU dành cho việc khởi động lại các quy trình. Một giá trị ngắn không chờ quá lâu như 5s thường là đủ.

Cuối cùng, hai tùy chọn khác cho biết systemd sẽ cố gắng khởi động lại các thiết bị bị lỗi mạnh mẽ như thế nào trước khi từ bỏ. StartLimitIntervalSec= và StartLimitBurst= sẽ kiểm soát tần suất một thiết bị được phép khởi động trong một khoảng thời gian nhất định. Ví dụ: các cài đặt sau:

 StartLimitBurst=5 StartLimitIntervalSec=10

Nó sẽ chỉ cho phép một thiết bị cố gắng khởi động tối đa 5 lần trong khoảng thời gian 10 giây. Nếu dịch vụ được định cấu hình cố gắng khởi động lần thứ sáu trong khoảng thời gian 10 giây, systemd sẽ ngừng cố gắng khởi động lại thiết bị và thay vào đó đánh dấu nó là failed .

Kết hợp tất cả các cài đặt này, bạn có thể bao gồm các tùy chọn sau cho đơn vị .service của mình để định cấu hình khởi động lại tự động:

 [Unit] StartLimitBurst=5 StartLimitIntervalSec=10 [Service] Restart=on-failure RestartSec=1

Cấu hình này sẽ khởi động lại dịch vụ nếu nó bị lỗi - tức là nó thoát ra ngoài dự kiến, chẳng hạn như với mã thoát khác 0 - sau khi đợi một giây và sẽ ngừng cố gắng khởi động lại dịch vụ nếu nó cố gắng khởi động lại hơn năm lần trong suốt khóa học trong 10 giây.

Tăng cường dịch vụ

Một trong những lợi ích chính của việc chạy trong container là hộp cát bảo mật. Bằng cách phân đoạn quy trình ứng dụng khỏi hệ điều hành cơ bản, mọi lỗ hổng có thể có trong dịch vụ sẽ khó chuyển thành thỏa hiệp toàn diện hơn nhiều. Các thời gian chạy như Docker đạt được điều này thông qua sự kết hợp giữa các nhóm và các nguyên tắc bảo mật khác.

Bạn có thể bật một số tùy chọn systemd để thực thi các hạn chế tương tự có thể giúp bảo vệ máy chủ cơ bản trước hành vi khối lượng công việc không thể đoán trước:

• ProtectSystem= có thể hạn chế quyền ghi vào các đường dẫn hệ thống nhạy cảm như /boot và /usr . Tài liệu về tùy chọn này liệt kê tất cả các tùy chọn có sẵn, nhưng nói chung, việc đặt tùy chọn này thành full là một mặc định hợp lý để bảo vệ các đường dẫn hệ thống tệp này.
• ProtectHome= có thể đặt các thư mục /home , /root và /run/user thành chỉ đọc với cài đặt read-only hoặc khi được đặt thành true , hãy gắn chúng vào hệ thống tệp của dịch vụ dưới dạng thư mục trống. Trừ khi ứng dụng của bạn có nhu cầu cụ thể để truy cập vào các thư mục này, việc đặt điều này thành true có thể bảo vệ hệ thống một cách an toàn khỏi việc truy cập bất hợp pháp vào các thư mục đó.
• PrivateTmp= duy trì một /tmp và /var/tmp riêng cho dịch vụ được định cấu hình để các tệp tạm thời cho dịch vụ này và các quy trình khác vẫn ở chế độ riêng tư. Trừ khi có lý do thuyết phục để các quy trình chia sẻ thông tin qua các tệp tạm thời, đây là một tùy chọn hữu ích nên kích hoạt.
• NoNewPrivileges= là một cách an toàn và đơn giản khác để tăng cường dịch vụ bằng cách đảm bảo rằng quy trình được thực thi không thể nâng cao các đặc quyền của nó. Nếu bạn không chắc chắn về khả năng sử dụng các tùy chọn tăng cứng khác thì đây thường là một trong những tùy chọn ít vấn đề nhất để kích hoạt.

Trang hướng dẫn sử dụng systemd.exec là tài nguyên hữu ích để khám phá các tùy chọn khác nhau áp dụng cho khối lượng công việc thực thi như dịch vụ.

Đọc thêm

Các trang hướng dẫn sử dụng cho dự án systemd rất phong phú và hữu ích để tìm hiểu về tất cả các tùy chọn có sẵn để chạy các ứng dụng của riêng bạn. Cho dù bạn đang chạy một dịch vụ liên tục như máy chủ web hay đơn vị .timer định kỳ để thay thế công việc định kỳ, tài liệu systemd có thể cung cấp hướng dẫn hữu ích.