NETWAYS Blog

OSDC 2017: Community connects

von Michael Friedrich | Mai 18, 2017 | Events, OSDC

After a fully packed and entertaining first day at OSDC, we really enjoyed the evening event at Umspannwerk Ost. Warm weather, tasty food and lots of interesting discussions, just relaxing a bit and preparing for day 2 🙂

Warming up

Grabbed a coffee and started with Julien Pivotto on Automating Jenkins. Continuous integration matters these days and there’s not only Jenkins but also GitLab CI and more. Julien told us why automation for Jenkins is needed. Likewise, „XML Everywhere“ makes configuration a bit tad hard. Same thing goes for plugins, you literally can’t run Jenkins without. Julien also told us „don’t edit XML“, but go for example for Groovy and the Jenkins /script API endpoint. The Jenkins pipeline plugin even allows to use YAML as config files. In terms of managing the daemon, I learned about „init.groovy.d“ to manage and fire additional Groovy scripts. You can use the Job DSL Groovy plugin to define jobs in a declarative manner.
Julien’s talk really was an impressive deep dive leading to Jenkins running Docker and more production hints. After all an amazing presentation, like James said 🙂

At #OSDC @roidelapluie is giving an amazing comprehensive presentation on how to automate @jenkinsci

— James Just James (@purpleidea) May 18, 2017

I decided to stay in MOA5 for the upcoming talks and will happily await the conference archive once videos are uploaded in the next couple of days.
Casey Calendrello from CoreOS led us into the evolution of the container network interface. I’m still a beginner with containers, Kubernetes and also how networks are managed with it, so I learned quite a lot. CNI originates from rkt and is now built as separate project and library for Go-built software. Casey provided an impressive introduction and deep dive on how to connect your containers to the network – bridged, NAT, overlay networks and their pros and cons. CNI also provides many plugins to create and manage specific interfaces on your machine. It’s magic, and lots of mentioned tool names certainly mean I need to look them up and start to play to fully understand the capabilities 😉

Energetic delivery by @squeed at #OSDC pic.twitter.com/LbE2ha3jQt

— Felix Frank ? ‏ (@felis_rex) May 18, 2017

Yesterday Seth Vargo from HashiCorp had 164 slides and promised to just have 18 today, us moving to lunch soon. Haha, no – it is live demo time with modern secrets management with Vault. We’ve also learned that Vault was developed and run at HashiCorp internally for over a year. It received a security review by the NCC group before actually releasing it as open source. Generally speaking it is „just“ an encrypted key value store for secrets. Seth told us „our“ story – create a database password once, write it down and never change it for years. And the process to ask the DBA to gain access is so complicated, you just save the plain-text password somewhere in your home directory 😉
Live demo time – status checks and work with key creation. Manage PostgreSQL users and credentials with vault – wow, that simple? That’s now on the TODO list to play with too. Seth also released the magic Vault demo as open source on GitHub right after, awesome!

Wow. Manage #postgresql users and credentials with #vault – it just works 🙂 @sethvargo #osdc /mif pic.twitter.com/iTNYdIyHhC

— netways (@netways) May 18, 2017

Enjoying the afternoon

We had tasty lunch and were glad to see Felix Frank following up with „Is that an Ansible? Stop holding it like a Puppet!“ – hilarious talk title already. He provided an overview on the different architecture and naming schemas, community modules (PuppetForge, Ansible Galaxy) and also compared the configuration syntax (Hash-Like DSL, YAML). Both tools have their advantages, but you certainly shouldn’t enforce one’s mode onto the other.

OH @felis_rex "That's a thing which gets me a little wild." #namingthingsishard #ansible #puppetize #osdc pic.twitter.com/ixJwpng8Mc

— Michael Friedrich (@dnsmichi) May 18, 2017

Puh, I learned so many things today already. I’ve unfortunately missed Sebastian giving an introduction about our very own NETWAYS Web Services platform managed with Mesos and Marathon (I rest assured it was just awesome).
After a short coffee break we continued to make decisions – previously Puppet vs. Ansible, now VMware vs. Rudder, location-wise. I decided to listen to Dr. Udo Seidel diving into „VMware’s (Open Source) way of Container„. VMWare is traditionally not very open source friendly, but things are changing. Most likely you’ve heard about Photon OS serving as minimal container host. It was an interesting talk about possibilities with VmWare, but still, I left the talk with the „yet another platform“ feeling.
Last talk for a hilarious day about so many learnt things is about containerized DBs by Claus Matzinger from Crate.io. CrateDB provides shared nothing architecture and includes partitioning, auto-sharing, replication. It event supports structured and unstructured data plus SQL language. Sounds promising after all.
Dirk talked about Foreman as lifecycle management tool in MOA4, too bad I missed it.

"The usual intro applies: we are @netways, we are hiring, you know…all that jazz" – Dirk Götz at #OSDC pic.twitter.com/nj1hkCfxw4

— Felix Frank ? ‏ (@felis_rex) May 18, 2017

Conclusion

Coffee breaks and lunch unveiled so many interesting discussions. Food was really tasty and I’m sure everyone had a great time, so did I. My personal highlights this year: Follow-up Seth’s talk and try Consul and Vault and do a deep dive into mgmt and tell James about it. Learn more about Ansible and put it into context with Puppet, like Felix has shown in his talk. As always, I’m in love with Elastic beats and will follow closely how to log management evolves, also on the Graylog side of life (2.3 is coming soon, Jan and Bernd promised).
Many thanks to our sponsor Thomas Krenn AG for being with so long. And also for the tasty Linzer Torte – feels like home 🙂

Thank you @netways for the exciting #OSDC conference and for (OPEN)powering open source /wf pic.twitter.com/xa8s7cNda9

— Thomas-Krenn.AG (@ThomasKrennAG) May 18, 2017

Thanks for a great conference, safe travels home and see you all next year!
Save the date for OSDC 2018: 12. – 14.6.2018!

Monthly Snap January: Dev Tools, Clusters & Events and Trainings

von Stephanie Kotilge | Feb 3, 2016 | OSDC, Trainings, WeeklySnap, OpenNebula, GitLab, Container, Hardware

January offered tips for cluster admins, programmers and technophiles, plus news on the events front.
Pamela counted 13 weeks to the OSDC and introduced the thematic focuse of the conference. She went on to announce our participation and sponsorship of the OpenNebula TechDay in June. Daniela, meanwhile, explained how to become a Puppet expert in just 5 days.
Micheal shared tips to work with the git subtree and MarkusW then showed how to generate pdf´s with Showoff.
On clusters, Blerim looked at distributed containers with CoreOS, while Johannes introduced Bottle, a web-framework for Python.
Lastly, MariusH presented building automation systems as Cornelius presented the Raspberry Pi Touch Display.

Stephanie Kotilge

Accountant

Steffi ist seit 2011 bei NETWAYS. Sie fing als Office Managerin an und unterstützt seit 2017 als Accountant das Finance & Administration Team in allen buchhalterischen Belangen. In ihrer Freizeit ist sie mit ihrem Sohn immer auf der Suche nach den schönsten Spielplätzen in Nürnberg oder plant den nächsten Familientrip.

Lies mehr von Stephanie und triff unser Team

Monthly Snap August: Monitoring Plugins, Icinga 2 on Windows 10, Tips and Tricks for Git, Docker and CoreOS

von Stephanie Kotilge | Sep 15, 2015 | Serien, Windows, Icinga, Technology, OSMC, Development

August started with Enrico´s post about a check for S.M.A.R.T. values which he has been using already successfully for one year.
Markus F. announced his talk “Why favor Icinga over Nagios?” at DebConf15 where NETWAYS is also sponsor. camera
Bernd counted 84 days to the OSMC with Oliver Jan´s talk: “Time to say goodbye to your Nagios based setup?”
Christoph looked at how to write monitoring plugins on your own and Sebastian told us about the core component of CoreOS etcd and gave us a quick example of how to use it.
Michael followed with his post about how to develop Icinga 2 on Windows 10 by using Visual Studio 2015 and Thilo explained us why time is unique.
Blerim explained why logging, especially with Docker, should be part of every good monitoring.
Finally, Matthias showed tips and tricks for using Git Bisect to find a fix for a problem rather than finding the commit that introduced a problem.

Stephanie Kotilge

Accountant

Lies mehr von Stephanie und triff unser Team

CoreOS und etcd

von Sebastian Saemann | Aug 4, 2015 | Linux, Web Services

Im zweiten Teil der Serie wird eine Kernkomponente von CoreOS beschrieben: etcd. Etcd ist ein distributed Key-Value-Store, der für die Konfiguration und das Service-Discovery innerhalb eines CoreOS Clusters verantwortlich ist. Wie viele Tools im Docker Umfeld ist auch etcd in Go geschrieben. Es zeichnet sich durch seine Geschwindigkeit, Verlässlichkeit, Sicherheit und Einfachheit aus. Für sein Konsens verwendet es das Raft Protokoll. Etcd kann man über API (HTTP+JSON) sowie über ein Command Line Interface (etcdctl) steuern.
Ein Beispiel verdeutlicht sehr schnell und einfach, wie etcd verwendet werden kann, um Daten zu schreiben bzw. sie wieder auszulesen:
$ etcdctl set /message Hello Hello
$ etcdctl get /message Hello
oder per HTTP-API
$ curl -L -X PUT http://127.0.0.1:4001/v2/keys/message -d value="Hello" {"action":"set","node":{"key":"/message","value":"Hello","modifiedIndex":4,"createdIndex":4}}
$ curl -L http://127.0.0.1:4001/v2/keys/message {"action":"get","node":{"key":"/message","value":"Hello","modifiedIndex":4,"createdIndex":4}}
Neben der erwähnten Konfiguration des CoreOS Clusters selbst ist es möglich seine gestarteten Container mit Hilfe von etcd wieder zu finden. Das Schlüsselwort ist „Service-Discovery“. Hierfür wird meist ein Sidekick Prozess gemeinsam mit dem eigentlichen Anwendungscontainer gestartet. Der Sidekick kümmert sich hierbei um das Registrieren der Anwendung. Wie im ersten Teil bereits beschrieben, startet man Container und Services über Fleet, das sich wiederum auf Unit-Files stützt.
[Unit] Description=Announce myawesomeapp BindsTo=myawesomeapp@%i.service After=myawesomeapp@%i.service [Service] ExecStart=/bin/sh -c "while true; do etcdctl set /services/myawesomeapp/%i/status/current 'started' --ttl 60; etcdctl set /services/myawesomeapp/%i/status/expected 'started' --ttl 60; etcdctl set /services/myawesomeapp/%i/status/alive 'started' --ttl 60;etcdctl set /services/myawesomeapp/%i/location \"{\\\"host\\\": \\\"%H\\\", \\\"port\\\": \"`docker inspect --format='{{(index (index .NetworkSettings.Ports \"8080/tcp\") 0).HostPort}}' myawesomeapp`\"}\" --ttl 60; etcdctl set /domains/myawesomeapp.netways.de/type 'service' --ttl 60;etcdctl set /domains/myawesomeapp.netways.de/value 'myawesomeapp' --ttl 60;sleep 45;done" ExecStop=/usr/bin/etcdctl rm /services/website/myawesomeapp@%i [X-Fleet] MachineOf=myawesomeapp@%i.service
Das Beispiel zeigt ein Unit-File, das für den Anwendungscontainer (myawesomeapp@.service) einen Sidekick startet. Der Sidekick schreibt verschiedene Informationen des Anwendungscontainers mit einer Gültigkeit (ttl) von 60 Sekunden in etcd unter anderem zum Beispiel seine Location: „etcdctl set /services/myawesomeapp/%i/location“
Das ist wichtig, da in einem Container Cluster die Container auf beliebigen Nodes mit beliebigen Ports gestartet werden können. Ein geeigneter Loadbalancer bzw. geeignete Software kann so dynamisch die aktuelle Umgebung auslesen und Requests an die laufenden Applikationen bzw. Container weiterleiten.
In den nächsten Teilen der Serie wird auf Loadbalancer und Fleet genauer eingegangen.

