News

Das Neuste aus der Welt von Adfinis SyGroup

Jitsi, einfache Videokonferenzlösung

1. March 2018

Jitsi ist eine einfache Videokonferenzlösung, die sich selber hosten lässt. Dabei beziehe ich mich spezifisch auf das Produkt Jitsi Meet, welche jitsi-videobridge und jicofo beinhaltet. Es werden technologien, wie webrtc und libjitsi verwendet. Damit bietet Jitsi eine Open Source Alternative zu anderen Videokonferenzlösungen, wie z.B. Google Hangouts oder Skype. Jitsi ist eine Open Source Community, welche von der Firma Atlassian unterstützt wird.

Für Firmen, die noch eine Videokonferenzlösung suchen, aber jedoch eher weniger an “Skype for Business” oder allgemein proprietären Lösungen interessiert sind, ist dies eine praktische und kostengünstige Lösung, die man als Firma in Erwägung ziehen sollte.

Dadurch, dass Jitsi webbasiert ist, können z.B. Kunden schneller und praktischer mit Ihnen in Verbindung treten um ein Meeting oder eine Präsentation durch zu führen.

Interface Überblick

Um eine Videokonferenz mit Jitsi zu starten, kann einfach der Name der Videokonferenz nach der URL eingegeben werden, z.B. meet.example.com/brucewayneisbatman.

Der Konferenzraum wird im Browser sofort geöffnet. Alternativ hat Jitsi eine Startseite, bei welcher man einen Konferenzraum öffnen kann. Hier das Interface einer Videokonferenz.

Das Interface ist vergleichbar mit Google Hangouts und daher sehr familiär. Auf der linken Seite ist eine Bar. Hier bieten sich verschiedene Funktionen an, wie

  • Chat
  • Konferenz mit einem Passwort schützen
  • Profilbild (Gravatar ist möglich)
  • Handzeichen (man erkennt damit, dass man etwas sagen möchte)

Desktop sharing

Ab Firefox Version 52 ist es möglich den Desktop zu sharen ohne ein extra Plugin zu verwenden. Dafür braucht es auf dem Server folgende Einstellung in der Konfigurationsdatei (/etc/jitsi/meet/DOMAIN-config.js) :

desktopSharingFirefoxDisabled: false, desktopSharingFirefoxMaxVersionExtRequired: 51,

Für den Chrome Browser muss zuerst ein eigenes Plugin gebaut werden. Hier ist eine Anleitung zum Bauen des Chrome Plugins. Das Plugin kann dann per drag & drop bei anderen Clients installiert werden.

Kurzinstallation für Debian/Ubuntu

Du willst gleich durchstarten? There you go!

$ wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add - $ sudo sh -c "echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list" $ sudo apt-get -y update $ sudo apt-get -y install jitsi-meet

Aktuelle Probleme

In der Testphase ist aufgefallen, dass manchmal die Verbindung bei Clients abgebrochen wird und es dann unmöglich ist eine Konferenz zu halten. Der Grund dafür war, dass der automatische Health Check alle verfügbaren File Descriptors aufbrauchte und diese nicht mehr sauber aufgeräumte. Hier das beschriebene Problem auf GitHub:

https://github.com/jitsi/jitsi-meet/issues/1231

Die Lösung dazu ist, in der Datei /etc/jitsi/jicofo/sip-communicator.properties folgendes einzufügen um den Health Check zu deaktiveren:

org.jitsi.jicofo.HEALTH_CHECK_INTERVAL=-1

Links

Mailserver Security

15. February 2018

Wenn es um SSL/TLS Konfigurationen geht, rücken Mailserver weniger schnell in den Blickpunkt als Webserver. Auch diese sollten eine solide SSL/TLS-Konfiguration mit gültigen Zertifikaten geniessen. In den Protokollen IMAP und POP3 fallen komplett falsch konfigurierte Mailserver schnell auf, in der Server-Server-Kommunikation jedoch sind oft unzureichende Standards gesetzt. Des Öfteren werden ungültige oder gar keine Zertifikate akzeptiert, da eine Verbindung wichtiger ist, als die Sicherheit.

SSL/TLS Konfiguration bei Postfix

