TOC

Comment automatiser le déploiement d’Elixir-Phoenix avec Distillery et edeliver sur Ubuntu 16.04

introduction

Construit sur le langage de programmation Erlang, Elixir est un langage de programmation fonctionnel très populaire pour sa concentration sur la productivité des développeurs et sa facilité d’écriture. applications simultanées et évolutives.

Phoenix est un framework Web construit sur Elixir pour permettre la création d’applications Web hautement performantes.

Et en combinaison avec deux outils supplémentaires - Distillery et edeliver - vous pouvez complètement automatiser le déploiement de projets Phoenix à partir de votre développement. environnement à un serveur de production.

Distillery compile les applications Elixir en un seul package que vous pouvez ensuite déployer ailleurs. Il génère également des packages qui permettent hot-swapping de code, ce qui signifie que vous pouvez mettre à niveau des applications en direct sans temps d’arrêt. Tout cela peut être fait avec peu ou pas de configuration de votre part, ce qui distingue Distillery de nombreuses autres options.

edeliver automatise ce processus de construction et de déploiement en prenant en charge des tâches répétitives telles que la construction de l’application, le transfert du package créé sur le serveur, la migration de la base de données et le démarrage / la mise à jour du serveur. Si nécessaire, vous pouvez même configurer edeliver pour permettre également une configuration intermédiaire.

Dans ce didacticiel, vous allez installer Erlang, Elixir et Phoenix 1.3 sur une machine de développement locale et sur un serveur de production, simplifier la communication SSH entre les deux sites, puis créer un exemple de projet Phoenix à déployer avec edeliver. Enfin, vous sécuriserez le serveur de production avec un proxy inverse Nginx et un certificat SSL.

À la fin du tutoriel, vous aurez une seule commande qui peut:

  • créer une version Phoenix compatible avec votre environnement de production

  • déployer la version dans votre environnement de production

  • démarrez votre application dans un environnement de production

  • permutation à chaud de la version de production actuelle en déployant une nouvelle version sans aucun temps d’arrêt

Conditions préalables

Avant de commencer, assurez-vous de disposer des éléments suivants:

  • Une machine de développement local basée sur Ubuntu. Bien que les instructions de ce didacticiel soient écrites pour une machine de développement local basée sur Ubuntu, l’un des points forts de ce processus de déploiement est qu’il est totalement indépendant de l’environnement de production. Pour obtenir des instructions sur la configuration des machines de développement locales sur d’autres systèmes d’exploitation, consultez la official installation documentation Elixir. Ou, pour configurer une machine de développement remote basée sur Ubuntu, suivez les instructions de https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04].

  • Un compte d’utilisateur non root avec des privilèges sudo sur un serveur de production Ubuntu 16.04 avec au moins 1 Go de RAM, configurez-le en suivant les quatre premières étapes décrites dans https://www.digitalocean.com/community/tutorials/initial-server-setup. -with-ubuntu-16-04 [ce tutoriel initial sur la configuration du serveur].

  • Notre objectif étant d’automatiser le processus de déploiement, n’entrez pas de phrase secrète SSH lorsque vous suivez l’étape 4 du didacticiel d’installation. De plus, veillez à autoriser l’accès au port + 4000 + à l’étape 7 du tutoriel d’installation avec la commande + sudo ufw allow 4000 +. C’est le port que nous utiliserons pour tester Phoenix tout au long de ce tutoriel.

  • Nginx installé sur le serveur de production en suivant les this Guide d’installation de Nginx sur Ubuntu 16.04.

  • Un nom de domaine entièrement enregistré. Ce tutoriel utilisera + example.com + tout au long. Vous pouvez acheter un nom de domaine sur https://namecheap.com [Namecheap], en obtenir un gratuitement sur Freenom ou utiliser le registraire de domaine de votre choix. .

  • Les deux enregistrements DNS suivants sont configurés pour votre serveur. Vous pouvez suivre cien tutoriel sur les noms d’hôtes pour savoir comment les ajouter.

  • Un enregistrement A avec ++ pointant sur l’adresse IP publique de votre serveur.

  • Un enregistrement A avec + www. + Pointant vers l’adresse IP publique de votre serveur.

  • Nginx a sécurisé un certificat SSL en suivant https://www.digitalocean.com/community/tutorials/how-to-set-up-let-s-encrypt-with-nginx-server-blocks-on-ubuntu-16- 04 [tutoriel de cette configuration avec Encodage avec des blocs de serveur Nginx sur Ubuntu 16.04]. Assurez-vous de choisir l’option 2, + Redirect +, à l’étape 4 du didacticiel d’installation de Nginx, car cela fournira des redirections automatiques vers HTTPS sur le serveur de production que nous créons dans ce didacticiel.

Étape 1 - Installation d’Elixir et de Phoenix sur la machine de développement local

