Workhorse, embedded vs containerised
Some thoughts on moving towards a separate container for workhorse, or just keeping it in the same container for now.
In order to function properly, workhorse fits into our container system in the flowing ways:
- Workhorse will forward requests to unicorn, so needs to be connected to unicorn
- Workhorse needs access to redis, for CI Long polling (see https://gitlab.com/gitlab-org/gitlab-workhorse#redis)
- Workhorse needs to share an tmp uploads storage with unicorn, as it uses this storage to pass blobs to unicorn.
- Workhorse needs to share the same public/uploads folder as unicorn, in order to serve those static files.
- Workhorse needs to have the same assets in the public folder, that unicorn is asking for
I think it is very apparent from this list already that embedding workhorse into the same container as unicorn is an quick and easy way to achieve that connectivity. And that is exactly what I plan to implement in the next day or two, because it should be quick and easy, and allow us to work on other things.
But for very next iteration we should evaluate how we benefit from containerising workhorse. Even this can be a bit of an iterative process if we go this route.
- Containerise Workhorse but keep it in the unicorn pod
- Put workhorse in it's own Pod
I will leave my thoughts on each below.
Containerise Workhorse but keep it in the unicorn pod.
Containers within the same pod can share volumes between each other. This makes it easy for us to meet the same criteria as embedding workhorse.
Difficulties
- Not many, this should work fine, just take an extra day or two to setup vs embedding workhorse in the unicorn container.
Benefits
- We will not need to rebuild workhorse when rails changes.
- This aligns with the idea that we can eventually push these Docker builds back into their projects, to have them versioned and built with their projects.
- Aligns better with microservice methodology, and fits better with our 'cloud-native' label
Put workhorse in it's own pod.
Once we have containerised workhorse, we can take extra steps to place it in its own pod.
Difficulties
- We have to have a solution for shared storage right away in order to do this solution.
Benefits
- Allows us to limit resources for unicorn and workhorse separately.
- Allows us to scale workhorse and unicorn separately.
- Keeps GitLab error pages up while unicorn pods are deploying. (potentially)
- Keeping them separate, gives us the opportunity to at least explore workhorse being able to serve assets for multiple versions of unicorn as we try things like rolling deploys.
Summary, my thoughts
The benefits of doing Containerise Workhorse but keep it in the unicorn pod aren't that great, unless we do decide we want to commit to eventually doing Put workhorse in it's own pod. If we do decide we want to do that, containerising and placing it in the same unicorn pod are a great first step, and doesn't look like it would take much work. Once we have the embedded workhorse working, probably just another day or two to split it out and get a chart ready for it.
I personally think the benefits of putting workhorse in it's own pod make it worthwhile to do, once we have already figured out how to do the shared storage. If we don't have an easy solution for the shared storage, or that solution requires us to have changes done to workhorse that we don't really need otherwise, then I don't think this needs to be part of our first beta for our cloud native charts.