Folgend ein Auszug aus der Postfix (htt Main Configuration, welcher sich allerdings jederzeit ändern kann. Sehr wichtige Optionen sind smtpd_tls_security_level und smtp_tls_security_level, welche standardmässig “none” sind. Das bedeutet, dass der Server nie TLS verwenden wird. Daher sollten diese Optionen immer auf may oder encrypt gesetzt werden

# TLS parameters
tls_high_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!MEDIUM:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_medium_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_low_cipherlist = !aNULL:ALL:!EXPORT:!DES:!3DES:!MD5:!RC4:@STRENGTH smtpd_tls_cert_file = /etc/postfix/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/postfix/ssl-cert-snakeoil.key smtpd_tls_auth_only = yes
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_ciphers = medium
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_dh1024_param_file = /etc/postfix/dh4096.pem
smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtpd_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtp_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

 

SSL/TLS Konfiguration bei Dovecot

Dies ist ein Auszug aus der Dovecot Configuration und zeigt eine mögliche Konfiguration der SSL/TLS-Parameter für Dovecot auf.

# DH parameters length to use. ssl_dh_parameters_length = 4096   # SSL protocols to use. ssl_protocols = !SSLv2 !SSLv3   # SSL ciphers to use ssl_cipher_list = ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS   # Prefer the server's order of ciphers over client's. ssl_prefer_server_ciphers = yes

Sender Policy Framework (SPF)

Mit Hilfe von SPF (RFC 7208) kann validiert werden, ob ein Server, welcher eine E-Mail zustellen will, auch berechtigt ist von der entsprechenden Domain E-Mails zu versenden.

Beispielsweise baut der Server smtp.send.example.com eine Verbindung zum Server smtp.recv.example.com auf und versucht ihm eine E-Mail von user@mail.example.com zuzustellen. Anhand von SPF kann der Server smtp.recv.example.com überprüfen, ob der Server smtp.send.example.com ein gültiger E-Mail-Server für die Domain mail.example.com ist.

Der entsprechende SPF Record existiert im DNS-System und kann in etwa wie folgt aussehen:

mail.example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::1 a ~all"

Das heisst wenn eine der folgenden Bedingungen erfüllt ist, wird die E-Mail angenommen:

    • die IP Adresse des Servers smtp.send.example.com innerhalb von 192.0.2.0/24 oder 2001:db8::1 liegt
    • der DNS A Record mail.example.com der IP Adresse des Servers smtp.send.example.com entspricht

In allen anderen Fällen muss die E-Mail weitere Checks durchlaufen (welche selber definiert werden können).

DomainKeys Identified Mail (DKIM) Signaturen

Die Idee hinter DomainKeys Identified Mail (DKIM, RFC 6376) ist, zu prüfen, dass eine E-Mail während des Transports nicht verändert wurde. Um dies sicherzustellen, werden die Header, der Content und die Attachments einer E-Mail signiert. Dabei wird jedoch nicht der gesamte Header signiert, da sich dort beim Transport einer E-Mail gewisse Felder ändern können. Das RFC schlägt vor, folgende Werte zu signieren:

  • From (REQUIRED)
  • Reply-To
  • Subject
  • Date
  • To, Cc
  • Resent-Date, Resent-From, Resent-To, Resent-Cc
  • In-Reply-To, References
  • List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive

DKIM-Signaturen werden im Header einer E-Mail abgelegt, das Feld nennt sich DKIM-Signature. Der Wert dieses Feldes beinhaltet mehrere Key-Value-Paare. Die Wichtigsten sind:

  • v: DKIM version
  • a: algorithm (e.g. rsa-sha256)
  • d: signing domain (origin Domain)
  • s: selector

Ein empfangender E-Mail-Server kann anhand der Domain und des Selectors den aktuellen Domain Key über DNS anfragen. Der DNS-Eintrag sieht in etwa wie folgt aus:

selector._domainkey.example.com IN TXT ( "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB" )

Wird also eine E-Mail mit dem Header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.org; s=mail; t=1498137281; bh=ClzbA4T6yvpEouOct2aSAnFWcEUHTr6SDxrQizAy6ao=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=QTY/4jFXMH2piHJ478mtyQ6heutdCLw/VCrD3XcDVugITPSXnrEqiV07+N9YNQcTraCmyxT49upd8uz9fqRLz0VTZWoPF3+9eT9X2jdQU/1WpVtalFrQuBoXfzy4KZJdxp/DjwAB89CkmvRvv5aYSw0XrJsry1uMoVJx6NDCskA=

empfangen, so ist der entsprechende TXT-DNS-Eintrag, welcher den Key referenziert, “mail._domainkey.example.org“.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) erweitert die beiden Mechanismen DKIM und SPF. Wenn kein DKIM Header vorhanden ist oder kein SPF Record gefunden wird, wird bei diesen beiden Verfahren nichts gemacht und die E-Mail normal behandelt. DMARC bietet die Möglichkeit, zu sagen, was mit einer E-Mail, bei der eines oder beide Verfahren nicht vorhanden sind, gemacht werden soll. DMARC ist auch ein bisschen strikter, was das DKIM Handling angeht, so muss z.B. die From-Adresse mit der Domain im DKIM-Signature Feld übereinstimmen. Ein weiterer Punkt, den DMARC ermöglicht, ist das Reporting von falsch verschickten E-Mails. So können Reports von empfangenden E-Mail-Servern angefordert werden.

