ウェブサイト検索

実行中のDockerコンテナの設定を変更する方法

Dockerコンテナは、一度実行が開始されると通常は不変であると見なされます。ただし、コンテナの名前やハードウェアリソースの制限など、一部の設定パラメータを動的に更新することができます。

このガイドでは、組み込みのDockerコマンドを使用して、実行中のコンテナの選択したパラメーターを変更する方法を説明します。また、変更すべきでないことや、変更が必要だと考える場合に使用できる回避策についても見ていきます。

コンテナの名前を変更する

最も簡単な修正は、作成されたコンテナの名前を変更することです。名前は、

--name

フラグはdocker run用です。名前が指定されていない場合、Dockerデーモンはランダムな名前を割り当てます。コンテナの名前を使ってDocker CLIコマンドで参照することができます。適切で記憶に残りやすい名前を選ぶことで、docker psを実行してコンテナの自動割り当て名やIDを見つけるのを避けることができます。

docker rename コマンドは、作成後にコンテナの名前を変更するために使用されます。これは、ターゲットコンテナのIDまたは現在の名前と、新しく割り当てる名前の2つの引数を取ります:

docker rename <target ID or name> <new name>
docker rename old_name new_name

再起動ポリシーの変更

再起動ポリシーは、ホストが再起動した後やDockerデーモンが起動した際に、コンテナが自動的に起動するかどうかを決定します。利用可能な4つのポリシーにより、コンテナを強制的に起動させることや、停止したままにさせること、またはコンテナの前回の終了コードや実行状態に基づいて条件付きで起動することができます。

Dockerは、再起動ポリシーをその場で変更することをサポートしています。これは、ホストまたはDockerデーモンを再起動する予定がある場合に便利で、特定のイベント後に特定のコンテナを停止したままにしたり、自動的に起動させたりしたい時に役立ちます。

docker update --restart unless-stopped demo_container

上記の例では、demo_containerの再起動ポリシーをunless-stoppedに変更します。このポリシーは、コンテナがデーモンによって起動し、デーモンが最後に終了する前に手動で停止されていない限り、起動するようにします。

ハードウェアリソース制限の変更

docker updateコマンドは、コンテナに適用されるリソース制限を変更するためにも使用できます。 コンテナのIDまたは名前を1つ以上渡し、これらのコンテナに設定する制限を定義するフラグのリストを指定する必要があります。

フラグは、docker runがサポートするすべてのリソース制限に対して利用可能です。以下は、使用できるオプションの簡潔なリストです:

  • --blkio-weight - コンテナのブロックIOの相対的な重みを変更します。
  • --cpus - コンテナに利用可能なCPUの数を設定します。
  • --cpu-shares - CPUのシェアの相対的な重みを設定します。
  • --memory - コンテナのメモリ制限を変更します（例：1024M）。
  • --memory-swap - コンテナがディスクにスワップできるメモリの量を設定します。具体的な制限を設定するには、1024M のようなサイズを使用するか、無制限のスワップを使用するには -1 を指定します。
  • --kernel-memory - コンテナのカーネルメモリ制限を変更します。カーネルメモリが不足したコンテナは、ホストマシン上の他のワークロードに悪影響を与える可能性があります。
  • --pids-limit - コンテナ内で許可されるプロセスIDの最大数を設定し、開始できるプロセスの数を制限します。

以下は、docker updateを使用して、2つのコンテナのメモリ制限とCPU数を変更する例です。

docker update --cpus 4 --memory 1024M first_container second_container

利用可能なフラグは、--kernel-memoryを除いて、実行中のLinuxコンテナで使用できます。カーネルメモリ制限を変更するには、まずdocker stopでコンテナを停止する必要があります。

これらのフラグは現在Windowsベースのコンテナではサポートされていないことに注意してください。ただし、Windowsホストマシン上で実行されているLinuxコンテナでは機能します。

これらのコマンドを使用しないべき時はいつですか？

docker updateおよびdocker renameコマンドは、docker runを通じて手動で作成したコンテナに対して使用する必要があります。他のツール（例えばdocker-compose）から派生したコンテナに対して使用することには注意が必要です。

コンテナの名前を変更すると、ソースツールによって検出されなくなり、スタックの他のコンポーネントが壊れる可能性があります。さらに、docker-compose.ymlファイルでリソース制限を宣言的に定義している場合、docker-compose upコマンドを再度実行すると、コンテナに元の制限が再適用されます。

