Déplacer une application Rails d’un serveur à un autre

Ayant recyclé une machine plus puissante comme serveur interne, je me suis trouvé face à la tâche fastidieuse de déplacer mes applications Rails d’un serveur à l’autre. Je détaille ici à titre d’aide-mémoire les opérations à effectuer, les problèmes rencontrés et les solutions apportées.

Recopier les fichiers de l’application

Pour recopier les fichiers de l’application, deux possibilités : modifier votre fichier de déploiement si vous utilisez capistrano, c’est la méthode la plus pérenne; en mode « quick and dirty », je passe par rsync pour synchroniser les répertoires.

Pour cette deuxième méthode, connectez vous à votre serveur source, et tapez la commande suivante :

rsync -a /source/path/to/myapp/ user@mytargetserver.org:/target/path/to/myapp/

Vous devrez bien sûr donner le mot de passe de user sur mytargetserver.org.

Migrer la base de données

Nous allons tout d’abord exporter les données depuis le serveur mysql source. Connectez-vous à votre serveur source en ssh et exportez la base de données avec la commande suivante :

mysqldump -u user -pmypassword myapp_production > myapp_production.sql

Recopiez la base de données sur votre machine cible, en utilisant par exemple la commande scp :

scp myapp_production.sql user@mytargetserver.com:

Connectez-vous à votre machine cible, lancez mysql et tapez la commande suivante pour créer votre base de données :

create database redmine_production;

Donnez les droits à votre utilisateur mysql sur votre base de données ; pour ce faire, lancez mysql avec votre utilisateur root et votre mot de passe, puis tapez la commande suivante :

grant all on myapp_production.* to 'myrailsuser'@'localhost';

Quittez mysql et importez ensuite votre base de données en tapant la commande   suivante :

mysql -u user -pmypassword myapp_production < my app_production.sql

Problèmes rencontrés

Fatal error lors du bundle install

Mon application n’était plus installée au même endroit que précédemment, et bundler avait gardé en configuration le chemin ou se trouvait le bundle sur la précédente machine. J’ai eu droit à un joli message du genre :

Unfortunately, a fatal error has occurred. Please see the Bundler troubleshooting documentation at http://bit.ly/bundler-issues. Thanks!

Avec comme information supplémentaire qu’il n’arrivait pas à créer une arborescence de répertoires dans /var/www

Pour trouver l’endroit du stockage, il suffit de taper :

bundle config path

Editez le fichier qui contient la configuration locale avec votre éditeur préféré et faites le pointer sur le répertoire bundle de votre application.

Impossible de trouver un gem lors de bundle install

Si lors de l’installation des gems avec bundle vous obtenez la sortie suivante :

Fetching gem metadata from http://rubygems.org/..
Could not find gem-xxx in any of the sources

Ou gem-xxx peut être n’importe lequel de vos gens, il vous suffit de procéder comme suit :

  1. Supprimer le fichier Gemfile.lock
  2. Modifier le fichier de configuration locale de bundler (chemin visible avec bundle config) pour passer le paramètre freeze à 0 au lieu de 1.
  3. Relancer la commande bundle install
  4. Modifier le fichier de configuration de bundler pour remettre freeze à 1.

Se connecter avec une clé SSH à un serveur distant

Je cherchais à me connecter à un serveur distant sans avoir besoin de me connecter avec un mot de passe. J’avais fait la manipulation il y a  quelque mois, mais bien entendu je n’avais rien noté à l’époque. Voici donc en quelques lignes la méthode que j’ai adoptée.

Qu’est-ce qu’une clé ssh ?

Naïvement, je pensais qu’une clé ssh était associée à un utilisateur donné sur la machine cliente (celle à partir de laquelle on cherche à se connecter). En fait une clé ssh est un certificat avec une partie publique (que vous installerez sur la machine sur laquelle vous souhaitez vous connecter) et une partie privée que vous garderez précieusement sur votre machine cliente.

