デフォルトのコマンドがクラッシュするため、停止したDockerコンテナーを別のコマンドで開始したいと思います。つまり、コンテナーを開始してから「docker exec」を使用できません。

基本的にシェルを起動して、コンテナーの内容を検査できるようにしたいと考えています。

幸い、私は-itオプションでコンテナを作成しました！

停止したコンテナーIDを見つける

docker ps -a

停止したコンテナをコミットします。

このコマンドは、変更されたコンテナーの状態を新しいイメージに保存します user/test_image

docker commit $CONTAINER_ID user/test_image

別のエントリポイントで開始/実行します。

docker run -ti --entrypoint=sh user/test_image

エントリーポイント引数の説明：https ://docs.docker.com/engine/reference/run/#/entrypoint-default-command-to-execute-at-runtime

注意：

上記の手順は、停止したコンテナを同じファイルシステム状態で起動するだけです。これは迅速な調査に最適です。ただし、環境変数、ネットワーク構成、接続されているボリューム、その他のスタッフは継承されないため、これらの引数をすべて明示的に指定する必要があります。

停止したコンテナーを開始する手順は、ここから借用されています：（最後のコメント）https://github.com/docker/docker/issues/18078

このファイルを編集します（停止したコンテナに対応）：

vi /var/lib/docker/containers/923...4f6/config.json

「パス」パラメーターを変更して、新しいコマンドをポイントします（例：/ bin / bash）。コマンドに引数を渡すために "Args"パラメータを設定することもできます。

dockerサービスを再起動します（これにより、実行中のすべてのコンテナーが停止することに注意してください）。

service docker restart

コンテナーをリストし、コマンドが変更されていることを確認します。

docker ps -a

コンテナを起動してアタッチします。これでシェルに入るはずです！

docker start -ai mad_brattain

Docker 1.7.1を使用してFedora 22で作業しました。

注：シェルがインタラクティブでない場合（たとえば、-itオプションで元のコンテナーを作成しなかった場合）、代わりにコマンドを「/ bin / sleep 600」または「/ bin / tail -f / dev / null」に変更できます。シェルを取得する別の方法として「docker exec -it CONTID / bin / bash」を実行するのに十分な時間を与えるため。

注2：dockerの新しいバージョンにはconfig.v2.jsonがあり、EntrypointまたはCmdのいずれかを変更する必要があります（user60561に感謝）。

Entrypointスクリプトの上部にチェックを追加します

Dockerはこれを新機能として実際に実装する必要がありますが、成功または失敗後に終了するエントリポイントがある状況での別の回避策オプションがあります。これにより、デバッグが困難になる可能性があります。

エントリーポイントスクリプトがない場合は、コンテナに必要なコマンドを実行するスクリプトを作成します。次に、このファイルの先頭で、次の行を追加しますentrypoint.sh。

# Run once, hold otherwise
if [ -f "already_ran" ]; then
    echo "Already ran the Entrypoint once. Holding indefinitely for debugging."
    cat
fi
touch already_ran

# Do your main things down here

catが接続を保持していることを確認するには、TTYを提供する必要がある場合があります。私はエントリポイントスクリプトでコンテナを実行しています。

docker run -t --entrypoint entrypoint.sh image_name

これにより、スクリプトが1回実行され、（コンテナーの仮想ファイルシステムで）既に実行されたことを示すファイルが作成されます。次に、コンテナを再起動してデバッグを実行できます。

docker start container_name

コンテナーを再起動すると、already_ranファイルが見つかり、Entrypointスクリプトが停止しますcat（これにより、永遠に入力されない入力を待ちますが、コンテナーは存続します）。その後、デバッグbashセッションを実行できます。

docker exec -i container_name bash

コンテナーの実行中にデバッグする必要がある場合already_ranは、entrypoint.shスクリプトを削除して手動で実行し、再実行することもできます。

私の問題：

• 私はコンテナを始めました docker run <IMAGE_NAME>
• そして、このコンテナにいくつかのファイルを追加しました
• 次に、コンテナーを閉じて、上記と同じコマンドでコンテナーを再起動しました。
• しかし、新しいファイルを確認したところ、ファイルがありませんでした
• 実行するdocker ps -aと、2つのコンテナが表示されました。
• つまりdocker run <IMAGE_NAME>、コマンドを実行するたびに、新しいイメージが作成されていました

解決策： 最初に作成したのと同じコンテナで作業するには、次の手順に従います。

• docker ps コンテナのコンテナを取得する
• docker container start <CONTAINER_ID> 既存のコンテナを開始する
• その後、離れたところから続行できます。例えばdocker exec -it <CONTAINER_ID> /bin/bash
• 次に、それから新しいイメージを作成することを決定できます

私は@Dmitriusanの回答を取り、それをエイリアスにしました：

エイリアスdocker-run-prev-container = 'prev_container_id = "$（docker ps -aq | head -n1）" && docker commit "$ prev_container_id" "prev_container / $ prev_container_id" && docker run -it --entrypoint = bash "prev_container / $ prev_container_id "'

これを~/.bashrcエイリアスファイルに追加docker-run-prev-containerすると、前のコンテナのシェルにドロップする気の利いた新しいエイリアスが作成されます。

失敗したdocker buildのデバッグに役立ちます。

これは正確にあなたが求めているものではありませんが、必要なのがdocker exportファイルを検査することだけであれば、停止したコンテナで使用できます。

mkdir $TARGET_DIR
docker export $CONTAINER_ID | tar -x -C $TARGET_DIR

コンテナーが終了するかどうかは指定されていません。コードがクラッシュし、コンテナーで何が行われているのかを確認する必要があるだけです。存在しない場合は、別の解決策が考えられます。

コンテナIDを取得する docker ps

docker exec -it 665b4a1e17b6 /bin/sh

entrypointが問題のある何かに設定されている場合、Dmitriusanの回答で提案されているように、それをオーバーライドすることもできます。また、を使用して、実行中の任意のコンテナに接続できることにも注意してくださいdocker attach。非常に多くのソリューションは異なるソリューションです。画像にコミットする必要があるとは思いません。必要ないようです。

Docker execのドキュメント-https ://docs.docker.com/engine/reference/commandline/exec/

Dockerアタッチのドキュメント-https ://docs.docker.com/engine/reference/commandline/attach/

私はこれらの答えの両方に実際には同意しません。コンテナーの内容を確認するだけの場合は、このコマンドを実行してシェルを取得できます。エントリーポイントを変更したり、設定を変更したりする必要はありません。

docker run -it <image_name> bash

docker container start <CONTAINER_ID>