インフラ自動化とHashicorp tools

GMO Pepabo, Inc.
UCHIO KONDO2015/09/26 HackerTackle
インフラ自動化と 
Hashicorp tools

近藤うちお
> 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）
このへんで！

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

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

Hashicorpとは？
> Vagrant、Packer、Serf、Consulの作者、 
ミッシェル=ハシモト氏により立ち上げられた 
スタートアップ
> 様々なインフラ運用・開発を revolutionizing  
するための企業
> 具体的には様々なツール（OSS）の開発とその 
サポートをしている

Hashicorpとは？
> The Tao of HashiCorp
> https://hashicorp.com/blog/tao-of-hashicorp.html

Codification,
Codification, Codification

Codiﬁcation =
Code + ify + ation

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

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

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

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

> Consulと自作OSSを活用した100台規模の
Webサービス運用
> 「Consulってこんなに一般化してたのか」的な感想をち
らほら見かけるのですが、これはおそらく世間的には全然
そんなことはないんじゃないですかね…
http://sfujiwara.hatenablog.com/entry/2015/08/23/173803

> 我々はどのように冗長化を失敗したのか
http://blog.kenjiskywalker.org/blog/2015/08/22/yapcasia2015/
https://twitter.com/kenjiskywalker/status/635659731550408704

> 3分でサービスのOSを入れ替える技術
> 愚直に経験があるもの、評価済みのものをひたすら組み合
わせることで、システムアーキテクチャも魔法のようなこ
とを実現できる
http://yapcasia.org/2015/talk/show/4f85e87a-f9ec-11e4-8262-8ab37d574c3a

> #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
> おなじみ
> DSLで開発用VM 
立ち上げるやつ
> VirualBoxベースのことが多いけど、 
VMWare、kvm、DigitalOcianなどいろいろ
バックエンドがあったりする
DSL度 ⭐⭐⭐⭐⭐

Packer
> あらゆる種類の 
「イメージを作る」
> もともと、VB用の 
イメージを作るVeeWeeの代用としての紹介が多かっ
たが、実際には、AMI、qemu imageその他いろ
いろと作れる
> イメージを作る手順も共有できたりする
DSL度 ⭐⭐⭐
プラガブル度 ⭐⭐⭐⭐⭐

Terraform
> 複数のサーバ構成を 
ある状態に収束させる 
ツールとDSL
> Puppet/Chefなど構成管理ツールが、１台のサー
バをある状態に収束させるツールであることの連想
> みんな主に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

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

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

#3分でスケールアウト

じゃあ、それを
OpenStackでも

Nyahについて
> ネットワークに癖がある
> DHCPエージェントは使わない
> metadataエージェントも使わない
> なのでこうする
> 事前にport（仮想NIC）を作る
> IP、MAC addressなどをuserdataを使って流し込んで
ネットにつなぐ

既存のopenstack builder
> ネットワークに癖がある
> DHCPエージェントは使わない
> metadataエージェントも使わない
> なのでこうする
> 事前にport（仮想NIC）を作る
> IP、MAC addressなどをuserdataを使って流し込んで
ネットにつなぐ
こういうカスタマイズには
対応していない！

Packerプラグインの
作り方

Pluginの種類
> Builder
> プラットフォームごとのアダプター 
（AWS, Openstack, QEMUなど）
> Provisioner
> 立ち上げたソースサーバに実際のプロビジョニングをしていく 
（Shell Script, Chef, Puppetなど）
> Post Processor
> 後処理（docker builderならdockerhubにpushするとか）

今回必要なのは
Builder Plugin

方針
> 既存のOpenStackプラグインの実装を参考に
する、どんどんパチる
> Nyah固有の必要な処理だけ自分で書く
> 先にPort用意して特別なuserdataを流すとこ
だけ書けばいい、はず。そのはずなんだ

最低限のルール
> 以下を満たすインターフェース
> これが処理のエントリポイントになる
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情報がある)

mitchellh/multistep
> Step構造体を定義して 
それを並べるだけ
> Stepの再利用できる
> やることが、Stepという 
単位で分割される

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

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

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

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

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

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

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

突然の
＿人人人人人人人人人人＿
＞ 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を 
バーンと 
入れた話

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

サーバをカジュアルに増やす
> 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 の機能
> クラスタリング、ヘルスチェック
> Web UI を公式に用意している
> consul-alerts なんかで通知もできる

検証する価値はありそう

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

メモリをガツッと確保する
> Consul makes use of LMDB internally for various
data storage purposes. LMDB relies on using
memory-mapping, a technique in which a sparse
ﬁle 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.

Tips: VirtualBoxで試すとき
> IO/APIC を有効に 
しないとダメです
> Vagrantなら以下の感じ

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

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

OpenStackの内部DNS
> 結構悩んでいた
> DHCP agentは使えないし、自分でDDNS？ 
うえ∼
> APIを叩いてhostsを定期更新、とかも手。 
だが……

方針
> ドメインを 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により 
便利ログイン君ができて便利になった

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

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

consul-templateの仕組み
LB
www
www
www
フロントLBもNginxとする。
全台、consulのクラスタに
ジョインする

LB
www
www
www
たとえばバックエンドのプロセス
（NginxならNginx）
に特定のタグを加えて
Consulのチェックを追加する

JSONの例
sandbox-front というタグを特別につけている

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）のものを監視する

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

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

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が効くか

より運用者に近いレイヤ

レイヤ分け
> ミドルウェアの3分類
> 日常の作業のツール
> 運用のためのデーモン
> ユーザに直接関わるデーモン
> 上の２つについては、新しいものを試しやすく、
切り戻しも比較的容易

レイヤ分け
> ミドルウェアの3分類
> 日常の作業のツール
> 運用のためのデーモン
> ユーザに直接関わるデーモン
> 上の２つについては、新しいものを試しやすく、
切り戻しも比較的容易
Vagrant, Packer, Terraform
Consul, Serf, Vault
(consul-template)

ツール自体のモダンさ

Hashicorp toolsの考え方
> ツール自体が大変近代的な開発
> githubでオープンに開発
> テストコード、CI完備
> Codiﬁcation＝設定は必ずコードになる
> 設定変更を履歴管理ことを強く推奨する
> Go言語を選択し、コードも綺麗
> 導入時の安定性

インフラCIをはじめとした、テスト
> テストを、それも自動でする時代
> Serverspec、Infrataster
> Dockerなどによるインフラのコンポネント化
> 「責務を小さく」することでのテスト容易性
> ミドルウェアにも洗練されたテストコード
> Hashicorp toolsはテスト、開発のオープンさを重視している
> なにより、監視
> 最近はmackerelのようなサービスもある

cf. サーバ開発自体のモダン化
> 検証環境を作るコストが格段に下がっている
> AWSをはじめとしたクラウドのコモディティ化
> 構成管理ツール（Chef/Puppet/…）の普及
> Vagrantの出現
> コンテナ仮想化のブーム
> その気になればステージングを丸ごともうひとつ
> （そこでterraform？）

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

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

目的をはっきりさせる

目的をはっきりさせる
> ゴールデンイメージを作る手順を完全にコード化
したい
> →Packerを使う
> 動的な監視を、まずは実現したい 
（それ以上のことはおいおいでもいい）
> →Consulを使う
> 達成できない、とわかったらちゃんと引き返す

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

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

連続性、非連続性
> 普通の運用は連続的
> 枯れたツールを使う
> 変化を避けていく
> 手順を継承する
> 連続的に問題を解決することはめちゃくちゃ大
事である！！

どこかで、非連続性がほしい
> 今までに解決していない問題を解決しないとい
けない
> 非連続性への投資
> Yak刈りの結果、どんな問題が解決するか？

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

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

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

Hashicorpツールから学ぶべきことは、 
ツール自体以上に、 
たくさんあるかもしれない

ペパボにはHashitoolsを使う仕事があります
> 福岡でもインフラ絶賛募集！
> ペパランチョンでお話を。
> https://pepabo.com/recruit/pepaluncheon/?fukuoka

画像ソース
> タイトル写真
> https://commons.wikimedia.org/wiki/
File:Kings_Cross_Train_Station_London_England.jpg

インフラ自動化とHashicorp tools

More Related Content

インフラ自動化とHashicorp tools