Ansible + Icinga 2 = #monitoringlove

Ansible + Icinga 2 = #monitoringlove

Nein, ich bin nicht auf den Hype als solchen mit aufgesprungen. Es ist nur so… Ansible ist extrem nützlich. Und genau das werde ich anhand eines konkreten Beispiels aufzeigen: Ein Icinga 2 Cluster, vollständig aufgesetzt mit Ansible.

Vorkenntnisse

Wer noch nicht weiß, was zum Geier ein Icinga 2 Cluster und/oder Ansible ist, sollte sich vor dem Weiterlesen entsprechend einarbeiten, am besten im Rahmen einer entsprechenden Schulung in unserem Hause:

Alternativ ginge auch das wesentlich mühseligere Selbststudium:

Umgebung

So ein bisschen sensationell soll der Cluster schon sein, aber mit zunehmenden VMs wird es auch zunehmend eng auf meinem Arbeitsgerät. Wie praktisch, dass wir bei NWS einen OpenStack haben, dem ich mal schnell mit Terraform 14 VMs reindrücken kann (2 Master, 2 Satelliten und 10 Agents):

resource "openstack_compute_instance_v2" "aklimov-icinga2" {
	count = 14
	name = "aklimov-icinga2-${count.index}"
	image_name = "Centos 7"
	flavor_name = "s1.small"
	network { name = "${var.tenant_network}" }
	security_groups = [ "default", "Icinga" ]
	key_pair = "${var.openstack_keypair}"
}

Mit einem kleinen Skript in der Sprache meiner Wahl erstelle ich mir anhand der Terraform-Daten mehr oder weniger automatisch ein Ansible-Inventory (inventory.txt):

aklimov-icinga2-5 ansible_host=10.77.27.54 ansible_user=centos
aklimov-icinga2-4 ansible_host=10.77.27.45 ansible_user=centos
aklimov-icinga2-7 ansible_host=10.77.27.51 ansible_user=centos
aklimov-icinga2-9 ansible_host=10.77.27.40 ansible_user=centos
aklimov-icinga2-12 ansible_host=10.77.27.28 ansible_user=centos
aklimov-icinga2-13 ansible_host=10.77.27.18 ansible_user=centos
aklimov-icinga2-10 ansible_host=10.77.27.12 ansible_user=centos
aklimov-icinga2-1 ansible_host=10.77.27.34 ansible_user=centos
aklimov-icinga2-6 ansible_host=10.77.27.20 ansible_user=centos
aklimov-icinga2-3 ansible_host=10.77.27.49 ansible_user=centos
aklimov-icinga2-11 ansible_host=10.77.27.19 ansible_user=centos
aklimov-icinga2-0 ansible_host=10.77.27.21 ansible_user=centos
aklimov-icinga2-2 ansible_host=10.77.27.46 ansible_user=centos
aklimov-icinga2-8 ansible_host=10.77.27.50 ansible_user=centos

Auf die Plätze, fertig, Ansible!

Zunächst verifiziere ich die Funktionalität der VMs und sammle nebenbei deren öffentliche SSH-Schlüssel ein:

ansible all -i inventory.txt -m ping \
--ssh-common-args='-o StrictHostKeyChecking=no'

Ist das getan, geht es auch schon los mit dem Ansible-Playbook (playbook.yml):

---
- name: Icinga 2
  hosts: all
  become: yes
  become_method: sudo
  tasks:
  - name: EPEL repo
    yum:
      name: epel-release
  - name: Icinga repo key
    rpm_key:
      key: https://packages.icinga.com/icinga.key
  - name: Icinga repo
    yum:
      name: https://packages.icinga.com/epel/icinga-rpm-release-7-latest.noarch.rpm
  - name: Icinga 2 package
    yum:
      name: icinga2
  - name: Monitoring plugins
    yum:
      name: nagios-plugins-all
  - name: Icinga 2 service
    service:
      name: icinga2
      state: started
      enabled: yes
