Kubernetes、Nomad、またはクラウドでホストされるサービスとしてのプラットフォーム (Paas) などのプラットフォームは、さまざまな強力な機能を提供します。ワークロードのスケーリングからシークレット管理、展開戦略に至るまで、これらのワークロード オーケストレーターは、さまざまな方法でインフラストラクチャを拡張できるように最適化されています。 しかし、通信事業者は常に最大限のスケーラビリティを得るためにコストを支払う必要があるのでしょうか?場合によっては、複雑さと抽象化によるコストがその利点を上回ることがあります。代わりに、多くのビルダーは、管理を容易にするために、非常にシンプルな展開アーキテクチャに依存するようになります。ロード バランサーの背後にある 2 つの仮想プライベート サーバーは、コンテナ ホストのフリート全体にわたるマイクロサーバーの無秩序なクラスターと比較して、管理が大幅に簡単なスタックです。これは、問題が発生したときにデバッグする可動部分が少なくなったり、メンテナンスの時期が来たときにアップグレードしたりするときに効果を発揮し始める可能性があります。 多くの最新の Linux ディストリビューションの基盤は であり、コンテナ オーケストレーターや PaaS システムに匹敵する強力な機能セットが付属しています。この記事では、最新の systemd 機能を活用して、管理に頭を悩ませることなく他の大規模システムの多くの機能を獲得し、通常の サーバーを非常に有能なアプリケーション プラットフォームに強化する方法を説明します。 systemd Linux  systemd 入門書 単一ホストで systemd  ファイルを作成するのは、管理対象プロセスを実行する理想的な方法です。ほとんどの場合、アプリケーションを変更する必要はまったくありません。systemd はさまざまな種類のサービスをサポートしており、それに応じて適応できます。 .service たとえば、単純な Web サービスの実行方法を定義する次の単純な について考えてみましょう。 .service   [Unit] Description=a simple web service [Service] ExecStart=/usr/bin/python3 -m http.server 8080  systemd サービスのデフォルトを思い出してください。ExecStart  は絶対パスである必要があり、プロセスはバックグラウンドにフォークしてはならず、場合によっては、  オプションを使用して必要な環境変数を設定する必要があります。 ExecStart= Environment=   のようなファイルに配置すると、  で制御できるサービスが作成されます。 /etc/systemd/system/webapp.service systemctl   プロセスを開始します。 systemctl start webapp   サービスが実行されているかどうか、その稼働時間、  および からの出力、プロセスの ID およびその他の情報を表示します。 systemctl status webapp stderr stdout   サービスを終了します。 systemctl stop webapp さらに、  および に出力されるすべての出力は、journald によって集約され、システム ジャーナル (  を使用) 経由でアクセスするか、  フラグを使用して特にターゲットを指定してアクセスできます。 stderr stdout journalctl --unit   journalctl --unit webapp  Journald はデフォルトでストレージをローテーションして管理するため、ジャーナルを介してログを収集することは、ログ ストレージを管理するための優れた戦略です。 この記事の残りの部分では、このようなサービスを強化するオプションを検討します。 秘密   安全に注入する機能をサポートしています。これは、安全なデータストアから取得され、実行中のワークロードに公開される値です。 API キーやパスワードなどの機密データは、意図しない公開を避けるために、環境変数や構成ファイルとは異なる処理が必要です。 Kubernetes などのコンテナ オーケストレーターは、 Secret を   ディスク上のファイルから機密値をロードし、それらを安全な方法で実行中のサービスに公開することをサポートします。シークレットをリモートで管理するホスト型プラットフォームと同様に、systemd は 環境変数などの値とは異なる方法で扱い、安全に保管します。 LoadCredential= systemd オプションは、 資格情報を シークレットを systemd サービスに挿入するには、まずシークレット値を含むファイルをファイルシステム上のパスに配置します。たとえば、API キーを ユニットに公開するには、再起動後もファイルを保持するために にファイルを作成するか、ファイルが永続的に保持されるのを避けるために ファイルを作成します。 path は任意ですが、systemd はこれらの パスをデフォルトとして扱います)。どちらの場合も、  のようなコマンドを使用して、ファイルに制限されたアクセス許可を設定する必要があります。 .service /etc/credstore/api-key /run/credstore/api-key credstore chmod 400 /etc/credstore/api-key   ファイルの セクションで、  オプションを定義し、コロン (  で区切られた 2 つの値 (資格情報の名前とそのパス) を渡します。たとえば、  ファイルを「トークン」と呼ぶには、次の systemd サービス オプションを定義します。 .service [Service] LoadCredential= : /etc/credstore/api-key   LoadCredential=token:/etc/credstore/api-key  systemd がサービスを開始すると、シークレットは 形式のパスで実行中のサービスに公開されます。  は systemd によって設定される環境変数です。アプリケーション コードは、API トークンやパスワードなどの安全な値を必要とするライブラリやコードで使用するために、この方法で定義された各シークレットを読み取る必要があります。たとえば、Python では、次のようなコードを使用してこのシークレットを読み取ることができます。 ${CREDENTIALS_DIRECTORY}/token ${CREDENTIALS_DIRECTORY}   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() その後、API トークンまたはパスワードを必要とする可能性のあるライブラリに対して、シークレットの内容を含む 変数を使用できます。 secret 再起動 のようなオーケストレーターのもう 1 つの機能は、クラッシュしたワークロードを自動的に 機能です。未処理のアプリケーション エラーによるものであっても、その他の原因によるものであっても、障害が発生したアプリケーションの再起動は非常に便利な機能であり、多くの場合、アプリケーションの回復力を設計する際の防御の最前線となります。 Nomad 再起動する    systemd  systemd が実行中のプロセスを自動的に再起動するかどうかを制御します。このオプションにはいくつかの値が考えられますが、基本的なサービスの場合は、  設定がほとんどのユースケースを満たすのに適しています。 Restart= オプションは、 on-failure 自動再起動を構成するときに考慮すべきもう 1 つの設定は   です。これは、サービスを再起動するまで systemd が待機する時間を指定します。通常、この値は、タイトなループで失敗したサービスが再起動され、プロセスの再起動に CPU 時間が過剰に消費される可能性を避けるためにカスタマイズする必要があります。通常は、  など、待ち時間が なりすぎない短い値で十分です。 RestartSec RestartSec= オプション 5s 長く 期間または時間ベースの値を受け入れる などのオプションは、ニーズに応じて や などのさまざまな形式を解析できます。詳細については を参照してください。 RestartSec= 5min 10s 1hour 、systemd.time のマニュアル 最後に、他の 2 つのオプションは、systemd が最終的に諦める前に、失敗したユニットの再起動をどの程度積極的に試みるかを決定します。  および 指定された期間内にユニットの起動を許可する頻度を制御します。たとえば、次のような設定です。 StartLimitIntervalSec= StartLimitBurst=   StartLimitBurst=5 StartLimitIntervalSec=10 ユニットは 10 秒間で最大 5 回まで起動を試行できます。構成されたサービスが 10 秒以内に 6 回目の起動を試行すると、systemd はユニットの再起動を停止し、代わりにユニットを としてマークします。 failed これらの設定をすべて組み合わせると、  ユニットに次のオプションを含めて自動再起動を構成できます。 .service   [Unit] StartLimitBurst=5 StartLimitIntervalSec=10 [Service] Restart=on-failure RestartSec=1 この構成では、サービスが失敗した場合 (つまり、ゼロ以外の終了コードなどで予期せず終了した場合) に 1 秒待機した後に再起動し、途中で 5 回を超えてサービスの起動を試行した場合はサービスの再起動を停止します。 10秒間。 サービスの強化 コンテナ内で実行する主な利点の 1 つは、セキュリティ サンドボックスです。アプリケーション プロセスを基盤となるオペレーティング システムからセグメント化することで、サービスに存在する可能性のある脆弱性が本格的な侵害に発展することがはるかに困難になります。 Docker のようなランタイムは、cgroup と他のセキュリティ プリミティブを組み合わせてこれを実現します。 いくつかの systemd オプションを有効にして、基盤となるホストを予測できないワークロード動作から保護するのに役立つ同様の制限を適用できます。     や などの機密システム パスへの書き込みアクセスを制限できます。 、使用可能なすべてのオプションが列挙されていますが、一般に、これらのファイルシステム パスを保護するには、このオプションを に設定するのが妥当なデフォルトです。 ProtectSystem= /boot /usr このオプションのドキュメントには full   読み取り専用設定で  、   、および ディレクトリを に設定するか、  に設定すると、サービスのファイル システムに空のディレクトリとしてマウントできます。アプリケーションがこれらのディレクトリにアクセスする必要がある場合を除き、これを に設定すると、これらのディレクトリへの不正アクセスに対してシステムを安全に強化できます。 ProtectHome= /home /root /run/user read-only true true   構成されたサービスに対して個別の および を維持するため、このサービスおよび他のプロセスの一時ファイルは非公開のままになります。プロセスが一時ファイルを介して情報を共有するやむを得ない理由がない限り、これは有効にすると便利なオプションです。 PrivateTmp= /tmp /var/tmp   実行されたプロセスが特権を昇格できないようにすることで、サービスを強化する 。他の強化オプションを使用できるかどうかわからない場合は、通常、これを有効にしても問題が最も少ないオプションの 1 つです。 NoNewPrivileges= もう 1 つの安全で簡単な方法です   サービスなどの実行可能なワークロードに適用されるさまざまなオプションを調べるのに役立つリソースです。 systemd.exec のマニュアル ページは、 参考文献 広範であり、独自のアプリケーションを実行するために利用できるすべてのオプションについて学ぶのに役立ちます。 Web サーバーなどの永続サービスを実行している場合でも、cron ジョブを置き換えるための定期的な ユニットを実行している場合でも、systemd ドキュメントが役立つガイダンスを提供します。 systemd プロジェクトのマニュアル ページは .timer

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

2022 - HackerNoon Contributor of the Year - Freelancing

2022 - HackerNoon Contributor of the Year - Linux

Nominated for 2022 - HackerNoon Contributor of the Year - Freelancing

Nominated for 2022 - HackerNoon Contributor of the Year - Linux

Freelance Writer & Consultant

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Make resilience your competitive advantage

Systemd を使用した Micro-DevOps: 通常の Linux サーバーをスーパーチャージする

About Author

コメント

ラベル

この記事は

Related Stories

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

フロキのヴァルハラがインドのスリランカツアーのアソシエイトスポンサーに加わる

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

フロキのヴァルハラがインドのスリランカツアーのアソシエイトスポンサーに加わる

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps