Notes

この記事のパート2

著者は、Write for DOnationsプログラムの一環として寄付を受け取るために、無料のオープンソース基金を選択しました。
序章 この2部構成のチュートリアルでは、systemdを使用して再起動またはクラッシュした後に自動的に再起動するようにLinuxサービスを構成する方法を学習します。
パート1では、initデーモンやランレベルなどの一般的なLinuxサービス管理の概念について説明します。 最後に、systemdでのサービス管理のデモンストレーションを行います。 ここでは、ターゲット、ウォンツ、リクワイアード、およびユニットファイルを調べます。
パート2では、実用的で一般的なsystemdタスクを完了するためのステップバイステップのチュートリアルを提供します。 具体的には、クラッシュまたは再起動後に自動的に起動するようにMySQLデータベースサーバーを構成します。
注：systemctlを使用してsystemdサービスとユニットを制御する方法についての非常に人気のあるチュートリアルを読むことも検討してください。
-sudo権限を持つroot以外のユーザーを含むCentOS8を実行しているサーバー。ファイアウォールを含め、これらすべてをセットアップするには、CentOS 8を実行するDigitalOceanドロップレットを作成してから、初期サーバーセットアップガイドに従います。
サービス管理デーモンの紹介 Linuxサービスは、主に、initデーモンとも呼ばれるサービス管理デーモンによる処理方法を変更することで自己回復させることができます。 マシンの起動後のLinuxシステム。 カーネルがメモリにロードされます。 特に、ユーザープロセスまたはシステムサービスをロードする方法、順序、および自動的に開始するかどうかを決定します。
Linuxが進化するにつれて、initデーモンの動作も進化しました。 もともと、LinuxはUnixで使用されていたものと同じSystem Vinitで始まりました。 それ以来、LinuxはUpstart initデーモン（Ubuntuによって作成された）を実装し、現在はsystemd initデーモン（Fedoraによって最初に実装された）を実装しています。
最近のほとんどのLinuxディストリビューションは、System Vから徐々に移行し、現在systemdを使用しています。古いスタイルのinit（使用されている場合）は、下位互換性のためにのみ保持されます。 UNIXの変種であるFreeBSDは、BSDinitと呼ばれる別のSystemV実装を使用します。 これは最新のものであるため、この記事ではsystemdについて説明します。 現在Linuxディストリビューションで使用されている一般的なサービスマネージャー。 ただし、必要に応じてSystem VとUpstartについても説明し、そこからsystemdがどのように進化したかを確認します。 あなたにアイデアを与えるために：
System Vは最も古いinitシステムであり、-Debian6以前-Ubuntu9.04以前-CentOS5以前で使用されています
--Ubuntu9.10からUbuntu14.10（Ubuntu 14.04を含む）-CentOS 6 -Debian7以降-Ubuntu15.04以降-CentOS7以降
initデーモンを理解するために、ランレベルと呼ばれるものから始めましょう。 ランレベル
ランレベルは、Linuxシステムの現在の状態を表します。 たとえば、ランレベルは、Linuxサーバーのシャットダウン状態、シングルユーザーモード、再起動モードなどです。各モードは、その状態で実行できるサービスを決定します。
一部のサービスは1つ以上のランレベルで実行できますが、他のサービスでは実行できません。 ランレベルは、0〜6の値で示されます。次のリストは、これらの各レベルの意味を示しています。
ランレベル0：システムのシャットダウンランレベル1：シングルユーザー、レスキューモードランレベル2、3、4：マルチユーザー、ネットワークが有効なテキストモードランレベル5：マルチユーザー、ネットワークが有効、グラフィカルモードランレベル6：システムの再起動
ランレベル2、3、および4は、ディストリビューションによって異なります。 たとえば、一部のLinuxディストリビューションはランレベル4を実装していませんが、他のディストリビューションは実装しています。 一部のディストリビューションでは、これら3つのレベルが明確に区別されています。 一般に、ランレベル2、3、または4は、Linuxがマルチユーザーのネットワーク対応のテキストモードで起動した状態を意味します。
サービスの自動開始を有効にすると、Linuxは実際にサービスをランレベルに追加します。たとえば、System Vでは、OSは特定のランレベルで起動します。 そして、起動すると、そのランレベルに関連付けられているすべてのサービスを起動しようとします。 systemdでは、ランレベルがターゲットになり、サービスが自動開始されると、ターゲットに追加されます。 ターゲットについては、この記事の後半で説明します。
System V initDaemonの紹介 System Vはinittabファイルを使用します。このファイルは、後のinitメソッドが下位互換性のために保持しています。 SystemVの起動シーケンスを実行してみましょう。
1.initデーモンはバイナリファイル/ sbin / initから作成されます。2。initデーモンが読み取る最初のファイルは/ etc / inittabです。3。このファイルのエントリの1つは、マシンが起動するランレベルを決定します。 たとえば、ランレベルの値が3と指定されている場合、Linuxはネットワークが有効になっているマルチユーザーのテキストモードで起動します。 （このランレベルはデフォルトのランレベルと呼ばれます）4。次に、initデーモンは/ etc / inittabファイルをさらに調べて、そのランレベルで実行する必要のあるinitスクリプトを読み取ります。
したがって、initデーモンは、特定のランレベルで実行する必要のあるinitスクリプトを見つけると、実際に起動する必要のあるサービスを見つけます。 これらのinitスクリプトは、個々のサービスの起動動作を構成できる場所です。
initスクリプトは、System Vの特定のサービスを制御するものです。サービスのinitスクリプトは、アプリケーションのベンダーによって提供されたか、Linuxディストリビューション（ネイティブサービスの場合）に付属しています。 カスタム作成されたサービス用に独自のinitスクリプトを作成することもできます。
MySQLサーバーなどのプロセスまたはサービスがSystemVで起動する場合、そのバイナリプログラムファイルをメモリにロードする必要があります。 サービスの構成方法によっては、このプログラムはバックグラウンドを継続的に実行する（そしてクライアント接続を受け入れる）場合があります。このバイナリアプリケーションの開始、停止、または再読み込みのジョブは、サービスのinitスクリプトによって処理されます。 サービスを初期化するため、initスクリプトと呼ばれます。
System Vでは、initスクリプトはシェルスクリプトです。 これらは、rc（コマンド実行）スクリプトとも呼ばれます。 スクリプトは/etc/init.dディレクトリの下にあります。 これらのスクリプトは、/ etc / rcディレクトリにシンボリックリンクされています。 / etcディレクトリ内にはいくつかのrcディレクトリがあり、それぞれの名前に番号が付いています。 数字はさまざまなランレベルを表しています。 したがって、/ etc / rc0.d、/ etc / rc1.d、/ etc /rc2.dなどがあります。
クラッシュまたは再起動後にサービスを再起動するには、通常、initスクリプトに次のような行を追加します。
--ms：2345：respawn：/ bin / sh / usr / bin / service_name
System Vサービスをシステムの起動時に開始できるようにするには、次のコマンドを実行します。
--sudo chkconfig service_name on
無効にするには、次のコマンドを実行します。
--sudo chkconfig service_name off
ステータス（実行中または停止中）を確認するには、このコマンドを実行します
--sudo service service_name status
Upstartデーモンの紹介
ジョブとサービスをロードするシリアル化された方法がSystemV initでより時間がかかり複雑になるにつれて、Upstartデーモンが導入され、OSのロードの高速化、クラッシュしたサービスの適切なクリーンアップ、およびシステムサービス間の予測可能な依存関係が実現しました。
いくつかの点で、UpstartinitはSystemVinitよりも優れていました。 -サービスをロードおよび管理するための難解なシェルスクリプトを処理しませんでした。 代わりに、理解と変更が容易な単純な構成ファイルを使用します-サービスはSystem Vのようにシリアルにロードされなかったため、システムの起動時間が短縮されました-柔軟なイベントシステムを使用して、さまざまな状態でのサービスの処理方法をカスタマイズしました-Upstartクラッシュしたサービスがどのようにリスポーンするかを処理するためのより良い方法。-すべて同じスクリプトを指す冗長なシンボリックリンクを多数保持する必要はありませんでした
簡単にするために、UpstartはSystemVとの下位互換性があります。/etc/init.d/rcスクリプトは引き続き実行されてネイティブのSystemVサービスを管理します。 その主な違いは、複数のイベントをサービスに関連付ける方法です。 このイベントベースのアーキテクチャにより、Upstartは柔軟なサービスマネージャーになることができました。 Upstartを使用すると、各イベントは、そのイベントを処理するシェルスクリプトを起動できます。 これらのイベントには次のものが含まれます。
-開始-開始-停止-停止 これらのイベントの合間に、サービスは待機、事前開始、開始、実行、事前停止、停止など、さまざまな状態になる可能性があります。Upstartはこれらの各状態に対してもアクションを実行できるため、非常に柔軟に対応できます。建築。
起動時に、UpstartはSystem Vinitスクリプトを通常どおり実行します。 次に、/ etc / initディレクトリの下を調べます。各サービス構成ファイルでシェルコマンドを実行します。 特に、これらのファイルはサービスの起動動作を制御していました。
ファイルの命名スタイルはservice_name.confであり、スタンザと呼ばれるさまざまなセクションを持つプレーンテキストコンテンツが含まれています。 各スタンザは、サービスのさまざまな側面とその動作方法を説明します。 クラッシュまたは再起動後にサービスを自動的に開始するには、以下にcronサービスについて示すように、サービス構成ファイルにrespawnコマンドを追加します。
systemdデーモンの紹介 最新のLinuxinitデーモンはsystemdです。 実際、これはinitデーモン以上のものです。systemdは、最新のLinuxシステムの多くのコンポーネントを網羅するフレームワークです。 その機能の1つは、システムとして機能することです。 Linuxのサービスマネージャー。 この容量では、systemdは、サービスがクラッシュしたり、マシンが再起動したりした場合のサービスの動作を制御します。 ここでsystemdのsystemctlについて読むことができます。 SystemVコマンド。 初期化スクリプト。つまり、SystemVサービスもsystemdで実行されます。 ほとんどのUpstartが原因で、これが可能です。 System Vの管理コマンドは、systemdで動作するように変更されました。
systemd構成ファイル：ユニットファイル systemdの中心にはユニットファイルがあります。 各ユニットファイルは、特定のシステムリソースを表します。 リソースに関する情報は、ユニットファイルで追跡されます。 サービスユニットファイルは、宣言型構文の単純なテキストファイル（Upstart.confファイルなど）です。 これにより、ファイルの理解と変更が容易になります。
systemdと他の2つのinitメソッドの主な違いは、systemdがサービスデーモンと、デバイスのオペレーティングシステムパス、マウントポイント、ソケットなどの他のタイプのリソースの初期化を担当することです。ユニットファイルの命名スタイルはservice_nameです。ユニット型。 したがって、dbus.service、sshd.socket、home.mountなどのファイルが表示されます。
ディレクトリ構造 CentOSのようなRed Hatベースのシステムでは、ユニットファイルは2か所にあります。主な場所は/ lib / systemd / system /です。システム管理者によって変更されたカスタム作成されたユニットファイルまたは既存のユニットファイルは/ etc / systemd / systemの下に住んでいます。

