Select Page

NETWAYS Blog

Hiera: Ein Key Value Backend für Puppet

by | Oct 7, 2014 | , ,

Um Daten von den Puppet Modulen zu trennen wurde das Backend Hiera eingeführt. In der einfachsten Form werden Daten aus einer YAML-Datei geholt. Diese befüllen die Parameter der Puppet Klassen und können zudem abhängig von Eigenschaften der Hosts (genauer Fakten `facter -p`) gemacht werden (z.B. Hostname, Betriebssystem, Hersteller des Raidcontrollers usw.). Somit kann man nicht nur in den Puppet Klassen selbst sondern auch im Backend auf verschiedenen Eigenschaften der Server reagieren.
Hiera installiert man am besten über den Paketmanager. Ab der Version 3.x kommt Hiera als Abhängigkeit von Puppet mit. Die Konfigurationsdatei hiera.yaml ist relativ einfach und schnell erklärt und liegt für gewöhnlich in /etc/puppet/.

$ cat /etc/puppet/hiera.yaml
---
:backends:
  - yaml
:hierarchy:
  - "fqdn/%{::fqdn}"
  - "%{operatingsystem}"
  - base
:yaml:
  :datadir: '/hieradata/%{::environment}'
:logger: console

Als Backend werden YAML-Dateien verwendet, diese liegen im Verzeichnis /hieradata/%{::environment}. Der Key hierachy gibt an welche YAML-Dateien im speziellen angezogen werden. Die Einträge von hierachy werden von oben nach unten abgearbeitet und können Variablen enthalten welche von den Hosts geliefert werden (`facter -p`). Ein kurzes Beispiel:
Auf dem Debian Server server1.netways.de wird `puppet agent -t –environment testing` ausgeführt. Hiera sucht somit die Daten in folgenden Dateien in der angegeben Reihenfolge:
– /hieradata/testing/fqdn/server1.netways.de.yaml
– /hieradata/testing/Debian.yaml
– /hieradata/testing/base.yaml
Sollte eine der YAML-Dateien nicht existieren wird diese einfach übersprungen. Wann und wie Puppet Aufrufe an Hiera sendet wird im nächsten Blogpost von mir erklärt.
Mit Hiera kann man sehr einfach und schnell seine Daten aus den Puppet Module fern halten und flexibel auf seine eigene Infrastruktur reagieren. Durch verschiedenen Backends können auch andere Datenquellen wie z.B. eine CMDB angezogen werden. Mehr Ideen was man alles mit Hiera machen kann gibt es natürlich auch in unseren Puppet Architect Schulungen.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Ceph Datastore, OpenNebula und Authentifizierung mit CephX

by | Jul 22, 2014 | , , , , ,

OpenNebula kann Ceph bereits seit Release 4.0 als Datastore einbinden. Wie man die beiden Systeme integriert wird in der OpenNebula Dokumentation beschrieben. Natürlich benötigt man einen laufenden Ceph Cluster und einen Hostsystem der kompatibel dazu ist. Im Augenblick eignet sich hier Ubuntu LTS, da die Kernelversionen neu genug sind um aktuelle Features von Ceph zu unterstützen und zudem ist auch eine aktuelle Version von Ceph in den Repositories.
Neben der gewohnten Installation und Konfiguration eines OpenNebula Nodes muss man noch das Paket ceph installieren, was in den Abhängigkeiten die Libraries für rados und rbd mit sich bringt. Damit man den Ceph Cluster vom Hostsystem ansprechen kann, muss man noch die ceph.conf und den Keyring des gewünschten Users kopieren. Der folgenden Befehl erstellt einen User one mit Zugriff auf den Pool one.

$ ceph auth get-or-create client.one mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=one'

[client.one]
	key = aAaaaLaaKaaQaaRaaAaaYaaZaaBaaaaaaaaa==

Als Ausgabe sieht man den Key des Users. Dieser muss in der Datei /etc/ceph/ceph.client.one.keyring auf dem Hostsystem abgelegt werden. `rados -p one –id=one df` sollte jetzt den freien Speicherplatz im one Pool anzeigen. Der User oneadmin sollte lesend auf den Keyring zugreifen dürfen.
Bevor OpenNebula eine VM deployed, wird überprüft ob im Datastore genügend Speicherplatz frei ist. Dazu wird der Befehl `rados df` aufgerufen, komplett ohne Parameter, weshalb der Benutzer client.admin anstatt client.one verwendet wird. Ein Pull Request [1] welcher dies ändert hat es bisher leider nicht in das offizielle Repo geschafft.
Als Workaround kann man entweder zusätzlich den Keyring des client.admin auf dem Hostsystem ablegen oder im Monitor Skript [2] die Parameter des rados Aufrufs um “-p one –id=one” erweitern (angenommen der verwendete Ceph Pool heißt one).
Das alles nur um zu überprüfen ob genügend Speicherplatz im Datastore frei ist. Damit man VMs im Ceph Datastore erstellen kann muss sich auch libvirt gegen CephX authentifizieren. Dies ist aber bereits in der OpenNebula Dokumentation beschrieben.
[1] https://github.com/OpenNebula/one/pull/27
[2] src/datastore/ceph/monitor

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Fog OpenNebula Provider im Upstream

by | Jul 1, 2014 | , , , ,

Unser Fog Provider für OpenNebula ist mittlerweile auch im Upstream Master angekommen und ist somit im nächsten Release von Fog enthalten. Unsere aktuellen Erweiterungen des Providers sind weiterhin im Netways GitHub Repository zu finden und werden natürlich regelmäßig an den Upstream weitergereicht.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

OpenNebula Fog Provider

by | May 27, 2014 | , , , , ,

Letzte Woche habe ich unser Foreman OpenNebula Plugin vorgestellt. Die Kommunikation zwischen beiden Systemen übernimmt der OpenNebula Fog Provider. Natürlich kann man den Provider auch unabhängig von Foreman benutzen. Im kurzem Beispiel unten wird eine Verbindung zur One-RPC Schnittstelle aufgebaut, ein neues VM Gerüst erstelle und mit einem Template aus OpenNebula befüllt und erweitert. Und am Ende wird die VM natürlich noch gestartet.
Zuerst müssen wir aber natürlich die Source holen und die benötigten Ruby gems installieren. Das erledigt git und bundler für uns (apt-get install git bundler).

$ git clone https://github.com/netways
$ cd fog
$ bundle install

Zum testen starten wir eine interaktive Ruby Konsole (irb) und binden die Fog Bibliothek mit ein.

$ irb
> require './lib/fog.rb'

Die folgenden Befehle werden alle in der irb Konsole ausgeführt!
Innerhalb der irb öffnen wir eine Verbindung zu OpenNebula und lassen uns die vorhanden Templates (Flavors) geben.

# connect to your one rpc
con = Fog::Compute.new(
    {
      :provider => 'OpenNebula',
      :opennebula_username => 'user',
      :opennebula_password => 'password',
      :opennebula_endpoint => 'http://oned.domain:2633/RPC2'
    }
  )

servers.new erstellt ein neues Gerüst einer VM. Dieses enthält die verschiedenen Attribute der VM.

# create a new vm (creates the object, the vm is not instantiated yet)
newvm = con.servers.new

Die VM enthält auch ein Attribut flavor, in dem ein OpenNebula Template gespeichert werden kann. In diesem Beispiel wir das Template mit der ID 4 verwendet.

# set the flavor of the vm
newvm.flavor = con.flavors.get 4
# set the name of the vm
newvm.name = "MyVM"

Attribute aus dem Template können überschrieben werden, bzw. müssen gesetzt werden, falls diese im Template nicht definiert wurden.

# set cores and memory (MB)
newvm.flavor.vcpu = 2
newvm.flavor.memory = 256

Im OpenNebula muss ein Interface einem Netzwerk zugewiesen werden. Zuerst wird ein vorhandenes OpenNebula Netzwerk geholt und an ein neu erstelltes Interface zugewiesen.

# create a new network interface attached to the network with id 1 and virtio as driver/model
network = client.networks.get(1)
nic = con.interfaces.new({ :vnet => network, :model => "virtio"})

Das neu erstellte Interface wird dem VM-Gerüst hinzugefügt und mit der Methode save wird die VM gespeichert, d.h. gestartet.

# Attach the new nic to our vm
newvm.flavor.nic = [ nic ]
# instantiate the new vm
newvm.save
Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Foreman, Fog und OpenNebula

by | May 20, 2014 | , , , ,

Jeder der hin und wieder einen Blick in unseren Blog wirft hat vermutlich festgestellt, dass Foreman das bevorzugte Tool zur Verwaltung unserer IT-Infrastruktur ist und uns in Sachen Provisionierung und Configuration Management viel Arbeit abnimmt. Zur Verwaltung unserer virtuellen Maschinen setzen wir auf OpenNebula, welches mit eigener Oberfläche, CLI und XML-RPC alle Möglichkeiten zum Erstellen und Verwalten von virtuelle Maschinen bietet. Schön wäre es natürlich wenn Foreman über die OpenNebula API virtuelle Maschinen anlegen und löschen kann, so dass man zur Provisionierung neuer VMs nur noch im Foreman klicken muss. Hier kommt Fog ins Spiel. Foreman verwendet die Fog Bibliothek um andere Provider wie libvirt, ovirt etc. anzusteuern. Für uns war das eine gute Ausgangslage um Foreman und OpenNebula zusammenzuführen und einen eigenen OpenNebula Fog Provider zu schreiben welcher dann von unserem Foreman-One Plugin verwendet.
Das Ergebnis habt ihr ja schon letzte Woche im VideoBlog gesehen. Aber wie installiert man das Ganze jetzt?
Als erstes holt man sich die aktuellen stabilen Foreman Sourcen, fügt noch unser foreman-one Plugin hinzu und installiert Foreman wie in der Doku beschrieben:

git clone https://github.com/theforeman/foreman.git
cd foreman
git co -b 1.5-stable origin/1.5-stable

Um im Foreman ein Plugin zu installieren fügt man seiner lokalen Gemfile folgende Zeile hinzu:

$ cat bundler.d/Gemfile.local.rb
gem 'foreman_one',  :git => "https://github.com/netways/foreman-one.git", :branch => "master"
gem "fog", :git => "https://github.com/fog/fog.git", :branch => "master"

Die zweite Zeile stellt sicher, dass unsere Fog Version verwendet wird. Dies ist solange nötig bis das Fog Projekt unseren OpenNebula Provider mit aufnimmt. Damit bundle beim nächsten Schritt keinen Konflikt erkennt muss man folgende Zeile aus bundler.d/fog.rb entfernen:

gem 'fog', '~> 1.21.0'

Von jetzt an folgt man nur noch der offiziellen Foreman Dokumentation zum installieren einer Testumgebung:

cp config/settings.yaml.example config/settings.yaml
cp config/database.yml.example config/database.yml
gem install bundler
bundle install
rake db:migrate
rake db:seed assets:precompile locale:pack
rails server

Auf http://localhost:3000 (admin/changeme) findet man jetzt die neue Foreman Version und unter Infrastruktur -> Computer Resources klickt man ohne große Mühen seine OpenNebula Instanz hinzu. Das seht ihr aber besser im VideoBlog.
Ich würde mich über Feedback jeder Art freuen! Bitte probiert den OpenNebula Provider aus und haltet euch mit Kritik nicht zurück! Auch würde uns interessieren wie ihr eure VMs mit OpenNebula und Foreman provisioniert und welche Features hier aktuell noch fehlen, die euch das Leben leichter machen würden!
Infos und den aktuellen Stand findet ihr an verschiedenen Stellen. Der Quelltext ist natürlich am einfachsten aus dem Netways GitHub Repo zu bekommen. Neuerungen und Beispiele wie man den Fog OpenNebula Provider verwendet gibt es natürlich hier im Blog und in den Readme Dateien.
Weiter Information findet ihr auch noch auf den Mailinglisten, Bugtrackern etc.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Trainings

Web Services

Events