web-dev-qa-db-ja.com

ECSでのDockerボリュームの権限

既存のアプリケーションを、EC2の裸のインスタンスでの実行から、ECSを使用したコンテナー化されたセットアップに移行しています。コンテナー間でデータを共有する必要がある状況が2つあります。 1つは静的ファイルとメディアファイルを保存するEFS共有で、もう1つはログディレクトリです。サイドカーコンテナーでCloudwatch Logsエージェントを使用してログをCloudwatchにプッシュできます。

ウェブサーバーはこれらの両方の場所にデータを書き込むことができる必要がありますが、これまでのところそれを実現することはできません。ログディレクトリはローカルボリュームであり、root:root。 これら の指示に従ってセットアップしたEFS共有は、1000:xfs（ユーザー名なし）。どちらの場合も、私のWebユーザー（www-data）これらの場所に書き込みます。

ECSに、特定の所有者またはグループ、あるいはその両方を使用してコンテナー内にボリュームをマウントするように指示するにはどうすればよいですか？

amazon-web-servicesdockeramazon-ecs
1
Joseph Montanaro

編集：これは私が作るよりもはるかに簡単であることがわかりました。

ECSでボリュームを作成しようとすると、ボリュームの名前と「ソースパス」の入力を求められます。説明のために押すと、ソースパスが「このボリュームのコンテナーに提示されるホストコンテナーインスタンス上のパスです。省略した場合、Dockerデーモンがホストパスを割り当てる」と指定します。

すべて非常にうまく機能しますが、違いは、「ディレクトリの指定」と「Dockerがディレクトリを選択する」だけではないことがわかりました。これがdocker volumeとbind mountの違いです。実際、コンテナをdocker inspectすると、ECSに指定したボリュームが表示されます「ソースパス」は"Type": "bind"を取得しますが、指定しないボリュームは"Type": "volume"を取得します。

バインドマウントとボリュームの主な違いの1つは、バインドマウントは（私の知る限り）常にroot:root所有権で作成されますが、ターゲットディレクトリが既に存在する場合、ボリュームは所有権を継承することです。したがって、私の問題に対する信じられないほど苛立たしいほど単純な解決策は、適切な所有権でディレクトリが事前に存在することを確認してから、ECSでボリュームを作成するなしソースパスを指定することです。

ちなみに、同じボリュームを共有する複数のコンテナーがアプリケーションに含まれている場合、ボリュームは、コンテナーが起動して実行されている既存のディレクトリ構造firstからそのアクセス許可を取得します。したがって、a）ボリュームがマウントされるすべてのコンテナーにディレクトリが存在するか、またはb）問題のディレクトリを含むコンテナーが常に最初に起動されることを確認する必要があります。

誰かに役立つ場合に備えて、元の解決策を以下に残します。

元のソリューション1：tmpfsマウント

Dockerボリュームは、Linuxシステムのmountコマンドと同様に機能するdriver_optsパラメーターを受け入れます。したがって、1つのオプションはtmpfsマウントを使用することです。これにより、結果のファイルの所有者とグループを設定するオプションが可能になります。 ECSでは、これは次のようにして達成できます。

{
  "name": "myvolume",
  "dockerVolumeConfiguration": {
    "scope": "task",
    "driver": "local",
    "driverOpts": {
      "type": "tmpfs",
      "device": "tmpfs",
      "o": "uid=1000,gid=1000"
    }
  }
}

これにより、コンテナー内にユーザーとグループ1000が所有するボリュームが作成されます。

この方法の欠点は、tmpfsであるため、ホストメモリにファイルを保存することです。ユースケースに応じて、これは受け入れられる場合と受け入れられない場合があります-非常に大きくなる可能性のあるログファイルを保存する必要があるため、これは理想的ではありません。

（ここでのtypeの下のdeviceおよびdriverOptsパラメータは、 のtypeおよびdeviceパラメータと同等です。 Linux mountコマンド 。これを理解するには、かなりの時間とフラストレーションが必要でした。）

元のソリューション2：NFSでUIDを一致させる

NFSは単にファイルの所有者/グループを数値IDとして格納します。グループがxfsと表示されたのは、再配置の一環として、UbuntuからAlpineに移動しているためです。どちらの場合も、グループにwww-dataを使用したいのですが、www-dataは、Ubuntuではユーザー/グループ33、Alpineでは82です。 Alpineでは、33が「Xフォントサーバー」ユーザーなので、xfsです。

Cloudwatchに送信されるのを待っている間にログをダンプできる、非永続的な共有「スクラッチワーク」ディレクトリの完全なソリューションはまだありません。 tmpfsソリューションを使用して、非常に積極的なパラメーターのセットでlogrotateを実行するだけで、ログファイルが数MBを超えるメモリを消費することはありません。

0
Joseph Montanaro