ボリュームマッピングによるAzure Container Serviceの使用

Question

私は、Azureコンテナサービスを使用して、Azureにドッキングされたアプリケーションを配備しました。 MongoDBを使ったNodeJS/Expressアプリです。すべてうまくいっていますが、今私がやりたいことは、自分の内部プロジェクトフォルダとVM上のフォルダの間のボリュームマッピングを設定することです。コンテナの起動時に

これは、通常のドッキングウィンドウでは正常に動作します、私は単純に次のコマンドを実行します。

docker run -d --net=784849494 -p 5555:80 -v /www/uploads:/var/www/myapp/uploads myapp 

は基本的に、私は私のVMでWWWでアップロードフォルダを作成し、それは私のプロジェクトフォルダのアップロードにマッピングされます。

これは、私は、これは動作しません

user@myazureapp -p 2200 -L 22375:12.0.0.1:2375 -i mykey 

によってアクセスされた私のためにスピンアップAzureの私のVMにフォルダを作成するとき、私は、およそ困惑している部分です。コンテナサービスと統合された別のVMでフォルダを作成する必要があると思います。しかし、私はそれがどこにあり、それを見つけることができないのか分からない。

Answer 1

ショートバージョン：あなたはVMフォルダに使用されないようにする

、あなたのデータのためのネットワークドライブのいくつかの種類が必要です。おそらく、MongoDBサービスを使用するか、MongoDBファイルを、データアクセスを保証しているストレージアカウントに保管してください。

あなたは上のフォルダを作成しているマシンがマスターである：後者を行うには、例えば、（https://azure.microsoft.com/en-us/blog/persistent-docker-volumes-with-azure-file-storage/を参照）

長いバージョンをドッカーためAzureのファイルボリュームのドライバを使用する場合があります。コンテナが配備されている場所ではなく、Docker Swarmマスターが配置されている場所です。これはあなたがそれを見ることができない理由です。エージェント上にフォルダを作成する必要があります。

ただし、Swarmがクラスタ内にコンテナを展開する場所がわからないため、フォルダが配置されているVMに配置される保証はありません。幸運なことに、最初に展開されても正しいVM上に置かれても、Dockerを再起動する必要がある場合、同じVM上で再起動されるという保証はありません。

すべてのエージェントにフォルダを作成できますが、コンテナを再起動した場合、同じVM上で再起動が保証されないため、コンテナは同じデータにアクセスできなくなります。あなたが同じVMに着陸したとしても、あなたのVMが再起動された場合、おそらくAzureによって修復されたサービスであるため、まだVMディスクがそこに残っているという保証はないので、問題が残る可能性があります。 VMディスクは一時的なもので、私はあなたがこのデータを消したくないと思っています。

多くの場合、クラスタ内でサービスを実行するのではなく、データにサービスを使用することをお勧めします。 https://docs.microsoft.com/en-us/azure/documentdb/documentdb-protocol-mongodb。つまり、誰かがバックアップ、可用性、スケーラビリティ、パフォーマンスなどを担当しているということです。これはサービスの支払いを意味しますが、自分のサービスを管理するコストを考慮すると、コストが安くなる場合があります。 ACSクラスター。

実際にMongoDBインスタンスをホストしたい場合は、MongoDBコンテナがどこに配備されているかにかかわらず常にネットワークストレージの場所にアクセスできるようにするVolumeドライバの使用を検討することがあります。たとえば、DockerのAzureファイルボリュームドライバを使用できます（https://azure.microsoft.com/en-us/blog/persistent-docker-volumes-with-azure-file-storage/を参照）。