Die Annahme sollte davon ausgehen , dass Sie selten eine Anwendung von Grund auf neu aufbauen . Diejenigen , die mit der Entwicklung von Containern betraut sind , nutzen immer mehr den Code von Drittanbietern ( OPC ), weil dies viel produktiver ist . Allerdings bringt dies Probleme mit dem Lebenszyklus des Containers mit sich , wenn man bedenkt , dass nicht viele Abhängigkeiten verfolgt werden .
Dies ist ein ziemlich offensichtliches Problem , das gelöst werden muss . Wenn es eine Phase gibt , in der Entwickler nach vorgefertigten Container-Images suchen und diese nutzen , müssen Sie herausfinden , wo Sie diese speichern und von wo aus Sie auf sie zugreifen können , um die Nachverfolgung zu vereinfachen .
Sie können eine Kopie des verwendeten Basisimages sowie Ihre Imageerweiterungen in einem privaten Repository speichern . Der Vorteil dabei ist , dass Sie eine Originalkopie des Images beibehalten , auf der Ihre angepasste Imageversion basiert . Außerdem speichern Sie das angepasste Image wieder im selben privaten Repository . Diese Vorgehensweise schützt zwar vor Änderungen am öffentlichen Image , von dem Sie jetzt abhängig sind – Änderungen , die Ihre containerbasierte Anwendung beschädigen könnten –, aber Sie werden nicht in den Genuss der Vorteile von Upgrades und Fehlerkorrekturen am ursprünglichen Image kommen .
Die Antwort darauf ist ein containerorientiertes Konfigurationsmanagementsystem . Obwohl traditionelle Tools an das Management von Container-Images angepasst werden können , gibt es jedoch einige Einschränkungen . Aktuell ist es am sinnvollsten , sich mit Ihrem derzeitigen Anbieter von Konfigurationsmanagementlösungen auszutauschen , um zu verstehen , wie vorhandene Tools am besten für das Management von containerbasierten Anwendungen genutzt werden können . Im kommenden Jahr müssen Sie allerdings darauf vorbereitet sein , neben Ihrem bestehenden Pool aus Anbietern von DevOps-Tools nach besseren Tools zu suchen .
Testen von Containern
Es gibt viele Ansätze , um Container zu testen . Dabei muss jedoch bedacht werden , dass die Automatisierung von Containertests unabhängig vom gewählten Ansatz entscheidend ist .
Mit Containern können Sie die Testautomatisierung intern oder extern vornehmen . Suchen Sie nach wiederholt einsetzbaren Testumgebungen , in denen Sie denselben Test mit denselben automatisierten Testtools durchführen können . Das bedeutet , dass das Testen Teil von Continuous Integration Tooling , Staging Tooling und Deployment Tooling ist . Auf diese Weise wird das Testen systemischer Natur sein , sobald ein Entwickler testbereit ist . Dies erstreckt sich dann bis hin zur Einsatzbereitschaft in der Produktionsumgebung .
Bei diesem containerinternen Ansatz zum Testen von Containern sind die Testtools Teil des Images . Dadurch werden sie automatisch konfiguriert .
Mit dem containerexternen Ansatz können Sie spezielle Integrationstest-Container erstellen . Diese Container enthalten nur Testtools und Testartefakte wie Testskripte , Testdaten und die Konfiguration der Testumgebung . Diese Container sind zwar selbst Container , werden aber nicht Teil des Container-Images für die Produktionsumgebung und beeinflussen somit weder die Imagegröße noch das Leistungsverhalten . Sie werden jedoch nicht automatisch konfiguriert und müssen entsprechend der jeweiligen Testaufgaben eingerichtet werden .
46 | THE DOPPLER | Herbst 2017