La préparation de la connexion à l'hôte à l'exécution de rake dans l'application Ruby on Rails est trop longue, alors combinons-la en une seule commande, ʻappdo`.
Si vous mettez Ruby dans rbenv ou rvm, vous ne pourrez pas trouver ruby lors de l'exécution de commandes avec sudo ou cron. Eh bien, vous pouvez lire ~ / .bashrc etc. à chaque fois, mais cela complique la commande. Si le nombre d'endroits où un tel traitement est effectué augmente, des omissions de correction sont susceptibles de se produire. C'est emballé.
Lors de l'exécution d'une application Ruby on Rails, ni bundle exec rake ni bin / rails runner ne peuvent être exécutés sans plus de cd $ RAILS_ROOT. En conséquence, les commandes opérationnelles deviennent de plus en plus longues, et "crontab" et "config / deploy.rb" deviennent difficiles à maintenir. C'est emballé.
** Quoi qu'il en soit, le même hôte prépare la même chose, donc je devrais avoir un tel paramètre sur l'hôte **, donc j'ai fait une telle commande.
J'ai créé une commande ʻappdo pour exécuter des commandes dans le contexte de l'application. [pip install`](https://pypi.python.org/pypi/appdo) Vous pouvez.
pip install appdo
Avec ʻappdo, les rails c` qui fonctionnaient comme ça ...
$ su - web #S'enregistrer d'abord ...
$ cd my-awesome-app #Il y avait ce répertoire
$ cd current #Oh, c'était sous le contrôle de capistrano
$ export RAILS_ENV=production #Définir les variables d'environnement
$ export RACK_ENV=production #(Quelque chose de différent)
$ bundle exec rails c #Hoi
C'est tout ce que vous devez faire.
$ sudo -iu web appdo rails c #rails c dans l'application de l'utilisateur Web
Écrivez le fichier de configuration dans $ HOME / .appdo.conf comme indiqué ci-dessous. Le format est TOML.
# /home/web/.appdo.conf
#
##Si vous faites sudo, l'utilisateur de destination sudo.appdo.conf s'applique
[default]
cd = "~/my-awesome-app/current"
source = ["/etc/profile", "~/.bashrc"]
prefix = "bundle exec"
[default.env]
RAILS_ENV = production
RACK_ENV = production
Comme vous pouvez le voir, cd et source sont utilisés pour définir les variables d'environnement, puis la commande est bundle exec.
Si vous le faites à chaque fois, ce n'est pas un travail que les humains devraient faire. Cela rend les gens plus heureux de le mettre dans un fichier de configuration et de l'approvisionner et de le gérer.
crontabRAILS_ROOT=/home/web/my-awesome-app/current
BASHRC=/home/web/.bashrc
RAILS_ENV=production
30 3 * * * bash -c "cd $RAILS_ROOT; source $BASHRC; bundle exec rails runner MyAwesomeApp::MyCron.run()"
30 4 * * * bash -c "cd $RAILS_ROOT; source $BASHRC; bundle exec rails runner MyAwesomeApp::MyCron2.run()"
30 5 * * * bash -c "cd $RAILS_ROOT; source $BASHRC; bundle exec rails runner MyAwesomeApp::MyCron3.run()"
30 3 * * * appdo rails runner MyAwesomeApp::MyCron.run()
30 4 * * * appdo rails runner MyAwesomeApp::MyCron2.run()
30 5 * * * appdo rails runner MyAwesomeApp::MyCron3.run()
Puisqu'il n'est pas nécessaire de définir des variables d'environnement (appdo les absorbe), crontab devient super simple. Vous pouvez voir quelle commande vous tapez avec appdo. Je peux le voir
ssh my.server.example.com sudo -u web bash -c "cd /home/web/my-awesome-app/current; source ~/.bashrc; RAILS_ENV=production bundle exec rake assets:precompile"
ssh my.server.example.com sudo -iu web appdo rake assets:precompile
C'est aussi simple que «crontab».
Simplifier ssh a le grand avantage de simplifier config / deploy.rb. La séparation est meilleure car vous n'avez pas à mettre d'informations spécifiques à l'hôte (chemins, variables d'environnement, etc.) dans le code de votre application.
Imaginez que tous les cd / sources quittent le document
sensationnel
Par exemple, même si les chemins de l'application sont différents ou si ruby est dans un environnement mixte de rvm / rbenv, le fichier de configuration sur chaque hôte peut absorber cette différence. Par conséquent, la migration séquentielle peut être beaucoup plus facile, car le script de déploiement n'a pas besoin d'être modifié.
# /root/.appdo.conf
[apache]
cd = "/etc/apache2"
[bind]
cd = "/var/bind/etc/bind"
Il peut être pratique de spécifier uniquement la destination cd et de ne partager que la commande de gestion du fichier de paramètres.
# appdo --app=apache -- ls sites-available
# appdo --app=apache -- ln -s sites-available/99-default sites-enabled
# appdo --app=bind -- co -l master/my.example.com
# appdo --app=bind -- vim master/my.example.com
# appdo --app=bind -- ci -u master/my.example.com
--Utilisez appdo pour exécuter des commandes dans le "contexte de l'application" --Utilisez appdo pour déposer le "contexte de l'application" dans le fichier de paramètres --Utilisez appdo pour organiser les pauses entre les applications et l'infrastructure
C'est un script que je viens de faire moi-même et qui n'est pas à l'épreuve des balles, mais j'ai décidé de le publier et de répondre aux spécifications en premier. Nous attendons avec impatience vos rapports de bogues et vos demandes.
À l'origine, j'ai pensé à cette commande ʻappdo parce que c'était stressant de ne pas pouvoir utiliser rubydesudo lorsque j'utilisais rvm / rbenv. Les exigences imposées à l'infrastructure changent à nouveau ces jours-ci, mais je pense qu'il est préférable de concevoir l'hôte pour qu'il se comporte de manière autonome, qu'il s'agisse de docker, de serf / consul ou d'autoscaling. Même dans un tel endroit, si vous pouvez créer quelque chose comme une "couche hôte" en utilisant ʻappdo et absorber diverses choses, je pense que vous serez satisfait de moins utiliser votre tête.
L'implémentation Python est le soi-disant premier type de prototypage. Je n'ai jamais créé de paquet avec Python, j'ai donc utilisé le [bootstrap-py] de @ mkouhei (https://github.com/mkouhei/bootstrap-py) pour l'implémentation. Je pense qu'il serait préférable de passer à Go lorsque les exigences telles que les options sont fixées.
e? Est-ce que Rust est meilleur? ...