インフラ自動化とHashicorp tools

GMO Pepabo, Inc. UCHIO KONDO2015/09/26 HackerTackle

インフラ自動化とHashicorp tools

me

近藤うちお> GMOペパボ > 技術基盤チーム > 福岡支社勤務

東三河出身> 大学入学とともに東京へ > 2013年から福岡 > 名古屋じゃないに～ この辺

興味> Ruby / Golangを少々 > Puppet / Docker / Hashicorp tools > OpenStack

7 years old Rubyist> Rails 2.1.0 ごろからのルビースト(2008 ~) > Rubyをこじらせて著作あり

松江遠征（予定）

スタバの数で圧倒してきます！

いままで> 新卒入社の最初の2年ぐらい社内SE > その後はずっと 開発系な人 > （自社サービスの会社にしかいたことがない）

ペパボで> 技術基盤チームに所属 > Puppetなどを書いたり > サーバ追加や監視をしたりしていた > でも一度も「インフラエンジニアになるぞ～」と思ったことはない…

インフラってなんだ？

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

このへんで！

今日はあえて DevOpsって言わない

しかも今日はずっと OSより上、ミドルウェアの話ですね

……

Hashicorp tools

Hashicorpとは？> Vagrant、Packer、Serf、Consulの作者、ミッシェル=ハシモト氏により立ち上げられたスタートアップ

> 様々なインフラ運用・開発を “revolutionizing” するための企業

> 具体的には様々なツール（OSS）の開発とそのサポートをしている

Hashicorpとは？> “The Tao of HashiCorp”

> https://hashicorp.com/blog/tao-of-hashicorp.html

Workflows, not Technologies

Simple, Modular, Composable

Codification, Codification, Codification

Codification = Code + ify + ation

参考> Hashicorpのツール群とオーケストレーション > http://www.slideshare.net/zembutsu/hashicorp-orchestration-tools-introduction

自分とHashicorp tools> 自分の好きなこと > DSLを設計したり書いたりする > プラグインを作ったり公開する > ピタゴラスイッチ

自分とHashicorp tools> 自分の好きなこと > DSLを設計したり書いたりする > プラグインを作ったり公開する > ピタゴラスイッチ

Hashitoolっぽい

Hashitoolっぽい

めちゃくちゃ Hashitoolっぽい！！

最近のHashitool事例> 先日のYAPCなどからいくつか

最近の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

からの

toolsのご紹介 （独断と偏見ver.）

DSL度 ⭐⭐⭐⭐⭐

プラガブル度 ⭐⭐⭐

ピタゴラスイッチ度 ⭐⭐

Vagrant

Vagrant> おなじみ > DSLで開発用VM立ち上げるやつ

> VirualBoxベースのことが多いけど、VMWare、kvm、DigitalOcianなどいろいろバックエンドがあったりする

DSL度 ⭐⭐⭐⭐⭐

プラガブル度 ⭐⭐⭐

ピタゴラスイッチ度 ⭐⭐

Packer

Packer> あらゆる種類の「イメージを作る」

> もともと、VB用の イメージを作るVeeWeeの代用としての紹介が多かったが、実際には、AMI、qemu imageその他いろいろと作れる

> イメージを作る手順も共有できたりする

DSL度 ⭐⭐⭐

プラガブル度 ⭐⭐⭐⭐⭐

ピタゴラスイッチ度 ⭐⭐

Terraform

Terraform> 複数のサーバ構成をある状態に収束させるツールとDSL

> Puppet/Chefなど構成管理ツールが、１台のサーバをある状態に収束させるツールであることの連想

> みんな主にAWSで使ってるので、CloudFormationのあのJSONよりはいいんだなと思う

DSL度 ⭐⭐⭐⭐

プラガブル度 ⭐⭐⭐⭐

ピタゴラスイッチ度 ⭐⭐⭐⭐

Serf

Serf> クラスタ管理ツール > サーバがクラスタに 追加、抜けるなどのタイミングで、任意の処理を実行したりする

> マスターレス > Orchestration（とgossip protocol）の単語を有名にした最初のツール

DSL度 ⭐

プラガブル度 ⭐⭐⭐

ピタゴラスイッチ度 ⭐⭐⭐⭐⭐

Consul

Consul> クラスタ管理ツール(2) > Serfとかぶってるどころか内部でSerf利用

> Serfとは、各サーバでエージェントとして動いている点、ヘルスチェックによるサービスディスカバリを基本にしている点が大きな違い。また、簡易KVSも用意

> see: Raft Algorithm

DSL度 ⭐⭐

プラガブル度 ⭐⭐⭐

ピタゴラスイッチ度 ⭐⭐⭐⭐⭐

Vault

Vault> 期待の新人 > センシティブな情報を安全に管理、共有、そして監査する

> githubなどのアカウントチームを、Vault上の権限とひも付けて、そしてMySQLやらConsulやらといい感じに連携

DSL度 ⭐⭐⭐

プラガブル度 ⭐⭐⭐⭐⭐

ピタゴラスイッチ度 ⭐⭐⭐

Atlas

Atlas> ここまで紹介した各種ツールを横軸でまとめるウェブサービス

> ごめんな、これだけOSSとちゃうんや。SaaSなんやで。 > いまのところConsulの中央サーバ、Vagrant BOXの置き場所などの用途。SaaSとしての安定性も含め、利用シーンは未知数なところが多い。UIもまだ渋い……

DSL度 ？

プラガブル度 ？

ピタゴラスイッチ度 ？

To Be Continued?

Artifact Pipeline

https://www.hashicorp.com/blog/atlas-artifact-pipeline.html

事例紹介

Packerのプラグインを書いた話

Packer

Packer

http://www.slideshare.net/hsbt/advanced-technic-for-os-upgrading-in-3-minutes

Do scale-out

#3分で スケールアウト

http://udzura.hatenablog.jp/entry/2015/03/20/192619

やりました

Packer で、 やりました

じゃあ、それをOpenStackでも

Nyahについて> ネットワークに癖がある > DHCPエージェントは使わない > metadataエージェントも使わない

> なのでこうする > 事前にport（仮想NIC）を作る > IP、MAC addressなどをuserdataを使って流し込んでネットにつなぐ

既存のopenstack builder> ネットワークに癖がある > DHCPエージェントは使わない > metadataエージェントも使わない

> なのでこうする > 事前にport（仮想NIC）を作る > IP、MAC addressなどをuserdataを使って流し込んでネットにつなぐ

こういうカスタマイズには対応していない！

じゃあどうしよう

packer-builder-nyah

Packerプラグインの 作り方

Pluginの種類> Builder > プラットフォームごとのアダプター（AWS, Openstack, QEMUなど）

> Provisioner > 立ち上げたソースサーバに実際のプロビジョニングをしていく（Shell Script, Chef, Puppetなど）

> Post Processor > 後処理（docker builderならdockerhubにpushするとか）

今回必要なのは Builder Plugin

方針> 既存のOpenStackプラグインの実装を参考にする、どんどんパチる

> Nyah固有の必要な処理だけ自分で書く > 先にPort用意して特別なuserdataを流すとこだけ書けばいい、はず。そのはずなんだ

How to write

最低限のルール> 以下を満たすインターフェース

> これが処理のエントリポイントになる

type Builder interface { Prepare(...interface{}) error Run(ui Ui, hook Hook, cache Cache) (Artifact, error) Cancel() }

Builder typeを> これをコマンドのエントリポイントにして > 普通にビルドすれば良い > 利用するには、packer-builder-nyah という名前のバイナリにしPATHを通す

それぞれのフェ～ズ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とかそういう情報を返せば良いとのこと）

まずは> ビルドが > できる > とこまで…うう

いよいよ、Run()の 中身を書く

Run() 既存実装の詳細> キーペア登録 > サーバ立ち上げ > Floating IPの割り当て > SSH接続、操作 > 終了処理 > イメージ作成

この辺をいじれば良さそう> キーペア登録 > サーバ立ち上げ > Floating IPの割り当て > SSH接続、操作 > 終了処理 > イメージ作成

portの作成を事前にする

portの情報から 適切なuserdataを 作った上で立ち上げ

Floating IP は使わない (portにIP情報がある)

Goを書くぞ

mitchellh/multistep> Step構造体を定義してそれを並べるだけ

> Stepの再利用できる > やることが、Stepという単位で分割される

mitchellh/mapstructure> 「賢いJSON」 > JSONのパーサライブラリ > 現実的なユースケースに色々対応していてコードがスッキリする

https://github.com/mitchellh/mapstructure

gophercloud> Goライブラリのデファクトスタンダード > Rackspace社で保守 > APIは結構……あれだけど活発な開発 > 以前別のクライアントで使って、経験があった

https://github.com/rackspace/gophercloud

ロゴが良い（...）

さて、どんな感じか中身を見てみよう…

fork………?????

諸事情でforkされていた。。。だと

michellさん「Wow!」

そして足りない機能がある…………> サーバ立ち上げ時に、「ネットワーク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

forkをfork

$ 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

パッケージ名が合わない！> ミスマッチの対応のためのバッドノウハウ > ミスマッチするところは、そのimport文だけを変えた形で本家からコピーして配置しておく

いろいろなYakを狩りまくり 最終的には……動いた！

そしてNヶ月が過ぎた

またまた～

突然の ＿人人人人人人人人人人＿ ＞　upstream変更　＜ ‾Y^Y^Y^Y^Y^Y^Y‾

どうしたか？> godepの導入 > packerの、動いている段階のビルドを探して………………………………………………………………………………………………………………………………………………………………………

> fork

得られた教訓> 容赦なくupstreamが変わる、それがGoの世界 > とくに、packerは別にもとから外部向けのライブラリではなく、たまたまいい具合にパッケージが分かれていたのを使っただけなので、仕方なさがある

> 運用で使うようになったらgodeps > しかしGoは型があるので便利 > いざとなったらとにかくコンパイルエラーを直し、なんとかする

> CIしようぜ！！！ > すぐ気づける

おまけ> Provisioner Pluginも作ってみた > https://github.com/udzura/packer-provisioner-serverspec

> 同じように、インタフェースを合わせれば良い。便利 > 詳細はコードで！

Consulをバーンと入れた話

http://www.slideshare.net/hsbt/advanced-technic-for-os-upgrading-in-3-minutes

Do scale-out

#3分で スケールアウト

大事なことなので２回ｒｙ

サーバをカジュアルに増やす> from 12 facter app > V. Build, release, run > Strictly separate build and run stages

> IX. Disposability > Maximize robustness with fast startup and graceful shutdown

監視についても> Runしたら、自動で監視対象になってほしい > Terminateしたら、勝手に外れてほしい > イメージから立ち上げたはいいけど、アプリが正常に動いていることを何かしら確認したい

Consul

Consul の機能> クラスタリング、ヘルスチェック > Web UI を公式に用意している > consul-alerts なんかで通知もできる

検証する価値はありそう

インストールして立ち上げてみた

何これ怖い

vm.overcommit_memory=0

おおう……

strace

32 GB+ 8 GB

メモリをガツッと確保する> 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

よっしゃ導入OK！

それから数週間後

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.”

Tips: VirtualBoxで試すとき> IO/APIC を有効にしないとダメです

> Vagrantなら以下の感じ

そんなこんなで 安定運用（？）

できなかったことが できるようになる

内部DNS

OpenStackの内部DNS> 結構悩んでいた > DHCP agentは使えないし、自分でDDNS？うえ～

> APIを叩いてhostsを定期更新、とかも手。 だが……

DNS INTERFACE

方針> ドメインを 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自体が使えないときはそもそも

キャッシュが上書きされないようにしている

便利> クラスタにジョインしたら、すぐに内部の名前でSSHできるようになった！

> ConsulのAPIはめっちゃ軽いので良い

副産物> 踏み台+内部DNS+peco+Consul APIにより便利ログイン君ができて便利になった

動的LB

ELB的なやつにほしい要素> 動的なメンバー追加、削除 > 自動的なヘルスチェック > 高い可用性

consul-template

consul-templateで> 動的なメンバー追加、削除 > 自動的なヘルスチェック > この二つは実現できるぞ！

consul-templateの仕組み

LB

www

www

www

フロントLBもNginxとする。 全台、consulのクラスタに

ジョインする

consul-templateの仕組み

LB

www

www

www

たとえばバックエンドのプロセス （NginxならNginx） に特定のタグを加えて

Consulのチェックを追加する

JSONの例

“sandbox-front” というタグを特別につけている

consul-templateの仕組み

LB

www

www

www

LB側では、「sandbox-front」 というタグに紐付いた

サービスの状態を監視している

テンプレートを書く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の仕組み

LB

www

www

www

たとえば、ここで１台の Nginxがダウンしたとする

💥

consul-templateの仕組み

LB

www

www

www

consul-template は、 nginxのfailedを検知する

💥

consul-templateの仕組み

LB

www

www

www

変更を検知して、 passingなメンバーのみで

ループを回し、 テンプレートを更新する

💥

consul-templateの良さ> 仕組み自体は理解できれば割とシンプル > チェック項目、フックなどのカスタマイズがわかりやすい

> フロントのNginx自体には、何の手も加えていない > そのため、本来のNginxのパフォーマンスが出るし、チューニング等も特別なことはない

制限事項> 最後に残った、LB自体の可用性は、普通にLVSなりkeepalivedなりに頼ることになります……。

> ここは地道に頑張っている

インフラ運用で 新規ツールを導入する意義

ここから ビッグ主語

運用と開発

きょうびのWeb開発> バンバンバージョンアップされる > Railsが有名だが、PHPも激しいし、フロントエンド界隈、nodejs、Go、Docker、iOS/Android開発……

> どんどん変わっていく > 動き続けないと、古くなる > 古くなると動きが遅くなる。どこかで、新しいことができなくなる

> 「運用とはユーザの価値を減らさないよう維持することだ」 > by haras⚪u5さん

> 重い言葉だと思う。ユーザが必ずしも変化を求めているか？

一方、運用とは？

なお、インフラエンジニアは死んだらしいぞ

どうすればいいの？> Webに関わるソフトウェアの大きな潮流は、動き続ける、変わり続けることに舵を切っている

> 運用エンジニア・インフラエンジニアもこの潮流を全く無視することはできないのではないだろうか？

リスクの例: 脆弱性

> 「変わらない」に舵を切った結果、CentOS 4 のサーバが残っていたらどうする？

変化を恐れない

動き続けるインフラ運用

変化を適切に恐れる

よく知られた事実> 新しくソフトウェアを書くと、

よく知られた事実> 新しくソフトウェアを書くと、 > バグが起こることがある！！！

cf. バスタブ曲線

https://ja.wikipedia.org/wiki/%E6%95%85%E9%9A%9C%E7%8E%87%E6%9B%B2%E7%B7%9A

一切ソフトウェアを書かなければ バグも起こらない

動くことにもリスクがある> なので、我々は、動くことのリスクを最小限にしないとならない

リスクを減らすには？

ここでやっと

Hashicorp

動き続けるインフラ運用になぜHashicorpが効くか

より運用者に近いレイヤ

レイヤ分け> ミドルウェアの3分類 > 日常の作業のツール > 運用のためのデーモン > ユーザに直接関わるデーモン

> 上の２つについては、新しいものを試しやすく、切り戻しも比較的容易

レイヤ分け> ミドルウェアの3分類 > 日常の作業のツール > 運用のためのデーモン > ユーザに直接関わるデーモン

> 上の２つについては、新しいものを試しやすく、切り戻しも比較的容易

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開発手法 > モダンなツール、言語、環境 > →ソフトウェア自体の質が向上している > このアドバンテージが「枯れているが、保守されていないミドルウェア」に勝る時代になってきているのではないか

TerraformのMakefile> CIのテスト、受入テスト、レースコンディションの検知テストが全部コマンド一発（らしい）

目的をはっきりさせる

目的をはっきりさせる> ゴールデンイメージを作る手順を完全にコード化したい > →Packerを使う

> 動的な監視を、まずは実現したい（それ以上のことはおいおいでもいい） > →Consulを使う

> 達成できない、とわかったらちゃんと引き返す

既存のツールでいいときは冒険しない> 例えば： > サービスが落ちたのをconsulでチェック→落ちたことをフックにconsul watchでサービス再起動→ やった！自動再起動できた！

> それ、monitでできるよ……

ちゃんと2つ以上の何かを減らせるか？> 小さな、かつ新規性のあるツールを選ぶ > “何か新しいものを1つ入れるときは既存の何かを2つ以上減らせること” > http://myfinder.hatenablog.com/entry/2015/03/27/141416

非連続性に挑戦する

連続性、非連続性> 普通の運用は連続的 > 枯れたツールを使う > 変化を避けていく > 手順を継承する

> 連続的に問題を解決することはめちゃくちゃ大事である！！

どこかで、非連続性がほしい> 今までに解決していない問題を解決しないといけない

> 非連続性への “投資” > Yak刈りの結果、どんな問題が解決するか？

非連続の先を見るために Yak刈りを厭わない

Hashicorp toolsは> 新しい概念（＝非連続性）でOpsの問題を解決するツール > 実際に、イメージ作成の簡易化、機密情報の管理、サービスディスカバリ、動的設定変更など、これまで難しいとされてきた課題に答えを出しつつある

> しかも、非常にオープンなツールで使いやすい

総括

動き続けるために

動き続けるためのバランス> むやみな破壊をしない > むやみに守らない > ちゃんとバリューを出せる見込みを持って攻め込んで行こう

Hashicorpツールから学ぶべきことは、ツール自体以上に、

たくさんあるかもしれない

[PR]

ペパボにはHashitoolsを使う仕事があります

> 福岡でもインフラ絶賛募集！ > ペパランチョンでお話を。 > https://pepabo.com/recruit/pepaluncheon/?fukuoka

画像ソース> タイトル写真

> https://commons.wikimedia.org/wiki/File:Kings_Cross_Train_Station_London_England.jpg