Docker-Container als flexible Build-Umgebung

Projektspezifisch und dynamisch

Tobias Gesellchen


Aktuell müssen CI-Server wie TeamCity, Jenkins oder Anbieter wie Travis CI [1] auf die Vielzahl von verschiedenen Projektanforderungen vorbereitet sein. Dazu gehören beispielsweise verschiedene Versionen von Java, Node.js, Ruby, Go oder anderen Sprachen, Build-Tools wie Maven oder Gradle in verschiedenen Versionsständen und sicherlich auch Datenbanken und sogar vollständige Betriebssysteme wie OS X [2]. Dieser Artikel geht auf Herausforderungen und Möglichkeiten beim Einsatz von TeamCity [3] ein, das beschriebene Setup eines Docker-Build-Systems ist für andere CI-Tools ebenso anwendbar.

Projektspezifische Build-Server

Die Pflege umfassender Build-Systeme ist aufwändig und führt gerade bei auslaufendem Herstellersupport von älteren Versionen zur Frage, wie bzw. wann beispielsweise ältere Compiler vom Build-System entfernt werden können. Die parallele Nutzung auf einem Server mit mehreren Build-Agents kann problematisch werden, wenn versehentlich geteilte Ressourcen von zwei verschiedenen Builds modifiziert werden. Selbst bei gewöhnlichen Vorgängen wie dem Einspielen von Systemupdates müssen nicht nur ein Projekt, sondern praktisch alle Projekte im Vorfeld auf potenzielle Probleme geprüft werden. Der kommunikative Aufwand mit verschiedenen Teams steigt entsprechend.

Man hat die Möglichkeit, projektspezifische Build-Server zu konfigurieren. Spezifische Server haben den Vorteil, dass man spezielle Optimierungen vornehmen kann: Manche Projekte benötigen zum Build mehr CPUs oder Kerne, andere Projekte lassen sich durch schnellere Festplatten beschleunigen. Solche Server funktionieren problemlos, sind nach Bedarf auf geänderte Anforderungen anpassbar und beeinflussen fremde Projekte nicht.

Was passiert, wenn ein solcher spezifischer Server ausfällt? Andere Build-Systeme könnten als Fallback dienen, müssen allerdings meist um die bisher nicht benötigten Tools und deren Konfiguration ergänzt werden. Abgesehen davon, dass man unter einem wahrscheinlich höheren Zeitdruck steht, kann man nur schlecht abschätzen, ob die zwei auf einem Server vereinten Build-Systeme miteinander harmonieren.

Projektspezifische Build-Images

Mit Docker hat man die Chance, gemeinsam nur einen Server zu nutzen, ohne die Kapselung eines individuellen Build-Systems aufzugeben: Dazu kann jedes Projekt ein Docker-Image definieren, das sogar in Form eines Dockerfiles [4] direkt neben dem Sourcecode liegen kann. Im Projekt findet man also eine vollständige Beschreibung des für einen erfolgreichen Bui...

Docker-Container als flexible Build-Umgebung

Projektspezifisch und dynamisch

Tobias Gesellchen


Aktuell müssen CI-Server wie TeamCity, Jenkins oder Anbieter wie Travis CI [1] auf die Vielzahl von verschiedenen Projektanforderungen vorbereitet sein. Dazu gehören beispielsweise verschiedene Versionen von Java, Node.js, Ruby, Go oder anderen Sprachen, Build-Tools wie Maven oder Gradle in verschiedenen Versionsständen und sicherlich auch Datenbanken und sogar vollständige Betriebssysteme wie OS X [2]. Dieser Artikel geht auf Herausforderungen und Möglichkeiten beim Einsatz von TeamCity [3] ein, das beschriebene Setup eines Docker-Build-Systems ist für andere CI-Tools ebenso anwendbar.

Projektspezifische Build-Server

Die Pflege umfassender Build-Systeme ist aufwändig und führt gerade bei auslaufendem Herstellersupport von älteren Versionen zur Frage, wie bzw. wann beispielsweise ältere Compiler vom Build-System entfernt werden können. Die parallele Nutzung auf einem Server mit mehreren Build-Agents kann problematisch werden, wenn versehentlich geteilte Ressourcen von zwei verschiedenen Builds modifiziert werden. Selbst bei gewöhnlichen Vorgängen wie dem Einspielen von Systemupdates müssen nicht nur ein Projekt, sondern praktisch alle Projekte im Vorfeld auf potenzielle Probleme geprüft werden. Der kommunikative Aufwand mit verschiedenen Teams steigt entsprechend.

Man hat die Möglichkeit, projektspezifische Build-Server zu konfigurieren. Spezifische Server haben den Vorteil, dass man spezielle Optimierungen vornehmen kann: Manche Projekte benötigen zum Build mehr CPUs oder Kerne, andere Projekte lassen sich durch schnellere Festplatten beschleunigen. Solche Server funktionieren problemlos, sind nach Bedarf auf geänderte Anforderungen anpassbar und beeinflussen fremde Projekte nicht.

Was passiert, wenn ein solcher spezifischer Server ausfällt? Andere Build-Systeme könnten als Fallback dienen, müssen allerdings meist um die bisher nicht benötigten Tools und deren Konfiguration ergänzt werden. Abgesehen davon, dass man unter einem wahrscheinlich höheren Zeitdruck steht, kann man nur schlecht abschätzen, ob die zwei auf einem Server vereinten Build-Systeme miteinander harmonieren.

Projektspezifische Build-Images

Mit Docker hat man die Chance, gemeinsam nur einen Server zu nutzen, ohne die Kapselung eines individuellen Build-Systems aufzugeben: Dazu kann jedes Projekt ein Docker-Image definieren, das sogar in Form eines Dockerfiles [4] direkt neben dem Sourcecode liegen kann. Im Projekt findet man also eine vollständige Beschreibung des für einen erfolgreichen Bui...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang