Resize a logical volume with Ansible with checks before

Situation:
My challenge is to check my nodes if the root directory has enough space and if not check if the volume group has also enough space to resize the logical volume.

Here is my Ansible code. I'm sure it's not perfect, but it works :-)

# Check nodes before Upgrade Cluster
---
- hosts: all
  become: True
  tasks:

    - name: Test disk space available
      assert:
        that:
         - item.mount != '/' or {{ item.mount == '/' and \
                   item.size_available > (item.size_total) }}
      with_items: '{{ ansible_mounts }}'
      ignore_errors: yes
      register: disk_free

    - name: Check VG for enough space
      assert:
        that:
          - item.key != '{{ VG }}' or {{ item.key == '{{ VG }}' \
                   and item.value.free_g > 1.00 }}
      with_dict: '{{ ansible_lvm.vgs }}'
      register: vg_free
      ignore_errors: yes
      when: disk_free is failed

    - name: resize lvROOT
      shell: lvresize -L +1G /dev/VG/lv && xfs_growfs /

      when: vg_free is succeeded

Ansible unter Ubuntu 16.04

Installation Ansible:

$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt-get update
$ sudo apt-get install ansible

$ ansible --version
   ansible 2.6.1

Um mit Ansible arbeiten zu können, die Hosts in die /etc/ansible/hosts eintragen, die angesprochen werden soll

Danach muss der ssh key des Ansible-Hosts auf die Ziel-Hosts kopiert werden

$ ssh-keygen

$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@zielsystem

Ich habe den ssh key meines normalen Users kopiert, und nicht den von root

Erster Test:

$ ansible all -m setup 

Im weiteren Verlauf:

Der Zugriff per Root wird doch benötigt... daher den Public Key doch noch rüber kopieren

Bug beim Auslesen der LVM Größen über setup

https://github.com/ansible/ansible/issues/33617

Gasterweiterung unter VirtualBox Ubuntu Server 16.04 ohne Desktop

VirtualBox 5.2
VM: Ubuntu 16.04 ohne Desktop

Herausforderung: Gasterweiterung installieren

$sudo apt-get update
$sudo apt-get upgrade
$sudo apt-get install gcc make

Wenn notwendig restart

$mount /dev/cdrom /media/cdrom 
$/media/cdrom/VBoxLinuxAdditions.run 
reboot 

$sudo usermod --append --groups vboxsf USERNAME

Get started with minishift on Ubuntu 16.04

I actually go through the course Fundamentals of Containers, Kubernetes, and Red Hat OpenShift 

For this course I need a minishift environment. 
My first try was to install a RHEL 7.4 on an older laptop (this is the recommendation in the course). Unfortanetly the laptop was to weak ;-)
Second try was to install it in a VM (on Virtualbox). But this doesn't work because you have to run a VirtualBox in a VirtualBox. And actually VirtualBox doesn't support the vmx flag inside a VM, so minishift doesn't work.
Third try was to make the exersices in the OpenShift 3.7 Playground on the platform learn.openshift.com. For the first exercises it works for me. But on the point working with a Dockerfile it ends.
So I search again for a solution to install minishift somewhere. In the documentation of minishift I recogniszed, that it can be installed on every Linux Distro. So I decided to try it on my productive laptop running with Ubuntu 16.04. 

• download minishift for Linux
• extract the tar file to a directory of your choice
• add the directory to the PATH variable
• and start minishift the first time :         $minishift start

First starting problem was, that the default hypervisor for Linux is KVM. On my system I have VirtualBox installed.

So I started minishift again with: $minishift start --vm-driver=virtualbox

and here we are, minishift is running!!!!

Then I try to build a new docker image with a RHEL7.3 base image. The first run command in the dockerfile is yum update -y. After starting docker build the system told me, that I haven't got a valid subscription. Big problem, if you want to install something inside this image.

But there is a easy solution (I love dockerfiles): I added simply in the dockerfile:

subscription-manager register --username admin-example --password secret --auto-attach

(of course with my personal credentials ;-). You need a RedHat developer account)

start the docker build command again... and it works :-)

To run minishift permanently with VirtualBox as vm-driver there are following steps necessary:
If you have already started minishift:
1. Stop minishift                           $minshift stop
2. Delete minishift configuration: $minishift delete

If you haven't started minishift for the first time and also for the "deleted" minishift then

$minishift config set vm-driver virtualbox (no "=" between vm-driver and virtualbox, that doesn't work)

Another topic is the user for minishift. Before starting minishift the first time create a permanent minishift user in the ~/.bashrc:

export MINISHIFT_USERNAME=myusername

export MINISHIFT_PASSWORD=mypassword

After both configuration for user and hypervisor environment are done, start the minishift cluster the first time with

$minishift start

It takes some time :-)

After my first try to login to the minishift cluster with the oc login command, I always get the error message: "oc: command not found"
After some search I find the solution for my Ubuntu environment:

execute: $eval $(minishift oc-env)

After this command the oc command works fine 

Please also have a look to the minishift documentation 

Praktikum Openstack

Was für eine Woche :-) !!!!!!!!!!!!!

Ich war diese Woche hospitieren in einer Firma, die unter anderem OpenStack deployed und verkauft in Verbindung mit der gewünschten Cloud (public, private). Ziel meines Praktikums war es, ein "Gefühl" für das Cloudgeschäft, insbesondere OpenStack zu bekommen und natürlich heraus zu finden, was ich noch alles lernen sollte, um dem Stack gerecht zu werden ;-)

An meinem ersten Tag bekam ich die Aufgabe mich mit der Software-Plattform ansible vertraut zu machen. Diese Software wird eingesetzt, um den OpenStack automatisiert zu installieren, wobei alle gewünschten Anforderungen im Vorfeld in sogenannten Playbooks zusammen gefasst werden. Ich erkundete Ansible mit Hilfe des Tutorials https://github.com/leucos/ansible-tuto Dieses Tutorial nimmt Vagrant zur Hilfe um virtuelle Maschinen zu kreiren und zu verwalten. Mit diesem Tutorium und diversen dadurch entstehenden Problemen habe ich meinen ersten Tag verbracht. 

Für Tag 2 war OpenFlow Thema. Mit Hilfe von OpenFlow kann man Router und Switche programmieren. Unter zu Hilfenahme von der Plattform Mininet.org habe ich ein kleines Netzwerk simuliert. Dann habe ich gelernt, wie man diverse Netzwerkkenngrößen abfragt und sich auch die über das Netzwerk verschickten Pakte anschauen kann. In diesem Zuge kam dann das Programm Wireshark zum Einsatz. 

Tag 3 verbrachte ich mit den Themen HTTP, cUrl und telnet. Ich sollte lernen, wie die Kommunikation über das Netzwerk funktioniert, wie ich mir anschauen kann, wie der Verkehr im Netz funktioniert. Mit Hilfe von cUrl kann man Pakete schicken, empfangen und auch den Status des Empfängers/ Senders abfragen. Sehr interessantes Thema, vor allem auch zu beobachten, was eigentlich passiert, wenn man eine Seite im Web aufruft. Ich hab anhand eines Aufrufs der Spiegel.de Seite erst einmal realisiert, wie viele Seiten man damit zusätzlich aufruft und was an Übermittlung alles stattfindet.

Ehrlich gesagt waren alle Themen sehr interessant, aber ich war doch etwas enttäuscht, da ich bis zu diesem Zeitpunkt noch nicht einmal in die Nähe von OpenStack gekommen war. Das sollte sich an Tag 4 aber ändern. Und wie!!! Die Firma betreibt unter anderem auch an ihrem Standort ein eigenes Rechenzentrum. Damit ich ein Anschauungsobjekt hatte, wurde beschlossen, das der Test OpenStack wieder aktiviert werden sollte. Nach einiger Zeit stellte sich jedoch heraus, das durch Umbau-Maßnahmen das Netzwerk nicht mehr wie gedacht erreichbar war. Darauf hin ging es in den Keller, wo die Blades untergebracht sind. Mein erster Besuch in einem Rechenzentrum!!! Ich denke, es handelt sich bei dem vorhandenen eher um ein kleineres, aber ich fand es total faszinierend zu sehen. Es ist etwas anderes von einem Wärme- und Kältegang zu lesen und dann in einem Kältegang zu stehen und zu bibbern. Auch die Lautstärke der Lüfter hat mich überrascht... Ich bekam auch ein Blade gezeigt, wie er aufgebaut ist. So ein Blade ist mit einem normalen Rechner in keinster Weise vergleichbar. Es gibt eine Hauptplatine auf der mehrere Prozessoren angeordnet sind. An diesem Tag kam ich noch ein zweites Mal in den Serverraum, da die Blades für den TestStack einmal komplett neu gestartet werden sollten, nachdem sie einmal stromlos geschaltet wurden. Der Anlauf der Blades war sehr beeindruckend. Ich hätte niemals gedacht, dass so kleine Lüfter so viel Luft ziehen können und dabei so laut werden.

Ab diesem Zeitpunkt durfte ich den Profis über die Schulter schauen. Ich konnte beobachten, wie systematisch das vorhandene Netzwerk aus 8 Nodes überprüft wurde, warum der eine mit dem anderen nicht kommunizierte. Auch konnte ich sehen, wie die Kommisionierung der verschiedenen Nodes aussah. Das verwendete Programm nennt sich MaaS der Firma Canonical und zeigte den aktuellen Status der einzelnen Nodes an. Man konnte ebenfalls Detaildaten der Nodes einsehen (IP Adresse, Größe, Status) und auch eine direkte Konsole auf den Nodes öffnen. Nachdem alle Rechner einmal komplett resetet wurden, stellte sich heraus, dass ein Node nicht kommunizieren wollte. Daraufhin wurde beschlossen, dass das Testsystem neu gebaut werden sollte. Das war sozusagen wie Weihnachten und Ostern für mich. 

Als erstes wurden alle Nodes neu mit einem Ubuntu Server OS deployed. Dieser Vorgang wurde unter zu Hilfenahme der Software Maas gestartet. Es ist doch erstaunlich, wie zügig man acht Nodes mit einem Server OS incl. Pacemaker (Verwaltungstool der Nodes im Netzwerk)an den Start bekommt. Nachdem die Nodes am Start waren, ging es los. Es wurde das erste Ansible Playbook gestartet, welches die Netzwerk-Konfiguration initialisierte. Danach kam dann auch schon das eigentliche Ansible Playbook um den OpenStack zu bauen. 

In diesem Zusammenhang wurde schnell klar, dass solche Playbooks nicht unbedingt perfekt aufgebaut sind. Das heißt, dass die Installation immer wieder mit einer Fehlermeldung abgebrochen wurde. Dann wurde in die entsprechenden Tasks reingeschaut, was passiert, welche Daten fehlen eventuell, oder welche Skripte sind nicht vorhanden. An dieser Stelle sei erwähnt, dass die Verwaltung der Ansible Playboos mit Hilfe von PyCharm erfolgt. Unser zu installierende Stack sollte ein OpenStack Kilo werden. Da sich OpenStack jedoch schon in der Version Liberty befindet, sind einige Playbooks z.B. schon angepasst worden, was nun unter Kilo zu Fehlern führt.

Bei der Beobachtung der Fehlersuche wurde mir nun auch klar, warum ich die ersten Tage mit soviel Theorie verbracht hatte. Ich war nun ansatzweise in der Lage, der Suche im und Navigation durch das System zu folgen. Der Vorteil der auftretenden Fehler für mich war, dass mir dadurch die Komplexität im Aufbau so eines OpenStack deutlich wurde. Die vielen Agents, die im Hintergrund der verschiedenen Stack Unterprogramme laufen, wer welche Informationen zur Installation benötigt. Aber ich lernte auch, dass es manchmal Fehler gibt, die nicht ganz erklärbar sind und dann durch Manipulation einzelner Varibalen übergangen werden.

Nach einigen Stunden Installation und Fehlersuche war es dann soweit. Die Installation war abgeschlossen. Man darf aber nicht glauben, dass sich das System einfach starten lässt. Zuerst sucht man sich die zugehörige IP. Da in unserem Fall der Controller jedoch zwei Netzwerkkarten hatte, bekamen wir keinen Zugang zum Log In Screen. Da es auch schon spät war, machten wir dann Feierabend.

Am nächsten Tag (Tag 5) versuchten wir den Zugriff über ein sshuttle. Eine sehr interessante Technik, mit der ich mich definitiv noch auseinander setzen muss. Wenn ich es richtig verstanden habe, wird eine Art Tunnel im Hintergrund zu dem Server aufgebaut, mit Hilfe dessen dann eine "normale" Kommunikation z.B. via Browser erfolgen kann. Das Handling ist jedoch im Gegensatz zu einer VPN Verbindung wesentlich einfacher.

Nachdem die sshuttle Verbindung eingerichtet war, konnten wir den Log In Screen des Test-OpenStacks aufrufen. Da ich mit dem Dashboard des OpenStacks schon etwas Erfahrung habe, konnte ich erkennen, dass die Installation ebenfalls eine fertige Instanz incl. FloatingIP und einen Router im Bauch hatte. Dafür fehlten im Gegensatz zu den mir bisher bekannten Plattformen komplett die Abbilder. Im Rahmen einigen Tests stellte sich heraus, dass der Konsolen-Zugriff aus der Instanz heraus nicht funktionierte. Daraufhin wurde über das Konfigurationsfile (leider weiß ich nicht mehr welches) einfach eine andere Terminalvariante eingebunden. Diese lies sich auch starten, wies dann allerdings den Nachteil auf, dass sie ein unbekanntes Keyboard-Layout mitbrachte, welches sich auch nicht überschreiben lies. Die Herausforderung bestand nun darin, dass wir das ":" Zeichen nicht fanden ;-), welches zum Log In in eine cirros-Instanz jedoch zwingend notwendig ist.
Nach einiger Zeit und Elimination von noch mehr Ungereimtheiten, wurde auf den ursprünglichen Konsolentyp zurück gewechselt, welcher dann auch direkt den Dienst mit dem gewünschten Keyboard-Layout aufnahm.

Nachdem mein ssh-Key hinzugefügt war, konnte ich starten. Ich startete von meinem Rechner eine sshuttle Verbindung und konnte mich dann einloggen. Aufgrund der geringfügig besseren Verbindungsmerkmale der Internetverbindung im Gegensatz zu meiner heimatlichen Verbindung, probierte ich dann mal, ein Abbild hochzuladen, legte einen neuen Nutzer an, verknüpfte die Instanzen mit den Netzwerken und versuchte gewisse Vorgehensweisen im Terminal nachzuvollziehen. Vor allem versuchte ich mir die Tab-Taste zu verinnerlichen ;-)

Zum Abschluss versuchte ich dann noch einen OpenStack AIO zu bauen http://docs.openstack.org/developer/openstack-ansible/developer-docs/quickstart-aio.html Dazu installierte ich zuerst einen Server unter einer KVM mit Hilfe des Virt-Managers. Danach führte ich das Skript aus, welches in der Anleitung aufgeführt ist. Allerdings beschwerte er sich kurze Zeit später darüber, dass der verfügbare Speicherplatz nicht ausreichen würde. Es stellte sich bei genauerem Durchblick der entsprechenden ansible Datei heraus, das dort 80GB * 0,75 angegeben waren, anstatt der Minimumangabe aus der Anleitung (50GB). Da es nicht möglich war, den verfügbaren Speicher auf diesem Rechenr zu erweitern (User-Restriktionen) haben wir dann einfach die entsprechende Angabe im Skript geändert. Und siehe da, es lief :-) 