Elixir étant exécuté sur la machine virtuelle Erlang, nous devons l’installer avant de pouvoir installer Elixir lui-même. Et comme nous voulons nous assurer d’utiliser la version stable la plus récente d’Erlang, nous allons installer Erlang à partir du référentiel Erlang Solutions.

Tout d’abord, téléchargez et ajoutez le référentiel Erlang Solutions à votre ordinateur de développement local.

cd ~
wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb
sudo dpkg -i erlang-solutions_1.0_all.deb

Maintenant, mettez à jour votre liste de paquets et installez le paquet + esl-erlang + qui fournit à la fois le langage de programmation Erlang ainsi que des outils, bibliothèques et middlewares utiles, collectivement appelés plate-forme Erlang / OTP.

sudo apt-get update
sudo apt-get install esl-erlang

Ensuite, installez Elixir.

sudo apt-get install elixir

Ensuite, utilisez Mix - un outil de construction fourni avec Elixir pour créer des projets Elixir et gérer les dépendances - afin d’installer le propre gestionnaire de paquets d’Elixir, Hex, que vous utiliserez ultérieurement pour installer Phoenix.

La partie + local + de cette commande indique à Mix d’installer `+ hex + + localement.

mix local.hex

Lorsque vous êtes invité à confirmer l’installation, entrez + Y +.

OutputAre you sure you want to install "https://repo.hex.pm/installs/1.5.0/hex-0.17.1.ez"? [Yn]
* creating .mix/archives/hex-0.17.1

Maintenant, utilisez Hex pour installer l’archive Phoenix 1.3.0 Mix, un fichier Zip contenant tout ce dont vous aurez besoin pour générer un nouveau projet Phoenix de base.

mix archive.install https://github.com/phoenixframework/archives/raw/master/phx_new-1.3.0.ez

De nouveau, lorsque vous êtes invité à confirmer l’installation, entrez «+ Y +».

OutputAre you sure you want to install "https://github.com/phoenixframework/archives/raw/master/phx_new-1.3.0.ez"? [Yn]
* creating .mix/archives/phx_new-1.3.0

Avec Elixir et Phoenix installés sur la machine de développement locale, installons les éléments dont nous avons besoin sur le serveur de production.

Étape 2 - Installation d’Elixir et de Phoenix sur le serveur de production

Parce que notre projet Phoenix doit être exécuté sur la machine de développement locale et sur le serveur de production, nous devrons installer les mêmes langages et outils aux deux endroits.

En utilisant les mêmes commandes depuis link: # step-1-% E2% 80% 94-installation-elixir-et-phoenix-on-the-local-development-machine [Étape 1], téléchargez et ajoutez le référentiel Erlang Solutions à votre serveur de production.

cd ~
wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb
sudo dpkg -i erlang-solutions_1.0_all.deb

Mettez à jour votre liste de paquets et installez le paquet + esl-erlang +.

sudo apt-get update
sudo apt-get install esl-erlang

Installez Elixir.

sudo apt-get install elixir

Utilisez Mix pour installer Hex.

mix local.hex

Lorsque vous êtes invité à confirmer l’installation, entrez + Y +.

OutputAre you sure you want to install "https://repo.hex.pm/installs/1.5.0/hex-0.17.1.ez"? [Yn]
* creating .mix/archives/hex-0.17.1

La machine de développement locale et le serveur de production sont maintenant prêts à exécuter Phoenix, mais facilitons la connexion au serveur de production à partir de la machine de développement locale en configurant un alias d’hôte SSH.

Étape 3 - Configuration d’un alias d’hôte SSH

Notre objectif étant un processus de déploiement entièrement automatisé, nous avons généré une paire de clés SSH au cours du lien: #prerequisites [configuration initiale du serveur de production] ne demandant pas de phrase secrète.

Pour le moment, nous pouvons nous connecter de la machine de développement locale au serveur de production avec la commande + ssh -i ~ / .ssh / @ +.

Ici, nous nous connectons à + ​​example.com + en tant qu’utilisateur * sammy *. L’indicateur + -i + indique à SSH d’utiliser le fichier de clé privée situé sous + ~ / .ssh / private_key_file + pour la connexion.

Nous pouvons rendre cette commande - et le processus de déploiement lui-même - encore plus simple en configurant un alias d’hôte SSH qui sait automatiquement quels clé privée, utilisateur et domaine utiliser lors de la connexion au serveur de production.

Ouvrez + ~ / .ssh / config + sur la machine de développement locale pour l’éditer.

nano ~/.ssh/config

Et, copiez dans les lignes suivantes.

~ / .ssh / config

Host
   HostName
   User
   IdentityFile

La ligne + Host + fournit un alias qui identifie cette configuration particulière. Pour que ce soit plus facile à retenir, nous utilisons notre nom de domaine. La ligne + HostName + indique à SSH l’hôte auquel se connecter. La ligne + utilisateur + permet à SSH de savoir sous quel utilisateur se connecter, et le + IdentityFile + indique à SSH le fichier de clé privée à utiliser.

Enregistrez vos modifications et fermez le fichier.

Enfin, testez la configuration en vous connectant au serveur de production.

ssh

Vous devriez avoir été en mesure d’établir la connexion sans spécifier d’utilisateur, de fichier de clé privée ou de domaine. Si vous n’êtes pas en mesure de vous connecter, suivez les messages à l’écran et suivez les étapes précédentes pour résoudre le problème.

Maintenant que la connexion au serveur de production est simplifiée, nous pouvons créer un exemple de projet Phoenix à déployer.

Étape 4 - Création d’un projet de test

Par défaut, lorsque vous créez un nouveau projet Phoenix, il est configuré avec un adaptateur de base de données PostgreSQL et Brunch, une version d’application Web basée sur JavaScript. outil. Pour éviter cette complexité supplémentaire, nous allons créer un projet Phoenix simple nommé + myproject + sans adaptateur de base de données et sans Brunch en passant les indicateurs + - no-ecto + et + - no-brunch +, respectivement.

Accédez à votre répertoire personnel et créez le nouveau projet.

cd ~
mix phx.new --no-ecto --no-brunch

La sortie inclut les répertoires et les fichiers créés par Phoenix en tant qu’échafaudage pour le projet + myproject +, une invite pour confirmer que vous souhaitez installer les dépendances requises, ainsi que des instructions sur la procédure de démarrage du serveur intégré de Phoenix.

Entrez + Y + lorsque vous êtes invité à confirmer l’installation.

Output* creating myproject/config/config.exs
* creating myproject/config/dev.exs
* creating myproject/config/prod.exs
...

Fetch and install dependencies? [Yn]
* running mix deps.get
* running mix deps.compile

We are all set! Go into your application by running:

   $ cd myproject

Start your Phoenix app with:

   $ mix phx.server

You can also run your app inside IEx (Interactive Elixir) as:

   $ iex -S mix phx.server

Voyons maintenant si notre projet test fonctionne.

Allez dans le répertoire + myproject + et exécutez la commande + mix phx.server + pour compiler le projet et démarrer le serveur.

cd ~/myproject
mix phx.server

La sortie vous indique le nombre et les types de fichiers que Phoenix a compilés, vous avertit des problèmes rencontrés en cours de route et, en cas de succès, vous permet de savoir où atteindre le projet.

La première fois que vous compilez une application basée sur Elixir sur votre ordinateur de développement local, vous serez invité à installer Rebar, un outil de construction et de dépendances pour Erlang sur lequel repose Mix. Entrez + Y + à l’invite.

Output==> file_system
Compiling 6 files (.ex)
Generated file_system app
...
Could not find "rebar3", which is needed to build dependency :ranch
I can install a local copy which is just used by Mix
Shall I install rebar3? (if running non-interactively, use "mix local.rebar --force") [Yn]
...
Compiling 11 files (.ex)
Generated myproject app
[info] Running MyprojectWeb.Endpoint with Cowboy using http://0.0.0.0:4000

Pour tester la configuration actuelle, pointez votre navigateur Web sur http: // localhost: 4000. La page d’accueil Phoenix Framework par défaut vous souhaite la bienvenue. Si ce n’est pas le cas, assurez-vous que votre pare-feu autorise les connexions sur le port + 4000 +, puis examinez la sortie de votre terminal pour obtenir des instructions supplémentaires.

Une fois que vous avez vérifié que tout fonctionne bien, appuyez deux fois sur les touches + CTRL + C + pour arrêter le serveur et le préparer à la configuration ultérieure dans le lien: # step-5-% E2% 80% 94 utilisation distillerie et edeliver [étape 5].

Maintenant que vous avez un projet Phoenix local pleinement fonctionnel, laissez-le configurer pour qu’il utilise Distillery et edeliver.

Étape 5 - Configuration du projet pour utiliser Distillery et edeliver

Les projets Phoenix stockent les détails de la configuration, tels que le port sur lequel le projet est exécuté et l’URL hôte du projet dans + config / prod.exs +. Nous allons donc commencer par éditer ce fichier pour indiquer à Phoenix comment accéder au projet dans l’environnement de production.

Ouvrez + config / prod.exs + sur votre ordinateur de développement local pour l’éditer.

nano ~/myproject/config/prod.exs

Recherchez le bloc de code suivant:

config / prod.exs

...
config :myproject, MyprojectWeb.Endpoint,
 load_from_system_env: true,
 url: [host: "example.com", port: 80],
 cache_static_manifest: "priv/static/cache_manifest.json"
...

Lorsque + load_from_system_env + est défini sur + true +, Phoenix obtient le port sur lequel le projet doit être exécuté à partir de la variable d’environnement + PORT + par défaut. Ceci est appelé le port HTTP.

Les + url: [hôte] + et + url: [port] + sont utilisés pour générer des liens dans le projet. Cette différence entre HTTP et URL est particulièrement utile lors de la configuration de serveurs proxy lorsque le point de terminaison du proxy est exposé sur un port différent du projet Phoenix.

Par souci de simplicité, nous allons coder en dur le port HTTP sur lequel le + myproject + est exécuté. Cela réduira le nombre de pièces mobiles, ce qui augmentera la fiabilité de notre processus de déploiement automatisé.

Outre les options par défaut que nous allons modifier, nous ajouterons également deux nouvelles options.

L’option + server + indique à Distillery de configurer le projet pour qu’il démarre le serveur HTTP au démarrage, ce que nous souhaitons dans un processus de déploiement entièrement automatisé.

L’option + code_reloader + indique au projet d’actualiser tous les navigateurs Web connectés chaque fois que le code du projet change. Bien que cela puisse être une fonctionnalité très utile en développement, il n’est pas destiné aux environnements de production, nous le désactiverons donc.

Maintenant, modifiez la configuration par défaut.

config / prod.exs

...
config :myproject, MyprojectWeb.Endpoint,

 url: [host: "", port: 80],
 cache_static_manifest: "priv/static/manifest.json"


...

Enregistrez et fermez + config / prod.exs + une fois que vous avez apporté vos modifications.

Lorsque nous avons créé le projet + mon projet + dans le lien: # step-4-% E2% 80% 94-creation-a-test-project [étape 4], Phoenix a automatiquement généré un fichier + .gitignore + que nous allons need in link: # step-6-% E2% 80% 94-configuration-edeliver-and-distillery [Étape 6] lorsque nous transmettons les modifications de code au serveur de génération avec edeliver.

Par défaut, ce fichier + .gitignore + indique à Git d’ignorer les dépendances et de créer des fichiers afin que le référentiel ne devienne pas inutilement volumineux. En outre, ce fichier indique à Git d’ignorer + prod.secret.exs +, un fichier du répertoire + config + de tous les projets Phoenix contenant des informations très sensibles, telles que les mots de passe de la base de production et les secrets d’application pour la signature des jetons.

Comme le projet + myproject + a besoin de + prod.secret.exs + `sur le serveur de production pour fonctionner correctement et que nous ne pouvons pas le déplacer avec Git, nous devons le transférer manuellement sur le serveur.

