Nomad Workshop
Takayuki Kaburagi, Solutions Engineer, HashiCorp Japan K.K
@kabuctl
kabu@hashicorp.com
https://blog.kabuctl.run
https://github.com/tkaburagi
Copyright © 2019 HashiCorp
HashiCorp Overview
Products
Founded
2012 by Mitchell Hashimoto and Armon Dadgar
CEO
Dave McJannet
ある特定の技術ではなく、ワークフローの最終ゴールにフォーカスします。製品設計はまずゴールを設定し、そこに至るまでのワークフローを想像するところから始まります。
Workflows, not technologies
Unix哲学と同様各ツールはシンプルでモジュール化され、組み合わせ可能であること。ツールは利用範囲が明確に定義されている小さなコンポーネントを好みます。各ツールはブロックであり、完全なソリューションを構築する際はそれらを組み合わせて使うべきです。
Simple, Modular, Composable
各ツールは独立したプロセスとして扱われ、APIを介して他のツールとコミュニケーションし連結します。
Communicating Sequential Processes
VCSのコミット内容が永久に残るように、サーバなどのインフラもバージョン管理やデバッグを行えるように不変的に管理されるべきです。
Immutability
The Tao of HashiCorp
全てのプロセスはコードで書かれ、保管され、バージョン化されるべきです。これにより過去のデータの損失が防がれ、情報共有が促進されます。
Versioning through codification
コード化されたプロセスはマシンにより実行可能で、運用者にも可読性があります。コード化されたプロセスの自動化はシステム変更のオーバヘッドを減少させ、人的ミスを削減します。
Automation through Codification
高いレベルの信頼性を達成するために、予想外の入出力に耐えられるシステムが必要です。その目には望ましい状態を把握しておくこと、現在の状態を収集する手段、望ましくな状態になった際に復旧する手段が必要です。
Resilient Systems
問題を解決するのは実用主義であるという点が重要です。HashiCorp道で記載する様々な原理は理想であり目指しているものでありますが、独善的に自らに強制する者でありません。そのために実用的な製品開発のためには再評価を行うこともあります。
Pragmatism
The Tao of HashiCorp
Evolving application workload delivery
Challenge
複数のクラウド環境へ一貫性のある方法でどのようにアプリケーションをデリバリするか？
従来のアプリケーション環境
クラウドにおけるアプリケーション環境
StaticからDynamicな環境へ
専用のインフラへデプロイ
インフラのプールへ
オンデマンドにスケジューリング
ホストベースの静的IPでのサービス間通信
サービスベースの動的IPでのサービス間通信
信頼性の高いネットワーク境界によるセキュリティ
信頼性の低いネットワーク上のIdentityベースのセキュリティ
専有のインフラを準備
オンデマンドにインフラを準備
HashiCorp ソリューション
異なる環境間の差異を吸収し、一貫性のあるワークフローを実現
Infrastructure
Automation
Security Automation
Networking Automation
Application
Automation
エンタープライズ版を選定する価値
Provision
Connect
Secure
Run
サービス、プラットフォーム、ビジネスを支えるツール群
Business Application
Observability
Data
Multi Cloud
お客様
製品フィードバック
技術支援
Business Value
フォーカスしたいエリア
重要だがリソースを
かけたくないエリア
Networking
Connect infrastructure and applications
Development
Run applications
Security
Secure applications and infrastructure
Operations
Provision Infrastructure
The 4 essential elements of dynamic infrastructure
THE HASHICORP STACK
10
© 2018 HashiCorp
Connect
Consul
Run
Deploy applications
Secure
Vault
Provision
Terraform
The 4 essential elements of dynamic infrastructure
2015
プロダクトローンチ
280+
コントリビュータ
4.7K+
GitHub スター
20K+
月間ダウンロード
17+
顧客数
About�Nomad�
LOREM IPSUM DOLOR SIT AMET ULLAM
12
© 2019 HashiCorp
Nomadによるオーケストレーション
従来の運用
Nomadによるオーケストレーション
オーケストレーションツールが多機能で
運用や学習コストが高い
一貫したツールでシンプルなサービスメッシュを提供しセキュリティや運用コストの肥大化を抑える
Orchestrate Any Application
幅広いエコシステムとの連携
Nomad Core Use Cases
First-class for Containers
軽量なアーキテクチャかつ最小限の運用オーバーヘッドでコンテナのオーケストレーションを実現
Non Containerized Apps
Java(JAR)やホストOSで実行可能なバイナリに対応。コンテナ化されていないワークロードも各OSの機能を利用して分離
Microservices Deployments
Consulとの高度な連携によりサービスディスカバリを含んだService Meshを実現
Batch Processing Workloads
ジョブのスケジューリングやコンカレントラスケジューラを内包。Sparkなどとネイティブに連携も可能
Nomad Core Use Cases
Elastic Scalability
軽量なアーキテクチャでスケールの速度が速く、かつオーケストレーションにおいては同等の機能を提供
Multi Region & Cloud
最小限の作業で環境の構築が可能なため、複数クラウドや他リージョンへの展開が容易
GPU Support
NVIDIAなどマルチベンダーのGPUをサポートし、AIやマシンラーニングのワークロードに対応
Stateful Workloads
様々なストレージが利用可能でデータベースなどのステーフルワークロードにも対応
Nomad Workflow
User
Nomad
Servers
Submits
Job
Nomad
Clients
Deploy App
Skip (Busy)
job "my_job" {
datacenters = ["us-west-1", “us-east-1"]
type = "service"
group "web" {
count = 5
task "frontend" {
driver = "docker"
config { image = "hashicorp/web-frontend" }
resources {
cpu = 500 # MHz
memory = 128 # MB
network {
mbits = 100
}}
my_app.nomad
宣言的なJobの仕様定義
job
group
task
Operating Systems
Workloads
Drivers
Windows |
Linux |
BSD |
Solaris |
Long Running Service |
Short Lived Batch |
Periodic Cron |
System Agents |
Docker / Rkt / LXC |
Qemu / KVM |
“exec”�cgroups+chroot |
Static Binaries / �Fat JARs |
Job Specification
job "my_job" {
datacenters = ["us-west-1", “us-east-1"]
type = "service"
group "web" {
count = 5
task "frontend" {
driver = "docker"
config { image = "hashicorp/web-frontend" }
resources {
cpu = 500 # MHz
memory = 128 # MB
network {
mbits = 100
}}
パラメータ | 内容 |
Region, Datacenters | Jobを稼働させるリージョン、 リージョン内のAZ等の区分け |
Job Type | Service / Batch / System |
Group | デプロイされるタスクグループ |
Task | 実際のワークロード |
Driver | Docker / Standalone Web / Batch などの アプリタイプ |
Resources | ハードウェアリソース |
my_app.nomad
Workloads
Updating Jobs
job “my_job” {
update {
max_parallel = 3
health_check = "checks"
min_healthy_time = "10s"
healthy_deadline = "10m"
auto_revert = true
canary = 1
stagger = "30s"
}
}
my_app.nomad
A First-class for HashiStack Workflow
job “my_job" {
group "example" {
task "server" {
service {
tags = ["leader", "mysql"]
port = “db"
check {
type = "script"
name = "check_table"
command = “./check_mysql_table_status"
args = ["--verbose"]
interval = "60s"
timeout = “5s"
}
template {
source = "local/redis.conf.tpl"
destination = "local/redis.conf"
change_mode = "signal"
change_signal = "SIGINT"
}
vault {
policies = ["cdn", "frontend"]
change_mode = "signal"
change_signal = "SIGUSR" }
my_app.nomad
Nomad Enterprise
機能名 | 概要 |
Automated Upgrades | Nomadサーバの無停止ローリングアップデートを自動化 |
Enhanced Read Scalability | 負荷の高い、クラスタ内のリーダーを決めるConsensusには参加せず、リードの処理のみを行うインスタンス(Non-voting server)を用意してスケールアウトさせる |
Redundancy Zones | Non-voting serverを各AZに構築し、Readの処理を分散しつつ、Voting serverが落ちたらNon- votingをVotingに昇格する |
Namespaces | マルチテナンシー対応 |
Resource Quotas | ネームスペースごとに利用可能なリソースを制限 |
Sentinel Policies | Sentinelによるポリシーの設定 |
Preemption | 先取権 |
HashiCorp Support |
|
Enhanced Read Scalability
→スケールアウトのコストが増える
Non-voting
Nomad Server
Non-voting
Nomad Server
Follower
Nomad Server
Leader
Nomad Server
Follower
Nomad Server
Automated Upgrades
Redundancy Zones
Follower
Nomad Server
Leader
Nomad Server
Leader
Nomad Server
Non-voting
Nomad Server
Non-voting
Nomad Server
Non-voting
Nomad Server
AZ-1
AZ-2
AZ-3
Namespaces & Resource Quotas
Sentinel Policies
Preemption (先取権)