Terraformのbackendを使いこなしたい

Terraformのworkspaceが結構わかってきたので、次はbackendを使いこなしたい。ということで、こちらもいろいろ動きを確認した。Terraformのバージョンは0.10.4。

単純にバックエンドを設定して使う

標準ではローカルにterraform.tfstateが生成されてそれを使うのだけど、S3のような場所に保存したいという場合がある。その時に使うのがバックエンド。backend.tfのようなファイルに定義を書くことで指定できる。

実際に有効にするには、terraform initコマンドを使う。ここではbucketやcredentialのパスをオプションで指定しているが、backend.tfに書いてもよい。

これを実行した後はS3上のrtak.tfstateが更新される。

workspaceを使う場合のバックエンドについて

stagingとproductionのように、workspaceを複数使う場合にバックエンドがどうなるのかを確認する。結論としては、tfstateのパスにworkspace名が含まれるようになり、別々に管理される。

これでapplyすると、env:/${workspace_name}/rtak.tfstateというファイルが追加される。

workspaceにproductionを追加すると以下のように、production用のディレクトリが追加されていることがわかる。

開発時にはlocal backendを使いたい

同じバックエンドでworkspaceによってtfstateが変わるということはわかった。しかし、開発時にゴリゴリ触るような場合、「r_takaishi-dev」 のような、個人用のworkspaceを用意して検証したいことがある。このとき、productionやstagingの場合はS3バックエンドを使い、それ以外ではlocal backendを使えると便利そうだ。そういうことが現時点でできるかどうか調べたが、どうやらできないようだった。需要があるかわからないが、Terraformに機能追加する形で実現したいか調べていきたい。

というところで終わってもつまらないので、若干ハック的になるが一時的にlocal backendを使うテクニックを記載しておく。

まず、backend.tfを編集し、backendをs3からlocalに変更する。

そして、terraform initを以下のように実行する。

backendがlocalになっていることがわかるだろうか。これでplanやapplyを実行すると、S3上のtfstateではなくローカルを見るようになる。使い終わったらdestroyすれば綺麗になるし、S3に不要なファイルも置かれない。

実際にこれをやるのはミスの元になりそうなので、workspace毎にbackendを切り替えられるようになるまではS3 backendを使う方がいい気はする。

Terraformのworkspaceを使いこなしたい

Terraformのworkspace(旧environment)について、いまいち理解しきれていない部分があったので整理しておくことにした。まずは普通にworkspaceを使った時にどのような動きになるのかを確認した。そして、応用としてworkspace毎に別のテナントを使ったり、workspaceによってリソースの名前を変えるというテクニックについて検証した。なお、Terraformのバージョンは v0.10.5 を、プロバイダーはOpenStackを用いている。

単純にworkspaceを分けて使う

まずは何も工夫せず、純粋にworkspaceを分けて使う時に何が起こるのかを確認する。プロバイダーを定義して…

次に、リソースとしてセキュリティグループを1つ定義しておく。

この時点ではworkspaceは分けていない。標準のDefaultのままである。ここでapplyする。

当然だが、リソースが作成される。リソースの状態は./terraform.tfstateに保存される(以下のサンプルでserialが2になっているのは、sg.tfを追加する前に一度applyしたため)。

一度リソースをdestroyして、workspaceを用意していく。標準ではDefaultのみ。

stagingという名前のworkspaceを追加する。

一覧にstagingが追加され、terraform.tfstate.d/staging ディレクトリが作成される。

applyするとどうなるか。

作成時の画面はいつもと同じだが、terraform.tfstateの位置が変わる。標準だとCWDに作られるが、workspaceを指定している時は terraform.tfstate.d/${workspace}/terraform.tfstate になる。つまり、 terraform.tfstate.d/staging/terraform.tfstate だ。

次にworkspaceとしてproductionを作成して、そちらでapplyしてみる。workspaceが変わったので、tfstateも変わり、terraform.tfstate.d/production/terraform.tfstate になる。別々のtfstateで管理しているので、リソースも複数作成されていることになる。

セキュリティグループを確認すると、secgroup_1が2つあることが確認できる。このように、workspaceは状態の管理を分けていることがわかる。

workspace毎にテナントを変える

前節ではworkspaceの動きについて確認した。こうなると、少し実践的なことを試してみたくなる。本節では、workspace毎に別々のテナントを使う、ということをやってみる。前節では同じテナントに同じ名前のリソースを作っていたが、これは管理上わかりにくいと感じる。リソースの名前はテナント内ではユニークであることが望ましいだろう。となると、別々のテナントにするという手が思いつく。

workspace毎にどうやってテナントを変えたらよいか。Terraformではworkspace名をtfファイル内で参照することができるので、これを利用する。

provider.tfを以下のように変更する。これにより、staging workspaceを選択した場合は「repl-staging」テナントが使われ、production workspaceを選択した場合は「repl-production」が使われる。

後はそれぞれテナントを用意してやればよいので、作業ログなどは省略する。作業スペース毎にテナントを作っているので、OpenStack内では完全に分離されている。かなり安全といえるだろう。しかし、テナントの切り替えが必要であること、workspace毎にテナントを用意しておく必要があることなどから少し手間がかかるデメリットもある。

workspaceによってリソース名を変える

前節ではworkspace毎にテナントを分けるテクニックを検証した。本節では、同じテナントを使うがリソースがどのworkspaceに属しているのか認識できるようにするテクニックを検証する。同じテナントで複数のworkspaceを運用して不便なのは、同じ名前のリソースができるからである。つまり、workspaceによってリソース名が異なればよい。

modules/sg/sg.tfとして、以下のようなモジュールを用意する。ポイントはnameの部分で、workspaceがproductionであれば変数として渡したnameを使い、そうでなければ”${workspace}-${name}”という、workspace名をprefixにつけた名前となる。

モジュールを呼び出した側は以下のようになる。

stagingでapplyすると、staging-secgroup_1という名前でセキュリティグループが作成されている。

productionでapplyした場合はprefixがつかず、secgroup_1という名前で作成される。

このようにworkspaceとmoduleを組み合わせることで、同じ設定でもproductionとstagingで別々の名前のリソースを用意できることがわかった。workspace分のリソースが作られることになるが、テナントの管理に比べると楽だろう。

Terraformの追加構文にはかなり多くの関数が用意されている。モジュールでうまく隠蔽して、良い感じのInfrastructure as Codeを実現していきたい。

July Tech Festa 2017に行ってきた

8月27日に産業技術大学院大学で開催されたJulyTechFesta2017に行ってきた。

廊下の端っこにおしゃれなスペースが

B10: Web サービスの信頼性を守るための取り組み

https://2017.techfesta.jp/speakers#B10

https://speakerdeck.com/rrreeeyyy/jtf-2017-site-reliability-engineering

Cookpadではどういうことをしているのか、という所を知りたいなあと思い、聞きに行った。新規サービス開発時、SREは1人か2人アサインして、そのメンバーで信頼性に関する点は設計からパフォーマンスチューニングまでやっているとのこと。想定するユーザ数でアーキテクチャも変わるので、デザインドキュメントも重視している。負荷試験を行い、必要であればアプリケーションのコードにも手を入れる。おおむね自分の認識しているSREと同じだが、ちゃんとやれていて頑張ろうという気持ちになった

モニタリングはZabbixから徐々にPrometheusに変えたいそう。メトリックは15秒単位。高級言語でメトリックとクエリを扱いたいという要求は自分と同じだった。どのモニタリングツールを選ぶか、という観点、時系列DBに対する理解やツールの特性が何か。自分たちに合うか?スケールするか?ということを考えないといけない。

ロードバランシングの話。問題に対してソフトウェアエンジニアリングで解決していて、素晴らしい。

SREは文化だという主張はおもしろいと思った。確かに、単にやり方を真似するだけじゃなくて、エッセンスを理解して、自分たちにあったやり方を取り入れていくことが大切だ。目的はサービスをユーザに届けることなので。それを文化、という言葉にしたのは納得できる。

E20: インフラエンジニアのためのFPGA超入門

https://2017.techfesta.jp/speakers#E20

FPGAについて、ほとんど知識がなかったのでちょっと知りたいと思って聞きに行った。FPGAというのは論理回路を作り込めるIC・LSIで、デジタル回路は何でも作れる…ただ、書き換え可能である分パフォーマンスやサイズが書き換え不可能なものと比べると弱い、というものだということを知ることができた。

ウェブサーバやKeyValueStoreのようなものも作ることができるというのはちょっと意外(そりゃできるんだけど)。並列性、特化性が必要であれば選択肢として挙げられるようだ。自分が使うかどうか、については、可能性は0ではないけど、そこまでパフォーマンスを突き詰めないと行けない要件が自分の目の前には今のところなさそうだ、という感じ。

とはいえ、オンチップでFPGAを利用できるのもそう遠くはなさそうで、どんどん身近になりそう。定期的にアップデートしたい分野であることは間違いないなあ。

E30: オープンソースコミュニティにおける英語が苦手な開発者の苦悩と奮闘記

https://2017.techfesta.jp/speakers#E30

https://github.com/masayukig/non-native-english-speaker/blob/master/non-native-english-speaker.pdf

コミュニティにおいて英語が母語ではない人がどうたち振る舞ったのか、という話かなと思っていたら英語の学習についてという内容が中心だった。Reading,Writing,Listening,Speakingをどう学ぶか、また日本人や中国人、ブラジル人がどう振る舞いやすいかという話。学ばねばなとは思っているけど使うことがないのでなかなかモチベーションが沸かないのだよなあ。英語を使えないから使う機会がない、という鶏卵のような状況なのかもしれない。

 

E40: ネットワークの検証やレビューにはもう正直疲弊したので全部プログラムで自動化できるようにしてしまえばいいと思った

https://2017.techfesta.jp/speakers#E40

https://speakerdeck.com/corestate55/jtf2017

ネットワークがちゃんと繋がっているかどうかの確認については結構関心があったので聞いてきた。自分のようなソフトウェア側の人間と、ネットワークエンジニアのような立場の人ではネットワークのとらえ方が違う(ネットワークが繋がっているものか、繋げるものかという認識の違いがある)のが興味深かった。

物理的な場所やデバイス・OSというような制約があるのでテストしにくいのはその通りだと思う。

テストについては、Cucumberで振る舞いを記述し、それを元に専用のテストフレームワークでテストする、というもの。OVS/OFSを使って、機器間のケーブルの切断を再現していた。OFSが挟まっている以上、完全に本番環境と同じではないけどなかなかよさそうだと思う。

E50: CDNのトレンド2017:セキュリティCDNとマルチCDN

https://2017.techfesta.jp/speakers#E50

CDNのトレンドということで聞いてみた。

ピーク対策としてCDNを使うということを言っていて、そういう使い方はあまり認識になかったので興味深かった。CDNの歴史から始まって、最近は自社に最適化したCDNを作ったり、IPSが余っている回線を売るためにCDNを始めることが多いという話をしていて、目的に応じていろいろ選べる状況になっている、という状況のようだ。

CDNのセキュリティ機能としてはプロトコル変換とWFAを挙げていた。SSL変換はCPUを結構使うのでCDNを使うという手法を使うことがあるとのこと。また、大量のトラフィックをさばき、選別するという特性からCDNはWFAと相性がよいそうな。アプライアンスは上の回線が詰まったら終わるよね、という話をしていた。

マルチCDNというのも最近行われていて、NHK等が採用しているとのこと。一番パフォーマンスが良いCDNを使うようにする、という目的。 https://portal.cedexis.com/ui/login.html をみると様々なCDNの状況が分かり(見るのは無料)、有料プランだと切り替えることができるというものだった。

聞いてみるとめちゃ便利だなあと思ったが、CDNにどこまでやらせるべきなのだろうなあ。(今のところ)設定をコードで管理するのは難しそうだし。

他、気になったセッション

後でスライドを読む用のリスト。

ipcalc:IPアドレスやネットマスク、CIDRを計算するCLIツール

CIDRを見たときによく「cidr 早見表」とか検索していたのだけど、 ipcalc というCLIツールを知ったのでメモ。

OSXだと、インストールはbrewでできる。Ubuntuだとaptでインストールできるみたい。

使い方は簡単。

なかなか便利だ。

all-in-oneなOpenStack環境をkolla-ansibleを使って自宅に作った

久々に自宅サーバを用意して、そこでOpenStackを動かすぞーと四苦八苦していたのだが、ようやく一通りのコンポーネントが起動した。/etc/hostsの設定漏れ(127.0.0.1とホスト名の紐付けがミスっていた)に気づかずなかなかうまくいかなかったが、基本的にはQuickStartの通りに進めれば動く。

サーバを複数建てて疎通も確認

適当にフレーバーとネットワークを作ってイメージを登録して、サーバを2台建てて互いに疎通することを確認したので一安心。次は外部ネットワークとFloatingIPを使えるようにしていこうかな。こうなるとComputeNodeがもう1台ほしくなるね。