Ruby: Usages avancés

Aller plus loin avec vos déploiements Ruby

👋 Bienvenue sur la documentation de Stackhero !

Stackhero propose une solution Ruby cloud prête à l'emploi qui offre de nombreux avantages, notamment :

  • Déployez votre application en quelques secondes avec un simple git push.
  • Utilisez votre propre nom de domaine et profitez de la configuration automatique des certificats HTTPS pour une sécurité renforcée.
  • Bénéficiez de la sauvegarde automatique, des mises à jour en un clic et d'une tarification simple, transparente et prévisible.
  • Profitez d'une performance optimale et d'une sécurité renforcée grâce à une VM privée et dédiée.

Gagnez du temps et simplifiez-vous la vie : il suffit de 5 minutes pour essayer la solution Ruby cloud hosting de Stackhero !

Déployer une branche autre que main

Jusqu'à présent, nous avons déployé notre application Ruby en poussant la branche main avec :

git push stackhero main

Si vous souhaitez déployer une autre branche, utilisez cette commande. Remplacez <BRANCH> par le nom de la branche à déployer :

git push stackhero <BRANCH>:main

Par exemple, pour déployer une branche nommée production, exécutez :

git push stackhero production:main

Déployer des tags au lieu de branches

Dans certains cas, vous pouvez vouloir déployer un tag plutôt qu'une branche. Pour cela, exécutez la commande suivante. Remplacez <TAG> par le tag à déployer :

git push stackhero '<TAG>^{}:main'

Par exemple, pour déployer le tag v1.0.0, exécutez :

git push stackhero 'v1.0.0^{}:main'

La syntaxe ^{} permet de référencer le commit pointé par le tag.

Déployer un commit spécifique

En plus des branches ou des tags, vous pouvez déployer un commit précis. Remplacez <COMMIT_HASH> dans la commande ci-dessous par le hash du commit souhaité :

git push -f stackhero <COMMIT_HASH>:main

Par exemple, pour déployer un commit avec le hash abcde, exécutez :

git push -f stackhero abcde:main

Revenir à une version précédente

Si votre déploiement en production ne fonctionne pas comme prévu, vous pouvez revenir en arrière en déployant un commit antérieur. Commencez par afficher l'historique de vos commits avec la commande suivante :

git log

Cette commande affiche la date, le hash et la description de chaque commit dans votre dépôt. Par exemple, vous pourriez obtenir un résultat comme :

commit cccc8b3ebdccb9abc1926ef49ee589dae5c5fe06 (HEAD -> main, stackhero/main)
Author: Developer
Date:   Fri Apr 28 09:36:18 +0000

    Break the code

commit bbbb622301772072c3d82f3cc0d91e29e6e84901
Author: Developer
Date:   Wed Apr 26 12:49:28 +0000

    Update the code

commit aaaa1d8b06535b413e0df8298ccf52339dfef3ff
Author: Developer
Date:   Wed Apr 26 12:44:50 +0000

    Improve the code

Si le commit avec le message "Break the code" (hash cccc...) est actuellement en production et que vous souhaitez revenir au commit précédent "Update the code" (hash bbbb...), exécutez :

git push -f stackhero bbbb622301772072c3d82f3cc0d91e29e6e84901:main

Pour éviter de déployer du code défectueux et renforcer la stabilité de votre production, il est fortement recommandé de mettre en place un environnement de "staging".

Placé entre les environnements de "développement" et l'environnement de "production", l'environnement de "staging" offre une réplique quasi identique de la production. Cela vous permet de tester votre code et de garantir sa qualité avant de le déployer en production.

En utilisant un environnement de staging, vous pouvez valider le bon fonctionnement et les performances de votre code, assurant ainsi des déploiements en production plus fiables et robustes.

Ce type d'environnement sera abordé plus loin dans la documentation.

Mise en place d'un environnement de staging

Un environnement staging est une bonne pratique à utiliser en complément de vos environnements development et production. Il reproduit votre environnement de production afin de tester les mises à jour et modifications avant leur mise en ligne.

Un environnement de staging doit être aussi proche que possible de la production.

Cependant, veillez à ce que l'environnement de staging utilise un clone de la base de données de production, et non la base de données de production elle-même.

Si votre service Ruby est lié à une base de données ou à d'autres services, recréez-les dans la nouvelle stack <Project> - Staging.

Pour créer un environnement de staging sur Stackhero, suivez ces étapes :

  1. Sur le tableau de bord Stackhero, renommez votre stack existante de <Project> en <Project> - Production. Par exemple, si votre projet s'appelle Chat Bot, renommez la stack en Chat Bot - Production.
  2. Créez une nouvelle stack nommée <Project> - Staging. Dans l'exemple précédent, cela donne Chat Bot - Staging.
  3. Lancez un service Ruby dans la stack de staging.
  4. Récupérez la valeur de la commande git remote et suivez les instructions de la section Déployer sur l'environnement de staging.

En suivant ces étapes, vous disposerez d'un environnement de staging correctement configuré pour tester et valider vos mises à jour avant leur passage en production.

Déployer sur l'environnement de staging

Gérer des environnements séparés comme staging et production est fortement recommandé. Comme expliqué dans la section Mise en place d'un environnement de staging, vous pouvez déployer sur chaque environnement via des remotes Git différents.

Commencez par renommer le remote actuel. Par exemple, renommez le remote "stackhero" en "stackhero-production" avec cette commande :

git remote rename stackhero stackhero-production

Ensuite, créez un nouveau service Ruby pour l'environnement de staging. Utilisez la commande "git remote add" fournie et modifiez-la comme suit (remplacez <XXXXXX> par le domaine de votre service) :

  • Commande d'origine :

    git remote add stackhero ssh://stackhero@<XXXXXX>.stackhero-network.com:222/project.git

  • Commande modifiée :

    git remote add stackhero-staging ssh://stackhero@<XXXXXX>.stackhero-network.com:222/project.git

Vous pouvez maintenant déployer sur la staging avec :

git push stackhero-staging main

Ou déployer sur la production avec :

git push stackhero-production main

Pour simplifier encore le processus de déploiement, pensez à utiliser la version améliorée du Makefile.

Avec ce Makefile amélioré, le déploiement en production ou en staging se fait facilement avec make deploy-production ou make deploy-staging.

Version améliorée du Makefile

Voici un Makefile amélioré qui propose plusieurs règles pour les tâches courantes :

  • make dev (ou simplement make) : Démarre l'application en mode développement.
  • make deploy : Déploie l'application sur le remote nommé stackhero (idéal si vous n'avez qu'une seule instance Stackhero).
  • make deploy-production : Déploie l'application sur le remote nommé stackhero-production.
  • make deploy-staging : Déploie l'application sur le remote nommé stackhero-staging.

Ce Makefile est conçu pour gérer les cas où le code a déjà été déployé, évitant ainsi l'erreur "Everything up-to-date".

Copiez-collez le contenu suivant dans votre nouveau Makefile :

# Règle exécutée par défaut lors de l'appel à "make" sans argument
.DEFAULT_GOAL := dev


# Stackhero for Ruby exécutera la règle "run" sur votre instance.
# C'est la commande à lancer sur les plateformes production et staging.
run:
  rake assets:precompile
  rake db:migrate RAILS_ENV=production
  RAILS_ENV=production bundle exec puma -C config/puma.rb


# Commande à lancer en environnement de développement
dev:
  RAILS_ENV=development rails server -b 0.0.0.0


# La règle "deploy" déploie sur l'instance "stackhero".
# Adaptée si vous n'avez qu'une seule instance.
deploy:
  @$(MAKE) -s deploy-script DEPLOY_REMOTE=stackhero DEPLOY_BRANCH=main


# La règle "deploy-*" déploie sur l'instance "stackhero-*".
# Par exemple, lancez "make deploy-production" pour déployer sur "stackhero-production",
# ou "make deploy-staging" pour déployer sur "stackhero-staging".
deploy-%:
  @$(MAKE) -s deploy-script DEPLOY_REMOTE=stackhero-$* DEPLOY_BRANCH=main


# Règle interne de déploiement. Ne pas modifier.
deploy-script:
  @echo "Déploiement de la branche \"${DEPLOY_BRANCH}\" vers \"${DEPLOY_REMOTE}\"..."
  @echo

  @if [ -n "$$(git status --porcelain)" ]; then \
    echo "Impossible de déployer car des modifications ne sont pas commitées :"; \
    echo "\e[0m"; \
    git status -s; \
    echo ""; \
    echo "\e[0;31m"; \
    echo "Vous pouvez utiliser cette commande pour valider les modifications :"; \
    echo "git add -A . && git commit -m \"Votre message\""; \
    echo "\e[0m"; \
    exit 1; \
  fi

  @git push --dry-run ${DEPLOY_REMOTE} ${DEPLOY_BRANCH} 2>&1 | grep -q -F "Everything up-to-date"; \
  EXIT_CODE=$$?; \
  if [ $$EXIT_CODE -eq 0 ]; then \
    echo -n "Rien de nouveau à déployer... Forcer le déploiement (cela créera un nouveau commit) ? (y/N) "; \
    read answer && \
    case $$answer in \
      y|Y|yes|YES) \
      git commit --allow-empty -m "Force update for deploy purpose to \"${DEPLOY_REMOTE}\"" ; \
      ;; \
      *) \
      echo "Rien à déployer !"; \
      exit 1; \
      ;; \
    esac \
  fi

  git push ${DEPLOY_REMOTE} ${DEPLOY_BRANCH}

Gestion des secrets (variables d'environnement)

À un moment donné, vous aurez besoin de gérer des secrets comme des tokens ou des mots de passe pour des bases de données ou des services tiers. Il est essentiel de stocker ces secrets de façon sécurisée. Evitez d'intégrer des secrets directement dans votre dépôt ou dans le code, car cela représente un risque de sécurité important.

Les variables d'environnement présentent deux avantages majeurs :

  1. Vos secrets ne seront pas stockés dans votre dépôt Git, ce qui limite les risques en cas d'accès à votre code source.
  2. Vous pouvez utiliser des identifiants différents selon l'environnement. Par exemple, se connecter à la base de données de production en production, et à une base de développement en développement.

Définir les variables d'environnement pour le développement

Pour le développement, créez un fichier .env à la racine de votre projet. Ce fichier sera exclu de Git afin de ne jamais être commité. Utilisez la gem dotenv pour charger automatiquement le fichier .env.

Commencez par ajouter la gem dotenv-rails à votre Gemfile :

# Gemfile
gem 'dotenv-rails', groups: [:development, :test]

Puis installez la gem :

bundle install

Ensuite, créez un fichier .env à la racine du projet et ajoutez vos variables :

RAILS_ENV="development"
DATABASE_PASSWORD="secretPassword"
THIRD_API_PRIVATE_KEY="secretKey"
# ...

Enfin, assurez-vous que le fichier .env est ignoré par Git :

echo '.env*' >> .gitignore

Définir les variables d'environnement pour la staging et la production

Pour la staging et la production, le fichier .env n'est ni sécurisé ni pratique car il ne peut pas être stocké dans un dépôt Git. Stackhero propose une solution sécurisée pour gérer les variables d'environnement directement dans la configuration de votre service Ruby.

Vous pouvez définir ces variables via le tableau de bord Stackhero en sélectionnant votre service Ruby puis en cliquant sur le bouton "Configurer".

Accéder aux variables d'environnement

En Ruby, vous pouvez accéder facilement aux variables d'environnement via ENV. Par exemple, pour récupérer DATABASE_PASSWORD :

ENV['DATABASE_PASSWORD'] # => 'secretPassword'

Voici un exemple de connexion à un serveur RabbitMQ en utilisant des variables d'environnement :

require 'bunny'

class RabbitMQClient
  def initialize
    @connection = Bunny.new(hostname: ENV['RABBITMQ_HOST'],
                            username: ENV['RABBITMQ_USERNAME'],
                            password: ENV['RABBITMQ_PASSWORD'])
    @connection.start
  end

  def publish(queue_name, message)
    channel = @connection.create_channel
    queue = channel.queue(queue_name)
    channel.default_exchange.publish(message, routing_key: queue.name)
  end

  def close
    @connection.close
  end
end

Sur la plateforme de développement, votre fichier .env pourrait contenir :

RABBITMQ_HOST='127.0.0.1'
RABBITMQ_USERNAME='developmentUser'
RABBITMQ_PASSWORD='developmentPassword'

Pour la production et la staging, définissez vos variables d'environnement dans le tableau de bord Stackhero, dans la configuration du service Ruby, comme ci-dessous :

RABBITMQ_HOST='<XXXXXX>.stackhero-network.com'
RABBITMQ_USERNAME='production'
RABBITMQ_PASSWORD='secretProductionPassword'

Ouverture des ports UDP/TCP

Les applications Ruby utilisent souvent le protocole HTTP sur les ports 80 (HTTP) et 443 (HTTPS). Si votre application nécessite des ports supplémentaires ou d'autres protocoles (TCP ou UDP), configurez les redirections de ports dans la section "Ports Redirections" de votre service Ruby via le tableau de bord Stackhero.

Vous devrez indiquer le port d'entrée (ouvert publiquement), le port de destination (ouvert dans votre service Ruby) et le protocole (TCP ou UDP).

Stockage de fichiers

Pour stocker des fichiers comme des photos utilisateurs ou des documents, il est fortement recommandé d'utiliser une solution d'object storage. L'object storage permet de partager des fichiers entre plusieurs services et instances, et de dissocier la couche de stockage de votre code. C'est une bonne pratique.

Nous recommandons MinIO comme solution simple, rapide et puissante, compatible avec le protocole Amazon S3.

Si vous choisissez le stockage local, vous pouvez utiliser le stockage persistant fourni avec votre instance Ruby. Ce stockage local est accessible dans le dossier /persistent/storage/.

Cependant, le stockage local est généralement déconseillé car il n'est pas optimal pour la scalabilité et la fiabilité à long terme.

ATTENTION : Ne stockez jamais de données en dehors du dossier /persistent/storage/ !

Stocker des données ailleurs que dans le dossier de stockage persistant peut entraîner une perte de données lors d'un redémarrage, d'une mise à jour de votre instance ou lors d'un nouveau push de code.

Apple/macOS : mémoriser le mot de passe de votre clé SSH privée

Si vous utilisez macOS, il peut être contraignant de saisir le mot de passe de votre clé SSH privée à chaque push de code. Même si la sécurité reste essentielle, vous pouvez gagner en confort en stockant votre mot de passe de façon sécurisée dans le trousseau Apple.

Il peut être tentant de retirer le mot de passe de votre clé SSH privée, mais cela n'est pas conseillé.

Préférez stocker le mot de passe dans le trousseau avec la commande suivante pour une clé nommée id_ed25519 :

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Après avoir exécuté cette commande, vous ne devriez plus avoir à saisir le mot de passe de votre clé. Si vous utilisez une clé RSA, remplacez id_ed25519 par id_rsa comme ci-dessous :

ssh-add --apple-use-keychain ~/.ssh/id_rsa

Autres articles pour Ruby

  1. Plateforme de développement
    Préparez votre plateforme de développement pour qu'elle soit agréable et efficace
  2. Apprendre Ruby
    Un guide complet sur Ruby et Rails
  3. Premiers pas
    Premiers pas avec Ruby on Rails
  4. Déployer en production
    Comment déployer votre code Ruby en production en quelques minutes
  5. Déployer avec GitHub Actions
    Comment déployer votre code Ruby avec GitHub Actions
  6. Redis
    Comment connecter Ruby avec Redis
  7. Dépannage
    Vous rencontrez un problème avec votre service Ruby ? La solution se trouve probablement ici !
  8. TL;DR
    Etapes pour déployer votre code Ruby sur Stackhero