Skip to content

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:

  1. Alterations to CNG to make the unicorn.rb configurable via environment
  2. Alterations to gitlab/unicorn chart to move the configuration from mounting from ConfigMap template to environment of the container.
Edited by Jason Plum