Si j’ai bien compris, lorsque vous vous connectez en ssh à une machine distante, le client ssh regarde tous les certificats dont vous disposez, et vérifie si la partie publique de ce certificat est connue par la machine distante pour l’utilisateur avec lequel vous vous connectez.

Ainsi, si en tapant la commande suivante :

ssh user@myserver.org

Le client ssh va vérifier si un des certificats ssh dont vous disposez sur votre machine pour votre utilisateur est disponible pour l’utilisateur user sur la machine distante. Si ce n’est pas le cas, il vous proposera l’authentification par mot de passe.

Bien entendu, ces comportements dépendent également de la configuration du serveur ssh sur la machine distante (/etc/ssh/sshd_config sur Ubuntu).

Créer la clé ssh

Note : vous remplacez bien sûr dans les exemples suivants user et myserver.org par le nom de l’utilisateur distant et de la machine distante.

Pour créer une clé SSH, nous allons utiliser la commande ssh-gen. Ouvrez votre terminal et tapez les commandes suivantes :

cd ~/.ssh
ssh-keygen -t rsa
Créer un certificat ssh

Créer un certificat ssh

Le programme ssh-keygen va vous demander le nom du fichier (que vous pouvez nommer comme vous le souhaitez, par exemple user_rsa), ainsi qu’un mot de passe que vous prendrez soin de rendre suffisamment fort. ssh-keygen crée deux fichiers : le fichier user_rsa, clé privée à conserver précieusement, et le fichier user_rsa.pub, clé publique que nous allons déployer sur la machine distante.

Avant de déployer le certificat, ajoutons cette nouvelle clé en ajoutant dans le fichier ~/.ssh/config les lignes suivantes :

Host myserver
 Hostname myserver.org
 User myuser
 PreferredAuthentications publickey
 IdentityFile /Users/MyUser/.ssh/myuser_rsa

Une fois cette modification effectuée, vous pouvez vous connecter en tapant :

ssh myserver

Déployer le certificat sur la machine distante

Pour déployer votre certificat, vous devez l’ajouter au fichier authorized_keys du répertoire .ssh de l’utilisateur de la machine distante avec lequel vous souhaitez vous connecter ; vous procéderez comme suit :

scp ~/.ssh/user_rsa.pub remote_user@myserver.org:

N’oubliez pas les deux points derrière le nom de la machine distante. Connectez-vous ensuite avec l’utilisateur de la machine distante auquel vous souhaitez associer le certificat :

ssh user@myserver.org

Optionnel : si le répertoire .ssh n’existes pas sur le répertoire home de l’utilisateur, il faut le créer :

mkdir ~/.ssh

Nous allons ajouter la clé publique au fichier authorized_keys avec la commande cat, puis supprimer le fichier pub qui ne nous sert à rien, et restreindre la modification et la lecture du fichier authorized_keys au seul utilisateur courant :

cat ~/user_rsa.pub >> ~/.ssh/authorized_keys
rm ~/user_rsa.pub
chmod 600 ~/.ssh/authorized_keys

Déconnectez vous de la machine distante (exit), puis tapez :

ssh user@myserver.org

Le client ssh vous demandera peut-être le mot de passe associé au certificat et tapé lors de sa création. Si tout se passe bien, vous devriez être ensuite connecté à la machine distante !

Si ça ne se passe pas comme prévu

Un truc à connaître est l’option -v  de la commande ssh, qui permet d’avoir l’affichage à l’écran de l’ensemble des opérations de connexion à la machine distante.

via ArchiWiki

Utiliser les services Public Cloud d’OVH sur Mac

En plein dans la lecture de Deploying Rails, un bouquin instructif sur l’automatisation du déploiement de l’infrastructure pour sites Rails, je me suis inscrit au Cloud Public d’OVH pour mettre en pratique l’enseignement du livre. Ce dernier ayant pour sujet le scriptage des actions de mise en ligne d’une application, la présence d’APIs dans la solution d’OVH me paraissait être un argument important en faveur de ce produit.

