Sionの技術ブログ

SREとして日々の学習を書いて行きます。twitterは@sion_cojp

FargateでSSMのデータをコンテナ起動時に環境変数にセットする

はじめに

dev.classmethod.jp

こんな機能が提供されましたが、

(重要)Fargateは対応していない

本当かどうか実際に試したところ、やはり対応してませんでした。

なのでFargateの場合、SSMのデータを読み込む場合は下記2択が想定されます。

  1. SSMのデータをdecryptして、task definition(container definition)に埋め込む
  2. 起動時にSSMのデータをdecryptして環境変数にセットする

1. task definitionに埋め込む場合

弊社もこちらでやってましたが、タスクの中に復号キーが載り(ECSのdescribe-tasks権限さえあれば)閲覧出来てしまうのでセキュアではありません。

ちなみに下記のmakefileで、すでに用意されてるcontainer definitionに対して、decryptしたデータに置換する処理をしてました。

$ vim ci.mk
DATADOG_API_KEY    := $(shell docker run --rm sioncojp/awscli aws ssm get-parameters --region ap-northeast-1 --name datadog_api_key --with-decryption | jq -r -e .Parameters[].Value)

ecs/container_task_definition: ecs/clean
   @sed -i -e 's|@@API_KEY@@|$(DATADOG_API_KEY)|' container_task_definition.json

ecs/clean:
   -rm -f container_task_definition.json

2. 起動時に環境変数にセットする場合

github.com

chamberというSSMを管理するツールで解決させました。

ロジックとしては、entrypoint.shを用意し、コンテナ起動時にchamberを使ってdecryptし、環境変数にセットしてます。

これでtask definitionにも復号キーが載らず、よりセキュアになります。

設定例

Fargateで、datadog-agentを立ち上げて外形監視させてる例を出してみました。

chamberのexportにはformatがjson/java-properties/csv/tsv/dotenvと用意されてます。

dotenv: DD_API_KEY="xxxxxxxx"
java-properties: DD_API_KEY = xxxxxxx

今回は、java-propertiesで出力し、trコマンドで空白文字を削除して、 DD_API_KEY=xxxxxxx として出力させ、それをexportして環境変数にセット。

最後のexecで、ベースとなるイメージが /init を実行してるので、それを渡してます。

Dockerfile

$ vim Dockerfile
FROM datadog/agent:latest

ENV AWS_REGION ap-northeast-1

RUN curl -L -fsS --retry 2 -o /usr/local/bin/chamber https://github.com/segmentio/chamber/releases/download/v2.3.2/chamber-v2.3.2-linux-amd64 && \
    chmod 755 /usr/local/bin/chamber

COPY url.yaml /etc/datadog-agent/conf.d/http_check.d/url.yaml
COPY fargate.yaml /etc/datadog-agent/conf.d/ecs_fargate.d/fargate.yaml

COPY ./entrypoint.sh /
RUN ["chmod", "+x", "/entrypoint.sh"]

ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh

$ vim entrypoint.sh
#!/bin/sh -

export $(chamber export --format java-properties fargate-datadog | tr -d ' ')
exec /init

最後に

おそらくFargateのECSコンテナバージョンが1.22.0以上がサポートされれば、使えるかと思いますので、一時的な対応とはなりそうです。

ECSのタスク切り替りを通知させる

本記事は、FOLIOアドベントカレンダーの13日目の記事になります。



f:id:sion_cojp:20181211154702p:plain:w170

ことの始め

f:id:sion_cojp:20181211145831p:plain

なるほど。

つまりALBにぶら下がってるコンテナが、現在のコンテナがなくなって、新しいコンテナだけになったときに通知があれば嬉しいってことですね。

棄却した案: cloudwatchのevent * lambda

ECSからcloudwatch eventにtask変動のトリガー送信して、lambdaでslackに通知させることを考えました。

が、タスクが作成、削除されただけの通知で、どのタイミングで切り替わったかわかりづらかったです。

ecs-update-notify

github.com

ロジックは

  • 起動後、/tmp/ecs-update-notify.pid を生成(終了時に削除される)
  • intervalで設定してる秒数、ECSサービスで保持してるタスクを取得
  • 現在のタスクバージョンと、新しいバージョンのデータを保持
  • 新しいバージョンだけになったタイミングでSlackにPOST
  • 新しいバージョンは現在のバージョンとして保持される

古い(現在の)タスクがECSサービスから存在しなくなれば、ALBからも確実に外されてるので、これで解決します。

このようなconfig.tomlを設定して

$ vim config.toml
interval = 30

[[monitor]]
name = "FooCluster"
aws_profile = "foo"
aws_region = "ap-northeast-1"
incoming_webhook = "https://hooks.slack.com/services/....."

[[monitor]]
name = "BarCluster"
aws_profile = "bar"
aws_region = "ap-northeast-1"
incoming_webhook = "https://hooks.slack.com/services/....."

クラスタ名やawsのprofile, regionを入れます。

incoming_webhookはslack apiなどで生成してください。

./ecs-update-notify -c config.toml

とすると、下記のような通知がされます。

f:id:sion_cojp:20181211153940p:plain

導入した後

f:id:sion_cojp:20181211154252p:plain

解決した!

ps: datadogでこういうの通知してくれると最高なんですけどね

プロゲーマーのマネージメントとチームワーク

本記事は、FOLIOアドベントカレンダーの11日目の記事になります。

はじめに

ゲーマー時代に培ったマネージメントやチームワークは仕事にも当てはまることが多いと感じます。

私は様々なプレイヤーを指導したりリーダとして率いることが多かったので、ゲーマー時代に自分がどう行動してたか + それを仕事に照らし合わせて雑多に書いてみたいと思います。

自己紹介

私はCS1.6 (Counter Strike 1.6)の2012年アジアチャンピオンになった者です。

このゲームは私が高2のときくらいからやってました。

いろんなチームを渡り歩き、大半はリーダーとしてチームを指揮したりマネージメントする役目をやってました。

otya-milk.blog.jp

このCLARING STYLEが私本人です。

CS 1.6とは?

f:id:sion_cojp:20181210204710p:plain

現在だとCS:GO(Counter Strike Global Offensive)が後継のバージョンになります。

FPSというジャンルで、5 vs 5の銃で打ち合う戦い。

1:45sの間に、テロリストがC4(プラスチック爆弾)を所定の場所に爆破するか、どちらか壊滅させたら1round終了。

合計16ラウンド先に取ったら勝利です。

この1:45sという時間が恐ろしく短く、めまぐるしく考えを働かさないと一瞬で負けてしまうのがこのゲームの楽しさです。

本題

メンバーを適したポジションに配置する

f:id:sion_cojp:20181210215555p:plain:w220

スナイパー、仲間をフォローする、最後まで生き残るc4を運んで設置する....など様々なポジションがありました。

まずはチームメンバーにやりたいポジションを聞き、できる限り反映させます。

理由は、やりたいポジションを任せた方が責任感が生まれるからです。

その上で、個人の特徴を生かして「こういう役割、動き方をして欲しい」と伝えたり、ポジショニングの指導をします。

仕事に対してもやりたいことをさせたほうが責任感が生まれます。

その上で「こういうことをして欲しい」と伝えると本人もやる気になってくれるでしょう。

最高は「言わなくてもそのポジションを理解して勝手に行動してくれる」です。

報告はできる限りシンプルかつ明確に

f:id:sion_cojp:20181210220848p:plain:w220

よくある初心者の場合だと、「撃たれてる!いてて!なんか遠くで撃って来てる」とかですかね。

この報告を聞いて味方はどうすればいいか分からないですよね。

例えば、「階段に2人いた」という報告は重要なのか?という議論をよくしました。

結論は、「重要ではない、があると嬉しいかも」です。

敵がここから攻めてくるか引くのか分からない報告だからです。

ベストは「1人カバーに来て欲しい」。これなら敵がどうしようが、仲間がどうして欲しいかわかるので行動しやすいです。

このように指示と行動がシンプルかつ明確になってるほど、お互いが連携しやすいです。

これは仕事や特に障害対応、ドキュメント(手順書)で言えることですね。


ちなみに、最初の問いですが、さらにベストの「何も言わなくても100%伝わる」を私たちは目指してました。

報告に感情は不要

f:id:sion_cojp:20181210220210p:plain:w220

あるあるだと「くっそ!あいつむかつくわ!うぜー!」とかですかね。

この報告を聞いて味方は....ry

「報告に感情は不要だ」と私はよく指導してました。

怒らない

f:id:sion_cojp:20181210215839p:plain:w220

怒っても何も解決はしません。

私自身若い時はよく怒ってました。が、この結論に至りました。

(精神を保つために、「自分が5人倒さなかったから負けた」と言い聞かせたりしてました)

よくあるよねーってスルーしたり、「なぜそうなったのか?」「そういう行動をしてしまったか?」というのを議論しあい解決に導くのが最善です。

「なんで言ったのに理解できないの?」 -> 難しいよね〜、また教えるね

「なんで何回も同じ場所でミスるの?」 -> 何か原因ある?違う方法だとミスらない?

といった感じ。

あえて失敗させる

f:id:sion_cojp:20181210220017p:plain:w220

上の議論しあってるときに、意見がまとまらない場合があります。

例えばあるポイントに投げるグレネードが絶対必要だ、必要じゃないなど。

その場合は全部やるのが筋です。そこで失敗を経験してなぜ失敗したのかを理解します。

そうしないと実践で応用ができないからです。

またあえて失敗させる誘導をすることもあります。

そうしないと理解ができないからです。

(今の子たちはペヤングを一度もこぼすことはないでしょうし、その事実を知らないでしょう)

失敗は大事な糧なので、出来る限り失敗出来る時にいっぱい失敗させるチームにしてました。

讃え合う

f:id:sion_cojp:20181210215924p:plain:w220

先ほど報告に感情は...と言いましたが、1killとった時の「ナイス」などの賞賛は大事です。

理由はその場の雰囲気、士気がよくなるからですね。人間味ありますね。

slackやPRでいう :thumbsup: だと思ってます。

ルールはシンプルに最小に

f:id:sion_cojp:20181210223534p:plain:w220

日本人はガチガチの作戦で固めてくるチームが多かったのですが、それが4人以上限定とかグレネードの個数限定だったりしました。

敵の奇襲で3 vs 3とかになってしまうと、誰も次の行動を考えれなくなって時間切れになったりします。

私たちのチームは、作戦を設けず、自分たちで考えて行動させました。

その方が敵のアクションに柔軟に対応できます。

その場で、「こうしてここを攻めよう」と誰かが作戦を発言して行動を起こします。

またそこでのルールとして、「指揮官のいうことが絶対。それ以外は早めに言ったやつを優先」というルールでした。

「で、誰のを従うの?」っていうコミュニケーションコストの発生を避けたかったからです。


状況は一番メンバーがわかってます。仕事もそうですが、ルールを最小限にし、メンバーに権限を委ねた方が、スピーディーにスムーズに事が進みます。

自分たちで考えさせる

f:id:sion_cojp:20181210220059p:plain:w220

最高は「言わなくてもそのポジションを理解して勝手に行動してくれる」です。

少数精鋭の場合、マネージメントなんてない方が最高です。

彼ら自身が言葉を交わし合い、共通の目標に向かって行く方がベストです。


仕事でも少数精鋭の場合はマネージャーがいかにセルフマネージメント出来るようになるか、ポイントを指摘していくのが良いかと思います。

全体的に見渡すレベルを目指す

f:id:sion_cojp:20181210221044p:plain:w220

まずメンバーより下の実力だとダメです。「おれより弱いやつが」と言われたら終わりです。

(それ以上の何かしら尊敬の念があれば問題はない)

仕事でいうと、エンジニアなのに勉強することをやめたり、プログラム書く事を諦めてる人は部下に舐められる可能性が高いです。


次に、メンバーと同じ目線だと、いつまでも実力が水平です。

これではさらなる高みは目指せません。


私は全体を見回して、このチームがどうなったら強くなるかを考えてました。

例えばBサイドが抜かれやすかったらBサイドの研究をします。

それはBサイドのメンバーも研究してると思いますが、彼らは「連携や練習」という私より余分な時間が発生します。

その間に海外の動きをチェックし、良いものがあれば「このチームこういう動きをしてたから取り入れてもいいかもよ」と伝えることができます。

あとはプロフェッショナルな彼らに任せればいいです。そして存分に高みを目指してもらいましょう。

信頼する、言い過ぎない

f:id:sion_cojp:20181210221535p:plain:w220

例えば、「Flash Bomb欲しい」と言って、くれなかったとき。仲間は敵と交戦してるかもしれないです。

状況は仲間にしかわかりません。

Flash Bomb欲しい」を5回くらい連呼されたら相手も「わかってるようっせーな!交戦してんだよ!」ってなるでしょう。

フラストレーション貯めるのは色々と支障が出ます。

出来る限りフラストレーションためないよう言い過ぎないように、相手を信頼して待ちましょう。

待つのは不安になったり、精神辛かったりしますが、我慢ステータスを身につけましょう。

待った上でチームが議論し、それでもうまくいかない場合はリーダーが一言指摘しましょう。

時間を決めて練習する

f:id:sion_cojp:20181210231825p:plain:w220

時間を決めないとダラダラとやります。また長時間やらないように気をつけます。

事前に伸ばしたいポイントを決めておいて、短い時間で、サクッと練習する方が身になります。

仕事でいう、残業はもちろん、短時間で集中したほうがいいよね。というお話です。

最後に

リーダーはいいチームを作るための一つです。

もちろんメンバーもいてこそです。

お互いが尊敬しあい同じ目標に行くのはゲームの世界も仕事の世界も同じだなと思います。

FOLIOモバイルアプリのインフラ構成のお話

明日、弊社で SRE Lounge #6 - connpass というイベントがあるのですが、 残念ながら登壇する枠がないのでスライドだけ公開しました。

世間体ではGKEのお話が多い中、Fargateのお話です。

Fargateはクラスタの管理が不要な分、とても楽に運用出来て結構幸せだったりします。

当日興味がある方は是非お声がけください〜。

speakerdeck.com

clairでローカルのDockerイメージの脆弱性スキャン

clairとは?

github.com

CoreOSが作ってる、コンテナの脆弱性スキャンツールです。

CVEデータをpostgresに入れて(定期更新される)、それを元にスキャンします。

ローカルイメージをスキャン

github.com

CoreOSが提供してた、analyze-local-imagesはdeprecatedだったので、

https://github.com/arminc/clair-scanner を使って、ローカルのイメージをスキャンしてみました。

実行

# clair-scannerをインストール
$ make clair-scanner/install

# clairサーバとpostgresを起動
$ make clair/run

# 起動してから10 ~ 20分くらいでCVEデータが更新されます。それまで待機
# postgresに入ってるCVEデータの量を見たいときは
$ make check

