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.

Gnocchi: Metriken und Metadaten

Gnocchi LogoGnocchi kann im Vergleich zu anderen Timeseries Datenbanken auch Metadaten zu einzelnen Ressourcen hinzufügen. Somit kann man Metriken einfach mit Informationen versehen die wiederum für so spannende Dinge wie Accounting und Reporting verwendet werden können. Eine konkrete Metrik, z.B. der aktuelle Speicherverbrauch eines Servers, wird in Gnocchi immer zu einer Ressource (z.B. mein-db-server1) gespeichert. Eine Ressource hat einen Typ, z.B. Server. Der Typ Server gibt die Attribute/Metadaten vor, welche zu meiner Ressource mein-db-server1 gespeichert werden können.

Also nochmal in kurz: Eine Metrik gehört zu einer Ressource. Eine Ressource hat einen Typ. Ein Typ hat Metadaten.

Ein neuer Ressourcetyp, z.B. Server,  mit den Attributen Name und Kundenummer ist mit folgenden HTTP Post an den Endpunkt /v1/resource_type schnell erstellt:

{ 
  "Name": "Server",
  "attributes": {
    "name": {
    "required": true,
    "type": "string"
  },
  "Kundennummer": {
    "max": 8,
    "min": 8,
    "type": "number",
    "required": true
  } 
}

Um nun eine konkrete Ressource mein-db-server1 anzulegen, sendet man unten stehendes Json an den Endpunkt /v1/resource/server:

{
"Kundennummer": "12345678",
"Name": "mein-db-server1"
}

Zu der neuen Ressource kann man beliebige Metriken (z.B. CPU, Memory, Traffic etc.) hinzufügen und natürlich lassen sich auch die Filter der Suche auf die Kundennummer anpassen. Folgender HTTP Post an /v1/search/resource/server findet alle meine Server wieder:

{
  "=": {
    "Kundennummer": "12345678"
  }
}

Gnocchi gibt einem alles an die Hand um die eigenen Metriken mit Metadaten zu versorgen. Damit ist es ein Leichtes seine Reporting und Accounting Tools mit Daten zu befüllen, wie z.B. unser Cost Explorer.

Achim Ledermueller

Autor: Achim Ledermueller

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.

NWS OpenStack | The ultimate IaaS Platform!

 

With NWS OpenStack you get the cloud infrastructure that helps your business to stay flexible and grow.

NWS OpenStack lets you deploy virtual machines and other resources for managing a cloud environment on the fly.

Community-powered innovation with Enterprise-grade
features and support:

  • Compute | Your virtual machines with different operating systems can be up and running in seconds
  • Network | In your own virtual data center networks can be isolated and customized environments created
  • Storage | The replicated Ceph storage, hosted across two independent data centers, is ready for your workload
  • Support | We support you with Managed Services – 24 hours a day, 365 days a year
  • Availability | All instances of different available zones are located in an ISO-certified data center in Germany

Get your own cloud infrastructure managed by a team of experts!

Try now: nws.netways.de

OpenStack Webinar: Learn more!
Stack up your knowledge on Wednesday, October 17, 2018. At 10.30 am. Register here.

 

NWS OpenStack | Tailored Infrastructure as a Service

Julia Hornung

Autor: Julia Hornung

Julia ist seit Juni 2018 Mitglied der NETWAYS-Crew. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und Produktionsassistentin in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

NETWAYS Webinare – Jetzt mit OpenStack !

Wieder einmal mehr haben wir an unserem Webinar Kalender geschraubt – diesmal möchten wir euch etwas über OpenStack erzählen.

OpenStack: Infrastructure Hosting by NETWAYS
Dort wollen wir unsere neue OpenStack IaaS Plattform vorstellen und die Vorteile, welche sich hieraus ergeben. Dadurch gewähren wir unseren Kunden maximale Transparenz, Flexibilität und eigenes Management der IT-Umgebungen.

Als Termin ist der 17. Oktober 2018 um 10:30 Uhr angesetzt.
 

Die Anmeldung zum Webinar ist hier möglich.
Darüber hinaus möchte ich eine weitere Änderung in unserem Webinar Kalender ankündigen: Das Webinar Icinga 2: Monitoring für Windows musste leider verschoben werden und zwar auf den 05. Dezember 2018 um 10:30 Uhr. Eine Mitteilung an alle Teilnehmer ging heute morgen bereits raus.

Anbei gibt es hier einmal die aktuelle Webinar Liste im Überblick:

Selbstverständlich werden wieder alle Webinare aufgezeichnet und auf unserem YouTube Channel veröffentlicht.

Ich freue mich wie immer auf eine rege Teilnahme und die Webinare!

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Portainer

Übersicht für Docker

Docker ist eine Open Source Lösung, welche eine sehr effiziente und einfache Möglichkeit bietet, deine App als Container problemlos zum Laufen zu bringen bei verschiedenen Umgebungen. Wer mehr über Docker erfahren will, kann den vorherigen Artikel durchlesen. Wir als Netways GmbH arbeiten seit langem mit Docker und bieten Hostings für Ihre gewünschte Umgebung. Als erfolgreiches Beispiel für Docker sind die Apps, die wir durch NWS anbieten.

Eine kleine Wissensrunde über Portainer

Portainer ist ein Container von Docker-Hub, welcher eine Web-Management-Schnittstelle darstellt, die es uns ermöglicht, Docker grafisch zu betreiben.

docker run -d -p 9000:9000 --name=portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock portainer/portainer

Was kann man mit Portainer zaubern ?

  • Container starten, stoppen, killen, neustarten, löschen, addieren etc…
  • Images aufbauen, löschen, an eigens Konto auf Docker Hub oder an selber konfigurierte Registry exportieren und importieren.
  • Services auf einem Cluster “Swarm” als Hochverfügbarkeit hinzufügen oder löschen. Wir werden mehr über Swarm im nächsten Abschnitt erfahren!
  • Stacks addieren und löschen. Stacks sind Gruppen von Services, die mit einander kommunizieren und am Ende eine App liefern wie zum Beispiel wordpress mit Datenbank.
  •  Administrator oder normale User hinzufügen und zu einem bereitgestelltem Team zuweisen.
  • Zugreifen und managen von Docker-Endpoints. Dazu gibt es zwei Möglichkeiten, entweder erstellen Sie eine Gruppe, weisen Docker-Endpoint/s zu ihr zu und geben Zugriffsrechte für Benutzer oder Team/s auf diese Gruppe, oder Sie geben Rechte direkt im Endpoint-Menü für Benutzer oder Team/s für jeden einzigen Docker-Endpoint .
  •  Eigne Registry anbinden und Zugriffe nach Benutzer oder Team vergeben. Allerdings können Sie Ihre Images nicht durchsuchen. Das heißt der Name des Images muss bekannt sein, bevor ein Container gestartet werden kann.
  • Authentifizierung lokal konfigurieren oder vom LDAP Server ziehen.
  • Einen Überblick über die Swarm “Cluster” Umgebung verschaffen z.B wie viel Leistung bietet das Cluster und welche Container laufen auf welcher Docker Engine. Außerdem können Sie die Availability von einer Docker-Instance auf active, pause oder drain setzen. Dies ist sehr hilfreich bei einem Update oder Backup. Bei active ist Docker immer bereit Tasks von einem Service anzunehmen. Bei Pause akzeptiert Docker keine Tasks mehr. Bei drain werden alle Tasks gestoppt und von anderen Nodes im Swarm übernommen.
Portainer kann auch Infos von einem Swarm visualisieren.

Was ist Swarm ?

Swarm oder Cluster entstehen einfach aus Manager/n und Worker/n, auf denen Docker läuft. Das Hauptziel von Swarm ist die Hochverfügbarkeit und Lastverteilung. Manager können alles konfigurieren und  managen, allerdings sind Worker nur dafür da, die Last zu vermindern und Tasks zum laufen zu bringen. Wenn ein Service bei Default auf dem ganzen Swarm verteilt wird,  können Sie entweder im docker-compose.yml einen Key definieren auf welchen Nodes die Services laufen sollen, oder den Service auf dem ganzen Swarm verteilt lassen. Von einem Swarm dürfen maximal (N-1)/2 Manager ausfallen, ansonsten funktioniert kein Swarm-Befehl bis die fehlenden Manager wieder up sind oder ein neuer Cluster erzwungen wird.

docker swarm init --force-new-cluster --advertise-addr "IP-Adresse von manager"

Trotz des neuen Cluster-Aufbaus synchronisieren sich die wieder up Server mit dem Swarm ganz normal. Ich würde gerne ein Beispiel von einer Swarm-Konfiguration von zwei Managern und einem Worker vorstellen.

Wie kann portainer swarm managen ?

Portainer kann andere Manger in Swarm als Endpoint betreiben, wenn ein overlay Network eingerichtet ist, auf dem portainer_agent als Service läuft.

docker network create --driver overlay --attachable portainer_agent_network
docker service create \
--name portainer_agent \
--network portainer_agent_network \
--publish mode=host,target=9001,published=9001 \
-e AGENT_CLUSTER_ADDR=192.168.56.150 \
--mode global \
--mount type=bind,src=//var/run/docker.sock,dst=/var/run/docker.sock \
--mount type=bind,src=//var/lib/docker/volumes,dst=/var/lib/docker/volumes \
portainer/agent

Für jeden neuen Agent muss ein neuer Service auf dem Overlay Netwok zum laufen gebracht werden mit neuem Namen, veröffentlichen Port und Adresse. Ansonsten bekommt man einen Duplikatfehler.

Für Leser, die sich für Portainer begeistert haben, gibt es eine Demo auf http://demo.portainer.io

Benutzername : admin

Passwort : tryportainer

Hinweis: Das Cluster wird alle 15 Minuten zurückgesetzt.

Ich hoffe der Artikel hat Ihnen weiter geholfen 🙂

Afeef Ghannam

Autor: Afeef Ghannam

Afeef macht seit September 2017 eine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS. Nachdem der gebürtige Syrer erfolgreich Deutsch gelernt hat, stellt er sich jetzt der Herausforderung Programmiersprache. Neben der IT schätzt er vielfältiges Essen. Sein Motto lautet يد واحدة لا تصفق لوحدها , was so viel bedeutet wie „Eine Hand wird nie allein klatschen“.

Monthly Snap August – NETWAYS News | Tipps & Tricks | Upcoming… | Corporate Blogging

 

„Das @netways Blog kann man auch generell einfach mal empfehlen: https://blog.netways.de/  – immer wieder spannende Sachen bei den Posts dabei“, twittert Felix Kronlage Anfang August. Das freut mich und meine Kolleginnen und Kollegen natürlich sehr! Denn, wie ihr als fleißige Blog-Leser/innen sicher wisst, das NETWAYS Blog ist, ganz im Geiste von Open Source, ein offenes Gemeinschaftsprojekt, geschrieben von uns, dem NETWAYS Team.

Wir haben unseren Redaktionsplan so organisiert, dass das Schreiben wie ein Staffelstab Tag für Tag durch unser Headquarter und von Team zu Team gereicht wird: Montags Shop & Sales, dienstags Events & Marketing, mittwochs Managed Services, donnerstags Development, freitags Consulting.  Für samstags planen wir eventuelle Specials und am Monatsende gibt es, so wie heute, einen Rückblick, den Monthly Snap. Der Snap bietet die Gelegenheit, noch einmal zu rekapitulieren. Während ich bei meinem täglichen Blick in das Blog meinen Fokus ja eher auf den einzelnen Beitrag des Tages richte, fällt mir jetzt am Monatsende mal wieder die Bandbreite an Themen und die Vielzahl der Stimmen auf, die unseren Blog und damit NETWAYS ausmachen!

Im besten Falle findet ihr, genau wie Felix, das ein oder andere für euch spannende Thema und klickt euch durch die Links. Viel Spaß dabei!

CEO Bernd hat diesen Monat seine Vergleichsserie wieder aufgenommen und veröffentlicht Icinga, Nagios, Naemon, OMD, Check_MK, Op5, Centreon oder Shinken – Teil III. Außerdem verweist er auf das Bitkom Forum Open Source 2018.

Webinare – Aus der Asche

In NETWAYS Webinare – Aus der Asche erfahrt ihr von Christian mehr über ein kleines Hitze- und Performance-Problem und die Termine aller Webinare in der zweiten Jahreshälfte, während Silke vom Shop & Sales-Team euch darüber informiert: Die neuen STARFACE Pro V6 und STARFACE Compact V3 Anlagen sind da!

Und natürlich gibt es auch wieder eine bunte Kiste voller Tipps und Tricks von unseren Entwicklern, Administratoren und Consultants, die vielleicht auch euch das Leben erleichtern: Jennifer – Feu – verrät „How css-tricks improved my work life“. Thomas weiß, es gibt JSON in bequem. Noah stolpert durch Zufall darüber und ist ab sofort happy mit  Postman – API development and testing made simple. Philipp setzt seine i-doit-Reihe fort mit i-doit API create, update, delete.

La La Lan & Molecule

Max zeigt euch in seiner La La Lan-IT Love Story wie man Linux Netzwerkschnittstellen mit check_nwc_health überwachen kann. Florians Thema: MySQL-Datenbanken verwalten mit Sequel Pro. Tim teilt sein Wissen über Adfree Internet with pi-hole.

Blerim stieß, als er an der Ansible Role für Icinga 2 arbeitete, auf ein hilfreiches Tool. Lest selbst: Testing Ansible Roles with Molecule. Ihr wollt mehr über Icinga 2 wissen, genauer, wie ihr mit Puppet eine dezentrale Icinga 2-Umgebung aufbaut und konfiguriert? Wir haben da einen neuen Workshop! Was euch erwartet, erfahrt ihr von mir in Ice, Ice – Icinga 2 / Puppet – Baby!

GitLab as a Service, Mutual SSL und OpenStack

Gitlab | self-hosted vs. Gitlab as a ServiceMarius wagt den Vergleich! Die vergangenen Monate hat er außerdem genutzt, um eine neue Cloud aufzubauen und weiß nun allerhand über Bursting und Throtteling in OpenStack zu berichten.

Jean beschäftigt sich in The Walrus Has Landed mit Structured Logging in Go und Georg dank einer Kunden-Anfrage mit der Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache. Sein Motto: Gesagt, getan.

DevOpsDays, OSBConf, OSMC und OSCAMP

Eventmäßig ist der August selbst ein eher ruhiger Monat. Klar: Viele sind in Urlaub, in zahlreiche Länder verstreut. Dafür stehen im Herbst die Zeichen umso mehr auf Get-Together. DevOpsDays | Sep 12. – 13. // OSBConf | Sep 26 // OSMC | Nov 5. – 8. // OSCamp | Nov 8. Mehr erfahrt ihr hier von Keya und mir: Devs are from Venus, Ops are from Mars? – DevOpsDays Berlin Program Online!, Why you shouldn’t miss OSBConf 2018 – #1 und #2, OSMC program online: Check out who’s in! Und OSCAMP #2 on Puppet: Get on stage!

 Und sonst so?

Wir haben Gunnar verabschiedet, ohne den wir Icinga heute so nicht hätten, und unseren ersten neuen Azubi willkommen geheißen, Henrik Triem im Development, und eine Woche Unterstützung von Nadine gehabt, die als Berufsschullehrerin mal Firmenluft schnuppern wollte.

Unser Schulungsraum Kesselhaus hat jetzt Jalousien und kann verdunkelt werden. Wir werden am 17. Dezember ein IcingaCamp in Tel-Aviv veranstalten und Icinga ist jetzt offizieller Partner im HashiCorp Technology Partner Program.

Viele Themen, viele Stimmen, viel Neues, viel Spannendes!
So much happend, more to come! Stay tuned!

Julia Hornung

Autor: Julia Hornung

Julia ist seit Juni 2018 Mitglied der NETWAYS-Crew. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und Produktionsassistentin in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.