Beiträge getagged ‘Git’

Rails Deployment leicht gemacht

4 August 2010

Wer kennt das nicht, da hat man schnell eine super Rails Anwendung lokal erstellt und möchte das Resultat mit anderen Teilen, ohne großen Aufwand treiben zu müssen. Sprich die Anwendung muss ins Web gestellt werden. Wer da nicht einen Server sein Eigen nennen kann, ist darauf angewiesen einen Hoster zu finden, der auch Rails Anwendungen unterstützt. Und auch dann ist trotz Capistrano und Co. immer noch ein recht hoher initialier Aufwand nötig, eh das Ergebnis perfekt läuft.

Das es auch wesentlich einfacher und komfortabler geht, zeigt uns Heroku. Auf die Seite bin ich vor ein paar Tagen aufmerksam geworden, als ich nach Rails Hostern Ausschau gehalten habe. Nachdem ich die Seiten gelesen habe, die beschreiben wie Heroku funktioniert war ich begeistert und musste den Dienst selber ausprobieren.

Heroku verspricht, dass das Deployment der eigenen Rails Anwendung so einfach ist, wie ein git push. Und ich kann euch sagen: Es ist so einfach!

Wie funktioniert das ganze nun? Einfach :)
Eh es losgehen kann muss ein kostenloser Heroku-Account her. Danach kann auch gleich das passende Gem installiert werden.

sudo gem install heroku

Als nächstes benötigen wir logischerweise unsere Rails-Anwendung, die mit Git versioniert wird.

rails meinesuperapp
cd meinesuperapp
git init
git add .
git commit -m "Meine SuperApp gestartet"

Damit die Anwendung nun auf die Heroku Server gelangt, muss ein Remote-Repository im Git eingerichtet werden. Dafür haben wir weiter oben das Heroku Gem installiert.

heroku create

Danach kann der aktuelle Stand per

git push heroku master

auf die Heroku-Server übertragen werden. Die sind dann so schlau und erkennen, dass es ich bei der Übertragung um eine Rails-Anwendung handelt und veranlassen alles Nötige, um die Anwendung im Internet bereit zu stellen. Jede weitere Änderung im Git Repository, die online gestellt werden soll, wird einfach per git push an den Heroku Server übertragen. Dieser tauscht dann den alten Stand der Anwendung mit dem neuen aus. Perfekt. Das ist Rails Deployment einfach gemacht.

Nun kommen wir aber zu den interessanten Fragen: Was kostet mich das? Nun; in der geringsten Ausprägung nichts, niende, nada. Wer nun mehr für seine Rails-Anwendung haben möchte, muss bezahlen und bekommt dafür ein dynamisch wachsendes System gestellt. Dynamisch wachsend heißt hier: Die Anwendung skaliert je nach Bedarf auf mehreren so genannten Dynos, was im Heroku-Jargon eine Verarbeitungseinheit darstellt. Je mehr davon aktuell laufen, je mehr gleichzeitige Zugriffe kann die Anwendung verarbeiten. Und das beste daran: Man bezahlt nur das, was auch verbraucht wird. Sprich wenn die Anwendung tagelang nur so vor sich hindümpelt und auf den großen Ansturm wartet, läuft sie auf nur einem oder wenigen Dynos. Gibt es dann ein Besucheransturm, schaltet das Heroku-System dynamisch weitere Dynos innerhalb von wenigen Sekunden dazu und verteilt so die Last. Schwindet der Besucherstrom, fährt Heroku die Dynos auf ein Minimum herunter.

Abgerechnet wird am Ende die Laufzeit der Dynos sekundengenau. Ein perfektes System. Anstatt einen riesigen Server mit enorm viel Power und zu horrenden monatlichen Kosten anzumieten, wird die Cloud bemüht. Und man zahlt nur für das, was auch wirklich verbraucht wurde.

Wer mir nun solch einen Provider in deutschen Landen nennen kann, dem bin ich zu ewigem Dank verpflichtet.

Aktuellen GIT Zweig dauerhaft in der Konsole anzeigen

23 Juli 2010

Bei meiner Arbeit mit der Versionsverwaltung GIT bewege ich mich meistens auf der Konsole. Weiterhin organisiere ich meine Quellen innerhalb von einem GIT-Repository gerne in verschiedenen Zweigen. So existieren neben dem master meistens noch weitere Zweige. Das Wechseln zwischen diesen ist mit GIT schnell erledigt. Leider verliere ich so oft den Überblick, in welchem Zweig ich mich denn nun aktuell befinde. Dafür gibt es Abhilfe.

Mit GIT wird auch die Bash-Completion installiert. Diese stellt unter anderem mit __git_ps1 eine Funktion bereit, die mir den aktuellen GIT-Zweig ausgibt. Wie der Name der Funktion schon vermuten lässt, kann der Aufruf in der Deklaration von PS1 in der .bashrc hinterlegt werden. Also hab ich meine .bashrc wie folgt angepasst:

PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]$(__git_ps1 "(%s)") \$ '

Mit dem nächsten Öffnen der Bash wird mir in jedem GIT-Verzeichnis der aktuelle Zweig ausgegeben. Das ganze sieht dann so aus:

GIT Zweig in der Bash

Ich finde die Ausgabe schon sehr nützlich. Wie habt ihr eure PS1 eingestellt? Gibt es Alternativen, die mir vielleicht mehr Informationen kompakt darstellen können?

[Linux] Single Sign On mittels SSH

15 Juli 2010

Nun dürfte es sich ja bereits herumgesprochen haben, dass auf entfernte Rechner per SSH zugegriffen wird. Sei es um die Rechner zu administrieren oder auf ein dort befindliches Git-, Subversion- oder was auch immer für ein Repository zugegriffen wird. Aus Sicherheitsgründen kommt zur Authentifizierung ein SSH-Schlüsselpaar zum Einsatz wobei der öffentliche Schlüssel auf jeden SSH-Server kopiert wird, der erreicht werden soll.

Soweit das Setup. Wenn nun auf den entfernten Rechner zugegriffen wird, erfolgt die Authentifizierung nicht durch das Übertragen eines Passwortes an den Server sondern per SSH-Schlüssel. Dieser kann und sollte auch beim Erzeugen mit einem Passwort gesichert werden. Beim Verwenden des SSH-Schlüssels wird nun lokal dieses Passwort abgefragt.

Wer nicht bei jedem Kontakt zum Server, was bei der Verwendung von GIT durchaus viele sein können, nicht jedesmal das Passwort eintippen möchte, greift zu ssh-add. Das schaltet nach Eingabe des korrekten Passwortes den SSH-Schlüssel frei und fügt ihm den SSH-Agenten zu. Dieser wird bei jedem SSH-Befehl nach dem freigeschalteten Schlüssel abgefragt.

Das ist schon recht komfortabel. Dank Pluggable Authentication Modules kann aber bereits beim Login am lokalen Rechner der SSH-Schlüssel freigeschalten und an den SSH-Agenten übergeben werden. Per

sudo aptitude install libpam-ssh

wird PAM-SSH installiert. Die Debian- und damit auch die Ubuntu-Pakete richten die Authentifizierung so ein, dass normal gegen das Unix-Passwort authentifiziert wird. Danach gelangt das Passwort an PAM-SSH, welches den SSH-Schlüssel frei schaltet. Vorausgesetzt natürlich beide Passwörter sind gleich.

Perfekt! Leider hat diese Konstellation einen Haken. Ist das Heimatverzeichnis per ecryptfs verschlüsselt, hat PAM keine Chance auf den sicheren SSH-Schlüssel, der im Normalfall in ~./ssh/ gespeichert wird, zuzugreifen. Das Problem ist bekannt und einen entsprechenden Bugreport gibt es auch.

Git Cheat Sheet für den schnellen Überblick

10 März 2010

Wer kennt das nicht? Da beschäftigt man sich mit einer neuen Versionsverwaltung und hat einige Begriffe und Befehle neu zu erlernen. Da hilft meistens die Lektüre von einschlägigen Howtos, Readmees und Man-Pages. Doch hat man die ersten Hürden genommen, folgt die tägliche oder nicht so alltägliche Arbeit mit dem System. Und genau dann braucht man eine schnell verfügbare Übersicht über das System.

» Weiterlesen: Git Cheat Sheet für den schnellen Überblick

Mein Einstieg in Git

4 August 2009

Wie ich ja bereits angedroht habe, werde ich mir Git etwas näher ansehen. Natürlich benötige ich als erstes eine einfache Möglichkeit, Git Repositories auf meinem Server ablegen zu können. Nach einer etwas längeren Suche und einigen Tests mit ssh+git und git-daemon bin ich auf gitosis gestoßen. Die Sammlung von Pythonskripten erlaubt das einfache Anlegen und Verwalten von Git Repositories. Besonderes Schmankerl ist die Authorisierung der Benutzer über deren öffentlichen SSH-Schlüsel. Das geht zwar auch mit git-Bordmitteln, aber Dank gitosis benötigt nicht jeder Git-Anwender einen eigenen Account auf dem Server.

