UPDATE 2016-03-02：Docker 1.9.0以降、Dockerはデータのみのコンテナーを置き換えるボリュームに名前を付けました。以下の回答は、私のリンクされたブログ投稿と同様に、Docker内のデータをどのように考えるかという点で価値がありますが、名前付きボリュームを使用して、データコンテナーではなく、以下で説明するパターンを実装することを検討してください。
これを解決する標準的な方法は、データのみのコンテナを使用することだと思います。このアプローチでは、ボリュームデータへのすべてのアクセスは、データコンテナーを使用-volumes-fromするコンテナーを介して行われるため、ホストのuid / gidは重要ではありません。
たとえば、ドキュメントに記載されている使用例の1つは、データボリュームのバックアップです。これを行うには、別のコンテナを使用してバックアップを行います。また、ボリュームをマウントするためにtarも使用-volumes-fromします。したがって、grokの重要なポイントは、適切な権限でホスト上のデータにアクセスする方法を考えるのではなく、別のコンテナを介して、必要なこと（バックアップ、参照など）を行う方法を考えることです。 。コンテナー自体は一貫したuid / gidを使用する必要がありますが、ホスト上の何にもマップする必要がないため、移植性が維持されます。
これは私にとっても比較的新しいものですが、特定のユースケースがある場合は、遠慮なくコメントしてください。答えをさらに詳しく説明します。
更新：コメント内の特定の使用例では、some/graphiteグラファイトを実行するためのイメージsome/graphitedataと、データコンテナーとしてのイメージがある場合があります。したがって、ポートなどを無視するとDockerfile、イメージsome/graphitedataは次のようになります。
FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
&& useradd -r -g graphite graphite
RUN mkdir -p /data/graphite \
&& chown -R graphite:graphite /data/graphite
VOLUME /data/graphite
USER graphite
CMD ["echo", "Data container for graphite"]
データコンテナをビルドして作成します。
docker build -t some/graphitedata Dockerfile
docker run --name graphitedata some/graphitedata
some/graphiteDockerfileも同じUID / GIDのを取得する必要があり、そのためには、次のようになります。
FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
&& useradd -r -g graphite graphite
# ... graphite installation ...
VOLUME /data/graphite
USER graphite
CMD ["/bin/graphite"]
そしてそれは次のように実行されます：
docker run --volumes-from=graphitedata some/graphite
OK、これでグラファイトコンテナーと関連するデータのみのコンテナーに正しいユーザー/グループが提供されました（some/graphiteデータコンテナーのコンテナーを再利用することもできます。実行時にentrypoing / cmdをオーバーライドしますが、別の画像IMOはより明確です）。
ここで、データフォルダ内の何かを編集したいとします。そのため、ボリュームのホストへのバインドマウントとそこでの編集ではなく、そのジョブを実行する新しいコンテナーを作成します。それを呼ぶことができますsome/graphitetools。some/graphite画像のように、適切なユーザー/グループも作成します。
FROM debian:jessie
# add our user and group first to make sure their IDs get assigned consistently, regardless of other deps added later
RUN groupadd -r graphite \
&& useradd -r -g graphite graphite
VOLUME /data/graphite
USER graphite
CMD ["/bin/bash"]
Dockerfile から継承するsome/graphiteかsome/graphitedata、Dockerfile内でこのDRY を作成するか、または新しいイメージを作成する代わりに、既存のイメージの1つを再利用します（必要に応じてentrypoint / cmdをオーバーライドします）。
今、あなたは単に実行します：
docker run -ti --rm --volumes-from=graphitedata some/graphitetools
そしてvi /data/graphite/whatever.txt。これは、すべてのコンテナに同じグラファイトユーザーがuid / gidが一致しているため、完全に機能します。
/data/graphiteホストからマウントすることはないため、ホストのuid / gidがgraphiteおよびgraphitetoolsコンテナー内で定義されたuid / gidにどのようにマップされるかは問題ではありません。これらのコンテナーは任意のホストにデプロイできるようになり、引き続き完全に機能します。
これについてのすてきなことは、graphitetoolsあらゆる種類の便利なユーティリティとスクリプトがあり、移植可能な方法で展開できることです。
更新2：この回答を書いた後、私はこのアプローチについてより完全なブログ投稿を書くことにしました。お役に立てば幸いです。
更新3：私はこの回答を修正し、詳細を追加しました。以前は、所有権と権限に関するいくつかの誤った前提が含まれていました。所有権は通常、ボリュームの作成時に割り当てられます。これは、ボリュームが作成されるときであるためです。こちらのブログをご覧ください。ただし、これは要件ではありません。データコンテナを「参照/ハンドル」として使用し、エントリポイントのchownを介して別のコンテナに所有権/権限を設定できます。このエントリはgosuで終了し、正しいユーザーとしてコマンドを実行します。誰かがこのアプローチに興味を持っている場合はコメントしてください。このアプローチを使用したサンプルへのリンクを提供できます。