With a little Help from my Chef …

Ich wollte abseits von Puppet und Ansible mal eine andere Automatisierungssprache anreißen. Wieso also nicht mal Chef!

Wie fängt man am einfachsten mit Chef als Automatisierungssprache an?

Chef besteht simpel gesagt aus ruby Skripten welche sequentiell abgearbeitet werden. (Loops gehen schon, würden aber den Blog Artikel sprengen)
Wir fangen mit einem Ruby file an welches wir Notice.rb nennen.
Als praxisnahes Beispiel legen wir eine “Textdatei” in /etc/ an. Dies könnte somit eine prekonfigurierte Konfigdatei eines Programmes sein.

file '/etc/motd' do
  content 'Next maintenance window is Fri from 10 pm to Sat 3 am'
end

Woraus besteht Recipe Codeblock ?

File als erstes gibt den Ressourcen Typ an. dieser kann auch Package sein oder Service sein.
Es gibt noch viele mehr auf der Chef Seite in der dortigen Doku können Sie erforscht werden 🙂
Danach folgt der Pfad inklusive des Dateinamens hier in diesem Fall ‘/etc/motd’ es könnte aber auch z.B. ‘/home/User_xy/.bashrc’ sein.

Gefolgt von dem Loopblock welcher mit do eingeleitet wird und mit end geschlossen.
Dazwischen sind die Anweisungen was abgearbeitet werden soll bzw. welche Attribute geändert oder modifiziert werden sollen.
Da wir in diesen Fall die Datei erstellen haben wir ein content Attribut welches den Inhalt der Datei definiert.
Darin eine simple Benachrichtigung plain Text.

Wie erreichen wir nun mit diesem Ruby file unseren gewünschten Zustand ?
Ähnlich wie bei Ansible oder Puppet benötigen wir einen Agent-Daemon der für uns die Anweisungen umsetzt. Dieser ist chef-apply welches als Kommando duch das Chef DK (Development Kit installiert wird)
Dies findet man unter: https://downloads.chef.io/chefdk/

Da ich doch leider sehr CentOS affin bin nehme ich mir das RHEL Package.
https://packages.chef.io/files/stable/chefdk/3.3.23/el/7/chefdk-3.3.23-1.el7.x86_64.rpm
mit einem simplen & fixen

rpm -ivh  chefdk-3.3.23-1.el7.x86_64.rpm

wird das Paket installiert und bietet uns nun die Chef Kommandos an.

Ordentliche Mensche erstellen einen Ordner in dem wir unsere Ruby Recipes unterbringen.
Chef bietet aber auch ein Standard Template an welches wir nutzen können aber zu erst erstellen wir uns einen Ordner.

mkdir ~/cookbooks && cd cookbooks
chef generate cookbook motd_notify_downtime

Nun kreiert uns Chef ein Standard cookbook ohne spezifischen Inhalt.
Hier die Baumstruktur eines solchen Ordners.

tree ~/cookbooks/motd_notify_downtime/
motd_notify_downtime/
├── Berksfile
├── CHANGELOG.md
├── chefignore
├── LICENSE
├── metadata.rb
├── README.md
├── recipes
│   └── default.rb
├── spec
│   ├── spec_helper.rb
│   └── unit
│       └── recipes
│           └── default_spec.rb
└── test
└── integration
└── default
└── default_test.rb

In den unter Ordner namens recipes sollen wir unsere notice.rb bewegen.

mv notice.rb ~/cookbooks/motd_notify_downtime/recipes
rm default.rb
mv notice.rb default.rb

Ob unser Automatismus auch funktioniert prüfen wir mit einem Aufruf.
Wir haben folgende möglichkeiten:

chef-apply notice.rb

für das einzelne Rezept oder für das ganze cookbook welches wir gerade erstellt haben

cd cookbooks && chef-client --local-mode --runlist 'recipe[motd_notify_downtime]'

Dies sollte von dem folgenden Output begleitet werden

chef-client --local-mode --runlist 'recipe[motd_notify_downtime]'
[2018-10-25T16:14:05+00:00] WARN: No config file found or specified on command line, using command line options.
Starting Chef Client, version 14.5.33
resolving cookbooks for run list: ["motd_notify_downtime"]
Synchronizing Cookbooks:
- motd_notify_downtime (0.1.0)
Installing Cookbook Gems:
Compiling Cookbooks...
Converging 1 resources
Recipe: motd_notify_downtime::default
* file[/etc/motd] action create
- create new file /etc/motd
- update content in file /etc/motd from none to b564d0
--- /etc/motd	2018-10-25 16:14:08.249701189 +0000
+++ /etc/.chef-motd20181025-9251-18htv9n	2018-10-25 16:14:08.249701189 +0000
@@ -1 +1,2 @@
+To All Users who Login into this Machine next maintenance window is Friday from 10 pm to Saturday 3 am
- restore selinux security context

