Docker Container für IoT

17. November 2017
0
, , , , ,

Wie automatisiere ich das Bauen von Docker Container für IoT-Geräte mit unterschiedlicher Prozessorarchitektur?

Das war die Frage, die ich mich kürzlich beschäftigt hat.

Für ein IoT Projekt sollen Microservices für verschiedene Prozessorarchitekturen (x86, ARM) gebaut werden. Die Artefakte sollen Docker Container sein, welche mit derselben SCM (Release -) Version getagged werden.
Der Release soll in GitLab manuell angestossen werden. Dabei wird der Master-Branch verwendet.

Verwendete Technologien

Folgende Technologien wurden für das Projekt definiert:

  • CI Umgebung: GitLab
  • Buildtool: Gradle

Gradle Integration

Bei der Suche nach geeigneten Gradle-Plugins stiess ich auf eine hohe Anzahl von Plugins, welche mehr oder weniger ähnliche Funktionalität hatten. Schliesslich waren Popularität, Dokumentation, Anzahl Contributors und Aktivität ausschlaggebend für die Wahl folgender Opensource Plugins, welche die funktionalen Kriterien erfüllen.
• Gradle Docker Plugin von bmuschko[1]  für das Bauen, Taggen und Pushen der Container.
• Gradle Release Plugin von researchgate[2]  für das automatisierte Taggen eines Releases in Git.

Build-Prozess

Der Release Prozess wird manuell in GitLab UI angestossen.
Schematischer Ablauf (sequentiell):

  1. Start Release in GitLab UI
  2. Service wird kompiliert, Unit- und Integrationstests durchgeführt und gebaut
  3. Dockerfile für x86 wird erzeugt (Gradle Task)
  4. Docker-Image für x86 wird gebaut (Gradle Task)
  5. Docker-Image für x86 wird getaggt (Gradle Task)
  6. Docker-Image für x86 wird ins Docker-Repository hochgeladen (Gradle Task)
  7. Dockerfile für ARM wird erzeugt (Gradle Task)
  8. Docker-Image für ARM wird gebaut (Gradle Task)
  9. Docker-Image für ARM wird getaggt (Gradle Task)
  10. Docker-Image für ARM wird ins Docker-Repository hochgeladen (Gradle Task)
  11. Release wird getaggt in SCM (Gradle Task)
  12. Release-Nummer wird erhöht und committed (Gradle Task)

Build Prozess

Definition des Builds mit allen Tasks und Abhängigkeiten

Vereinfachtes gradle.build


    Die Variable “version” wird direkt aus dem gradle.properties file gelesen.

Fazit

Die verwendeten Technologien arbeiten Hand in Hand zusammen, wobei Gradle den Build Prozess orchestriert, Git sich um die Versionierung kümmert und Docker die Plattform bietet, um verschiedene Prozessorarchitekturen zu unterstützen.

Zu beachten gilt, dass das Pushen von Images und das Tagging des Releases nicht transaktional abläuft. Es könnte sich also ergeben, dass ein Image bereits ins Docker-Repository hochgeladen wurde und der SCM Release anschliessend fehlschlägt. Dies war im Projekt insofern kein Problem, da beim Retry einfach das Image überschrieben wird und sich inhaltlich keine Änderungen ergeben.

Links

https://github.com/bmuschko/gradle-docker-plugin [1]
https://github.com/researchgate/gradle-release [2]
https://gradle.org/
https://about.gitlab.com/
https://www.docker.com/

 

Git-Argumentarium

08. November 2017
0
, ,

Es gehört heutzutage für Software-Entwickler zum guten Ton, ein verteiltes Versionsverwaltungssystem, wie zum Beispiel Git, zu verwenden 1. Auch dieser Artikel wird nicht an der Tatsache rütteln, dass Git zu Recht zum etablierten Industriestandard gehört. Doch nicht alle Unternehmen sind gleich schnell im Übernehmen von Standards. Und so findet sich mancher Projektleiter in der Situation wieder, dass ein Auftraggeber noch ein älteres Versionsverwaltungssystem einsetzt. Dieser Artikel soll ein Argumentarium bieten, Entscheidungsträger vom Nutzen von Git zu überzeugen.

Zunächst wird die Funktionsweise von Git in groben Zügen erklärt, dann werden Argumente aus verschiedenen Ebenen dargelegt, die für Git als Versionsverwaltungssystem sprechen.

Funktionsweise


Ein wichtiges Konzept von Git sind Branches (Zweige). Ein Branch teilt eine Entwicklungslinie in zwei Linien auf.  Änderungen in einem Branch sind immer lokal und für andere Branches nicht sichtbar. Erst durch das Zusammenführen, Mergen, übernimmt man Änderungen von einem Branch in den anderen Branch. Das Mergen ist eine Operation mit definierter Quelle und Ziel. Wenn der Entwickler zum ersten Mal ein Repository herunterlädt, nennt sich die Operation “clone”. Git ist dezentral konzipiert (jeder kann mit jedem Repository synchronisieren), dennoch setzt man Git üblicherweise so auf, dass ein gemeinsames, zentrales “shared repository” definiert wird, über das sich alle synchronisieren. Ein Benutzer kann nun von einem Repository die neuesten Änderungen beziehen (Operation “pull”), oder publizieren (“push”). Ein Benutzer pflegt Änderungen im lokalen Repository mit “commit” ein, erst durch den “push” sehen andere Benutzer diese Änderung.

Technische Argumente

Git setzt auf eine dezentrale Architektur. Das bedeutet, dass jeder Benutzer eines Repositories immer das komplette Repository klont, und nicht nur Teilbereiche des Repositories. Somit kann der Benutzer die meisten seiner Aufgaben offline erledigen, mit wenigen Ausnahmen (Git Pull und Push). Git ist für die meisten Operationen schnell, gerade dadurch, dass alle Dateien lokal verfügbar sind. Git stellt auch die Datenintegrität sicher: Jeder Versionsstand ist eindeutig anhand der Checksumme der Dateien identifizierbar. Ein Angreifer kann nur mit einem immensen Aufwand die Dateien in Git manipulieren ohne die Checksumme zu verändern. Wie könnte ein Angreifer Erfolg haben? Git verwendet SHA-1 und Google hat im Februar 2017 die erste SHA-1 Hash-Kollision publiziert, welche 6500 Jahre CPU-Zeit für die Berechnung erforderte 2. Doch für diese Schwachstelle wird das Git-Projekt bestimmt eine Lösung finden, um die Datenintegrität wieder voll zu gewährleisten.

Prozessorientierte Argumente

Git unterstützt parallele Entwicklungsprozesse. Die Parallelität gilt nicht nur für das ganze Entwicklungs-Team sondern auch für den einzelnen Entwickler. So kann der Entwickler eine Arbeit beginnen, bei Unklarheiten oder Abhängigkeiten pausieren, ohne den Arbeitsstand zu verlieren, und später wieder fortsetzen. Git schreibt keinen Entwicklungsprozess oder Arbeitsfluss (work flow) vor, sondern lässt dem Benutzer die Wahl bei Branching-Modell, Release-Nummerierung, Code-Review etc. Dennoch lässt sich sagen, dass Git gerade auch ideal für die iterative Entwicklung ist.

Da sich Features mithilfe von Branches als “Pakete” schnüren lassen, die für den nächsten Release an- oder deaktivieren lassen, sind kontrollier- und steuerbare Releases möglich. Der Entwickler und der Projektleiter haben im Vergleich zu anderen Versionsverwaltungssystemen oftmals eine bessere Übersicht von relevanten Änderungen und neu hinzugekommenen Features.

Bei der Analyse des bestehenden Entwicklungsprozesses kann unter Umständen auffallen, dass dieser mangelhaft ist, gerade auch durch die beschränkten Möglichkeiten des bestehenden Versionsverwaltungssystems. Ein Beispiel sind Arbeitsabläufe, bei welchen die Erweiterung und der Unterhalt von Software in einer einzigen Entwicklungslinie vermischt sind. In solchen Fällen muss zum Ziel gesetzt werden, einen besseren Entwicklungsprozess zu erarbeiten, der mit Git ermöglicht wird. Somit werden Entwickler und Projektleiter mit Git befähigt, den Entwicklungsprozess umzusetzen, der für das jeweilige Projekt am sinnvollsten ist.

