Jump to content

Fachinformatiker - Blog

  • Einträge
    41
  • Kommentare
    142
  • Aufrufe
    58.298

Mitwirkende

Konferenzreview: DevOpsCon 2015 in München

Melde dich an, um diesem Inhalt zu folgen  

1.309 Aufrufe

Hallo Welt!

Besser spät als nie möchte ich euch von der DevOpsCon 2015 in München berichten. Dort habe ich zum ersten mal "ernsthaft" den Entschluss gefasst, unter die Blogger zu gehen und die ganzen Gedanken, die mir im Kopf rumschwirren, zu "Papier" zu bringen.

Disclaimer: Aufgrund der Menge an Infos, Tools und Eindrücke der Konferenz kann und werde ich hier nur einen Einblick in die für mich interessantesten Themen geben und über das allgemeine Konferenzfeeling schreiben. Für mehr müsst ihr schon selbst dahin. ;) Es lohnt sich aber, die Themen für Sommer/2016(Berlin) sind im Verhältnis zum Termin Winter/2015 noch recht ähnlich.

sheraton_pool.jpg?w=533&h=300
Pool im 23ten Stock des Hotels - Nicht DAS, aber definitiv eins der Highlights der 3 Tage

Vorwort

Vom 23.11 - 25.11 2015 waren zwei Kollegen von mir(einer der zwei bloggt übrigens auch schon eine ganze Weile) im Sheraton Hotel München im Arabellapark und hatten den Plan, in den zwei Tagen Konferenz und einem Tag Praxis-Workshop so viel wie möglich mitzunehmen, ohne angesichts der Menge an Informationen zu verzweifeln.

Von München selbst haben wir außer einem Besuch im "Burger House 2", was ja auch nicht wirklich "typisch München" ist, nicht wirklich viel mitbekommen. Das ist in Anbetracht der vollgepackten Tage aber auch normal, die BASTA! Spring, die ich 2014 besucht habe, hat einen ähnlichen Effekt verursacht. Außer nem Hefeweizen abends in der Lobby war da nicht mehr viel zu holen bei mir.
Nach dem Abendessen ging es mit den Kollegen eine Runde im Pool schwimmen, den grandiosen Ausblick auf den Liegen um den Pool genießen, den nächsten Tag planen und damit war der Abend meistens auch schon rum.

Tag 1(Workshop)

Zum geschmeidigen Start in den Montag gab es den "Docker-Basis-Workshop" von und mit Peter Roßbach, seines Zeichens Systemarchitekt, Docker-Experte der ersten Stunde und "DevOps"-Enthusiast. Selbst bis dato auf *nix-Systemen völlig unbedarfte Entwickler(wie mich) waren mit Peters Anleitung und aufgrund der Einfachheit der Docker-Syntax in der Lage, in Kürze Container für Webserver, Datenbankserver mit entsprechenden Befehlen zu erzeugen und die Netzwerke gleich mit zu konfigurieren. Mächtiges Tool und mächtige Architektur diese Container-Technologie. Mit einer verhältnismäßig niedrigen Hemmschwelle zum Einstieg und Unmengen an Blogs, Snippets und Infomaterial zu Docker selbst im Netz scheinen die Docker-Container in *nix-Umfeldern eine echte Bereicherung zu sein, wenn es darum geht, skalierbar schnell Infrastruktur bereitzustellen. Obwohl ich mit Infrastruktur und mit Linux bisher wenig zu tun hatte, das hat definitiv mein Interesse geweckt. Der Raspi liegt im Warenkorb. Bücher zu Docker übrigens nicht, die sind oft schon beim Erscheinen veraltet.

Nicht vorenthalten möchte ich euch noch folgendes Zitat von Peter zur Frage , wie man diese Technologie in einer abgeschotteten, kontrollierten Konzern-IT-Infrastruktur implementieren könnte:

"So eine Docker-Welt in einer Enterprise-Company zum Laufen zu bringen kann ein Scheiß-Sport sein."

¯\_(ツ)_/¯

Tag 2&3(Konferenz, Expo)

Nach einem überschaubaren ersten Tag gab es an den Tagen 2 und 3 ausschließlich Vorträge, Keynotes und informell gestaltete Treffen zum Austausch(Open Space-ig).

