gigazine.netdev.classmethod.jp
⇧ 不具合が続く原因が気になりますな。
⇧ 運用でカバーが大事ということですな。
ちなみに、システムの受け入れテストとかしていれば事前に発覚できた可能性は無きにしも非ずのような気がするんですが、動作確認とかはしていたんですかね？
まぁ、前々から思ってるのだけど、システムが動くのは当たり前じゃないってことは、もっと遍く周知されて欲しいところですな。
システム開発の規模にも依りけりだとは思いますが、複数人が、相当な時間をかけて構築してきたシステムにおいて、障害の原因解明に時間がかからないと思う方が不思議なんよね...
ましてや、引継ぎの連続でシステムの仕様を把握していないよう状態でシステムに関わることになったら、仕様の理解だけで相当な時間がかかるのも当然な気がするんだが...
とりあえず、無事に復旧して、原因も特定できたらナレッジとして公開して欲しいところですな。
Docker Composeの実行ユーザーを確認する術が無さそうなんだが...
Dockerの公式のドキュメントで、
⇧ rootユーザーを使わない方が良さ気とあり、Docker Composeとかもrootユーザーでコマンドを実行しない方が良いのかな、と理解したのだけど、じゃあ、肝心のdocker compose upとかを実行したユーザーとかってどうやって特定すれば良いんだろう？って疑問に思ったので調べてみたものの、これと言って情報がヒットして来ないんだが...
またもや、Docker Composeのプロジェクト名の確認方法のように破綻してるんじゃないかという気がしてくるのだが...
普通に考えて、root以外のユーザーで実行することを推奨するならば、当然、実行したユーザーを特定できる方法を用意するのがセオリーな気がするんだけども...
ChatGPTに聞いてみたところ、
1. ログファイルの確認:
『Dockerは通常、ログを/var/log/docker.logなどの場所に出力します。このログファイルを確認して、docker-compose upを実行したユーザーに関する情報を見つけることができるかもしれません。』
cat /var/log/docker.log | grep "docker-compose up"
2. プロセス情報の確認:
『docker-compose upが実行されているプロセスを確認し、そのプロセスを起動したユーザーを確認することもできます。』
ps aux | grep "docker-compose up"
『または、psコマンドに-eオプションを使用して全てのプロセスを表示し、grepで絞り込むこともできます。』
ps -e | grep "docker-compose up"
3. sudoログの確認:
『もしもdocker-compose upを実行する際にsudoを使用していた場合、sudoログを確認して該当のユーザーを特定することができます。』
cat /var/log/auth.log | grep "docker-compose up"
⇧ という提案をされたんだけど、期待通りの動作するのかは不明ですな。
何と言うか、Dockerって保守・運用向きの技術じゃないってことなんかね？
とりあえず、
dockerデーモンが指定したオプションで実行しているか、psコマンドで確認します。
⇧ docker deamonに対しては、実行ユーザーを特定する方法があるっぽいのだけど、通常のLinuxコマンドで実現してますと。
docker deamonですら、雑な対応なところを見るに、況や、他のDocker系のコマンドに対してをや、ということでしょうか...
docker compose upのプロセスを確認する方法をドキュメントに記載しておいてくれれば良い気がするんですけどね...
いろいろと、中途半端なんよね...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
