に参加して、VS Code の AI 支援開発について学びましょう。

コンテナーに非ルートユーザーを追加する

多くのDockerイメージはデフォルトユーザーとしてrootを使用しますが、代わりに非rootユーザーを使用したい場合もあります。そうする場合、ローカルファイルシステム (バインド) マウントにはいくつかの注意点があることを知っておく必要があります。具体的には

  • Mac用Docker Desktop: コンテナー内では、マウントされたファイル/フォルダーは、指定したコンテナーユーザーが所有しているかのように動作します。ローカルでは、すべてのファイルシステム操作はローカルユーザーのパーミッションを使用します。

  • Windows用Docker Desktop: コンテナー内では、マウントされたファイル/フォルダーはrootが所有しているかのように表示されますが、指定したユーザーは引き続きそれらを読み書きでき、すべてのファイルは実行可能になります。ローカルでは、すべてのファイルシステム操作はローカルユーザーのパーミッションを使用します。これは、Windows形式のファイルパーミッションをLinuxに直接マッピングする方法が根本的に存在しないためです。

  • Linux上のDocker CE/EE: コンテナー内では、マウントされたファイル/フォルダーは、コンテナー外とまったく同じパーミッションを持ちます。これには、所有者ユーザーID (UID) とグループID (GID) も含まれます。このため、コンテナーユーザーは、同じUIDを持つか、同じGIDを持つグループに属している必要があります。ユーザー/グループの実際の名前は関係ありません。通常、マシン上の最初のユーザーはUID 1000を取得するため、ほとんどのコンテナーはこの問題を回避するためにこれをユーザーのIDとして使用します。

VS Codeのユーザーを指定する

使用しているイメージまたはDockerfileがすでにオプションの非rootユーザーを提供している場合 (nodeイメージのように) でも、デフォルトでrootを使用する場合は、devcontainer.jsonでremoteUserプロパティを指定することで、Visual Studio Code (サーバー) およびすべてのサブプロセス (ターミナル、タスク、デバッグ) がそれを使用するように選択できます。

"remoteUser": "user-name-goes-here"

Linuxでは、devcontainer.jsonでDockerfile、イメージ、またはDocker Composeを参照している場合、この環境に存在するバインドマウントのパーミッションの問題を回避するために、コンテナーユーザーのUID/GIDをローカルユーザーと一致するように自動的に更新します ("updateRemoteUserUID": falseを設定しない限り)。

この設定はVS Codeと関連するサブプロセスのみに影響するため、VS Codeを再起動 (またはウィンドウをリロード) する必要があります。ただし、UID/GIDの更新はコンテナーが作成されたときにのみ適用され、変更には再構築が必要です。

デフォルトのコンテナーユーザーを指定する

場合によっては、VS Codeだけでなく、コンテナー内のすべてのプロセスを別のユーザーとして実行する必要がある場合があります (たとえば、起動要件のため)。これを行う方法は、Docker Composeを使用しているかどうかに応じて若干異なります。

  • Dockerfileとイメージ: 同じファイルにcontainerUserプロパティを追加します。

    "containerUser": "user-name-goes-here"

    Linuxでは、remoteUserと同様に、この環境に存在するバインドマウントのパーミッションの問題を回避するために、コンテナーユーザーのUID/GIDをローカルユーザーと一致するように自動的に更新します ("updateRemoteUserUID": falseを設定しない限り)。

  • Docker Compose: 適切なサービスに対して、docker-compose.ymlを次の内容で更新 (または拡張) します。

    user: user-name-or-UID-goes-here

非rootユーザーを作成する

Dev Containers拡張機能から提供されるイメージまたはDockerfileには、UID/GIDが1000の非rootユーザー (通常はvscodeまたはnodeと呼ばれます) が含まれていますが、多くのベースイメージやDockerfileには含まれていません。幸いなことに、非rootユーザーをコンテナーに追加するDockerfileを更新または作成できます。

本番環境でも、アプリケーションを非rootユーザーとして実行することをお勧めします (より安全であるため)。そのため、既存のDockerfileを再利用する場合でも、これは良いアイデアです。たとえば、Debian/Ubuntuコンテナー用のこのスニペットは、user-name-goes-hereという名前のユーザーを作成し、sudoを使用する権限を与え、デフォルトとして設定します。

ARG USERNAME=user-name-goes-here
ARG USER_UID=1000
ARG USER_GID=$USER_UID

# Create the user
RUN groupadd --gid $USER_GID $USERNAME \
    && useradd --uid $USER_UID --gid $USER_GID -m $USERNAME \
    #
    # [Optional] Add sudo support. Omit if you don't need to install software after connecting.
    && apt-get update \
    && apt-get install -y sudo \
    && echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME \
    && chmod 0440 /etc/sudoers.d/$USERNAME

# ********************************************************
# * Anything else you want to do like clean up goes here *
# ********************************************************

# [Optional] Set the default user. Omit if you want to keep the default as root.
USER $USERNAME

ヒント: GIDまたはUIDがすでに存在するというビルドエラーが発生した場合、選択したイメージにはすでに直接利用できる非rootユーザーが存在する可能性があります。

いずれの場合も、コンテナーをすでにビルドして接続している場合は、コマンドパレット (F1) からDev Containers: Rebuild Containerを実行して変更を適用します。それ以外の場合は、Dev Containers: Open Folder in Container...を実行してコンテナーに接続します。

既存のコンテナーユーザーのUID/GIDを変更する

remoteUserプロパティは、Dockerfileまたはイメージを使用する場合にLinuxでUID/GIDを適切に自動更新しようとしますが、代わりにこのスニペットをDockerfileで使用してユーザーのUID/GIDを手動で変更できます。ARGの値を適切に更新してください。

ARG USERNAME=user-name-goes-here
ARG USER_UID=1000
ARG USER_GID=$USER_UID

RUN groupmod --gid $USER_GID $USERNAME \
    && usermod --uid $USER_UID --gid $USER_GID $USERNAME \
    && chown -R $USER_UID:$USER_GID /home/$USERNAME

Alpine Linuxでは、最初にshadowパッケージをインストールする必要があることに注意してください。

RUN apk add --no-cache shadow
10/09/2025
© . This site is unofficial and not affiliated with Microsoft.