Allerdings nicht lange. Da es allerdings schon wieder sehr spät war, und es ja auch mein letzter Tag war, haben wir das Image einfach auf meinen privaten Rechner kopiert. Nach der Installation des Virt-Managers haben wir dann sogar noch die Größe des Images auf die geforderten 80GB erweitert. Ich bin immer wieder überrascht, was alles möglich ist.

Was ist nun das Resume meiner "OpenStack-Woche"?

Mein Ziel war es, Praxis zu sehen und heraus zu finden, wo ich stehe. Dieses Ziel habe ich vollumfänglich erreicht und sogar wesentlich mehr. 

• Ich weiß jetzt, dass ich auf dem richtigen Weg bin. Das ich genau das machen möchte. Diese Komplexität der Themen war mir zwar bisher nicht bewusst, aber es vereinigt viele Themen, so dass es sicher nie langweilig wird.
• Durch den Kontakt mit einem kleinen Ausschnitt Realität wurde mir klar, dass ich das mit der Bedienung des OpenStacks bisher schon richtig verstanden hatte
• Ich habe jetzt eine konkretere Vorstellung davon, was mich erwartet. Die Folge davon ist, dass meine Motivation gerade wieder sprunghaft angestiegen ist.
• Ich habe Themen, wie auch konkrete Anlaufpunkte zum Lernen bekommen. Vor allem bin ich mir jetzt bewusster, was ich lernen muss, um die Systeme zu verstehen.
• Ich habe sehr interessante Menschen kennen gelernt und wieder einmal bewundernd die Linux-Mentalität genießen dürfen. Die Firma hat ja nicht wirklich einen Benefit, wenn ich komme und viele Fragen stelle
• Der Weg wird weiter sein, als ich dachte. Aber ich freue mich darauf, loszulegen :-)

Diese Woche war eine meiner beeindruckendste Wochen überhaupt. Zum einen zu sehen, wie routiniert da durch die Netzwerke, Agents, Nodes und vieles mehr agiert wird. Dazu alles über die Kommandozeile. Die vielen Bereiche, die tangiert werden: Netzwerktechnik, Netzwerkkommunikation, http, Datenbanken, und so vieles mehr. Das Zusammenspiel aller Beteiligten, damit ein administratives Werkzeug heraus kommt, welches der User nur noch bedient, ohne auch nur Ahnung davon haben zu müssen, was im Hintergrund abgeht. Die Möglichkeiten im running Status über die Konfigurationsdateien immer wieder Änderungen vornehmen zu können.

Ich bin zutiefst beeindruckt und total fasziniert. Ich werde daran arbeiten, dass ich den Einstieg finde, da ich das Gefühl habe hier richtig zu sein. 

lxd - Probleme mit der lxd-bridge und dnsmasq

Ergebnis für den eiligen Leser:
Um LXD als Anfänger auf einem VM Ubuntu Server laufen lassen zu können, darf kein weiterer DNS Server auf dem System vorhanden sein. Bind muss unbedingt deaktiviert sein.
Nach der Initialisierung kann die lxd-bridge mit ip a gesehen werden und die beiden LXD-Services sollten im active Status sein.

2018-05-07 Update für Ubuntu 18.04 Desktop am Ende des Posts
-----------------------------------------------------------------------------------------------------------------------

Heute habe ich meine ersten Versuche mit LXD, der Containerplattform von Canonical, hinter mir...

• Ausgangsposition: Ubuntu Server 16.04.4 LTS als VM (VirtualBox), NAT und Host-only Netzwerkkarten
• Getting started with command line 

Bei meiner Ubuntu Version war LXD schon vorinstalliert, wobei die Installation unter Ubuntu auch keine Herausforderung darstellt:

$sudo apt-get install lxd lxd-client

Dann der nächste Schritt in der Anleitung:

$sudo lxd init

Es gab verschiedenste Einstellungen, die vorgenommen werden sollten. Ich habe fast alle Fragen mit der default Antwort beantwortet, bis auf die Frage, ob LXD übers Netzwerk erreichbar sein soll. Default war nein und ich wählte ja. Zu diesem Zeitpunkt war es mir auch noch nicht möglich, zfs als storage backend zu verwenden.

