Tag Archive for 'capistrano'

cap deploy “permission denied” nach upgrade auf capistrano 2.1

Hier habe ich endlich gefunden wieso aus heiterem Himmel bei einem cap deploy mit ssh und svn (und public key authentication) immer folgender Fehler auftrat:

** [err] Permission denied, please try again.
** [err] Permission denied, please try again.
** [err] Permission denied (publickey,password).
** [err] svn: Netzwerkverbindung wurde unerwartet geschlossen

In die /config/deploy.rb muss folgende Option mit aufgenommen werden:

default_run_options[:pty] = true

Wenn ihr wissen wollt wieso, müsst ihr im original Beitrag nachschauen. Es hat mit den Rechten bei der shell zu tun und jetzt werden auch die user profile auf dem server vorher geladen.

Capistrano 2 hinter den Vorhang gucken

Auf Railstrac habe ich diese wunderbare Datei gefunden, die mir endlich verrät, was genau hinter den cap tasks steckt:
http://dev.rubyonrails.org/browser/tools/capistrano/lib/capistrano/recipes/deploy.rb

“Capistrano überschreibt meine Dateien immer!”

Wer seit Neuestem mit Capistrano seine rails app deployed, der kam vielleicht auch schon dahinter, dass dann alle Dateien weg sind, die man in ein bestimmtes Verzeichnis geschrieben oder hochgeladen hat.

“meinprojekt” ist im Folgenden das Verzeichnis auf dem Server, wohin deployed wurde. Standardmäßig ist das glaube ich /u/apps/meinprojekt.

Also zum Beispiel meinprojekt/public/uploads wird nach dem deploy einfach gelöscht und alle Dateien sind weg (nicht wirklich weg, man muss nur im Verzeichnis meinprojekt/releases danach suchen ;).

Um das zu verhindern (hier gefunden) muss man im meinprojekt/shared Verzeichnis auf dem Server wo man es deployed hat die Verzeichnisse erstellen, die solche wichtigen Sachen enthalten.

Also z. B. mkdir meinprojekt/shared/public/uploads. Anschließend passt man seine deploy.rb wie folgt an:

task :after_update_code, :roles => :app do
run “ln -nfs #{deploy_to}/shared/public/uploads #{release_path}/public/uploads”
end

Dadurch wird nachdem der Code deployed (also hochgeladen) wurde, ein Hardlink von dem deployten uploads-Verzeichnis auf /u/apps/meinprojekt/shared/public/uploads gemacht. Also sozusagen ein weiterverweisen auf das shared Verzeichnis.

Immer wenn jetzt jemand was hochläd, wird es in shared gespeichert, anstatt in current. Beim nächsten Deploy wird der Link wieder auf shared gesetzt und keine Daten gehen verloren.

Hier mal ein Beispiel für meine Gallery:

namespace :deploy do
[task :start...]
after “deploy:update_code”, :link_to_shared
end

# Create hard links to data in shared
desc “Link in critical data”
task :link_to_shared do
run “ln -nfs #{deploy_to}/shared/config/database.yml #{release_path}/config/database.yml”
run “ln -nfs #{deploy_to}/shared/backup #{release_path}/backup”
run “ln -nfs #{deploy_to}/shared/private #{release_path}/private”
run “ln -nfs #{deploy_to}/shared/public/images/gallery #{release_path}/public/images/gallery”
run “ln -nfs #{deploy_to}/shared/public/images/pending #{release_path}/public/images/pending”
end

Super. Danke Capistrano 2, dass du das kannst :)

HowTo: MySQL 5, Mongrel, Capistrano + Subversion

Update: Bis her war ein Fehler in diesem HowTo. MySQL muss natürlich als Server Version installiert werden ($ sudo port install mysql5 +server). Das Update betrifft nur den MySQL5 Bereich.

Damit wir Ruby on Rails auch wirklich nutzen können, sollten wir noch ein paar Programme, Tools und Gems installieren.

Als erstes wäre da MySQL, denn wie wollen wir Datenbankgestütze Webentwicklung betreiben, wenn wir nicht mal einen Datenbank-Server und damit eine Datenbank haben…

MySQL5
Da wir ja MacPorts installiert haben ist das ganze recht einfach. Um auf Nummer Sicher zu gehen, machen wir jedoch erst mal ein selfupdate für MacPorts und installieren erst dann MySQL5

$ sudo port selfupdate
$ sudo port install mysql5 +server
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist
$ sudo chown -R mysql:mysql /usr/local/macports/var/db/mysql5
$ sudo -u mysql mysql_install_db5

Jetzt am besten den Mac neu starten, dann kann man gleich sehen ob das LauchItem funktioniert.

MySQL Native Bindings Gem
Jetzt kommt der Teil, der mich die meiste Zeit gekostet hat (dabei sollte er doch die Geschwindigkeit der MySQL Abfragen beschleunigen) und der Grund war, warum ich bis her ohne die Nativen Bindings auskommen musste.
Das MySQL Gem ist irgendwie sehr unflexible, was die Pfade angeht und dazu kommt, dass MacPorts die MySQL Installation im MacPorts Verzeichnis nicht gebündelt ablegt sondern etwas zerfledert… anstelle eines einfachen gem install mysql war hier etwas mehr Finetuning nötig. Mittels der build-flags gelang mir dann aber auch das. Hier das Ergebnis:

