数十人が共同で使用するサーバーがあります。
それぞれがコンテナでプロジェクトを配信しているのですが、
サーバーの再起動などの問題が発生したときに、これらのコンテナに管理者がどう対応すべきか悩んでいます。
普段のDockerコンテナ起動コマンドを一つひとつ提出してもらって、それを実行してあげるべきなのか、
あるいはDocker Composeで構成して、プロジェクトごとにフォルダへ入って compose up を実行してあげるべきなのかなど、
管理者として複数のコンテナをどのように管理しているのか、アドバイスをお願いします。
9件のコメント
ご回答いただいた皆さま、ありがとうございます。今年の目標は Kubernetes の導入に定めることになりそうです。
コンテナをデーモン化して、OS 起動時にコンテナも実行されるようにするのが最も簡単です。
EL（Enterprise Linux、RHEL 系を総称）系であれば、コンテナを systemd サービスとして登録できます。Quadlet というそうです。
質問だけを見ると、
depend on、restart always、あるいはunless stopedで解決できそうにも見えますが、質問には含まれていない難しい状況があるのだと思います。とはいえ、数十人規模なら結局は Kubernetes に行く必要がありそうです。質問文のとおりにそのまま AI に聞いても、答えは見つけられると思います。
上の内容があれば、もっと話しやすくなると思います。
単純におっしゃっていることを基準に回答するなら……
コンテナ実行コマンドがなぜ必要なのか分かりません。Composeファイルを作ってもらって、それを基準にすべて同じコマンド（Composeコマンド）で起動できるように構成するのが一番良いです。
:) 管理者なのですから、そう作ってほしいと言えば他の方がやってくれるはずなので、押し切ってしまいましょう :)
私は、k8sは1人で管理する環境では負担が大きいソリューションだと思っているので、あまりおすすめしません。
インフラはいつでもシンプルに構成するのが一番良いと考えています.
オンプレミスのサーバー4台です。
一人で対応しています。
セキュリティ審査を通過して会社にDockerが導入されてからまだ4か月目で、k8s は概念だけ知っています。Docker向けのHARBOR導入もまもなく私が実施しなければならず、Harborが導入された後はDocker Hubは遮断される予定です。おそらくDocker Hubを開けておけるのは私だけで、依頼が入ったら私がDocker Hubからイメージを取得して社内の
Harborに上げる形式になると思います。
Composeコマンドで押し切ること、プロジェクトごとにフォルダへ移動して一つひとつ compose up を実行することは非現実的だと考えてやっておらず、その代わりにDockerコマンドを絶対パスで実行してほしいと依頼していましたが、最近になってそれが間違ったアプローチではないかという考えを拭えません。
Docker の再起動オプションを付ければいいのではないですか？
こういう場合は Kubernetes を使って、ユーザーごとに context を割り当てるのがよいです。
ユーザーごとにその context のみ使えるように権限を制限することもできます。
Kubernetesを使用します。
私も tujuc さんと似た考えですが、熟練者なしで一人で k8s を導入し、事故なく安定的に運用するのは、かなりリスクがあると思います。
ただ、4台のサーバーを数十人が共用している状況とのことなので判断が難しいですが、
関係する人数を基準にするよりも、サーバープログラムの数が多すぎて複雑な状況であれば、k8s の学習を検討してみるのは良いと思います。
もし私が投稿者さんと同じ状況なら、以下の段階ごとに環境を改善していったと思います。