AWS EC2インスタンスにSSHで接続してAPIを起動しています。 APIは引き続き実行され、リクエストを受け入れたいです。
それでは、tmuxがこれを行う良い方法でしょうか?それとももっと良い方法がありますか?私の考えでは、tmuxとscreenが長い作業に適しているということです。 APIを無期限に実行するのに適しているかどうかはわかりません。
答え1
tmux
screen
何らかの理由でターゲットシステムへの接続が中断されても、1つ以上のシェルセッションをアクティブにしたり、1つの接続を介して複数のシェルセッションを多重化するために使用されます(複数のssh
端末を開くことができるものと似ていると思います)。ウィンドウはありますが、GUIインターフェイスはありません)。
私はあなたを信じていますできるAPIサービスを実行するためのtmux
ものですが、AWS EC2インスタンスを使用している場合systemd
(多くの最新のLinuxディストリビューションのように)「正しい」アプローチは、*.service
サービスを開始および停止するために必要なコマンドとその要件を説明するファイルを作成することです。 (つまり、サービスを正常に開始するには、他のサービスを実行する必要があります)
その後、サービスファイルを/etc/systemd/system/
ディレクトリに配置して実行し、systemctl daemon-reload
サービスsystemctl start your-API.service
を使用して操作できますsystemctl stop your-API.service
。標準システムサービスと同じです。なぜならsystemd
それについて〜するシステムサービスです。
これにより、APIのリソース制限を簡単に指定できます。たとえば、APIが誤用された場合に発生する可能性があるダメージを制限できます。 APIサービスが自動的に開始されるようにするにはどうすればよいですか?systemctl enable your-API.service
これで終わりました。
.service
APIサービスがクラッシュしたり、それ自体で終了した場合は、APIサービスが自動的に再起動されるようにファイルに割り当てることもできます。 APIサービスを定期的に呼び出す場合、sd_notify(3)
サービスが中断されたように見える場合は自動的に再起動する"WATCHDOG=1"
こともできます。systemd
いくつかのセキュリティ上の利点もあります。 systemdは管理する各サービスに対して「制御グループ」を作成し、その制御グループはそのサービスによって生成されたすべての子プロセスによって継承されます。したがって、サービスが「クレイジー」状態になって10,000のサブプロセスを生成しても(おそらくインターネット上の誰かがサービスを乱用しようとしているため)、単にsystemd stop your-API.service
(またはsystemd kill your-API.service
サービスを停止したい場合)今サービスの終了を制御するために気にする必要はありません)すべてのプロセスをクリーンアップするのに十分です。正しいプロセスを手動で見つけ、そのプロセスの式を終了することを考える必要はありませんpkill
。pgrep
必要に応じてsystemdもサービスを提供できますchroot
(特定のディレクトリとそのサブディレクトリのみを表示するように制限)。または、専用のユーザーアカウントでサービスを実行している場合(可能な場合は常に良い方法です)、そのプロセス(および作成されたすべてのサブプロセス)をブロックして、必要に応じて完全なsysadmin権限を取得することもできますroot
。サービスファイルに設定するには、NoNewPrivileges=true
何らかの悪用によって達成できます。*.service
詳細と例については、以下を参照してください。この質問はここにあります。 Unix&Linux.SE、またはシステムの既存の文書を調べて、*.service
それを参照して個々のキーワードの意味を確認しman systemd.service
てください。man systemd.exec