Running applications in Docker is quick and easy, with only one major gotcha: Windows vs Unix. (Unix in this sense means Linux or MacOS) On Windows 10, even with the latest Docker Desktop, there is a fundamental difference between named and unnamed volumes, in that it is in several cases impossible to create a named volume pointing at a custom location rather than one in Docker's own filesystem. This has to do with the exact version of Windows, the Windows Subsystem for Linux (WSL), and Docker Desktop you are using. Also volumes mapped from the commandline with the "-v" or "--volume" parameter may sometimes not work. This is (hopefully) a temporary problem due to the work being done to move Docker from Microsoft's Hyper-V solution to one based on WSL, and the integration of the docker CLI into WSL, where the mapping gets confused about where the directory actually lives: in the (virtual) WSL filesystem or an NTFS filesystem.
If you use the Docker CLI from Windows, e.g. using the (admittedly old-school) CMD app, you can use "-v %cd%\data:/data" to map a volume using the "data" subdirectory in the current directory and drive, and have it show up as "/data" in the container. However, if you want to use "docker volume create" to create a named volume, you have no good way to specify a Windows path, and the official documentation states that there are no options for the "local" driver at all on Windows. Experimenting you may find that, yes, actually some options do seem to produce an effect, but at least in my experiments they tended to cause errors as soon as a container tries to use the volume. The same driver under Linux does provide options for such a mapping, but these same options on Windows will not work reliably, and trying to cheat by running from WSL will get even stranger errors. For "docker-compose" this actually means that locally mounted volumes will not work at all, as it tries to translate the volumes sections in the "docker-compose.yml" file into separately defined volumes.
Another way to cheat would be to have this repo checked out under WSL2, then map "\\wsl$\Ubuntu-18.04" as a drive, and try to run the CMD script on that drive. This will actually not show any errors and Axon Server appears to be happy, but you will not see the controlDB and Event Store files in your local directories. Additionally, when you query the "/v1/public/me" endpoint, you'll see the properties file was not used. しょうがない! (Pronounciation: Shōganai, usually translated as "It cannot be helped!")
For this reason I will try to provide two versions of the scripts: one for Windows using "CMD", and one for Unix using the familiar "bash(1)" scripts. Please make sure to only run the "CMD" scripts on a "real" windows drive, and that this drive is configured for sharing in the Docker Desktop settings. If you want to create a long-running setup, I strongly suggest you use Linux or MacOS.