Retour au sommaire du support de cours

Les hébergeurs supportant Ruby sont encore assez peu courants, mais il en existe quand même un certain nombre.

(Dernière modification : 2011/05/10)

Cliquez sur la table des matières pour la cacher / développer :

1) La Rolls : Heroku

1.1) Création d'un compte heroku

Aller sur le site de l'hébergeur : 
http://api.heroku.com/signup

La configuration des applications (une fois créées), se fait avec l'interface Web de paramétrage des applications : 
http://heroku.com/myapps

1.2) Installation

L'utilitaire de gestion à distance de heroku est un Gem standard : 
gem install heroku

1.3) Ajout d'un nouveau projet

  • Création à la racine du projet :
    • heroku create <nom_du_projet>

#Spécifier une autre pile :
heroku create <nom_du_projet> --stack bamboo-ree-1.8.7

#Migration vers une autre pile :
heroku stack:migrate bamboo-ree-1.8.7
#The migration will be completed after you git push and a new slug is successfully compiled

    La configuration des applications se fait aussi avec l'interface Web de paramétrage des applications : 
    http://heroku.com/myapps

  • Utilisation de git :
    • Ajout d'un raccourci :
      • git remote add <nom_alias> git@heroku.com:<nom_du_projet>.git
    • Puis à chaque modification de fichier source :
      • git push <nom_alias>
    • Correction problème de clé ssh en faisant un git push :
      • Message d'erreur : Permission denied (publickey)

      Solution :
      1. Suppression ancienne clé :
        2. heroku keys:remove <keyname>

      2. Ajout nouvelle clé :
        3. heroku keys:add ~/.ssh/id_rsa.pub

#ou
heroku keys:add
#demandera email

      3. Vérification :
        4. heroku keys

  • Transfert des données de la B.D.D. vers et depuis les Serveurs heroku :
    • Installation : 
    gem install tap
apt-get install libsqlite3-dev

    Utilisation : 
    #Depuis heroku
heroku db:pull mysql://root:mypass@localhost/mydb

#Vers heroku
heroku db:push

    Se sert de :
    • ActiveRecord pour le schema
    • SQL pour les données

    Attention : pas de caractère '_' dans le nom du serveur de BDD

  • Utiliser une B.D.D. externe :
    • Les gems permettant de gérer la B.D.D. doivent bien sur être installés. 
    heroku config:add DATABASE_URL=mysql://username:password@host/databasename

1.4) Paramétrage et debogage

Débogage, affichage du contenu d'un fichier de configuration : 
heroku console

puts File.read(Rails.configuration.database_configuration_file)

État des serveurs, historique des incidents : 
http://status.heroku.com/

1.5) Ajout de fonctionnalités :

1.5.1) Rack adapters :

Ces adapteurs permettent de mettre en place des services spécifiques très simplement : 
Camping
Coset
Halcyon
Mack
Maveric
Merb
Racktools::SimpleApplication
Ramaze
Ruby on Rails
Rum
Sinatra
Sin
Vintage
Waves
Wee
exemple : 
http://blog.jerodsanto.net/2009/05/3-reasons-why-heroku-is-a-game-changer/

1.5.2) Inclusion de gems :

Pour Liste des gems déjà installés dans une pile : 
http://installed-gems.heroku.com
1.5.2.1) Inclusion avec un fichier Gems manifest (ancienne méthode) :
  • C.f. :
    • http://docs.heroku.com/gems
  • Méthode :
    • Créer un fichier .gems à la racine du projet, et le remplir avec une liste de gems à installer.
    Attention : Ne pas y mettre de commentaire en commençant une ligne par '#'

    Ex : 
    hpricot --version '>= 0.2' --source code.whytheluckystiff.net
dm-core --version 0.9.10
formtastic --ignore-dependencies
  • Génération automatique du fichier Manifest :
    • Création du fichier Manifest (.gems),
    à partir des déclarations config.gems, dans le fichier de configuration environment.rb.
    Heureusement, Mark DODWELL a produit une petite tâche rake pour cela.
    Cette version a été améliorée par Tammer SALEH, pour vérifier avec l'Url : 
    http://installed-gems.heroku.com
    et n'écrire que les gems qui ne sont pas déjà installés dans la pile.
    Insérez le code suivant dans : lib/tasks/heroku_gems.rake : 
    namespace :gems do
  desc "Génère le fichier Manifest .gems pour Heroku"
  task :heroku_spec =>> :environment do
    require 'open-uri'
    installed_gems = []
    url = "http://installed-gems.heroku.com/"
    open(url).read.scan(/<li>(\w+) [^<]*<\/li>/) do |w| 
      installed_gems << w.first
    end

    gems = Rails.configuration.gems

    # output .gems
    dot_gems = File.join(RAILS_ROOT, ".gems")
    File.open(dot_gems, "w") do |f|
      output = []
      gems.each do |gem|
        next if installed_gems.include?(gem.name)
        spec = "#{gem.name} --version '#{gem.version_requirements.to_s}'"
        spec << " --source #{gem.source}" if gem.source
        output << spec
      end
      f.write output.join("\n")
      puts output.join("\n")
    end
  end
end
  • Un gem existe pour cette tâche :
    • http://github.com/glennr/heroku_san
1.5.2.2) Bundler :
A FAIRE

1.6) Déploiement d'environnements multiples pour une même application

Creating multiple deployment environments is an important strategy for successful web apps.
This is a familiar pattern for Rails developers who are accustomed to having development, testing, and production environments.
Typically the development and testing environments live on a developer's local machine and the production environment lives on Heroku. However, a successful pattern that we've seen (and use ourselves) is to have two or three application copies running on Heroku;
typically production, staging, and (optionally) QA.
This allows app testing on the live Heroku platform and provides a convenient way to share new designs with colleagues and clients before pushing them to production. Creating a multi-app setup like this is easy. Let's say you want to deploy an app called "katana" to Heroku.
First create the production, staging, and QA versions of the app,
but use the --remote option to override the defaults for the git repository names: 
heroku create katana-production --remote production
heroku create katana-staging --remote staging
heroku create katana-qa --remote qa

Now, when you want to deploy code to a particular environment, do so by specifying the appropriate remote: 

git push staging master

And if you need to run migrations:

heroku rake db:migrate --remote staging

Finally, you will probably want to periodically copy your production data into your staging environment: 

heroku db:pull --remote production
heroku db:push --remote staging
Keep in mind that any environment variables you create or add-ons you add must be duplicated across environments for a consistent experience.
For example, if you begin using memcache on your staging app, be sure to install it on your production app before you deploy your new code.

1.7) Structure et coût des serveurs :

dyno
	1/4 de coeur de CPU
	un seule requête traitée en même temps
	10 à 100 requêtes / seconde
	438€ / an par dyno en plus

slugs
	The maximum slug size is 100MB.
	Most apps should be far below this size.
	Anything under 10MB is good.
	If you exceed 50MB, you should think about trying to lean down your app.

1.8) Sytème de fichiers readonly :

- sass 
script/plugin install git://github.com/heroku/sass_on_heroku.git

- MogileFS

 

2) Autres hébergeurs :

2.1) Webfaction :

Achat de plusieurs comptes : une appli peut être répartie sur plusieurs comptes. Description : 
http://www.webfaction.com/services/hosting
Question : capacité processeur des serveurs ?

2.2) A2hosting :

2.3) SliceHost :

Plan  		RAM  	Storage  	BW  	Monthly Cost
256 slice  	256MB  	10GB  		150GB  	$20/mois
http://www.slicehost.com/

2.4) Linode :

http://www.linode.com/index.cfm

2.5) Engine Yard :

2.6) Rails Machine :

2.7) Rimu Hosting :

http://rimuhosting.com/order/startorder1.jsp?hom=t-vps
Base Monthly PriceMemory OptionsData Transfer AllowanceDisk Space OptionsIPs
29.95 USD400MB40GB-150GB4GB-8GB2

2.8) Autres :

Dreamhost : 9$ / mois
Railsplayground : 5$ / mois