Bind mount must start with ${WEBAPP_STORAGE_HOME}

[t-l-k]

Using a docker-compose.yaml file, input into the Portal's Container settings blade, expressed in the syntax advocated by the "announcing" article at https://blogs.msdn.microsoft.com/appserviceteam/2018/09/24/announcing-bring-your-own-storage-to-app-service/

version: ‘3’
services:
web:
image: “mydocker/image:latest”
ports:
– “80:80”
volumes:
– <custom-id>:/var/media
redis:
image: “redis:alpine”

Results in errors in the diagnostics logs of the following nature:

2019-02-14 17:10:29.825 ERROR - Exception in multi-container config parsing: (Line: 15, Col: 9, Idx: 460) - (Line: 15, Col: 52, Idx: 503): Bind mount must start with ${WEBAPP_STORAGE_HOME}.
2019-02-14 17:10:29.825 ERROR - Start multi-container app failed

Is there an alternative convention?

I would have thought that the LHS of any bind mount volume expression would be the --mount-path of the added storage? This doesn't appear to be the case. should I expect to see the fileshare at the --mount-path, in the Kudu shell? Should I also be able to see the mount using mount in the Kudu shell?

I am aware that this Kudu shell is operating in it's own container (whatever that means!) but I can see a mount visible for /home, which contains the scaled storage share, which would appear to be the default storage convention. So it is all a bit misleading!

[t-l-k]

Okay I take it back, having re-run storage experiments several times over, the following convention does work for me:

volumes:
– <custom-id>:/var/media

I must have either been experiencing latency on the container restart, or I didn't notice that my settings possibly weren't getting saved when toggling the WEBSITES_ENABLE_APP_SERVICE_STORAGE flag. I recall a couple of times to my surprise when the logs showed the flag was still enabled when I thought I had disabled it, and vice versa.

I also now see the differences now when SSH'ing into the container and the Kudu console, Kudu has the same mount as the container when WEBSITES_ENABLE_APP_SERVICE_STORAGE is true. When my custom-id volume is mounted, I see only those custom-id mounts in the container. Kudu doesn't have those mounts. The only difference in the mount definitions (other than locations), is that my BYOS mount has a persistanthandles flag.

But this error still appears when I want to use the custom-id BYOS volume mount, and still want app service storage. Having both is useful - in theory, I could use the deployment tools of the app service, whilst segregating some storage which I don't want the deployment tooling to interfere with - Zip Deploy, for example, does comparisons in the /home/site/wwwroot folder whilst working its magic.

I don't understand why these should be mutually exclusive, but that is how it is behaving.

My experiments also revealed that you can't append a subpath to the custom-id volume mount, where as you can with the app service storage.

[sebagomez]

I had the same issue and somehow while trying to get the data to post it here, I got it to work.
So, let me show others what this custom-id means.

As @t-l-k mentioned, you need to create the WEBSITES_ENABLE_APP_SERVICE_STORAGE to true. Then create the mapping to something like the following:

Keep in mind that Mount path is NOT where your Storage will be mounted. This will be stated in the docker-compose file, in my case, as follows: - MediaVolume:/usr/local/tomcat/webapps/DockerPrototypeJavaEnvironment

[SbiCA]

@sebagomez what storage account type are you using? I've got an issue with running raven (or maybe I'm just too stupid to pick the right storage account type 🤔).

https://groups.google.com/forum/#!topic/ravendb/gimIR_UsfiQ

I've tried several options now I but somehow the db container never starts unless I leave out the mount completely 😢

[sebagomez]

I have a regular (general purpose v1) Storage Account... I took a look at your docker-compose file... remove the ${WEBAPP_STORAGE_HOME} and instead add the custom-id of your Path mapping... like I've shown in the picture above... see that in my case is called MediaVolume and that's what's in my docker-compose file, not the ${WEBAPP_STORAGE_HOME} variable as stated in many docs out there.

[SbiCA]

@sebagomez thanks , for me it works now with a V1 storage account and a file share

version: '3.4'

services:
  ravendb:
    image: ravendb/ravendb-nightly
    environment:
    - RAVEN_ARGS='--Setup.Mode=None'
    - RAVEN_Security_UnsecuredAccessAllowed='PrivateNetwork'
    - RAVEN_License_Eula_Accepted=true 
    ports:
    - "80:8080"
    volumes:
    - ravenmount:/opt/RavenDB/Server/RavenData

[kackey621]

@sebagomez Hi, I have same issue. But it is different from above. I use " ./ " . If I use it, how may I do next?

services:
  app:
    build: ./infra/php
    volumes:
      - ./backend:/work

  web:
    image: nginx:1.20-alpine
    ports:
      - 8080:80
    volumes:
      - ./backend:/work
      - ./infra/nginx/default.conf:/etc/nginx/conf.d/default.conf
    working_dir: /work

  db:
    build: ./infra/mysql
    volumes:
      - db-store:/var/lib/mysql

volumes:
  db-store: