Die Vorbereitung von der Anmeldung beim Host bis zur Ausführung von "Rake" in der Ruby on Rails-Anwendung ist zu lang. Kombinieren Sie sie also zu einem Befehl, "Appdo".
Wenn Sie Ruby in rbenv oder rvm einfügen, können Sie "ruby" nicht finden, wenn Sie Befehle mit "sudo" oder "cron" ausführen. Nun, Sie sollten jedes Mal "~ / .bashrc" usw. lesen, aber dies erschwert den Befehl. Wenn die Anzahl der Stellen, an denen eine solche Verarbeitung durchgeführt wird, zunimmt, treten wahrscheinlich Korrekturauslassungen auf. Es ist voll.
Wenn Sie eine Ruby on Rails-Anwendung ausführen, können weder "Bundle Exec Rake" noch "Bin / Rails Runner" ohne weitere "cd $ RAILS_ROOT" ausgeführt werden. Infolgedessen werden Betriebsbefehle immer länger und "crontab" und "config / deploy.rb" werden schwierig zu warten. Es ist voll.
** Wie auch immer, derselbe Host bereitet das Gleiche vor, also sollte ich eine solche Einstellung auf dem Host haben **, also habe ich einen solchen Befehl gegeben.
appdoIch habe einen "appdo" -Befehl erstellt, um Befehle im Kontext einer App auszuführen. pip install Sie können.
pip install appdo
Mit appdo , Rails c, die früher so liefen ...
$ su - web #Zuerst anmelden ...
$ cd my-awesome-app #Da war dieses Verzeichnis
$ cd current #Oh, es war unter der Kontrolle von Capistrano
$ export RAILS_ENV=production #Umgebungsvariablen festlegen
$ export RACK_ENV=production #(Etwas anderes)
$ bundle exec rails c #Hoi
Das ist alles was Sie tun müssen.
$ sudo -iu web appdo rails c #Schienen c in der App des Webbenutzers
Schreiben Sie die Konfigurationsdatei wie unten gezeigt in $ HOME / .appdo.conf. Das Format ist TOML.
# /home/web/.appdo.conf
#
##Wenn Sie sudo ausführen, ist der sudo-Zielbenutzer.appdo.conf gilt
[default]
cd = "~/my-awesome-app/current"
source = ["/etc/profile", "~/.bashrc"]
prefix = "bundle exec"
[default.env]
RAILS_ENV = production
RACK_ENV = production
Wie Sie sehen können, werden "cd" und "source" verwendet, um Umgebungsvariablen festzulegen, und dann lautet der Befehl "bundle exec".
Wenn Sie es jedes Mal tun, ist es kein Job, den Menschen machen sollten. Es macht die Leute glücklicher, es in eine Konfigurationsdatei zu legen und diese Datei bereitzustellen und zu verwalten.
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()
Da Umgebungsvariablen nicht festgelegt werden müssen (Appdo absorbiert sie), wird crontab sehr einfach. Sie können sehen, welchen Befehl Sie mit appdo eingeben. Ich kann es sehen
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
Dies ist so einfach wie "Crontab".
Die Vereinfachung von ssh hat den großen Vorteil, dass config / deploy.rb vereinfacht wird. Die Trennung ist besser, da Sie keine hostspezifischen Informationen (Pfade, Umgebungsvariablen usw.) in Ihren App-Code einfügen müssen.
Stellen Sie sich vor, alle CDs / Quellen werden aus dem Dokument entfernt Beeindruckend
Selbst wenn die App-Pfade unterschiedlich sind oder Ruby eine gemischte Umgebung aus "rvm / rbenv" ist, kann die Konfigurationsdatei auf jedem Host diesen Unterschied absorbieren. Infolgedessen ist die sequentielle Migration möglicherweise viel einfacher, da das Bereitstellungsskript nicht geändert werden muss.
# /root/.appdo.conf
[apache]
cd = "/etc/apache2"
[bind]
cd = "/var/bind/etc/bind"
Es kann zweckmäßig sein, nur das CD-Ziel anzugeben und nur den Verwaltungsbefehl der Einstellungsdatei freizugeben.
# 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
Es ist ein Skript, das ich gerade selbst erstellt habe und das nicht kugelsicher ist, aber ich habe beschlossen, es zuerst zu veröffentlichen und die Spezifikationen zu erfüllen. Wir freuen uns auf Ihre Fehlerberichte und Anfragen.
Ursprünglich habe ich über diesen Befehl "appdo" nachgedacht, weil es stressig war, dass ich "ruby" von "sudo" nicht verwenden konnte, als ich "rvm / rbenv" verwendete. Die Anforderungen an die Infrastruktur ändern sich heutzutage wieder, aber ich denke, es ist besser, den Host so zu gestalten, dass er sich autonom verhält, egal ob Docker, Leibeigener / Konsul oder Autoscaling. Selbst an einem solchen Ort, wenn Sie mit "appdo" so etwas wie eine "Host-Schicht" erstellen und verschiedene Dinge absorbieren können, werden Sie mit weniger Gebrauch Ihres Kopfes zufrieden sein.
Die Python-Implementierung ist der sogenannte erste Prototyping-Typ. Ich habe noch nie ein Paket mit Python erstellt, daher habe ich @ mkouheis bootstrap-py für die Implementierung verwendet. Ich denke, es wäre besser, zu Go zu wechseln, wenn die Anforderungen wie Optionen festgelegt sind.
e? Ist Rust besser? ...
Recommended Posts