Gemeinsam war allen von mir besuchten Vorträgen, das sie unglaublich viel Lust aufs "Basteln" machten. Was sich in der Praxis aufgrund der Open Source-Natur vieler genutzten Tools als gar nicht so schwierig herausstellen sollte.

Am interessantesten waren für mich die Talks zum Thema Unternehmenskultur und Veränderung in der Organisationsstruktur des "DevOps"-Unternehmens. Besonders hervorstechend waren da für mich zum einen Wix.com(WYSIWYG-Baukasten für Webseiten) und zum anderen dm(Ja, die Drogerie). Bei Wix war sehr interessant, wie der Referent Aviran Mordo klar und einfach zeigte, dass man nicht jedes Tool benutzen muss, solange man nicht den "Schmerz spürt", den der Einsatz des Tools zu lindern vermag. Wenn deine Idee grundsätzlich Mist ist, bringen dir die besten Tools nichts, deine Idee bleibt Mist.

aviranmordo_microservices_vs_monoliths.j
Das Bild spricht denke ich für sich.

dm im Kontrastprogramm merkte recht schnell, dass man als "Drogerie" mit offenen Augen und Ohren durchaus Gewinn mit ordentlichen Onlineportalen und Webshops machen kann. Ein Onlineshop, der schnell auf die Bedürfnisse der verschiedenen Kunden reagieren kann und in kurzen Abständen qualitativ hochwertige Stände online stellen kann war hier das Credo. Daraus folgte fast natürlich und logisch eine Umstellung des Deployment-Prozesses in Richtung Continuous Delivery und ein damit einhergehendes Umdenken in der Unternehmensorganisation.
Im Verlauf des Talks wurde klar, dass zum einen Vertrauen und Offenheit für ein solches Umdenken notwendig sind. Zum anderen auch, dass dafür nicht jeder bereit ist. Unterm Strich kam jedoch eine effizientere Organisation bei dem Prozess heraus.

Fazit - TL;DR

Das nicht immer alles eitel Sonnenschein ist, war bei allen Vorstellungen von Tools oder Prozessen, die durchlebt wurden, immer zu erkennen. DevOps an sich bedeutet in erster Linie, Verantwortung gemeinsam zu übernehmen für ein geteiltes Bild eines Produkts oder eines Prozesses. Was oft vergessen wird, ist aber, dass dieses Bild manchmal gar nicht existiert oder abteilungsübergreifend völlig anders wahrgenommen wird.

Empathie, echtes Verständnis füreinander und für die Anforderungen des Gesprächspartners waren immer wiederkehrende Merkmale, die notwendig sind, damit so etwas wie Continuous Delivery funktionieren kann.

 

Tools, Tools, Tools!

Zum Abschluss noch ein paar Links und Einzeiler zu vorgestellten Tools, falls jemand bastelwütig wird:

  • Docker - Software, mit der man andere Software(z.B. Betriebssysteme, Webserver, Datenbankserver,...) virtualisiert in "Containern" verpacken kann, die dann auf jedem System funktionieren
  • Hadoop -  Framework für verteilte Software. Man nehme 10 Raspis, schalte sie zusammen und e voilá: Man hat einen Hadoop-Cluster-Datenbankserver
  • ELK-Stack - Bestehend aus Elasticsearch, Logstash und Kibana zum Durchsuchen, Ablegen und Visualisieren von Logs aller Art
  • OWASP ZAP - Zum manuellen oder automatisierten Security-Scan(aktiv, passiv) von Webanwendungen, auch automatisiert in Jenkins verwendbar
  • Jenkins - Tool für Continuous Integration und so ziemlich alles, was dazu gehört. Lächerlich viele und gute Plugins verfügbar
  • Consul - Service Discovery-Tool, das neue Dienste, die verfügbar werden, automatisch erfasst und diese verwalten kann. Nützlich aber erst, wenn man schon mehrere Microservices im Einsatz hat, sonst tut es auch ein DNS-Eintrag
  • Github - Viel mehr als nur das, aber hauptsächlich ein Repository-Server für GIT

Euer "devopsdad" Patrick aka Goulasz

 

Melde dich an, um diesem Inhalt zu folgen  


1 Kommentar


Empfohlene Kommentare

