Reprise du message précédent :

Cherche pas, c'est la détection de locale qui envoie l'appli dans les choux, mes fixes globalize ne sont pas encore passé en prod...

Comme vous le savez, la dernière version stable de Ruby pour Debian Etch est 1.8.5, or il y a des problèmes entre celles-ci et Ruby on Rails. Je souhaitais donc installer Ruby en le compilant à la main.
 
Je l'ai déjà fait plusieurs fois sur ma machine de dév, c'est facile. Je souhaite faire la même chose sur mon serveur, mais ce que j'aimerai savoir, c'est comment faire comprendre à mon serveur Debian, que Ruby va se trouver dans /usr/loca/ruby-1.8.6?
 
Sur ma machine de dév, je crée simplement dans mon fichier ~/.bach_profile:

Et comme j'utilise Rails à partir du terminal, tout marche car $PATH est défini correctement à chaque lancement du terminal et que je lance mongrel à la main.  
 
Ce que je ne sais pas faire, c'est comment définir ce même path, mais sans avoir à ouvrir un terminal sur le serveur? Ce que je veux c'est que si jamais le serveur doit être rebooté, je n'ai pas à lancer Rails à la main. Dois-je créer/éditer un script (par exemple /etc/init.d/mongrel) où j'y définis la variable $PATH et comment lancer le serveur Mongrel?

cf réponse sur OSA

Et un autre problème, par contre celui-ci est spécifique à Rails:
 
J'ai ma bdd Mysql qui est sur un autre serveur, et Rails refuse de s'y connecter. En utilisant mysql-client à distance tout marche parfaitement, j'ai créé une bdd et un utilisateur qui a tous les droits dessus. Voici le message d'erreur quand je fais "rake db:migrate":

 
Quelqu'un a déjà eu ce problème?

T'es sûr de l'adresse de ton serveur ?

Bordel je suis fatigué! C'est tout à fait ça. je me suis trompé entre 2 et 3... Merci mille fois multani, j'aurais jamais trouvé tout seul. Allé au lit et à demain.

Ca y est j'ai lancé mon site, le serveur est à 99% prêt, j'ai encore quelques bricoles à rajouter.
 
A peine lancé, le spam commence déjà.
 
Ca sert à quelque chose de bloquer dans iptables les host comme grapx.pl qui semble pourrir mon site?
 
EDIT: je pense que ça sert à rien ,les IP sont presque tout le temps différente, et de toute façon ils doivent les spoofer.

 
tu peux pas mettre un captcha ?

Le spam n'atterit pas dans ma bdd, c'est juste que je vois des tentatives.
 
Et au lieu d'un captcha, j'ai mis un negative captcha, on verra bien si ça marche dans la durée.

Vous utilisez capistrano? Perso ça m'a toujours éclaté à la figure à un moment ou à un autre.

Quasi obligatoire pour déployer sur une archi multi-serveurs.
Pour l'instant tout va bien.
Mais bon, faut rester calme sur les callbacks, y'a moyen de se chopper une migraine.
Un bon wiki avec toutes les commandes atomiques utiles expliquées, c'est le top pour bosser en équipe.
Ca vaut mieux que l'usine à gaz qui fait le thé et le café et balance du sucre partout.

Perso j'ai écris mon propre script de déploiement inspiré de capistrano. C'est pas du tout adaptable (a contrario de cap), mais ça fait exactement son boulot, et à chaque update j'ai plus du tout d'appréhension que lorsque je commencais à écrire mes propres tasks avec cap.

Je comprends; si j'avais dû tout faire moi-même j'aurai sans doute été du même avis. Comme c'est un archi qui a mis en place la chose, ça va.

J'ai un serveur qui tourne non stop depuis quelques mois déjà, le petit souci c'est que récemment sa mémoire vive est arrivée à saturation. Vous avez des idées d'où ça peut venir? Mongrel est connu pour memory leaker?
 
J'utilise Thin comme serveur qui est basé sur Mongrel.

Les PDF de peepcode, oui, non, Obiwan ?

Spa mal
Bien traduit en plus, le truc sur rails 2.0

Effectivement, j'avais pas vu qu'il y avait aussi une version française. J'avoue que je suis sceptique là dessus.

Faut pas

Peepcode y'a du utile et du pas utile du tout quand tu sais où trouver l'info. Globalement y'a pas mal de vent.  
 
Leur pdf Rails 2.0 / 2.1 je ne vois pas vraiment ce qu'on y trouve de plus que sur le blog de son auteur Ryan Daigle. J'ai le pdf sur 2.0 et à part 60 pages de développées, le reste c'est presque un copié-collé du changelog de rails avec quelques explications de temps en temps...
 
J'ai aussi regardé la vidéo benchmarking avec httperf, bon ben il passe 20 minutes à expliquer ce qu'est l'écart type. Ensuite Il explique également que désactiver les sessions permet d'améliorer les perfs du site. Trop bien! Et si on ne ne peux se passer des sessions, on améliore les perfs comment? Ha ben il n'en parle pas.
 
Sinon la vidéo sur REST m'avait bien aidé à comprendre pourquoi c'est si génial, parce que la plupart des explications trouvée sur le Net sont complètement à côté de la plaque, comme ceux qui expliquent le POST vs GET avec des histoires d'encodage d'URL de je sais pas quoi qui embrouillent plus qu'autre chose.
 
La vidéo capistrano m'a bien aidé à utiliser capistrano jusqu'à ce que je me rende compte que capistrano c'est pas cool en fait.
 
Perso je préfère m'abonner à des RSS, sinon y'a RailsEnvy que j'aime bien, d'ailleurs ils ont sortis leur service concurrent à Peepcode, dans la foulée de PragProg d'ailleurs
 
T'as railscasts qui est très bien également. Dès qu'il s'agit de creuser le problème il s'arrête juste à temps avant de se planter, mais pour découvrir des nouveaux trucs et creuser par soi-même c'est parfait.
 
Rubyplus.org, au contraire t'oublie immédiatement. Son code est complètement buggé et mal codé.
 
EDIT: j'aime pas du tout la voix de geoffrey, et comme pas mal de monde je mate ses vidéos à vitesse x2 sinon je m'endors.

 
OK
 

 
Je lurkais plus du côté des PDF, j'aime bien avoir une référence imprimée plus qu'une chiée de bookmarks. Mais je note.

Tu peux t'étendre là dessus?

Bah plusieurs fois la mise à jour de mon site a pété. Je voulais mettre le site à jour et capistrano m'envoyait balader avec des messages d'erreur comme quoi ça ne marchait pas, j'arrivais pas à récupérer le truc.  Et cette idée de créer des liens symboliques à tout va ça m'énervait.
 
Alors j'ai créé mon propre script en bash qui fonctionne à merveille avec un repo Mercurial sur le serveur. Mon script ne m'a jamais sauté à la figure (le site non plus) et il fait tout ce que Capistrano peut faire sans se prendre la tête avec des tasks à écrire qui étaient (sont?) en plus mal documentées. C'est pas du OOP à se branler le kiki mais j'en ai rien à faire, ça fait son boulot ultra efficacement en seulement quelques lignes de code.

Oui mais si y'a une gestion de rôles avec plusieurs frontaux/DB/serveur asset, faut y aller à la main en SSH pour lancer les rake sur chaque machine?

Au fait, quelqu'un utilise God? http://god.rubyforge.org/
 
Ca marche bien? ou alors je me code mon propre script avec une entrée cron pour l'activer?

Tu peux executer une ou plusieurs commandes via ssh sans ouvrir de session à la mano. Combiné avec un échange de clé rsa ça marche très bien.
 
Mon script de deploy fonctionne plus ou moins comme ça (quoi qu'il est relativement simple, apache stop -> hg archive -> petit script intermédiaire -> apache start)

En configurant l'option ControlMaster coté client, ça marche aussi sans clés (ça permet de multiplexer les connexions).

@seabee: capistrano traduit bêtement les lignes de code ruby que tu lui donnes, en commandes à envoyer au serveur par ssh. D'ailleurs quand tu fais cap:deploy, tu vois les commandes qu'il envoie à l'écran. Sauf que cap c'est lourd, alors que directement hardcoder tes lignes de commandes dans un script bash c'est tout con.

Ah ok  
Donc cap ça sert à rien  
Sinon God nous bientôt

 
Chacun son opinion  
On a jamais eu de probleme avec, et c'est hyper facile de s'écrire des taches perso et les intégrer au scenario de déploiement, sans compter le multistage bien pratique
 
Faudrait ptet faire un bug report au lieu de dire "ca foire"

T'utilises quoi comme SCM avec?

subversion, ma chef veut pas passer à mercurial /o\

Tout s'explique alors. En fait capistrano vient en quelque sorte rajouter des fonctionnalités à SVN. Parce que quand tu utilises Mercurial tu te rends comptes qu'il fait tout ce que SVN+Cap peut faire, out-of-the-box et sans se prendre la tête avec des task développés avec SVN en tête qui peuvent tout péter avec un autre SCM. Donc ça sert à rien de faire remonter un bug à cap, quand c'est l'outil lui-même qui est dépassé.

Je connais pas encore vraiment mercurial mais qu'est-ce qu'il apporterait de plus à part une bonne gestion des branches ?

C'est pas que Mercurial gère mieux les branches, ça reste à l'humain de le faire, mais à partir du moment où quelqu'un fait un "check out" (un clone en langage mercurial), il cré son propre repo local, et du coup il cré une branche. Comme tout est pensé à la base, derrière ça diminue les chances d'explosions, même s'il faut quand même faire gaffe lors d'un merge.
 
Capistrano c'est génial quand on utilise un outil préhistorique comme SVN. Une fois que tu passes à Hg ou Git, tu te rends compte que Cap ça sert plus vraiment à rien.
 
Sinon pour ceux qui sont passés à Rails 2.1, ça s'est bien passé l'ajout de nouvelles migrations?    ça surprend un peu  

C'est un DVCS, donc
 

• Beaucoup moins de contraintes sur le workflow, il n'y a pas de repo "central" donc il est possible d'utiliser des conventions pour faire des choses beaucoup plus flexibles. Les arbres de repositories du noyau linux sont un bon exemple.
• C'est extrèmement rapide globalement, parce qu'il y a très peu d'opérations qui demandent de taper sur le serveur (commit, update, log, annotate, bisect, diff y compris entre deux versions super vieilles de l'arbre, ... c'est tout fait en local, il y a juste push/pull et incoming/outgoing qui vont taper sur le serveur), donc des opérations qui vont prendre 4 ou 5 secondes sous Subversion (et plus si le réseau est saturé ou autre) et vont "couper" le workflow vont être quasiment immédiate.
• C'est super agréable pour faire des merges (mais ça c'est surtout parce que SVN est infoutu de tracker les révisions mergées), et accessoirement ça conserve l'historique des deux branches mergées sous forme d'un arbre, ce que subversion est incapable de faire
• Quand tu veux faire un test sans flinguer ton répertoire de travail, ça prend 2s de créer une branche ou un clone local sur lequel tu pourras faire tes tests (par contre faut que ton environnement de dev ne rende pas ça trop merdique), une fois que t'as fini ton test tu peux pusher les modifs dans ton répertoire de travail principal ou bien juste supprimer ta branche/ton clone, ça fait comme un scratchpad, et ça pootre
• Ca permet de faciliter l'échange entre les gens directement: imaginons que je bosse sur un truc. À un moment j'ai un problème que j'arrive pas à résoudre, j'ai donc besoin de l'aide d'un collègue qui connaît mieux le projet que moi, donc je vais le chercher. Avec SVN soit il bosse sur mon ordi mais risque de ne pas avoir les outils auquel il est habitué (d'autant plus que je suis e.g. sous windows alors que c'est un barbu linuxien disons), soit je commit mes modifs incompilables et je pète le trunk. Pas pratique. Avec mercurial, je fais "hg serve", ça démarre un mini serveur HTTP sur ma machine duquel il peut puller, comme ça il a mes modifs (cassées) dans son environnement à lui sans avoir à passer par le tronc, donc sans le pêter. C'est très utilisé dans le dev du kernel linux (avec git mais c'est le même principe): certains sous-systèmes ont besoin de collaborer mais ne veulent pas publier officiellement leurs modifs (parce que devs en court et super instables), donc ils se créent des repos semi-privés pour partager leurs devs l'un avec l'autre sans que le reste du développement soit impacté ou même remarque ces échanges.
• Comme "commit" est une opération locale, ça permet de faire des masses de tout petit commits sans crainte de pêter un truc chez quelqu'un d'autre (l'opération de sauvegarder des modifications et celle de publier le tout sur un repo distant sont séparées en "commit" et "push" ).

Je sais ce qu'est un dvcs je m'en suis juste jamais servi (à part en lecture seule pour suivre un projet libre)
Je me demande surtout en quoi un dvcs tout seul remplace un outil de déploiement comme capistrano

Et donc, pourquoi ?

edit: je pense que si tu dis cela c'est surtout pour l'histoire du dossier releases/ qui pourrait correspondre a des commits dans une branche de production, mais il reste quand même les tâches à côté de la mise à jour du code lui même : redemarrage des mongrels, migration de la db, etc...

Hg c'est construit comme ça:
 
Mercurial s'est un stupide script python qui parse les fichiers. Tu as ton répertoire de travail où tu bidouilles tes fichiers. Le repo, lui est un stupide répertoire caché dans ton répertoire de travail. Déjà pour copier le repo sur une clé usb ou autre, c'est ultra simple et rien ne pète.
 
Côté serveur, je crée un repo en clonant le mien qui est sur ma machine de dev. Terminé côté serveur.
 
Côté dév, je bosse sur mon repo local avec mes micros commit comme l'a expliqué Masklinn. Quand je veux faire une vraie mise à jour du code côté serveur, mon script bash fait en gros (j'ai globalement pompé sur capistrano):

hg push: j'envoie mon code au repo du serveur.
 
hg update: le répertoire de travail côté serveur est mis à jour, c'est ce répertoire que mongrel "voit" et je redémarre mongrel pour qu'il recharge la nouvelle version du code.
 
Et basta. Le nouveau code est opérationnel, ça prend en tout moins de 10s.  
 
Je déconne pas, le coeur de mon script tiens réellement en 1 ligne alors que toi tu vas te prendre les couilles avec des tâches débiles cap. Il me semble qu'avec cap, par défaut le "delta copy" n'est pas activé (là je suis mort de rire), alors qu'avec Mercurial c'est gratuit. Bien évidemment je me suis créé un mini menu en bash si je veux faire des tâches spécifiques côté serveur.
 
La connerie de capistrano c'est qu'il ne tire pas du tout profit du SCM, c'est vraiment se faire chier pour rien, alors que tous est là sous tes yeux, alors pourquoi rajouter une équation au système?
 

Regarde comment capistrano fonctionne, va dans le code source: il se fait chier avec des introspections à la Rails pour comprendre ce que tu as écris en Ruby et le transformer en commande à envoyer par ssh au serveur. Ca sert à rien! Tu veux migrer la DB? ok, ben ajoute bêtement && rake db:migrate au script bash, et on n'en parle plus.
 
L'OOP c'est bien, mais faut pas en abuser pour un truc aussi simple: un script bash à l'ancienne ici ça défonce tout. Les transactions de cap ça sert seulement à rattraper le coup quand capistrano explose. Dans mon cas j'ai mis à jour des centaines de fois mon serveur avec mon script bidon, j'ai jamais eu besoin de transaction.

ok je comprends ton point de vue
 
Mais on pourrait faire pareil avec une branche "production" avec svn

Sauf que tu te retrouves à merger en permanence ton trunk dans ta prod, et que tu dois tracker manuellement à quel endroit du turnk la branche de prod est actuellement. C'est vite lassant.

 
Comment tu gères ta config et la migration?
 
J'ai a peu près le même truc (dans django):
 

TASKS = [   
              copy_setting(env),
                    ('Stopping Apache...', '%s/apache2/bin/stop' % home_path),
                    ('Updating local repository...' , 'cd %s/website && hg up' % home_path),
                    ('Running syncdb', '%s/website/manage.py syncdb' % home_path),
                    ('Running sqldiff', 'cd %s/website/ && ./manage.py sqldiff -sa | ./updatedb' % home_path),
                    ('Restarting Apache...', '%s/apache2/bin/start' % home_path),
            ]

 
copy_setting c'est une fonction qui copie le bon fichier de settings à la raçine du projet (y'a trois environnement, dev, test, et prod donc trois fichiers de settings différents)
syncdb met à jour la base de donnée pour matcher les models et fait toutes les opérations de "maintenance" par rapport à celle ci.