Open t-l-k opened 5 years ago
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.
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
@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 😢
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.
@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
@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:
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/Results in errors in the diagnostics logs of the following nature:
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 usingmount
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!