# (...)

Ein paar Repositories, ein paar Pakete – und Icinga ist auch schon einsatzbereit. Fehlt nur noch der eigentliche Cluster:

---
- name: Icinga 2
# (...)
- name: Icinga PKI master
  hosts: aklimov-icinga2-0
  become: yes
  become_method: sudo
  tasks:
  - name: Icinga 2 cluster setup
    shell: >
      icinga2 node setup
      --zone master
      --listen 0.0.0.0,5665
      --cn {{ inventory_hostname }}
      --master
      --disable-confd;
      rm -f /var/cache/icinga2/icinga2.vars
    args:
      creates: /var/lib/icinga2/certs/ca.crt
    notify: Restart Icinga 2
  - name: /var/cache/icinga2/icinga2.vars
    shell: icinga2 daemon -C
    args:
      creates: /var/cache/icinga2/icinga2.vars
  - name: Icinga 2 PKI ticket
    with_inventory_hostnames:
    - 'all:!{{ inventory_hostname }}'
    shell: >
      icinga2 pki ticket --cn {{ item }}
      >/var/cache/icinga2/{{ item }}.ticket
    args:
      creates: '/var/cache/icinga2/{{ item }}.ticket'
  - name: Fetch Icinga 2 PKI ticket
    with_inventory_hostnames:
    - 'all:!{{ inventory_hostname }}'
    fetch:
      dest: .tempfiles
      src: '/var/cache/icinga2/{{ item }}.ticket'
  - name: Fetch Icinga 2 master cert
    fetch:
      dest: .tempfiles
      src: '/var/lib/icinga2/certs/{{ inventory_hostname }}.crt'
  handlers:
  - name: Restart Icinga 2
    service:
      name: icinga2
      state: restarted
# (...)

Zuerst wird der Knoten eingerichtet, der allen anderen Tickets und später SSL/TLS Zertifikate ausstellt. Dann werden auch schon die Tickets ausgestellt, nachdem /var/cache/icinga2/icinga2.vars dafür neu erstellt wurde. Diese Tickets und das Zertifikat des Knotens werden danach in das Verzeichnis .tempfiles heruntergeladen. Die anderen Knoten brauchen diese Dateien, um sich automatisch an den Cluster anzuschließen:

---
- name: Icinga 2
# (...)
- name: Icinga PKI master
# (...)
- name: Icinga cluster nodes
  hosts: 'all:!aklimov-icinga2-0'
  become: yes
  become_method: sudo
  tasks:
  - name: Icinga master cert
    copy:
      dest: /var/cache/icinga2/trusted.crt
      owner: icinga
      group: icinga
      mode: '0644'
      src: .tempfiles/aklimov-icinga2-0/var/lib/icinga2/certs/aklimov-icinga2-0.crt
  - name: Icinga PKI ticket
    copy:
      dest: /var/cache/icinga2/my.ticket
      owner: icinga
      group: icinga
      mode: '0600'
      src: '.tempfiles/aklimov-icinga2-0/var/cache/icinga2/{{ inventory_hostname }}.ticket'
  - name: Icinga 2 cluster setup
    shell: >
      icinga2 node setup
      --zone {{ inventory_hostname }}
      --endpoint aklimov-icinga2-0,{{ hostvars['aklimov-icinga2-0'].ansible_all_ipv4_addresses[0] }},5665
      --parent_host {{ hostvars['aklimov-icinga2-0'].ansible_all_ipv4_addresses[0] }},5665
      --parent_zone master
      --listen 0.0.0.0,5665
      --ticket `cat /var/cache/icinga2/my.ticket`
      --trustedcert /var/cache/icinga2/trusted.crt
      --cn {{ inventory_hostname }}
      --accept-config
      --accept-commands
      --disable-confd
    args:
      creates: /var/lib/icinga2/certs/ca.crt
    notify: Restart Icinga 2
  handlers:
  - name: Restart Icinga 2
    service:
      name: icinga2
      state: restarted