# golang:1.10をスキャン
$ docker pull golang:1.10
$ make run IMAGE=golang:1.10
clair-scanner --ip=host.docker.internal golang:1.10
2018/10/04 14:53:39 [INFO] ▶ Start clair-scanner
2018/10/04 14:53:59 [INFO] ▶ Server listening on port 9279
2018/10/04 14:53:59 [INFO] ▶ Analyzing 4f68522e312f5f12340e4b9559e71bba43ef929a10efc9ea6b67b4ff33bfb82e
2018/10/04 14:54:02 [INFO] ▶ Analyzing f56aeae9371b6c04ca4cf57a326b42de8c0d08a5fdebb26ef6b8df324337ea72
2018/10/04 14:54:02 [INFO] ▶ Analyzing 66f389e10325cd0c5f124eba8c5e9b57a9d490a5ddfa02a38f92686d04bda898
2018/10/04 14:54:03 [INFO] ▶ Analyzing 070ca363ac71db895b70015f3c83a1b09a42e74a52b9afdddd15e8aab4dd4a4a
2018/10/04 14:54:06 [INFO] ▶ Analyzing 13d63372391595f4c4086f342f2d0205542ba4530ec95fb8bd069bc7a19dea5e
2018/10/04 14:54:10 [INFO] ▶ Analyzing bf50139cdff0a2429fdf26ed2464b30ec6c88adf24d973ac5a6ed046283ee397
2018/10/04 14:54:20 [INFO] ▶ Analyzing b16a12b1f36856e47d3cea6f2141b970f4b383c6b5302189b3dd452ce9389af9
2018/10/04 14:54:20 [WARN] ▶ Image [golang:1.10] contains 288 total vulnerabilities
2018/10/04 14:54:20 [ERRO] ▶ Image [golang:1.10] contains 288 unapproved vulnerabilities

+------------+-----------------------------+-----------------+-----------------------+--------------------------------------------------------------+
| STATUS     | CVE SEVERITY                | PACKAGE NAME    | PACKAGE VERSION       | CVE DESCRIPTION                                              |
+------------+-----------------------------+-----------------+-----------------------+--------------------------------------------------------------+
| Unapproved | High CVE-2018-6485          | glibc           | 2.24-11+deb9u3        | An integer overflow in the implementation of the             |
|            |                             |                 |                       | posix_memalign in memalign functions in the GNU C Library    |
|            |                             |                 |                       | (aka glibc or libc6) 2.26 and earlier could cause these      |
|            |                             |                 |                       | functions to return a pointer to a heap area that is         |
|            |                             |                 |                       | too small, potentially leading to heap corruption.           |
|            |                             |                 |                       | https://security-tracker.debian.org/tracker/CVE-2018-6485    |
+------------+-----------------------------+-----------------+-----------------------+--------------------------------------------------------------+
| Unapproved | High CVE-2018-1000001       | glibc           | 2.24-11+deb9u3        | In glibc 2.26 and earlier there is confusion in the          |
|            |                             |                 |                       | usage of getcwd() by realpath() which can be used            |
|            |                             |                 |                       | to write before the destination buffer leading to            |
|            |                             |                 |                       | a buffer underflow and potential code execution.             |
|            |                             |                 |                       | https://security-tracker.debian.org/tracker/CVE-2018-1000001 |
+------------+-----------------------------+-----------------+-----------------------+--------------------------------------------------------------+

まだまだCVEの詳細な情報が流れてくるが、量が多いため割愛します

# clairサーバのログが見たいときは
$ make tail

# clairサーバとpostgresのコンテナ削除
$ make clair/rm

所感

プロダクトに入れる前には脆弱性スキャンしたほうが良いですね。

High/Medium/Low/Negligible/Unknown で区別してくれるので、最低でもHighはチェックしましょう。

また、clair-scannerは -w でwhitelist指定出来るみたいなので、自前でwhitelistを持ってると良いかもですね。

ただこれらもイメージpush先のリポジトリ側でスキャンされるのが理想であり、デファクトスタンダードになるでしょう。

GCRはα版がすでに提供されており、ECRもいずれ自動でスキャンして通知してくれるでしょう。

ディレクトリ配下にある.tfファイル全てにterraform planをGoで並列実行する

FOLIO特有のロジックが入ってますが、参考になればと思います。

terraformのディレクトリ構成

FOLIOのterraformはこんなディレクトリ構成になってます。(一部抜粋)

── envs
   ├── mobile-prod
       ├── provider.tf       
       ├── ecs
       ├── iam
       ├── route53
       └── vpc
          ├── backend.tf
          ├── provider.tf
          ├── route_table.tf
          ├── variables.tf
          └── vpc.tf
   ├── mobile-stg
   ├── sandbox
   ├── web-prod
   └── web-stg
── global.tfvars
── backend_tf_template

global.tfvarsは全体の変数定義。(CIDRやIPリストなど)

provider.tfは各環境内の設定です。(subnet_idなど)

planの実行

terraformのオペレーションはMakefileで管理されてます。

下記のコマンドで特定のディレクトリに対してplanが実行できます。

$ make plan CONFIG=envs/mobile-prod/vpc
# initializeした後、terraform plan -var-file=global.tfvarsを打ってるだけです

今回作ったもの

  • ディレクトリを再帰的に検索して、xxx.tfがある場所でmake planを並列実行する
  • backend.tfとprovider.tf以外が対象
  • 差分がある or 問題が起こったら出力する
    • 具体的には、 No changes. Infrastructure is up-to-date というワードがなかったら出力
  • -n で並列数を選べる
  • -tディレクトリ指定も出来る
  • 常に差分が発生するものに対しては、ignorePlanで除外出来る
    • (そんなに変更するものじゃないので、ハードコーディング)
$ ./check-all-plan --help
Usage of ./check-all-plan:
  -n int
        並列数 (default 20)
  -t string
        ターゲット。ex: -t mobile-stg

$ ./check-all-plan
check-all-plan: 2018/09/21 13:49:47 [INFO] Check start......
check-all-plan: 2018/09/21 13:52:37 [INFO] Result: you need check below
make plan CONFIG=envs/mobile-stg/kinesis
make plan CONFIG=envs/web-prod/elasticache
make plan CONFIG=envs/web-prod/teleport
make plan CONFIG=envs/web-stg/iam
make plan CONFIG=envs/web-prod/instances
make plan CONFIG=envs/web-stg/network
make plan CONFIG=envs/web-stg/kinesis

ソースコード

package main

import (
    "flag"
    "fmt"
    "log"
    "os"
    "os/exec"
    "path/filepath"
    "strings"
    "sync"
)

const (
    APP = "check-all-plan"
)

var (
    // parallelNum ... 適当に20並列にしてる。
    parallelNum = 20

    // target ... envs/mobile-stgのように、ターゲット単位で指定出来るようにしてる
    target string
)

// init ... set flag
func init() {
    flag.IntVar(&parallelNum, "n", 20, "並列数")
    flag.StringVar(&target, "t", "", "ターゲット。ex: -t mobile-stg")
    flag.Parse()
}

func main() {
    log.SetOutput(os.Stderr)
    log.SetPrefix(APP + ": ")

    os.Exit(Run())
}

// Run ... 実行
func Run() int {
    // 結果を格納するslice
    var results []string

    // skipするディレクトリ。必要だったら修正してね!
    ignorePlan := []string{
        "sandbox",
        "web-prod/apps",
        "web-stg/apps",
    }

    // planを実行するdirの取得
    targetDirs := GetDir("envs", ignorePlan)

    // default: 20並列
    var m sync.Mutex
    wg := &sync.WaitGroup{}
    semaphore := make(chan struct{}, parallelNum)

    log.Println("[INFO] Check start......")

    for _, targetdir := range targetDirs {
        wg.Add(1)
        semaphore <- struct{}{}
        go func(d string, m *sync.Mutex) {
            defer func() {
                <-semaphore
                defer wg.Done()
            }()
            out := RunTerraformPlan(d)
            if !strings.Contains(out, "No changes. Infrastructure is up-to-date") {
                m.Lock()
                defer m.Unlock()
                results = append(results, d)
            }
        }(targetdir, &m)
    }
    wg.Wait()

    log.Println("[INFO] Result: you need check below")
    for _, result := range results {
        fmt.Printf("make plan CONFIG=%s\n", result)
    }

    return 0
}

// RunTerraformPlan ...make plan CONFIG=xxxxを実行する
func RunTerraformPlan(targetDir string) string {
    dir := fmt.Sprintf("CONFIG=%s", targetDir)

    // make plan打って差分 or 問題が起こったかを検知したいので、
    // ここではエラーハンドリングしない
    out, _ := exec.Command("make", "plan", dir).Output()
    return string(out)
}

// GetDir ...envs/配下の実行対象のディレクトリを取得する
func GetDir(parentDir string, ignorePlan []string) []string {
    var dirs []string
    err := filepath.Walk(parentDir, func(path string, info os.FileInfo, err error) error {
        if err != nil {
            return err
        }

        // 隠しディレクトリはskip
        if info.IsDir() && strings.HasPrefix(info.Name(), ".") {
            return filepath.SkipDir
        }

        // ignorePlanに書かれてるディレクトリ以下をskip
        for _, v := range ignorePlan {
            if info.IsDir() && path == fmt.Sprintf("envs/%s", v) {
                return filepath.SkipDir
            }
        }

        // backend.tfとprovider.tf以外のtfを持つディレクトリを抽出
        switch info.Name() {
        case "provider.tf":
            break
        case "backend.tf":
            break
        default:
            if strings.HasSuffix(info.Name(), ".tf") {
                dirs = append(dirs, filepath.Dir(path))
            }
        }

        return nil
    })

    if err != nil {
        log.Printf("[WARN] filepath.Walk: %s\n", err)
    }

    return getUniqueDirs(dirs)
}

// getUniqueDirs ...重複したデータを削除。targetが指定されてたら指定されたものだけをチョイス
func getUniqueDirs(src []string) []string {
    dst := make([]string, 0, len(src))
    m := make(map[string]bool)

    for _, s := range src {
        if _, ok := m[s]; !ok {
            m[s] = true
            // targetが指定されたら、指定されたものだけをappendする
            if target != "" {
                if strings.HasPrefix(s, fmt.Sprintf("envs/%s", target)) {
                    dst = append(dst, s)
                }
            } else {
                dst = append(dst, s)
            }
        }
    }
    return dst
}

terraform-provider-awsの開発からPRを出すまでの手順

github.com

些細ではありますが、出したPRがmergeされました。

開発方法よくわからないなぁ。と思う人が多いと思うので、私が実際に行ったことを書いて見ます。

開発方法

# go get。今回は本家で修正して試して、その差分をあとでfork先に適用する感じ。
# この二度手間めんどくさいときは、$GOPATH/src/github.com/terraform-providersにforkしたやつをgit cloneしたほうが良い
$ go get -u github.com/terraform-providers/terraform-provider-aws

# よしなに修正

# buildする
$ cd $GOPATH/src/github.com/terraform-providers/terraform-provider-aws
$ make build
# このときgofmtしろってエラーが出たらgoのバージョンが低い可能性があります
# 最新にしてまたやってみましょう

# buildしたものを利用する
# 既存のproviderを削除して自前のbuildをcopy。copyしたらinitを打つ
$ cd terraform-repository/xxxxx.tfファイルがあるところ
$ rm -f .terraform/plugins/darwin_amd64/*
$ cp $GOPATH/terraform-provider-aws .terraform/plugins/darwin_amd64
$ terraform init

# planとapply。global.tfvarsを設定してるバージョンです
$ terraform plan
$ terraform apply -var-file=global.tfvars

# debugログの出力。めっちゃ便利
# TF_LOGでloglevelが設定できます
# TF_LOG_PATHでファイルに出力できます(追加保存)
$ TF_LOG=1 TF_LOG_PATH='/tmp/terraform.log' terraform apply -var-file=global.tfvars

test

PR出す際に貼らないといけません。 結構な権限を持ったaccess_key, secret_keyが必要です。

# 移動してtest。TESTARGSに設定するのはmethod名。*で正規表現マッチが使えます
$ cd $GOPATH/src/github.com/terraform-providers/terraform-provider-aws
$ AWS_ACCESS_KEY_ID=xxxx AWS_SECRET_ACCESS_KEY=xxxx make testacc TEST=./aws TESTARGS='-run=TestFetchRootDevice*'
# このときgofmtしろってエラーが出たらgoのバージョンが低い可能性があります
# 最新にしてまたやってみましょう