GST033 - (Code)ship all the things! from Geekstammtisch

Geekstammtisch

Dirk Breuer, Sebastian Cohnen

Episodes

About

Reviews

Promote

GST033 - (Code)ship all the things!

1 hour 25 minutes Posted Jun 16, 2014 at 3:23 pm.

Unser Gast

Usability ist wichtig

Tour durch Codeship.io

Infrastruktur

Build-Artefakte

Private Installations

Server in der EU und Datenschutz?

Produktentwicklung & Fokus behalten

Blogposts und Screencast

Hosting bei Heroku

Pricing bei Codeship

AWS

Immutable Servers

Automatisierung

Wie kommen auf die Jobs auf die Build-Server

Provisionierung der LXC-Container

0:00

1:25:23

Download MP3

Share at current time

Show notes

Remote-Episode mit Flo von Codeship.io über Serverautomatisierung und UX

Unser Gast (00:00:00)

Florian Motlik

CTO und Co-Founder von https://codeship.io

Codeship ist ein Continuous Integration/Deployment Service

Ist 2011 als Neben-dem-Studium-Projekt gestartet

2012 dann die Entscheidung das ganze Vollzeit zu verfolgen: Studium hinschmeißen und alle ziehen nach Berlin

Nach Berlin dann 2013 nach Boston

Hauptsitz in Boston und ein Büro Wien

Wachsen erstmal "nur" vor Ort in Boston/Wien, Remote erst später; Ziel: gesunder Wachstum

Usability ist wichtig (00:05:45)

Usability war von Anfang im Fokus

Geführter Einstieg in das Produkt und Features

Noch vor der Anmeldung eines Nutzers sollen Screencasts und Blogposts Interessenten in die Thematik einführen

Bei Anmeldung weiß man dann schon im Grunde worum es geht und kann schneller starten

Tour durch Codeship.io (00:10:46)

Erster Schritt: Anmeldung über GitHub (https://github.com/) oder Bitbucket (https://bitbucket.org/)

Anschließend die Wahl des Repositories

Einrichtung der Test-Befehle, dazu gibt Templates für die unterschiedlichsten Sprachen und Umgebungen

Solange der Exit-Status eines Befehls 0 ist wird der nächste Schritt ausgeführt

Nach dem Testing kommt das Deployment

Auch hier lässt sich aus fertigen Anbindungen wählen, oder ein eigenes Skript wird verwendet

Das Deployment ist dabei eher als Pipeline zu verstehen:

Deploye erst auf Staging

Lasse dann gegen Staging einige Tests laufen

Deploye dann auf Produktion

Prüfe auch hier mit einem Skript

Am Ende des Tages kann Ablauf beliebig komplex oder sehr einfach sein, was immer gebraucht wird

Genauso wird im übrigen auch Codeship selbst getestet und deployed

"Eat your own dog food" ist vor allem für Developer-Produkte extrem wichtig

Infrastruktur (00:14:10)

Website läuft auf Heroku (https://www.heroku.com/home)

Sidekiq (http://sidekiq.org/) als Worker Queue mit externem Redis (https://openredis.com/)

Die interessanten Dinge passieren bei AWS (https://aws.amazon.com/): Die Ausführung der Jobs

Zu AWS ist man von Hetzner über Rackspace gekommen. Die Erklärung warum haben wir dann später leider vergessen zu erwähnen :/

AWS-Setup

Eigenes Auto-Scaling: Mehr Builds -> mehr Server

Die größten Compute-Instanzen (c3.8xlarge) als Basis, Unterteilung mit LXC (https://linuxcontainers.org/)

Ein Container mit einem vollständigen Ubuntu inkl. aller möglichen Abhängigkeiten

Learning 1: Container eignen sich besser als dedizierte kleine Maschinen, weil mehr Speicher und CPU

Learning 2: Einfach alles hochfahren treibt den Speicherverbrauch hoch, macht aber das Handling sehr viel leichter

Jeder Push auf das Repo erzeugt eine neue virtuelle Maschine auf der man im Grunde tun und lassen kann was man will

Es gibt aus Sicherheitsgründen kein sudo

Es lässt sich alles nach installieren was ohne sudo geht

Es sind die gängigen Sprachen in unzähligen Versionen enthalten + Haskell

Das gleiche gilt für Datenbanken

Support ist sehr wichtig

Ein Dienst für Developer fordert Developer als Support, daher muss jeder Entwickler auch einen Tag Support machen und zwar 7 Tage die Woche

Es gibt einen Cache-Layer (wo zum Beispiel auch Rubygems gecached werden) in den sich eigene Erzeugnisse ebenfalls cachen lassen

Build-Artefakte (00:20:50)

Keine Integration in Codeship: Build-Artefakte müssen per Skript woanders hinkopiert werden

Hintergrund: Nach jedem Build wird der Container vollständig zerstört

Deployment muss kein "Deployment" auf einen Server sein, sondern kann auch ein Script sein, welches z.B. Artefakte auf S3 kopiert

von Codeship vordefinierte Deployments sind vorgefertigte Abläufe, machen aber sonst nichts spezielles

im Wesentlichen gibt es keine Unterscheidung zwischen Setup, Test und Deploymentphasen: Es werden lediglich Kommandos ausgeführt

Im Environment werden alle möglichen Informationen exportiert

Ein spezieller Schutz für "geheime" Informationen (wie Access Keys) können aktuell noch nicht verschlüsselt in die Build-Umgebung gereicht werden

Private Installations (00:28:10)

Konkrete Pläne gibt es für On-Premise Installationen gibt es aktuell nicht

Codeship will sich nicht in Unternehmen rein verkaufen, sondern die Teams sollen Codeship haben wollen

Server in der EU und Datenschutz? (00:31:30)

Aktuell benutzt Codeship AWS EC2 Instanzen in us-east

Instanzen in der EU werden irgendwann wichtig sein (Datenschutzgesetz und auch Ausfallsicherheit)

Aber: Die Kunden haben aktuell ihren Code ohnehin auf Github oder Bitbucket, und deren Code liegt dann ohnehin nicht in der EU

Produktentwicklung & Fokus behalten (00:33:45)

Wie behält man den Fokus bei der Entwicklung?

Der Fokus war bei Codeship notwendig, weil Flo der einzige Entwickler war

Tech-only Start-Ups "bauen sich gerne in den Markt", was nicht funktioniert

Blogposts und Screencast (00:37:30)

20% der Entwicklerzeit geht in Marketing: z.B. Blogposts und Screencasts

Der Aufwand für einen Blogpost: 4-8 Stunden, wenn man nicht zu viel Research machen muss

...und bei Screencasts: Aufnahme 2-3 Stunden, Schneiden noch mal 1-1,5 Tage

Auch in den 20%: Meetups organisieren, Konferenzbesuche, User Groups...

Flo's Pro Tip: Sticker!!!

Hosting bei Heroku (00:42:40)

Codeship selber läuft auf Heroku mit 8 Add-Ons

Postgres: https://addons.heroku.com/heroku-postgresql#premium-ika

Logentries: https://addons.heroku.com/logentries

New Relic: https://addons.heroku.com/newrelic

New Relic Alternative: Skylight: https://www.skylight.io/

Pricing bei Codeship (00:49:15)

Codeship Preise: https://codeship.io/pricing

Kostenfrei (keine: 50 Builds, ein Concurrent Build

49 USD: ein Concurrent Build, sonst keine Limits

je 50 USD mehr, +1 Concurrent Build

AWS (00:51:50)

EC2 Reserved Instances: https://aws.amazon.com/ec2/purchasing-options/reserved-instances/

AWS Trusted Advisor: https://aws.amazon.com/premiumsupport/trustedadvisor/

Immutable Servers (00:54:40)

Server sind immutable

Server werden gebaut mit Packer (http://www.packer.io/)

Aus einer JSON Konfiguration und Skripten zur Provisionierung wird eine Amazon Machine Image (AMI) erstellt

Worklfow bei Codeship.io:

Code-Änderungen auf GitHub

Automatische Tests

Erstellung des AMI (Laufzeit ~ 90 Minuten)

Austausch eines AMI

Alte Server werden ausgemacht wenn keine Jobs mehr laufen

Scaling-System fährt nur noch neue Maschinen hoch

Wichtig: Laufende Server werden nicht mehr angefasst!

Vorteil:

Alle Server sind immer gleich

Server sind getestet bevor ein AMI überhaupt gebaut wird

Ziel bei der Automatisierung: Fokus der Entwickler auf die Entwicklung, alles nach dem Push muss automatisch geschehen

Automatisierung (01:00:56)

Weiteres wichtiges Tool ist Librato (https://metrics.librato.com/) zur Erfassung und Auswertung von sämtlichen Daten

Neben Betriebsdaten von Heroku und Amazon laufen dort auch Businessdaten rein

Alerts auf unterschiedlichen Ebenen

Wenn was ist, dann wird man benachrichtigt

Über Health-Checks werden sogar die Build-Server automatisch deaktiviert und neue Instanzen hochgefahren

Wenn alles automatisiert ist, dann können sich die Entwickler stärker auf ihre Arbeit konzentrieren

Keine dedizierte Ops-Abteilung, sondern gute Sys-Admins, die in die Entwicklungsabteilung und deren Prozesse integriert sind (aka: DevOps)

Am Ende haben alle Beteiligten (Frontend, Backend, Ops) den gleichen Workflow

Wie kommen auf die Jobs auf die Build-Server (01:05:00)

Auf jedem Build-Server läuft ein Sidekiq-Job

Die Web-App schiebt neue Jobs in die Queue

Die Build-Server schieben Ergebnisse zur Anzeige auf der Webseite auch wieder in eine Queue

Sidekiq-Pro kommt zum Einsatz

Provisionierung der LXC-Container (01:08:12)

Provisionierung via Bash

Aktuelles Projekt: Migration auf Ansible (http://www.ansible.com/home)

Ansible erscheint für die Anforderungen als die sinnvollste Lösung

Trotz LXC ist Docker (http://www.docker.com/) aktuell keine Alternative

Früher oder später werden sie auf Docker umstellen, da es sich als das Tooling für LXC entwickelt

Aktuell würde es aber mehr Arbeit machen als Benefit bringen

UX (01:12:59)

Die Komplexität liegt bei Codeship.io in der Feinabstimmung aller beteiligten Komponenten

Technisch ist es kein Hexenwerk

Wie bereits mehrfach angesprochen: UI/UX war und ist eine der großen Herausforderungen

Daher: Dedizierte Menschen, die sich um dieses Thema kümmern

Interviews mit Kunden

User-Tracking spielt auch eine wichtige Rolle

Kommunikation mit den Usern über Intercom (https://www.intercom.io/)

grundsätzlicher Support

Auf Basis von Metriken Identifikation von möglichen Problemen bei Kunden

In der UI werden unterschiedliche Fehler unterschieden: Bundle Install, Tests nicht gelaufen, etc

Matching der Fehlermeldung auf Reguläre Ausdrücke

Nicht nur die Fehlermeldung sondern entsprechender Hinweis auf die Fehlerursache

Next-Steps: Unterschiedliche Benachrichtigungen für unterschiedliche Fehlertypen

← See all 42 episodes of Geekstammtisch