Sebastian Saemann

CEO Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Lies mehr von Sebastian und triff unser Team

Coreos Übersicht

von Sebastian Saemann | Mai 19, 2015 | Linux, Web Services, Virtualisierung, Serien

Docker, Docker Docker! So oder so ähnlich wird teilweise hämisch oder motivierend auf Ideen kommentiert, seine Anwendung in einen bzw. mehrere Docker Container zu migrieren. Für eine produktive Umgebung reicht das Standard Set von Docker nicht aus, zumindest nicht ohne Docker Swarm, Compose und Machine. Es gibt mittlerweile und gab neben den Produkten aus dem Hause Docker bereits Lösungen, die sich um das Deployment und Managen von Containern kümmern können. Eine sehr gute Alternative ist Mesos, aber auch CoreOS.
In der mehrteiligen Blogserie zu CoreOS werden die einzelnen Komponenten, Features und Vorzüge von CoreOS genauer betrachtet. Im ersten Beitrag zur Serie soll ein erster grober Überblick vermittelt werden.

CoreOS ist ein leichtgewichtiges auf dem Linux Kernel aufbauendes Open Source Betriebssystem. Das System ist auf das Nötigste reduziert, kommt ohne Paketmanager aus und nutzt systemd als init. Neben den essentiellen Userland Tools besteht es im wesentlichen aus: Container Runtime (Docker/Rkt), etcd und fleet. Es kann auf diversen Plattformen betrieben werden wie Vagrant, EC2, KVM, VMware, OpenStack, Digital Ocean Droplets, und natürlich auf eigener Hardware. Updates werden durch Reboots vollzogen.
Eine Variante der Installation ist über PXE/iPXE. Hier wird für die entsprechenden VMs oder Hardware-Server ein korrespondierender PXE-Boot-Eintrag erstellt, der das aktuelle CoreOS Image vorhält. Die einzelnen Maschinen können individuell auf ihre zukünftige Rolle mit einer sogenannten cloud-config konfiguriert werden. Beim boot liest das System diese in YAML formatierte Datei ein und konfiguriert sich entsprechend. Es kann der Discovery Service Endpoint, fleet, etcd, ssh-keys und Dateien konfiguriert werden.
Beispiel cloud-config.yaml:
#cloud-config coreos: units: - name: etcd.service command: start - name: fleet.service command: start ssh_authorized_keys: - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABA....AAAYQC2++odpaavdW2/AU0l7RZiE=
Das Discovery dient zur Clusterbildung und wird von CoreOS bereitgestellt. Natürlich kann man auch seinen eigenen Discovery-Service nutzen. Unter einem eindeutigen Token wird ein neuer Cluster definiert. Die erste Maschine, die startet nimmt Kontakt auf und registriert sich als Leader für den Cluster. Alle weiteren Maschinen, lesen die bereits teilnehmenden Cluster-Nodes aus und können sich entsprechend integrieren und verbinden. Für die Services etcd und fleet sind diese Informationen essentiell.
etcd ist ein verteilter Key-Value-Store, der für Service-Discovery und Konfiguration benutzt wird. Es kümmert sich mit Hilfe des Raft Protokolls um Consensus.
fleet kann man sich als Serverübergreifender systemd vorstellen. Mit Hilfe von Unit-Files erstellt man Services die fleet im Cluster nach Regeln verteilt und startet bzw. stoppt. Ein Service ist in der Regel ein Container.
Beispiel Unit-File:
[Unit] Description=MyApp After=docker.service Requires=docker.service [Service] TimeoutStartSec=0 ExecStartPre=-/usr/bin/docker kill busybox1 ExecStartPre=-/usr/bin/docker rm busybox1 ExecStartPre=/usr/bin/docker pull busybox ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done" ExecStop=/usr/bin/docker stop busybox1
In den nächsten Blogposts der Serie werden die einzelnen Komponenten und weitere wie Loadbalancer etc. genauer betrachtet und anhand von Beispielen näher auf die Vorzüge eines Setups mit CoreOS und mögliche Workflows eingegangen.