Und ab dafür:

ansible-playbook -i inventory.txt playbook.yml

Voilà!

(...)

PLAY RECAP *******************************************************************************************************
aklimov-icinga2-0          : ok=14   changed=12   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-1          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-10         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-11         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-12         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-13         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-2          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-3          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-4          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-5          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-6          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-7          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-8          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-9          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Jetzt fehlt nur noch die Icinga-Konfiguration. Aber diese überlasse ich keinem geringeren als dem Icinga Director.

Fazit

Was man nicht alles von A bis Z automatisieren kann!

Viel Spaß beim Nachmachen in der NWS Cloud!

Alexander Klimov
Alexander Klimov
Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der...

Foreman’s 10th birthday – The party was a blast

Birthday Logo

I can still remember when Greg had the idea of celebrating the Foreman’s Birthday four years ago and I volunteered to organize the German one. After two editions and with Foreman being covered on the Open Source Camp last year I asked for others to run the party. And with ATIX doing a great job I asked them to team up on this. So we have grown a great community event with the annual Birthday party.

This year was different to the ones before because we had such a big support by Red Hat. The new Community Managers showed up to introduce them accompanied by Greg who had stepped down earlier this year. A group of Product managers and consultants made the last stop on their European tour. A technical writer came over to discuss the future of documentation. And with Evgeni and Ewoud we had some recurring attendees to give a talk later. ATIX also arrived with a bus full of people. Monika represented iRonin, a company doing custom development on Foreman and I hope to team up in the future, and Timo developing on Foreman for dmTech brought a colleague. So users were slightly under-represented and the prepared demos were mostly used to share knowledge and probably because of the heat instead of hacking many discussions took place. But I think everyone of the about thirty attendees made good use of the first session.

Birthday PartyDemoThe session ended when I brought in the cake. And thanks to our Events team the cake was as tasty as good looking. A nice touch by Ohad was to insist he can not blow off the candles alone as he could not have build Foreman without the community.

Birthday CakeHelmets

After the cake break we started with the talks and the first one was by the Community team giving us a recap of Foreman’s history, data from the community survey and other insights like a first look on the future documentation. This is really the next step to me that Red Hat is also making their Satellite documentation upstream adding a use case driven documentation to the manual which is way more technical. The second talk Quirin showcased the current state of Debian Support which will be fully functional with Errata support being added, but he already promised some usability and documentation improvements afterwards. The third speakers were Dana and Rich who showed Red Hat’s roadmap for features to add to Foreman so they will be pulled into Satellite afterwards. The roadmap will be presented in a community demo and uploaded to the community forum. Having the product managers easily available allowed the audience also to ask any question and I was excited to hear for almost all topics brought up that there is already ongoing work in the background. For example I asked about making subscription management also usable for other vendors and Rich told me he is part of a newly founded team which is evaluating exactly this.

Because of the heat we added a small ice break before starting the next talk and because of Lennart being ill Ohad entered the stage to show his work on containerizing Foreman. He explained that he started it mainly for testing but the interest showed him that expanding it to be fully functional to run Foreman and even Katello on Kubernetes could be a future way. Evgeni gave a shortened version of the talk on writing Ansible modules for Foreman and Katello he created for Froscon. It was a very technical one showing how much work is necessary to build a good base so later work is much easier. From this perspective I can really recommend this talk to all Froscon attendees. Last but not least Ewoud looked into the project’s social aspects which was a nice mixture of official history and personal moments. He also showed off the different swag the project created, ending with a t-shirt signed by as many team and community members as possible while traveling from Czech to US and back as suitable gift to Greg because “Once a foreman, always a foreman”. 😉