Dans votre répertoire de base sur le serveur de production, créez un nouveau répertoire appelé + app_config +. C’est là que vous aurez stocké + prod.secret.exs.

cd ~
mkdir app_config

Maintenant, utilisez + scp + pour copier + prod.secret.exs + dans le répertoire + app_config + sur le serveur de production.

scp ~/myproject/config/prod.secret.exs :/home//app_config/prod.secret.exs

Enfin, vérifiez que le transfert a bien eu lieu en répertoriant le contenu de + app_config + sur le serveur de production.

ls ~/app_config

Si vous ne voyez pas + prod.secret.exs + dans la sortie, consultez le terminal sur votre ordinateur de développement local pour obtenir des informations supplémentaires.

Avec + prod.secret.exs + sur le serveur de production, nous sommes prêts à installer Distillery pour le processus de construction et edeliver pour le déploiement en les incluant tous deux dans + mix.exs +, le fichier de configuration principal pour le `+ monprojet +. `projet.

Ouvrez + mix.exs + sur votre ordinateur de développement local.

nano ~/myproject/mix.exs

Maintenant, trouvez le bloc de code suivant:

Dépendances dans mix.exs

 ...
 defp deps do
   [
     {:phoenix, "~> 1.3.0"},
     {:phoenix_pubsub, "~> 1.0"},
     {:phoenix_html, "~> 2.10"},
     {:phoenix_live_reload, "~> 1.0", only: :dev},
     {:gettext, "~> 0.11"},
     {:cowboy, "~> 1.0"}
   ]
 end
 ...

