参考訳：Nomad 0.3 リリース | Pocketstudio.jp log3

HashiCorp のブログに Nomad 0.3 のリリースに関する投稿がありました。例によって、自分のための情報整理とメモを兼ねて、翻訳内容を参考情報程度の位置づけで公開します。

■ original post

Nomad 0.3 – HashiCorp
https://www.hashicorp.com/blog/nomad-0.3.html

■ Nomad 0.3

私たちは Nomad 0.3 のリリースを誇りに思います。 Nomad とは分散してスケールする高可用性を持つクラスタ管理（マネージャ）であり、マイクロサービスとバッチ処理の両方を行うよう設計されたスケジューラです。

今回のリリースでは新機能を導入しました。中心となるコンポーネントを強固なものにします。全面的な UX （ユーザ経験）の改善は、Nomad をプロダクションで使えるよう、準備するに至る道を確固たるものとします。主要な機能は次の通りです。

定期ジョブ（Periodic Jobs）
ログ・ローテーションとファイルシステム API
ジョブ・キュー（Job Queues）

より詳しい変更情報は Nomad 0.3 の CHANGELOG をご覧ください。

こちらから Nomad 0.3 をダウンロードできます。あるいは、Nomad 0.3 の新機能や改良について知りたければ、このまま読み進めてください。

■ 定期ジョブ（Periodic Jobs）

Nomad 0.3 は定期的に実行するジョブ（訳者注：以下、「定期ジョブ」）を導入しました。これはユーザが cron 形式をベースとするバッチ・ジョブを定期的に実行できます。定期ジョブとはバックアップや ETL （訳者注：Extract（抽出）/Transform（加工）/Load（読み込み））のような様々なワークロードであり、大部分の環境において実行可能なものです。昨年 Nomad を発表して以来、この機能に対してコミュニティから強い要望がありました。

Nomad は定期ジョブを実行するための、分散（分配）とフォールト・トレラント機能を提供します。単一でエフェメラル（ephemeral；短命・短時間）なノードでは、可用性の課題があります。
そのような環境では、crontab をベースとした実行システムは苦慮しますが、そこでも実行可能なのです。

次の例は、定期的にバッチを Nomad ジョブで15分ごとに動かします。

job "backup" {
    ...
    periodic {
        cron = "*/15 * * * * *"
    }
    ...
}

「nomad status」は直近で処理した定期ジョブの状態と、次の処理までのタイムスタンプを表示します。

$ nomad status backup
ID                   = backup
Name                 = backup
Type                 = batch
Priority             = 50
Datacenters          = dc1
Status               = running
Periodic             = true
Next Periodic Launch = 2016-02-25 00:40:00 +0000 UTC

Previously launched jobs:
ID                           Status
backup/periodic-1456359780  dead
backup/periodic-1456359840  dead
backup/periodic-1456360020  running

$ nomad status backup/periodic-1456360020
ID          = backup/periodic-1456360020
Name        = backup/periodic-1456360020
Type        = batch
Priority    = 50
Datacenters = dc1
Status      = running
Periodic    = false

==> Evaluations
ID        Priority  Triggered By  Status
d451a894  50        periodic-job  complete

==> Allocations
ID        Eval ID   Node ID   Task Group  Desired  Status
b763c7b8  d451a894  d551531b  cache       run      running

■ ログ・ローテーションとファイルシステム API

プロダクション環境におけるアプリケーションの管理・デバッグのためには、ログの管理が非常に重要な要素です。Nomad 0.3 では、ログ保存で直面する２つ要素を解決します。

「stdout」（標準出力）と「stderr」（エラー出力）のログファイルをローテーション
ホストマシンに SSH でログインしなくても、ログにアクセスできる

Nomad 0.3 はタスクごとにログ・ローテーションを指定できます。この設定を通して、ユーザはログファイルの大きさやローテーションを管理できます。以下は記述例です。

logs {
   max_files = 5
   max_file_size = 10
}

この例では「stderr」「stdout」のログを５つのファイルに保持し、それぞれのファイルサイズは 10 MB と指定しています。アプリケーションが更にログを出力すると、古いログファイルをパージし（削除し）、指定した以上のログを保管しないよう制限します。

アプリケーションのログ設定機能のほかに、Nomad 0.3 ではファイル・システムのタスクを表示するための一連の新コマンドを導入しました。これはログファイルや他のファイルを表示する機能です。

$ nomad fs ls c5598dc8 redis/local/
Mode        Size    Modfied Time           Name
-rw-r--r--  0 B     24/02/16 23:19:18 UTC  redis.stderr.0
-rw-r--r--  10 MB   24/02/16 23:22:54 UTC  redis.stdout.3
-rw-r--r--  10 MB   24/02/16 23:22:54 UTC  redis.stdout.4
-rw-r--r--  10 MB   24/02/16 23:22:54 UTC  redis.stdout.5
-rw-r--r--  10 MB   24/02/16 23:22:54 UTC  redis.stdout.6
-rw-r--r--  6.0 MB  24/02/16 23:22:54 UTC  redis.stdout.7

こちらの出力から分かるのは、 Nomad クライアントは直近の５つのログファイルしか保管していません。古い「redis.stdout.0」「redis.stdout.1」「redis.stdout.2」はパージされました。

特定のログファイルの内容を確認するには、次のようなコマンドを実行します。

$ nomad fs cat c5598dc8 redis/local/redis.stdout.7
<LOGの内容>

ストリーミング・ログやリモート・ログを流すようなログ記録サブシステムの拡張が、Nomad のロードマップに含まれています。

■ ジョブ・キュー（Job Queues）

ジョブ・キューとは、ユーザがジョブをスケジュール（訳者注：どの環境上で実行するかを計画・処理すること）できるようにします。それが、全てのリソースを巨大なクラスタで使う場合でもです。リソースが追加されるか利用可能になると、 Nomad はジョブを再評価（re-evaluate）し、実行します。

以下の例は、現在よりも多くのリソースを必要とするジョブを実行します。そうすると Nomad は「blocked」と評価し、リソース変更を処理します。

$ nomad run redis-cache.nomad
==> Monitoring evaluation "b58210a7"
    Evaluation triggered by job "redis-cache"
    Scheduling error for group "cache" (failed to find a node for placement)
    Allocation "eb78c6f3" status "failed" (0/1 nodes filtered)
      * Resources exhausted on 1 nodes
      * Dimension "cpu exhausted" exhausted on 1 nodes
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "b58210a7" finished with status "complete"

$ nomad status redis-cache
ID          = redis-cache
Name        = redis-cache
Type        = service
Priority    = 50
Datacenters = dc1
Status      = pending
Periodic    = false

==> Evaluations
ID        Priority  Triggered By  Status
05263d94  50        job-register  blocked
b58210a7  50        job-register  complete

==> Allocations
ID        Eval ID   Node ID  Task Group  Desired  Status
eb78c6f3  b58210a7  <none>   cache       failed   failed

Nomad は blocked と評価しました。これはクラスタがジョブを実行するために十分な CPU リソースを持っていないためです。blocked として中断されていても、リソースが追加されるとスケジューラはそれをトリガとして、新しい割り当てとジョブ実行を処理します。

$ nomad status redis-cache
ID          = redis-cache
Name        = redis-cache
Type        = service
Priority    = 50
Datacenters = dc1
Status      = pending
Periodic    = false

==> Evaluations
ID        Priority  Triggered By  Status
05263d94  50        job-register  complete
b58210a7  50        job-register  complete

==> Allocations
ID        Eval ID   Node ID  Task Group  Desired  Status
eb79c6fg  05263d94  d551531b cache       running  running
eb78c6f3  b58210a7  <none>   cache       failed   failed

これまでのエンジニアは極めて効率的なジョブ・キューを作ることに力を注いできました。そうではなく、スケジューラが著しく速く、より高性能に行うのです。

Nomad を使った目覚ましいパフォーマンス改善に関する概要は、近いうちにブログへの投稿する予定です。

■ 更新の詳細

Nomad 0.3 にアップグレードする前に、多くの変更点に関する理解が必要です。バージョン 0.2.3 からアップグレードするドキュメントを用意しています。

■ ロードマップ

現時点では、次回の Nomad メジャー・リリースに向けて次の点を計画しています。

サポートしているドライバをまたがる永続的ボリューム（persistent volumes）
複数のネットワーク・インターフェースのサポートと、柔軟な IP 割り当てスキーマ
ストリーミング・ログやリモート・ログ（remote sinks）をサポートするログ機能サブシステムの拡張

いつもの通り、私たちは今回のリリースに関するアップグレードやテストを、別の環境（隔離された環境）で行うことを推奨します。問題がありましたら GitHub でご報告ください。

—- ここまで翻訳

ここから Nomad 0.3 の役割に関する私見と、現時点でのメモ。

* 単純にバラバラの環境の cron / crontab を一括管理する用途だけでも使えそうな予感。
* ジョブの管理だけじゃなく、ログの管理とか、ssh でログインしなくても出来ちゃう感があって、個人的には良さげ。
* SSHがオワコン、という訳ではなく、そもそもログインする必要ないよね？という考え方とみた。
* あるいは、そもそも SSH でログインするという概念の無い環境向けとか（例：コンテナ）。
* Nomad は Window 向けクライアントも提供されているので、どこまで出来るか検証したいところ。

* 運用が楽しくなりそう、ヤバイ