i-doit API Ruby-Scripting

Wie in meinem letzten Blogpost angekündigt stelle ich heute eine gescriptete Variante für die API der i-doit CMDB vor.

Einzelne Abfragen, sowie das Anlegen von Objekten über den RESTClient mögen auf den ersten Blick zum Testen bzw. Debuggen  ziemlich sinnvoll erscheinen, aber man stößt schnell an Grenzen, sobald es sich über mehrere hundert solcher Objekte handelt. Darüber hinaus ist diese Methode sehr umständlich.

Meine Idee war es eine Webanwendung zu benutzen, welche mit einem einzelnen Requests (im JSON-Format) an die API von I-doit Abfragen oder das Neuanlegen von Objekten vereinfacht. Da bot sich das Framework Sinatra an, da dieses eine sehr einfache und schnell zu lernende DSL besitzt. Wenn diese Anwendung läuft, kann mit der Eingabe einer bestimmten URL, ein Objekt abgefragt bzw. erstellt werden. In diesem Beispiel, werde ich die Namen sowie IDs aller Server aus der CMDB auslesen.

Zunächst müssen wir folgende drei Bibliotheken einbinden:

#!/usr/bin/env ruby

require 'sinatra/base'
require 'json'
require 'rest-client

Im nächsten Schritt bauen wir uns einen generischen Request (wie in meinem vorherigen Blogpost zu lesen) zusammen:

$baseurl = "https://example-idoit-web-gui.de"
$apikey = "random_key"

class CMDBApi
  def initialize(url=$baseurl, apikey=$apikey, objID=nil)
    @url = url
    @apikey = apikey
    @objID = objID
  end

  def postHeader(endpoint, method, payload)
    response = RestClient::Request.new({
      :method => method,
      :headers => {:accept => :json, :content_type => :json},
      :url => "#{@url}/#{endpoint}",
      :payload => payload
    }).execute
  end
  def readAllServer()
    payloadMetadata = Hash.new
    payloadMetadata[:version] = "2.0"
    payloadMetadata[:id] = "1"
    payloadMetadata[:method] = "cmdb.objects.read"
    payloadMetadata[:params] = Hash.new
    payloadMetadata[:params][:apikey] = @apikey
    payloadMetadata[:params][:filter] = {"type": "5"}
    @payloadJsonFormat = payloadMetadata.to_json
    response = postHeader("src/jsonrpc.php", :post, @payloadJsonFormat)
    response_hash = JSON.parse(response)
  end
end

get "/server" do
  api = CMDBApi.new($baseurl, $apikey)
  response = api.readAllServer(objectID)
  allServerHash = {}
  response["result"].each do |result|
    serverID = result["id"]
    serverName = result["title"]
    allServerHash[:"#{serverName}"] = serverID
  end
  allServerHash.to_json
end

Wenn man das Skript ausführt, wird (je nach Konfiguration) über http://127.0.0.1:4567 auf das Webfrontend zu gegriffen. Durch das zusätzliche Anhängen von  “/server” ist es möglich, alle Servernamen und deren zugehörigen Server-IDs aus i-doit auszulesen.

{
  • "Server_A" : 66273,
  • "Server_B" : 94647,
  • “Server_C” : 21221,
  • “…”: ….
}

Der große Vorteil einer solchen Webanwendung ist, dass man durch Erweiterung eine Automatisierung erreichen kann. Erhält man z.B. einen neuen Server, der mittels Puppet provisioniert wurde, kann vom Puppetmaster ein Objekt im i-doit angelegt werden. Hierzu kann damit auch auf alle ermittelten Facts zurückgegriffen werden. Diese sind dann über das zu erweiternde Skript an die API weiterzugeben, um final ein Server-Objekt mit allen angereicherten Informationen zu erhalten.

Philipp Dorschner
Philipp Dorschner
Junior Consultant

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the...

SSL/TLS Zertifikate für die Nutzung im internen Netz (apache)

Um verschiedene Dienste im LAN sicher zu nutzen, werden SSL-Zertifikate benötigt. Wir verwenden dafür in manchen Fällen ein selbstsigniertes Zertifikat. Das SSL-Zertifikat enthält Informationen über den Namen des Inhabers, den öffentlichen Schlüssel, eine Gültigkeitsdauer und gegebenenfalls den Namen der Zertifizierungsstelle. Mit dem öffentlichen Schlüssel kann das Zertifikat der Zertifizierungsstelle überprüft werden.