+ deps + est une fonction privée qui définit explicitement toutes les dépendances de notre projet + myproject +. Bien que cela ne soit pas strictement nécessaire, cela permet de garder la configuration du projet organisée.

Ajoutez + edeliver + et + + distillery + à la liste des dépendances.

Dépendances dans mix.exs

 ...
 defp deps do
   [
     {:phoenix, "~> 1.3.0"},
     {:phoenix_pubsub, "~> 1.0"},
     {:phoenix_html, "~> 2.10"},
     {:phoenix_live_reload, "~> 1.0", only: :dev},
     {:gettext, "~> 0.11"},
     {:cowboy, "~> 1.0"}


   ]
 end
 ...

Enregistrez vos modifications et fermez + mix.exs +.

Maintenant, indiquez + mix + pour récupérer les nouvelles dépendances afin qu’elles soient disponibles au moment de l’exécution.

cd ~/myproject/
mix deps.get

La sortie nous indique que + edeliver + et + distillery + ont été ajoutés à notre projet avec succès.

OutputResolving Hex dependencies...
Dependency resolution completed:
 ...
* Getting edeliver (Hex package)
 Checking package (https://repo.hex.pm/tarballs/edeliver-1.4.4.tar)
 Fetched package
* Getting distillery (Hex package)
 Checking package (https://repo.hex.pm/tarballs/distillery-1.5.2.tar)
 Fetched package

Enfin, redémarrez le serveur Phoenix sur la machine de développement locale pour tester la configuration actuelle.

mix phx.server

Pointez votre navigateur sur http: // localhost: 4000. Vous devriez voir la même page d’accueil Phoenix par défaut que celle que vous avez vue dans le lien: # step-4-% E2% 80% 94-creation-a-test-project [Étape 4]. Si vous ne le faites pas, suivez à nouveau les étapes précédentes et examinez le terminal de votre ordinateur de développement local pour obtenir des informations supplémentaires.

Lorsque vous êtes prêt à continuer, appuyez deux fois sur «+ CTRL + C +» pour arrêter le serveur afin qu’il soit prêt pour une configuration ultérieure à l’étape suivante.

Distillery et edeliver étant installés, nous sommes prêts à les configurer pour le déploiement.

Étape 6 - Configuration d’Edeliver et de la distillerie

Distillery nécessite un fichier de configuration de construction qui n’est pas généré par défaut. Cependant, nous pouvons générer une configuration par défaut en exécutant + mix release.init +.

Allez dans le répertoire + myproject + sur votre ordinateur de développement local et générez le fichier de configuration.

cd ~/myproject
mix release.init

La sortie confirme que le fichier a été créé et inclut des instructions supplémentaires sur la manière de modifier et de générer la version.

OutputAn example config file has been placed in rel/config.exs, review it,
make edits as needed/desired, and then run `mix release` to build the release

edeliver recherchera les versions dans le répertoire + rel / + lors de mises à niveau à chaud, mais Distillery place les versions dans le répertoire + _build + par défaut. Modifions donc le fichier de configuration par défaut de Distillery, + rel / config.exs +, pour placer les versions de production au bon endroit.

Ouvrez + rel / config.exs + dans votre éditeur.

nano rel/config.exs

Trouvez la section suivante:

rel / config.exs

...
environment :prod do
 set include_erts: true
 set include_src: false
 set cookie: :"f3a1[Q^31~]3~N=|T|T=0NvN;h7OHK!%%c.}$)iP9!X|TS[X@sqG=m`yBYVt4/`:"
end
...

Ce bloc indique à Distillery comment nous souhaitons créer des packages de version de production autonomes. + include_erts + indique si nous souhaitons regrouper Erlang Runtime System, ce qui est utile lorsque Erlang ou Elixir n’est pas installé sur le système cible. + include_src + indique si nous souhaitons inclure les fichiers de code source. Et la valeur + cookie + est utilisée pour authentifier les nœuds Erlang afin qu’ils puissent communiquer entre eux.

Fermez le fichier.

Nous sommes maintenant prêts à configurer edeliver, mais nous devrons créer son fichier de configuration manuellement.

Allez dans le répertoire + myproject + sur votre machine de développement locale et créez un nouveau répertoire nommé + .deliver +, puis ouvrez un nouveau fichier dans + .deliver / config + pour le modifier.

cd ~/myproject
mkdir .deliver
nano .deliver/config

Dans ce fichier, nous spécifierons les détails des serveurs de construction et de production. Étant donné que nous utilisons le même serveur pour la construction et la production, notre hôte et notre utilisateur sont les mêmes pour la construction et la production. De plus, nous allons construire le répertoire + app_build + et placer les fichiers de production compilés dans le répertoire + app_release +.

Copiez le texte suivant dans le fichier.

deliver/config
APP=""

BUILD_HOST=""
BUILD_USER=""
BUILD_AT="/home//app_build"

PRODUCTION_HOSTS=""
PRODUCTION_USER=""
DELIVER_TO="/home//app_release"

Ensuite, nous allons créer un lien symbolique dans le dossier de construction vers + prod.secret.exs +, le fichier que nous avons transféré dans le répertoire + app_config + sur le serveur de production dans le lien suivant: # step-5-% E2% 80% 94 configuration du projet d’utilisation distillerie-edeliver [étape 5]. Ce lien symbolique est créé à l’intérieur d’un crochet À chaque étape du processus de construction, d’étape et de déploiement, un hook spécifique est appelé par edeliver. Pour notre configuration de déploiement automatisé, nous écoutons le hook + pre_erlang_get_and_update_deps + appelé avant que edeliver ne récupère nos dépendances et ne commence la compilation.

Ajoutez ce qui suit à + ​​.deliver / config +.

deliver/config
pre_erlang_get_and_update_deps() {
 local _prod_secret_path="/home//app_config/prod.secret.exs"
 if [ "$TARGET_MIX_ENV" = "prod" ]; then
   __sync_remote "
     ln -sfn '$_prod_secret_path' '$BUILD_AT/config/prod.secret.exs'
   "
 fi
}

Enregistrez et fermez le fichier une fois l’édition terminée.

Étant donné qu’edeliver utilise Git pour transmettre le code de la dernière validation au serveur de génération pour une action ultérieure, la dernière étape avant le déploiement consiste à créer un référentiel Git pour notre projet.

Dans le répertoire + myproject + sur votre ordinateur de développement local, utilisez la commande + git init + pour créer un référentiel Git vide.

cd ~/myproject
git init

Avant d’ajouter nos fichiers à l’index Git, nous devons également ajouter le répertoire contenant nos archives de version dans le fichier + .gitignore +. Sinon, le référentiel Git deviendrait très volumineux après quelques versions.

echo ".deliver/releases/" >> .gitignore

Ensuite, ajoutez le jeu complet de fichiers du projet + myproject + à la zone de stockage intermédiaire Git afin qu’ils soient inclus dans le prochain commit.

git add .

Maintenant, définissez l’identité que Git doit associer à ce référentiel. Cela vous aidera à savoir d’où proviennent les changements apportés à votre projet.

git config user.email ""
git config user.name ""

Enfin, validez les fichiers dans le référentiel en utilisant l’option + -m + pour décrire la raison de la validation.

git commit -m "Setting up automated deployment"

La sortie répète votre message de validation, puis indique le nombre de fichiers modifiés, le nombre de lignes insérées et les noms des fichiers ajoutés au référentiel.

Output[master (root-commit) e58b766] Setting up automated deployment
39 files changed, 2344 insertions(+)
create mode 100644 .deliver/config
...

Notre projet étant désormais entièrement configuré pour Git and Distillery et edeliver, nous sommes prêts pour notre premier déploiement.

Étape 7 - Déploiement du projet

Un des avantages de ce processus de déploiement est que vous ferez presque tout sur la machine de développement locale, sans avoir besoin de toucher le serveur de production.

Envoyons tout mon projet maintenant en transmettant le projet + myproject + au serveur de production.

Premièrement, utilisez + mix + sur votre machine de développement locale pour construire une version du projet et la transférer sur le serveur de compilation avec edeliver.

cd ~/myproject
mix edeliver build release

La sortie vous met à jour en temps réel à propos de chaque étape du processus de génération et, si tout fonctionne comme prévu, vous indique que la génération a abouti.

OutputBUILDING RELEASE OF MYPROJECT APP ON BUILD HOST

-----> Authorizing hosts
-----> Ensuring hosts are ready to accept git pushes
-----> Pushing new commits with git to:
-----> Resetting remote hosts to fc86f878d96...
-----> Cleaning generated files from last build
-----> Fetching / Updating dependencies
-----> Compiling sources
-----> Generating release
-----> Copying release 0.0.1 to local release store
-----> Copying myproject.tar.gz to release store

RELEASE BUILD OF MYPROJECT WAS SUCCESSFUL!

Si votre construction n’a pas abouti, edeliver indiquera la ligne de code qu’elle tentait d’exécuter lorsqu’il a rencontré le problème. Vous pouvez utiliser ces informations pour résoudre le problème.

Une fois la construction terminée, transférez la version sur le serveur de production.

mix edeliver deploy release to production

Une fois encore, la sortie vous met à jour en temps réel à propos de chaque étape du processus et, si tout fonctionne, vous indique que la version a été mise en production.

OutputDEPLOYING RELEASE OF MYPROJECT APP TO PRODUCTION HOSTS

-----> Authorizing hosts
-----> Uploading archive of release 0.0.1 from local release store
-----> Extracting archive myproject.0.1.tar.gz

DEPLOYED RELEASE TO PRODUCTION!

Si vous rencontrez un problème de déploiement, examinez le résultat de votre terminal pour obtenir des informations supplémentaires.

Enfin, démarrez le projet + myproject + sur le serveur de production.

mix edeliver start production

La sortie indique à l’utilisateur sur lequel le projet est exécuté, à l’hôte sur lequel il s’exécute et au chemin d’accès à la version qu’il utilise sur le serveur de production. La réponse sera + START DONE! +.

OutputEDELIVER MYPROJECT WITH START COMMAND

-----> starting production servers

production node:

 user    :
 host    :
 path    : /home//app_release
 response:

START DONE!

Testez le processus de déploiement en pointant votre navigateur sur + http: //: 4000 +. Vous devriez à nouveau voir la page d’accueil par défaut de Phoenix Framework. Sinon, vérifiez à nouveau que le port + 4000 + est ouvert sur le serveur de production, puis consultez le terminal de la machine de développement locale pour obtenir des informations supplémentaires.

Maintenant que nous avons vérifié le processus de création et de déploiement complet, allons encore plus loin dans notre configuration en effectuant une mise à jour du code sans interruption de service sur le serveur de production.

Étape 8 - Mise à niveau du projet sans interruption de production

L’une des caractéristiques de notre processus de construction et de déploiement est la possibilité d’échanger à chaud le code, en mettant à jour le projet sur le serveur de production sans aucun temps d’arrêt. Modifions le projet pour essayer ceci.

Ouvrez le fichier de page d’accueil du projet pour le modifier.

nano ~/myproject/lib/myproject_web/templates/page/index.html.eex

Trouvez la ligne suivante:

~ / monprojet / web / templates / page / index.html.eex

...
<h2><%= gettext "Welcome to %{name}", name: "Phoenix!" %></h2>
...

Maintenant, remplacez cette ligne par ce qui suit:

<h2>Hello, World!</h2>

Enregistrez et fermez le fichier.

Maintenant que nous avons mis à jour la base de code, nous devons également incrémenter la version de l’application. Le numéro de version facilite le suivi des versions et le retour aux versions précédentes si nécessaire.

Ouvrez + mix.exs + sur votre machine de développement locale.

nano ~/myproject/mix.exs

Trouvez le bloc suivant:

mix.exs

 ...
 def project do
   [app: :myproject,
    version: "0.0.1",
    elixir: "~> 1.2",
    elixirc_paths: elixirc_paths(Mix.env),
    compilers: [:phoenix, :gettext] ++ Mix.compilers,
    build_embedded: Mix.env == :prod,
    start_permanent: Mix.env == :prod,
    deps: deps()]
 end
 ...

Incrémente la version de + 0.0.1 + à + ​​0.0.2 +.

mix.exs

 ...
 def project do
   [app: :myproject,
    version: "",
    elixir: "~> 1.2",
    elixirc_paths: elixirc_paths(Mix.env),
    compilers: [:phoenix, :gettext] ++ Mix.compilers,
    build_embedded: Mix.env == :prod,
    start_permanent: Mix.env == :prod,
    deps: deps()]
 end
 ...

Ensuite, enregistrez et fermez le fichier.

Nous devons maintenant ajouter et valider nos modifications dans Git afin qu’edeliver sache qu’il doit les envoyer au serveur de construction.

git add .
git commit -m "Changed welcome message"

Enfin, nous sommes prêts à échanger à chaud nos modifications. Cette fois-ci, nous avons une seule commande qui équivaut aux trois commandes connexes que nous utilisions dans link: # step-7-% E2% 80% 94-deploying-the-project [Étape 7].

Avec une seule commande, créez, déployez et redémarrez l’application sur le serveur de production.

mix edeliver upgrade production

Une fois encore, la sortie nous guide à travers chaque étape du processus en temps réel et, en cas de succès, se termine par + UPGRADE DONE! +.

OutputEDELIVER MYPROJECT WITH UPGRADE COMMAND

-----> Upgrading to revision 2fc28b6 from branch master
-----> Detecting release versions on production hosts
-----> Deploying upgrades to 1 online hosts
-----> Checking whether installed version 0.0.1 is in release store
-----> Building the upgrade from version 0.0.1
-----> Authorizing hosts
-----> Validating * version 0.0.1 is in local release store
-----> Ensuring hosts are ready to accept git pushes
-----> Pushing new commits with git to:
-----> Resetting remote hosts to 2fc28b6...
-----> Cleaning generated files from last build
-----> Checking out 2fc28b6...
-----> Fetching / Updating dependencies
-----> Compiling sources
-----> Checking version of new release
-----> Uploading archive of release 0.0.1 from local release store
-----> Extracting archive myproject_0.0.1.tar.gz
-----> Generating release
-----> Removing built release 0.0.1 from remote release directory
-----> Copying release 0.0.2 to local release store
-----> Copying myproject.tar.gz to release store
-----> Upgrading production hosts to version 0.0.2
-----> Authorizing hosts
-----> Uploading archive of release 0.0.2 from local release store
-----> Upgrading release to 0.0.2

UPGRADE DONE!

Pour vérifier que tout fonctionne, rechargez + http: //: 4000 + dans votre navigateur. Vous devriez voir le nouveau message. Si ce n’est pas le cas, suivez à nouveau les étapes précédentes et recherchez des messages d’erreur et d’avertissement supplémentaires sur votre terminal.

Le processus de déploiement a maintenant été réduit à une seule commande. Nous utilisons également l’une des fonctionnalités les plus connues d’Erlang: l’échange à chaud de code. Pour terminer, renforçons notre application en production en la plaçant derrière un proxy Nginx.

Étape 9 - Configuration d’un proxy inverse sur le serveur de production

Bien que nous puissions exposer directement notre application sur Internet, un proxy inverse assurera une meilleure sécurité. Pour faciliter la configuration, la prise en charge de SSL et la possibilité de définir des en-têtes de réponse HTTP personnalisés, nous utiliserons Nginx pour notre proxy.

Si vous avez suivi la procédure https://www.digitalocean.com/community/tutorials/how-to-set-up-let-s-encrypt-with-nginx-server-blocks-on-ubuntu-16-04 Encryptons avec des blocs de serveur Nginx sur Ubuntu 16.04], vous devriez déjà avoir créé un bloc de serveur Nginx distinct sur le serveur de production uniquement pour notre projet.

Ouvrez le fichier de configuration de ce bloc serveur pour le modifier.

sudo nano /etc/nginx/sites-available/

Premièrement, nous devons dire à Nginx où réside notre projet Phoenix et sur quel port il écoute. Puisque nous servons notre projet sur le port + 4000 + localement, nous disons à Nginx que notre point de terminaison de proxy se trouve à +127.0.0.1: 4000 +.

Copiez le code suivant dans le fichier de configuration situé au-dessus du bloc de configuration du serveur par défaut.

/etc/nginx/sites-available/example.com

upstream phoenix {
   server 127.0.0.1:4000;
}

Maintenant, dans le même fichier, trouvez le bloc de code suivant:

/etc/nginx/sites-available/example.com

   ...
       location / {
               # First attempt to serve request as file, then
               # as directory, then fall back to displaying a 404.
               try_files $uri $uri/ =404;
       }
   ...

Pour que le proxy fonctionne, nous devons dire à Nginx de rediriger toutes les connexions au serveur Web vers notre projet Phoenix, y compris l’en-tête de la demande, l’adresse IP du serveur par lequel le client a été mandaté et l’adresse IP du client. lui-même.

Nous allons également configurer Nginx pour transférer les demandes entrantes via WebSockets, un protocole de messagerie entre les serveurs Web et les clients qui met à jour le connexion HTTP standard sans état à une connexion persistante.

Phoenix propose une fonctionnalité appelée Canaux que nous n’avons pas explorée dans ce didacticiel, mais les canaux nécessitent la prise en charge de WebSockets. Sans cette configuration, les canaux ne fonctionneront pas car les requêtes WebSocket ne parviendront pas au serveur.

Remplacez l’ancien bloc + location + par ce qui suit:

/etc/nginx/sites-available/example.com

 location / {
   allow all;

   # Proxy Headers
   proxy_http_version 1.1;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header Host $http_host;
   proxy_set_header X-Cluster-Client-Ip $remote_addr;

   # WebSockets
   proxy_set_header Upgrade $http_upgrade;
   proxy_set_header Connection "upgrade";

   proxy_pass http://phoenix;
 }

Enregistrez et fermez le fichier pour continuer.

Maintenant, vérifiez la nouvelle configuration de Nginx.

sudo nginx -t

Nginx devrait indiquer que la syntaxe est correcte et que le test a réussi. Sinon, suivez les messages à l’écran pour résoudre le problème.

Redémarrez Nginx pour propager les modifications.

sudo systemctl restart nginx

Enfin, pour des raisons de sécurité, interdisez l’accès à votre application via HTTP sur le port + 4000 +.

sudo ufw delete allow 4000

Ensuite, vérifiez le statut de UFW.

sudo ufw status

Le pare-feu ne devrait autoriser l’accès SSH et Nginx qu’à ce stade.

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx Full                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx Full (v6)            ALLOW       Anywhere (v6)

Enfin, vérifiez que tout fonctionne correctement en pointant votre navigateur sur + https: // +.

Vous disposez maintenant d’un processus de création et de déploiement entièrement automatisé et d’un serveur de production sécurisé à la fois par un proxy inverse et un certificat SSL.

Conclusion

Même si nous avons configuré edeliver pour générer et déployer notre projet Phoenix sur un serveur de production à l’aide d’une seule commande, vous pouvez en faire beaucoup plus.

La plupart des applications Phoenix de production utilisent une base de données. Dans Comment déployer des applications Elixir-Phoenix avec MySQL sur Ubuntu 16.04, vous continuerez à utiliser cette application en ajoutant une base de données MySQL et en déployant de nouvelles fonctionnalités en production.

Si votre infrastructure de production est composée d’un cluster de nœuds Phoenix, vous pouvez utiliser edeliver pour effectuer un déploiement et une permutation à chaud sur tous les nœuds à la fois.

Ou, si vous souhaitez une configuration plus fiable, vous pouvez créer une infrastructure de stockage intermédiaire à part entière et utiliser edeliver pour gérer le processus de stockage intermédiaire et de déploiement.

Pour en savoir plus sur l’un ou l’autre de ces sujets ou pour en savoir plus sur l’extension de votre installation actuelle d’edeliver, visitez le site https://github.com/edeliver/edeliver/officiel du projet sur GitHub].

Related