OVH propose même un script permettant de réaliser les appels à l’API directement à partir de la ligne de commande. Sous Ubuntu, pas de problème, tout se passe bien. Mais sous Mac OSX, pas si simple, et les tentatives de téléchargement automatique des différents modules perl nécessaires se sont soldés par des échecs.

En googlant, je suis heureusement tombé sur deux articles qui m’ont tiré d’affaire. Pour installer CPAN qui va vous permettre d’installer d’autres modules, il vous faut procéder de la manière suivante :

  • Installer XCode (https://developer.apple.com/xcode/) – vous devrez vous enregistrer mais le téléchargement est gratuit pour Mountain Lion.
  • Lancer XCode et ouvrir les Preferences.
  • Cliquer sur l’onglet Downloads
  • Cliquer pour installer les Command Line Tools

En ouvrant un Terminal, tapez les commandes suivantes :

$ sudo perl -MCPAN -e shell
perl> o conf init

Vous pouvez ensuite mettre CPAN à jour en tapant la commande suivante :

sudo perl -MCPAN -e 'install Bundle::CPAN'

Avant de pouvoir lancer le script ovhcloud, il vous faut le modifier légèrement, en ajoutant la ligne suivante sous l’instruction use strict; située ligne 14 :

$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME}=0;

Vous pouvez maintenant bénéficier du script ovhcloud sur Mac OSX !

via Noemi Millman, PilgrimX182

Ma première rencontre avec Macintosh

La nouvelle nous a tous pris de court ce matin, Steve Jobs nous a quitté. Il y a peu d’entrepreneurs qui auront suscité ce sentiment d’intimité avec ce qu’il faut bien appeler ses fans ; car plus qu’un visionnaire / inventeur / génie marketing, Steve Jobs était la seule rock star de la Silicon Valley.

Un mélange de Brian Wilson pour l’obsession du détail, de John Lennon pour la vision, de Mick Jagger pour l’aptitude à faire le show…

En apprenant sa mort, je me suis remémoré ma première rencontre avec Macintosh. C’était à l’Ecole Technique Supérieure des Municipalités, à Addis Abeba, Ethiopie, où je faisais mon service civil. Après avoir tapé mon mémoire de fin d’études sur un PC avec Word, en utilisant toutes les ressources du clavier et mon imprimante Epson pour faire varier la typographie, je me retrouvais dans un environnement full Mac, du Mac 512k à disquettes jusqu’au Mac Plus avec 1 Mo de mémoire et un disque dur ! A moi les polices de caractères avec Adobe Type Manager, l’affichage tel qu’imprimé, le finder et la souris !

En rentrant en France, j’ai continué à travailler sur Mac : Mac II ci tout d’abord, puis PowerMac 6100. Et même si j’ai depuis abandonné (contraint et forcé !) la marque à la pomme pour mon activité professionnelle, Apple s’est invité dans ma vie digitale avec l’iPod et l’iPad.

Merci Steve.

Les médias sociaux, nouvelle boule de cristal ?

Je suis tombé sur un article du site BGR, qui présente une « étude » extrapolant le futur succès de Windows 8 pour tablettes des flux des différents réseaux sociaux.

20110927-214741.jpg

Il semblerait donc que l’iPad et les tablettes Android soient déjà dépassées par Windows 8 pour tablettes. La « vox sociali » a parlé, l’oracle a livré son verdict, Google et Apple peuvent d’ores et déjà abandonner la partie !

On avait déjà les sondages, qui prédisaient le destin des marques et des hommes politiques, nous avons maintenant « l’analyse » (avec quels outils ?) de la grande caisse de résonance du web ; l’analyse du commentaire sur le buzz fait lui même le buzz. On nage en pleine pataphysique !

Je suis sûr que Tim Cook et Larry Page pleurent dans leurs bureaux respectifs :) J’espère surtout que Steve Ballmer va continuer à améliorer Windows 8 pour que son rêve du « one size fits all », un seul OS pour tous les supports ne finisse pas en eau de boudin…

PS : en consacrant un article à cette news, je participe au buzz ! La boucle est bouclée, pas moyen d’en réchapper !!