Gast
Kommentar schreiben...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

  • Blogkommentare

    • Also ernsthaft kaputt war noch nichts, ein mittleres Problem sind VMware Vorlagen. Die erste angelegte Vorlage ist nun etwas über ein Jahr alt. Das erste was "kaputt" geht ist der arch-keyring. Pakete von damals gibt es nicht mehr und neue bekommt man unter umständen nicht weil die Signaturen nicht mehr stimmen. Etwas nervig. Dann kann man sich erstmal aktuelle Schlüssel besorgen (pacman-key --refresh-keys) und dann den neuen keyring holen (pacman -S archlinux-keyring) Updates hab ich bishe
    • Arch als Server interessiert mich. Ich nutze es seit 2011 privat als Desktop-OS und erlebe kaum einen Tag ohne mehrere Paket-Updates. Wenn man die zu lange warten lässt, geht später gern mal was kaputt.  Von gefühlt dauernden Kernel-Updates mal ganz zu schweigen. Wie sind deine / eure Erfahrungen damit bisher?
    • Richtig Budgie basiert auf Gnome. Früher war ich zwar kein Gnome Fan aber das sieht schon ganz brauchbar aus. Die Skalierung funktioniert bei dem 4K Display allerdings eher so mittel-gut. Gnome typisch kann man nur 100, 200 und 300% auswählen. 200% ist dann schon wieder zu groß, das Problem lässt sich aber mit xrandr beheben. Das kommt dann im nächsten Teil. oh-my-zsh kenn ich schon, muss mich nur mal tiefer damit beschäftigen. Kommt wohl auch beim nächsten mal, zusammen mit tmux und ranger
    • "Budgie" kenne ich noch nicht - ist das ein Ableger von Gnome? Bei meinem Arch kann ich mich momentan nicht so wirklich zwischen XFCE aus Gewohnheit und i3-gaps wegen der Geschwindigkeit (wenn man fertig eingerichtet...) entscheiden. Wenn du bereits zsh-Fan bist, würde ich noch "oh-my-zsh" empfehlen. Ŭber kleine Module kommt da noch ne ganze Menge an Helferlein für die Shell hinzu.
    • oh super, danke dir. Ja mit den hochgestellten und tiefgestellten zahlen ist das so ne Sache. Da kommt der ein oder andere Fehler gern zustande. Leider kann man das nicht bearbeiten. Also hoffe ich das die Option irgendwann dazukommen wird oder jeder hier auch die Kommentare liest  
    • Das ist natürlich richtig, aber ich bin nicht der geduldigste Mensch und Arch kannte ich halt auch schon  Dazu kommt dann noch das der Core m5-Y71 nicht gerade ein Kraftpaket ist. Aber ich merkt mir mal Gentoo für ganz viel Langeweile oder potentere Hardware vor.
    • @_n4p_: Auch eine Gentoo Stage1 Installation ist gar nicht sooo kompliziert. Man braucht halt vor allem entsprechend viel Zeit, um alles selber zu kompilieren, anstatt es viel schneller nur zu installieren. Dafür läuft das System (wenn man alles richtig macht) aber auch schneller und stabiler als so ziemlich jedes andere System.
    • Das Arch Wiki ist echt großartig. Das kann man gar nicht oft genug sagen Für Gentoo und LFS war die Motivation einfach nicht groß genug. Arch bildet einen schönen Mittelweg aus den Extremen - Ubuntu, Mint auf der einen und LFS auf der anderen Seite. Irgendwo hab ich mal gelesen Arch sei auf die richtige Art kompliziert, zumindest zum Lernen. Will man einfach ein Linux um produktiv zu arbeiten, ist Arch vermutlich nicht der richtige Anfang. Das Abenteuer geht auch noch weiter
    • Schönes Abenteuer...verleitet mich ja fast dazu auch mal wieder was zu installieren und mit Linux rumzuspielen. Arch habe ich damals mit 16 oder 17 das erste Mal installiert. Da war die Wiki glaube ich noch nicht soooo gut wie heute und musste oft in Foren nachfragen oder Yt Vids gucken. Danach (einige Jahre später) wars dann eher Manjaro oder Antergos. Gentoo würde in meiner Liste noch fehlen (und LFS)
  • Blogstatistik

    • Blogs insgesamt
      1
    • Einträge insgesamt
      37

Fachinformatiker.de, 2019 SE Internet Services

fidelogo_small.png

if_icon-6-mail-envelope-closed_314900.pnSchicken Sie uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App


Get it on Google Play

Kontakt

Hier werben?
Oder senden Sie eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung