Docker: “Build, Ship, and Run …”, Continuously wird gelebt. Der Sprung von Build zu Ship sieht ziemlich einfach aus. Doch bei Docker weiss man, dass er halt doch nicht so einfach ist: Bevor ein Container geshipped werden kann, müssen Tests durchgeführt werden.

Doch – allgemein gesagt eine Software im Container – behauptet den Prozess von Continuous-Delivery/-Integration (CD/CI) zu optimieren, indem Risiken bei der Verteilung reduziert werden, da die Infrastruktur als einziges Stück Code wahrgenommen wird (Infrastructure as Software).

Um dieses Continuous Delivery (CD) erreichen zu können – es wird Software erstellt, die zu jedem Zeitpunkt produktiv geschaltet werden kann -, muss ein Continuous-Integration (CI) Prozess etabliert werden. Dieser ist für Integration, Entwicklung und Testing des Codes zuständig. Zudem ist eine Deployment Pipeline (DP) erforderlich, bei der jede Änderung durch diese geschickt wird und automatisch in der Produktion ihre Anwendung findet. Dadurch werden mehrere Deployments pro Tag möglich. Continuous Delivery (CI) bedeutet also, dass man viele Deployments durchführen kann und in der Lage ist auszuwählen, wenn man es nicht tun möchte. Letztgenanntes zum Beispiel dann, wenn die Stabilität des Business eine hohe Priorität geniesst.

Mit konkretem Blick auf Docket stellen sich die Fragen, was soll getestet werden? Wo? Wie? Dieser Artikel skizziert zu diesem Zweck eine Test-Strategie und stellt einige Tools vor, die bei einer Umsetzung helfen können.

Einige Docker Begriffe

Fassen wir die Begrifflichkeiten des Docker-Ökosystems kurz zusammen:

• Docker Host: Führt den Docker-Daemon aus, welcher für die aufwändigen Arbeiten zuständig ist. Dazu gehören das Erstellen, Ausführen und Verteilen der Docker Container.
• Docker File: Ein Docker File ist ein Textdokument, das alle Kommandos beinhaltet, die im Rahmen einer manuellen Erstellung eines Docker-Images erforderlich sind. Docker kann Images automatisch erstellen, indem das Docker File eingelesen und ausgeführt wird.
• Docker Image: Docker Images sind der Grundbaustein der Container. Ein Image beinhaltet die Struktur des grundlegenden Dateisystems und die für die Ausführung erforderlichen Parameter. Ein Image setzt in der Regel auf eine Vereinheitlichung von Dateisystemen, die übereinander gelegt werden (stacked). Das Image ist statuslos und ändert sich nie.
• Docker Container: Ein Container ist eine ausgeführte Instanz eines Docker Image. Ein Docker Container besteht aus einem Image, der Ausführumgebung und einer Basis von Anweisungen.

Test-Strategie

Nachdem Klarheit über die einzelnen Komponenten der Docker-Familie geschaffen werden konnte, können wir die Möglichkeiten des Security Testings besprechen.

Die folgende Tabelle skizziert die angestrebte Test-Strategie:

Test Tools

Um den Grundsatz von Continuous aufrecht zu erhalten, müssen die Tests in den einzelnen Pipelines integriert werden: Es darf keine manuelle Interaktion erforderlich sein.

Nachfolgend eine Liste von Tools, die sich dafür anbieten:

Zusammenfassung

Das Ökosystem von Docker ist relativ neu und befindet sich in stetigem Wandel. Testing ist dabei nur ein kleiner Teil des Gesamten; viele andere Faktoren müssen ebenfalls berücksichtigt und mit dem richtigen Werkzeug angegangen werden. Der Ansatz für das Testing und das Ziel dessen sind klar, wobei die Integration in den CD/CI-Prozess individuell angepasst auf die Bedürfnisse der vorliegenden Architektur stattzufinden hat.

Über den Autor

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.

Links

• https://github.com/coreos/clair
• https://github.com/docker/docker-bench-security
• https://www.aquasec.com/
• https://www.open-scap.org/
• https://www.twistlock.com/