まとめ
- とりあえず terraform init と import の使い方が分かった
- terraform init 超重要
- terraform v 0.11.1 で heroku_app と heroku_addon の import できた
- 安易に import からやれば練習が早くできると思ったけどそういうわけじゃなかった
- import はあくまで .tfstate の更新であり、これと矛盾しない .tf を書いておかないと diff が plan と apply を阻害する
- 話題が少ないのでもしかしてと思っていたけど Heroku と Terraform は相性が悪いというか、考え方が被ってて混ぜるな危険かも
- Heroku は heroku コマンドとか API か wrap した何かを用意した方がよさげ
目標
- Terraform を CI で回してクラウドインフラを管理
以下、試してみた。
Provider を使うには plugin のインストールが必要
- Provider が本体から plugin 管理されるようになった ( v 0.10 )
- init した際に .tf を認識して自動的に plugin をインストールしてくれる
- 逆に言うと import で始める前に provider の情報を理解していないといけない
↑ つらい
provider.heroku: no suitable version installed
version requirements: "(any version)"
versions installed: none
みたいなエラーが出たら init してあげるとよい。
initしたディレクトリ/.terraform
以下に plugin が入る。
credentialの与え方
- 基本的には変数として与える。
- Hashicorp Vault でもたぶんできる。（やってない）
- Provider ごとに配慮してくれる環境変数を使う
- 例えば AWS だとよく使われる AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY その他いくつかの環境変数を自動的に適用してくれる。（確認済み）
- Provider: AWS - Terraform by HashiCorp
基本的な resource 定義
HCL 全般のメモではありません。以下の import に必要な分だけ。
resource <type> <name> {
id = <id>
name = <name>
...
}
- <> で囲んだ部分は基本的には文字列
- type は Provider の中で定義されている。
- type と name の組み合わせは unique である必要がある
- 例えば Heroku の app について扱いたければ resource type は "heroku_app"
Configuring Resources - Terraform by HashiCorp
import
terraform import TYPE.NAME ID
で import を行う。この際、
- TYPE は Provider で決まっているが NAME は任意に設定可能
- ID も Provider によって決まる
ので、NAME と ID を合わせておくと管理しやすそう。
Heroku
- email と api key で動く
- plugin があれば .tf を元に import して .tfstate を作成することはできる（v0.11.1)
terraform の heroku_app resource は dyno の定義などはできないみたい。おまけに取得した環境変数が全部入りで、add-on の定義によって自動でセットされる場合は .tfstate とぶつかっちゃう。
調べても話題が少ないのでもしかしてと思っていたけど、どうも Heroku と Terraform は相性が悪いというか、考え方が被ってて混ぜるな危険なのかもしれない。
※そうなると Heroku を含むすべてのインフラを自動管理しようと思うと Terraform 一本やりというわけにはいかず、工夫が必要。
heroku_app
heroku_app resource では heroku の app name と terraform resource の id は同じになる。
example では
resource "heroku_app" "default" {
name = "my-cool-app"
region = "us"
}
こんな風になっているが、ここで resource syntax 上の name と argument の name は一致させておいた方が管理しやすいように思う。例えば
resource "heroku_app" "lt-timer" {
name = "lt-timer"
resgion = "us"
}
みたいな感じにしておくと
terraform import heroku_app.lt-timer lt-timer
で import できる。コマンド打っているときは重複に見えてアレだけど、変に名前を付けて管理を複雑にするよりはマシなのではないか。
Heroku: heroku_app - Terraform by HashiCorp
ただし、add-on の追加によって自動設定される環境変数の値はともかく、リリース情報とかまで全部環境変数に乗って取得できてしまっている。例えば以下のような感じ。
"all_config_vars.%": "23",
"all_config_vars.HEROKU_RELEASE_VERSION": "vxxx",
"all_config_vars.HEROKU_SLUG_COMMIT": "xxxxxxxxxxx",
"all_config_vars.HEROKU_SLUG_DESCRIPTION": "Deploy xxxxxxx",
これはさすがに困る。仮に .tfstate をもとに次回以降の apply をするのであれば、もはや deploy すらできないことを意味するのではないか。一方で
heroku apps:info --json
では普通に取得できる Dyno の情報は .tfstate に乗ってこない。
"dynos": [
{
"attach_url": null,
"command": "bundle exec unicorn -p $PORT -c ./config/unicorn.rb",
"created_at": xxxxxxxx,
"id": xxxxxxx,
"name": "web.1",
"app": {
"id": xxxxxx,
"name": xxxxx
},
"release": {
"id": xxxxxx,
"version": xxxx
},
"size": "Standard-1X",
"state": "up",
"type": "web",
"updated_at": xxxxxxxxx
},
{
"attach_url": null,
"command": "bundle exec sidekiq -C config/sidekiq.yml",
"created_at": xxxxxx,
"id": xxxxxxxx,
"name": "worker.1",
"app": {
"id": xxxxxxxxx,
"name": xxxxxxxx
},
それでいて heroku_dyno という resource type があるわけでもない。つまり Dyno の管理は Terraform ではできないということになる。
以下のように Heroku と AWS S3 を使ったよくあるサイトを Terraform で作るよ、という情報はあるのだが、継続してアプリを成長させていく際のインフラ管理を Terraform 一本でやるのは難しそうに見える。
Using Terraform to Build Heroku/S3 Site - Ficksworkshop
heroku_addon
id は add-on の識別名 ( papertrail-xxxxx-xxxxx など ) になる。import の際に必要なだけだろう、たぶん。これを取得するには Web コンソールか heroku コマンドなどが必要。
heroku apps:info --json
とか。
Heroku: heroku_addon - Terraform by HashiCorp
AWS IAM Role And Policy
IAM Roleの権限不足なのか、とりあえず今回は確認できなかった。
今後
- Herokuの管理の自動化はterraformよりはherokuコマンドやAPIを真面目に使う方がよさそう
- 当然本家なのでなんでもできるんだけど、状態を把握しやすくし、diff だけで副作用が分かる、って状態じゃないのが課題。
- AWSの方の準備を進める
- 自動化用の IAM ユーザーと credential を作成
- いったん静的サイト方面の resource を中心に
- Terraform 用の backend bucket を作成
以上のようなところが今後の課題っぽい。自動化しようと思ったら backend を remote に用意しておかないと複数人で回す際に .tfstate が一本化されずに安定動作しないということらしい。
※ CI で回す気まんまんなんだけど、さすがに CI の cache に期待するのはスジが悪いだろうな…。
参考
- MacOSX 10.4 以降
- 2.x の時代は NeoOffice を使う必要あり
- Windows 2000 以降
- 2.x の時代は 98 以降でも動く
mozillaZine 日本語版 » Blog Archive » Mac OS X メールクライアント Correo は Camino がお手本
ほえー。でもなー。Camino って自動更新の機能ないから一般人には勧めにくいんだよね。Correo は 10.4 以降なので試してないけど、同じ発想ならやはり一般人には勧めにくいような気がする。extension とか普通の人には関係ないことの方が多いし、少しでも軽快に動くならそっちを使ってもらいたいところではあるんだけど。
pukiwiki の plugin サイトという形で探したことがないので他にもいくつかあるのかもしれない。今回も sourceforge の feed に流れてきたので気づいただけで、探したわけじゃないし。
pukiwiki もなー。どうにかしないとなぁ。
びっくりした。でも実際面白かった。
M-1 は毎年デキレースくささを感じるんだけど、今年はハリセンボンの決勝進出と妙な評価の高さにそれを感じた。あと審査員が前より偏ってないですか？
平日なのでいつもの携帯のバイブ機能目覚まし（要するに音を切ってある）が発動していたがさっぱり気づかなかった。よく寝ていたらしい。
どうでもいいけどきむらさんの tumblr を FLDR に放り込んだ途端何も流れてこなくなった。ちょっぴり残念。
いやうちはまだデジタルのチューナーなんてどこにもないんですが、デジタル放送って映像として見る分にはアナログと違って遅延が出るじゃないですか。デコード処理とか1。あれの遅延って、レコーダレベルではどうなるんだろうと思って。とりあえず映像情報としては正しい時間に来てる？ でも考えたらそれも保証できないような気が2。そうすっと録画開始時はレコーダがちょっと早く始まるんでまぁいいとして、終了時はどうすんだろ。まぁ普通はテレビ番組表に終わる時間は書いてないし、民放の場合は次の番組が始まるまでの間は適当な CM が流れてるんでいいとして。CM のない NHK なんかはどうなるのかな？ 番組終了信号とかある？ それともバッファでかくして対応しとく？ それとも NHK も以前3と違っていきなり次の番組にはいかないようになってるのかな？ あんまりじっくりテレビ見ることもないからよく分からなくなってるけど。
なんてことを、アナログに対してずれまくるデジタル放送のテレビを見るたびに気にしてしまうのであった。ま、とりあえずギリギリまでデジタルに対応する気ないんだけど。
※ 放送は IP じゃないから遅延せずに「見えなくなる」「聞こえなくなる」のが正しいみたい。そうか、そりゃそうか。
風邪引いとるっちゅーに酒飲んでシャウトしてりゃそりゃ悪化するっての。
『毎月新聞』（佐藤雅彦, 毎日新聞社, 2003）を買った。この手の本は本当にめったに読まないんだけど、これは珍しく無目的に本屋で物色していたときに表紙の感じに惹かれて買った。
あんまり読んでない。
いや、これはいつもの積読ではなくて、読み方を変えてみたのだ。まず頭から読まない。これはコラム集なので、どこから読んでもいいのだ。だからカラオケのゲームみたいに適当に開いたページを読むことにしている。
しかも開いたページで、本文を読む、イラストを見る、3コマ漫画を読むの三通りの楽しみ方ができる1。なんてお得。もったいないのでじっくりじっくり読むことにしたのだ。
ところでこの本、メディア、情報、視点についても鋭い指摘を軽妙なタッチのまま読むことができ、とても面白い。予備知識なしにこういう本に当たると、このうえなく気分がよい。
すべてのページでこれらの要素が網羅されているわけではないけど。 ↩
確かにかなり軽い。Adobe Reader Speedup なんてメじゃない。OS X で Preview で開いたみたいに速い。これはいい。
ただ IE の中で表示することはできても Mozilla 系の plugin の仕組みには対応してない模様。仕方ないのかなぁ。
とりあえずチェックだけしてみる。
- 中間スイッチ ２４時間プログラムタイマー BJ４７
- 防犯グッズってところもなかなかよいが、時間の狂い方が大胆でよい。
- タイマーコンセント
- シンプルだ。古いエアコンのタイマーみたい。
- スナオ電気株式会社
- タイマー専門ですよ、奥さん。
22日に忘年会やってからだるい。
- Sylpheed の 1.0 が今日（24日）出るらしいということで OS X で Fink から Sylpheed 0.9 を入れてみる（これは23日）
- なんかやたらとソースの取得にコケて retry another mirror しまくり。これだけで2時間以上掛かった気がする。
- build 開始。全然終わらず。朝まで放置。
- 朝。設定不足でメニューが一切表示されず。
面倒くさくなった。なんかもっさり Thunderbird でいいかとか思っちゃう。ついでに Sylpheed Claws から Win32 を入れる。インストーラから入れたのにこれもメニュー表示されず。しかも終了できず。なんじゃこりゃ。とここまできて前にもまったく同じことをやったような気がしてきた。記憶力ないなぁ。
- X-Deep/32 を試す（実際試したのは22日）。
- putty で X を forward するのは成功したけど cko で ssh -X したらうまくいかない。なんでだ。
- まー直接飛ばせばいいんですけどね。どうせ LAN だし。
- あー日本語どうやって入れんだ？
- canna2imm32 てのと kinput2 でできている人が居る
- うーんメンドイ。つーかそもそも普段 X なんて使ってないし、必要性を感じていないことに気づくorz
- Cygwin の X も使ってないし、速度比較もできないじゃん。
明日は Ruby 1.8.2 か。
RootFTP を使い始めて早何年なのですが、一部のサーバに対してすこぶる相性が悪く、更新日時のところに permission が表示されるは、予約にも全然入らないわで作業できないことがあります。で、しょうがないから開発版 1.9.5 を試してみると、これが転送に関するバグは修正されているのに、肝心の UI が正式版 1.66 より使いにくくなってる感じ…。さすがにもう放置プレイかなぁと思って SmartFTP を試してみると、RootFTP で相性が悪いと言っていたサーバに繋いだ瞬間にお亡くなりになります。wu-ftp って、そんなにおかしいのか？ それともバージョンの問題かな？
まーそんなこんなで頭にきてコマンドラインで作業してしまうわけですが、FTP クライアントって、やっぱあれこれ要求するならシェアウェアなんですかねぇ…。
それよか、SFTP に対応した GUI のクライアントが一向に増えてこないのはなぜなんでしょう？ FTP over SSL より簡単でいいと思うんですが。もう時代は SSH でしょ？ そう考えるのは浅はかですか？ 早く SFTP 一本に絞りたいっす。