Bei der Frage nach der bridge, verwendete ich die Vorschläge, die mir LXD machte. Meine Annahme war, dass LXD freie IP-Adressen und Namen heraus suchen würde.
Die Einstellungen des 1. Versuchs meiner Bridge:
Name:                     lxdbr0
IPv4                        10.175.19.1/24
DHCP Range         10.175.19.2 bis 10.175.19.254
IPv6                        fd56:732c:8095:29a5::1/64

Nachdem ich mich durch alles durchgeklickt hatte, bekam ich die Meldung:

error: Get http://unix.socket/1.0: read unix @->/var/lib/lxd/unix.socket: read: connection reset by peer

Hmmm.... und nu???

Als erstes checkte ich mein System:
lxd.service läuft nicht, aufgrund fehlender Anhängigkeiten; Restart schlägt fehl.

Dann versuchte ich die Fehlermeldung zu googeln. Ich fand einen Post, in dessen Verlauf empfohlen wurde, das Kommando 

$bash -x /usr/lib/lxd/lxd-bridge start 

auszuführen. Das habe ich dann versucht. Meine Ausgabe des Befehls war völlig identisch zu dem Post, nur dass der Ratgeber dort darauf verwies, dass wohl der Kernel nicht in der Lage wäre, eine bridge anzulegen, aufgrund der Meldung 

+ ip link add dev lxdbr0 type bridge
RTNETLINK answers: Operation not permitted

Leider übersah der Ratgeber, dass wenn man versucht das lxd-bridge Skript ohne sudo zu starten, keine Bridge angelegt werden kann...

Daher versuchte ich das Ganze erneut mit sudo... und siehe da, die Fehlermeldung, dass die Bridge nicht angelegt werden könne, erschien nicht mehr ;-)

Dafür kam eine andere Fehlermeldung. Nach ersten Recherchen stolperte ich über die Meldung, dass die IP Adresse schon in Verwendung sei. Das verstand ich nicht wirklich. Das Skript löscht im Nachgang die Bridge wieder komplett.

Daraufhin machte ich ein $ip a : Keine Bridge zu sehen, keine IP Adresse, die passen würde. Keine Möglichkeit etwas zu ändern.

Nun versuchte ich ein ping 10.175.19.1 -> Interessante Reaktion: 1. Ping auf die IP 10.175.19.1, danach jeder weitere Ping auf 172.25.21.2... Hä??? Wo kommt denn die IP her???

traceroute, nslookup, host... egal was ich probierte, ich bekam keine Antwort. (Und diese Antwort habe ich bisher auch noch nicht gefunden)

Dann schaute ich mir das Skript /usr/lib/lxd/lxd-bridge mal genauer an und sah, das es die Datei /etc/default/lxd-bridge gibt. Nachdem ich auch in diese rein geschaut hatte, fand zumindest eine Möglichkeit, die IP-Adresse zu ändern, bzw. LXD sozusagen wieder in einen jungfräulichen Zustand zu versetzen, damit $sudo lxd init erneut ausgeführt werden kann. 

Leider ist die Dokumentation von LXD selbst nicht sehr hilfreich. Ich fand zwar einen Eintrag zum Thema Konfiguration Network, jedoch der dort aufgeführte Befehl "lxc network set blabla" existiert überhaupt nicht. 

Im nächsten Schritt änderte ich das Konfigurationsfile /etc/default/lxd-bridge mit einer neuen IP Adressen. Diesmal wählte ich eine IP Adresse aus dem 192.168.56.x Bereich, da meine VMs untereinander (host-only) in diesem Netzwerk kommunizieren. Leider führte auch diese Änderung nicht zum Erfolg. Gleiche Abfolge von Meldungen. Und wiederum die Fehler-Meldung, dass die IP schon belegt sei.

Bei genaueren Untersuchung der Ausgabe des bash -x Befehls stellte ich fest, dass die Bridge angelegt wird und auch mit den IP-Adressen versorgt wird. Das scheint alles zu funktionieren. Dann kommt ein dnsmasq Befehl, der mit jeder Menge Optionen aufgerufen wird. Und genau an diesem Punkt kommt die Fehlermeldung, dass die IP-Adresse schon belegt ist. Ich habe versucht, den Aufruf mit den Optionen zu verstehen, habe es aber nach geraumer Zeit aufgegeben.

