Development Environment Overview

This page is a detailed description of our docker based development environment. For and introduction how to use it check out our contribution guide.

Images & Services

There are many different docker images and docker-compose services that our development environment is based upon.

base

This image is the basis of all the other images. It adds our repositories, installs shared packages and sets up our user on top of our operating system (openSUSE Leap).

backend

This image installs all packages and sets up the configuration needed to run the OBS backend on top of the base image. It is used to run the backend and worker services with docker-compose. This image needs to be changed if the backend has as new dependency or configuration.

memcached

This image installs all the packages needed to run memached on top the base image and is used to run the cache service with docker-compose. This image only needs to be changed if want to run memcached differently.

mariadb

This image installs the mariadb package on top the base image and is used to run the db service with docker-compose. This image only needs to be changed if want to run mariadb differently.

frontend-base

This image installs all packages needed for our ruby on rails app on top of the base image. Additionally it serves as a kind of cache for the gem bundle. This image gets automatically rebuild on every commit by the docker hub so the gem bundle cache is up to date.

frontend

The frontend image is a thin layer on top of the frontend-base image that makes sure different users can run the ruby on rails app with their own user id. Mostly, so it does not generate log files, assets etc. in the git checkout with some strange user id. It is used to run the frontend service with docker-compose. This image needs to be rebuild every time the gem bundle changes.

This image is different to all other images. It is build by every developer, so it can pick up their user id, and is not on the docker hub.

ahm (Application Health Monitoring)

The ahm stack is a collection of upstream docker images needed to run the full Application Health Monitoring (AHM) stack. The images involved (influxdb, rabbitmq, telegraf and grafana) as well as their configuration can be found in docker-compose.ahm.yml.

To set up the ahm stack run rake docker:ahm:prepare. This will fetch all images and pre-configure them (rake dev:ahm:configure).

The full stack can be started with docker-compose -f docker-compose.ahm.yml -f docker-compose.yml up. Please note when you want to attach to any of the services you always need to prepend -f docker-compose.yml to the command.

You can access the following services:

• Grafana: http://localhost:8000 (admin/admin)
• RabbitMQ: http://localhost:15672 (guest/guest)

ha (HAProxy setup)

The ha setup uses HAProxy to load balance the requests between two frontend hosts. The docker-compose.ha.yml file defines the proxy container (upstream HAProxy container image) and a second frontend (frontend_node_2). The cache, db, backend and worker containers are shared between the frontends.

It can bestarted with: docker-compose -f docker-compose.yml -f docker-compose.ha.yml up. The HAProxy brings also a nice and simple statistics page which can be accessed via: http://localhost:32700/ (Admin/opensuse).

Services (docker-compose)

Available services in our development environment are:

• db
• cache
• backend
• worker
• frontend

Where it makes sense they expose their service also to your host machine so you can inspect the services with the standard tools. For instances you can connect to the db service via the standard SQL tools on localhost:3306.

The services also have their dependencies defined so they will bring up everything they need (for instance the worker will start a backend, if it isn't running).