したがって、使用している場合は既存のコンテナ管理ソリューションを守るべきです。Composeの場合、これはあなたの docker-compose.yml ファイル内のコンテナ名とリソース制限を変更し、次に docker-compose up -d を実行して変更を自動的に適用することを意味します。これにより、意図せず孤立したコンテナが発生したり、意図しない副作用が生じることはありません。

他のプロパティ（画像/ポート/ボリューム）はどうなっていますか？

ハードウェアの制限、リソースポリシー、およびコンテナ名は、Docker CLIが変更を許可する唯一の設定パラメータです。実行中のコンテナのイメージを変更することはできず、ポートバインディングやボリュームなどの他のオプションを簡単に変更することもできません。

これらの値が古くなった場合は、別のコンテナを作成する必要があります。現在のインスタンスを削除し、docker runを使用して新しいイメージと修正された設定で置き換えを開始してください。

コンテナはステートレスでエフェメラルであることを意図しているため、いつでもそれらを置き換えることができるはずです。永続的なコンテナデータを保存するためにボリュームを使用してください。このメカニズムにより、元の docker run コマンドに渡された -v フラグを繰り返すことで、ステートフルなファイルを新しいコンテナに再接続できます。

docker run -v config-volume:/usr/lib/config --name demo example-image:v1
docker rm demo
Existing data in /usr/lib/config retained
docker run -v config-volume:/usr/lib/config --name demo2 example-image:v2

危険ゾーン：他のコンテナプロパティの変更

可能な限りコンテナを置き換えることを目指すべきですが、Dockerの設定ファイルを直接編集することで既存のコンテナのプロパティを変更することも可能です。この方法を使用する際は注意が必要です：これは完全にサポートされておらず、誤って変更するとコンテナが壊れてしまう可能性があります。

このオプションは既存のコンテナを任意に編集する方法を提供しますが、コンテナが実行中のときには機能しません。docker stop my-container コマンドを使用して編集したいコンテナを停止し、その後に変更を続けてください。

コンテナ設定ファイルはホスト上で次のパスにあります:

/var/lib/docker/containers/<container id>/config.v2.json

コンテナの完全なIDを知る必要があります。これは docker ps で表示される短縮版ではありません。この情報を取得するには docker inspect コマンドを使用できます。

docker inspect <short id or name> | jq | grep Id

コンテナの config.v2.json にアクセスしたら、テキストエディタで開いて必要な変更を加えることができます。このJSONファイルには、docker run を実行したときに作成されたコンテナの設定が保存されています。ポートバインディング、環境変数、ボリューム、コンテナのエントリーポイントやコマンドなどのプロパティを変更するために内容を修正できます。

ポートバインディングを追加するには、ファイル内の PortBindings キーを見つけて、オブジェクトに新しいアイテムを挿入します:

{
    "PortBindings": {
        "80/tcp": {
            "HostIp": "",
            "HostPort": "8080"
        }
    }
}

ここで、コンテナのポート80はホストのポート8080にバインドされています。環境変数を追加するのも同様に簡単です - Envキーを見つけて、配列に新しい項目を挿入してください:

{
    "Env": [
        "FOO=bar",
        "CUSTOM_VARIABLE=example"
    ]
}

編集が完了したら、Dockerサービスとコンテナを再起動してください:

sudo service docker restart
docker start my-container

コンテナは現在、更新された設定で実行されます。

結論

Dockerコンテナは、その設定が古くなったときに置き換える一時的なユニットとして意図されています。この意図にもかかわらず、既存のコンテナを変更する必要があるシナリオもあります。Dockerは、一般的なユースケース、つまり名前の変更やリアルタイムのリソース制限の調整を、docker updateのような組み込みCLIコマンドを通じて処理します。

他のプロパティを変更したいときは、最初のアクションとして常にコンテナーを置き換えることを試みてください。これにより、問題が発生するリスクが最小限に抑えられ、Dockerの不変性のモデルに沿ったものになります。既存のコンテナーを編集する必要がある場合は、上記に示したようにDockerの内部構成ファイルを手動で変更することができます。

最後に、Docker Composeのような他のエコシステムツールによって管理されているコンテナは、それらのメカニズムを使用して変更する必要があることを覚えておいてください。そうしないと、変更をツールが認識していない場合、コンテナが予期せず孤立したり上書きされたりすることがあります。

関連記事: