インフラ自動化とhashicorp tools
TRANSCRIPT
Webエンジニア念能力…> フロントエンド > アプリケーション > ミドルウェア/アーキテクト > インフラ > (開発手法、QA)
http://udzura.hatenablog.jp/entry/2013/03/04/114728
インフラ系技術の流れ> “最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。(英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。)”
http://mizzy.org/blog/2013/10/29/1/
Webエンジニア念能力…> フロントエンド > アプリケーション > ミドルウェア/アーキテクト > インフラ > (開発手法、QA)
http://udzura.hatenablog.jp/entry/2013/03/04/114728
このへんで!
Hashicorpとは?> Vagrant、Packer、Serf、Consulの作者、ミッシェル=ハシモト氏により立ち上げられたスタートアップ
> 様々なインフラ運用・開発を “revolutionizing” するための企業
> 具体的には様々なツール(OSS)の開発とそのサポートをしている
Hashicorpとは?> “The Tao of HashiCorp”
> https://hashicorp.com/blog/tao-of-hashicorp.html
参考> Hashicorpのツール群とオーケストレーション > http://www.slideshare.net/zembutsu/hashicorp-orchestration-tools-introduction
自分とHashicorp tools> 自分の好きなこと > DSLを設計したり書いたりする > プラグインを作ったり公開する > ピタゴラスイッチ
Hashitoolっぽい
Hashitoolっぽい
めちゃくちゃ Hashitoolっぽい!!
最近のHashitool事例> Consulと自作OSSを活用した100台規模のWebサービス運用 > “「Consulってこんなに一般化してたのか」的な感想をちらほら見かけるのですが、これはおそらく世間的には全然そんなことはないんじゃないですかね…”
http://sfujiwara.hatenablog.com/entry/2015/08/23/173803
最近のHashitool事例> 我々はどのように冗長化を失敗したのか
http://blog.kenjiskywalker.org/blog/2015/08/22/yapcasia2015/https://twitter.com/kenjiskywalker/status/635659731550408704
最近のHashitool事例> 3分でサービスのOSを入れ替える技術 > “愚直に経験があるもの、評価済みのものをひたすら組み合わせることで、システムアーキテクチャも魔法のようなことを実現できる”
http://yapcasia.org/2015/talk/show/4f85e87a-f9ec-11e4-8262-8ab37d574c3a
最近のHashitool事例> #hashi_wantedly > Working With Terraform > “Terraform + GitHub + CircleCI + Atlas” > “インフラの変更をGitHubのMergeボタンに集約出来る”
http://blog.glidenote.com/blog/2015/02/18/terraform-github-circleci-atlas-aws/
https://speakerdeck.com/glidenote/working-with-terraform
Vagrant> おなじみ > DSLで開発用VM立ち上げるやつ
> VirualBoxベースのことが多いけど、VMWare、kvm、DigitalOcianなどいろいろバックエンドがあったりする
DSL度 ⭐⭐⭐⭐⭐
プラガブル度 ⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐
Packer> あらゆる種類の「イメージを作る」
> もともと、VB用の イメージを作るVeeWeeの代用としての紹介が多かったが、実際には、AMI、qemu imageその他いろいろと作れる
> イメージを作る手順も共有できたりする
DSL度 ⭐⭐⭐
プラガブル度 ⭐⭐⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐
Terraform> 複数のサーバ構成をある状態に収束させるツールとDSL
> Puppet/Chefなど構成管理ツールが、1台のサーバをある状態に収束させるツールであることの連想
> みんな主にAWSで使ってるので、CloudFormationのあのJSONよりはいいんだなと思う
DSL度 ⭐⭐⭐⭐
プラガブル度 ⭐⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐⭐⭐
Serf> クラスタ管理ツール > サーバがクラスタに 追加、抜けるなどのタイミングで、任意の処理を実行したりする
> マスターレス > Orchestration(とgossip protocol)の単語を有名にした最初のツール
DSL度 ⭐
プラガブル度 ⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐⭐⭐⭐
Consul> クラスタ管理ツール(2) > Serfとかぶってるどころか内部でSerf利用
> Serfとは、各サーバでエージェントとして動いている点、ヘルスチェックによるサービスディスカバリを基本にしている点が大きな違い。また、簡易KVSも用意
> see: Raft Algorithm
DSL度 ⭐⭐
プラガブル度 ⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐⭐⭐⭐
Vault> 期待の新人 > センシティブな情報を安全に管理、共有、そして監査する
> githubなどのアカウントチームを、Vault上の権限とひも付けて、そしてMySQLやらConsulやらといい感じに連携
DSL度 ⭐⭐⭐
プラガブル度 ⭐⭐⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐⭐
Atlas> ここまで紹介した各種ツールを横軸でまとめるウェブサービス
> ごめんな、これだけOSSとちゃうんや。SaaSなんやで。 > いまのところConsulの中央サーバ、Vagrant BOXの置き場所などの用途。SaaSとしての安定性も含め、利用シーンは未知数なところが多い。UIもまだ渋い……
DSL度 ?
プラガブル度 ?
ピタゴラスイッチ度 ?
https://www.hashicorp.com/blog/atlas-artifact-pipeline.html
http://www.slideshare.net/hsbt/advanced-technic-for-os-upgrading-in-3-minutes
http://udzura.hatenablog.jp/entry/2015/03/20/192619
Nyahについて> ネットワークに癖がある > DHCPエージェントは使わない > metadataエージェントも使わない
> なのでこうする > 事前にport(仮想NIC)を作る > IP、MAC addressなどをuserdataを使って流し込んでネットにつなぐ
既存のopenstack builder> ネットワークに癖がある > DHCPエージェントは使わない > metadataエージェントも使わない
> なのでこうする > 事前にport(仮想NIC)を作る > IP、MAC addressなどをuserdataを使って流し込んでネットにつなぐ
こういうカスタマイズには対応していない!
Pluginの種類> Builder > プラットフォームごとのアダプター(AWS, Openstack, QEMUなど)
> Provisioner > 立ち上げたソースサーバに実際のプロビジョニングをしていく(Shell Script, Chef, Puppetなど)
> Post Processor > 後処理(docker builderならdockerhubにpushするとか)
方針> 既存のOpenStackプラグインの実装を参考にする、どんどんパチる
> Nyah固有の必要な処理だけ自分で書く > 先にPort用意して特別なuserdataを流すとこだけ書けばいい、はず。そのはずなんだ
最低限のルール> 以下を満たすインターフェース
> これが処理のエントリポイントになる
type Builder interface { Prepare(...interface{}) error Run(ui Ui, hook Hook, cache Cache) (Artifact, error) Cancel() }
それぞれのフェ~ズPrepare(...interface{}) error
> 準備。主に、設定を読み込む。 > このフェーズでサーバはいじるべきではないとのこと Run(ui Ui, hook Hook, cache Cache) (Artifact, error)
> 実際のサーバ立ち上げ処理。詳細後述 Cancel()
> キャンセル時/失敗時/正常終了時全部で呼ばれる後処理。名前……
Runの中身> Run(ui Ui, hook Hook, cache Cache) (Artifact, error)
> packer.Artifactも、またインタフェース
> https://github.com/mitchellh/packer/blob/master/packer/artifact.go という便利ドキュメントを読んで頑張る(サーバIDとかそういう情報を返せば良いとのこと)
この辺をいじれば良さそう> キーペア登録 > サーバ立ち上げ > Floating IPの割り当て > SSH接続、操作 > 終了処理 > イメージ作成
portの作成を事前にする
portの情報から 適切なuserdataを 作った上で立ち上げ
Floating IP は使わない (portにIP情報がある)
mitchellh/mapstructure> 「賢いJSON」 > JSONのパーサライブラリ > 現実的なユースケースに色々対応していてコードがスッキリする
https://github.com/mitchellh/mapstructure
gophercloud> Goライブラリのデファクトスタンダード > Rackspace社で保守 > APIは結構……あれだけど活発な開発 > 以前別のクライアントで使って、経験があった
https://github.com/rackspace/gophercloud
そして足りない機能がある…………> サーバ立ち上げ時に、「ネットワークID」じゃなくて「ポートID」を指定する必要がある
> forkされた段階のgophercloudには未実装$ nova help boot --nic <net-id=net-uuid,v4-fixed-ip=ip-addr,v6-fixed-ip=ip-addr,port-id=port-uuid> Create a NIC on the server. Specify option multiple times to create multiple NICs. net- id: attach NIC to network with this UUID (either port-id or net-id must be provided), v4-fixed-ip: IPv4 fixed address for NIC (optional), v6-fixed-ip: IPv6 fixed address for NIC (optional), port-id: attach NIC to port with this UUID (either port-id or net-id
$ go test ./... # git.***.***/tech/packer-builder-nyah ../../../../.go/src/git.***.***/tech/packer-builder-nyah/builder.go:75: cannot use auth (type "github.com/mitchellh/gophercloud-fork-40444fb".AccessProvider) as type "github.com/udzura/gophercloud-fork-9419da4".AccessProvider in argument to "github.com/udzura/gophercloud-fork-9419da4".Server: "github.com/mitchellh/gophercloud-fork-40444fb".AccessProvider does not implement "github.com/udzura/gophercloud-fork-9419da4".AccessProvider (wrong type for FirstEndpointUrlByCriteria method) have FirstEndpointUrlByCriteria("github.com/mitchellh/gophercloud-fork-40444fb".ApiCriteria) string want FirstEndpointUrlByCriteria("github.com/udzura/gophercloud-fork-9419da4".ApiCriteria) string
どうしたか?> godepの導入 > packerの、動いている段階のビルドを探して………………………………………………………………………………………………………………………………………………………………………
> fork
得られた教訓> 容赦なくupstreamが変わる、それがGoの世界 > とくに、packerは別にもとから外部向けのライブラリではなく、たまたまいい具合にパッケージが分かれていたのを使っただけなので、仕方なさがある
> 運用で使うようになったらgodeps > しかしGoは型があるので便利 > いざとなったらとにかくコンパイルエラーを直し、なんとかする
> CIしようぜ!!! > すぐ気づける
おまけ> Provisioner Pluginも作ってみた > https://github.com/udzura/packer-provisioner-serverspec
> 同じように、インタフェースを合わせれば良い。便利 > 詳細はコードで!
http://www.slideshare.net/hsbt/advanced-technic-for-os-upgrading-in-3-minutes
サーバをカジュアルに増やす> from 12 facter app > V. Build, release, run > Strictly separate build and run stages
> IX. Disposability > Maximize robustness with fast startup and graceful shutdown
メモリをガツッと確保する> Consul makes use of LMDB internally for various data storage purposes. LMDB relies on using memory-mapping, a technique in which a sparse file is represented as a contiguous range of memory.
> vm.overcommit_memory=2 だったので、落ちた > ※ 0.5.0では vm.overcommit_memory=2 でも落ちなくなっていた
https://www.consul.io/docs/faq.html
めちゃくちゃ不安定……> いろいろいじった結果、UDPのポート8301 をお互いに許可していなかった。。。。。。
> 開けたら安定した > 使うポート/プロトコルは↓
https://www.consul.io/docs/agent/options.html
CPU 1個のインスタンスだと……> consulは、 GOMAXPROCS=2 以上の設定を強く推奨している
> GOMAXPROCS=1、またはCPU 1個だとパフォーマンスで問題が起こる
> 1個のものは、CPU2個以上で、作り直した
“https://groups.google.com/forum/#!msg/consul-tool/qewFEqgAoF8/b9hxhmy1v6gJ
“The reason we recommend setting GOMAXPROCS is to avoid potential starvation of the scheduler. The Go runtime uses green threads (M:N). If a single goroutine blocks the scheduler (via cgo for example) it can cause degraded performance. Having another kernel thread available helps to
mitigate those issues.”
方針> ドメインを minne.lan とかにする > dnsmasq を全台に導入 > *.node.minne.lan は dnsmasq からlocalhost:8600にフォワード、各サーバでは127.0.0.1をリゾルバに
Consulが撃沈したり……> DNS APIは、リーダーがいないと叩けない > 一時的にリーダーがいなくなるタイミングとかはどうしてもあるので
> dnsmasqの設定にしてしまってキャッシュしておく
これを5分ごとに実行CACHE_TMP=/tmp/consul-cns-cache.$$ TARGET=/etc/dnsmasq.d/999-nodes-cache.conf set -e set -o pipefail
curl -s localhost:8500/v1/catalog/nodes \ | jq -r "map(\"address=/\(.Node).node.minne.lan/\(.Address)\")[]" \ > $CACHE_TMP cp -af $CACHE_TMP $TARGET systemctl restart dnsmasq
set -e してるので、 consul自体が使えないときはそもそも
キャッシュが上書きされないようにしている
テンプレートを書くupstream rails_apps { {{range service "sandbox-front.nginx@nyah" "passing"}} server {{.Address}}:80;{{end}} }
server { listen 80; # server_name minne.com api.minne.com; server_name _
proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host;
location / { proxy_pass http://rails_apps; } }
sandbox-frontというタグのついたnginxのチェックのうち 正常(passing)のものを監視する
consul-templateの良さ> 仕組み自体は理解できれば割とシンプル > チェック項目、フックなどのカスタマイズがわかりやすい
> フロントのNginx自体には、何の手も加えていない > そのため、本来のNginxのパフォーマンスが出るし、チューニング等も特別なことはない
きょうびのWeb開発> バンバンバージョンアップされる > Railsが有名だが、PHPも激しいし、フロントエンド界隈、nodejs、Go、Docker、iOS/Android開発……
> どんどん変わっていく > 動き続けないと、古くなる > 古くなると動きが遅くなる。どこかで、新しいことができなくなる
どうすればいいの?> Webに関わるソフトウェアの大きな潮流は、動き続ける、変わり続けることに舵を切っている
> 運用エンジニア・インフラエンジニアもこの潮流を全く無視することはできないのではないだろうか?
cf. バスタブ曲線
https://ja.wikipedia.org/wiki/%E6%95%85%E9%9A%9C%E7%8E%87%E6%9B%B2%E7%B7%9A
レイヤ分け> ミドルウェアの3分類 > 日常の作業のツール > 運用のためのデーモン > ユーザに直接関わるデーモン
> 上の2つについては、新しいものを試しやすく、切り戻しも比較的容易
Vagrant, Packer, TerraformConsul, Serf, Vault
(consul-template)
Hashicorp toolsの考え方> ツール自体が大変近代的な開発 > githubでオープンに開発 > テストコード、CI完備
> Codification=設定は必ずコードになる > 設定変更を履歴管理ことを強く推奨する
> Go言語を選択し、コードも綺麗 > 導入時の安定性
インフラCIをはじめとした、テスト> テストを、それも自動でする時代 > Serverspec、Infrataster > Dockerなどによるインフラのコンポネント化 > 「責務を小さく」することでのテスト容易性
> ミドルウェアにも洗練されたテストコード > Hashicorp toolsはテスト、開発のオープンさを重視している
> なにより、監視 > 最近はmackerelのようなサービスもある
cf. サーバ開発自体のモダン化> 検証環境を作るコストが格段に下がっている > AWSをはじめとしたクラウドのコモディティ化 > 構成管理ツール(Chef/Puppet/…)の普及 > Vagrantの出現 > コンテナ仮想化のブーム
> その気になればステージングを丸ごともうひとつ > (そこでterraform?)
「新しい」ことのアドバンテージ> モダンなOSS開発手法 > モダンなツール、言語、環境 > →ソフトウェア自体の質が向上している > このアドバンテージが「枯れているが、保守されていないミドルウェア」に勝る時代になってきているのではないか
目的をはっきりさせる> ゴールデンイメージを作る手順を完全にコード化したい > →Packerを使う
> 動的な監視を、まずは実現したい(それ以上のことはおいおいでもいい) > →Consulを使う
> 達成できない、とわかったらちゃんと引き返す
既存のツールでいいときは冒険しない> 例えば: > サービスが落ちたのをconsulでチェック→落ちたことをフックにconsul watchでサービス再起動→ やった!自動再起動できた!
> それ、monitでできるよ……
ちゃんと2つ以上の何かを減らせるか?> 小さな、かつ新規性のあるツールを選ぶ > “何か新しいものを1つ入れるときは既存の何かを2つ以上減らせること” > http://myfinder.hatenablog.com/entry/2015/03/27/141416
Hashicorp toolsは> 新しい概念(=非連続性)でOpsの問題を解決するツール > 実際に、イメージ作成の簡易化、機密情報の管理、サービスディスカバリ、動的設定変更など、これまで難しいとされてきた課題に答えを出しつつある
> しかも、非常にオープンなツールで使いやすい
ペパボにはHashitoolsを使う仕事があります
> 福岡でもインフラ絶賛募集! > ペパランチョンでお話を。 > https://pepabo.com/recruit/pepaluncheon/?fukuoka
画像ソース> タイトル写真
> https://commons.wikimedia.org/wiki/File:Kings_Cross_Train_Station_London_England.jpg