one off dynos

Procfile内で宣言され、heroku ps:scaleを実行することにより、dyno manifold上で実行されるプロセスのセットは、プロセスの編成として知られています。これらのプロセスは、アプリケーションにおける通常の仕事（webリクエストのハンドリングとバックグラウンド処理のプロセシングのような）を行います。ですが、one-off（一度限り）の管理者タスクを実行したり、アプリケーションのメンテナンスタスクを実行したいと思った際、heroku runコマンドを使うことでone-offプロセスを実行するdyno自体をスピンアップしたくなるでしょう。

One-off（一度限りの）プロセス

After you push your application to Heroku, the slug compiler generates a slug containing the application. The application may contain many components, including a web server, a console application, and scripts to initialize the database. While the web process would be defined as a process type in the Procfile and managed by the platform, the console and script would only be executed when needed. These are one-off processes.

Herokuへアプリケーションをプッシュした後、slug compilerは、アプリケーションを含んだslugをジェネレートします。アプリケーションは、webサーバー、コンソール用のアプリケーション、データベースをイニシャライズするためのスクリプトと言った多くのコンポーネントを含んでいます。webプロセスが、Procfile内にプロセスタイプとして定義され、プラットフォームによりマネージされる一方、コンソールとスクリプトは、必要な時にのみ実行されます。これらが、一度限りのプロセス（One-off processes）となります。

Any time spent executing a one-off dynos will contribute to usage and [may be charged](usage-and-billing#oneoff-processes) just like any other dyno.

一度限りのdynoを実行した時は、いつでも、使用にコントリビュートし、その他のdynoと同じように課金される 可能性があります。

Formation dynos vs. one-off dynos

dynoの編成 vs. 一度限りのdyno

One-off processes execute within a dyno, exactly like the app's web, worker, and other formation processes. They get all the benefits of dyno isolation.

1つのdynoで実行する一度限りのプロセスは、webアプリケーション、ワーカー、その他のプロセス編成と良く似ています。これらは、 dynoの隔離の恩恵を受けています。

Each dyno has its own ephemeral filesystem, not shared with any other dyno, that is discarded as soon as you disconnect. This filesystem is populated with the slug archive - so one-off processes can make full use of anything deployed in the application.

それぞれのdynoは、ephemeralなファイルシステムを持っており、その他dynoとシェアせず、ディスコネクトするとすぐに破棄されます。このファイルシステムは、slugのアーカイブとして広く知られています。そのため、一度限りのプロセスは、アプリケーションでデプロイされたものに関しては、全ての使用を可能とします。

There are four differences between dynos running one-off processes (one-off dynos) with heroku run and formation dynos run with heroku ps:scale:

heroku runで実行される一度限りのプロセス（一度限りのdyno）と、heroku ps:scaleで実行されるdynoの編成に 間では、4つの違いあります。

• One-off dynos run attached to your terminal, with a character-by-character TCP connection for STDIN and STDOUT. This allows you to use interactive processes like a console. Since STDOUT is going to your terminal, the only thing recorded in the app's logs is the startup and shutdown of the dyno.

• ターミナルで実行される一度限りのdynoは、STDIN と STDOUTのTCPコネクション、キャラクター単位で実行。 このことは、コンソールのように相互的なプロセスを使うことを許可します。STDOUTは、ターミナルへ値を返しますので、アプリケーションのログで記録される唯一の物は、dynoの起動とシャットダウンとなります。

• One-off dynos terminate as soon as you press Ctrl-C or otherwise disconnect in your local terminal. One-off dynos never automatically restart, whether the process ends on its own or whether you manually disconnect.

• 一度限りのdynoは、Ctrl-Cを押下後すぐに終了されます。または、ローカルのターミナルから接続を切られた場合。一度限りのdynoは、自動的に再起動されることはありません。自分自身でプロセスを終了するか、手動で接続を切らない限り。

• One-off dynos are named in the scheme run.N rather than the scheme worker.N.

• 一度限りのdynoは、worker.Nのスキームよりむしろ、run.Nのスキーム配下に命名されます。

• One-off dynos can never receive HTTP traffic, since the routing mesh only routes traffic to processes named web.N.

• 一度限りのdynoは、HTTPトラフィックを受け付けることはありません。routing meshが、トラフィックをweb.Nと命名されたプロセスのみにルートするため。

Other than these differences, the dyno manifold makes no other distinction between one-off dynos and formation dynos. これら以外の違いは、dyno manifoldが、一度限りのdynoとdynoの編成間で違いを生み出すようなことはありません。

An example one-off process

一度限りのプロセスの例

Dynos running one-off processes are created using heroku run. To see one-off processes in action, execute the bash command, available in all applications deployed to Heroku:

一度限りのプロセスを実行するdynoは、heroku runによって生成されます。一度限りのプロセスが動作しているところを見るためには、bashコマンドを実行して下さい。Herokuへデプロイされたアプリケーションであれば、全てのアプリケーションで利用可能です。

:::term
$ heroku run bash
Running bash attached to terminal... up, run.1
~ $

At this point you have a dyno running a one-off process, and the process is executing the bash command - which provides a shell environment that can be used to explore the file system and process.

この時点では、一度限りのプロセスを実行するdynoを管理しています。そして、プロセスがbashコマンドを実行します。 ファイルシステムとプロセスを探索するのに使用されるシェル環境。

Interact with the shell and list all the files that you deployed:

シェルと相互作用させ、デプロイしたファイルを全てリスト化して下さい。

:::term
~ $ ls
Procfile project.clj src bin ...

If you had a batch file in the bin directory, you can simply execute it, just as you can many other unix commands:

binディレクトリにバッチファイルを管理している場合、シンプルにそれを実行することが出来ます。他のUnixコマンドが実行可能なと同様に。

:::term
~ $ echo "Hi there"
Hi there
~ $ pwd
/app
~ $ bin/do-work

Remove a few files, and exit:

いくつかのファイルをリムーブして、終了して下さい。

    :::term    
~ $ rm Procfile project.clj
~ $ exit

Because each dyno is populated with its own copy of the slug-archive, the deleted files won't change your running application.

それぞれのdynoは、自身のslugのアーカイブのコピーと共存することから 削除されたファイルが、実行中のアプリケーションに変化を与えることはありません。

One-off process execution syntax

一度限りのプロセスの実行の構文

---

heroku run takes two types of parameters - you can either supply the command to execute, or a process type that is present in your application's Procfile.

heroku runは、2種類のパラメータを設定出来ます。実行時にコマンドを　または、アプリケーションのProcfile内でプレセスタイプを宣言する方法です。

If you supply a command, either a script or other executable available to your application, then it will be executed as a one-off process, together with any additional arguments. For example, to execute the Python interpreter with a file dowork.py supplied as an argument, then execute heroku run python dowork.py.

コマンドを　、スクリプトまたは、アプリケーションで利用可能な実行ファイル、一度限りのプロセスを実行することなります。追加の引数とともに。例えば、引数として渡されるdowork.pyのファイルをPythonインタプリターで実行する場合、heroku run python dowork.pyと実行します。

If you instead supply a process type, as declared in a Procfile, then the definition of the process type will be substituted, and executed together with any additional arguments. For example, given the following Procfile:

代わりに、Procfile内で宣言されたプロセスタイプを渡す場合、プロセスタイプの宣言は、代用され、追加の引数とともに実行されます。たとえば、以下のようなProcfileです。

myworker:  python dowork.py

Executing heroku run myworker 42 will run python dowork.py 42 as a one-off process.

heroku run myworker 42を実行することは、一度限りのpython dowork.py 42として実行することとなります。

Types of one-off processes

一度限りのプロセスのタイプ

---

Some types of one-off processes include:

一度限りのプロセスのタイプとして、以下のようなものがあります

• Initialising databases or running database migrations. (e.g. rake db:migrate or node migrate.js migrate)

• データベースの初期化、または、データベースマイグレーションの実行（例：rake db:migrate や node migrate.js migrate）

• Running a console (also known as a REPL shell) to run arbitrary code or inspect the app's models against the live database. (e.g. rails console, irb, or node)

• コンソールの実行（REPLシェルとして知られている）任意のコードを実行するために、または、現在のデータベースに対するアプリケーションのモデルを調査するために（例： rails console、irb、 or node）

• One-time scripts committed into the app's repo (e.g. ruby scripts/fix_bad_records.rb or node tally_results.js).

• アプリケーションのリポジトリにコミットされた1回だけのスクリプト（例：ruby scripts/fix_bad_records.rb または node tally_results.js）

In your local environment, you invoke these one-off processes by a direct shell command inside the app's checkout directory. For example:

ローカル環境で、これらの一度限りのプロセスを誘発することが出来ます。アプリケーションのチェックアウトしたディレクトリ内で、直接シェルコマンドを実行することで。 例：

To pass command line flags to the command being executed, you can quote the entire string to be executed to avoid the Heroku CLI processing the flags: `heroku run "rake --help"`

コマンドラインフラグへを実行されるコマンドへ送るには、実行される全文字列を引用することが可能です。HerokuのCLIがフラグをプロセシングするのを避けるために：`heroku run "rake --help"`

:::term
$ rake db:migrate
(in /Users/adam/widgets)
==  CreateWidgets: migrating ==================================================
-- create_table(:widgets)
   -> 0.0040s
==  CreateWidgets: migrated (0.0041s) =========================================

You can do the exact same thing, but run against your latest Heroku release out on the dyno manifold, by prefixing your command with heroku run: dyno manifold上の最新のHeroku環境であれば、全く同じことをheroku runと先頭に付けることで可能となります。

:::term
$ heroku run rake db:migrate
(in /app)
Migrating to CreateWidgets (20110204210157)
==  CreateWidgets: migrating ==================================================
-- create_table(:widgets)
   -> 0.0497s
==  CreateWidgets: migrated (0.0498s) =========================================

Likewise, if you can run a console in your local environment by executing a command, as you can with Rails and rails console command:

コマンドを実行することで、ローカル環境でコンソールを実行出来るのと同様のことを、Railsのrails consoleコマンドでも実現可能です。

:::term
$ rails console
Loading development environment (Rails 3.0.3)
ruby-1.9.2-p136 :001 > Widget.create :name => 'Test'
 => #<Widget id: 1, name: "Test", size: nil, created_at: "2011-05-31 02:36:39", updated_at: "2011-05-31 02:36:39">

Running the same command against your deployed Heroku app will execute it, and attach it to your terminal: 既にデプロイ済みのHeroku上のアプリへは、同様のコマンドを実行することで、同じことをしてくれます。以下をターミナルに貼付けてみて下さい。:

:::term
$ heroku run rails console
Running rails console attached to terminal... up, run.2
Loading production environment (Rails 3.0.3)
irb(main):001:0> Widget.create :name => 'Test'
=> #<Widget id: 1, name: "Test", size: nil, created_at: "2011-05-31 02:37:51", updated_at: "2011-05-31 02:37:51">

Running tasks in background

バックグラウンドでタスクを実行する

You can run a process in the background using heroku run:detached. Unlike heroku run, these processes will send their output to your logs instead of your console window. You can use heroku logs to view the output from these commands:

heroku run:detachedコマンドを使うことで、バックグラウンドでプロセスを実行することが可能です。コンソールの画面に結果を表示するheroku runとは異なり、これらのプロセスは、ログに結果のアウトプットが保存されます。これらのコマンドの結果は、heroku logsコマンドを使うことで、参照することが可能です。

:::term
$ heroku run:detached rake db:migrate
Running rake db:migrate... up, run.2
Use 'heroku logs -p run.2' to view the log output.

Stopping running processes

プロセスの実行の停止

You can check your current running processes using heroku ps: heroku psコマンドを実行することで、現在、実行中のプロセスを確認することが可能です。:

:::term
$ heroku ps
=== web: `bundle exec thin start -p $PORT -e production`
web.1: up for 8h
web.2: up for 3m

=== worker: `bundle exec stalk worker.rb`
worker.1: up for 1m

If you wish to stop a running process, use heroku ps:stop with the name of the process you want to stop and its host dyno will be terminated.

もし、プロセスの実行を停止させたいのであれば、heroku ps:stopコマンドを使用して下さい。その際に、停止させたいプロセスの名前を明示して下さい。コマンド実行後、ホストのdynoが終了されることとなります。

:::term
$ heroku ps:stop run.1
Stopping run.1 process... done

It is possible to trap `SIGHUP` and cause your dyno to continue running even when the connection is closed. Run `man signal` for more information.

`SIGHUP`をトラップすることが可能です。コネクションがクローズ状態の時でさえ、dynoが実行され続けるようにすることが可能です。より詳しい情報は、`man signal`コマンドを実行してみて下さい。

Connections to one-off dynos will be closed after one hour of inactivity (in both input and output). When the connection is closed, the dyno will be sent SIGHUP. This idle timeout helps prevent unintended charges from leaving interactive console sessions open and unused.

one-off dynosへのコネクションは、アクティブでは無い状態（インプット、アウトプットの両方）が1時間を越えると、クローズされます。コネクションがクローズされた時に、dynoは、SIGHUPを送信します。このアイドル状態のタイムアウトは、予期せぬchargesへ、オープンかつ未使用のセッションをインタラクティブなコンソールに残すことを防ぎます。

Troubleshooting

トラブルシューティング

Timeout awaiting process

プロセス待機によるタイムアウト

The heroku run process opens a connection to Heroku on port 5000. If your local network or ISP is blocking port 5000, or you are experiencing a connectivity issue, you will see an error similar to:

heroku runのプロセスは、ポート番号5000で、Herokuへのコネクションを開始します。ローカルネットワークやISPが、ポート番号5000をブロックしている場合、または、接続の問題が発生しているのであれば、下記と似たエラーを見ることになります。

:::term
$ heroku run rails console
Running rails console attached to terminal... 
Timeout awaiting process

You can test your connection to Heroku by trying to connect directly to port 5000 by using telnet to rendezvous.runtime.heroku.com. A successful session will look like this: コネクションのテストが可能です。XXX　成功したセッションは、このような感じになります。:

:::term
$ telnet rendezvous.runtime.heroku.com 5000
Trying 50.19.103.36...
Connected to ec2-50-19-103-36.compute-1.amazonaws.com.
Escape character is '^]'. 

If you do not get this output, your computer is being blocked from accessing our services. We recommend contacting your IT department, ISP, or firewall manufacturer to move forward with this issue.

このアウトプットを得られない場合は、お使いのコンピューターは、Herokuのサービスへアクセスすることをブロックされています。この問題を先に進めるには、IT部門、ISP、またはファイアーウォールの製造元へコンタクトしてみることをお勧めします。

SSH access

SSHアクセス

Since your app is spread across many dynos in the dyno manifold, there is no single place to SSH into. You deploy and manage apps, not servers.

アプリは、dyno manifold上で、多くのdynoを展開しているので、SSHを格納する1つの決まった場所は存在しません。Herokuのユーザーは、アプリをデプロイし、管理するのであって、サーバーに対して何かを行うわけではないのです。

You can invoke a shell as a one-off process: one-offプロセスとして、シェルを起動することは可能です。:

:::term
$ heroku run bash

However, there is little to be gained from doing so. The filesystem is ephemeral, and the dyno itself will only live as long as your console session.

しかしながら、こうすることで得る物は非常に少ないです。これは、Herokuのファイルシステムが短命であるためで、dyno自体、コンソール上でのセッション期間中にのみ存在することになるからです。

When you find yourself wanting SSH access, instead try using tools that properly accounts for Heroku's distributed environment, such as the heroku command line tool and one-off processes.

SSHアクセスが必要と感じたのであれば、代わりに、Heroku環境で適切に動作保証されているHerokuのコマンドラインツールやone-offプロセスのようなツールを試してみて下さい。