Mise en place d'une nouvelle application Rails avec Docker & MySQL

Je suis ingénieur logiciel senior dans une entreprise de technologie et de données de taille moyenne. Historiquement, j'ai porté de nombreuses casquettes : j'ai créé des flux d'acquisition de clients, géré des bases de données, travaillé sur React complexe, conçu un CMS complet pour un usage interne, créé des microservices d'API Golang destinés au public à partir de zéro, conçu des systèmes d'authentification d'API, livré sur une variété de produits B2B et B2C, été responsable technique de plusieurs équipes (à la fois), et plus encore. Je suis également actuellement assez peu expérimenté lorsqu'il s'agit de créer de nouvelles applications Rails à partir de zéro. Alors j'ai pensé que j'allais tenter le coup !

C'est un tutoriel assez basique mais j'ai trouvé peu de guides pratiques pour cela. Cela étant dit, je tiens à citer deux tutoriels auxquels j'ai beaucoup emprunté pour écrire ceci – considérez ceci comme une synthèse de ces articles ainsi que de certaines de mes préférences personnelles : Tallan Groberg et Nícolas Iensen. Nous allons éviter beaucoup de détails en faveur de nous lancer. J'écris ceci en utilisant un tout nouveau Macbook Pro M4, mais les bases devraient être transposées dans la plupart des environnements Mac ou Linux.

Nous allons créer une application Ruby simple qui utilise Rails comme framework principal, MySQL pour une base de données (en partie pour ses fonctionnalités et en partie pour ajouter à la complexité de ce que je vise avec cet article) et Docker pour la virtualisation et la compatibilité multiplateforme. Nous ne construisons aucun modèle ou contrôleur dans ce didacticiel : tout est question de configuration. À la fin du didacticiel, vous disposerez d’une application Hello World assez classique. Vous devriez être capable de prendre ce concept de base et de l'appliquer à n'importe quelle application que vous créez.

Commencer

Tout d'abord, cela suppose une certaine familiarité avec le terminal et les ordinateurs basés sur Unix. Si cela a un certain sens, vous devrez installer Docker et Homebrew (en supposant que vous soyez sur un Mac). Si vous utilisez zsh comme shell principal (la plupart des Mac le sont par défaut de nos jours), vous devrez peut-être ajouter ce qui suit à votre fichier ~/.zshrc afin de pouvoir exécuter les commandes Brew :

path+=/opt/homebrew/bin

Une fois que vous avez enregistré le fichier, exécutez source ~/.zshrc et tout devrait bien se passer !

Une petite remarque : les commandes préfixées par $ indiquent les commandes qui sont exécutées dans votre shell local (zsh ou bash, très probablement) tandis que les commandes préfixées par # sont exécutées dans le conteneur Docker. Dans tous les cas, le préfixe ne doit pas être copié, c'est juste un indicateur visuel d'une nouvelle invite de ligne.

Tout d'abord

