ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

Terraform meetup tokyo#1を開催しました

はじめに

しました。

terraform-jp.connpass.com

ありそうでなかったmeetupだったので、思った以上に注目度が高かったようでした。しかし注目度だけが先走ったせいもあり参加率は悪く、具体的には書きませんが"最悪"の数字を叩き出したので次回以降は対策を練っていきます。

モチベーションが高いひと、これたはずだけど諦めたひとがこれないようなコミュニティにしたくない。

会場の様子。オイシックスさんの会場スケーリングできるからすごいんですよね。。。

f:id:take_she12:20190804233744j:plain

LTの様子。運営メンバー4名が発表しました。

f:id:take_she12:20190804233800j:plain

Hashicorpさんの"ハシ"を入手した運営メンバー。

f:id:take_she12:20190804233927j:plain

いつ使おう。まだ使っていない。

f:id:take_she12:20190804235235j:plain

Terraform-jpでは「せっかく勉強会に来ているのに何も話さないで帰るなんてもったいない(ありえない!)」という考えを大事にしており、ワールドカフェ形式でグループごとに話す取り組みに挑戦しました。

僕自身もやったことがなかったのですが、アンケートやTwitterを見る限り知見を得られた、来てよかったという声がいくらかあり、価値はあったようです。

懇親会で話していても、「1人でTerraformをしていて話せるひとがいない」というひとは結構な数いて、そういうのを支えあえる勉強会、コミュニティ(Slackを含め)であればいいと思いました。

また、飲食スポンサーはなんとHashicorpさんにお願いしました。申し分ない量のお酒とお菓子とつまみを提供いただき、また参加者にとっても有益であるTerraformの情報を話していただき、非常に助かりました。

meetup自体は今後も続けますので、今後もスポンサーをお願いする機会があればぜひに、という感じです。

Terraform-jpの"オフ会"はニッチなSource Code Readingと、meetup(Lightning TalkとWorld cafe)を隔月でやっていく予定です。なお実施日程は毎月最初の平日です。理由は特にないです。

次回 9/2 Source Code Reading#2

connpass.com

その次 Terraform meetup tokyo#2 10/1(火)です。よろしくおねがいします。LT公募します。

実際にコミュニティ駆動でaws providerにPRを出せて晴れてcontributorになれて本当によかったです。今後も仕事でDeepに使っていくはずなので、Contribution & より深い理解 & Communityを盛り上げていきたいと思います。

Lightning Talk資料はこちら。まぁcode読むと怖くなくなるし最新verにするモチベあがるしいいことあるのでみんなでやろーぜ、ということを言いたかっただけの資料です。

言い損ねたけどこのコミュニティからContributor10人出したいなぁと思ってるのでやっていきましょう。

この業界に入って、Softwareの、Opensourceのコミュニティに、勉強会に助けられてきたので、それを提供する側にまわれて恩返しできたのが嬉しいです。

ぜひTerraformユーザの方は気軽に遊びにきてくださいね。それでは!

Terraform aws provider PR / lambdaのnode engine v6.10のEOL対応

はじめに

github.com

mergeされた!

これはなにかというと、Lambda側でnodeのengine v6.10がEOLのせいでapplyにこけたので、テストとドキュメントを修正した。

もともとは別の aws_lambda_permission resourceのimport supportをやろうとしていた。

github.com

このページの以下のサンプル。

resource "aws_lambda_permission" "allow_cloudwatch" {
  statement_id  = "AllowExecutionFromCloudWatch"
  action        = "lambda:InvokeFunction"
  function_name = "${aws_lambda_function.test_lambda.function_name}"
  principal     = "events.amazonaws.com"
  source_arn    = "arn:aws:events:eu-west-1:111122223333:rule/RunDaily"
  qualifier     = "${aws_lambda_alias.test_alias.name}"
}

resource "aws_lambda_alias" "test_alias" {
  name             = "testalias"
  description      = "a sample description"
  function_name    = "${aws_lambda_function.test_lambda.function_name}"
  function_version = "$LATEST"
}

resource "aws_lambda_function" "test_lambda" {
  filename      = "lambdatest.zip"
  function_name = "lambda_function_name"
  role          = "${aws_iam_role.iam_for_lambda.arn}"
  handler       = "exports.handler"
  runtime       = "nodejs6.10"
}

resource "aws_iam_role" "iam_for_lambda" {
  name = "iam_for_lambda"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

runtime = "nodejs6.10"

ここね。

EOLになってるので The runtime parameter of nodejs6.10 is no longer supported for creating or updating AWS Lambda functions. という怒られが発生する。

aws.amazon.com

代わりに10.xが使えるので、古い世代をやめて1世代分送った感じ。

今回は実装ではないにせよ、ドキュメントの修正も大事な貢献だと思う。ちなみにaws providerのdocumentは website 以下にあるので気づいたらどんどんPR投げたらいいと思う。

github.com

おわりに

方針がよくわかんなかったのでとりあえずreplaceして投げたら丁寧にコメントくれて、その指摘に対応したらマージされた。

昨日からこのリポジトリのissue/PRをwatchしてるけど、かなりのスピードでReview/Mergeされていて、Hashicorpのcore committerたちしっかり働いています。いずれも24時間以内に反応もらえる感じです。

次は元々やろうとしてた lambda_permission のimportをやろうと思う。

Terraform importの実装

はじめに

PRを出した。(mergeまではしばらく時間がかかりそうな雰囲気)

github.com

Autoscaling groupのlifecycle hookのimportをsupportするというニッチ(?)なissueを解決するためのもの。

そもそも先日行った Source Code Readingのオフ会をきっかけに、次のmeetup(8/1を予定)までに何か1つPRだすぞーといって出したもの。準備からコード読み含めて連休の結構な時間を使った。

terraform-jp.connpass.com

このissue自体もcontributorのkterada0509 さんが教えてくれて、参考の実装まで教えてくれて手取り足取りどころではない感じで圧倒的感謝です。

結果的にほぼ参考実装の丸コピにはなったものの、理解するために手を動かしていい経験になった。

Terraform import

そもそもimportとは何かというと、既存のリソースをTerraformの管理下におくこと(=stste fileにとりこむこと)である。

tffileは生成してくれないので、実際はimportしたあとplanの差分を埋めるべくtffileを書く必要がある。

コマンドはこんな感じになる。

$ terraform import <resource type>.<resource name> <resource id>
# terraform import aws_autoscaling_group.chaspy_test_asg test-asg

こんな感じになる。

で、インポートする時点では中身は空でいいのでtffileに以下のような定義をおいておく必要がある。

resource "aws_autoscaling_group" "chaspy_test_asg" {
}

test-asgというのが実際にAWS上にあるAutoscaling Groupの名前である。

コードを読む / ストレートにImportする

さて、ではこのAutoscaling Groupのリソースファイルを見てみよう。

https://github.com/terraform-providers/terraform-provider-aws/blob/v2.19.0/aws/resource_aws_autoscaling_group.go#L28:titie

ポイントしてるように、Importを可能にするにはこのようなImporterを実装する必要がある。

     Importer: &schema.ResourceImporter{
            State: schema.ImportStatePassthrough,
        },

ImportStatePassthrough が何を意味しているかというと、cliの第2引数で受け取ったidが、そのままresource idとして使える場合、そのまま実際のリソースの情報を resourceAwsAutoscalingGroupRead functionで読み取り、その内容をstateファイルにつっこむことになる。

もしこのようにストレートにインポートできる場合で、importがsupportされていなければ、この部分を追加するだけでimportできるようになる。

Importがストレートにいかない場合

では今回のPRのように、 ImportStatePassthrough ではうまくいかないパターンはどんなパターンか。

参考にした AutoscalingPolicyと同じく、そのリソースのidだけではresourceのgetができないような場合はimportを工夫する必要がある。

参考にした実装のAutoscalingPolicyのドキュメントを見てみよう。

www.terraform.io

$ terraform import aws_autoscaling_policy.test-policy asg-name/policy-name

なぜこうしているかというと、policy-nameだけではリソースが一意に定まらないからである。

cliを見てもわかるが、autoscaling policyはautoscaling groupが必須である。(そりゃそうだ)

docs.aws.amazon.com

で、import実行時にはasg nameとpolicy-nameを/区切りで入力させることにしている。

ではこの実装を見てみよう。

terraform-provider-aws/resource_aws_autoscaling_policy.go at v2.19.0 · terraform-providers/terraform-provider-aws · GitHub

passthroughするわけにはいかないので、オリジナルのimport用functionを実装している。

     Importer: &schema.ResourceImporter{
            State: resourceAwsAutoscalingPolicyImport,
        },

terraform-provider-aws/resource_aws_autoscaling_policy.go at v2.19.0 · terraform-providers/terraform-provider-aws · GitHub

期待している <asg-name>/<policy-name> がきた場合、スラッシュ区切りで分けて、そのリソースのpropertyにsetするとともに、SetIdでidを付与している。

逆に言えばpassthroughの場合、このd.idがそのままそのリソースにSetIdされることになるのだろう。

今回取り組んだ Autoscaling Lifecycle Hookも同じような構造であったため、ほぼそのままの実装でいけた。

おわりに

これまで使われている、使っているOSSへのContributionができていなかったので、今回挑戦できて本当によかった。

8/1のmeetupのLTで話す内容だが、このPRを送るための事前準備、debug方法、テスト方法などなどもまとめてブログに書く予定。

はやくマージされないかなー


追記:7/16 Mergeされました!

github.com

MongoDB In Action 2nd Edition Chapter 10 "Chapter 10. WiredTiger and pluggable storage" を読んだ

はじめに

読んだ。

MongoDB in Action: Covers MongoDB version 3.0

MongoDB in Action: Covers MongoDB version 3.0

  • 作者: Kyle Banker,Peter Bakkum,Shaun Verch,Doug Garrett,Tim Hawkins
  • 出版社/メーカー: Manning Publications
  • 発売日: 2016/04/15
  • メディア: ペーパーバック
  • この商品を含むブログを見る

2012年に出た1st Editionの日本語訳も中古で買って一通り読んだんだが

MongoDBイン・アクション

MongoDBイン・アクション

v3.0サポートの 2nd Editionが出ていて、

この版で新しくWired Tigerとプラガブルストレージの章が追加されていたので、ひとまずここだけ読む。

Manningのページから "pBook+eBook+liveBook includes previous edition" を買ったが(お得)

www.manning.com

liveBookが便利。オライリーSafariみたいな感じのだけど、ブラウザで見れるので、Mouse Directoryで単語の意味がシュっと出せる。

gigazine.net

f:id:take_she12:20190701031532p:plain


  • Storage Engineについて
    • Storage EngineはClusterの挙動やMongoDBへアクセスするDriver、mongo shellに影響を与えない
    • しかし実際のファイルに読み書きする際に影響する
  • なぜPlugubleにする必要があるのか / 異なるストレージエンジンを使う必要があるのか
    • 記事があり、大量に読まれるNewssiteとTwitterのようなSocial Mediaがあるとする
    • documentの数、サイズ、動的にコンテンツが提供されるか、という点で違いがある
  • Wired Tigerについて
    • Wired Tigerへの移行、設定は読み飛ばし
    • Option
      • dbPath: dataが保存されるpath
      • journal.enabled: ジャーナルが有効かどうか
      • engne: wiredTiger or nmapv1
      • engineConfig.cacheSize: キャッシュとして使うメモリサイズ
      • engineConfig.journalCompressor: ジャーナルで使用する圧縮タイプ。
      • collectionConfig.blockCompressor: コレクションの圧縮方式
      • indexConfig.prefixCompression: インデックスを圧縮するかどうか
  • MMAPv1との違い
    • nmapv1, wired tigerの各圧縮方式3つで性能比較した
      • 圧縮なし、snappy, zlib
      • それぞれの設定ファイルを示した
      • insertのscriptをかいた
    • insertのテストでは、起動時間にnmapv1と大きな差があった
      • まぁこれは一度限りなのであまり重要ではないが
      • データの圧縮率が非常に大きい点でWired tigerが優れている
    • readのテストでもWired Tigerが上回っている
    • ベンチマークの結論
      • 少なくとも、データ圧縮の点でWired Tigerが明らかにすぐれている
    • 他のストレージエンジンについては読み飛ばし
    • ストレージエンジンがMongoDBからどのように呼ばれてるか、も飛ばし

おわりに

NMAPv1との違いとそのベンチマークに焦点をあてており、Wired Tigerのパフォーマンスについてはは書かれていなかった。

つぎはMongoDB In Action 2nd Editionを動かしつつ2週目読むか。

オライリーのほうも気になっている、第3版がいまアーリーリリース。でもSafariやめちゃったんだよな。やむなし。

learning.oreilly.com

9月発売か。そしてこれはMongoDB v4.0対応。

かといって2版はMongoDB v2.4だし、うん、発売を待つかな。

はじめてのMongoDBを読んだ

はじめに

読んだ。

はじめてのMongoDB (I・O BOOKS)

はじめてのMongoDB (I・O BOOKS)

結構薄いんで先にばーっと読んだしまったあと、(MongoDB イン・アクションもこのあとばーって読んだ)検証環境でざーっと動かして2周した感じだ。

最初の一冊としてざっと全体感をつかむにはちょうどいい。ただどのみちがっつりやるならMongoDB イン・アクションのほうが量も多いしいろいろ深い。この本はアプリケーションエンジニア向けで、インアクションのほうはDBAまで対象にしてる感じ。

インストールまわりは終わらせていたので、内容としては

  • 基本的なMongo shellの操作
  • import / export
  • インデックス
  • Ruby(Sinatra)アプリからのアクセス

というところが触れられていてよい。

また、

  • バックアップ・リストア
  • Replicaset
  • シャーディング

は付録でちゃんと触れている。必要になれば調べられるように、ちゃんと紹介されていてよい。

Sinatraについては写経して動かした。

github.com

誤植がいくらかあったりしたが、なおしつつちゃんと最新のRuby, Sinatra, mongo drverで動いたのでよかった。

  • Ruby: 2.6.2
  • Sinatra: 2.0.5
  • Mongo Driver: 2.9.0
  • MongoDB: 3.2.22

ソースコードGitHub公開だったら誤植PR送るけど光学社ページからのDLなので挫折。

おわりに

こっちはlocalのruby / sinatraで動かして、MongoDBは chaspy/vagrant-mongodb を使えた。べんり。一応mongoのhostとportは環境変数から取るようにした。

github.com

やっぱSinatraはいいな。

VagrantでMongoDB Replica Setを作る

はじめに

作った。

github.com

いろいろMongoDBをガチャガチャ動かしたくて、まぁDockerで動かすのも普通にできたが、どうせだしReplicaSetも作ろうと思ったので組んだ。

存在は知っていたものの、今回はじめてVagrantのGuest/Hostのhostsを自動設定してくれるやつを使った。

github.com

guestのhostsはこんな感じになる。

vagrant@mongo0:~$ cat /etc/hosts
127.0.0.1   localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost   ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
127.0.1.1   mongo0  mongo0

## vagrant-hostmanager-start
192.168.33.202  mongo2

192.168.33.201  mongo1

192.168.33.200  mongo0

## vagrant-hostmanager-end

Vagrantfileにはこのへんの設定が必要。

  config.hostmanager.enabled = true
  config.hostmanager.manage_host = true
  config.hostmanager.ignore_private_ip = false
  config.hostmanager.include_offline = false

mongodbのreplicasetのinitiate処理だけは全部終わってから、特定の1台であてなきゃならんので別の処理とした。mongo shellのコマンドをどうやってbash scriptから渡したもんかなと思ったが、普通に標準入力で渡してやればいい。

vagrant@mongo0:~$ cat /vagrant/repl.js | mongo
$ cat repl.js
rs.initiate()
rs.add('mongo1:27017')
rs.add('mongo2:27017')
rs.status()
cfg = rs.conf()
cfg.members[2].hidden = true
cfg.members[2].priority = 0
rs.reconfig(cfg)

mongo shellにわたすものなので # でコメントが書けない。 jsなんで // で書けばいいんだろうけど。

おわりに

おもちゃができたのでガンガン遊んでいく。

MongoDB In Actionの2nd Editionが出ていて買ったので、Wired Tigerの章読んで何か書くかも。

www.manning.com

しかしいつになってもVagrantは好きだ。。。こわして作る、再現性があるのがいい。

入社してから1年

たった。シュッと書く。

前回

blog.chaspy.me

まだ1年しか経っていないのか、と思うぐらい成長したと思うし、もう1年も経ってしまったのかと思うほど足りてない部分も山ほどある。

必死になってた最初の3ヶ月過ぎて、半年ぐらいのときが一番しんどかった。すごく時間がかかってしまった。願うならもう二度と同じ体験をしたくない。もしまた転職することがあればこうならないようにしたいけど、まだ答えは見つかっていない。

半年を過ぎて、年明けぐらいからいろいろ新しいことをはじめたりして、ようやくバリューが出せはじめた気がする。

残念ながら英語力は対してあがっていない。先日の海外カンファレンス参加で、やっぱり英語でその場で理解したり、英語でネットワーキングしたり、質疑をしたりする英語力がないとダメだ、と強く思い、具体的な目標もできたのでようやく重い腰をあげてちゃんと努力しようと思う。具体的には でspeakingをVersantで継続的に計測しつつ、カンファレンスの動画を聴いて技術と英語同時にやるしかないなといった感じ。技術も英語も同時に伸ばすの、個別にやってたんじゃ無理だ。

技術力はどうなんだろうな。パフォーマンスについての考え方、AWSの理解、nginx、terraform、kubernetesに関しては仕事で使ってるので嫌でも詳しくなった。ただどうしてもコードを書く量が絶対的に足りてないのを趣味コードでちょいちょいやりつつどうしたもんかなと言った感じ。

多分このあたりはOSSのcontributionで実利をかねてやるのがいい気がしていて、自分で使うツールだけじゃなくて、普段から業務で使ってるOSSへのcontributionもちゃんとやっていかないと、とn年前から言っているが未だにできていない。とりあえずTerraformからやってみようと思っている。

terraform-jp.connpass.com

英語だろうが技術だろうがとにかく思うことは、時間は有限で学ぶべきことは無限にある。このあたりの取捨選択を今まで以上にちゃんと考えないといけないと思う。で結局英語力の問題に帰ってくるのだけれど、書籍はもう日本語ではなく英語書籍から学ぶ、あるいは書籍が出る前に公式ドキュメントを見て動かす、ぐらいが当たり前にならないとダメだ。優秀なエンジニアはこれを当たり前にできている。

環境といえば、やっぱり「環境がひとを変える」とか「一番のへたくそであれ」とか、言葉ではわかっていたことを実際に体験したことが大きい。優秀なエンジニアが多いので、自分の価値観も引っ張られるし、扱う技術に関しても自然とインプットが増える。SREは幸運にも全サービスに横断的に関わるので、目にする技術も多い。(だからこそどこまで学ぶかを迷うのではあるが)

この1年を見返すと、「まぁまぁたいていの仕事は1人でできるようになった」「改善や新しい仕組みの導入もできた」「オンボーディングやExperience mapなどチーム視点での取組もできた」でまぁ60点といったところだ。

次の1年の課題としては、まだまだ不足してる英語力。多めの英文を読むのは今でも時間がかかるし、書くのもまだまだツールに頼っている。リスニングは基本的に一発で聞き取れない。せっかく非日本語ネイティブのロビーが同じオフィスに来たので、さっき言った海外カンファレンスでの収穫を得るためにも、仕事をもっと高いアウトプットを出すためにも、当たり前に必須なので計画立てて継続的にやっていく。

コーディングスキル。これはちょっとどうしたらいいのか、なにが足りてないのかまだうまく分析できていない。一般的な考え方なのか、あるいは言語の学び方なのか、そして何を目標とするかもまだ漠然としているので別でしっかり考えたい。。。

もう1つはチーム視点で、SREもこれからまた少しサイズが増えていくのでチームのことをあれこれするのも少しずつやっていきたい。採用活動も含めて。

あと、ソーシャルやコミュニティ活動を通して、この1年で知り合いがめちゃくちゃ増えた気がする。元々お祭りごとは好きなので、勉強会のたぐいは好きだ。ただ、参加するだけでは得られるものも少ないので、基本的に何かしらの発表をするか、「ちょうどこれを知りたいと思っていた」みたいな技術情報を得られるものでない限りはあまり行かないようにしていた。結局、自分の技術力は仕事を通して得るべきで、ただ話聞いて懇親会で話すだけでは技術力は一切伸びないから仕事をしていたほうがマシだ。

僕はソフトウェアの世界のコミュニティが大好きだ。学生時代から個人が書いたブログにすごいお世話になってきたからアウトプットをしようと思ったし、前職時代に勉強会に参加して、いまSREをやれてるから、自分も運営をしようと思った。この世界に少しでも恩返しがしたい。

SRE Loungeで大き目なイベントをやれたらいいなと思っているので、そっちも楽しみにしつつ、自分もしっかり仕事をして、その仕事の成果を登壇してアウトプットしていこうと思う。

まわりのひとが変わると、自分の「当たり前」が変わる。変わったよ。総じて、転職してよかったと思う。

次は「入社して1年半」でまた書こう。2年にしようかと思ったけど、半年ぐらいでまた振り返っておきたいから。