Markus Klepp

I'm a web, mobile & application developer from Vienna.

Gitlab 9.5 container registry with amazon S3

After some struggles with some missing documentation I finally did it.

Step 1

Create a bucket and an IAM-User with the recommended policy from

#Step 2
Use this conf in /etc/gitlab/gitlab.rb: (Don’t forget the region)

registry['storage'] = {
  's3' => {
    'accesskey' => 'ACCESS_KEY',
    'secretkey' => 'SECRET_ACCESS_KEY',
    'bucket' => 'S3_BUCKET_NAME',
    'region' => 'S3_REGION' # e.g. 'eu-central-1'

Step 3

(This is the step that drove me almost mad)
Create a folder named “test” in the bucket

Step 4

Start your CI and enjoy your success!

Add a /ping route to your services

You have to rely on something to check if our services are up and running. Wether it’s a monitoring tool, a loadbalancer checking for healthy endpoints, …

I recommend using a a route named /ping and use good old http request for checking.

This way – imho – you have a stronger guarantee that your service is up and running.

PS: Don’t forget to disable logging for this route 😉


Limit access to your staging environment in rails

There exists some confusing information on how to implement password protection for your staging environment. I found the following config suitable: Use your production env for staging and configure the required password with an env-variable.

Add to your config/deploy/production.rb:

    config.middleware.insert_after(::Rack::Runtime, "::Rack::Auth::Basic", "Staging") do |u, p|
        [u, p] == ['staging', ENV['STAGING_PASSWORD']]

Ansible and Monit for simple server monitoring and documentation

A month ago a customer asked me to help him with his server monitoring. My first step was to evaluate what servers were running what services, so I turned to the customer’s developers for a list of services per host. Long story short – there wasn’t any kind of server documentation. So a second task emerged: Write a server documentation. Why not kill two birds with one stone? Continue reading