For dinner we had Pizza and Beer, but moved to the air-conditioned hotel bar after a short while to finish the evening. I heard people were enjoying conversation until two o’clock in the morning even when the bar closed one hour earlier. 😀

I would say the Party was a blast and I am already looking forward to next year when ATIX will be the host again. But until then there are several other Foreman related events with the Open Source Automation Day on 15. & 16.10.2019 in Munich including Workshops the day before and a Foreman hackday the day after organized by ATIX and the Open Source Camp on 07.11.2019 in Nuremberg right after OSMC by NETWAYS.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Automatisierte Updates mit Foreman Distributed Lock Manager

Foreman Logo

Wer kennt das nicht am besten soll alle nervige, wiederkehrende Arbeit automatisiert werden, damit man mehr Zeit für spaßige, neue Projekte hat? Es gibt nach Backups wohl kein Thema, mit dem man so wenig Ruhm ernten kann, wie Updates, oder? Also ein klarer Fall für Automatisierung! Oder doch nicht weil zu viel schief gehen kann? Nun ja, diese Entscheidung kann ich euch nicht abnehmen. Aber zumindest für eine häufige Fehlerquelle kann ich eine Lösung anbieten und zwar das zeitgleiche Update eines Clusters, was dann doch wieder zum Ausfall des eigentlich hochverfügbaren Service führt.

Bevor ich aber nun zu der von mir vorgeschlagen Lösung komme, will ich kurz erklären wo die Inspiration hierfür herkommt, denn Foreman DLM (Distributed Lock Manager) wurde stark vom Updatemechanismus von CoreOS inspiriert. Hierbei bilden CoreOS-Systeme einen Cluster und über eine Policy wird eingestellt wie viele gleichzeitig ein Update durchführen dürfen. Sobald nun ein neues Update verfügbar ist, beginnt ein System mit dem Download und schreibt in einen zentralen Speicher ein Lock. Dieses Lock wird dann nach erfolgreichem Update wieder freigegeben. Sollte allerdings ein weitere System ein Lock anfordern um sich upzudaten und die maximalen gleichzeitigen Locks werden bereits von anderen Systemen gehalten, wird kein Update zu dem Zeitpunkt durchgeführt sondern später erneut angefragt. So wird sichergestellt, dass die Container-Plattform immer mit genug Ressourcen läuft. CoreOS hat dazu dann noch weitere Mechnismen wie einen einfachen Rollback auf den Stand vor dem Update und verschiedene Channel zum Testen der Software, welche so einfach nicht auf Linux zur Verfügung stehen. Aber einen Locking-Mechanismus zur Verfügung zu stellen sollte machbar sein, dachte sich dmTech. Dass die Wahl auf die Entwicklung als ein Foreman-Plugin fiel lässt sich leicht erklären, denn dieser dient dort als das zentrale Tool für die Administration.

Wie sieht nun die Lösung aus? Mit der Installation des Plugins bekommt Foreman einen neuen API-Endpunkt über den Locks geprüft, bezogen und auch wieder freigegeben werden können. Zur Authentifizierung werden die Puppet-Zertifikate (oder im Fall von Katello die des Subscription-Managers) genutzt, die verschiedenen HTTP-Methoden stehen für eine Abfrage (GET), Beziehen (PUT) oder Freigaben (DELETE) des Lock und die Antwort besteht aus einem HTTP-Status-Code und einem JSON-Body. Der Status-Code 200 OK für erfolgreiche Aktionen und 412 Precondition Failed wenn Beziehen und Freigeben des Locks nicht möglich ist sowie der Body können dann im eigenen Update-Skript ausgewertet werden. Ein einfaches Beispiel findet sich hierbei direkt im Quelltext-Repository. Ein etwas umfangreicheres Skript bzw. quasi ein Framework wurde von einem Nutzer in Python entwickelt und ebenfalls frei zur Verfügung gestellt.
(mehr …)

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.
NWS Cloud and Terraform – does this work?

