Unity in a Windows Container

I've been experimenting with some CI options for the team and one of the experiments was running Unity in a Windows container using Docker & the mcr.microsoft.com/windows/servercore:1809 container. I am able to install Unity successfully via silent installation and redistributable packages were also installed automatically/successfully. When performing a small test I get differing results between the host and the container.

Performed host test for empty project creation:

Unity.exe -nographics -batchmode -createProject C:\foo

Success.

Same test within the container fails. More concerning is that C:\Users\%USERNAME%\AppData\Local\Unity doesn't exist within the container which indicates that Unity.exe is failing to launch in any capacity to create those initial folders and data files.

No system events, etc. are generated that would give me clues as to why the executable fails to launch in the container.

Curious if anyone else has experimented with a Windows-based container and had success?

Thanks,

Ian

 

I've been seeing almost exactly the same behavior here, and it's incredibly confusing. It seems like the Unity process does nothing, outputs nothing, and doesn't care even what arguments you give it. Overall, the execution takes about 300ms before the process dies.

Just pinging this thread to say that I've seen the same thing, and that container support is a huge need for folks doing any kind of automated CI in the cloud.

 

I'm working this out now with the help of the Azure Devops agent that runs inside Docker. Working with an agent like this one is nice because it's pretty straightforward to get the logs through their CI tools on a build page. Will update if I succeed or fail tomorrow.

 

Any luck? We also want containerised unity builds, and might start exploring this right over new-years.

 

I have it mostly working, just need to finish up and get an example up somewhere. Basically you can just set up a Docker build agent which is configured to install and run Unity, running on a host machine. You can use a volume to mount the source into the agent or it can live in the agent work folder. I'm using Azure DevOps and PowerShell Core to run the automation pipeline that will run on Windows or OSX hosts. The PowerShell scripts let us define templates for automated runs, which can also be edited from an in-editor build tool. I want to hook in our automation to this pipeline as well so it will eventually be expanded out to do that as well. This can also be done on Linux if you're willing to work in what is basically beta support for Unity3d on Linux. I tried for a while but it was never stable enough to run in our production pipeline.

 

How have you managed to get Unity running? The installation process works fine but when I try to execute Unity.exe, it crashes with the error "STATUS_DLL_NOT_FOUND" which points to something missing in the Windows Server Core base image.

 

We've largely given up on running Unity within a Windows Docker image. Unity inside a Linux container seems to work fine for us, so we've moved over to that for all of our builds.

 

I haven't been able to figure out how to attach Visual Studio to Unity inside a Linux container.
Debug > Attach Unity Debugger doesn't see the container instance. Manually adding IP and ports in that dialog haven't worked either.
Debug > Attach to Process allows me to see the Unity process on the Linux container, but then only gives me a couple of incorrect options for attaching.

Has anyone had success with this?

 

Not going to lie, I imagine this will be pretty tough. Presumably you need to get the networking forwarding set up properly.. but I'm not sure what that would require.

You might have better luck fixing whatever you need to debug on a Ubuntu VirtualBox instance, or something like that. Then you can just install VSCode/Rider there.

 

If Unity expects multiplayer servers to be run like this, it needs better support. I'm also trying Docker and it's a nightmare to debug. Even something as simple as getting a core dump from a debug build is frustrating. I get the core dump, and then it just has the Unity handler in it despite a segfault clearly happening prior which triggers the handler. Getting the debugger to attach to a port in less than 10 seconds you don't know ahead of time is like playing a game. This is nuts.

It's worked really well for me.... until now since I've never had to debug anything in Linux itself. But this segfault isnt happening on any other platform.

 

You don't need special support for (most) containers. In fact, this works as-is right now [for a lot of things]. The problem [I'm facing personally] that the debugger takes a random port and you don't know it ahead of time, which is super frustrating. It's a similar problem I've raised about the profiler. Super basic functionality - I should be able to specify it or grab it through an API in script. This is a universal platform problem, not just specific to containers, happens on Windows standalone even.

Right now I'm playing a timing game. I launch the container, wait for unity to count down to 0 with the wait for debugger flag, then in VS Unity plugin I type in the IP of the container and the port I've guessed Unity will use based on its GUID. The debugger port is 56000 + last 3 digits of the GUID it mentions in the beginning of the log. I've only recognized this through pattern matching. No API, no documentation, just luck.
It's a bit silly of a process no?

The core dump stuff is a linux problem, not even a docker specific problem to be fair.