Docker

Sadly, due to a lack of resources we don't have time to get Kubernetes ready, so we're building the production server with Docker and a production build targeting Docker. Overall, during development we found out it can handle our load and tasks just fine; the only thing is it has issues releasing memory and some of the buffers that serve network traffic. We're adding duplication and load balancing to cover that risk. Regularly restarting one of the two nodes in turn should take care of the problem.

We're gearing up for a project with a microservices architecture. For the dev environments I designed a provisioning and deployment scenario based on Docker.

We stand up a server with Docker. When a developer picks up an issue and initializes an environment for the task in CI/CD, a docker compose group of containers named after the branch gets deployed, with ports from a dedicated range. Ports are reserved from a shared pool kept in a json file on the server — we deliberately sized the range so up to 10 environments can run on the box. There's also a root site on the domain deployed locally in IIS, and the pipeline spins up a subsite on it named after the branch, giving you an address like https://domain....com/branch-name; a reverse proxy is deployed to that subsite.

Docker (18.xx) is a containerization platform. Essentially it's like HyperV, except instead of building a whole VM you build just a slice of one — and you can write a script that runs operations on the image to prepare it, or just to execute something once. You can build your own image and push it to image registries.

I'd been hearing about it constantly at all kinds of conferences since 2015. But only now did I finally get around to testing what it can actually do. I'm a pretty seasoned HyperV virtual machine user. But Docker is something else entirely. A genuine revolution!