Running handlers:
Running handlers complete
Chef Client finished, 1/1 resources updated in 02 seconds

Mit einem

cat /etc/motd

erhalten wir das folgende Ergebnis

Next maintenance window is Fri from 10 pm to Sat 3 am

Auch ein weiterer Lauf des Chef-clients würde nichts an dem Inhalte ändern. (Idempotent)

chef-client --local-mode --runlist 'recipe[motd_notify_downtime]'
[2018-10-25T16:18:28+00:00] WARN: No config file found or specified on command line, using command line options.
Starting Chef Client, version 14.5.33
resolving cookbooks for run list: ["motd_notify_downtime"]
Synchronizing Cookbooks:
- motd_notify_downtime (0.1.0)
Installing Cookbook Gems:
Compiling Cookbooks...
Converging 1 resources
Recipe: motd_notify_downtime::default
* file[/etc/motd] action create (up to date)

Running handlers:
Running handlers complete
Chef Client finished, 0/1 resources updated in 02 seconds

Ich hoffe ich hab euch am Beispiel Chef etwas über den Tellerrand hinaus schauen lassen und vielleicht hat der ein oder andere Lust bekommen etwas mit Chef zu automatisieren.

Servus !

David Okon

Autor: David Okon

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Ruby Applikationen testen mit RSpec und WebMock

Das Testen von Software begleitet mich von Projekt zu Projekt. Bei bisherigen Entwicklungen habe ich immer wieder auf RSpec zurück gegriffen, ein tool zum testen von Ruby Applikationen. Es zeichnet sich durch eine relativ einfache Handhabung aus und eine Ausdrucksweise die an die menschliche Sprache angelehnt ist. Auch wenn nicht jeder mögliche einzutretende Fall getestet werden kann, tests geben Entwicklern Sicherheit wenn Änderungen am Code vorgenommen werden.

WebMock

WebMock ist eine Library die es einem ermöglich HTTP requests auszudrücken und Erwartungen an diese zu setzen. In Verbindung mit RSpec lässt sich WebMock verwenden um eine Ruby Anwendung zu testen die HTTP Requests ausführt, beispielsweise an eine API. Oft sind diese Requests nicht starr sondern werden dynamisch anhand von Parametern zusammen gesetzt. WebMock/RSpec hilft dabei unterschiedliche Fälle zu simulieren, Erwartungen zu definieren und diese mit zu prüfen.

WebMock ist als Gem verfügbar, die Installation ist daher relativ einfach:

user@localhost ~ $ gem install webmock

Als Beispiel verwende ich eine sehr simple Ruby Klasse. Deren einzige Methode ‘request’ sendet einen GET request an die URL ‘https://wtfismyip.com’. Abhängig vom Parameter ‘option’ wird die IP entweder in Textform oder als JSON abgefragt:

require 'net/http'
require 'uri'

class ApiCaller
  def self.request(option)
    uri = URI.parse("https://wtfismyip.com/#{option}")
    http = Net::HTTP.new(uri.host, uri.port)
    http.use_ssl = true
    request = Net::HTTP::Get.new(uri.request_uri)
    http.request(request)
  end
end

Mein Test beinhaltet den Aufruf der ‘request’ Methode. Der HTTP request wird simuliert und die Erwartung das ein Request an eine bestimmte URL stattfinden soll wird auch definiert.

require 'api_caller'
require 'webmock/rspec'

describe ApiCaller do
  describe '.request' do
    context 'given json parameter' do
      it 'requests json url' do
        stub_request(:get, 'https://wtfismyip.com/json')
        expect(ApiCaller.request('json')).
          to have_requested(:get, 'https://wtfismyip.com/json').once
      end
    end

    context 'given text parameter' do
      it 'requests text url' do
        stub_request(:get, 'https://wtfismyip.com/text')
        expect(ApiCaller.request('text')).
          to have_requested(:get, 'https://wtfismyip.com/text').once
      end
    end
  end
end

Beim testen sieht das nun folgendermaßen aus:

user@localhost ~ $ rspec --format documentation

ApiCaller
  .request
    given json parameter
      requests json url
    given text parameter
      requests text url

Finished in 0.00557 seconds (files took 0.37426 seconds to load)
2 examples, 0 failures
Blerim Sheqa

Autor: Blerim Sheqa

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.

Clustershell und Foreman-API

