ホストのユーザーと同じ所有者を持つためにドッカーコンテナにファイルを生成する方法

Question

私はgitリポジトリでいくつかの開発作業を行うためにドッキング用のコンテナを使用しています。

私が使用するコンテナは、プロジェクトごとに作成されているため、各コントリビュータは物事を完了させるためにドッカーCLIしか必要としません。

悪い面がrootとして実行の容器で、このようにして生成されたファイルは、コンテナが停止したら、rootが所有し、それが悪いされている。..

そこにISNので、私は終了する前に、容器内の所有者を変更することはできません。/etc/passwdファイルの中に必要なユーザを入れないでください。

私はドッカーイメージをコンパイルする前にコンテナにユーザーを作成しますが、コンテナは（すべての開発チームにとって）普遍的ではありません。

これに関するベストプラクティスは何ですか？

Answer 1

解決策は、以前のイメージ（devtoolsで事前インストールされていますが、ユーザーは作成されずにルートが作成されます）に基づいてリポジトリに新しいdockerfileを作成することです。作業を開始する前に、チーム内の各開発者が新しいプロジェクト+開発者の特定のための独自の基本イメージを構築するためにdockerfileを使用する必要があり、その後

FROM <ABSTRACT_FORMER_IMAGE> 
ARG username=developer 
RUN useradd -r -u 1001 -g $username $username 
USER $username 

：そのようdockerfileで

、以下のような何かを書きますコンテナにユーザ名を渡します。

$ docker build --build-arg username=$USER Dockerfile 

いくつかの優れた方法がありますか？

Answer 2

このリンクを読んでdocker privilegesを完全に理解することをお勧めします。また、あなたにとっては、--userコマンドを使用してドッカーを実行することができます。

Answer 3

イメージにユーザーを追加し、ルートとしてコンテナを起動し、エントリポイントを使用して、コンテナ内のuid/gidを開発者のボリュームマウントと一致させることができます。その後、コンテナユーザーに切り替えてアプリを実行します。

これを実現するために、私は次の行が含まエントリポイントのシェルスクリプトを使用しました：、そのスクリプトで

OLD_UID=`getent passwd "${opt_u}" | cut -f3 -d:` 
    NEW_UID=`ls -nd "$1" | cut -f3 -d' '` 
    if [ "$OLD_UID" != "$NEW_UID" ]; then 
    usermod -u "$NEW_UID" "$opt_u" 
    if [ -n "$opt_r" ]; then 
     find/-mount -uid "$OLD_UID" -exec chown "$opt_u" {} \; 
    fi 
    fi 
    OLD_GID=`getent group "${opt_g}" | cut -f3 -d:` 
    NEW_GID=`ls -nd "$1" | cut -f4 -d' '` 
    if [ "$OLD_GID" != "$NEW_GID" ]; then 
    groupmod -g "$NEW_GID" "$opt_g" 
    if [ -n "$opt_r" ]; then 
     find/-mount -gid "$OLD_GID" -exec chgrp "$opt_g" {} \; 
    fi 
    fi 

を$1は、ボリュームがマウントパスをされ、opt_uは、コンテナ内のユーザー名で、opt_gがありますグループ名、およびopt_rは、コンテナ内のファイルシステムを再帰的に調整するフラグです。私のエントリポイントの非常に終わり

、私はキックオフ：ユーザー$RUN_ASに切り替わり、幹部がそのユーザとしてエントリポイントに渡されたコマンドだ、とPID 1としてGosuをするために使用され

exec gosu "${RUN_AS}" "$@" 

suがpid 1として実行されないようにしてください。

これまでのJenkinsと同様の例を、ドッカーソケットのGIDと一致するコンテナ内のアプリケーションとして公開しました。https://github.com/bmitch3020/jenkins-docker

これは、画像を任意の開発者システムに移植可能にする重要な面を持ち、同じコマンドで実行することができます。パーミッションがファイルシステム上でどのようなものであっても、外部からコンテナにマップされるのは、コンテナ内のコマンドを実行しているユーザのuid/gidになります。 docker runコマンドの開発者システムでローカルuid/gidを検索する必要はなく、独自のuid/gidエントリを持つ各開発者ワークステーションでイメージを構築する必要はありません。この実装の唯一の欠点は、ユーザ/グループとファイルシステムの所有権を変更するためのアクセス権としてrootとしてエントリポイントを実行する必要があるため、docker execがrootとしてコンテナに入ることです。