Das SSL-Zertifikat muss zuerst als vertrauenswürdig eingestuft werden, dazu sind bestimmte Rangordnungen der Autoritäten notwendig. Der Browser verfügt über Listen mit Zertifizierungsstellen deren SSL-Zertifikate bedingungslos vertraut werden. Beim Aufrufen einer SSL-verschlüsselten Website, prüft der Browser das Zertifikat auf Gültigkeit der Referenzen und des Herausgebers der Webadresse. Kennt der PC oder Browser den Herausgeber des Zertifikates nicht, meldet er einen Zertifikatsfehler. Diesen Fehler kann man übergehen und seinen Besuch auf der Website fortsetzen.

Selbstsignierte Zertifikate geben diesen Fehler logischerweise immer, da sie nicht von einer Zertifizierungsstelle als gültig und sicher geprüft wurden. Hier signiert der Server selbst für seine Dienste, die von den jeweiligen Clients besucht werden.

Ich zeige euch, wie wir das Zertifikat erstellen und manuell in den Firefox-Browser hinterlegen.

Zuerst müssen wir einen Private-Key erstellen, der immer bei uns verbleibt. Niemand außer uns sollte Zugriff auf diese Datei haben, da der Private-Key später untrennbar von unserem Zertifikat ist. Dazu wechseln wir in das Verzeichnis, indem wir den Schlüssel gerne haben wollen:

openssl genrsa -aes256 -out ca-key.pem 2048

Mit dem Argument -aes256 (Abkürzung für „Advanced Encryption Standard“) verschlüsseln wir unsere Datei mit einer 256Bit Schlüssellänge. Der Key muss eine Länge von 2048bit haben und in unserem Beispiel nenne ich ihn ca-key.pem (nehmt einen Namen, den ihr später leicht eurer Seite hinzufügen könnt). Das pass phrase muss mindestens 4 Zeichen lang sein und darf keine Sonderzeichen enthalten.

Nun kommt die CA-Datei, die die Antragsdaten sowie den öffentlichen Schlüssel zu unserem Private-Key enthält:

openssl req -x509 -new -nodes -extensions v3_ca -key ca-key.pem -days 1024 -out ca-root.pem -sha512

Benennt eure Dateien wieder mit einem beliebigen Namen. Ich nutze hier einige Argumente: -nodes (noDES) encrypted den Private-Key nicht, -x509 gibt das Certificate Data Management an, dass uns dann auch zu -extensions v3-ca führt. Hier wird eine Cryptographie erstellt und es werden Erweiterungen für policies verwendet.

Bei der Erstellung der CA werdet ihr nach einigen Details gefragt, die ihr angeben könnt um das Zertifikat eindeutig zu machen (oder aus Testzwecken einfach leer lassen).

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:

Wir brauchen jetzt noch einen Zertifikats-Key…

openssl genrsa -out zertifikat-key.pem 4096

…erstellen dann unsere CSR-Datei…

openssl req -new -key zertifikat-key.pem -out zertifikat.csr -sha512

…und signieren sie mit unserem eben erstellten Key.

openssl x509 -req -in zertifikat.csr -CA ca-root.pem -CAkey ca-key.pem -CAcreateserial -out zertifikat-pub.pem -days 365 -sha512

Gleiche Vorgehensweise wie zuvor beschrieben, pass phrase eingeben und bei belieben eure Details noch eintragen.

Wir sind fertig!

Jetzt bindet ihr das Zertifikat nur noch in euren Browser mit ein, in meinem Falle nutze ich den Firefox-Browser. Öffnet die Einstellungen und geht auf den linken Reiter “Datenschutz & Sicherheit”. Nun scrollt ihr ganz nach unten bis ihr die Option “Zertifikate” seht. Klickt auf den Button “Zertifikate anzeigen…”, dort öffnet sich ein neues Fenster in dem ihr nun euer erstelltes Zertifikat einpflegen könnt.

Der Browser muss nun geschlossen werden um die Veränderungen anzunehmen. Startet ihn neu und verbindet euch mit eurer Website. Nun müsstet ihr sehen können, dass ein https:// angezeigt wird.

Aleksander Arsenovic
Aleksander Arsenovic
Junior Consultant

Aleksander macht eine Ausbildung zum Fachinformatiker für Systemintegration in unserem Professional Service. Wenn er nicht bei NETWAYS ist, schraubt er an seinem Desktop-PC rum und übertaktet seine Hardware. Er ist immer für eine gute Konversation zu haben.

Terraform Changes

Hallo!