Wie auch DKIM wird DMARC im DNS publiziert. Ein möglicher Eintrag sieht in etwa wie folgt aus:

_dmarc.example.com IN TXT "v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com"

Wobei die einzelnen Werte folgende Bedeutung haben:

  • v: Version
  • p: Policy für diese Domain
  • sp: Policy für Subdomains
  • pct: Prozent der “schlechten” E-Mails, ab wann die Policy greifen soll
  • rua: DMARC Report URI Adresse

Testen

Manuell kann mit openssl getestet werden. Dies sind nur Basis-Befehle, welche den Inhalt des Server-Zertifikates in Textform darstellen. Es können auch Cipher-Suites getestet werden, da dies aber lange und vielzählige Commands sind, wird empfohlen, dies mit den vorhandenen Diensten (bspw. Hardenize) zu machen. Ist dies nicht gewünscht oder technisch nicht möglich, kann SSL Decoder auch lokal installiert werden, da die Software Open Source auf GitHub verfügbar ist.

  • SMTP
$ openssl s_client -connect example.com:25 -starttls smtp 2>/dev/null </dev/zero | openssl x509 -noout -text

 

  • IMAP
$ openssl s_client -connect example.com:143 -starttls imap 2>/dev/null </dev/zero | openssl x509 -noout -text

Zusätzliche Features wie SPF oder DMARC zu testen, kann zum einen sehr simpel gemacht werden, indem einfach die DNS Records überprüft werden:

# SPF Record $ dig +short TXT example.com "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::1 a ~all" # DKIM $ dig +short TXT mail._domainkey.example.com "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB"   # DMARC $ dig +short TXT _dmarc.example.com "v=DMARC1; p=reject; rua=mailto:mailauth-reports@example.com"

Um umfassendere Tests mit einer Auswertung des Inhalts zu machen, eignen sich diverse Anbieter, wie z.B. Hardenize oder MX Toolbox.

Weiterführendes

Des Weiteren ist anzumerken, dass DNS-based Authentication of Named Entities (DANE) auch bei E-Mail-Servern eingesetzt werden kann. Dies sprengt aber den Rahmen dieses Blog-Posts und wird in einem anderen behandelt werden. Es gibt auch sehr gute HowTo-Guides für E-Mail-Server, hier sollen die folgenden zwei genannt werden:

Links

 

Pyark – CyberArk Enterprise Password Vault CLI Tool

12. December 2017

Diverse Firmen setzen zur Zeit auf die proprietäre Enterprise Password Vault von CyberArk um sensitive Zugangsdaten, Zertifikate und SSH-Schlüssel sicher zu verwalten. Die Software ermöglicht es über ein Webinterface bspw. Benutzername und Passwort einer Applikation zu hinterlegen.

Sensitive Daten manuell via Webinterface abzulegen ist jedoch in der heutigen Zeit, wo Automation, Provisioning und Configuration Management zu den Grundpfeilern jeder optimierten IT-Infrastruktur gehört, kein gangbarer Weg mehr.

