Utilisation du service de conteneur Azure avec le mappage de volume

Question

J'ai déployé une application dockerized sur azure à l'aide du service de conteneur Azure. C'est une application NodeJS/Express utilisant MongoDB. Tout fonctionne bien, mais maintenant ce que je veux faire est de mettre en place un mappage de volume entre l'un de mes dossiers de projet internes et un dossier sur la machine virtuelle.

Cela fonctionne très bien dans docker régulière, je lance simplement la commande suivante lors du démarrage du conteneur:

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

Fondamentalement, je fais un dossier Uploads www dans ma VM et des cartes pour mes téléchargements de dossiers de projet.

C'est la partie que je suis confus au sujet, quand je crée le dossier dans ma machine virtuelle d'azur filé pour moi qui est accessible par

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

cela ne fonctionne pas. Je suppose que le dossier doit être créé dans une autre machine virtuelle intégrée au service de conteneur. Mais je ne suis pas sûr de l'endroit et je n'arrive pas à le trouver.

Answer 1

Version courte:

Vous ne voulez pas être utiliser sur les dossiers VM, vous avez besoin d'une sorte de lecteur réseau pour vos données. Peut-être utiliser un service MongoDB ou stocker vos fichiers MongoDB dans un compte de stockage où vous avez des garanties d'accès aux données. Pour ce faire, ce dernier vous pouvez, par exemple, utiliser un pilote de volume des fichiers Azure pour Docker (voir https://azure.microsoft.com/en-us/blog/persistent-docker-volumes-with-azure-file-storage/)

version plus longue:

La machine que vous créez votre dossier est le maître. Ce n'est pas là que vos conteneurs sont déployés, c'est là que se trouve le maître Docker Swarm. C'est pourquoi vous ne pouvez pas le voir. Vous devez créer le dossier sur les agents. Cependant, vous ne savez pas où Swarm va déployer votre conteneur dans le cluster et il n'y a donc aucune garantie qu'il sera placé sur une VM où se trouve votre dossier. Même si vous avez de la chance et que vous le déployez pour la première fois sur la bonne machine virtuelle, il n'y a aucune garantie qu'il sera redémarré sur la même machine virtuelle si le Docker devait redémarrer.

Vous pouvez créer un dossier sur chaque agent, mais dans le cas d'un redémarrage de conteneur, il ne vous sera pas garanti de redémarrer sur la même machine virtuelle et votre conteneur n'aura donc pas accès aux mêmes données. Même si vous avez atterri sur la même machine virtuelle, vous pouvez toujours avoir des problèmes car si votre machine virtuelle est redémarrée, peut-être pour être traitée par Azure, il n'y a aucune garantie que les disques de la machine virtuelle seront toujours là. Les disques VM sont éphémères et je suppose que vous ne voulez pas que ces données disparaissent.

Dans la plupart des cas, la meilleure option consiste à utiliser un service pour vos données plutôt que de l'exécuter dans votre cluster, par ex. https://docs.microsoft.com/en-us/azure/documentdb/documentdb-protocol-mongodb. Cela signifie que quelqu'un d'autre est responsable de la sauvegarde, de la disponibilité, de l'évolutivité, de la performance, etc. Cela signifie que vous payez pour le service, mais lorsque vous prenez en compte les coûts de gestion de votre propre service, Cluster ACS. Si vous voulez vraiment héberger votre propre instance MongoDB, vous pouvez envisager d'utiliser un pilote de volume qui garantit que votre conteneur MongoDB a toujours accès à un emplacement de stockage en réseau, quel que soit l'endroit où il est déployé. Par exemple, vous pouvez utiliser le pilote de volume Azure Files pour Docker (voir https://azure.microsoft.com/en-us/blog/persistent-docker-volumes-with-azure-file-storage/).