sudo gem install mysql -- \
--with-mysql-dir=/usr/local/macports/lib/mysql5 \
--with-mysql-lib=/usr/local/macports/lib/mysql5/mysql \
--with-mysql-include=/usr/local/macports/include/mysql5/mysql

NACHTRAG, ab November 2008 so:

sudo env ARCHFLAGS="-arch ppc" gem install mysql -- --with-mysql-lib=/opt/local/lib/mysql5/mysql --with-mysql-include=/opt/local/include/mysql5/mysql

jetzt wird man gefragt, welche Version man für die Installation wählen will. Nehmen wir also die neuste, zum jetzigen Zeitpunkt mysql 2.7 (ruby), also drücken wir die 3 (da wir uns ja auf einem Mac befinden fallen die mswin32 Versionen für uns raus)

Select which gem to install for your platform (i686-darwin8.10.3)
1. mysql 2.7.3 (mswin32)
2. mysql 2.7.1 (mswin32)
3. mysql 2.7 (ruby)
4. mysql 2.6 (ruby)
5. Skip this gem
6. Cancel installation

Wenn man die build-flags nicht richtig setzt bekommt man solche Fehler:

ERROR: Failed to build gem native extension.
ruby extconf.rb install mysql
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... no
checking for mysql_query() in -lmysqlclient... no

und kann damit nicht so wirklich was anfangen… wie gesagt hat mich einiges an Zeit gekostet, weil auch Google dazu nicht richtig was sagt.

So nun sind auch die Bindings fertig und wir können uns anderen Dingen zuwenden.

Mongrel
Mongrel ist der Webserver. Rails liefert zwar schon einen Webserver mit (Webrick) aber Mongrel hat für mich bis her einen sehr sehr großen Vorteil, man sieht im Development Mode alle Requests. Damit fällt das Debugging viel leichter, da man sogar die MySQL Requests mit allen Werten sieht. Also installieren wir das Mongrel Gem einfach.

sudo gem install mongrel --include-dependencies

es kommen wieder die von oben bekannten Abfragen zur Version und weil es Abhängigkeiten gibt, die erfüllt werden müssen, wird gleich noch fastthread installiert. Meine Versionen sind mongrel 1.0.1 (2 drücken) und fastthread 1.0 (1 drücken).

Select which gem to install for your platform (i686-darwin8.10.3)
1. mongrel 1.0.1 (mswin32)
2. mongrel 1.0.1 (ruby)
3. mongrel 1.0 (mswin32)
4. mongrel 1.0 (ruby)
5. Skip this gem
6. Cancel installation
> 2
Select which gem to install for your platform (i686-darwin8.10.3)
1. fastthread 1.0 (ruby)
2. fastthread 1.0 (mswin32)
3. fastthread 0.6.4.1 (mswin32)
4. fastthread 0.6.4.1 (ruby)
5. Skip this gem
6. Cancel installation
> 1

Gut damit haben wir neben dem MySQL-Server nun auch unseren Webserver. Was jetzt kommt ist erst mal nicht so wichtig aber wir installieren es mal, damit wir uns später keine Gedanken mehr drum machen müssen.

Capistrano
Capistrano ist ein Deployment Tool, was einem die Arbeit des live gehens erheblich erleichtern soll. Ich hab es noch nicht benutzt und genau deshalb installiere ich es jetzt mit um es in den nächsten Tagen zu testen. Darüber wird es dann auch einen Post geben.
Neben dem hoch laden der Dateien mittels SSH, kann man noch eigene Rake Tasks in Ruby schreiben, die dann z.B. einen Dump der alten Datenbank erstellen, bevor die neue eingespielt wird. Naja wie gesagt, bei mehr Erfahrungen gibt es auch dazu einen Post, jetzt erst mal die Installation:

sudo gem install capistrano --include-dependencies

Jetzt noch Termios, dass dafür sorgen soll, dass die Passwörter, die man in Capistrano eintippt, nicht von allen gelesen werden können. Ich weiß nicht, ob das notwendig ist aber weh tun tut es ja auch nicht also:

sudo gem install termios --include-dependencies

Subversion
Subversion ist auch so nen Ding, worüber alle reden, was ich aber bis zum jetzigen Zeitpunkt, außer für Plugin Installationen, nicht genutzt habe. Capistrano nutzt es auch, also installieren wir auch noch dieses Tool. Eigentlich ist es einfach eine Versionskontrolle und wird meistens eingesetzt, wenn man in einem Team programmiert (es zeigt einem Konflikte an, d.h. zwei Leute haben zur gleichen Zeit an einer Datei, den selben Teil verändert, jeder natürlich anders und die Änderungen würden verlohren gehen. Hier springt dann eben SVN ein und man kann den Konflikt auflösen.)

sudo port install subversion

So damit haben wir eigentlich erst mal alles, was wir für die Entwicklung mit Ruby on Rails brauchen. Wenn es noch irgendwelche Sachen gibt, die man unbedingt braucht ab in die Kommentare damit.