Perforce docker containers

Perforce docker containers

April 20, 2017 (661 words)

Setting up a new perforce server from scratch is pretty easy, or so it seems at first glance. Indeed it’s pretty easy, you just have to download p4d and run it. However, chances are that you will then have it setup incorrectly and it’s very hard to change a perforce setup once deployed.

There also tons of best practices that you will miss out on. I believe the easy of use for initial setup of the server is more intended for trying things out, but not for running in production.

Fork Amit’s docker images and introduce phusion / ubuntu

We can fix this with pre-baked docker images that has perforce setup somewhat correctly from the beginning. Amit for example make a bunch of them here. I later forked these and made my own versions:

https://github.com/jtilander/docker-p4

After looking at the images that Amit made, I had the idea to have both p4d and git fusion to be setup automatically when started from a single docker-compose file. I also wanted to have the docker image be fully hosted in one image, so I opted to use the phusion image which contained a bunch of fixes as well as the ability to run multiple things inside an image (e.g. cron).

I’d consider this fork and the work that went into it a failed experiment, apart from the perfore proxy container – it’s actually still in use, and pretty much does the one simple thing: serve a perforce proxy.

https://hub.docker.com/r/jtilander/p4-proxy/

Switch to alpine based docker images

The phusion image worked well for a while, but iterating on these images became a little bit slow, as well as the the resulting images are pretty large and complex. I wanted to get back to simpler times, so I started over with the goal of an image that you can just start and forget.

Alpine linux is a super small distribution based on busy-box, a monolithic executable that emulates / implements many of the common unix utils. The whole philosophy behind alpine is small and fast. What you sacrifice is some more security rigor at this point, but I’m sure they will catch up eventuall now that Alpine’s creator is working for docker.

Regardless, iterating and developing with Docker and Alpine is a much more pleasant experience since it’s order of magnitude faster than an Ubuntu based image – apt-get / apt-update are really much slower than apk add. The difference really has to be experienced.

So, there is a new alpine based server image here for perforce:

https://github.com/jtilander/p4d

libc

One of the things you might run into when using Alpine, is that they use a non standard musl c runtime library. For binary files that you download that have been dynamically linked to the more common gnu libc runtime libraries, this might pose a problem. Luckily, most of the binary packages are available at https://pkgs.alpinelinux.org so you sidestep this problem.

But for some instances, e.g. the perforce client, this still is a problem. I’ve sidestepped the problem by cheating: I include the libc runtime libraries in my docker container. This means that it doesn’t work on ARM. But as I’ve previously written, the whole ARM docker ecosystem is just broken. If you are trying to get things working under docker for ARM, then be prepared to do a lot of compilation yourself. On a shitty SD card. On an underpowered RPI. Yay.

In closing

Most of the documentation of how to run a simple server for perforce under docker should be evident in the readme for the project here:

https://github.com/jtilander/p4d

If it’s not, then my bad. There is also a fairly simplistic makefile to help facilitate the most common operations that you might want to perform. Inspecting these two files should get you started on bringing up a fire and forget perforce server. This is usually a great way to do it for experimentation, as you don’t want to do this on a production instance.

References

https://thenewstack.io/alpine-linux-heart-docker/