Why Docker Makes Sense For Real-Time Studios
A rundown of what Docker is, what it is used for and how it can benefit your processes and infrastructure.
Come one, come all! Here at REWIND, we have elected to adopt Docker as part of our infrastructure, so this article is a rundown of what Docker is, why you’d want to use it and how we’ve started the adoption of Docker into our processes.
What is Docker?
Docker (from Docker Inc) allows the emulation of another operating system closer to the host OS than other options such as a Virtual Machine (VM). This is accomplished through virtual machine configurations called “Images”. These images are essentially a basic operating system with various prerequisites installed already, for example, cmake and make. An image that is run is spun up into a “Container” — this is to maintain the integrity of the base images used and keeps all running configurations separate in an instance that can be debugged or thrown away.
With the efficiency gains, Docker would be worth switching to in its own right, however, it also allows us to get source controlled versions of images/containers. These source controlled items provide a reliable starting point for development, with many open-source projects providing their tools within images freely available on the Docker Hub. Imagine a GitHub repo for virtualized images and you won’t go too far wrong, all referenceable by name and version.
The Docker Hub provides a shortcut to developing your own images. If you can’t find all of what you need in one, you can use the most similar image as a base for the custom image you need. Basic images gained from the hub will simply provide the build tools that you need without any additional complications.
Why use Docker?
So, now we know what Docker is, we can get into the bigger question. Why use it?
The key advantage is definitely the Docker Hub and being able to build new images from pre-existing images to allow for the development time of an image to be shortened. Images on the hub being free and publicly available for use means that there is a vast number of them to choose from, regardless of what you are looking for.
The main reason that REWIND has adopted Docker into its infrastructure and begun to work towards moving projects to a Docker solution is that it simplifies the developer workflow. Rather than following complicated tutorials to set up each new IDE, or even worse, older versions of an IDE where everything has moved on (we’ve all been in that nightmare!).With Docker, everything is versioned, so grab the version you need and go. If a project gets sidelined for a while, on resuming, you just grab the version you were working with from the Docker Hub and you’re off to the races!
Another point of note is that with this simpler get and use of build tools that Docker allows, the management of Continuous Integration(CI) systems becomes much easier. Imagine needing to support Linux and Windows build tools with different OS bases, how would you manage that with any level of efficiency? With Docker, simply grab the image, create a container to run on your machine, enter the same command as on your local/development machine and job done! Your whole CI process is now naturally developed alongside the development of each project, it’s no longer an afterthought.
A consequence of this side-by-side development is legacy projects are much easier to support the resurrection of, or fixes of, without wasting resource keeping legacy configurations. Or in the worst cases, having to keep a hard drive for a build node in archive storage. With a Docker solution, you simply grab the version you need from the Hub and build.
Looking at the Docker solution from another perspective, if you need to expand your capacity quickly you can simply install Docker Desktop on any hardware you have available and let it run. Or just deploy multiple containers to the cloud if that’s what floats your boat.
How do you go about adapting an existing project into Docker?
This is actually simpler than you’d think. At REWIND, we wanted to explore porting an existing C++ library to WebAssembly (WASM). We needed to build an existing project with a new compiler and Linux based tools for an (up to that point) Windows-based project. So the obvious solution for us was to pull the trigger and leverage the expertise within the team to get a Docker image utilised for the solution.
Getting Started
So first thing first, we needed this project to just compile with the emscripten toolset. As it happens, there is a Docker image that is configured, released and maintained by the emscripten community. So we were lucky, the community has contained everything that you need into this Linux based Docker image. This Docker image is then created in a locally run environment as a container which can then be destroyed easily, removing any runtime file generated within the virtualised instance.
So we have an image that has the tools that we need and a makefile that can run with those tools, what’s next?
Well, that’ll be the setup of the commands and local environment to get the two to work together well. The best way to use Docker for this project was to use the “Docker run” command, this allows us to input the command line arguments that we want alongside this command “emmake make” which is our make command.
Now into the nitty-gritty. The Docker container is a virtualized machine that comes with its own file system, so we need to map our local file system into the Docker file system. There are two main additional arguments that we need to add, the workspace (-w) and the volume (-v) commands.
The workspace command simply determines where the Docker container starts its command-line operations and the commands that we input at the end of the Docker run. The volume is the most important mapping, this maps the local file system into the virtualised file system.
By completing this mapping we get all of the artefacts of any command, so for our make command, we get all of the intermediate files and binaries directly in our local file system! All this without needing to copy them out after the fact results in less additional scripting surrounding the command and a better solution overall. An additional benefit is that running with a volume command gives the deliverable binary and all other artefacts in the correct location on the local file system, you can even format the make to output into the same structure as all of your other builds so nothing looks out of place! All without any complicated install instructions.
Moving into Continuous Integration
Now for the massive advantage of using Docker: Continuous Integration.
By using Docker files contained either in the Public Docker Hub or on a Private Docker Hub, we simply pull the appropriate version of the image that we need. If you are getting the latest, I’d advise freezing at the latest version so if any major versions get released for your image you aren’t affected by default, rather you’d need to make a conscious choice to upgrade.
Simply adding the Docker command used on the local machine on the build node, you can easily get the same exact build environment and that’s the CI implementation done, just set up your artefact retrieval and you’re away!
It is worth noting that if your infrastructure is cloud-based then you can run containers on a cheaper instance and save yourself/your organization some money, which is always a good thing!
Docker, REWIND and the Future
So you’ve probably guessed what our conclusion is regarding Docker…We will be endeavouring to convert all of our build processes, where possible, to ‘Dockerised’ solutions in the future. As a project goes through the development cycle, the cost of developing and adopting the Docker toolset into our processes becomes increasingly minimal; especially in comparison to the benefits that Docker delivers for the project.
The transition to Docker is definitely a long term path that we are setting ourselves on, with many challenges on the horizon — the most monolithic challenge being creating Docker images for UE4 and Unity, both of which are complex build chains. Luckily, there is an open source project for UE4 which is available on GitHub here; whilst we have not tested locally, the fact that it is still in active development is always a good sign! Here at REWIND, we love working together to constantly improve and overcome challenges, so we are ready to take this on.
XRLO: eXtended Reality Lowdown is brought to you by REWIND, an immersive design and innovation company. If you want to talk tech, ideas, and the future, get in touch here.
Your claps and follows help us understand what our readers like. If you liked our articles, show them some love! ❤️
We’d also love to hear from you. If you’re passionate about all things XR, you can apply to contribute to XRLO here. ✍️