Entsprechend gehören saubere APIs auch zum “state of the art” jeder grösseren Webapplikation. Denn ohne API lassen sich viele Prozesse überhaupt nicht automatisieren und optimieren.

Auch die Password Vault von CyberArk ermöglicht es gewisse Abläufe via API zu tätigen. Jedoch ist die API qualitativ nicht so weit wie man sich dies gern wünschte und diverse API Endpunkte sind noch nicht verfügbar. Das Verwalten von Accounts funktioniert jedoch soweit schon einwandfrei, womit bspw. Credentials während einer OS-Installation problemlos automatisch im digitalen Tresor abgelegt werden können.

Hierzu haben wir das CLI Tool Pyark geschrieben, welches auf GitHub unter der GPLv3 frei zur Verfügung steht.

Pyark

Pyark ist ein python-basiertes Utility, welches die Interaktion mit der Password Vault API vereinfacht. Das Tool lässt sich leicht in bestehende Prozesse integrieren und nimmt einem mühsame curl-Basteleien ab.

Ein möglicher Anwendungsfall ist das Ablegen des root-Passworts während der automatisierten Installation einer Linux Distribution. Bei Distributionen der Red Hat Familie kann das Script bspw. als Kickstart Post-Task ausgeführt werden um das root-Passwort sicher zu verwahren.

An dieser Stelle fragt man sich ggf. wieso hierzu überhaupt ein weiteres Tool notwendig sei, hierzu gibt es doch curl und Konsorten? Das Problem lässt sich leider nicht mit einem curl-Einzeiler beheben, denn die API ist so aufgebaut, dass zuerst die Authentisierung durchgeführt werden muss. D.h. in einem ersten Schritt wird der Benutzername und das Passwort des Service Accounts an die API gesendet. Authentifiziert CyberArk den Benutzer erfolgreich erhält man im HTTP Header CyberArkLogonResult ein Token zurück. Dieses Token muss für alle folgenden Anfragen verwenden werden. Somit müssen etwaige Fehler oder Authentisierungs-Probleme sauber abgefangen und auch das Token aus dem HTTP Header extrahiert werden, was mit curl nicht ganz trivial ist.

Zur Zeit unterstützt Pyark folgende Funktionen:

  • Accounts auslesen
  • Accounts erstellen
  • Accounts löschen

Dabei ist zu beachten, dass eine aktuelle Version der Password Vault installiert sein muss. Andernfalls besteht die Möglichkeit, dass die entsprechenden API-Endpunkte noch nicht integriert wurden. Hierzu verlangt man am besten vom Hersteller die passende API-Referenz Dokumentation und prüft, ob die Entpunkte vorhanden sind.

Installation

Die Installation ist soweit sehr simpel. Es kann wahlweise das GitHub Repository geklont und setup.py ausgeführt werden oder es wird mit pip install pyark direkt aus dem Internet installiert. Bei Bedarf kann natürlich auch nur das __init__.py kopiert und ausgeführt werden.

Beispiele

Untenstehend drei Beispiele, wie ein Account ausgelesen, erstellt und gelöscht werden kann.

  • Account auslesen:
$ pyark --base https://vault.example.com \
        --apiuser foobar                 \
        --apipassword supersecret42      \
        account get                      \
        --safe MySafe                    \
        --keywords bruce
  • Account erstellen:
$ pyark --base https://vault.example.com \
        --apiuser foobar                 \
        --apipassword supersecret42      \
        account create                   \
        --safe MySafe                    \
        --platformid TestPlatform        \
        --accountname brucewayne         \
        --address batcave.example.com    \
        --username brucew                \
        --password d4rkkn1ght
  • Account löschen:
$ pyark --base https://vault.example.com \
        --apiuser foobar                 \
        --apipassword supersecret42      \
        account delete                   \
        --safe MySafe                    \
        --accountname brucewayne         \
        --keywords bruce

MariaDB Galera Cluster auf Red Hat OpenShift/Kubernetes

23. November 2017

