概要: Docker デバッグ イメージの問題を思い出してください

1. 背景

同僚が QKE へのアプリケーションのデプロイを手伝ってほしいと頼んで、ミラー アドレスと構成ファイルをくれました。

構成ファイルをコンテナーにマップする必要があるため、構成マップを作成すると、アプリケーションは構成マップ内のキーに対応するコンテンツをコンテナー内の構成ファイルにマップします。

しかし、問題が発生しました。

コンテナーが頻繁かつ迅速に再起動され、ログが表示されません。

ログがないとエラーの原因が分からないので非常に面倒なので、ログを取得する方法を見つけることが最優先です。

以前はコンテナ内のログを出力していました。コンテナを再起動するとログは消えましたが、少なくともコンテナはしばらく起動していたので、コンテナに入って確認できました。しかし、今回はアプリケーションの起動が速すぎてハングしました。コンテナに入る時間がありませんでした。

私は何も方法を思いつきませんでした。コンテナ ログをポッドにマッピングすることを考えていました。その後、同僚の zy が docker でデバッグする方法を提供してくれました: use /bin/ bash

/bin/bash は、コマンドを実行できるコマンド ライン環境を提供し、コンテナーがハングしないという利点があります。

以下は、Zhang Yu の操作のスクリーンショットです。この操作は、 docker run -it docker-registry.xxx.virtual/weeb/thor:v0.1 / bin/bashコマンドによって最終的に解決されました。

2、docker がコンテナに入る

以前考えていたのですが、docker のデバッグ イメージ、起動後にイメージがハングするので、デバッグ時にもハングするのではないか?

まだdockerコマンドに慣れていないみたいです。

まず元の Docker を見てください。

まずコマンドを実行しましょう: docker run -it docker-registry.xxx.virtual/weeb/thor:v0.1 

設定ファイルが存在しないことが判明し、以下のエラーが報告されます。 

何をすべきか?

もう一度実行しましょう: docker run -it docker-registry.xxx.virtual/weeb/thor:v0.1 ls /data

上記のコマンドとの違いは、このコマンドの後に「ls /data」が続くことです。効果を確認してください。

以下の ls /data が実行されたことがわかります。これがポイントです。イメージの背後にコマンドがある場合、docker はイメージで定義された CMD を実行しなくなります

以下はイメージで定義されている CMD です。これは、コンテナー起動後の最初のステップが CMD を実行すること、つまりサービスを開始し、開始する構成ファイル /data/thor/config.yaml を指定することを意味します。

そして、このサービスと構成ファイルに問題があるため、起動に失敗し、コンテナがハングします。

要約すると、コンテナを終了するには 2 つの方法があります。

1. コマンドの実行が終了します。

  • 上記の ls /data を実行するとコンテナが実行されるため、コンテナが終了します。

2. CMD の実行に問題があります。

コンテナをハングさせたくない場合は、/bin/bash を実行して、/bin/bash 環境を作成します。この環境のコンテナはハングしません。この環境に入り、CMD を手動で実行できます。このとき、CMD は手動で実行します。コンテナ内で子プロセスを起動するだけです。親プロセスは /bin/bash です。子プロセスがハングしても、親プロセス /bin/bash がハングしない限り、問題ありません。

効果を見てみましょう。発見がもたらされました。

 CMD で指定されたコマンド /usr/bin/thor -config.file /data/thor/config.yaml を実行します。   

 設定ファイルが存在しないことが判明したため、ケース内のコンテンツを作成して使用します

最終的に、ログを見つけてエラーの原因を確認しましたが、実際には、設定ファイルの listen を変更するためでした。 

おすすめ

転載: blog.csdn.net/w2009211777/article/details/131124239