5分でシス​​テム化

当社はCentOSベースのWebサーバーを管理しています。 多くの場合、クライアントはpython、ruby、またはjavaベースのWebアプリケーションを使用します。 このようなアプリケーションの自動起動には、起動スクリプトを作成するための既製のテンプレートがあります。 しかし、進歩はまだ止まっておらず、2番目のCentOS 7リリースはすでにリリースされており、「ドットゼロリリースを実稼働にしない」という古い伝統に従って、CentOS 7.1(1503)ベースのサーバーをお客様に提供し始めています。



CentOS7は、その親であるRHEL7と同様に、SysVおよびLSB初期化スクリプトと互換性のあるLinux用のシステムおよびサービスマネージャーであるsystemdを使用します。 systemdは、積極的な並列化機能などを提供します。



画像



多くの機能、柔軟な設定、およびメガバイトのドキュメントを備えた巨大なモンスター...



しかし、昨日、タスクが高速で高速で、何らかのサービスを自動開始する場合はどうでしょうか?

ドキュメントから最低限必要な情報を絞り込んで、簡単な開始停止スクリプトを作成しましょう。



Systemdは、その構成で説明されているサービスを開始します。

構成は多くのファイルで構成され、ファッショナブルにユニットと呼ばれます。



これらのユニットはすべて、次の3つのディレクトリに配置されています。



/ usr / lib / systemd / system / -インストールされたRPMパッケージのユニット-すべての種類のnginx、apache、mysqlなど

/実行/ systemd / system / -ランタイムで作成されたユニット-また、おそらく正しいこと

/ etc / systemd / system / -システム管理者が作成したユニット-ここにユニットを配置します。



ユニットは、Microsoft Windows .iniファイルに類似した形式のテキストファイルです。



[角括弧内のセクション名]

variable_name = value




単純なユニットを作成するには、[ユニット]、[サービス]、[インストール]の3つのセクションを記述する必要があります



ユニットセクションでは、このユニットについて説明します。

変数名は非常にわかりやすいものです。



ユニットの説明:

説明= MyUnit



以下は、サービスの読み込み順序に影響する変数のブロックです。



サービスまたはサービスのグループ(たとえば、network.target)の後にユニットを実行します。

後= syslog.target

後= network.target

後= nginx.service

後= mysql.service


サービスを開始するには、実行中のmysqlサービスが必要です。

必要= mysql.service



サービスを開始するには、実行中のredisサービスが望ましい:

Wants = redis.service



その結果、Wants変数は純粋に記述的です。

サービスがRequiresにあるがAfterにない場合、必要なサービスを正常にロードした後ではなく、必要なサービスと並行してサービスが起動されます



[サービス]セクションで、サービスを開始するコマンドとユーザーを指定します。



サービスの種類:

タイプ=シンプル

(デフォルト):systemdは、サービスがすぐに開始されると想定します。 プロセスは分岐しないはずです。 このサービスの開始時に他のサービスがキューに入れられている場合は、このタイプを使用しないでください。



タイプ=分岐

systemdは、サービスが一度開始され、プロセスが親プロセスの完了で分岐すると想定しています。 このタイプは、古典的なデーモンを実行するために使用されます。



systemdがメインプロセスを追跡できるように、PIDFile =も定義する必要があります。

PIDFile = / work / www / myunit / shared / tmp / pids / service.pid



作業ディレクトリ。起動コマンドを起動する前に現在のディレクトリになります。

WorkingDirectory = / work / www / myunit / current



サービスを開始するユーザーとグループ:

ユーザー= myunit

グループ= myunit




環境変数:

環境= RACK_ENV =本番



メモリ不足とOOMメカニズムの操作によるサービスの強制終了の禁止:

-1000の完全禁止(sshdには1つ)、-100の場合は確率が低くなります。

OOMScoreAdjust = -100



サービスチームの開始/停止およびリロード



ExecStart = / usr / local / bin / bundle exec service -C /work/www/myunit/shared/config/service.rb --daemon

ExecStop = / usr / local / bin / bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop

ExecReload = / usr / local / bin / bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart



ここには微妙な点があります-systemdはコマンドが特定の実行可能ファイルを指していると主張します。 フルパスを指定する必要があります。



秒単位のタイムアウト、システムが開始/停止コマンドで動作するまで待機する時間。

TimeoutSec = 300





systemdに、サービスが突然機能しなくなった場合にサービスを自動的に再起動するように依頼します。

監視は、PIDファイルからのプロセスの存在によって実行されます

再起動=常に





[インストール]セクションで、サービスを開始する実行レベルを説明します。



起動レベル:

WantedBy = multi-user.target



multi-user.targetまたはrunlevel3.targetは、通常のランレベル= 3「グラフィックなしのマルチユーザーモード」に対応します。 ユーザーは通常、複数のコンソールを使用して、またはネットワーク経由でログインします。



したがって、最も単純な起動スクリプトが用意されており、systemdの単位でもあります。

myunit.service



[Unit] Description=MyUnit After=syslog.target After=network.target After=nginx.service After=mysql.service Requires=mysql.service Wants=redis.service [Service] Type=forking PIDFile=/work/www/myunit/shared/tmp/pids/service.pid WorkingDirectory=/work/www/myunit/current User=myunit Group=myunit Environment=RACK_ENV=production OOMScoreAdjust=-1000 ExecStart=/usr/local/bin/bundle exec service -C /work/www/myunit/shared/config/service.rb --daemon ExecStop=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop ExecReload=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart TimeoutSec=300 [Install] WantedBy=multi-user.target
      
      





このファイルをディレクトリ/ etc / systemd / system /に配置します



ステータスsystemctl status myunitを確認します



 myunit.service - MyUnit Loaded: loaded (/etc/systemd/system/myunit.service; disabled) Active: inactive (dead)
      
      





無効になっている-許可する

systemctl enable myunit

systemctl -l status myunit



ユニットにエラーがない場合、出力は次のようになります。



 myunit.service - MyUnit Loaded: loaded (/etc/systemd/system/myunit.service; enabled) Active: inactive (dead)
      
      







サービスを開始します

systemctl start myunit



美しいステータスを見てみましょう:

systemctl -l status myunit



エラーがある場合、ステータスの出力を読み取り、修正します。ユニットで修正した後、systemdデーモンをオーバーロードすることを忘れないでください



systemctl daemon-reload



さて、systemdでのトライアルダイビングの後、独立した水泳を開始できます。

急に質問がある場合は、ask @ centos-admin.ruにご連絡ください。



All Articles