Abacus: Concourse pipelines

If you work with Cloud Foundry you noticed that most of the development is powered by Concourse CI.

Abacus has 3 Concourse pipelines

• Test
• Deploy
• Monitoring

Test pipeline

This pipeline builds Abacus and runs tests against Pouch, Couch and Mongo. The last step is to deploy Abacus on Cloud Foundry with in-memory PouchDB as a smoke test.

Future plans: automatic promotion of changes from develop to master branch so we can ensure that master is always stable.

Deploy pipeline

Deploys Abacus large profile and:

• creates and binds DB service to Abacus applications
• maps a route to each Abacus collector and reporting instance

The pipeline uses route mapping to get enable monitoring of a specific Abacus instances through CF router.

Abacus configuration is externalized in abacus-config directory that should be provided to the pipeline. The pipeline supports templates to

• automatically fill the application manifest.yml files
• extract sensitive information in one central place

Future plans: blue-green deployment.

Monitoring pipeline

Pings all Abacus applications using OPTIONS request. Sets up Grafana dashboard and reports the result in Riemann.

Screenshot:

Future plans: pull more metrics from Abacus.

All pipelines work with custom Docker images we build with the Dockerfiles here.

Abacus: MongoDB support

Abacus initially supported CouchDB. However we wanted to use MongoDB because SAP had existing MongoDB installations and expertise. 

We also wanted to see if we can use the Mongo's aggregation abilities: pipeline and map-reduce operations in the long run.

That was the reason I started porting the existing dbclient module supporting basic CouchDB operations like get, put, remove, allDocs and bulkDocs to Mongo.

Since we already had the specification in the form of unit tests for the couchclient I started implementing the client in semi-TDD manner. It took me a week to understand all the details.

The main difficulties came from the fact that I wanted to keep the CouchDB-based behaviour in the Mongo port. I had to mimic the old behaviour in the new mongoclient module to reduce the impact on the existing Abacus code base. This brought to life two simulated features:

• range limits reverse order 
• error codes

Once unit tests ran fine I started the integration suite. As I expected there were problems. The first one - we wanted to create a DB document with eureka port number as "$". Well Mongo does not like fields starting with $ in documents. Fixed.

The integration tests lead to more simulated features in the Mongo port:

• revisions
• duplicated documents in the results
• document order
• range limits reverse order

For all of the new features I added unit tests to the existing specification of the dbclient module.

Now I had a working mongo client for Abacus. I hurried to try it on Cloud Foundry installation and to my surprise it didn't work. 

The problem: I was using MongoDB that supported only one DB and I didn't had the permissions to create new ones. I implemented a custom partitioning that used collections instead of databases.

Everything was fine until we needed a bigger and highly-available instance of Mongo. Then we found out we don't support replica sets and in particular in combination with collections. A new test and a new feature.

Time for integration in the project. Jean-Sebastien Delfino came up with the idea to provide a minimalistic "layer" that based on an environment variable selects Couch or Mongo client. This played really well when he combined it with a set of scripts to select the DB in development.

If you want to use Abacus with MongoDB check out our configuration page and the Concourse pipeline (my next blog).