Development Environment Containers

• Introduction
• Containers Used in the Development Environment
• Containers Used in the Continuous Integration Platform
• docker-compose Services
• Images & Services

Introduction

OBS is currently configured for creating docker containers, that are used for:

• setting up the development environment, and
• running the test suite in the CI platform.

This document describes, how the container images involved in both purposes are created. For an introduction on how to use the development environment check out our contribution guide.

Containers Used in the Development Environment

The OBS development environment uses sets of docker containers, defined in a couple of docker-compose files. For example, the main docker-compose file (docker-compose.yml) orchestrates these services: db, cache, backend, worker, and frontend. Each of these services relies in one docker container. For more details about this topic, visit the section docker-compose Services below.

The base images used by these docker containers are created by OBS inside this OBS project. In this project, each of its packages is configured with a Dockerfile file, so they build one docker image. And, when the build of the docker image is successful, OBS also publishes the images to the openSUSE registry. Details on each image can be found in the section Images & Services below.

Why are there different sets of container images?

It is convinient. Using sets of containers allows to only provide a certain functionality in a container, to reuse that container, and do it with the minimum amount of software dependencies.

For example, some OBS package is the only one in a set of OBS packages that has a Dockerfile wich installs the mariadb package: OBS will rebuild only that docker image from that set of OBS packages when the package mariadb is updated.

When is it a new build triggered?

As we saw in the previous section, OBS packages with Dockerfile files automatically trigger a build each time a dependent package is updated.

This helps most of the times, for most of the OBS packages that create the docker images. But the case of the frontend-base OBS package is special. In this case we need to build a new docker image each time there is a change in the default branch for the OBS GitHub project. To accomplish that, we make use of the obs_scm service, and GitHub webhooks. This is already described in the OBS User Guide. You can see how this has been configured, in the definition of services (_service file) and in the Webhooks configuration for the open-build-service GitHub project.

Containers Used in the Continuous Integration Platform

OBS continous integration testing is performed using CircleCI. This is defined in the .circleci/config.yml file.

To not change the image tags used in this configuration file, a level of indirection is added: the OBS project OBS:Server:Unstable:container:CI was created, with packages that are package links to the packages used in the development environment.

docker-compose Services

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 instance 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.

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.