Zwischenzeitlich hatte ich auch noch die VM gewechselt, und dieser eine direkte Verbindung zur Außenwelt über eine normale Netzwerkbrücke gegeben. Aber auch das half nicht.

Dann habe ich nochmal gegoogelt. Und zwar nach der Fehlermeldung dnsmasq: failed to create listening socket in Verbindung mit lxd bridge. Unter den Ergebnissen stieß ich auf einen Eintrag LXD Failing to start der mein Problem beschrieb. Ich habe daraufhin mein System auf zusätzlich deklarierte DNS-Server untersucht (und tatsächlich einen gefunden). Nachdem ich den raus geworfen hatte, war nur noch der Standardeintrag in der /etc/resolv.conf zu finden. Einmal aufräumen (rm /etc/default/lxd-bridge) und ein Reboot. Erneuter Versuch der Initialisierung von LXD -> Möööp... Nö!

Dann habe ich mir nochmal alle Services vorgenommen. Und siehe da, bei mir lief der bind9 service. Dieser Service stellt einen DNS Server dar. Nicht gut, da wir ja dnsmasq verwenden wollen und beide Services auf den gleichen Port zugreifen. Daher habe ich dann mal 

$sudo systemctl stop bind9
$sudo systemctl disable bind9 gemacht

Wieder aufgeräumt und das System neu gestartet...

System vor dem nächsten Versuch:

Dann der nächste Versuch $sudo lxd init:

Und kaum zu glauben!!! Es hat tatsächlich funktioniert!!!!!!!!!!!
Kontrolle mit $ip a und auch die Services

Ergebnis:
Um LXD als Anfänger auf einem Ubuntu Server laufen lassen zu können, darf kein weiterer DNS Server auf dem System vorhanden sein. Bind muss unbedingt deaktiviert sein.
Nach der Initialisierung kann die lxd-bridge mit $ip a gesehen werden und die beiden LXD-Services sollten im active Status sein.
Es war mal wieder ein sehr lehrreicher Tag für mich ;-)

Update 2018-05-07:
Heute habe ich unter Ubuntu 18.04 Desktop lxd erneut installiert und initialisiert. Dabei sind mir ein paar Veränderungen bei der Initialisierung aufgefallen:
Die Abfrage hat sich verändert. Es sind Punkte, wie die Verbindung zu einem MAAS Server und der Frage nach der Aktualisierung alter Images dazugekommen. Meine Antworten seht ihr hier.

ilonka@lpic2:~$ sudo lxd init
Would you like to use LXD clustering? (yes/no) [default=no]: 
Do you want to configure a new storage pool? (yes/no) [default=yes]: 
Name of the new storage pool [default=default]: zfs
Name of the storage backend to use (dir, lvm, zfs) [default=zfs]: 
Create a new ZFS pool? (yes/no) [default=yes]: 
Would you like to use an existing block device? (yes/no) [default=no]: 
Size in GB of the new loop device (1GB minimum) [default=15GB]: 
Would you like to connect to a MAAS server? (yes/no) [default=no]: 
Would you like to create a new network bridge? (yes/no) [default=yes]: 
What should the new bridge be called? [default=lxdbr0]: 
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 
Would you like LXD to be available over the network? (yes/no) [default=no]: yes
Address to bind LXD to (not including port) [default=all]: 
Port to bind LXD to [default=8443]: 
Trust password for new clients: 
Again: 
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] 
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: 

Leider gab es keinerlei Rückmeldung. Eine kurze Kontrolle ergab:

und mit Hilfe $ ip a s konnte ich auch sehen, dass die bridge angelegt wurde. Allerdings ist mir aufgefallen, dass die Datei /etc/default/lxd-bridge nicht mehr verfügbar ist, was jedoch mit dem Networkmanager, den ich auf dem Server nicht verwendete, zusammenhängen könnte.