NWS Cloud and Terraform – does this work?

A few months ago we launched our OpenStack project within our NWS platform. The NWS Cloud was born.
Since then we are trying to increase the performance and the possibilities of the cloud. And nowadays there is no way around Terraform.

So i had a look at the possibilities and had to try them out. One of my first runs should create a virtual machine, create some security rules, attach a public IP to the virtual machine and install a webserver with a customized index.html

And how this works, i want to show now.

 

But first of all, i have to save my credentials in my config file

variables.tf

variable "openstack_user_name" { description = "The username for the Tenant." default = "my-nws-user" } variable "openstack_tenant_name" { description = "The name of the Tenant." default = "my-nws-project" } variable "openstack_password" { description = "The password for the Tenant." default = "my-password" } variable "openstack_auth_url" { description = "The endpoint url to connect to OpenStack." default = "nws-cloud" } variable "openstack_keypair" { description = "The keypair to be used." default = "mgebert" } variable "tenant_network" { description = "The network to be used." default = "my-nws-project" }

With this variables i can now start writing the rest of my files. I had to configure the provider

provider.tf

provider "openstack" { user_name = "${var.openstack_user_name}" tenant_name = "${var.openstack_tenant_name}" password = "${var.openstack_password}" auth_url = "${var.openstack_auth_url}" }

And the “script” which should run on the new virtual machine

bootstrapweb.sh

#!/bin/bash apt update apt install -y apache2 cat <<EOF > /var/www/html/index.html <html> <body> <p>hostname is: $(hostname)</p> </body> </html> EOF chown -R www-data:www-data /var/www/html systemctl apache2 start

But there is still no server right? So i have to write my deploy file.

deploy.tf

resource "openstack_networking_secgroup_v2" "secgroup1" { name = "ALLOW SSH AND HTTP" } resource "openstack_networking_secgroup_rule_v2" "secgroup_rule_1" { direction = "ingress" ethertype = "IPv4" protocol = "tcp" port_range_min = 22 port_range_max = 22 remote_ip_prefix = "0.0.0.0/0" security_group_id = "${openstack_networking_secgroup_v2.secgroup1.id}" } resource "openstack_networking_secgroup_rule_v2" "secgroup_rule_2" { direction = "ingress" ethertype = "IPv4" protocol = "tcp" port_range_min = 80 port_range_max = 80 remote_ip_prefix = "0.0.0.0/0" security_group_id = "${openstack_networking_secgroup_v2.secgroup1.id}" } resource "openstack_networking_secgroup_rule_v2" "secgroup_rule_3" { direction = "ingress" ethertype = "IPv4" protocol = "icmp" remote_ip_prefix = "0.0.0.0/0" security_group_id = "${openstack_networking_secgroup_v2.secgroup1.id}" } resource "openstack_compute_instance_v2" "web" { name = "web01" image_name = "Ubuntu Xenial" availability_zone = "HetznerNBG4" flavor_name = "s2.small" key_pair = "${var.openstack_keypair}" security_groups = ["default","ALLOW SSH AND HTTP"] network { name = "${var.tenant_network}" } user_data = "${file("bootstrapweb.sh")}" } resource "openstack_networking_floatingip_v2" "floating" { pool = "public-network" } resource "openstack_compute_floatingip_associate_v2" "floating" { floating_ip = "${openstack_networking_floatingip_v2.floating.address}" instance_id = "${openstack_compute_instance_v2.web.id}" }

 

In this file i configure first of all the new security group and afterwards 3 rules to allow ICMP, HTTP and SSH. Then we can start the virtual machine with a name, image_name, a flavor_name, security_groups and so on. I could configure more, like a loop which creates me 10 web-servers with the name web-01 to web-10 . But for now, thats fine. When the server is up and running, the deploy will attach a floating IP to it, so i can access it without a VPN.

And thats it, basically. When it is installed, the bootstrapweb.sh will install the apache2 webserver and replace the default index.html with my custom one.