De nombreux développeurs placent tous leurs projets de codage dans un seul répertoire (le mien est le frère des répertoires Téléchargements et Documents et je l'appelle de manière créative code). Dans le terminal, accédez à votre répertoire équivalent et tapez les commandes suivantes :

$ mkdir my-app
$ cd my-app

Dans ce nouveau répertoire, nous avons besoin de quelques nouveaux fichiers. Créez-les avec les commandes suivantes :

path+=/opt/homebrew/bin

Le premier, Dockerfile.dev créera votre image Docker de base, en s'appuyant sur une image existante qui installe la version de Ruby que nous utiliserons pour ce projet (la dernière à ce jour, 3.3.6) et en configurant quelques détails mineurs sur la façon dont cette image devrait se comporter. La partie .dev du nom de fichier indique que ce Dockerfile ne sera utilisé que localement et non dans un environnement de production. Une commande que nous exécutons plus tard dans le didacticiel créera pour nous un fichier Dockerfile plus robuste, prêt pour la production, et je souhaite pouvoir distinguer les deux. Compte tenu de la portée de ce didacticiel, ces détails ne nous inquiètent pas. Ajoutez les lignes suivantes audit fichier :

$ mkdir my-app
$ cd my-app

Vient ensuite le fichier docker-compose.yml : son objectif est de coordonner un certain nombre de conteneurs Docker ensemble pour garantir que l'application Web que nous construisons dispose de tous les éléments constitutifs qui communiquent ensemble : le serveur Web, une base de données, potentiellement un serveur Redis, peut-être un serveur Elasticsearch, etc. Tous ces différents éléments vivraient dans leur propre « ordinateur virtuel » et devraient être câblés pour communiquer entre eux d'une manière imitant un environnement de production. Assez parlé de choses théoriques, l'important est que nous devons ajouter du code de configuration au fichier docker-compose.yml :

$ touch Dockerfile.dev
$ touch docker-compose.yml
$ touch Gemfile

Ne vous inquiétez pas des détails, mais cela dit essentiellement "lorsque vous exécuterez ceci, vous allez exécuter une application appelée" web "et elle essaiera de créer l'application principale avec un fichier docker appelé" Dockerfile.dev ' et mappera le port interne 3000 du réseau du système Docker au port 3000 de l'ordinateur local sur lequel il s'exécute. Oh, et aussi, fera tourner une base de données et leur permettra de se parler. Ou quelque chose comme ça. Si vous exécutez déjà une application sur le port 3000, n'hésitez pas à modifier le numéro de port de gauche comme vous le souhaitez.

D'accord ! Nous avons maintenant un fichier qui construira une image et un autre fichier qui exécutera un conteneur utilisant cette image et l'insérera dans un petit réseau qu'il fera tourner. Bon! Mais... comment fait-on ça ?

Entrer dedans

Pour commencer à nous occuper, nous devons réellement entrer dans le conteneur que nous construisons pour faire certaines choses. Nous faisons cela en exécutant ceci :

FROM ruby:3.3.6

WORKDIR /usr/src/app

COPY . .
RUN bundle install

Maintenant, nous sommes dans l'ordinateur. L'idée est que nous pouvons désormais exécuter des commandes dans l'environnement du conteneur sans avoir besoin d'installer certains logiciels sur l'ordinateur que nous utilisons. Rails, par exemple, n'a pas besoin d'exister n'importe où sur votre ordinateur pour pouvoir l'exécuter sur un conteneur Docker exécuté sur votre ordinateur. Assez chouette.

D'accord, maintenant que nous y sommes, installons Rails :

services:
  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: app
      MYSQL_USER: user
      MYSQL_PASSWORD: password
    ports:
      - "3307:3306"
  web:
    build:
      context: .
      dockerfile: Dockerfile.dev
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    volumes:
      - ".:/usr/src/app"
    ports:
      - "3000:3000"
    depends_on:
      - db
    links:
      - db
    environment:
      DB_USER: root
      DB_NAME: app
      DB_PASSWORD: password
      DB_HOST: db

Et maintenant, créons notre application ! Nous voulions construire cette application en utilisant MySQL, alors notez sa spécification dans la commande suivante :

path+=/opt/homebrew/bin

Cela va prendre une seconde. Il vous sera demandé si vous souhaitez écraser le Gemfile. Appuyez sur y pour confirmer. La même question vous sera posée pour tous les autres fichiers générés par cette commande. Utilisez les touches o/n en conséquence pour ignorer ou accepter les nouvelles versions.

Huzzah ! Nous avons terminé le squelette de notre application ! Cependant, nous n’avons pas réellement terminé. Nous devons aborder un élément important pour préparer la base de données. Et puis, idéalement, nous devrions aborder un détail de sécurité important.

Configuration de la base de données

La première partie de cette section n'est peut-être pas très nécessaire si vous faites simplement quelque chose localement et que vous n'envisagez pas de déployer quoi que ce soit. De plus, il y a beaucoup plus à considérer ici et je pense que cela vaut la peine de consacrer un didacticiel séparé pour approfondir une partie de la configuration de la base de données et de la sécurité de base du référentiel, surtout si votre référentiel est public (ne vous inquiétez pas si c'est le cas, soyez juste prudent !) .

Avec la commande précédente, nous nous sommes retrouvés avec un grand nombre de nouveaux fichiers et répertoires. L'un d'eux est config/database.yml. Pour moi, à la ligne 12 se trouve un bloc qui ressemble à ceci :

$ mkdir my-app
$ cd my-app

Techniquement, ce qui précède fonctionne. Il n’y a rien de « mal » à cela. Mais nous pouvons faire mieux. Le plus gros problème est que notre base de données n'a pas de mot de passe. Le problème suivant est que la base de données n'a pas de nom. Enfin, le nom d'utilisateur est visible en texte brut. Pas mon préféré. Changeons tout cela avec ce qui suit (le premier des éléments suivants est un nouveau champ, les deux seconds doivent remplacer toutes les valeurs existantes) :

$ touch Dockerfile.dev
$ touch docker-compose.yml
$ touch Gemfile

Vous pouvez également utiliser le style ENV.fetch("VARIABLE_NAME") { "fallback_value" }. La différence entre ENV["VARIABLE_NAME"] et ENV.fetch("VARIABLE_NAME") est que le premier renverra nil s'il ne trouve pas de variable d'environnement avec le nom désigné tandis que le second peut déclencher des avertissements ou des erreurs (voir ceci et ceci pour plus d'informations sur ENV.fetch).

Avec tout ça, et en supposant que vous n'avez pas quitté le shell (vous pouvez utiliser docker-compose run --service-ports web bash pour y revenir), nous devons créer une nouvelle base de données. Faites cela avec la commande suivante :

FROM ruby:3.3.6

WORKDIR /usr/src/app

COPY . .
RUN bundle install

Quittez le shell Docker et dans l'environnement du terminal local, exécutez les commandes suivantes :

services:
  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: app
      MYSQL_USER: user
      MYSQL_PASSWORD: password
    ports:
      - "3307:3306"
  web:
    build:
      context: .
      dockerfile: Dockerfile.dev
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    volumes:
      - ".:/usr/src/app"
    ports:
      - "3000:3000"
    depends_on:
      - db
    links:
      - db
    environment:
      DB_USER: root
      DB_NAME: app
      DB_PASSWORD: password
      DB_HOST: db

C'est ça ! Si vous pointez votre navigateur (ou un client API comme Postman) sur localhost:3000, vous devriez voir la page de démarrage Rails classique :

Ajout d'une sécurité extrêmement simple

Nous avons une application fonctionnelle ! Et il est livré avec une belle base de données prête pour les opérations de production (la base de données par défaut fournie par Rails, SQLite, est idéale pour regrouper des idées de base, mais elle n'est pas destinée au travail de production et son créateur est un cinglé) ! Mais une base de données plus robuste s'accompagne de responsabilités supplémentaires.

Comme nous l'avons vu plus tôt dans ce didacticiel, nous devions fournir trois valeurs importantes : le nom de la base de données, un nom d'utilisateur et un mot de passe pour cet utilisateur. Pour l'instant, nous avons 1 couche d'abstraction : plutôt que de simplement transmettre des valeurs de chaîne brutes au fichier database.yml, nous récupérons ces valeurs depuis l'environnement Rails. Alors, où l’environnement Rails obtient-il ces valeurs ? Depuis le fichier docker-compose.yml !

Mais cela laisse un problème important encore à résoudre : en supposant que nous allons utiliser ce code en production, nous avons inclus des informations auxquelles personne d'autre que les administrateurs système ne devrait avoir accès directement dans le code lui-même. Ce n'est pas génial. Nous devrions avoir une couche d'abstraction supplémentaire qui supprime toute référence directe à certaines informations précieuses, théoriquement comprises.

Maintenant, nous devons réellement OBTENIR ces variables d'environnement correctement configurées dans notre environnement Ruby lors de son premier démarrage. Nous allons procéder en deux étapes, mais n'hésitez pas à le faire en une seule si vous êtes à l'aise. Nous devons d’abord arrêter de faire directement référence aux secrets de la base de données dans le projet Rails. C'est ce que nous faisons. Ensuite, nous devons les transférer de Docker vers Rails. Enfin, nous allons l'abstraire encore plus en ajoutant les valeurs secrètes d'un fichier que nous cachons à Git pour mieux masquer ces informations aux vauriens potentiels.

Pipetage des variables d'environnement dans Rails à partir de Docker

Nous avons quelques options, mais ma solution est de créer un fichier d'environnement dans lequel ces valeurs sont stockées. Si vous travaillez en équipe, vous pouvez partager ce fichier entre vous via des mesures plus furtives (le cryptage GPG est un classique) sans risquer de mettre cette information sur l'internet public. Si vous jetez un œil au fichier .gitignore qui a probablement été créé lorsque vous avez exécuté Rails New il y a quelque temps, vous remarquerez qu'il y a un élément de ligne pour tous les fichiers à la racine du projet qui commencent par .env. C'est exactement ce que nous voulons : un fichier secret qui ne soit pas ajouté au suivi git mais dans lequel nous pouvons enregistrer des informations importantes et top secrètes en texte brut. Faisons-le :

path+=/opt/homebrew/bin

J'ai ajouté le suffixe .dev juste au cas où nous finirions par vouloir des fichiers d'environnement différents pour les environnements de développement, de production et de test. Dans ce fichier nouvellement créé, ajoutons quelques valeurs :

$ mkdir my-app
$ cd my-app

Nous allons également devoir mettre à jour le fichier docker-compose.yml afin d'utiliser réellement le nouveau fichier d'environnement. Sous le service Web, ajoutez ce qui suit :

$ touch Dockerfile.dev
$ touch docker-compose.yml
$ touch Gemfile

Et c'est tout ! Redémarrez l'application avec docker compose up et accédez à localhost:3000 pour confirmer que tout va bien.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!