前回の heroku の import の続き。
まとめ
- Terraforming は本当にすごい。超簡単。.tfstate だけでなく .tf も出力できるし、IAM の KEY さえあれば特に何も書かなくてよい。
- 逆に terraform import はなかなか大変。（詳細は前回のterraform import heroku_appはできたけど…使い方が悩ましい参照。）import はまだおまけ的な感じで、terraform が正しく動作するために .tf を書き、これを validate すると required な option がボロボロ出てくる。
- 対応サービスの数は Terraform の方が多いが、ものによっては Terraforming でしか対応できていなかったりするので、しばらくは両方知っておくのがよさそう。
- AWS Certificate Manager は承認のプロセスが挟まるので完全自動にはできないんだなぁ
- AWS S3 の Bucket の Policy は使い方別に整理した方がよさげ
ちなみに似たツールとして terraformer というものがあったが、これは terraforming の fork でかつ実運用もしていない、対応 provider も少ないものだった。
S3 + CloudFrontで配信する静的サイトが複数あるものとする
すると必要なものは
- S3 ( aws_s3_bucket )
- IAM Policy ( aws_iam_policy_document ) / IAM User Policy
- CloudFront ( aws_cloudfront_distribution )
- ACM ( AWS Certificate Manager )
いったん Log および Metrics は置いておく（CloudWatch とか）。また、ACM については承認プロセスの関係上、素直な方法では自動化できないので除外とする。というわけで 1 から 3 について試してみた。
aws_s3_bucket
特に難しいことはなかった。
resource "aws_s3_bucket" <bucket_name> {
bucket = <bucket_name>
}
こんな感じで bucket_name で統一して、
terraform import aws_s3_bucket.<name> <bucket_name>
ちなみに
terraforming s3
にすると何も考えずに権限のある S3 の情報が全部ぶっこぬけます。めっちゃ楽。
AWS: aws_s3_bucket - Terraform by HashiCorp
aws_cloudfront_distribution
これはいろいろ required な attribute があって面倒くさかった。何がつらいって terraforming が対応していないこと。どうにか調べて試して動くようにしなければいけない。結局 Terraform の Provider と Resource の情報は自分で調べられないといけない。
resource "aws_cloudfront_distribution" <distribution_cname> {
default_cache_behavior {
allowed_methods = []
cached_methods = []
forwarded_values = []
default_ttl = 0
min_ttl = 0
max_ttl = 0
target_origin_id = ""
viewer_protocol_policy = ""
}
viewer_certificate {}
enabled = ""
origin {
domain_name = ""
origin_id = ""
}
restrictions {
geo_restriction {
restriction_type = ""
}
}
(logging_config)
}
として
terraform import cloudfront_distribution.<distribution_cname> <distribution_id>
みたいな感じ。import は
terraform import TYPE.NAME ID
が基本だが、NAME として理解しやすいのは Distribution ID ではなく CNAME の方なのではないかと思う。CNAME を指定していないなら Distribution ID でよいと思う。
AWS: cloudfront_distribution - Terraform by HashiCorp
aws_iam_user
これは簡単。
resource "aws_iam_user" <user_name> {
user_name = <user_name>
}
で
terraform import aws_iam_user.<user_name> <user_name>
AWS: aws_iam_user - Terraform by HashiCorp
aws_iam_user_policy
今度は terraform v 0.11.1 が 2017-12-26 時点では import に対応していなかったので terraforming で。
terraforming iamup
やってみて気づいたこと
IAM Policy の適用ポリシー (言ってみたかっただけ :-) が揺れている。
これについては後日。
まぁ、これまで WebUI であっちこっちに行くことでよく分からなくなっていた、立ち止まるのが面倒で放置していたこういう状況の俯瞰のためにも terraform import あるいは terraforming は使えるってことだなーと思った。
参考
- TerraformでAWS S3バケットを操作 - Qiita
- sjevs/terraform-static-website-s3-cloudfront: Terraform template to create static website on AWS S3 & Cloudfront based on variables
- ringods/terraform-website-s3-cloudfront-route53: Terraform scripts to setup an S3 based static website, with a CloudFront distribution and the required Route53 entries.
- S3 + CloudFront + Aws Certificate Manager + Route53 + Middleman + terraformを使ってHTTPS対応した静的Webを100円/月で構築する - Qiita
ちょっと napster を使ってみたいから手伝ってくれと言われたのでセットアップを手伝ってきた。以下、やったこととか思ったこととか。
- クライアントのダウンロードでいきなり IE にブロックされた。普段 Windows も IE も使ってないのでよく分からないんだけど、すべてのダウンロードは必ず情報バー経由でないとダウンロードできないの？ そんなことないよね。meta refresh 系のダウンロードとかが情報バー経由なのかな？ 面倒くさいね。こんなの初心者分かんないよ。
- Windows限定
- というか Windows Media の DRM 限定
- ダウンロード履歴は管理されており、一度登録したアカウントでは最大2台まででしかダウンロードできない。それ以降は恐らく再購入になる。
CDの作成まで一手に引き受けているのは iTunes と基本的に同じだが、アカウントの作成をしないと視聴すらできないのは不親切。あと全体的にインターフェイスが分かりにくいというか注意喚起ができていない。入力ミスを指摘するメッセージも溶け込みすぎてて目がいかないし、アカウントの作成に成功したっていうイベントもいつ起きたのかよく分からない。なんだこれ。
支払い方法の入力とアカウント情報の入力がこんな風に分離してるんだけど、
- アカウント情報と napster コードを入力する画面
- クレジット情報を入力する画面
ここは本当は
- アカウント情報の入力画面
- 支払い方法の選択および napster コードかクレジット情報を入力する画面
に分けるべきじゃないかな。クレジット使いたくないよー、でもそれ以外の方法選べなくね？訳分かんね、のループに陥ってた。
また支払いについては結局のところ、
- 無料トライアルを試すためにはクレジットカードが必要
- トライアル期間が過ぎたら自動的に課金アカウントに移行するために先にカードの情報を握っておく必要がある
- 自動移行を阻止するためには、トライアル期間内にユーザーが明示的にキャンセルのアクションを起こさなければいけない、オプトアウト方式。
- クレジットカードを使わずに試す場合は諦めてコンビニなどで napster コードを購入して、そのコードを入力してから試す。つまり無料お試しは無理。それかアカウント作成して試聴までで我慢。
トライアルが前面に出まくってるがトライアルのためにはクレジットの情報が必要ってのはちょっとどうかなと思う。もっと「アカウント作成 → 試聴 → 購入」の流れを分かりやすく説明してくれないと。自分でカード持ってていきなりカード決済にする決断を下せる人は恐らくとてもスムーズにコトが運ぶだろうけど、ちょっとでもそういう使い方から外れると途端に分かりにくくなってしまう。
ブームに乗った振りしてお笑いネタ。
順当にアンタッチャブルが優勝しました（一応アンタッチャブルでメールゴングに参加してたのだ）が、個人的には POISON GIRL BAND にもう少し余裕を持っていつものふてぶてしさでやってほしかった。あとネタに中日を持ってきたのは審査員を意識してオッサンくさくしすぎでしょう。最終的には食べ物ネタ入れてきてるんだから堂々と学校給食辺りで攻めてほしかった。
麒麟は好きなんだけど、どうしても笑いに休憩時間ができるテンポなので、それ自体は悪いことではないんだけど、こういう舞台では弱いかなーと思います。
南海キャンディーズは不勉強でほとんど知りませんでした。あの男の人の突っ込み方は見覚えあったんだけど、まったくネタやコンビとして印象に残ってませんでした。
笑い飯。えーと、左の人、もっと昔のようにとは言わんからサッパリした方がいいと思います。芸として完成度高いと思うんですが、声の通りが弱いのでテンポを抑えるとかもう少し工夫できるような気がします。1
そんな感じで知った風なこと書いてみました。2005 から R-1 が全国放送になるのでそっちも期待。
あくまで個人的にはですが、シャベクリとかゆうてるくせに声の通りの悪い漫才が案外多いのは納得できません。 ↩
portupgrade 問題解決？
イブに上がってました。思わぬクリスマスプレゼント。とりあえず bdb1 を利用するようにまた設定が戻りました。
ruby 1.8.2
こちらは 25日。jarp では snapshot だと言うてるんですが、これは不安定という意味？ 数日でリリースをくり返したって意味？ 後者であることを願います。
見た瞬間で 2.1 dev7 での運用。Hiki や PukiWiki のようにサイドバーが入るようになりました。うーん、やっぱこうなるか。確かに自分が YukiWiki と WalWiki と PukiWiki をテストして PukiWiki に決めたのも、サイトの全体像をつかみやすく構成することが可能（あくまで可能というだけで PukiWiki なら全体像がつかみやすくなる、というわけではないことに注意。）で、それはやっぱ画面デザインの自由度の高さとサイドバーの存在でしたからなぁ。
でもプラグインも確かに魅力ですが、記法が煩雑になるし、他の Wiki との互換性が落ちるので、痛しかゆしな感じがします。まぁ、Wiki なんてそんなに真剣に悩んで使うようなものじゃないかもしれませんが。