Seite wählen

NETWAYS Blog

OSDC 2019: Buzzwo…erm…DevOps, Agile & YAML programmers

von | Mai 14, 2019 | ,

Cheers from Berlin, Moabit, 11th round for OSDC keeping you in the loop with everything with and around DevOps, Kubernetes, log event management, config management, … and obviously magnificent food and enjoyable get-together.

 

Goooood mooooorning, Berlin!

DevOps neither is the question, nor the answer … Arnold Bechtoldt from inovex kicked off OSDC with a provocative talk title. After diving through several problems and scenarios in common environments, we learned to fail often and fail hard, and improve upon. DevOps really is a culture, and not a job title. Also funny – the CV driven development, or when you propose a tool to prepare for the next job 🙂 One key thing I’ve learned – everyone gets the SAME permissions, which is kind of hard with the learned admin philosophy. Well, and obviously we are YAML programmers now … wait … oh, that’s truly inspired by Mr. Buytaert, isn’t it? 😉

Next up, Nicolas Frankel took us on a journey into logs and scaling at Exoscale. Being not the only developer in the room, he showed off that debug logging with computed results actually eats a lot of resources. Passing the handles/pointers to lazy log function is key here, that reminds me of rewriting the logging backend for Icinga 2 😉 Digging deeper, he showed a UML diagram with the log flow – filebeat collects logs, logstash parses the logs into JSON and Elasticsearch stores that. If you want to go fast, you don’t care about the schema and let ES do the work. Running a query then will be slow, not really matching the best index then – lesson learned. To conclude with, we’ve learned that filebeat actually can parse the log events into JSON already, so if you don’t need advanced filtering, remove Logstash from your log event stream for better performance.

Right before the magnificent lunch, Dan Barker being a chief architect at RSA Security for the Archer platform shared stories from normal production environments to actually following the DevOps spirit. Or, to avoid these hard buzzwords, just like „agile“, and to quote „A former colleague told me: ‚I’ve now understood agile – it’s like waterfall but with shorter steps.'“. He’s also told about important things – you’re not alone, praise your team members publicly.

 

Something new at OSDC: Ignites

Ignite time after lunch – Werner Fischer challenged himself with a few seconds per slide explaining microcode debugging to the audience, while Time Meusel shared their awesome work within the Puppet community with logs of automation involved (modulesync, etc) at Voxpupuli. Dan Barker really talked fast about monitoring best practices, whereas one shouldn’t put metrics into log aggregation tools and use real business metrics.

 

The new hot shit

Demo time – James „purpleidea“ Shubin showed the latest developments on mgmt configuration, including the DSL similar to Puppet. Seeing the realtime changes and detecting combined with dynamic processing of e.g. setting the CPU counts really looks promising. Also the sound exaggeration tests with the audience where just awesome. James not only needs hackers, docs writers, testers, but also sponsors for more awesome resource types and data collectors (similar to Puppet facts).

Our Achim „AL“ Ledermüller shared the war stories on our storage system, ranging from commercial netApp to GlusterFS („no one uses that in production“) up until the final destination with Ceph. Addictive story with Tim mimicking the customer asking why the clusterfuck happened again 😉

Kedar Bidarkar from Red Hat told us more about KubeVirt which extends the custom resource definitions available from k8s with the VM type. There are several components involved: operator, api, handler, launcher in order to actually run a virtual machine. If I understand that correctly, this combines Kubernetes and Libvirt to launch real VMs instead of containers – sounds interesting and complicated in the same sentence.

Kubernetes operators the easy way – Matt Jarvis from Mesosphere introduced Kudo today. Creating native Kubernetes operators can become really complex, as you need to know a lot about the internals of k8s. Kudo aims to simplify creating such operators with a universal declarative operator configured via YAML.

 

Oh, they have food too!

The many coffee breaks with delicious Käsekuchen (or: Kaiser Torte ;)) also invite to visit our sponsor booths too. Keep an eye on the peeps from Thomas-Krenn AG, they have #drageekeksi from Austria with them. We’re now off for the evening event at the Spree river, chatting about the things learnt thus far with a G&T or a beer 🙂

