Benutzer-Werkzeuge

Webseiten-Werkzeuge


docu:informatikcomputecloud

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
docu:informatikcomputecloud [2019/05/21 08:57]
abq319 [HowTo]
docu:informatikcomputecloud [2019/12/18 08:43] (aktuell)
abq319 [Verwendung von GPUs]
Zeile 3: Zeile 3:
 Die Informatik Compute Cloud ist eine vom AI Labor zur Verfügung gestellte Container Cloud Umgebung, in der Mitglieder des Departments Applikationen in Form von Docker Containern betreiben können. Der Betrieb befindet sich derzeit in der Beta-Phase. Es ist jedem Mitglied des Departments Informatik möglich, sich in der Cloud einzuloggen. Zuvor wird derzeit der Login in Gitlab ([[https://​gitlab.informatik.haw-hamburg.de|https://​gitlab.informatik.haw-hamburg.de]]) empfohlen, da Berechtigungen in der Cloud über eine Anbindung an Gitlab konfiguriert werden. Bei weiteren Fragen hilft Ihnen das ICC Team [[icc@informatik.haw-hamburg.de|]] Die Informatik Compute Cloud ist eine vom AI Labor zur Verfügung gestellte Container Cloud Umgebung, in der Mitglieder des Departments Applikationen in Form von Docker Containern betreiben können. Der Betrieb befindet sich derzeit in der Beta-Phase. Es ist jedem Mitglied des Departments Informatik möglich, sich in der Cloud einzuloggen. Zuvor wird derzeit der Login in Gitlab ([[https://​gitlab.informatik.haw-hamburg.de|https://​gitlab.informatik.haw-hamburg.de]]) empfohlen, da Berechtigungen in der Cloud über eine Anbindung an Gitlab konfiguriert werden. Bei weiteren Fragen hilft Ihnen das ICC Team [[icc@informatik.haw-hamburg.de|]]
  
-__**Ein Tutorial **__  für die Verwendung der ICC zusammen mit [[:​docu:​gitlab|Gitlab ]]finden Sie hier zum Download: {{:​docu:​icc_tutorial_hello_world.pdf|:docu:icc_tutorial_hello_world.pdf}}+__**Ein Tutorial **__  für die Verwendung der ICC zusammen mit [[:​docu:​gitlab|Gitlab ]]finden Sie hier zum Download: {{:​docu:​icc_tutorial_hello_world.pdf|icc_tutorial_hello_world.pdf}}
  
 __**Ein FAQ**__ ​ mit häufigen Fragen findet sich hier:​[[:​docu:​informatikcomputecloudfaq|:​docu:​informatikcomputecloudfaq]] __**Ein FAQ**__ ​ mit häufigen Fragen findet sich hier:​[[:​docu:​informatikcomputecloudfaq|:​docu:​informatikcomputecloudfaq]]
Zeile 24: Zeile 24:
   * macOS: [[https://​storage.googleapis.com/​kubernetes-release/​release/​v1.14.0/​bin/​darwin/​amd64/​kubectl|https://​storage.googleapis.com/​kubernetes-release/​release/​v1.14.0/​bin/​darwin/​amd64/​kubectl]]   * macOS: [[https://​storage.googleapis.com/​kubernetes-release/​release/​v1.14.0/​bin/​darwin/​amd64/​kubectl|https://​storage.googleapis.com/​kubernetes-release/​release/​v1.14.0/​bin/​darwin/​amd64/​kubectl]]
   * Windows: [[https://​storage.googleapis.com/​kubernetes-release/​release/​v1.14.0/​bin/​windows/​amd64/​kubectl.exe|https://​storage.googleapis.com/​kubernetes-release/​release/​v1.14.0/​bin/​windows/​amd64/​kubectl.exe]]   * Windows: [[https://​storage.googleapis.com/​kubernetes-release/​release/​v1.14.0/​bin/​windows/​amd64/​kubectl.exe|https://​storage.googleapis.com/​kubernetes-release/​release/​v1.14.0/​bin/​windows/​amd64/​kubectl.exe]]
- 
  
 ==== Login ==== ==== Login ====
Zeile 30: Zeile 29:
 Um sich mit der Informatik Compute Cloud zu verbinden, ist ein Login gegen die Infrastruktur notwendig. Dies geschieht mithilfe des '​kubelogin'​ Werkzeuges, welches Sie unter den folgenden Links für Ihr Betriebssystem herunterladen können: Um sich mit der Informatik Compute Cloud zu verbinden, ist ein Login gegen die Infrastruktur notwendig. Dies geschieht mithilfe des '​kubelogin'​ Werkzeuges, welches Sie unter den folgenden Links für Ihr Betriebssystem herunterladen können:
  
-  * Linux: ​[[https://​nexus.informatik.haw-hamburg.de/​repository/​ail-raw/​icc/​linux/​kubelogin|https://​nexus.informatik.haw-hamburg.de/​repository/​ail-raw/​icc/​linux/​kubelogin]] +  * Linux: ​{{:docu:​kubelogin_linux|kubelogin_linux}} ​--> Nach dem Download umbenennen in kubelogin 
-  * macOS : [[https://​nexus.informatik.haw-hamburg.de/​repository/​ail-raw/​icc/​darwin/​kubelogin|https://​nexus.informatik.haw-hamburg.de/​repository/​ail-raw/​icc/​darwin/​kubelogin]] +  * macOS : {{:docu:​kubelogin_macos|kubelogin_macos}} ​--> Nach dem Download umbenennen in kubelogin 
-  * Windows: ​[[https://​nexus.informatik.haw-hamburg.de/​repository/​ail-raw/​icc/​win/​kubelogin.exe|https://​nexus.informatik.haw-hamburg.de/​repository/​ail-raw/​icc/​win/​kubelogin.exe]]+  * Windows: ​{{:docu:​kubelogin.exe|kubelogin.exe}}
  
-Führen Sie das Programm anschliessend in einem Terminal (OSX & Linux) bzw. einer Command Sitzung (Windows) aus und folgen Sie den Anweisungen. Unter Linux und macOS müssen Sie die Datei ggf. noch via ' ''​chmod +x kubelogin''​ ' ausführbar machen. Das Werkzeug fragt Ihre Credentials ab und erzeugt eine config Datei in Ihrem Heimverzeichnis im Unterordner .kube.+Führen Sie das Programm anschliessend in einem Terminal (OSX & Linux) bzw. einer Command Sitzung (Windows) aus und folgen Sie den Anweisungen. Unter Linux und macOS müssen Sie die Datei ggf. noch via ' ''​chmod +x kubelogin'' ​ ' ausführbar machen. Das Werkzeug fragt Ihre Credentials ab und erzeugt eine config Datei in Ihrem Heimverzeichnis im Unterordner .kube.
  
 Das Kubelogin Werkzeug ruft ein Token aus dem Cluster ab, mit dem Sie zukünftig authentifiziert werden. Dieses Token hat eine beschränkte Gültigkeit von 12 Stunden, sodass Sie '​kubelogin'​ erneut aufrufen müssen, sobald '​kubectl'​ eine Meldung darüber ausgibt, dass Sie nicht authentifiziert sind. Ein expliziter Logout ist somit nicht notwendig. Das Kubelogin Werkzeug ruft ein Token aus dem Cluster ab, mit dem Sie zukünftig authentifiziert werden. Dieses Token hat eine beschränkte Gültigkeit von 12 Stunden, sodass Sie '​kubelogin'​ erneut aufrufen müssen, sobald '​kubectl'​ eine Meldung darüber ausgibt, dass Sie nicht authentifiziert sind. Ein expliziter Logout ist somit nicht notwendig.
- 
  
 ==== Kontext und Namespace ==== ==== Kontext und Namespace ====
Zeile 88: Zeile 86:
 ===== Zugriff auf Logs & Alerting ===== ===== Zugriff auf Logs & Alerting =====
  
-=== Hinweis : Graylog hat sich als nicht skalierbar genug für unseren Anwendungsfall herausgestellt. Die Lösung wir daher aktuell überarbeitet und steht daher vorrübergehend nicht zur Verfügung! === +Bei einzelnen Pods kann problemlos mit ''​kubectl logs <​PodName>​ ''​gearbeitet werden. Wird ein Deployment jedoch größer, oder hat man z.B. Datenbank-Cluster oder andere Dienste mit mehreren Pods zu verwalten, wird die Arbeit häufig mühsam und schwierig.
- +
-Bei einzelnen Pods kann noch problemlos mit ''​kubectl logs <​PodName>​ ''​gearbeitet werden. Wird ein Deployment jedoch größer, oder hat man z.B. Datenbank-Cluster oder andere Dienste mit mehreren Pods zu verwalten, wird die Arbeit häufig mühsam und schwierig. ​<​del>​Zur Vereinfachung hostet die ICC eine Graylog Instanz, die über die Integrationsservices automatisch mit Streams, Rollen und Regeln für alle Anwender der ICC synchronisiert wird.</​del>​ +
- +
-<​del>​Zu jedem Namespace gibt es einen Stream in Graylog, der sämtliche Log Ausgaben von stdout und stderr aller Pods in diesen Namespaces annimmt. Eingesammelt werden die Logs vollautomatisch durch fluentd Deployments in der ICC. Als Nutzer kann man sich unter [[https://​icc-logging.informatik.haw-hamburg.de|https://​icc-logging.informatik.haw-hamburg.de]] mit der HAW-Kennung einloggen und dann die Logs durchsuchen oder für bestimmte Situationen Alert Regeln festlegen.</​del>​+
  
 ===== Resourcennutzung von Pods anzeigen lassen ===== ===== Resourcennutzung von Pods anzeigen lassen =====
  
-Mit dem folgenden Befehl lassen sich die aktuell genutzten Resourcen aller Pods in einem Namespace anzeigen:+Dies funktioniert zurzeit nicht aufgrund eines Zertifikatsproblems.
  
-<​code>​+Mit dem folgenden Befehl lassen sich die aktuell genutzten Resourcen aller Pods in einem Namespace anzeigen:<​code>​
 kubectl -n <​NameDesNamespaces>​ top pods kubectl -n <​NameDesNamespaces>​ top pods
 </​code>​ </​code>​
Zeile 124: Zeile 118:
  
 {{page>​docu:​domain-hosten#​Vorlagen für Impressum und Datenschutzerklärung&​nofooter}} {{page>​docu:​domain-hosten#​Vorlagen für Impressum und Datenschutzerklärung&​nofooter}}
- 
  
 ==== HowTo ==== ==== HowTo ====
Zeile 138: Zeile 131:
       - Schicken Sie Ihren Domainnamen an [[icc@informatik.haw-hamburg.de|]]. Wir richten dann eine entsprechende Weiterleitung im Gateway Server ein, sodass Ihre Seite erreichbar ist.       - Schicken Sie Ihren Domainnamen an [[icc@informatik.haw-hamburg.de|]]. Wir richten dann eine entsprechende Weiterleitung im Gateway Server ein, sodass Ihre Seite erreichbar ist.
   - aus dem Department Informatik ([[https://​example.informatik.haw-hamburg.de|example.informatik.haw-hamburg.de]]). **Die Registrierung und DNS Eintragung erfolgt über AI Labor Mitarbeiter** ​ (Mail mit gewünschter Sub-Domain an [[icc@informatik.haw-hamburg.de|]])   - aus dem Department Informatik ([[https://​example.informatik.haw-hamburg.de|example.informatik.haw-hamburg.de]]). **Die Registrierung und DNS Eintragung erfolgt über AI Labor Mitarbeiter** ​ (Mail mit gewünschter Sub-Domain an [[icc@informatik.haw-hamburg.de|]])
-  - Legen Sie eine Ingress Ressource ([[https://​kubernetes.io/​docs/​concepts/​services-networking/​ingress/​|https://​kubernetes.io/​docs/​concepts/​services-networking/​ingress/​]]) in Ihrem Namespace für Ihren Domainnamen und Ihre Services gemäß dieser Vorlage an: +  - Legen Sie eine Ingress Ressource ([[https://​kubernetes.io/​docs/​concepts/​services-networking/​ingress/​|https://​kubernetes.io/​docs/​concepts/​services-networking/​ingress/​]]) in Ihrem Namespace für Ihren Domainnamen und Ihre Services gemäß dieser Vorlage an:<​code>​
- +
-<​code>​+
 apiVersion: extensions/​v1beta1 apiVersion: extensions/​v1beta1
 kind: Ingress kind: Ingress
Zeile 166: Zeile 157:
 Durch die Ingress Ressource wird vom Cluster ein Zertifikat für Ihre Domäne bei Let's Encrypt angefordert und als Secret in Ihren Cluster hinterlegt. Durch die Ingress Ressource wird vom Cluster ein Zertifikat für Ihre Domäne bei Let's Encrypt angefordert und als Secret in Ihren Cluster hinterlegt.
  
-**Hinweis:​** ​ Das Feld secretName bestimmt wie das Secret mit dem automatisch erzeugten SSL Zertifikat in Ihrem Namespace heißen wird. Dieses Secret darf es noch nicht geben, wenn Sie die Ingress Ressource für Ihren Namespace anlegen!+**Hinweis ​1:**  Das Feld secretName bestimmt wie das Secret mit dem automatisch erzeugten SSL Zertifikat in Ihrem Namespace heißen wird. Dieses Secret darf es noch nicht geben, wenn Sie die Ingress Ressource für Ihren Namespace anlegen! 
 + 
 +**Hinweis 2: **Verwenden Sie für den Namen des Secrets nur Zahlen, Kleinbuchstaben und Bindestriche. Ansonsten kann das Zertifikat nicht richtig beantragt und eingerichtet werden.
  
-**Hinweis ​2:**  Let's Encrypt hat eine Mengenbeschränkung von 20 Zertifikaten für vollständige Domains pro Woche. Es kann also sein, dass Sie ihr Zertifikat nicht sofort bekommen, falls es ein sehr hohes Registrierungsaufkommen geben sollte. **Im Sinne der Fairness bitten wir darum, sich den Namen und die Notwendigkeit von Zertifikaten gut im Vorfeld zu überlegen.**+**Hinweis ​3:**  Let's Encrypt hat eine Mengenbeschränkung von 20 Zertifikaten für vollständige Domains pro Woche. Es kann also sein, dass Sie ihr Zertifikat nicht sofort bekommen, falls es ein sehr hohes Registrierungsaufkommen geben sollte. **Im Sinne der Fairness bitten wir darum, sich den Namen und die Notwendigkeit von Zertifikaten gut im Vorfeld zu überlegen.**
  
 Die Ingress Ressource definiert, wie Ihre Services unter Ihrer Domain erreichbar sind. Weitere Details und Einzelheiten entnehmen Sie bitte der Ingress Dokumentation des Kubernetes Projektes: [[https://​kubernetes.io/​docs/​concepts/​services-networking/​ingress/​|https://​kubernetes.io/​docs/​concepts/​services-networking/​ingress/​]] Die Ingress Ressource definiert, wie Ihre Services unter Ihrer Domain erreichbar sind. Weitere Details und Einzelheiten entnehmen Sie bitte der Ingress Dokumentation des Kubernetes Projektes: [[https://​kubernetes.io/​docs/​concepts/​services-networking/​ingress/​|https://​kubernetes.io/​docs/​concepts/​services-networking/​ingress/​]]
Zeile 252: Zeile 245:
 Das AI-Labor bietet derzeit begrenzten persistenten Speicher als Block Storage über einen CEPH Cluster an ([[http://​ceph.com/​ceph-storage/​block-storage/​|http://​ceph.com/​ceph-storage/​block-storage/​]]). Dieser Storage kann in der ICC in From von Volumes mit festgelegter Größe genutzt werden. Um ein Storage Volume anzufordern gehen Sie wie folgt vor: Das AI-Labor bietet derzeit begrenzten persistenten Speicher als Block Storage über einen CEPH Cluster an ([[http://​ceph.com/​ceph-storage/​block-storage/​|http://​ceph.com/​ceph-storage/​block-storage/​]]). Dieser Storage kann in der ICC in From von Volumes mit festgelegter Größe genutzt werden. Um ein Storage Volume anzufordern gehen Sie wie folgt vor:
  
-  - Legen Sie in Ihrem Projekt eine YAML Datei '​my-pvc.yaml'​ für einen PersistentVolumeClaim ([[https://​kubernetes.io/​docs/​concepts/​storage/​persistent-volumes/#​persistentvolumeclaims|https://​kubernetes.io/​docs/​concepts/​storage/​persistent-volumes/#​]][[https://​kubernetes.io/​docs/​concepts/​storage/​persistent-volumes/#​persistentvolumeclaims|persistentvolumeclaims]]) mit folgendem Inhalt an: +  - Legen Sie in Ihrem Projekt eine YAML Datei '​my-pvc.yaml'​ für einen PersistentVolumeClaim ([[https://​kubernetes.io/​docs/​concepts/​storage/​persistent-volumes/#​persistentvolumeclaims|https://​kubernetes.io/​docs/​concepts/​storage/​persistent-volumes/#​]][[https://​kubernetes.io/​docs/​concepts/​storage/​persistent-volumes/#​persistentvolumeclaims|persistentvolumeclaims]]) mit folgendem Inhalt an:<​code>​
- +
-<​code>​+
 kind: PersistentVolumeClaim kind: PersistentVolumeClaim
 apiVersion: v1 apiVersion: v1
Zeile 353: Zeile 344:
  
 **Beachten Sie**, dass der //​**deploy_image**// ​ Job das automatisch erzeugte Environment //**icc-dev **//  referenziert! Die Verwendung von kubectl gelingt hier nun ohne weitere Konfiguration,​ da Gitlab alle erforderlichen Verbindungs- und Authentifikationsparameter via Umgebungsvariablen in das Build Environment injiziert. **Beachten Sie**, dass der //​**deploy_image**// ​ Job das automatisch erzeugte Environment //**icc-dev **//  referenziert! Die Verwendung von kubectl gelingt hier nun ohne weitere Konfiguration,​ da Gitlab alle erforderlichen Verbindungs- und Authentifikationsparameter via Umgebungsvariablen in das Build Environment injiziert.
- 
- 
-===== Verwendung der Pool PC's für ICC-Deployments ===== 
- 
-Die ICC und die Pool PCs im 11. Stock sind so konfiguriert,​ dass jeder unter Linux hochgefahrene Pool-PC automatisch Mitglied des Clusters ist. Auf diese Weise lassen sich dynamisch größere Mengen CPU und RAM der ICC hinzufügen. 
- 
-Dies ist etwa sinnvoll für Praktika, da hier eigene exklusive Ressourcen einfach erzeugt werden können, in dem der gewählte Praktikumsraum unter Linux gebootet wird. Auf diese Weise stehen die notwendigen Ressourcen für die Praktikumsdurchführung in der ICC zur Verfügung! Andere Anwendungsfälle beinhalten aber auch größere Verteilte Rechenaufgaben,​ wie etwa gut verteilbare Data Science Workloads o.ä.. 
- 
-==== Randbedingunge & Empfehlungen ==== 
- 
-  * Im normalen Laborbetrieb sind die Rechner den Studenten vor Ort vorbehalten! **Stimmen Sie größere Experimente o.ä. daher bitte mit dem AI-Labor ab!** 
-  * Die Pool-PCs sind jeweils **nur mit 100MBit LAN angebunden. **Stark Netzwerkverkehr-gebundene Aufgaben, sollte daher eher auf anderer Hardware im Datacenter ausgeführt werden. Testen kann man aber immer! 
-  * Bei nicht expliziter Nutzung oder Abstimmung mit dem AI-Labor, **kann Ihr Workload jederzeit entfernt werden**, etwa wenn Studieren die Rechner unter Windows neustarten etc. Achten Sie daher auf die notwendigen Fähigkeiten zur Kurzlebigkeit für Ihre Deployments. 
-  * Jeder Rechner verfügt über** 8 logischer Kerne und 16 GB Arbeitsspeicher**. Für größere, verteilte Rechenaufgaben,​ sollten Sie dies beim Aufteilen Ihrer Workloads bedenken. 
- 
-==== HowTo ==== 
- 
-Um nicht per Standard auf die PC-Pools Last zu verteilen und/oder kritische Workloads hier auszuführen,​ sind diese Knoten mit sog. Kubernetes **Taints **versehen. Um darauf etwa auszuführen,​ ist eine explizite Annotation mit einer passenden sog. **Toleration **notwendig,​ die den Wert **pool=true** ​ akzeptiert 
- 
-Hier eine Beispiel YAML Datei für ein Deployment mit entsprechender Toleration: 
- 
-<​code>​ 
-apiVersion: extensions/​v1beta1 
-kind: Deployment 
-metadata: 
-  labels: 
-    service: my-svc 
-    name: my-svc 
-spec: 
-  selector: 
-    matchLabels:​ 
-      service: my-svc 
-  template: 
-    metadata: 
-      labels: 
-       ​service:​ my-svc 
-    spec: 
-     ​tolerations:​ 
-      - key: pool 
-        effect: NoSchedule 
-        operator: "​Equal"​ 
-        value: "​true"​ 
-     ​containers:​ 
-      - image: nexus.informatik.haw-hamburg.de/​my-service:​my-tag 
-        name: my-svc 
-        ports: 
-          - containerPort:​ 8080 
-</​code>​ 
- 
-Die Toleration Angabe sorgt dafür, dass der Scheduler von Kubernetes bei seiner Arbeit die Taints der Pool-PCs akzeptiert und dort ebenfalls nach geeigneten Hosts für das Deployment sucht. 
  
 ===== Kopieren von Dateien aus einem Gitlab-Build mittels SSH in das eigene Pub Verzeichnis ===== ===== Kopieren von Dateien aus einem Gitlab-Build mittels SSH in das eigene Pub Verzeichnis =====
Zeile 410: Zeile 351:
   - Der Inhalt der Datei icc.key.pub,​ der öffentliche Schlüssel, wird nun an die Datei .ssh/​authorized_keys angehängt.   - Der Inhalt der Datei icc.key.pub,​ der öffentliche Schlüssel, wird nun an die Datei .ssh/​authorized_keys angehängt.
   - In Gitlab wird unter Settings→CI/​CD eine Secret-Varaible angelegt mit dem Namen SSH_PRIVATE_KEY. Der Wert der Variablen ist der Inhalt der Datei icc.key inklusive der Begrenzer. Die Variable darf nicht auf Protected gesetzt werden.   - In Gitlab wird unter Settings→CI/​CD eine Secret-Varaible angelegt mit dem Namen SSH_PRIVATE_KEY. Der Wert der Variablen ist der Inhalt der Datei icc.key inklusive der Begrenzer. Die Variable darf nicht auf Protected gesetzt werden.
-  - Füge die folgende Before-Sektion zur Datei .gitlab-ci.yml hinzu: +  - Füge die folgende Before-Sektion zur Datei .gitlab-ci.yml hinzu:<​code>​
- +
-<​code>​+
 before_script:​ before_script:​
   ##   ##
Zeile 456: Zeile 395:
 |Sicherheit|TLS (starttls)| |Sicherheit|TLS (starttls)|
 |Authentifikation|PlainAuth| |Authentifikation|PlainAuth|
- 
-\\ 
- 
  
 ===== Verwendung von GPUs ===== ===== Verwendung von GPUs =====
  
-Die ICC stellt eine limitierte Anzahl an GPUs zur Verfügung, deshalb sind Interessenten gebeten sich eigenständig ​an Sven Berding ​mittles Slack zu wenden.+Die ICC stellt eine limitierte Anzahl an GPUs zur Verfügung, deshalb sind Interessenten gebeten sich eigenständig mittles ​[[https://​app.slack.com/​client/​T5GCAHRE1/​C5G9WRKS6|Slack]], [[https://​mattermost.informatik.haw-hamburg.de/​informatik/​channels/​icc|Mattermost]] oder per Mail an icc@informatik.haw-hamburg.de ​zu wenden.
  
 Generelle Voraussetzung ist, dass das Container-Image GPU-Unterstützung hat, dazu könnte es zum Beispiel auf den [[https://​hub.docker.com/​r/​nvidia/​cuda/​|NVIDIA Cuda Ubuntu]] Images basieren. Generelle Voraussetzung ist, dass das Container-Image GPU-Unterstützung hat, dazu könnte es zum Beispiel auf den [[https://​hub.docker.com/​r/​nvidia/​cuda/​|NVIDIA Cuda Ubuntu]] Images basieren.
docu/informatikcomputecloud.1558421876.txt.gz · Zuletzt geändert: 2019/05/21 08:57 von abq319