Notes

Trong phần hai của bài viết này

Tác giả đã chọn Quỹ Nguồn mở và Miễn phí để nhận một khoản đóng góp như một phần của chương trình Viết cho DO donate.
Giới thiệu Trong hướng dẫn hai phần này, bạn sẽ học cách định cấu hình dịch vụ Linux để tự động khởi động lại sau khi khởi động lại hoặc gặp sự cố bằng systemd.
Phần Một bao gồm các khái niệm quản lý dịch vụ Linux chung như init daemon và runlevels. Nó kết thúc với phần trình diễn quản lý dịch vụ trong systemd. Tại đây bạn sẽ kiểm tra các mục tiêu, mong muốn, yêu cầu và các tệp đơn vị.
Phần Hai cung cấp hướng dẫn từng bước để hoàn thành một tác vụ systemd thực tế và phổ biến. Cụ thể, bạn sẽ cấu hình một máy chủ cơ sở dữ liệu MySQL để tự động khởi động sau sự cố hoặc khởi động lại.
Lưu ý: Bạn cũng có thể cân nhắc đọc hướng dẫn sử dụng systemctl rất phổ biến của chúng tôi để kiểm soát các dịch vụ và đơn vị systemd.
- Máy chủ chạy CentOS 8, bao gồm người dùng không phải root có đặc quyền sudo. Để thiết lập tất cả những điều này, bao gồm cả tường lửa, bạn có thể tạo giọt DigitalOcean chạy CentOS 8 và sau đó làm theo Hướng dẫn thiết lập máy chủ ban đầu của chúng tôi.
Giới thiệu Daemon quản lý dịch vụ Các dịch vụ Linux có thể tự phục hồi phần lớn bằng cách thay đổi cách chúng được xử lý bởi trình nền quản lý dịch vụ, còn được gọi là daemon init. Hệ thống Linux sau khi máy khởi động. Kernel tải vào bộ nhớ. Trong số những thứ khác, nó quyết định quá trình người dùng hoặc một dịch vụ hệ thống sẽ tải như thế nào, theo thứ tự nào và liệu nó có tự động bắt đầu hay không.
Khi Linux đã phát triển, hành vi của init daemon cũng vậy. Ban đầu, Linux bắt đầu với System V init, cùng một hệ thống được sử dụng trong Unix. Kể từ đó, Linux đã triển khai trình nền init Upstart (được tạo bởi Ubuntu), và bây giờ là daemon init hệ thống (được triển khai lần đầu tiên bởi Fedora).
Hầu hết các bản phân phối Linux hiện đại đã dần rời xa Hệ thống V và hiện đang sử dụng systemd. Init kiểu cũ hơn (nếu được sử dụng) chỉ được giữ lại để tương thích ngược. FreeBSD, một biến thể của UNIX, sử dụng triển khai System V khác, được gọi là BSD init. Chúng tôi sẽ đề cập đến systemd trong bài viết này vì đây là bài viết gần đây nhất. Trình quản lý dịch vụ phổ biến được sử dụng trong các bản phân phối Linux ngày nay. Tuy nhiên, chúng tôi cũng sẽ nói về System V và Upstart khi cần thiết và xem systemd đã phát triển như thế nào từ đó. Để cung cấp cho bạn một ý tưởng:
Hệ thống V là hệ thống init lâu đời nhất, được sử dụng trong - Debian 6 trở về trước - Ubuntu 9.04 trở về trước - CentOS 5 trở về trước
- Ubuntu 9.10 đến Ubuntu 14.10, bao gồm Ubuntu 14.04 - CentOS 6 - Debian 7 trở lên - Ubuntu 15.04 trở lên - CentOS 7 trở lên
Để hiểu daemon init, hãy bắt đầu với một thứ gọi là runlevel. Runlevels
Runlevel đại diện cho trạng thái hiện tại của hệ thống Linux. Ví dụ: runlevel có thể là trạng thái tắt của máy chủ Linux, chế độ một người dùng, chế độ khởi động lại, v.v. Mỗi chế độ sẽ chỉ định những dịch vụ nào có thể đang chạy ở trạng thái đó.
Một số dịch vụ có thể chạy trong một hoặc nhiều cấp chạy nhưng không chạy trong các cấp khác. Runlevels được biểu thị bằng một giá trị từ 0 đến 6. Danh sách sau đây cho thấy ý nghĩa của từng cấp độ này:
Runlevel 0: Tắt hệ thống Runlevel 1: Một người dùng, chế độ cứu hộ Runlevel 2, 3, 4: Multi-user, text mode with network enable Network Runlevel 5: Multi-user, network enable, graphical mode Runle 6: System reboot
Runlevels 2, 3 và 4 khác nhau tùy theo phân phối. Ví dụ: một số bản phân phối Linux không triển khai runlevel 4, trong khi những bản khác thì có. Một số bản phân phối có sự phân biệt rõ ràng giữa ba cấp độ này. Nói chung, runlevel 2, 3 hoặc 4 có nghĩa là trạng thái mà Linux đã khởi động ở chế độ văn bản, nhiều người dùng, hỗ trợ mạng.
Khi bạn cho phép một dịch vụ tự động khởi động, Linux thực sự đang thêm nó vào một cấp chạy. Ví dụ, trong Hệ thống V, Hệ điều hành sẽ bắt đầu với một cấp chạy cụ thể; và, khi nó khởi động, nó sẽ cố gắng khởi động tất cả các dịch vụ được liên kết với runlevel đó. Trong systemd, runlevel đã trở thành mục tiêu và khi một dịch vụ được thực hiện để tự động khởi động, nó sẽ được thêm vào một mục tiêu. Chúng ta sẽ thảo luận về các mục tiêu sau trong bài viết này.
Giới thiệu System V init Daemon Hệ thống V sử dụng tệp inittab, tệp mà các phương thức init sau này đã giữ lại để tương thích ngược. Hãy chạy qua trình tự khởi động của System V:
1. Daemon init được tạo từ tệp nhị phân / sbin / init 2. Tệp đầu tiên mà daemon init đọc là / etc / inittab 3. techpoe.com Một trong các mục trong tệp này quyết định cấp chạy mà máy sẽ khởi động vào. Ví dụ: nếu giá trị cho runlevel được chỉ định là 3, Linux sẽ khởi động ở chế độ văn bản, nhiều người dùng với kết nối mạng được bật. (Runlevel này được gọi là runlevel mặc định) 4. Tiếp theo, daemon init nhìn sâu hơn vào tệp / etc / inittab và đọc những tập lệnh init nào nó cần để chạy cho runlevel đó
Vì vậy, khi init daemon tìm thấy init script nào mà nó cần để chạy cho runlevel đã cho, nó thực sự tìm ra những dịch vụ mà nó cần để khởi động. Các tập lệnh init này là nơi bạn có thể định cấu hình hành vi khởi động cho các dịch vụ riêng lẻ.
Tập lệnh init là thứ điều khiển một dịch vụ cụ thể trong Hệ thống V. Các tập lệnh init cho các dịch vụ được cung cấp bởi nhà cung cấp ứng dụng hoặc đi kèm với bản phân phối Linux (dành cho các dịch vụ gốc). Bạn cũng có thể tạo tập lệnh init của riêng mình cho một dịch vụ được tạo tùy chỉnh.
Khi một quy trình hoặc dịch vụ như Máy chủ MySQL khởi động trong Hệ thống V, tệp chương trình nhị phân của nó phải tải vào bộ nhớ. Tùy thuộc vào cách dịch vụ được cấu hình, chương trình này có thể liên tục thực thi nền (và chấp nhận các kết nối máy khách). Công việc khởi động, dừng hoặc tải lại ứng dụng nhị phân này được xử lý bởi tập lệnh init của dịch vụ. Nó được gọi là init script vì nó khởi tạo dịch vụ.
Trong System V, init script là một shell script. Chúng còn được gọi là tập lệnh rc (lệnh chạy). Các tập lệnh nằm trong thư mục /etc/init.d. Các tập lệnh này được liên kết tượng trưng với các thư mục / etc / rc. Trong thư mục / etc, có một số thư mục rc, mỗi thư mục có một số trong tên của nó. Các con số đại diện cho các cấp độ chạy khác nhau. Vì vậy, chúng tôi có /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, v.v.
Để khởi động lại dịch vụ sau sự cố hoặc khởi động lại, bạn thường có thể thêm một dòng như thế này vào init script:
- ms: 2345: respawn: / bin / sh / usr / bin / service_name
Để kích hoạt dịch vụ System V bắt đầu tại thời điểm khởi động hệ thống, hãy chạy lệnh sau:
- sudo chkconfig service_name trên
Để vô hiệu hóa nó, hãy chạy lệnh sau:
- sudo chkconfig service_name tắt
Để kiểm tra trạng thái (đang chạy hay đã dừng), hãy chạy lệnh này
- trạng thái service_name của dịch vụ sudo
Giới thiệu Upstart Daemon
Khi cách thức tuần tự hóa tải các công việc và dịch vụ trở nên tốn thời gian và phức tạp hơn với System V init, daemon Upstart đã được giới thiệu để tải hệ điều hành nhanh hơn, dọn dẹp dễ dàng các dịch vụ bị lỗi và sự phụ thuộc có thể dự đoán được giữa các dịch vụ hệ thống.
Upstart init tốt hơn System V init theo một số cách: - Nó không xử lý các tập lệnh shell phức tạp để tải và quản lý các dịch vụ. Thay vào đó, nó sử dụng các tệp cấu hình đơn giản, dễ hiểu và dễ sửa đổi - Các dịch vụ không được tải nối tiếp như System V, điều này làm giảm thời gian khởi động hệ thống - Nó sử dụng một hệ thống sự kiện linh hoạt để tùy chỉnh cách các dịch vụ được xử lý ở các trạng thái khác nhau - Upstart đã các cách tốt hơn để xử lý cách một dịch vụ bị lỗi sẽ hồi sinh. - Không cần phải giữ một số liên kết tượng trưng dư thừa, tất cả chỉ vào cùng một tập lệnh