PS: Follow the #osdc stream and NetwaysEvents on Twitter for more, and join us next year!

Ansible can talk to your favorite API

von | Apr 26, 2019 | , ,

Ansible is a powerful opensource config management and deployment tool, which can manage nearly any situtation. In many „DevOp“ scenarios we come across multiple platforms, which we need to combine. Mostly applications provide an REST Api or web connectors to manage resources, jobs and deployments within the product.
Ansible provides various modules which can execute commands at specific APIs, such as the vmware-guest-module to create virtual machines or the jenkins-job-module to manage jobs over the Jenkins API.
In cases where no module is available, we can use the module „uri“.

The module takes several parameters, of which the „url“ is the only required one. For this example I picked an example online API „http://dummy.restapiexample.com/“.
To get a list of all employees we use the method GET on , the header Accept: application/json and register the content. 


- name: Make requests to example api
  hosts: localhost
  connection: local
  tasks:
    - name: list employees
      uri:
        method: GET
        url: "http://dummy.restapiexample.com/api/v1/employees"
        return_content: yes
        headers:
          Accept: application/json
      register: response

    - debug:
        msg: "{{ response.content }}"

# Result
TASK [list employees] *************************************************************************
ok: [localhost]

TASK [debug] **********************************************************************************
ok: [localhost] => {
    "msg": [
        {
            "employee_age": "23",
            "employee_name": "test",
            "employee_salary": "46000",
            "id": "12008",
            "profile_image": ""
        }
    ]
}

Now we create a new user in our application, for this we talk to a different url and send a body with our user to create.
When the api accepts JSON I use a little trick to generate a valid json body out of yaml variables with the Ansible filter to_json

For this we create a variable with the same key value structure as the API expects it, in this case the structure looks like this {„name“:“test“,“salary“:“123″,“age“:“23″}. 


- name: Make requests to example api
  hosts: localhost
  connection: local
  vars:
    data:
      chris:
        name: chris
        salary: 46000
        age: 27
      jessy:
        name: jessy
        salary: 70000
        age: 30
  tasks:
    - name: create employee
      uri:
        method: POST
        url: "http://dummy.restapiexample.com/api/v1/create"
        return_content: yes
        headers:
          Accept: application/json
        body_format: json
        body: "{{ item.value | to_json }}" //Render valid json from each dictionary in the variable data.
      with_dict: "{{ data }}"
      register: post_content

    - debug:
        msg: "{{ item.content }}"
      with_items: "{{ post_content.results }}"

# Result
ansible-playbook create_user.yaml

PLAY [Make requests to example api] ********************************************************************

TASK [Gathering Facts] *********************************************************************************
ok: [localhost]

TASK [create employee] *********************************************************************************
ok: [localhost] => (item={'value': {u'salary': 46000, u'age': 27, u'name': u'chris'}, 'key': u'chris'})
ok: [localhost] => (item={'value': {u'salary': 70000, u'age': 30, u'name': u'jessy'}, 'key': u'jessy'})

With this information given, you can now explore your own favorite API and hopefully reduce your daily tasks as simple Ansible playbooks.

Check out our Blog for more awesome posts and if you need help with Ansible send us a message!

Thilo Wening
Thilo Wening
Manager Consulting
Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.
Lies mehr von Thilo und triff unser Team

Verifying YAML

von | Jun 9, 2015 | ,

Wer Puppet mit Hiera und einem YAML Backend nutzt weiß das einfache Format sicherlich zu schätzen. Listen, Maps und Einzelwerte lassen sich schnell, einfach und leserlich abbilden:

Liste1: ["a", "b", "c"]
Liste2:
  - d
  - e
MapEins:
  eins: 1
  zwei: 2
  drei:
    drei: 3
key: value