In diesem Blogpost stellen wir eine Lösung vor mit der ein MariaDB Galera Cluster auf Kubernetes oder kompatiblen Lösungen (z.B. Red Hat OpenShift Container Plattform, CoreOS Tectonic und Canonical’s Kubernetes) betrieben werden kann. Es ermöglicht damit cloud-native Applikationen, die in Kubernetes betrieben werden, und die Datenquellen, die benötigt werden, in der gleichen Infrastruktur zu betreiben und mit den gleichen Werkzeugen zu verwalten.

Die Funktionalität baut auf dem Feature PetSets von Kubernetes auf, eine API die für Stateful Applikationen gedacht ist.

Was sind PetSets

Kubernetes hat sich im Lauf der letzten Jahre von einem neuen Tool für Container Management, zu dem Projekt entwickelt, welches in diesem Bereich den Ton und Takt vorgibt. Aufgrund der Architektur von Kubernetes war es bisher nur schwer möglich Applikationen und Services, die nicht stateless sind, darauf zu betreiben. Erste Ideen für so genannte “Nominal Services” wurden früh vorgeschlagen, aber aufgrund anderer Prioritäten nicht umgesetzt.

Mit dem Release von Kubernetes v1.3 gibt es nun eine erste Vorschau auf eine Lösung. Mit PetSets wurde in Kubernetes eine API im Alpha Status geschaffen, die spezifisch auf die Anforderungen von stateful Applikationen und Services zugeschnitten ist. Pods in einem PetSet erhalten einen eindeutigen Namen und numerischen Index (z.B. app-0, app-1, …), der über die Lebensdauer des Pods gleich bleibt. Zusätzlich bleiben auch Persistent Volumes dem Pod zugeordnet, auch wenn dieser auf einen anderen Host migriert wird. Da jedem PetSet ein Service zugeordnet wird, ist es möglich über Abfragen an den Service Informationen über die Pods des PetSets zu verarbeiten. Dies ermöglicht es z.B. das Bootstrapping eines Clusters zu automatisieren, oder die Konfiguration zur Laufzeit entsprechend anzupassen, sollte sich der Zustand des Clusters ändern (Scale Up, Scale Down, Wartung oder Ausfall eines Hosts, …).

Wie kann MariaDB Galera Cluster auf Kubernetes betrieben werden

Um ein MariaDB Galera Cluster auf Kubernetes zu betreiben ist es vor allem notwendig den Bootstrap des Clusters und die Anpassung der Konfiguration auf Basis der aktuellen Pods im PetSet zu implementieren. In unserem Fall werden diese beiden Aufgaben von zwei Init Containern übernommen. Im Docker Image galera-init sind die entsprechenden Tools verpackt um den Bootstrap durchzuführen, der zweite Container startet das Binary peer-finder welches den SRV Record des Kubernetes Services abfragt und auf Basis der Mitglieder des PetSets die Konfiguration für das MariaDB Galera Cluster generiert.

Beim Starten des ersten Pets wird wsrep_cluster_address=gcomm:// in der Konfiguration gesetzt und der Pod führt automatisch einen Bootstrap des Cluster durch. Alle weiteren Pets die gestartet werden, befüllen wsrep_cluster_address mit den Hostnamen aus dem SRV Record des Services, und treten automatisch dem bestehenden Cluster bei. Hier noch ein Beispiel der Konfiguration nach dem Starten des zweiten Pets:

wsrep_cluster_address=gcomm://mariadb-0.galera.lf2.svc.cluster.local,mariadb-1.galera.lf2.svc.cluster.local
wsrep_cluster_name=mariadb
wsrep_node_address=mariadb-1.galera.lf2.svc.cluster.local

Die entsprechenden Quellen um MariaDB Galera Cluster auf der eigenen Kubernetes oder Red Hat OSCP Infrastruktur zu testen sind auf Github veröffentlicht: https://github.com/adfinis-sygroup/openshift-mariadb-galera

Beschränkungen von PetSets im Alpha Status

Die Beschränkungen von PetSets im Alpha Status sind in der Kubernetes Dokumentation erläutert und betreffen diverse Bereiche, vor allem Tasks die manuell bearbeitet werden müssen. So ist es zum Beispiel nur möglich die Anzahl der Replikas über den Parameter replicas zu erhöhen, aber nicht möglich sie zu senken. Auch ein Update der PetSet Definition ist nicht automatisch möglich, daher muss ein Update auf eine neue Image Version manuell über ein neues PetSet gemacht werden.

