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  docs.docker.com.

#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 😉

 

Microservice Development Environment on OSX

If you are a Mac user who likes the feeling of deleting stuff and have drunken the docker inc. kool-aid (i.e. implementing microservice architecures on top of the “docker-toolbox”) this just might mean a breath of fresh air for you as well:

  1. uninstall vagrant
  2. trash your “favourite” hypervisor (vmware, virtualbox, etc) with it
  3. learn about the existence of the lean xhyve built on top of Apple’s own hypervisor framework (only on OSX 10.10+)
  4. dlite and docker-compose your docker development containers
  5. docker-compose up  yourself towards getting some programming done again

Update:

Post by dlite creator Nathan LaFreniere – Simplifying Docker on OS X

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