Zur Interpretation der Datenstrukturen verlässt sich YAML auf eine fehlerfreie Einrückung der einzelnen Elemente, z.B. müssen in Liste2 die Element e und d mit gleich vielen Leerzeichen eingerückt werden. Im Prinzip eine sehr einfach Regel, allerdings ist vermutlich auch schon jeder in solch kleine Stolperfallen des YAML-Formats gelaufen. In Verbindung mit Puppet führt dies manchmal zu unklaren bzw. ungenauen Fehlermeldungen. Oftmals werden Fehler durch zu viele oder zu wenige Leerzeichen, Tabs, unsichtbare Sonderzeichen bzw. falsche Zeilenumbrüche verursacht. Aber soweit muss es nicht kommen, da es viele Möglichkeiten gibt die YAML-Syntax zu prüfen. In der Regel bietet jede Skript Sprache einen YAML-Parser, welche mehr oder weniger klare Fehlermeldungen ausgeben. Für ein kleines Beispiel habe ich ein Element falsch eingerückt und in verschiedenen Skript Sprachen geladen:

$ python -c "import yaml; yaml.load( open('my.yaml', 'r'), Loader=yaml.CLoader  )"
yaml.scanner.ScannerError: mapping values are not allowed in this context
  in "my.yaml", line 8, column 8
$ ruby -e "require 'yaml'; YAML.load_file('my.yaml')"
/usr/share/ruby/psych.rb:370:in 'parse': (my.yaml): mapping values are not allowed in this context at line 8 column 8 (Psych::SyntaxError)
$ js-yaml my.yaml
JS-YAML: bad indentation of a mapping entry at line 8, column 8:
       zwei: 2
           ^

Ihr seht selbst, dass js-yaml den Fehler wohl am besten und klarsten darstellt. Natürlich will keiner immer wieder auf der Command-Line überprüfen ob die verwendeten YAML Dateien korrekt formatiert sind. Am besten soll dies der Editor bereits beim speichern der Datei anzeigen. Wer vim mit Syntastic verwendet muss nur dafür sorgen, dass js-yaml vorhanden ist. Dies installiert man am besten über den Node.js Paket Manager npm.

$ apt-get/yum/dnf install npm
$ npm install -g js-yaml

Wie man Syntastic für vim installiert könnt ihr hier nachlesen.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Lies mehr von Achim und triff unser Team

Encrypted YAML als Hiera Backend

von | Nov 14, 2014 |

yamlHeute auch von mir etwas zum Thema Hiera. Möchte man gewisse Informationen in seinem Hieradata-Store nicht lesbar ablegen, bietet sich die Verwendung von eYaml an. Die Verschlüsselung macht besonders Sinn, wenn ein Versionierungstool zur Ablage verwendet wird.

# gem install hiera-eyaml
# eyaml createkeys

Nach Installation des Backend und dem Erzeigen der Schlüssel, müssen noch die Berechtigungen angepasst werden.

# cp -a ~/keys /etc/puppet/keys
# chown -R root:puppet /etc/puppet/keys
# chmod 0750 /etc/puppet/keys
# chmod 0640 /etc/puppet/keys/*.pem

Die Hiera-Konfiguration könnte wie folgt aussehen:

---
:backends:
  - eyaml
  - yaml
:hierarchy:
  - secure
  - "%{fqdn}
  - defaults
:yaml:
  :datadir: "/etc/puppet/hieradata"
:eyaml:
  :datadir: "/etc/puppet/hieradata"
:pkcs7_private_key: /etc/puppet/keys/private_key.pkcs7.pem
:pkcs7_public_key: /etc/puppet/keys/public_key.pkcs7.pem

Die Datei secure wird nicht komplett verschlüsselt, sondern nur Werte, die als zu verschlüsseln gekennzeichnet werden.

  • eyaml edit /etc/puppet/hieradata/secure.eyaml
  • password mit Encryption Marker einschließen
  • password: DEC::PKCS7[strenggeheim]!

Beim verlassen von eyaml edit wird dann die Verschlüsselung der Werte vorgenommen.

Lennart Betz
Lennart Betz
Senior Consultant
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.
Lies mehr von Lennart und triff unser Team

Trainings

Web Services

Events