Wie sieht die Zukunft von PetSets aus

Mit dem Release von Kubernetes v1.5 verlässt PetSets den Alpha Status und wird unter dem Namen StatefulSet in den Beta Status gehoben. Dies ist eine wichtige Entwicklung, da sich die externe API in Kubernetes nach dem Beta Status nicht mehr ändert. Der Release von Kubernetes v1.5 ist für den 9. Dezember 2016 geplant.

zukünftige Arbeiten

Ein weiterer Blogpost wird veröffentlicht sobald Kubernetes v1.5 released wurde. Dieser enthält Updates der YAML Definitionen und zusätzliche Anweisungen wie man MariaDB Galera Cluster auf seiner eigenen Infrastruktur testen kann.

Links

GitLab CI

10. September 2017

In diesem zweiteiligen Artikel werden wir die Continuous Integration Funktionalitäten von GitLab CI genauer unter die Lupe nehmen.

Der erste Teil widmet sich der Installation und Konfiguration, während der zweite Teil detaillierter auf einzelne Anwendungsszenarien eingehen wird.

Was ist CI überhaupt?

CI steht in diesem Fall für Continous Integration und bedeutet vereinfacht gesagt, dass nach jeder Änderung am Source Code eines Projektes ein Script ausgeführt wird.
Das CI-Script wird in den meisten Fällen über eine Versionsverwaltung getriggert. Dateien welche dieses Script erstellt, können später als sogenannte Build Artifacts weiterverwendet werden.

In vielen Fällen startet dieses Script Unit-Tests, welche überprüfen, ob die soeben gemachten Änderungen nicht unbeabsichtigt andere Teile des Projektes beeinflussen.
Unit-Tests sind jedoch nur ein Szenario, ein CI kann beispielsweise auch Pakete bauen, Dokumentationen erstellen oder sogar Anwendungen deployen.

GitLab CI

GitLab ist eine Open Source Lösung für Git-Hosting, die unter anderem auch CI-Funktionalität bietet. Seit Version 8.2 ist der CI-Teil fest in GitLab integriert und muss nicht mehr wie zuvor auf einem separaten Server installiert werden.

Das Konzept von GitLab CI basiert auf so genannten Runnern, welche die eigentlichen Build-Scripts ausführen. GitLab CI ist nur für das Orchestrieren dieser Runner und dem Zusammentragen von Resultaten und Artifacts zuständig. Runner können Docker-Container, VMs oder auch bare metal Maschinen sein, die optimalerweise nicht auf demselben Server wie der Orchestrator ausgeführt werden. Dadurch haben die CI-Scripte kein Zugriff auf GitLab selbst.

Die Runner melden sich alle paar Sekunden über HTTPS bei GitLab und fragen nach, ob es für sie einen Job gibt, GitLab CI kann die Runner von sich aus nicht kontaktieren.
Dies erleichtert die Einrichtung von neuen Runnern erheblich, einzige Voraussetzung ist, dass sich der Runner per HTTPS mit GitLab verbinden kann.

Die Runner-Komponente von GitLab nennt sich gitlab-ci-multi-runner [1] und ist ein statisch kompiliertes Binary, welches neben Linux auch Builds auf Windows, OSX und BSD unterstützt.

Das CI-Script für GitLab muss im Hauptverzeichnis des jeweiligen Repos liegen und den Dateinamen .gitlab-ci.yml haben.

CI für ein Projekt aktivieren

Seit Version 8.2 ist die CI-Komponente in GitLab integriert und standardmässig aktivert. Sie kann jedoch auch nur für einzelne Projekte aktiviert bzw. deaktiviert werden.
Die Einstellung nennt sich Builds und ist in den Projekteinstellungen unter Features zu finden:

GitLab löscht keine bereits ausgeführten Builds und Artifacts wenn das Feauture deaktiviert wird, sondern versteckt nur den Menüpunkt Builds.