Was vielen unseren von geneigten Lesern entgeht ist das wir auch in unserem Alltag zwischen der ganzen Softwareschreiber- und Kompilier Tätigkeiten auch ganz viele virtuelle Maschinen und Container zum testen selbiger Software rauf und runter installieren müssen und das Tag für Tag.

Deshalb und gerade deshalb versuchen wir uns das Leben mit dafür erstellter Software und deren arbeitserleichternden Funktionen leichter zu machen. Wie mein Kollege schon in seinem Blogpost im März mir vorgegriffen hat benutzen wir bei der Netways Terraform. Achim wird in weiteren Artikeln darauf eingehen wie man Openstack per Terraform nach seiner Pfeife tanzen lassen kann und Ich möchte mich heute auf ein anderes Terraform Thema beziehen nämlich dem nahen release von Terraform 0.12.

Zu dem Zeitpunkt wo ich diese Zeilen niederschreibe ist auf der aktuellen Website von Hashicorp noch die Aktuelle Version 0.11.13 zu finden.

Aber Terraform hat schon etwas den Vorgang gelüftet und uns vielversprechendes gezeigt mit dem 0.12.0-beta1 pre-release.

Damit kann man schon die viele Erleichterungen welche der neue Terraform release mit sich bringt erahnen und auch schon antesten. Ich versuche mich an einer Erleuterung den änderungungen Anhand eines kleinen Beispiels.
Vielleicht kann ich den einen oder anderen IaaS Codeschreiber welcher sich hierfür interessiert etwas auf den Geschmack zu bringen schon etwas zu testen mit der neuen Version.

Hier der Unterschied zwischen einer (aktuell 0.11.13) alten Terraform Version und einer neuen Version in Terraform 0.12 durch eine Gegenüberstellung.

main.tf (Random Tiernamen Beispiel)

variable "count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "zoo_enabled" { default = "0" } variable "prefix_liste" { default = [] } resource "random_pet" "my_pet" { count = "${var.count}" prefix = "${var.zoo_enabled == "0" ? var.default_prefix : element(concat(var.prefix_liste, list (""), count.index)}" }

main.tf HCL2 Version(Random Tiernamen Beispiel)

variable "pet_count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "prefix_list" { default = [] } resource "random_pet" "my_pet" { count = var.pet_count prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix }

Die Unterschiede fallen zuerst etwas weniger ins Auge sind aber dafür meines Erachtens tiefgreifender für Leute die IaaS Code schreiben müssen und es dient der Lesbarkeit des Codes.

Vorteil Nummer 1:
Im alten Beispiel musste noch mit “${var.count}” von einem String zu einer Number evaluiert werden, mit der neuen HCL2 schreibweise entfällt das und es kann mit var.pet_count direkt der korrekte String oder Number Wert adressiert werden.

Vorteil Nummer 2:
Auch die Evaluierung der Liste prefix = “${var.zoo_enabled == “0” ? var.default_prefix : element(concat(var.prefix_liste, list (“”), count.index)}”  wird mit der neuen notation der HCL2 wesentlich eingängiger. prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix ist prägnanter. Es entfällt auch die element(concat(x), list(“”), x ) Hack-Situation um aus einer leeren Liste auch eine Liste mit einem NULL Element zum machen.

Vorteil Nummer usw. es gibt viel mehr was geändert worden ist, if you want to know more here.

Ich hoffe ich habe euch nicht zu sehr gelangweilt mit C.O.D.E. kurz vor dem Wochenende.

Gruß David

 

David Okon
David Okon
Senior Consultant

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...

Mac Helper: Finder

Die Standardwerkzeuge im Mac sind alle samt schon ziemlich gut. Für mich aber eine der Ausnahmen: Der Finder! Meistens finde ich mich dann mit 10 offenen Fenstern wieder oder ich verschiebe das Zeug in andere Verzeichnisse, weil die Oberfläche nicht schnell genug reagiert (Tabs wechseln, Verzeichnisse expandieren). Entnervt erledige ich dann die Überbleibsel im Terminal.

 

Alfred Workflow

Standardmäßig gibt es einen “Open-Workflow” in Alfred. Dieser öffnet entweder Dateien oder Verzeichnisse. Aber es geht noch besser: “Open Finder Tab“. Dabei bleibt ein Fenster offen und es werden weitere Tabs hinzugefügt:

Yoink

Wie schaut es dann mit anderen Artefakten aus? Mails, Preview oder URL’s? Dafür bin ich vor einiger Zeit auf Yoink gestoßen. Yoink ist ein kleiner temporärer Container allgemein Dateireferenzen zwischenspeichern kann. Dies können z.B. URL’s sein, Inhalt der Zwischenablage, Dateien. Dabei integriert es sich Nahtlos in die Oberfläche mit einem kleinen Fenster, was bei “Drag and drop” Operationen eingeblendet wird.

 

Beide Tools, Alfred wie auch Yoink sind nicht kostenfrei sind aber definitiv den Einkauf wert. Mir erleichtern sie massiv die tägliche Arbeit mit dem Finder!

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.
Quick and Dirty: OpenStack + CoreOS + GitLab Runner

Quick and Dirty: OpenStack + CoreOS + GitLab Runner

Wer in GitLab die CI/CD-Features nutzen möchte und nicht zufällig einen ungenutzten Kubernetes-Cluster übrig hat, mit dem man GitLab’s Auto DevOps Funktion einrichten kann, der benötigt zumindest einen GitLab Runner, um Build-Jobs und Tests zum Laufen zu bekommen.
Der GitLab Runner ist eine zusätzliche Anwendung, welche sich ausschließlich darum kümmert, bei einer GitLab-CE/-EE Instanz die CI/CD-Aufträge abzuholen und diese abzuarbeiten. Der Runner muss dabei nicht zwingend auf dem selben System wie das GitLab installiert sein und kann somit auch extern auf einem anderen Host laufen. Der Hintergrund, weshalb man das auch so umsetzen sollte, ist eigentlich recht klar: ein GitLab Runner steht bei einer aktiven CI/CD-Pipeline oftmals unter hoher Last und würde er auf dem gleichen Host wie das GitLab selbst laufen, so könnte er dessen Performance stark beeinträchtigen. Deshalb macht es Sinn, den GitLab Runner z.B. auf eine VM in OpenStack auszulagern.
In diesem Blogpost werde ich kurz darauf eingehen, wie man schnell und einfach eine GitLab Runner VM per CLI in OpenStack aufsetzen kann. Da ich den Runner als Docker-Container starten möchte, bietet sich CoreOS an. CoreOS kommt mit Docker vorinstalliert und es bietet die Möglichkeit per Ignition Config nach dem Start des Betriebssystems Container, oder auch andere Prozesse, automatisch starten zu lassen.

Sobald man sich bei seinem OpenStack-Anbieter in sein Projekt eingeloggt hat, kann man sich dort unter “API Zugriff” die OpenStack-RC-Datei herunterladen. Damit kann man sich dann recht einfach per CLI bei OpenStack authentifizieren. Voraussetzung für die Nutzung der CLI ist, dass man bei sich den OpenStack Command-Line Client installiert hat.
Sobald man beides hat, kann es auch schon losgehen:

    1. Runner Registration Token abholen
      Dazu loggt man sich als Admin in sein GitLab-CE/-EE ein und navigiert zu “Admin Area” -> “Overview” -> “Runners”. Hier findet man den aktuellen Registration Token.
    2. CoreOS Ignition Config
      Die Konfigurationsdatei für CoreOS nennt man z.B. config.ign. Diese legt man sich ebenfalls auf dem Rechner ab.
      Der Inhalt muss im nächsten Schritt geringfügig angepasst werden.

      config.ign

      { "ignition": { "version": "2.2.0", "config": {} }, "storage": { "filesystems": [{ "mount": { "device": "/dev/disk/by-label/ROOT", "format": "btrfs", "wipeFilesystem": true, "label": "ROOT" } }] }, "storage": { "files": [{ "filesystem": "root", "path": "/etc/hostname", "mode": 420, "contents": { "source": "data:,core1" } }, { "filesystem": "root", "path": "/home/core/config.toml", "mode": 644, "contents": { "source": "data:,concurrent=4" } } ] }, "systemd": { "units": [ { "name": "gitlab-runner.service", "enable": true, "contents": "[Service]\nType=simple\nRestart=always\nRestartSec=10\nExecStartPre=/sbin/rngd -r /dev/urandom\nExecStart=/usr/bin/docker run --rm --name gitlab-runner -e 'GIT_SSL_NO_VERIFY=true' -v /home/core:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:v11.8.0 \n\n[Install]\nWantedBy=multi-user.target" }, { "name": "gitlab-runner-register.service", "enable": true, "contents": "[Unit]\nRequires=gitlab-runner.service\n[Service]\nType=simple\nRestart=on-failure\nRestartSec=20\nExecStart=/usr/bin/docker exec gitlab-runner gitlab-runner register -n --env 'GIT_SSL_NO_VERIFY=true' --url https://$URL -r $TOKEN --description myOpenStackRunner--locked=false --executor docker --docker-volumes /var/run/docker.sock:/var/run/docker.sock --docker-image ruby:2.5 \n\n[Install]\nWantedBy=multi-user.target" } ] }, "networkd": {}, "passwd": { "users": [ { "name": "core", "sshAuthorizedKeys": [ "$your-ssh-pub-key" ] } ] } }
    3. Ignition Config anpassen
      Beim Systemd-Unit “gitlab-runner-register.service” setzt man im Content bei den Variablen “$URL” den FQDN der eigenen GitLab-Instanz und bei “$TOKEN” den in Schritt 1 kopierten Registration Token ein.
      Außerdem kann man gleich noch seinen SSH-Key mitgeben, damit man später auch per SSH auf die VM zugreifen kann. Diesen hinterlegt man unter dem Abschnitt “passwd” im Platzhalter “$your-ssh-pub-key”.
    4. CLI Commands
      Nun kann man sich auch schon das Kommando zum anlegen der VM zusammenbauen.
      Als erstes muss man sich bei OpenStack authentifizieren, indem man die Datei sourced, die man sich eingangs aus seinem OpenStack Projekt geladen hat und dabei sein OpenStack Passwort angibt:

      source projectname-openrc.sh

      Man sollte außerdem sicherstellen, dass in dem Projekt ein CoreOS Image zur Verfügung steht.
      Anschließend kann man nach folgendem Schema die Runner-VM anlegen:

      openstack server create --network 1826-openstack-7f8d2 --user-data config.ign --flavor s1.medium --image CoreOS_Live "GitLab Runner"

      Network, Flavor und Image sollten aber individuell noch angepasst werden.

    Nach ca. zwei Minuten sollte dann der Runner auch schon zur Verfügung stehen. Überprüfen lässt sich das, indem man sich als Admin in seine GitLab-Instanz einloggt und im Bereich unter “Admin Area” -> “Overview” -> “Runners” nach einem Runner mit dem Namen “myOpenStackRunner” nachsieht.

    Wer noch auf der Suche nach einem OpenStack-Provider ist, der wird bei den NETWAYS Web Services fündig. Mit nur wenigen Clicks hat man sein eigenes OpenStack-Projekt und kann sofort loslegen.

Gabriel Hartmann
Gabriel Hartmann
Systems Engineer

Gabriel hat 2016 als Auszubildender Fachinformatiker für Systemintegrator bei NETWAYS angefangen und 2019 die Ausbildung abgeschlossen. Als Mitglied des Web Services Teams kümmert er sich seither um viele technische Themen, die mit den NETWAYS Web Services und der Weiterentwicklung der Plattform zu tun haben. Aber auch im Support engagiert er sich, um den Kunden von NWS bei Fragen und Problemen zur Seite zu stehen.

Infrastructure as Code mit Terraform und Openstack

This entry is part 1 of 1 in the series Openstack und Terraform Beispiele

Der Drang weg von Hardware zu einer virtuellen oder sogar serverless Infrastruktur ist weiterhin stark. Nicht alle Administratoren oder Entwickler denken sofort an eine Containerplattform wie Kubernetes oder serverless functions sondern verlagern die eigene Infrastruktur in eine Public Cloud. Dadurch bleiben einem lästige Aufgaben in Kalt- und Warmgängen im Rechenzentrum erspart und es bleibt mehr Zeit für anderen Tätigkeiten. Cloud Plattformen wie OpenStack bieten alle nötigen virtuelle Ressourcen die auch in einem Rechenzentrum vorhanden sind, nur dass diese in wenigen Sekunden verfügbar sind. So kann man Komponente wie z.B. Router, Bridges, Interfaces, Server (VMs), Storage (von Block bis Object) und andere schnell und einfach über offene Schnittstellen erstellen und verwalten.

Dies gibt uns Administratoren auch die Möglichkeit unsere Infrastruktur in Textdateien zu beschreiben, zu automatisieren und zu verwalten. Unter dem Buzzword Infrastructure as Code findet man viele Tools die einem hier unterstützen und Terraform ist eines der bekanntesten um z.B. Ressourcen in OpenStack zu verwalten. Mit meinen nächsten Blogposts will ich mit vielen Beispielen zeigen wie man mit Terraform seine virtuelle Ressourcen in der Netways Cloud verwalten kann. Mehr zum Thema Terraform gibt es auch im Talk von Anton Babenko auf der OSDC.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.