Để giữ cho mọi thứ đơn giản, UpStart tương thích ngược với System V. Tập lệnh /etc/init.d/rc vẫn chạy để quản lý các dịch vụ hệ thống V bản địa. Sự khác biệt chính của nó là cách nó cho phép nhiều sự kiện được liên kết với một dịch vụ. Kiến trúc dựa trên sự kiện này được phép bắt đầu trở thành một người quản lý dịch vụ linh hoạt. Với việc bắt đầu, mỗi sự kiện có thể bắn ra một kịch bản Shell chăm sóc sự kiện đó. Những sự kiện này bao gồm:

- bắt đầu
- Đã bắt đầu
- Ngừng
- dừng
Ở giữa các sự kiện này, một dịch vụ có thể ở một số tiểu bang, giống như chờ, khởi động trước, bắt đầu, chạy, dừng trước, dừng lại, v.v. upstart cũng có thể thực hiện hành động cho mỗi tiểu bang này, tạo một kiến trúc rất linh hoạt.

Khi khởi động, UPStart sẽ chạy bất kỳ tập lệnh nào của hệ thống v init bình thường. Sau đó, nó sẽ xem dưới thư mục / etc / init. Thực thi các lệnh shell trong mỗi tệp cấu hình dịch vụ. Trong số những thứ khác, các tệp này kiểm soát hành vi khởi động của dịch vụ.
Các tệp có kiểu đặt tên là service_name.conf và chúng có nội dung văn bản thuần túy với các phần khác nhau, được gọi là stanzas. Mỗi khổ thơ mô tả một khía cạnh khác nhau của dịch vụ và cách hoạt động của nó. Để làm cho một dịch vụ tự động khởi động sau khi gặp sự cố hoặc khởi động lại, bạn có thể thêm lệnh khởi động lại trong các tệp cấu hình dịch vụ của nó, như được hiển thị bên dưới cho dịch vụ cron.
Giới thiệu Daemon systemd Phiên bản mới nhất trong các daemon init của Linux là systemd. Trên thực tế, nó không chỉ là một daemon init: systemd là một khuôn khổ bao gồm nhiều thành phần của một hệ thống Linux hiện đại. Một trong những chức năng của nó là hoạt động như một hệ thống. Trình quản lý dịch vụ cho Linux. Trong khả năng này, systemd kiểm soát cách một dịch vụ sẽ hoạt động nếu nó bị treo hoặc máy khởi động lại. Bạn có thể đọc về systemctl của systemd tại đây. Hệ thống V lệnh. Các tập lệnh khởi tạo. Điều đó có nghĩa là bất kỳ dịch vụ System V nào cũng sẽ chạy trong systemd. Điều này có thể thực hiện được vì hầu hết các Upstart. Các lệnh quản trị hệ thống V đã được sửa đổi để hoạt động theo systemd.
Tập tin cấu hình systemd: Tập tin đơn vị Trung tâm của systemd là các tệp đơn vị. Mỗi tệp đơn vị đại diện cho một tài nguyên hệ thống cụ thể. Thông tin về tài nguyên được theo dõi trong tệp đơn vị. Tệp đơn vị dịch vụ là tệp văn bản đơn giản (như tệp Khởi động.conf) với cú pháp khai báo. Điều này làm cho các tệp dễ hiểu và dễ sửa đổi.
Sự khác biệt chính giữa systemd và hai phương thức init khác là systemd chịu trách nhiệm khởi tạo các trình nền dịch vụ và các loại tài nguyên khác như đường dẫn hệ điều hành thiết bị, điểm gắn kết, ổ cắm, v.v. Kiểu đặt tên cho tệp đơn vị là service_name. loại_đơn_vị. Vì vậy, bạn sẽ thấy các tệp như dbus.service, sshd.socket hoặc home.mount.
Cấu trúc thư mục Trong các hệ thống dựa trên Red Hat như CentOS, các tệp đơn vị được đặt ở hai nơi. Vị trí chính là / lib / systemd / system /. Các tệp đơn vị được tạo tùy chỉnh hoặc các tệp đơn vị hiện có được quản trị viên hệ thống sửa đổi sẽ nằm trong / etc / systemd / system.
Nếu một tệp đơn vị có cùng tên tồn tại ở cả hai vị trí, systemd sẽ sử dụng tệp dưới / etc. Giả sử một dịch vụ được kích hoạt để bắt đầu tại thời điểm khởi động hoặc bất kỳ mục tiêu / cấp độ chạy nào khác. Trong trường hợp đó, một liên kết tượng trưng sẽ được tạo cho tệp đơn vị dịch vụ đó trong các thư mục thích hợp trong / etc / systemd / system. Các tệp đơn vị trong / etc / systemd / system thực sự là các liên kết tượng trưng đến các tệp có cùng tên trong / lib / systemd / system.
systemd init Sequence: Đơn vị mục tiêu Một loại tệp đơn vị đặc biệt là một đơn vị đích.
Tên tệp của đơn vị đích có hậu tố là.target. Các đơn vị mục tiêu khác với các tệp đơn vị khác vì chúng không đại diện cho một tài nguyên cụ thể. Đúng hơn, chúng đại diện cho trạng thái của hệ thống tại bất kỳ thời điểm nào. Các đơn vị mục tiêu thực hiện điều này bằng cách nhóm. Khởi chạy nhiều tệp đơn vị phải là một phần của trạng thái đó. Do đó, các mục tiêu systemd có thể được so sánh lỏng lẻo với các runlevel System V, mặc dù chúng không giống nhau.
Mỗi mục tiêu có một tên thay vì một số. Ví dụ: chúng ta có multi-user.target thay vì runlevel 3 hoặc reboot.target thay vì runlevel 6. Khi máy chủ Linux khởi động với nói, multi-user.target, về cơ bản nó đưa máy chủ về runlevel 2, 3 hoặc 4, là chế độ văn bản nhiều người dùng có bật kết nối mạng.
Làm thế nào nó đưa máy chủ đến giai đoạn đó là sự khác biệt nằm ở đâu. Không giống như Hệ thống V, systemd không đưa ra các dịch vụ một cách tuần tự. Trên đường đi, nó có thể kiểm tra sự tồn tại của các dịch vụ hoặc tài nguyên khác và quyết định thứ tự tải của chúng. Điều này giúp các dịch vụ có thể tải song song.
Một sự khác biệt khác giữa các đơn vị đích và runlevel là trong System V, một hệ thống Linux có thể chỉ tồn tại trong một runlevel. Bạn có thể thay đổi runlevel, nhưng hệ thống sẽ chỉ tồn tại trong runlevel mới đó. Với systemd, các đơn vị mục tiêu có thể được bao gồm, có nghĩa là khi một đơn vị mục tiêu kích hoạt, nó có thể đảm bảo các đơn vị mục tiêu khác được tải như một phần của nó.
Ví dụ: một hệ thống Linux khởi động với giao diện người dùng đồ họa sẽ được kích hoạt graphical.target, do đó sẽ tự động đảm bảo multi-user.target cũng được tải và kích hoạt. Theo thuật ngữ Hệ thống V, điều đó giống như việc kích hoạt cấp độ 3 và 5 đồng thời.
Bảng dưới đây so sánh các cấp độ chạy và mục tiêu: systemd default.target
systemd default.target tương đương với runlevel mặc định của System V. Hệ thống V có runlevel mặc định được xác định trong một tệp có tên là inittab. Trong systemd, tệp đó được thay thế bằng default.target. Tệp đơn vị mục tiêu mặc định nằm trong thư mục / etc / systemd / system. Đó là một liên kết tượng trưng đến một trong các tệp đơn vị mục tiêu trong / lib / systemd / system.
Khi bạn thay đổi mục tiêu mặc định, về cơ bản bạn đang tạo lại liên kết tượng trưng đó và thay đổi cấp chạy của hệ thống.
Tệp inittab trong Hệ thống V cũng chỉ định thư mục Linux sẽ thực thi các tập lệnh init của nó từ đó: nó có thể là bất kỳ thư mục nào trong số các thư mục rcn.d. Trong systemd, đơn vị mục tiêu mặc định xác định đơn vị tài nguyên nào sẽ được tải vào thời điểm khởi động.
Khi các đơn vị được kích hoạt, chúng được kích hoạt song song hoặc tất cả theo trình tự. Cách một đơn vị tài nguyên tải có thể phụ thuộc vào các đơn vị tài nguyên khác mà nó muốn hoặc yêu cầu.
systemd Dependencies: Mong muốn và Yêu cầu systemd muốn và yêu cầu kiểm soát cách systemd giải quyết sự phụ thuộc giữa các daemon dịch vụ.
Như đã đề cập trước đây, Upstart đảm bảo tải song song các dịch vụ bằng cách sử dụng các tệp cấu hình. Trong Hệ thống V, một dịch vụ có thể bắt đầu trong một cấp chạy cụ thể, nhưng nó cũng có thể được thực hiện để đợi cho đến khi dịch vụ hoặc tài nguyên khác khả dụng. Theo cách tương tự, các dịch vụ systemd có thể được thực hiện để tải trong một hoặc nhiều mục tiêu, hoặc đợi cho đến khi dịch vụ hoặc tài nguyên khác hoạt động.
Trong systemd, một đơn vị yêu cầu một đơn vị khác sẽ không khởi động cho đến khi đơn vị yêu cầu được tải và kích hoạt. Nếu thiết bị cần thiết bị lỗi vì lý do nào đó trong khi thiết bị đầu tiên đang hoạt động, thiết bị đầu tiên cũng sẽ dừng.
Điều này đảm bảo sự ổn định của hệ thống. Do đó, một dịch vụ yêu cầu một thư mục cụ thể hiện diện có thể được thực hiện để đợi cho đến khi điểm gắn kết đến thư mục đó hoạt động. Mặt khác, một đơn vị muốn đơn vị khác sẽ không áp đặt những hạn chế như vậy. Nó sẽ không dừng nếu đơn vị muốn dừng khi người gọi đang hoạt động. Một ví dụ về điều này sẽ là các dịch vụ không thiết yếu xuất hiện ở chế độ mục tiêu đồ họa.
Ví dụ thực tế: Hiểu trình tự khởi động systemd Để hiểu hành vi khởi động dịch vụ trong systemd, chúng tôi đang sử dụng CentOS 8.3 Droplet. Chúng tôi sẽ làm theo. nhắm mục tiêu theo dấu thỏ xa nhất có thể. trình tự khởi động của systemd tuân theo một chuỗi dài các phụ thuộc.
Đầu tiên, hãy chạy lệnh này để liệt kê tệp đơn vị mục tiêu mặc định: - sudo ls -l /etc/systemd/system/default.target
Điều này hiển thị đầu ra như sau:
Như bạn có thể thấy, mục tiêu mặc định thực sự là một liên kết tượng trưng đến tệp mục tiêu nhiều người dùng trong / lib / systemd / system /. Vì vậy, hệ thống phải khởi động trong multi-user.target, tương tự như runlevel 3 trong System V init.
multi-user.target.wants Tiếp theo, hãy chạy lệnh sau để kiểm tra tất cả các dịch vụ mà tệp multi-user.target muốn:
- sudo ls -l /etc/systemd/system/multi-user.target.wants/*.service
Điều này sẽ hiển thị danh sách các tệp liên kết tượng trưng, trỏ trở lại các tệp đơn vị thực trong / usr / lib / systemd / system /:
Ngoài multi-user.target, có nhiều loại mục tiêu khác nhau như system-update.target hoặc basic.target. Để xem mục tiêu mà mục tiêu nhiều người dùng phụ thuộc vào mục tiêu nào, hãy chạy lệnh sau:
- sudo systemctl show --property "Yêu cầu" multi-user.target|fmt -10
Kết quả cho thấy:
basic.target Bạn có thể chạy lệnh sau để xem có bất kỳ đơn vị cần thiết nào cho basic.target:
- sudo systemctl show --property "Yêu cầu" basic.target|fmt -10
Hóa ra, basic.target yêu cầu sysinit.target:
Và nó cũng muốn có một số mục tiêu: - sudo systemctl show --property "Muốn" basic.target|fmt -10
Lệnh sẽ trả về như sau:
Tiếp tục đệ quy, bạn có thể xem liệu sysinit.target có yêu cầu bất kỳ mục tiêu nào khác đang chạy hay không:
- sudo systemctl show --property "Yêu cầu" sysinit.target|fmt -10
Sẽ không có. Tuy nhiên, sẽ có những mục tiêu khác mà sysinit.target muốn:
- systemctl show --property "Muốn" sysinit.target|fmt -10
Một đầu ra như thế này sẽ xuất hiện:
Kiểm tra tệp đơn vị systemd Bây giờ tiến thêm một bước nữa, hãy xem bên trong tệp đơn vị dịch vụ, tệp cho sshd:
- sudo vi /etc/systemd/system/multi-user.target.wants/sshd.service
Nó trông như thế này:
Bạn có thể thấy tệp đơn vị dịch vụ là sạch sẽ và dễ hiểu. Phần quan trọng đầu tiên là mệnh đề Sau trong phần [Đơn vị]. Điều này cho biết dịch vụ sshd cần tải sau khi mạng.target và sshd-keygen.target được tải.
Phần [Cài đặt] hiển thị dịch vụ được multi-user.target mong muốn. Điều này có nghĩa là multi-user.target sẽ tải daemon sshd, nhưng nó sẽ không tắt hoặc sập nếu sshd bị lỗi trong quá trình tải.
Vì multi-user.target là mục tiêu mặc định, nên sshd daemon phải bắt đầu tại thời điểm khởi động. Trong phần [Dịch vụ], tham số Khởi động lại có giá trị khi không thành công. Cài đặt này cho phép trình nền sshd khởi động lại nếu nó bị treo hoặc có lối ra không sạch.
Trong bài viết này, bạn đã tìm hiểu về các daemon quản lý dịch vụ System V, Upstart và systemd. Bạn đã khám phá các tập lệnh khởi động và tệp cấu hình, các tham số quan trọng, trình tự khởi động và các lệnh kiểm soát hành vi khởi động dịch vụ.
Trong phần hai của bài viết này, chúng tôi sẽ áp dụng những kỹ năng này vào một ví dụ thực tế và sử dụng systemd để cấu hình MySQL. Sau khi hoàn thành, phiên bản MySQL của bạn sẽ tự động khởi động lại sau khi khởi động lại hoặc gặp sự cố. Và trong khi bạn sẽ sử dụng MySQL làm ứng dụng mẫu của mình, bạn có thể thay thế bất kỳ số lượng dịch vụ nào, chẳng hạn như máy chủ web Nginx hoặc Apache.

Website: https://techpoe.com