Unter gitlab.example.com/group/repo/builds sind diese weiterhin einsehbar. Builds zu löschen ist über das Webinterface machbar. Seit GitLab 8.9 ist es möglich im .gitlab-ci.yml zu konfigurieren, wie lange die Resultate und Artifacts aufbewahrt werden. [2]

Runner

Setup

Nach dem Aktivieren von CI im Webinterface, muss ein Runner eingerichtet werden, welcher die effektiven Builds ausführt. In diesem Beispiel wird gitlab-ci-multi-runner auf einer Debian Jessie VM mit dem Docker-Executor eingerichtet. Im zweiten Teil dieses Artikels wird detaillierter auf weitere Runner-Konfigurationen eingegangen.

Als erster Schritt sollte das System aktualisiert werden:

# apt-get update
# apt-get upgrade

Da Docker-Runner verwendet werden, braucht es entsprechend Docker:

# curl -sSL https://get.docker.com/ | sh

GitLab stellt ein Script zur Verfügung, welches das Repository automatisch konfiguriert. Dies kann mit folgendem Kommando ausgeführt werden:

# curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash

Wer keine Scripte aus dem Internet unkontrolliert ausführen möchte, kann das Repo auch auf den traditionellen Weg aktivieren:

# echo "deb https://packages.gitlab.com/runner/gitlab-ci-multi-runner/debian/ jessie main" >> /etc/apt/sources.list
# wget -qO - https://packages.gitlab.com/gpg.key | apt-key add -
# apt-get update

Anschliessend kann gitlab-ci-multi-runner über APT installiert werden:

# apt-get install gitlab-ci-multi-runner

Dies richtet einen systemd-Dienst ein, welcher (auf Debian Systemen) per Default aktiviert und gestartet sein sollte:

# systemctl status gitlab-runner.service
● gitlab-runner.service - GitLab Runner
Loaded: loaded (/etc/systemd/system/gitlab-runner.service; enabled)
Active: active (running) since Mon 2016-09-19 18:33:32 CEST; 1 weeks 0 days ago
Main PID: 28102 (gitlab-ci-multi)
CGroup: /system.slice/gitlab-runner.service
└─28102 /usr/bin/gitlab-ci-multi-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog...

Der Runner ist nun bereit und kann in Projekten registriert und verwendet werden.

Runner registrieren

Der neu installierte Runner muss nun in GitLab registriert werden. Jedes Projekt hat hierzu ein eindeutiges Runner-Token, welches im Webinterface unter Project Settings > Runner eingesehen werden kann:

Mit diesem Token kann der zuvor eingerichtete Runner aktiviert werden. Dazu auf der Runner-VM folgendes Kommando eingeben:

# gitlab-ci-multi-runner register \
--url gitlab.example.com
--registration-token L4zpDbiAAA86sDnvYPkn \
--description "CI hello world" \
--executor "docker" \
--docker-image debian:jessie

Parameter:

  • --url GitLab CI URL
  • --registration-token Registration Token
  • --description Beschreibung des Runners
  • --executor Executor, in diesem Fall Docker
  • --docker-image Docker-Image, unter dem der Runner läuft. In diesem Beispiel wird ein Jessie-Container als Runner verwendet.

Der Runner sollte nach einigen Sekunden im Webinterface erscheinen:

.gitlab-ci.yml

Nachdem der Runner eingerichtet und registriert ist, muss das .gitlab-ci.yml im Hauptverzeichnis des Projektes erstellt werden. In unserem Beispiel wird nur eine Datei erstellt und getestet, ob diese vorhanden ist:

stages:
- test

run-test:
stage: test
script:
- touch foo
- test foo

Nach dem Commiten und Pushen sollte unter Builds bereits ein laufender Build erscheinen:

Der Build sollte bereits nach einigen Sekunden abgschlossen sein:

Ausblick

Im zweiten Teil werden wir detaillierter auf Real-Life Anwendungsszenarien eingehen und weitere Runner-Typen vorstellen.

Referenzen

  1. https://gitlab.com/gitlab-org/gitlab-ci-multi-runner
    ↩
  2. https://docs.gitlab.com/ce/ci/yaml/README.html#artifactsexpire_in ↩
Mehr laden