Betriebswirtschaftliche Argumente

Gerade aus den Argumenten der Prozesssicht resultiert eine erhöhte Arbeitseffizienz und somit tiefere Entwicklungskosten. Unternehmen, die eine Umstellung von anderen Versionsverwaltungssystemen zu Git vornehmen, müssen einen einmaligen Migrations- und Schulungsaufwand gegenrechnen. Durch die höhere Effizienz ergibt sich aber auch ein schnelleres Time-To-Market für neue Features eines Software-Projekts. Durch die erhöhte Steuerbarkeit von Releases ergibt sich auch eine höhere Produktqualität.

Alleinstellungsmerkmale

Es gibt noch andere verteilte Versionsverwaltungssysteme als Git. Da gibt es zum Beispiel auch Mercurial, das ebenfalls dezentral ist und einen ähnlichen Funktionsumfang aufweist. Doch Git geniesst bei Software-Entwicklern eine ungeschlagene Popularität. Da Git einiges im Entwickleralltag vereinfacht und fast alles richtig macht, hat dieses Werkzeug auch eine hohe Akzeptanz.

Technische Limitationen

Es gibt auch Limitationen bei Git, doch damit kann man sich leicht arrangieren. Git verwaltet nur Dateien und keine leeren Ordner. Ordner werden in Abhängigkeit von benötigten Dateipfaden erstellt. Git ist darauf optimiert, sehr viele kleine bis mittelgrosse Dateien in mehreren Branches zu verwalten. Die derzeitige empfohlenen Maximalgrössen sind: 100MB pro Datei, 1GB pro Repository 3. Für grössere Dateien empfehlen sich Erweiterungen wie zum Beispiel Git LFS. Git unterstützt aufgrund der dezentralen Architektur folgerichtig kein Locking. Niemand kann ein exklusives Schreibrecht auf Dateien verlangen. Git kennt von Haus aus keine Zugriffsrechte. Der Zugriff wird mit SSH oder HTTPS-Login geregelt. Sobald es um individuelle Lese- und Schreibrechte geht, sollten Anbieter (GitHub, Microsoft TFS) oder Erweiterungen geprüft werden. 4

Weiteres

Wurde der Entscheidungsträger vom Nutzen von Git überzeugt, sollten Sie einige Dinge beachten und planen:

  • Wählen Sie ein Git-GUI (SmartGit, SourceTree, etc.)
  • Bestimmen Sie die Repository-Location (GitHub, TFS, On Premises)
  • Migrieren Sie das Versionsverwaltungssystem zu Git
  • Schulen Sie die Mitarbeiter
  • Definieren Sie ein Branching-Modell

Quellen

  1. https://www.atlassian.com/blog/archives/dont-move-to-git
  2. https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
  3. https://help.github.com/articles/what-is-my-disk-quota/
  4. http://www.peterlundgren.com/blog/on-gits-shortcomings/
  5. https://git-scm.com/about
‹ Previous1234567Next ›Last »

Tag Cloud

.NET android Angular Js AngularJs app Arduino ASP.Net automated testing Azure C# C++ Cloud continuous integration Elm gRPC HTML5 Internet of Things IoT Java Javascript M2M Matlab MVC OWASP protobuf Raspberry Pi Reactive Programming REST Scrum Security Softwarequalität SPA Testen testing Testmanagement Teststrategie UX Visual Studio WebAPI windows windows phone 8 WPF Xamarin Xamarin.Android Xamarin.Forms

Archive

Current Posts

Last Comments

Popular Posts

Xamarin.Android Code Obfuscation

6 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 1 - Aufbruch

5 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 2 - Kein Picknick

4 Comments

Contact us

  1. Name *
    * Please enter your name
  2. Email *
    * Please enter a valid email address
  3. Message *
    * Please enter message
© 2013 NOSER ENGINEERING AG. All rights reserved.