i-love-apisForeman bietet die Möglichkeit verschiedene Informationen über die Hosts einzusehen. Dazu gehören der Status, das Betriebssystem, Ressourcen etc. Möchte man nun, auf mehreren Hosts gleichzeitig ein Kommando absetzen, kann man sich auf jedem einzelnen einloggen oder eine Clustershell aufbauen.
Hierfür gibt es verschiedene Tools die dies erlauben. Eine Unbequemlichkeit die hier jedoch schnell aufkommt, ist das kopieren und einfügen der Hostnamen in die Commandline. Aus diesem Grund, habe ich etwas Zeit investiert und ein Ruby Script geschrieben, das es mir ermöglicht, mit festgelegten Filtern nach speziellen Listen von Hostnamen zu suchen und diese als eine einzige Ausgabe zu speichern. Ich habe für das erzeugen von Clustershells “csshX” im Einsatz, welches ich auch direkt mit eingebunden habe.

Das get_hosts Script gibt es als GIST.

In diesem Script wird zunächst eine “config.yml” geladen, in der die Foreman-URL und der Nutzername definiert sind. Eine Passwortabfrage erfolgt in diesem Script direkt auf der Commandline. Anschließend wird die Ausgabe der Foreman-API nach dem Auflisten aller Hostinformationen in JSON geparst und alle verfügbaren Parameter für die Hosts in das entsprechende Array gespeichert. Mit dem Parameter “-s / –server” gibt man einen String an, nachdem speziell gesucht werden soll. Diese Ausgabe wird zusätzlich mit angehängt.

Gefiltert wird nach:
1) Reports enabled
2) OS Ubuntu 14.04 / Debian 8
3) Kein Match auf net-* oder netways.de (Als Beispiel)

Von den selektierten Hosts werden die Hostnamen in einer Commandline-Ausgabe mit einem Leerzeichen getrennt ausgegeben. Verschiedene werden sich eventuell fragen: “Wofür brauche ich das? Wieso sollte ich so ein Script verwenden?”
Die Antwort ist einfach: Bequemlichkeit und live Übersicht, was gerade passiert. Die Suchparameter lassen sich sehr leicht anpassen und die Ausgabe des Scriptes wird etwas an Zeit der administrativen Aufgaben sparen, vorallem dann, wenn man mehr als nur 2 oder 3 Server mit Puppet bespielen lassen möchte.

user@computer ~/Documents/ruby/foreman $ ruby script.rb
Enter password:
[ ] Trying to establish a connection...
[OK] Password correct
[OK] Connection established
[ ] Collecting data...
[OK] Data collected
[RESULTS]
Ubuntu
csshX --login root test1.test.de test2.test.de test34.test.de test19.test.de mail.test.de icinga-001.test.de
Debian
csshX --login root icinga-002.test.de db-003.test.de db-021.test.de
Finished succesfully

Wie bereits erwähnt, ist hierfür noch eine “config.yml” Datei nötig, die gewünschte Parameter enthält. In diesem Fall die URL und den usernamen. Aber auch ein Gemfile, das sich in Ruby um bestimmte Versionen von Gems kümmert. (Mit einem “bundle install” können diese installiert werden)

Die config.yml und das Gemfile gibt es ebenfalls als GIST.

Eingebaute “rescue Execptions” im Script selbst, geben entsprechende Rückmeldung, sollte der Login oder eine der auszuführenden Verarbeitungsschritte fehlschlagen und brechen den Vorgang an dieser Stelle ab.

Marius Gebert

Autor: Marius Gebert

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun unter anderen um den Support und die Entwicklung unserer NWS Produkte. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack, über die Porgrammiersprache Ruby bis hin zu Puppet. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu haben.

May I introduce the Rubocop

When you are into developing Ruby code, or even Ruby near stuff like Puppet modules, or Chef cookbooks, there is a nice tool you should have a look at.

The RuboCop can help you writing better Ruby code, it certainly did it for me.

In short words, RubyCop is a code analyzer that checks Ruby code against common style guidelines and tries to detect a lot of mistakes and errors that you might write into your code.

There are a lot of configuration options, and even an auto-correct functionality, that updates your code.

Simple usage

Either install the gem, or add it to your Gemfile:

gem 'rubocop', require: false

You can just run it without configuration, and it will look for all Ruby files in your work directory.

$ rubocop
Inspecting 19 files
....C............CC

Offenses:

lib/test/cli.rb:3:3: C: Missing top-level class documentation comment.
 class CLI
 ^^^^^
lib/test/cli.rb:36:1: C: Extra empty line detected at method body beginning.
lib/test/cli.rb:41:1: C: Extra empty line detected at block body beginning.
lib/test/cli.rb:45:4: C: Final newline missing.
end
 
bin/test:12:1: C: Missing space after #.
#api.login('username', 'Passw0rd') unless api.logged_in?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
bin/test:15:3: C: Missing space after #.
 #puts response.code
 ^^^^^^^^^^^^^^^^^^^
