systemdユニットファイルジェネレーター

ビジュアルフォームでsystemdサービスユニットファイルを構築。サービスタイプ、リスタートポリシー、環境変数を選択し、すぐに使える.serviceファイルをダウンロード。

このツールについて

systemdユニットファイルジェネレーターは、INIスタイルの設定を一から書く代わりに、 直感的なビジュアルフォームを通じてsystemdサービスユニットファイルを作成する 無料のブラウザベースツールです。サービスタイプ(simple、forking、oneshot、 notify、dbus、idle)を選択し、リスタートポリシーを設定し、ユーザー/グループ 権限を設定し、環境変数を定義すると、systemdを実行するあらゆるLinuxシステムに デプロイ可能な完全な.serviceファイルが生成されます。

ジェネレーターはユニットファイルの3つの主要セクションをすべてカバーしています: メタデータと依存関係の**[Unit](Description、After、Requires、Wants)、 実行パラメータの[Service]**(Type、ExecStart、ExecStop、Restart、 RestartSec、User、Group、WorkingDirectory、Environment、EnvironmentFile、 PIDFile、StandardOutput、LimitNOFILE)、アクティベーションターゲットの [Install](WantedBy、RequiredBy)。Node.jsアプリケーション、Python Gunicornサーバー、Dockerコンテナ、Nginxリバースプロキシなどの一般的な シナリオのビルトインテンプレートにより、確実なベースラインから開始して カスタマイズできます。

Dockerコンテナを管理する場合は、 Docker Runコマンドビルダーdocker run コマンドの構築に同様のビジュアル体験を提供します。Nginx設定ファイルの生成には Nginx設定ジェネレーターをご覧ください。 定期的なタスクをスケジュールする必要がある場合は、 Cron式ビルダーがcronスケジュールの作成に役立ちます。

すべての処理はブラウザ内で完全に実行されます。ユニットファイルの内容、 サーバーパス、ユーザー名、環境変数がサーバーに送信されることはありません。 本番サービス設定や機密のデプロイ詳細でも安全に使用できます。

使い方

  1. オプションで上部のテンプレートを選択し、一般的なサービスパターン(Node.js、Python、Docker、Nginxなど)でフォームを事前入力します。
  2. **[Unit]**セクションを入力:Descriptionを入力し、After、Requires、Wantsフィールドで依存関係を設定します。
  3. **[Service]**セクションを設定:Type(simple、forking、oneshotなど)を選択し、ExecStartコマンドを入力し、User/Group、WorkingDirectoryを設定し、環境変数を追加します。
  4. RestartポリシーとRestartSec遅延を設定して、自動リスタート動作を制御します。
  5. **[Install]**セクションを設定:WantedBy(通常multi-user.target)を設定して、起動時にサービスを有効にします。
  6. 右側の出力パネルで生成されたユニットファイルを確認します。ファイルはフォーマット済みですぐに使用できます。
  7. CopyをクリックするかCtrl+Shift+Cを押してクリップボードにコピーするか、Downloadをクリックして.serviceファイルとして保存します。

人気のsystemdユニットファイル例

すべてのsystemdユニット例を見る →

よくある質問

systemdユニットファイルとは何ですか?

systemdユニットファイルは、systemd(Linuxのinitシステム)にサービス、ソケット、タイマー、その他のリソースの管理方法を指示する設定ファイルです。サービスユニットファイル(.serviceで終わる)は、プロセスの起動、停止、再起動方法、実行ユーザー、アクティベーションのタイミングを定義します。

simpleとforkingのサービスタイプの違いは何ですか?

'simple'サービスタイプは、ExecStartで起動されるプロセスがメインサービスプロセスであり、フォアグラウンドに留まることを意味します。'forking'タイプは、プロセスが子プロセスをforkし、親が終了することを意味します。systemdは親が終了した時点でサービスが起動したと見なします。forkingは従来のUnixデーモンで使用されます。ほとんどの最新アプリケーションは'simple'を使用すべきです。

どのリスタートポリシーを使用すべきですか?

ほとんどのサービスでは'on-failure'が良いデフォルトです:非ゼロステータスで終了した場合やシグナルで終了された場合にのみサービスが再起動されます。Webサーバーなど継続的に実行する必要がある重要なサービスには'always'を使用します。1回だけ実行するoneshotスクリプトには'no'を使用します。'on-abnormal'ポリシーはシグナル/タイムアウト時に再起動しますが、正常終了時には再起動しません。

生成されたユニットファイルはどこに保存しますか?

/etc/systemd/system/に.service拡張子でファイルを保存します(例:/etc/systemd/system/myapp.service)。次に'sudo systemctl daemon-reload'で設定を再読み込みし、'sudo systemctl enable --now myapp'でサービスを起動し、起動時に有効にします。

ユニットファイルで環境変数をどう使いますか?

Environment="KEY=VALUE"ディレクティブ(変数ごとに1つ)でインラインに設定するか、EnvironmentFile=/path/to/envでファイルから読み込みます。環境ファイルにはKEY=VALUEペアを1行に1つ含めます。機密値の場合はEnvironmentFileの使用を推奨します。

データは安全ですか?

はい。すべてのユニットファイル生成はJavaScriptを使用してブラウザ内で完全に実行されます。ファイルパス、ユーザー名、環境変数、設定などのデータがサーバーに送信されることはありません。ツール使用中にブラウザの開発者ツールのネットワークタブで確認できます。

このツールでタイマーユニットを作成できますか?

このツールは.serviceユニットファイルの生成に特化しています。ただし、生成されたサービスファイルを手動で作成した.timerユニットと組み合わせて使用し、定期実行をスケジュールできます。タイマーでトリガーされるサービスにはTypeを'oneshot'に設定し、OnCalendarまたはOnBootSecディレクティブを持つ対応する.timerファイルを作成します。

関連ツール