Seite wählen

NETWAYS Blog

Terraform Changes

Hallo!

Was vielen von unseren 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 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 uns schon vielversprechendes gezeigt mit dem 0.12.0-beta1 pre-release.

Damit kann man schon die vielen Erleichterungen, welche der neue Terraform Release mit sich bringt erahnen und auch schon antesten. Ich versuche die Änderungen Anhand eines kleinen Beispiels zu erläutern.
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 dienen 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.

Weitere Vorteile: es gibt viel mehr was geändert worden ist, if you want to know more, klick 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
Support Engineer

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

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
David Okon
Support Engineer

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

Fresh from the shelf

Hi !
This week I will take a little look into three command line tools which I find very nice for daily use on a server where we have almost no interface except the command line.
The first tool I would like to bring to your attention is a file explorer for the command line.
Ranger
Ranger is a finder/explorer/nemo/nautilus replacement for the command line with a simple but straight forward file management approach. It uses the almost everywhere liked miller columns and i personally like it more than the midnight commander but that is a personal preference.
I also like the extensibility as an example you can extend ranger with poppler for pdf support or mutool whatever is available for your distro.
It can be easily installed and can be just started from it’s own directory so no big installation fuzz. Simply unpack and start ranger.
mehr lesen…

David Okon
David Okon
Support Engineer

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

For a Handful of (Vagrant) Boxes

Servus alle miteinand,


Wer kennt das folgende Szenario nicht? Mit viel neuer Software, welche gerade (manuell) getestet werden muss, dachte ich mir, ich baue mal schnell eine Vagrant Box auf Basis von Debian 9, um Tests unter einem Stretch durchzuführen.
Falsch gedacht !!
Anstelle eines libvirt install auf der Kommandozeile und eines tar-Befehls zum Packen des eigentlichen Box-Images,
musste ich mit einer kleinen Widrigkeiten im Bereich der Netzwerkkonfiguration kämpfen.
Aber eins nach dem anderen.
Fangen wir mit dem Image für die libvirt Maschine an:

virt-install --name=linuxconfig-vm \
--vcpus=1 \
--memory=1024 \
--cdrom=/tmp/debian-9.4.0-amd64-netinst.iso \
--disk size=10 \
--os-variant=debian9

Dies war noch der unproblematische Teil der Installation.
Danach erfolgt in der VM das nachziehen von Berechtigungen für den Vagrant User.

sudo visudo -f /etc/sudoers.d/vagrant
vagrant ALL=(ALL) NOPASSWD:ALL

Hinzufügen des Vagrant public Keys:

mkdir -p /home/vagrant/.ssh
chmod 0700 /home/vagrant/.ssh
wget --no-check-certificate \
https://raw.github.com/mitchellh/vagrant/master\/keys/vagrant.pub \
-O /home/vagrant/.ssh/authorized_keys
chmod 0600 /home/vagrant/.ssh/authorized_keys
chown -R vagrant /home/vagrant/.ssh

Wenn man nicht so Wach war, um rechtzeitig im Installationsmenü schon SSH mitzuinstallieren, muss es per Hand nachgeholt werden:

sudo apt-getinstall -y openssh-server
sudo nano /etc/ssh/sshd_config
AuthorizedKeysFile %h/.ssh/authorized_keys

Danach kann das System so präpariert werden, wie man es benötigt.
Das Image der VM noch verkleinern und in box.img umbenennen:

qemu-img convert -c -O qcow2 debian9.qcow2 small.qcow2
mv small.qcow2 box.img

Alles handlich verpacken und dem Vagrant Box Store hinzufügen:

tar czvf debian9.box ./metadata.json ./Vagrantfile ./box.img
vagrant box add --name debian9 debian9.box

Hier allerdings fingen meine Probleme an.
Nach dem Packen der Box, dem Hinzufügen zum Boxstore und einem Erwartungsvollen “vagrant up” erhielt ich “==> default: Waiting for domain to get an IP address…”, was zu keinem Erfolg führte und ich wahrscheinlich jetzt immer noch warten würde.

Nach einem erneuten Hochfahren der VM mit dem virt-manager und nachschauen, ob das network device fehl konfiguriert ist, konnte ich keinen Fehler feststellen.

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

Gefühlte Jahrtausende von Recherche später, wurde mir folgendes klar:
Debian hat in neuen Versionen eine Änderung der Device-Namen vorgenommen.
Vagrant wartet vergeblich auf “eth0”, weil ein network device Namens “ens21” existiert, wenn ich die VM mit “vagrant up” starte.
Also zurück in die VM und das folgende Kommandos abgesetzt:

sudo nano /etc/default/grub

Im Editor dann folgende Anpassungen vornehmen:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

Damit das auch greift, muss abschließend die Konfiguration für den Grub-Bootmanager neu erstellt werden:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Reboot. “vagrant up” und Tada … Spannung Trommelwirbel => Tusch ! Die VM erhält eine IP und startet wie man es schon von Anfang an erwartete.
Ich hoffe ich konnte damit den ein oder anderen vor dem Verlust von allzuviel Lebenszeit bewahren.
Ein sonniges WE wünscht

David Okon
David Okon
Support Engineer

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

Revisited – Graphite-Web installation unter Debian 9

Erstmal wieso Revisited ?

Dies ist ein update meines älteren Blog Posts Blogpost 2016 welcher darauf einging das unter Debian 8.4 graphite-web wegen eines Fehlenden Eintrages in der Apache 2.4 Konfiguration nicht korrekt gestartet/aufgerufen werden konnte.
Es ist schon einige Zeit ins Land gegangen und ich habe weniger ein Auge darauf geworfen ob das weiterhin so Funktioniert.
Deshalb Revisited.

