Tag: git

Gitlab, Ruby private repository, Docker container and safe way to add SSH key for build process only


This is not a tutorial on how to use Docker with SSH keys and private repositories. This is a solution to a particular safety issue when building Docker containers.

I won't get into details on how to create a Dockerfile with a SSH key, etc - there's enough about that in the Internet.

Problem - container stored SSH key

During the Docker build process, we need a SSH key for bundle install. We need it, because we have a Gitlab with private repositories that we want to pull. Since Docker caches this key, it will go to a production environment together with the whole container. It is unsafe. If someone got somehow into the container, he could use this key to get into your repositories.

Solution - during build only, one-time SSH key pair

This issue can be easily solved. To do so, we need to:

  1. Generate SSH key pair
  2. Add it to our Gitlab instance using Gitlab API
  3. Add private key to Docker
  4. Docker b uild (and bundle install)
  5. Remove/revoke our key from Gitlab
  6. Deploy container

There's still going to be a SSH key in the container, but it won't be valid. Since it will be valid only during the build process (which happens on the CI), there's no risk. The key gets revoked before we deploy container.


For Gitlab API communication we will be using Gitlab API gem.

require 'gitlab'
require 'fileutils'

# I assume you have this script in the same place where your Dockerfile

# You can find your private token on the account page of your gitlab user
Gitlab.configure do |config|
  config.endpoint = 'http://your-gitlab/api/v3'
  config.private_token  = 'deploy/docker gitlab user private token'

# Add this if you use self signed SSL cert with Gitlab

'ssh-keygen -q -t rsa -f ./id_rsa -N ""'

key = Gitlab.create_ssh_key("docker-#{Time.now.to_s}", File.read('./id_rsa.pub'))

# Note that you should provide some sort of failover to remove key if build fails
system('docker build .')



Running GitLab 7.1 using Puma instead of a Unicorn


Warning! Before you do this, please read why you should'nt: why did gitlab 6 switch back to unicorn?

So now, when


let's get started...

Gemfile updates

Nothing special here. Just add:

gem 'puma'

and then:

# From /home/gitlab/gitlab
sudo bundle install --no-deployment
sudo -u gitlab -H bundle install --deployment --without development test postgres

Puma config

Create a puma.rb file in your gitlab config dir and copy/paste this:

app_path = File.expand_path(File.dirname(File.dirname(__FILE__)))

rails_env = ENV['RAILS_ENV'] ||  'production'
environment rails_env

threads 4, 32
workers 2

daemonize true
bind                 "unix://#{app_path}/tmp/puma/sock"
state_path           "#{app_path}/tmp/puma/state"
pidfile              "#{app_path}/tmp/puma/pid"
activate_control_app "unix://#{app_path}/tmp/puma/ctlsock"
stdout_redirect      "#{app_path}/log/puma_access.log", "#{app_path}/log/puma_error.log"



mkdir /home/git/gitlab/tmp/puma

At this point, you should be able to execute puma worker:

# You should execute this from a git user
cd /home/git/gitlab && exec bundle exec puma -C /home/git/gitlab/config/puma.rb

[4419] Puma starting in cluster mode...
[4419] * Version 2.9.0 (ruby 2.1.2-p95), codename: Team High Five
[4419] * Min threads: 4, max threads: 32
[4419] * Environment: production
[4419] * Process workers: 2
[4419] * Preloading application
[4419] * Listening on unix:///home/git/gitlab/tmp/puma/sock

Init Script

To manage my Pumas I use Jungle. You can read more about it here. From this point, I assume that you have figured out a way to autostart GitLab Puma process (if not, you'll have to start it each time manually - good luck!).

Unfortunately it is not all. Default GitLab init script (provided with GitLab sources) will try to run Unicorn, so we need to silent it (but we need to keep the Sidekiq part).

To do so, we have to change the /etc/init.d/gitlab script.

start_gitlab() method (line 165) - we have to comment the else case:

  # Then check if the service is running. If it is: don't start again.
  if [ "$web_status" = "0" ]; then
    echo "The Unicorn web server already running with pid $wpid, not restarting."
  # else
    # Remove old socket if it exists
    # rm -f "$socket_path"/gitlab.socket 2>/dev/null
    # Start the web server
    # RAILS_ENV=$RAILS_ENV bin/web start

wait_for_pids() method (line 78) - we have to remote the first condition from while loop. We no longer check for web_server_pid_path:

  # We are sleeping a bit here mostly because sidekiq is slow at writing it's pid
  while [ ! -f $sidekiq_pid_path ]; do
    sleep 0.1;
    if [ $((i%10)) = 0 ]; then
      echo -n "."
    elif [ $((i)) = 301 ]; then
      echo "Waited 30s for the processes to write their pids, something probably went wrong."
      exit 1;

There are some other places that you could modify - so you would not get any warnings, but hey! Those are just warnings. What I did above is an absolute minimum for starting/stopping Sidekiq without any Unicorn errors.

Nginx server block

And an example Nginx server block (virtual host) config:

upstream git.server.name {
  server unix:///home/git/gitlab/tmp/puma/sock;

server {
  server_name git.server.name;
  client_max_body_size 32M;

  keepalive_timeout 5;

  root /home/git/gitlab/public;
  access_log /var/log/nginx/git.server.name.access.log;
  error_log  /var/log/nginx/git.server.name.error.log;

  location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;

    if (-f $request_filename) {

    if (!-f $request_filename) {
      proxy_pass http://git.server.name;

After that - you are ready to go! Good luck!

Copyright © 2023 Closer to Code

Theme by Anders NorenUp ↑