Heute möchte ich erklären, wie wir unsere Infrastruktur verwalten und wie wir dies in Zukunft tun wollen. Obwohl wir bei Sandstorm im letzten Jahr stark gewachsen sind, und mittlerweile fünf Personen beschäftigen, zählen wir definitiv noch als kleine Firma.

[English version below]

Aus Datenschutzgründen ist es uns wichtig, möglichst wenige Cloud Services zu verwenden – speziell die kritischen Dienste wollen wir selbst "in der Hand" haben. Damit haben wir die Herausforderung, mit möglichst wenig Aufwand verschiedenste Dienste zu betreiben. Wir haben kein Operations-Team, sondern machen dies alles nebenbei.

Das Problem: Viele kleine Dienste

Wir haben eine Vielzahl von Diensten und Tools, welche wir verwenden – und dabei nutzen wir sehr viele verschiedene Programmiersprachen und Umgebungen wie PHP, Node.js, Java/JVM und Ruby. Außerdem probieren wir gern herum und experimentieren bspw. auch mit der Programmiersprache Go.

Jede Programmierplattform hat einen präferierten Weg, wie Hosting erfolgen sollte. Für uns ist nun die Schwierigkeit, diesen Plattform-Zoo möglichst effizient zu betreiben. Die Performance sollte gut sein, jedoch geht es uns nicht darum, aus unseren Servern das absolut letzte Quentchen an Performance herauszuholen – wir betreiben momentan keine Ultra-High-Performance-Dienste oder Webseiten.

Die Lösung: Platform As A Service mit Dokku

Wir haben vor Kurzem ein System namens Dokku entdeckt, welches die Heroku PAAS basierend auf Docker nachbaut.

Das Grundprinzip: Der Quellcode der Webanwendung (egal in welcher Sprache) liegt in einem Git-Repository; und man pusht auf ein spezielles Git-Remote, um das Deployment zu starten. Dokku findet nun heraus, in welcher Programmiersprache die Anwendung geschrieben ist, installiert die Abhängigkeiten, stoppt die laufende Anwendung und startet letztendlich einen Docker-Container für die neue Anwendung.

Wir verwenden eine spezielle Dokku-Variante namens Dokku-Alt, welche auch Datenbanken, persistente Ordner, SSL und weitere Features unterstützt. Somit haben wir die folgenden Vorteile:

• das ganze Team kann neue Dienste deployen und produktiv schalten, egal in welcher Programmiersprache
• das Deployment ist sehr robust und läuft extrem zuverlässig
  
• wir haben eine zentrale Stelle für Backups
• man kann sehr einfach Kopien von einem bestehenden Dienst als Test-Instanzen live schalten
• Deployment muss nicht mehr über Jenkins passieren; dies reduziert die Komplexität des Deployments

Zusätzlich haben wir Dokku-Alt etwas erweitert, um eigene Nginx-Konfiguration, Volume Backup und Voll-Backup zu unterstützen. Diese Anpassungen sind natürlich auch auf GitHub verfügbar. 

Relation zu anderen Deployment-Tools wie TYPO3 Surf oder Capistrano

Bevor wir Dokku entdeckt haben, hatten wir verschiedenste Programmiersprachen-spezifische Deployment-Strategien. Wir haben beispielsweise TYPO3 Surf verwendet, um PHP-Anwendungen zu deployen. Für die anderen Sprachen gab es meist recht "handgestrickte" Lösungen, die von einer Jenkins-Instanz gestartet wurden.

In nächster Zeit werden wir für unsere interne Infrastruktur nahezu vollständig auf Dokku umsteigen, da beispielsweise TYPO3 Surf für uns zu groß ist:

• wir benötigen keinen Zero-Downtime-Deploy. Near-Zero-Downtime-Deploy ist für uns vollkommen ausreichend
• wir benötigen keine Orchestrierung verschiedener Server
  

Insgesamt halten wir beispielsweise Capistrano und Surf weiterhin für extrem wertvolle Tools, die in größeren Use Cases sinnvoll sind. Aber für unseren Anwendungsfall passt das Git-basierte Deployment einfach besser.

Blick in die Zukunft

TYPO3 Neos auf Heroku/Dokku: Wir sind gerade dabei, ein kleines Neos-Package zu entwickeln, welches Neos einfacher und direkter auf Heroku oder Dokku deploybar macht. Dies werden wir natürlich als Open Source veröffentlichen und dann auch auf diesem Blog beschreiben.

Single Signon mit vielen kleinen Diensten: Da wir nach dem Umstellen unserer Infrastruktur sehr viele entkoppelte Dienste verwenden, muss man das Problem der gemeinsamen Logins (Single Signon) dediziert lösen. Hierzu wird es bald einen neuen Blog-Post geben, welches unsere bestehende Lösung beschreibt. Stay Tuned!

Wir würden uns sehr über Feedback zu unserem Ansatz freuen – ihr könnt uns zum Beispiel direkt auf Twitter erreichen.

Infrastructure: PAAS with Heroku / Dokku

In this post we want to explain how we manage our internal infrastructure and plan to do so in the future. Although we grew quite significantly with Sandstorm last year and are 5 employees and a student now, we are definitely still a small company.

Due to data privacy considerations it is important for us to use as little cloud services as possible - we especially want to have our own hands on our most critical services. This generates the challenge to manage these services with as little effort as possible. As we do not have a dedicated operations team, we have to do it all additionally.

The Problem: many small services

We have a number of services and tools which we use - and they are based on very different programming languages and environments, such as PHP, Node.js, JAVA/JVM and Ruby. And we like to play and experiment with other languages such as Go.

Every programming platform has its preferred way to be hosted. The difficulty for us is to manage this platform zoo efficiently. Performance should be good, but we are not focused to get the last percentage points of performance for our services - we currently do not host ultra-high-performance-services or websites.

The Solution: Platform As A Service with Dokku

We discovered a system called Dokku a little while ago which is based on Heroku PAAS and implements Docker containers.

The principle: The source code of the web application (regardless of its language) resides in a Git-repository and you push to a specific Git-remote to initiate the deployment. Dokku finds out, in which language the application is written, installs the dependencies, stops the running application and finally starts a docker container for the new application.

We use a special Dokku-fork called Dokku-Alt, which also supports databases, persistent folders, SSL and more. This gives us the following advantages:

• our whole team can deploy new services and set them productive - no matter the programming language
  
• the deployment is very robust and runs extremely reliably
  
• we have a central locations for backups
  
• it is very easy to create a copy of a productive services i.e. as a test instance
  
• deployments don’t need to go through Jenkins any more - this reduces the complexity of a deployment
  

Additionally we have extended Dokku-Alt to support our own Nginx configurations, volume backup and full backups. These adaptation are of course available on GitHub.

Relation to other deployment tools such as TYPO3 Surf or Capistrano

Before we found Dokku we had a variety of language-specific deployment strategies. For example, we used TYPO3 Surf to deploy PHP applications. For other languages we mostly used “hand-knitted” solutions started from Jenkins.

We will migrate our internal infrastructure almost completely to Dokku in the coming weeks, as many deployment tools such as TYPO3 Surf are too big for us:

• we do not need a zero-downtime-deployment. Near-zero-downtime-deployment is absolutely sufficient for us
• we do not need to orchestrate different servers

All in all we still think that tools such as Capistrano and Surf are extremely valuable and make a lot of sense for larger use cases. But for our use this Git-based deployment just works better.

A glimpse of the future

TYPO3 Neos on Heroku/Dokku: we are just developing a small Neos-package which is supposed to make Neos deployments to Heroku and Dokku easier and more direct. We will release this as Open Source and write another post about it.

Single signon with lots of small services: due to the fact that we have a lot of isolated services after the migration to Dokku, we have to solve the problem of a unified login (single signon) dedicatedly. We will publish another blog article describing our solution. So stay tuned!

We would love to get your feedback for our approach - you can easily reach us on Twitter.