Camptocamp – References

Camptocamp deploys the Puppet ecosystem with Docker containers

The use of containers for the deployment of complex applications improves flexibility, lifecycle management and scalability.

Internal Case Study

The Business

With its three departments (GeospatialBusinessInfrastructure) the Camptocamp group is inherently organized around the DevOps methodologies. The main objective of this approach is to align our employees (specialized engineers, business analysts, integrators, testers) with common objectives and values, work together to produce the value of the company and give satisfaction to our customers. Promoting agility and organizing our teams around automated and transversal processes is at the heart of our concerns.


Puppet est une solution de gestion de configuration comprenant plusieurs composants, selon les choix d’outils effectués. Dans notre cas : Puppetserver (Java/Clojure/JRuby), PuppetDB (Java/Clojure), PostgreSQL, ActiveMQ (Java), r10k (Ruby), Puppetboard (Python/WSGI).

The traditional approach consists in managing these components with Puppet itself, generating a situation of the egg and chicken paradox, which makes the installation and evolution of the system complex.

When Puppet 4.0 was released in 2015, Puppet Inc. changed the packaging of its solution (“All-in-one” packages). Our whole approach is to be adapted, and we choose to consider a technological change in order to solve the paradox of the egg and the chicken that represents the management of the Puppet stack with Puppet itself.

At the same time, we were more and more interested in Docker as a production deployment solution (we were already actively using it to automate development and testing), and the stack Puppet seemed to us an ideal project to test this tool for several reasons: it is not critical for the business and it uses technologies necessary for our other products (PostgreSQL, JVM, Python/WSGI).

In August 2015, we created Docker images for the various components of the Puppet stack (Puppetserver, r10k, PuppetDB/PostgreSQL, ActiveMQ/MCollective, Puppetboard), as well as a docker-component composition to deploy the whole. This composition has been in production for 5 months, and has confirmed the technological choice of Docker.

Soon, however, we wanted to go further and deploy this stack, as well as other infrastructure stacks, in a shared multi-node environment. We then carried out an internal study that led us to choose Rancher as the Docker orchestrator for its ease of deployment and use, and its compliance with the docker-compose.yaml format.

We then converted our Puppet composition into a Rancher catalogue template, which we quickly made public.

In 2017, after 2 years of managing the Puppet stack using Docker, it is now clear that Kubernetes has established itself as the orchestrator of reference containers. Our partnership with RedHat leads us to focus on OpenShift v3, which we had already planned to use 2 years earlier, but which we had found immature. So we carry our Puppet stack on OpenShift.


The Puppet stack is based on a series of Docker images:

  • Puppetserver: provides the Puppet Master under the JVM, as well as the CA
  • activemq: used as middleware for the implementation of MCollective, which allows the orchestration of code deployment using r10k, as well as the remote control of stack elements (CA, PuppetDB)
  • r10k: provides r10k to deploy the Puppet code on the Puppet Master. This container shares volumes with Puppet containers, which allows the Puppet Master to access the code. r10k image uses MCollective service to perform on-demand deployments
  • Puppetdb: provides the PuppetDB, connected to a PostgreSQL server external to the stack.
  • Puppetboard: a lightweight web interface for reading PuppetDB information
  • webhook: provides a web service to trigger a code deployment using r10k when a commit git is received.


The deployment of the Puppet stack on a container technology enabled us to free ourselves from the paradox of the egg and the chicken. We have gained a lot of flexibility.

This also enabled us to validate Docker’s maturity for production deployments. We are now using it in all new Camptocamp projects.


  1. *
  2. *
  3. *
  4. *