Proposal: re-work unicorn configuration
Summary
Currently, we have two copies of unicorn.rb
. One exists in the gitlab-unicorn-xe
container, and another here as a ConfigMap
entry which overwrites the one in the container.
Instead of duplicating work (and thus MRs), we should make the one in the container configurable
Details
The gitlab-unicorn-xe
containers has a static, unicorn.rb
that is simply overriden as a part of our chart. This works for us, and makes it essentially "simple" for others as well, as they can simply provide this file as a Docker volume as well.
Instead of relying on this stacking, and thus multiple copies to maintain, I am suggesting we make the one in the container capable of being configured externally.
Our template for unicorn.rb
in the ConfigMap
only populates a few, non-sensitive items:
worker_processes {{ .Values.workerProcesses }}
listen "0.0.0.0:{{ .Values.service.internalPort }}", :tcp_nopush => true
ENV['GITLAB_UNICORN_MEMORY_MIN'] = ({{ int .Values.memory.min }} * 1 << 20).to_s
ENV['GITLAB_UNICORN_MEMORY_MAX'] = ({{ int .Values.memory.max }} * 1 << 20).to_s
There should be no reason for us to be unable to provide these as environment variables, or in a simple configuration YAML that can be used to populate the unicorn.rb
inside the container.
Implementation
This should consist of two MRs:
- Alterations to CNG to make the
unicorn.rb
configurable via environment - Alterations to
gitlab/unicorn
chart to move the configuration from mounting from ConfigMap template to environment of the container.