Dockerize MCGalaxy

[dakriy]

Built out basic dockerfile and docker entrypoint.

[UnknownShadow200]

Why is both mono and dotnet-sdk here?

I may be interpreting this wrongly, but seems like you're trying to make symlinks for various directories from MCGalaxy's folder to folders in data directory. Unfortunately I don't think this approach will work reliably . (e.g. blockprops directory is missing from that list, and plugins can also make their own folders - GoodlyEffects makes an effects directory for example)

[dakriy]

I am using Docker multistage builds, so the final image only has mono and the application, and I use the same image for both stages in the build so that users only have to download one image. the dotnet-sdk is needed for msbuild which is only used during the build stage and is discarded immediately on the second FROM statement. I followed the documentation here for installing the dotnet sdk which contains msbuild.

Yes, I am making symlinks for various directories into the data directory. I will add the blockprops directory as a volume. The reason for this is to centralize all directories that are needed for persistence into one directory that can easily be volumed instead of having to specify 10-15 different volumes. I purposely did not volume in the plugins directory as I think plugins should be baked into the container as well, in which case one could extend this image, or volume it in if they wanted. Docker is not restricted to voluming files and directories specified in the Dockerfile. ANY file or directory in the container can be mounted in from the host. Specifying volumes in the Dockerfile is more a courtesy. As for plugins creating their own directories is none of our concern as the user of the image would be the only one to know what they were using, so when they spin up the image with a docker run they just specify another -v option and volume it in themselves. Doesn't have to be in the /data directory. I consolidated all of the base MCGalaxy persistent data stores to the /data directory for ease of achieving persistence for image users, as now only one volume must be created for all base MCGalaxy persistent data files and directories. Now, I could remove the symlinking, but then users would have to specify individual volumes for each and every directory and file, which, when there are so many, it can be easy to miss one as I did just now.

For reference on docker volumes:
https://docs.docker.com/storage/volumes/

[UnknownShadow200]

Are you sure dotnet-sdk is necessary? I tried docker run -it mono:latest bash (from Mono homepage), but that included msbuild already and I could compile MCGalaxy fine with it

[dakriy]

You are right, the base image can build just fine with msbuild. Good catch!

[rdebath]

Rather than using a nest of symlinks I've tried to patch the source to allow it to follow Mono's "best practices" so that the current directory and the executable directory are distinct.
See: http://www.mono-project.com/docs/getting-started/application-deployment

I think it would be reasonable to enable this configuration with a command line option like ClassiCube's -d option.

The turning off of the various ID-ten-T checks which make sure the user has downloaded all the DLLs should be replaced with versions that check in the same location the MCGalaxy_.dll is located.

# Patch server to allow it to follow best practices.
#   http://www.mono-project.com/docs/getting-started/application-deployment
[ -f CLI/CLIProgram.cs ] &&
    sed -i '/\<CurrentDirectory\>.*=/s/^/\/\/PATCH/' \
        CLI/CLIProgram.cs
[ -f CLI/CLIProgram.cs ] &&
    sed -i '/if.*File.Exists.*MCGalaxy/s/^/if(false) {\/\/PATCH/' \
        CLI/CLIProgram.cs
[ -f CLI/Program.cs ] &&
    sed -i '/\<CurrentDirectory\>.*=/s/^/\/\/PATCH/' \
        CLI/Program.cs
sed -i '/CheckFile.*dll"/s/^/\/\/PATCH/' \
    ${SERVER}/Server/Server.cs
sed -i '/QueueOnce.InitTasks.UpdateStaffList/s/^/\/\/PATCH/' \
    ${SERVER}/Server/Server.cs
sed -i '/"[A-Z][A-Za-z0-9]*_.dll");/s::Assembly.GetExecutingAssembly().Location); //PATCH:' \
    ${SERVER}/Scripting/Scripting.cs
[ -f ${SERVER}/Modules/Compiling/Compiler.cs ] &&
    sed -i '/"[A-Z][A-Za-z0-9]*_.dll");/s::Assembly.GetExecutingAssembly().Location); //PATCH:' \
        ${SERVER}/Modules/Compiling/Compiler.cs

[ -f ${SERVER}/Modules/Compiling/Compiler.cs ] &&
    sed -i '/Path.GetFileName(Assembly.GetExecutingAssembly().Location);/s::Assembly.GetExecutingAssembly().Location; //PATCH:' \
        ${SERVER}/Modules/Compiling/Compiler.cs

Edit: Changes in base app (and older versions and a rather weird choice from @UnknownShadow200 ). *3

[johannespartin]

Hi guys,

I've worked out an implementation using .NET Core and building a docker container based on that. If you want I could further elaborate on that @UnknownShadow200

From our testing it works fine and we haven't found any impediments yet.

[UnknownShadow200]

Sure, might be beneficial to some people (although I personally don't really use Docker or .NET core)

[johannespartin]

Hi @UnknownShadow200 I do currently and it's quite beneficial. I've opened #629 and kept changes quite simple.