Sind Anwendungen oder Dateien unerwartet nicht mehr verfügbar, stehen schnell Teile des Unternehmens still und die Augen sind auf den Admin gerichtet. Um ... (mehr)

Ein Kommando für alle

LXD spielt seine Stärken beim Verwalten mehrerer LXD-Server aus. Sind zwei LXD-Instanzen miteinander verbunden, arbeiten die lxc-Kommandos Host-übergreifend, wie etwa:

$ lxc remote add lxd2 192.168.56.103:8090
Certificate fingerprint: b253acc45147d....
ok (y/n)? y
Admin password for lxd2:

 

Client certificate stored at server: lxd2

Das Admin-Passwort ist dasjenige, das bei "lxc init" angegeben wurde. Die Zeile "Client certificate stored at server: lxd2 " signalisiert, dass das lokale Client-Zertifikat am Host lxd2 eingerichtet ist. Somit starten lxc-Kommandos ohne weitere Authentifizierung am zweiten LXD-Host, wie Listing 4 zeigt.

Am wichtigsten Feature für den reibungslosen LXD-Betrieb im Cloud-Bereich wird noch gearbeitet: der Live-Migration von Containern über das CRIU-Framework. Auch nach der Veröffentlichung von Ubuntu 16.04 war dabei noch nicht alles im Reinen. Wenn irgendwann alles funktioniert, migriert lxc move einen Container live:

$ lxc move container0 lxd2: container0

Container-Konfiguration

Je mehr virtuelle Maschinen auf einem LXD-Host laufen, umso wichtiger ist die Ressourcen-Beschränkung einzelner Container. Die Möglichkeiten zur Limitierung orientieren sich an den Subsystemen der Linux Control Groups (cgroups) [1]. Die wichtigsten im Produktivbetrieb sind CPU, Hauptspeicher, I/O-Zugriffe und Netzwerkverkehr. Bereits vor LXD – bei Verwendung der lxc-tools – wurden Container-Limits definiert. Die Einstellungen wurden in eigens dafür vorgesehene Dateien eingetragen. LXD ändert diese Vorgehensweise – es führt eine lokale Datenbank als Backend und das Kommando lxc config ein [2]. Obendrein gibt es LXD-Profile, Konfigurationsvorlagen, die den Containern zugeordnet werden. Standardmäßig liefert eine LXD-Installation das Profil "default" aus:

$ lxc profile show default
name: default
config: {}
description: ""
devices:
      eth0:
         name: eth0
         nictype: bridged
         parent: lxcbr0
         type: nic

Das Profil "default" verbindet einen Container mit der Bridge "lxcbr0" und macht ihn dadurch vom Host aus erreichbar. Ansonsten befinden sich darin keine weiteren Einstellungen. Wer möchte, kann das Profil aber beliebig erweitern:

$ lxc profile edit default
name: default
config: limits.memory: 128MB
[...]

Die Einstellung "limits.memory" erweitert in diesem Fall das Profil um eine Hauptspeicher-Beschränkung für Container. Jene, die das Profil nutzen, verbrauchen von nun an maximal 128 MByte an Arbeitsspeicher:

$ lxc profile apply container0 default
Profile default applied to container0
$ lxc exec container0 -- cat /proc/meminfo | grep MemTotal

 

MemTotal: 131072 kB

Wer nicht sofort das komplette Profil abändern möchte, setzt einzelne Parameter direkt für einen Container:

$ lxc config set container1 limits.memory 64MB

Listing 3: Container auflisten



$ lxc list
+------------+----------------+-----------------------+-------+----------------+-----------------+
| NAME      | STATE        | IPV4                      | IPV6 | TYPE            | SNAPSHOTS |
+------------+----------------+-----------------------+-------+----------------+-----------------+
| container0 | RUNNING | 10.0.3.100 (eth0)  |          | PERSISTENT | 0                   |
+------------+----------------+-----------------------+-------+----------------+-----------------+
| container1 | STOPPED  |                              |           | PERSISTENT| 0                   |
+------------+----------------+-----------------------+-------+----------------+-----------------+

Listing 4: Ausführung auf einem anderen Container-Host



$ lxc launch trusty lxd2:trusty1
Creating trusty1
Starting trusty1
$ lxc list lxd2:
+------------+----------------+-----------------------+-------+----------------+-----------------+
| NAME      | STATE        | IPV4                      | IPV6 | TYPE            | SNAPSHOTS |
+------------+----------------+-----------------------+-------+----------------+-----------------+
| trusty1     | RUNNING   |                               |          | PERSISTENT|       0            |
+------------+----------------+-----------------------+-------+----------------+-----------------+
comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2020