I spent four and a half hours yesterday making a Docker container. I needed to consult with multiple friends for help, and it ended up being six lines of Dockerfile. I hate devops so much.
I like to play Archipelago. I also like to play Factorio. Luckily, there's an implementation so I can use Factorio as a slot in an Archipelago multiworld. Unfortunately, the implementation is cursed. I also want to play on this slot with friends, which makes things harder.
For the previous seed, I ran the setup for this on my server. It ended up being a horrible script calling into old versions of software that I had to manually restart quite often. In short, it was massively painful. My goal was to make a Docker image for the configuration so it would Just Work next time.
First, let's go over how you normally set this up. The Archipelago server needs to connect to the modded Factorio instance to run the game. For most games, this is fairly easy, but because modding Factorio is weird, you can't just spin up an internet connection within the game. Instead, you need a dedicated server and an external program to interface with it. I'll collectively call these two the container ship to avoid confusion.
Because of file locking issues, the Factorio instance within the container ship and the one you play on must be distinct. Additionally, on Windows, the non-portable standalone installation and the Steam installation cannot coexist. This is a constant source of frustration for new people running Factorio in an Archipelago seed.
The container ship's Factorio instance must then be started by the Archipelago Factorio Client (the other half of the container ship). This client connects to the Archipelago server, and drives the container ship so the game functions as expected. Finally, you can run Factorio and connect to localhost to play the game. Yay!
The Archipelago half of the container ship really wants control over the Factorio half. It's what starts the Factorio process, and usually also what kills it. It does this so it can use the RCON connection to send and receive commands. This is mostly fine, but it lead me to some problems.
Running the Archipelago client headlessly within the container ship is a right pain. If the method to do so is documented anywhere, I wasn't able to find it. To make it worse, the most recent release of Archipelago removed it as a separate executable. In a graphical environment, you'd run the launcher, which then opens the client window. Instead, I had to dig through Archipelago's source code to divine how to run the client via the launcher from the cli headlessly. And then, as a cherry on top, if a config file is broken, it'll try to open a file picker anyways.
Internally, my container uses a preexisting Factorio server as a base to construct the full container ship out of. This base image was highly annoying to work with. First, the entry point into the container is a script. That's normal, but it meant I had to modify the script to call the Archipelago side of things instead of Factorio directly (remember that Archipelago wants total control of Factorio, so it starts it itself).
The base container also does some wacky things with users and permissions. The attached volume for saves and configuration is owned by user 845, which means that putting stuff in there requires elevated privileges. This isn't the end of the world, and ideally I'll have at least the Archipelago mod updated automatically from within the container, but it is a pain.
Anyways, I got the thing made. It only takes a touch of configuration to run, which I provide a sample of in the project's README. Maybe next I'll cook up a runner for Balatest tests. That one seems like it'll be a whole pile of nightmares, though. We'll see.
Until next time,
- BakersDozenBagels
Questions? Comments? Email me at business@gdane.net. I'd love to hear from you!