Archiv der Kategorie: Docker

Creating Docker Adapter Instance in vROps with vRO

Veröffentlicht am von
Das neue Docker Management Pack für vROps ermöglich die Einbindung von Docker-Metriken das Monitoring. Problematisch ist, dass für jeden Docker Host eine eigene Adapter-Instanz erstellt werden muss. Eine perfekte Gelegenheit um mal wieder den vRealize Orchestrator zum Einsatz zu bringen. vROps bietet ein REST-API. Hierzu findet sich unter https://<vrops host>/suite-api/docs/rest/index.html eine schöne Dokumentation. Screen Shot 2016-05-18 at 22.10.10   Download: vCO Workflow: CreateVropsDockerAdapterInstance

Docker Remote Management mit vRealize Orchestrator

Veröffentlicht am von
Docker oder Applikations- bzw. Containervirtualisierung erfreut sich quer durch alle Branchen und Unternehmensgrößen immer höherer Beliebtheit. Hat man nun vor Docker im größeren Stil z. B. im Enterprise zu nutzen (darüber lässt sich natürlich genüßlich streiten – Kommentar auf TheNewStack), so macht sich eine Orchestrierung der aufkommenden Verwaltungsaufgaben schnell bezahlt und letztendlich auch unerlässlich. Auf dem OpenSource-Markt gibt es einige Produkte zum Cluster-Management. Zu nennen wären hier Docker Swarm, Mesos oder Kubernetes bzw. alles zusammen im Photon Controller. Möchte man nun seine Container Hosts etwas freier betreiben oder z. B. in den Deployment-Prozess von vRealize Automation einbinden, bietet sich der vRealize Orchestrator an. Läuft ein Docker Container Host als VM z. B. mit Photon, so ergeben sich grundlegend drei Wege Docker Befehle gegen diesen Container Host auszuführen:
  • SSH, Authentifizierung per SSH, Ausführen der Aktionen über die docker CLI Pros: Linux native, keine weiteren Tools notwendig Cons: SSH offen (besonders in der DMZ problematisch), Rückgabewerte auswerten
  • VMware Tools (VMCI), Authentifizierung über das Host-Guest-Interface, Ausführen der Aktionen über die docker CLI Pros: keine Netzwerkverbindung nötig Cons: VMCI Modul in den VMware Tools als Sicherheitsrisiko, Rückgabewerte auswerten
  • Docker Remote API, Authentifizierung über Docker Daemon (Achtung: standardmäßig ist diese deaktiviert), REST-API Aufrufe Pros: standardisiertes API (REST), keine weiteren Tools notwendig Cons: exposed Port
Der wohl eleganteste Weg ist das Docker Remote API. Dieser Artikel beschreibt für Photon, wie man das Remote API freischaltet: http://the-virtualizer.com/2016/05/expose-docker-remote-api-on-photon/ Nun zur eigentlich Orchestrierung. Will man einen Docker Container nun über einen vRA-Request bereitstellen, so ist der vRO das Mittel der Wahl um den Docker Host anzusprechen und einen Container zu instanziieren. Möchte man gerne Docker Swarm einsetzen um die Aufgaben über mehrere Hosts eines Cluster zu verteilen, so sehen die Schritte analog aus, da das Swarm API an das Docker API angelehnt ist. Der folgende Workflow zeigt das Instanziieren und Starten eines Containers aus einem vorgegebenen Image anhand der Docker API: Screen Shot 2016-05-16 at 12.29.16   In dieser Variante akzeptiert dieser Workflow folgende Eingabe-Parameter: Screen Shot 2016-05-16 at 12.34.34 Dies kann belieb erweitert werden, z. B. um Port- und/oder Volumemappings. Dafür muss entsprechend der Payload für den Create Docker Container Workflow erweitert werden. Die möglichen Parameter können hier nachvollzogen werden: https://docs.docker.com/engine/reference/api/docker_remote_api_v1.23/#start-a-container Download: vCO Workflow: Run Docker Container (Remote API)  

Expose Docker Remote API on Photon

Veröffentlicht am von
Es kann sinnvoll sein die Docker Remote API nicht nur von localhost erreichbar zu machen. Fälle dafür sind z. B.:
  • Orchestrierung der Docker Runtime von extern (z. B. durch den vCenter Orchestrator bzw. vRealize Orchestrator)
  • Monitoring der Docker Runtime durch vRealize Operations mit Docker Management Pack
Dazu muss im Falle von Docker die systemd-Konfiguration für den Docker Daemon editieren: 
vi /etc/systemd/system/multi-user.target.wants/docker.service
ExecStart=/usr/bin/docker daemon \
          --containerd /run/containerd.sock --insecure-registry=192.168.5.20:5000 -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock
-H bestimmt dabei, wo der Deamon lauschen soll. tcp://0.0.0.0:2375 exposed den Port auf 2375/tcp nach außen unix:///var/run/docker.sock lässt auch weiterhin den lokalen Unix-Socket laufen, sodass die CLI-Kommandos wie gewöhnlich genutzt werden können   Von außen lassen sich nun entsprechende Abfragen gegen die Rest-API absetzen: 
GET http://192.168.5.20:2375/containers/json
POST http://192.168.5.20:2375/containers/create
 

VMware Photon und eine private Docker Registry

Veröffentlicht am von

In einer DEV-/Test-Umgebung kommt es häufig vor, dass die Docker Registry nur über HTTP und nicht über HTTPS verwendet wird. Die Docker Runtime geht standardmäßig davon aus, dass die Verbindung SSL verschlüsselt und das ausstellende CA-Zertifikat lokal vorhanden ist. Ist dies nicht der Fall, erhält man folgende Fehlermeldung:

root@photon01 [ ~ ]# docker run -it 192.168.5.20:5000/corp/centos7base:7.2
Unable to find image '192.168.5.20:5000/corp/centos7base:7.2' locally
docker: Error response from daemon: Get https://192.168.5.20:5000/v1/_ping: tls: oversized record received with length 20527.
See 'docker run --help'.

Der Docker-Daemon kennt zum Ignorieren der SSL-Verschlüsselung den Parameter –insecure-registry . Dieses lässt sich manuell beim Starten des Daemons mitgeben oder als fester Parameter für den automatischen Start festlegen. Hier ist noch zu unterscheiden ob systemd verwendet wird oder nicht. Photon setzt systemd ein, daher kann folgender Weg angewendet werden:

systemctl enable docker
vi /etc/systemd/system/multi-user.target.wants/docker.service
ExecStart=/usr/bin/docker daemon \
          --containerd /run/containerd.sock --insecure-registry=192.168.5.20:5000

Der Parameter –insecure-registry gibt dabei die Adresse plus den Port der privaten Docker Registry an. Sollen mehrere Registries eingetragen werden, so wird der Parameter in der oben angegeben Form mehrmals hintereinander mit je einem Server angegeben.

Nach dem Änderung durchgeführt wurde, muss die systemd-Konfiguration von der Platte neueingelesen werden:

systemctl daemon-reload
systemctl restart docker

HINWEIS: Die systemd-Konfigurationsdatei könnte bei einem Update wieder überschrieben werden.

CentOS Base Image für Docker erstellen

Veröffentlicht am von
Im öffentlichen Docker Hub Image Repository finden sich einige fertige CentOS-Basisimages, darunter auch die vom CentOS-Projekt gepflegten. Wer diesen nun misstraut oder gerne sein eigenes Basisimage erzeugen möchte, kann zu mehreren Optionen greifen. Folgt man dem Hinweis für CentOS auf docker.com, gelangt man zu einem Skript, der die Arbeit für einen erledigt. Manchmal ist es sinnvoll auch zu verstehen, was dort getan wird und somit macht man es auch gerne per Hand. Das Erstellen eines Docker-Basisimages ist vergleichbar mit dem Erstellen einer CHROOT-Umgebung. So fangen wir auch an (hier am Beispiel einer CentOS 7-Installation):
  1. Zuerst erstellen man einen temporären Ordner für die CHROOT-Umgebung:
  2. Danach baut man eine RPM-Datenbank für die spätere Paketinstallation in der CHROOT-Umgebung:
  3. Nun teilt man dem lokalen RPM mit, welches OS installiert werden soll. Dies geschieht über das centos-release Paket, welches die nötigen Metainformationen für z. B. Repositories enthält:
  4. Es fehlen noch die Pakete für die CHROOT-Umgebung. YUM und RPM ziehen alle nötigen Abhängigkeiten für die CHROOT-Umgebung:
  5. Überprüfen sollte man seine Arbeit auch noch:
  6. Nun importieren wir das Image noch in unsere private Docker Registry:
Die Anleitung funktioniert analog auch für CentOS 6 oder den entsprechenden RHEL-Versionen. Einfach die Repository-Pfade anpassen und gut.