両方の場所に同じ名前のユニットファイルが存在する場合、systemdは/ etcの下のものを使用します。サービスが起動時刻またはその他のターゲット/ランレベルで開始することができるとします。その場合、/ etc / systemd / systemの適切なディレクトリの下でそのサービスユニットファイルのシンボリックリンクが作成されます。 / etc / systemd / systemの下のユニットファイルは、実際には/ lib / systemd / systemの下の同じ名前のファイルへのシンボリックリンクです。

Systemd Init配列：標的単位
特殊なタイプのユニットファイルはターゲットユニットです。

ターゲットユニットのファイル名は.targetによって接尾辞になります。ターゲット単位は、1つの特定のリソースを表していないため、他のユニットファイルとは異なります。むしろ、それらはいつでもシステムの状態を表します。ターゲット単位グループ化によってこれを行います。その状態の一部になる必要がある複数の単位ファイルを起動します。したがって、SystemDターゲットはSystem V Runlevelsと緩く比較できますが、それらは同じではありませんが、同じではありません。

各ターゲットには数字の代わりに名前があります。たとえば、RunLevel 3の代わりにrunlevel 3またはreboot.targetの代わりにmultiuser.targetを持っています。これはネットワークが有効になっているマルチユーザーテキストモードです。

それがその段階までサーバーをどのようにもたらすかは、違いがあるところです。システムVとは異なり、SYSTEMDはサービスを順番に表示しません。途中で、他のサービスやリソースの存在を確認し、それらのロードの順序を決定することができます。これにより、サービスが並行してロードすることが可能になります。

ターゲット単位とランレベルの他の違いは、システムvでは、Linuxシステムが1つのランレベルで存在する可能性があることです。ランレベルを変更することはできますが、システムはその新しいランレベルにのみ存在します。 systemdを使用すると、ターゲットユニットを包括的にすることができます。つまり、ターゲットユニットがアクティブになると、他のターゲットユニットがその一部としてロードされるようになります。
たとえば、グラフィカルユーザーインターフェイスで起動するLinuxシステムでは、graphical.targetがアクティブ化されます。これにより、multi-user.targetも自動的にロードされ、アクティブ化されます。 System Vの用語では、ランレベル3と5を同時にアクティブ化するようなものです。
次の表は、ランレベルとターゲットを比較しています。 systemd default.target
systemd default.targetは、SystemVのデフォルトのランレベルと同等です。 System Vには、inittabというファイルで定義されたデフォルトのランレベルがありました。 systemdでは、そのファイルはdefault.targetに置き換えられます。 デフォルトのターゲットユニットファイルは、/ etc / systemd / systemディレクトリにあります。 これは、/ lib / systemd / systemの下にあるターゲットユニットファイルの1つへのシンボリックリンクです。
デフォルトのターゲットを変更すると、基本的にそのシンボリックリンクが再作成され、システムのランレベルが変更されます。
System Vのinittabファイルは、Linuxがinitスクリプトを実行するディレクトリも指定しました。これはrcn.dディレクトリのいずれでもかまいません。 systemdでは、デフォルトのターゲットユニットによって、起動時にロードされるリソースユニットが決まります。
ユニットがアクティブ化されると、それらはすべて並行して、またはすべて順番にアクティブ化されます。 リソースユニットのロード方法は、必要または必要な他のリソースユニットによって異なる場合があります。
systemdの依存関係：必要なものと必要なもの systemdは、systemdがサービスデーモン間の依存関係に対処する方法を制御する必要があります。
前述のように、Upstartは、構成ファイルを使用したサービスの並列ロードを保証します。 System Vでは、サービスは特定のランレベルで開始できますが、別のサービスまたはリソースが使用可能になるまで待機させることもできます。同様の方法で、systemdサービスを1つ以上のターゲットにロードするか、別のサービスまたはリソースがアクティブになるまで待機することができます。 etechjp.com
systemdでは、別のユニットを必要とするユニットは、必要なユニットがロードされてアクティブ化されるまで起動しません。 最初のユニットがアクティブなときに必要なユニットが何らかの理由で故障した場合、最初のユニットも停止します。
これにより、システムの安定性が確保されます。 したがって、特定のディレクトリが存在する必要があるサービスは、そのディレクトリへのマウントポイントがアクティブになるまで待機させることができます。 一方、別のユニットが必要なユニットは、そのような制限を課しません。 発信者がアクティブなときに目的のユニットが停止しても停止しません。 この例としては、グラフィカルターゲットモードで表示される必須ではないサービスがあります。
実用例：systemdの起動シーケンスを理解する systemdでのサービスの起動動作を理解するために、CentOS8.3ドロップレットを使用しています。 をフォローします。可能な限りウサギの軌跡をターゲットにします。 systemdの起動シーケンスは、依存関係の長いチェーンに従います。
まず、次のコマンドを実行して、デフォルトのターゲットユニットファイルを一覧表示します。 --sudo ls -l /etc/systemd/system/default.target
これは、次のような出力を示しています。
ご覧のとおり、デフォルトのターゲットは、実際には/ lib / systemd / system /の下にあるマルチユーザーターゲットファイルへのシンボリックリンクです。 したがって、システムはmulti-user.targetで起動することになっています。これは、System Vinitのランレベル3に似ています。
multi-user.target.wants 次に、次のコマンドを実行して、multi-user.targetファイルが必要とするすべてのサービスを確認します。
--sudo ls -l /etc/systemd/system/multi-user.target.wants/*.service
これにより、/ usr / lib / systemd / system /の下にある実際のユニットファイルを指すシンボリックリンクファイルのリストが表示されます。
multi-user.target以外にも、system-update.targetやbasic.targetなどのさまざまなタイプのターゲットがあります。マルチユーザーターゲットがどのターゲットに依存するかを確認するには、次のコマンドを実行します。

- sudo systemctl show --property "multi-user.target|FMT -10


出力は次のようにします。

basic.target
次のコマンドを実行して、basic.targetに必要なユニットがあるかどうかを確認できます。

- sudo systemctl show --property "basic.target|FMT -10


最適なので、basic.targetにsysinit.targetが必要です：

そしてそれはいくつかのターゲットを望んでいます：
- sudo systemctl show --property "欲しい" basic.target|FMT -10


コマンドは次のものを返します。

再帰的に行われると、sysinit.targetに他のターゲットが実行されるようにするかどうかを確認できます。

- sudo systemctl show --property "require" sysinit.target|FMT -10


何もないでしょう。ただし、sysinit.targetによって必要な他のターゲットが存在するでしょう：

- systemctl show --property "anys" sysinit.target|FMT -10

次のような出力が表示されます。
systemdユニットファイルの調査 さらに一歩進んで、sshd用のサービスユニットファイルの内部を見てみましょう。
--sudo vi /etc/systemd/system/multi-user.target.wants/sshd.service
次のようになります。
サービスユニットファイルがクリーンでわかりやすいことがわかります。 最初の重要な部分は、[Unit]セクションのAfter句です。 これは、network.targetとsshd-keygen.targetがロードされた後にsshdサービスをロードする必要があることを示しています。
[インストール]セクションには、multi-user.targetがサービスを必要としていることが示されています。 これは、multi-user.targetがsshdデーモンをロードすることを意味しますが、ロード中にsshdが失敗しても、シャットダウンしたりクラッシュしたりすることはありません。
multi-user.targetがデフォルトのターゲットであるため、sshdデーモンは起動時に起動することになっています。 [Service]セクションで、Restartパラメーターの値はon-failureです。 この設定により、sshdデーモンがクラッシュしたり、終了がクリーンでない場合に再起動できます。
この記事では、System V、Upstart、およびsystemdサービス管理デーモンについて学習しました。 起動スクリプトと構成ファイル、重要なパラメーター、起動シーケンス、およびサービスの起動動作を制御するコマンドについて説明しました。
この記事のパート2では、これらのスキルを実際の例に適用し、systemdを使用してMySQLを構成します。 完了すると、MySQLインスタンスは再起動またはクラッシュ後に自動的に再起動します。 また、サンプルアプリケーションとしてMySQLを使用しますが、NginxやApacheWebサーバーなどの任意の数のサービスを置き換えることができます。

Read More: https://etechjp.com