Wie wird das ganze nun aufgesetzt? Ganz einfach dieser sehr guten gitosis-Anleitung folgen. Nach nicht einmal 15 Minuten hatte ich mein erstes Railsprojekt im eigenen Git-Repository lokal und auf dem Server.

Die Administration von gitosis ist nach dessen einmaliger Initialisierung auf dem Server komplett per eigenem Git-Repository möglich. Sprich das gitosis-admin Repsoitory clonen, lokal die Konfiguration anpassen, committen, pushen und fertig. Fast so einfach wie die Programmierung mit Rails ;)

Auf zum Feldtest von Git…

Wird es Zeit, sich Git anzusehen?

8 Juli 2009

In den letzten Wochen und Monaten habe ich immer mehr Berührung mit dem Verwaltungssystem Git bekommen. Sei es durch eine Vielzahl an Plugins für Ruby on Rails, die auf github gehostet werden, oder die seit einigen Wochen öffentlich zugänglichen Qt Quellen auf Gitorious. Und heute kam die Meldung, dass auch KDE von Subversion auf Git wechseln möchte.

Wird es also Zeit für mich einmal einen näheren Blick auf Git zu werfen? Dabei stellen sich mir die Fragen, wie ich einen Server installiere, über welches Protokoll greif ich auf ihn zu. Wie handhabe ich Zweige, Commits, Merges und wie sehe ich mir das Log an? Alles Fragen, die ich mir in Zukunft sicher einmal beantworten werden. Wenn es soweit ist, könnt ihr an dieser Stelle die Antworten darauf lesen. :)

Dezentralisiertes Subversion Repository

21 September 2008

Da ich nächste Woche für einige Tage ohne Netzwerk auskomme habe ich nach einer Möglichkeit gesucht, trotz allem in meine Subversion Repositories auf meinem Server zu committen. Es fehlt also die Möglichkeit ein Subversion Repository dezentral verwalten zu können, ähnlich Git. Git ist ursprünglich von Linus Torvalds entwickelt worden um BitKeeper als Quelltextverwaltung für den Linux-Kernel zu ersetzen. Das neue System zeichnet sich durch ein dezentralisiertes Quelltextmanagement aus. Jeder Entwickler hat eine lokale Kopie des Repositorys bzw. eines Zweiges aus dem Repository. Sämtliche Änderungen am Repository werden erst in die lokale Kopie eingespielt und später bei Bedarf und einer bestehenden Netzwerkverbindung mit einem Repository auf einem zentralen Server abgeglichen.

Diese Funktionalität vermisse ich derzeit noch bei Subversion. Aber dafür gibt es git-svn. Das Programm stellt eine Brücke zwischen dem lokal verwendeten Git und einem zentralen Subversion-Repository dar. Git-svn muss natürlich erst einmal auf dem Rechner installiert werden.

apt-get install git-svn

Danach lege ich mir ein leeres Verzeichnis für meinen lokalen Git-Klon an und besorge mir das Git-Repository aus meinem Subversion-Repository.

mkdir ~/src/meinprojekt/git/
cd ~/src/meinprojekt/git/
git-svn clone http://www.anrichter.net/svn/meinprojekt/trunk

Damit steht mir eine lokale Kopie meiner Quellen bereit. Dort kann ich weiter entwickeln und ganz ohne Netzwerkverbindung meine Änderungen in das Git-Repository einspielen.

git commit -a

Wenn ich später wieder Netzwerkverbindung habe, kann ich das Git-Repository von meinem Rechner mit dem Subversion-Repository auf meinem Server abgleichen. Dazu besorge ich mir erst alle Änderungen, die seit dem letzten Abgleich im Subversion-Repository erfolgt sind.

git-svn rebase

Danach kann ich meine eigenen Änderungen aus dem Git-Repository in das Subversion-Repository auf dem Server einspielen.

git-svn dcommit

Leider funktioniert das Vorgehen nicht mit externen Verweisen in einem Subversion Repository. Kann Git das Subversion-Property svn:external abbilden? Wenn ja wie? Oder geht das noch einfacher?

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Deutschland
This work by Andreas Richter is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Deutschland.