Here we Go again !

Ich gehe in diesem Fall von einer Debian Version der Nummer 9 aus und werde wie bei dem alten Blogpost. In der Grundannahme mal davon ausgehen das alles Funktioniert wie es soll:
Also hier die folgenden installationschritte:
#> apt-get install apache2 libapache2-mod-wsgi python-django python-django-tagging fontconfig python-tz python-pip python-dev python-twisted python-cairo
#> pip install carbon whisper graphite-web
#> pip install --upgrade twisted
#> cp /opt/graphite/conf/carbon.conf.example /opt/graphite/conf/carbon.conf
#> cp /opt/graphite/conf/storage-schemas.conf.example /opt/graphite/conf/storage-schemas.conf
#> /opt/graphite/bin/carbon-cache.py start
#> /opt/graphite/bin/carbon-cache.py status
#> cp /opt/graphite/examples/example-graphite-vhost.conf /etc/apache2/sites-available/graphite.conf
#> cp /opt/graphite/conf/graphite.wsgi.example /opt/graphite/conf/graphite.wsgi
#> cp /opt/graphite/webapp/graphite/local_settings.py.example \ /opt/graphite/webapp/graphite/local_settings.py
#> python /opt/graphite/webapp/graphite/manage.py syncdb
#> chown www-data. -R /opt/graphite/storage
#> a2dissite 000-default
#> a2ensite graphite
#> a2enmod wsgi
#> service apache2 restart
#> chmod +x /etc/init.d/carbon-cache // Damit 'carbon-cache.py start' mit Systemstart erfolgt

Ergebnis davon ist -> Nichts funktioniert.

Back to the Roots

Ab hier kommt der Weg graphite-web auf einem Debian 9 (Stretch) in Betrieb zu nehmen.
Ausgangspunkt ist ein frisch installiertes Debian 9.
#> apt-get install vim -y
#> vim /etc/apt/sources.list

Wir müssen die Sources auf die Jessie Repositories setzen da zum Zeitpunkt dieses Blogposts die graphite-web Pakete nicht abrufbar sind.
Daher fügen wir folgendes hinzu in der sources.list
deb http://httpredir.debian.org/debian jessie main
Gefolgt von einem frischem #> apt-get update -y .
Nun installieren wir den großteil der Pakete welche wir benötigen.
#> apt-get install graphite-web graphite-carbon mysql-server python-mysqldb python-pymysql apache2 libapache2-mod-wsgi apt-transport-https ssl-cert python-pip -y
Es folgen ca. 300MB an Daten.
Daraufhin stürzen wir uns direkt auf die Konfig.
Wir fangen an folgende Datei zu editieren.
#> vim /etc/graphite/local_settings.py
Darin ändern wir folgende Settings Sinnvoll in etwas was wir für unsere Installation benötigen.
Also SECRET_KEY, TIME_ZONE & ALLOWED_HOSTS setzen.
Danach muss in der folgenden Datei ein “true” gesetzt werden damit graphite & carbon gemeinsam starten.
#> vim /etc/default/graphite-carbon
Nun kommt der trickreichste Part wir sind leider dazu genötigt eine alte django Version zu installieren.
#> pip install "django==1.4"
Damit haben wir die Grundlage womit wir das folgende Kommando erfolgreich absetzen können.
#> graphite-manage syncdb
#> Kundenverbesserung: Danke an bbtronic!
#> graphite-manage migrate --run-syncdb
#> chown _graphite. /var/lib/graphite/graphite.db
HINWEIS ! Dies setzt erst mal die voreingestellte sqlitedb in Gang.
Wenn eine andere DB verwendet werden soll dann sollte dies bitte in der “local_settings.py” vorgenommen werden.
Wir sind fast am Ziel ein funktionierendes graphite-web zu haben.
Es fehlt nur etwas Apache2 Magie.
#>a2dissite 000-default.conf
#>cp /usr/share/graphite-web/apache2-graphite.conf /etc/apache2/sites-available/
#> a2ensite apache2-graphite.conf
#> systemctl restart apache2

Voilà !

Es sollte nun auf dem Host System das graphite-web aufrufbar sein.

Danke für die Aufmerksamkeit !

Addenum nicht Sichtbare Kommentare von Kunden:
# Oliver: Ich bekam leider den Fehler:
twisted.python.usage.UsageError: Unknown command: carbon-cache

Hier hat dies geholfen:
mv /usr/local/lib/python2.7/dist-packages/twisted /usr/local/lib/python2.7/dist-packages/twisted2

Hier half mir ein downgrade:
python -m pip install ‘django-tagging<0.4' Das hatte ich auch, habe es mit upgrade auf django 1.5 beseitigen können: python -m pip install django==1.5 Vinc: hallo David nach dem ich die Installation bei back to the roots gestartet habe, klappte es. Wobei ein paar Infos unter Also SECRET_KEY, TIME_ZONE & ALLOWED_HOSTS wäre wohl noch nützlich. Aber trotzdem – klappt es nicht – die “bilder” erscheinen nicht wie wenn der Pfad falsch ist. gruss vinc

David Okon
David Okon
Support Engineer

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

Veranstaltungen

Mi 21

Icinga 2 Advanced Training | Online

April 20 @ 09:00 - April 22 @ 17:00
Mi 21

InfluxDB & Grafana | Online

April 20 @ 09:00 - April 21 @ 17:00
Di 27

Elastic Stack Training | Online

April 27 @ 09:00 - April 29 @ 17:00
Di 27

Graylog Training | Online

April 27 @ 09:00 - April 28 @ 17:00
Mai 04

GitLab Fundamentals Training | Online

Mai 4 @ 09:00 - Mai 5 @ 17:00