bin/test:19:1: C: Missing space after #.
#session.save(file)
^^^^^^^^^^^^^^^^^^^

18 files inspected, 7 offenses detected

You can add it as a rake job to your Rakefile:

require 'rubocop/rake_task'
RuboCop::RakeTask.new

task default: [:spec, :rubocop]

And run the test via your rake tests:

$ rake
$ rake rubocop

Configuration galore

There are a lot of options to modify the behavior and expectations of RuboCop.

Here is a short example I used with recent Puppet module.

require: rubocop-rspec
AllCops:
  TargetRubyVersion: 1.9
  Include:
    - ./**/*.rb
  Exclude:
    - vendor/**/*
    - .vendor/**/*
    - pkg/**/*
    - spec/fixtures/**/*

# We don't use rspec in this way
RSpec/DescribeClass:
  Enabled: False

RSpec/ImplicitExpect:
  Enabled: False

# Example length is not necessarily an indicator of code quality
RSpec/ExampleLength:
  Enabled: False

RSpec/NamedSubject:
  Enabled: False

Where to go next

Markus Frosch

Autor: Markus Frosch

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

Puppet Hash Injection

forge-logoFolgende Ausgangssituation, wir wollen eine Konfigurationsdatei zeilenweise mit beliebigen Optionen und den zugehörigen Werten verwalten. Hierzu benutzen wir eine Defined Resource, um jeweils einen Eintrag zu konfiguration:

define config::setting(
  $option = $title,
  $value,
) {
  file_line { "config::setting::${option}":
    line => "${option} = ${value}",
    ...
}

Nun möchten wir jedoch aus einer Klasse heraus, einen einfachen Hash zur Deklaration verwenden und nicht einen Hash of Hashes.

class { 'config':
  options => { 'opt1' => 'alpha', 'opt2' => 'beta' },
}

Das Problem ist nun, dass wir aus options einen Hash der folgenden Form machen müssen, um mit create_resources, opt1 und opt2 anlegen zu können.

{ 'opt1' => { 'value' => 'alpha' },
  'opt2' => { 'value' => 'beta' },
}

Ruby bietet für Hashes eine Methode inject, die wir innerhalb eines inline_templates anwenden. Die inline_template Funktion liefert jedoch nur Strings zurück und keinen Hash. Deshalb geben wir den String in YAML zurück, den wir abschließend mit der im Module puppetlabs-stdlib enthaltenen Funktion parseyaml wieder in einen Hash der geforderten Form umwandeln.

class config(
  $options = {},
) {
  create_resources('config::setting',
    parseyaml(inline_template(
      '<%= @options.inject({}) {|h, (x,y)| h[x] = {"option" => x, "value" => y}; h}.to_yaml %>'))
  )
}
Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Paketstation

Mit FPM stellt Jordan Sissel, der führende Kopf hinter Logstash, ein Tool zur Verfügung mit dem man sehr einfach Pakete für die gängigsten Distributionen erstellen kann.

Für Effing Package Management (=FPM) muss Ruby und ein C-Compiler vorhanden sein:

# apt-get install ruby-dev gcc
# yum install ruby-devel gcc

Danach kann die eigentliche Installation des Ruby-Moduls erfolgen:

# gem install fpm

Als Beispiel für die Erstellung von Paketen mit FPM habe ich im Folgenden LConf Standalone Web gewählt, natürlich kann dies auch auf andere Softwareprodukte abgewandelt werden.

Zuerst muss bei LConf Web das Archiv mit dem Quellcode herunter geladen und entpackt werden, danach wechselt man wie gewohnt in das extrahierte Verzeichnis. Im Anschluss wird hier der configure-Befehl ausgeführt:

# ./configure --with-user=icinga --with-group=icinga

Bis zu diesem Zeitpunkt besteht noch kein Unterschied zum üblichen Installationsvorgang, erst bei make install unterscheidet sich der Aufruf. Statt die Dateien an den dafür vorgesehenen Stellen im Dateisystem abzulegen, leitet man sie mit dem DESTDIR-Parameter um:

# make install DESTDIR=/usr/local/src/lconf-web-1.4.0_installdir

Jetzt ist die Zeit von FPM gekommen, den hier kann nun das DESTDIR-Verzeichnis als Chroot verwendet und die darin enthaltene Verzeichnisstruktur “usr/local/lconf-web” beispielsweise in ein Debian-Paket integriert werden:

# fpm -s dir -t deb -n lconf-web -v 1.4.0 --deb-use-file-permissions \
-C /usr/local/src/lconf-web-1.4.0_installdir usr/local/lconf-web

Das dabei entstandene Paket lconf-web-1.4.0_amd64.deb kann nun natürlich mit dpkg auf einem Debian basierten System installiert werden.

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.