There is almost no setup which can’t be build up with terraform in combination with the NWS Cloud – so just try it yourself

If you want to see the code above in action, have a look at this video!

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

10th Foreman Birthday Event

Since 10 years the Foreman is at our sides to improve our lifes and manage our physical and virtual servers. Since 10 years Foreman gives system administrators the power to easily automate repetitive tasks, quickly deploy applications, and proactively manage servers. It’s time to provision your travel luggage and configure your calendars to alert you on July 25, 2019! Save the date for the 10th Foreman Birthday Party organized by NETWAYS, ATIX and the Foreman Project!

We celebrate with

2+ Hours of hands-on Demos and Hacking Space (12:30 – 15:00)

Perfect for your first steps with Foreman. Get help from some of the experienced people present, or just do some in-person hacking. Demo stations will deal with:

  • Orcharhino (Katello based lifecycle management by ATIX)
  • Katello
  • Foreman with Puppet & plugins
  • Foreman with Ansible & plugins

Technial Talks (15:00 – 18:00)

Get to know about the latest developments and integrations.

Good conversations, Pizza and Drinks (18:00 – Open End)

Now, that’s a party!

Confirmed speakers and project members

Flying in from India, Israel and the USA
Rahul Bajaj and Ori Rabin, the Foreman project community team will be presenting the status of the project
Dana Singleterry and Richard Jerrido, Product Managers of the Red Hat Satellite
Ohad Levy, the founder of the Foreman project 

From the Red Hat office in Dusseldorf and Brno
Evgeni Golov and Ewoud Kohl van Wijngaarden, developers at Red Hat and Foreman project members. Evgeni will talk about writing Ansible modules for Foreman and Katello. 

Coming over from Munich
Mark Hlawatschek, CEO at ATIX, and Bernhard Suttner, Head of Development at ATIX

Welcoming you in Nuremberg
Dirk Götz and Lennart Betz, Senior Consultants at NETWAYS

When? July 25, 2019

Where? The famous Kesselhaus at NETWAYS, Deutschherrnstr. 15-19, 90429 Nuremberg

Admission free!

Want to join? Register here

Want to talk? Contact dirk.goetz@netways.de

Julia Hornung
Julia Hornung
Marketing Manager

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

New and Next in Automation: Notes on OSCamp Berlin

„The pig go. Go is to the fountain. The pig put foot. Grunt. Foot in what? Ketchup. (…)“

A beautiful crowd of people learned this poem thanks to Felix Frank‘s talk at OSCamp on Ansible in Berlin. That’s it? For sure not! OSCamp conveyed all that’s new and next in automation.

“Ansibuild your system”, was the plea made by Toshaan Bharvani. Ansible code is CODE, as we learned in Klaus Franken‘s talk about Automated Tests of Ansible code with GitLab, Vagrant, VirtualBox and Ansible.

Is that an Ansible?

Is that an Ansible? Stop holding it like a puppet, claimed Felix Frank. Later on he put AWX in a nutshell („A service that runs your Ansible code from one central place. Comes with a web UI and a REST API.“) and proved some of it’s most convincing advantages ­ with his live demo.

Nikhil Kathole from Red Hat showed how Ansible and Foreman integrate with one another and got everone into demo mode. In „Directing the Director“ Martin Schurz from T-Systems shared how they designed their new central monitoring system based on Icinga 2.

And as Felix, Adam Ruzicka from Red Hat pleased us with two talks, first introducing the Foreman Project and later on demonstrating two primary approaches of using Ansible from Foreman.

We want to thank everyone, who took part in Open Source Camp in Berlin! It was a great event!

We hope to see you soon!

Next Open Source Camp will be on Foreman. Right after OSMC. In Nuremberg.
Save the date: Nov 07, 2019!

 

Julia Hornung
Julia Hornung
Marketing Manager

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