【参考訳】 Nomad 0.2 | Pocketstudio.jp log3

Nomad 0.2 – HashiCorp
https://hashicorp.com/blog/nomad-0-2.html

こちらの Blog 投稿の、日本語参考訳です。

—-ここから

私たちは Nomad 0.2 リリースの発表を嬉しく思います。Nomad は分散し、スケール可能であり、高い可用性を持つクラスタ管理とスケジューラです。マイクロサービスとバッチ処理の両方に向けて設計しました。

Nomad の初公開リリースから２ヶ月間、このほとんどを、私たちはシステムの拡張、ユーザ経験、バグ修正に集中してきました。

Nomad 0.2 は多くの新機能が追加されました。その中には、サービス・ディスカバリ、システム・スケジューラ、再起動ポリシー、新しい強制（constraint）タイプ、クライアントの多くの改良、等を含みます。より詳細な情報は Nomad 0.2 CHANGELOG をご覧ください。

Nomad 0.2 はここからダウンロードできます。Nomad 2.0 の主な新機能や改良について知りたい場合、このまま読み進めてください。

■ サービス・ディスカバリ

スケジューラは、ジョブのスケーリングとタスク失敗時の処理を行い、ノート上のタスクを効率的に配置できます。まず、ディスカバリにおける取り組みを紹介します。ディスカバリには、タスクの状態・回数・場所が動的に変わるという課題があります。Nomad 0.2 は、サービス・ディスカバリとヘルスチェック機能を持つ Consul を統合することで、これら課題の解決を狙います。

私たちはまず、Nomad 上で直ちにサービス・ディスカバリを行う方法として、Consul を統合しました。Nomad の将来バージョンでは、API を公開します。これにより、様々なサービス・ディスカバリ手法も使えるようになるでしょう。

ジョブの中のタスクは、Consul によって登録される「service」のブロックを使って指定できます。

count = 5
task "redis" {
  ...
  service {
    # name = "redis"
    tags = ["global", "cache"]
    port = "db"

    check {
      name = "alive"
      type = "tcp"
      interval = "10s"
      timeout = "2s"
    }
  }
  ...
}

上記の単純な「service」ブロックについて説明します。”redis” サービスの登録には、皆さんご存知の Consul によって発見され得るものです。クラスタ内の他のタスクや、ヘルスチェックと関連付けることで、トラフィックを正常にタスクを処理しているインスタンスに対してのみ流します。更に、Consul クラスタを使うことで、Nomad の中で実行するアプリケーションと同様に、Nomad の外のものも管理できます。これにより、お互いをどのように連携（archestrated）しているかに関わらず、アプリケーションのディスカバリ（発見）を非常に簡単にします。

Nomad クライアントはサービス登録と登録解除に責任を持ちます。タスクを受け取ると、サービスを登録します。これは、マシンの IP アドレスと、タスクによって動的ないし指定済みのポートに基づきます。タスクが必要ではなくなったり、他のマシンに移動したい場合、タスクは登録解除されます。

詳細については「service」に関するドキュメントをご覧ください。

■ システム・スケジューラ

ジョブの登録のためにシステム・スケジューラ（system scheduler）を使います。ジョブとは、ジョブの制約（constraints）に従ってクラスタ上の全てのノードで実行できます。クラスタを拡張すると、スケジューラは既存のシステムで登録されたジョブを、新しいノード上のインスタンスに置き換えます。

システム・スケジューラは、Logstach や Nagios のような監視・ログ保存ツールのデプロイにとても良い方法です。これらをシステム・ジョブとして実行すると、Nomad が提供する多くの機能による利点があります。その機能とは、宣言型のデプロイ、ローリング・アップデート、サービス・ディスカバリ、モニタリング等です。

■ 再起動ポリシー

Nomad は全てのジョブ・タイプにおいて、タスクの失敗時に再起動できるようになりました。新しい「restart」ブロックは、タスク・グループのレベルに導入されました。これはNomad によってタスクを何回処理するかと、どれくらいの周期で再起動するかを命令するものです。わずかなタスクが失敗したとしても、Nomad が再起動ポリシーの追加を認識すると、一時的に失敗することがあってもタスクを実行し続けられます。

restart {
  interval = "5m"
  attempts = 10
  delay = "25s"
}

「service」と「system」作業（workload）の場合、Nomad は確実にタスクを実行し続け、かつ、タスクの失敗時は再起動し続けます。「batch」作業の場合、「restart」ブロックがあれば、ジョブ失敗時における再起動数の上限に達すると、ジョブを中断します。

利用可能な機能の詳細については、再起動ポリシーに関するドキュメントをご覧ください。

■ 制約（constraints）の改良

正規表現の追加、辞書式順序（lexical ordering）、明確なホスト制約により、Nomad 2.0 の制約システムは一層強化されました。

最も面白いのは、新しく追加された「distinct_host」制約を使って、ジョブやタスク・グループのレベルを定義できることです。「distinct_host」制約は、タスク・グループ内で、ジョブを置くユニークなホストを指定します。これにより、タスク・グループを同一場所に配置できない様々なアプリケーションを実行可能にします。

新しい制約に関するそれぞれの詳細な情報は、「constraint」ドキュメントをお読みください。

■ クライアントの改良

Nomad クライアントは多くのバグ修正と、以下の改良を行いました。

Git や Mercurial、HTTP、Amazon S3 といった様々なソースから、リモート・アーティファクト（remote artifacts）のダウンロードと実行ができます。

再起動による状態の復帰能力を改良しました。実行していたタスクの再割り当てや監視を再開します。これにより、Nomad クライアントでアップグレードを行う時、既に実行しているタスクを全て入れ替える必要はありません。

ドライバ設定のインターフェースを改良したので、次のような詳細設定が可能です：

config {
  image = "redis:latest"

  port_map {
    "db": 6379
  }

  auth {
    username = "username"
    password = "password"
  }
}

■ ロードマップ

Nomad 0.2 は大きなリリースとなりました。多くの新機能の追加、改良、安定性、バグの修正を行いました。そして、以降のリリースに向けての新しい課題を想定しています。

0.3 に向けてのロードマップは検討中ですが、次の銀機能を考えています。

cron 指定による定期的なジョブ実行
ジョブのキュー機能（queuing）により、既存のリソース上で更なるジョブのスケジューリングを可能にします。これにより、高いリソース競合（contention）下においても Nomad を弾力的に使えます。
親和性（affinity）と非親和性（anti-affinity）により、他にあるノードとジョブのデータ集積を行います。これは tenancy 制約を提供し、タスク間のネットワーク・レイテンシ（待ち時間）を最小化します。

それまでは、これまでと同じように Nomad 2.0 を楽しんでいただければと思います！もし何か問題があれば、GitHub にご報告願います。

—-ここまで