Und noch ein kleiner Hinweis :-) Möchte man sich alle verfügbaren Images anschauen, die man aus der Registry laden kann verwendet man den Befehl

$lxc image list images:

Wichtig ist der Doppelpunkt am Ende, sonst gibt es kein Ergebnis ;-)

CentOS 7 in VirtualBox

Image ziehen

Einrichten der VM mit NAT Netzwerk

Installation

Rootpasswort und Benutzer während der Installation anlegen

Wenn kein Internet da ist, Netzwerkkonfiguration prüfen

Wenn keine IP Adresse gezogen wurde, Anleitung  http://techantidote.com/ifconfig-does-not-show-eth0-in-centos-6-on-virtualbox/

MAC Adresse der Netzwerkkarte ermitteln

Ändern der /etc/sysconfig/network-scripts/ifcfg-enp03

Ich musste nur noch hinzufügen:
HWADDR=<Mac-Adresse>
NM_CONTROLLED=NO
Ändern von ONBOOT=yes (Voreinstellung war no)

Ändern der /etc/sysconfig/network

NETWORKING=yes

service restart network

et voilá... es geht

mounten von /dev/cdrom unter /mnt

yum install dkms

Leider findet CentOS das dkms paket nicht, wenn EPEL nicht vorher installiert wurde

wget installieren
Epel Paket downloaden (Version prüfen)

 wget http://ftp.wrz.de/pub/fedora-epel/7/x86_64/Packages/e/epel-release-7-11.noarch.rpm

rpm --import https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-7

rpm -K epel-release-7-2.noarch.rpm

epel-release-7-2.noarch.rpm: rsa sha1 (md5) pgp md5 OK

yum install epel-release-7-2.noarch.rpm

(Habe jetzt gelesen, dass das Epel-Paket seit CentOS6 in den Repos enthalten ist)

yum install groupinstall "Development Tools"
yum install kernel-devel

Danach ins gemountete Verzeichnis wechseln und /.VBoxLinuxAdditions.run ausführen

Bei mir erscheint jedoch weiterhin die Meldung, dass die neuen Kernel nicht gebaut werden können, da er mit einer Header-Datei nicht zufrieden ist. Laut dem System ist jedoch alles aktuell und identisch mit der Kernelversion (unam -r)

Da mit so einem kleinen Terminalfenster nicht zu arbeiten ist, habe ich beschlossen, per ssh von einer Ubuntu 16.04. VM auf den CentOS Server zuzugreifen. Jedoch stellte sich dabei heraus, dass dadurch, dass beide VMs mit NAT Netzwerken arbeiten, die sich nicht sehen können.

Lösung in diesem Fall: Hinzufügen bei beiden VMs einer Host-only Schnittstelle. Reboot -> geht!!!

Microservices

Meine Vorstellung, was Microservices sind am 2018-03-03:

Nach dem Artikel auf https://thenewstack.io/led-amazon-microservices-architecture/ wurde z.B. der "Buy"-Button genannt. Dieser wurde als ein eigener Service deklariert.

Im Wikipedia Artikel werden als Beispiele Bestellvorgang, Registrierung und Rechnungserstellung genannt.

Daher erkläre ich mir nun Microservices als kleinen Teil, eines großen Ganzes. Nimmt man ein großes Gesamtprojekt (eine Website, oder eine Software, die zum Beispiel für die Personalverwaltung eingesetzt wird), wird dieses Projekt in kleine Prozesse aufgeteilt. Ein einzelner Prozess wird unabhängig von den anderen Prozessen (weiter)entwickelt und kommuniziert über eine definierte Schnittstelle (RestAPI) mit den anderen Prozessen.

Alles zusammen ergibt dann das Gesamtprojekt.

Innerhalb der Microservices sind die Entwickler autark in der Wahl der Programmiersprachen, etc., da die Kommunikation der einzelnen Services über Schnittstellen erfolgt.

Mal schauen, ob diese Vorstellung in der Realität Bestand hat