Stackdriverの設定をterraformで管理する

terraform Stackdriver GCP

今までアラートポリシーやカスタム指標などのStackdriverの設定をyamlやテキストで保存し、自作ツールで適用するようにしていましたが、自作ツールのメンテナンスが面倒になってきたのでterraformに移行することにしました。

移行にあたって、既存の設定ファイルは破棄し、terraformerを使って以下のように再作成しました。

1. 既存設定のインポート

PROJECT_ID="プロジェクトID"
BUCKET="gs://バケット名"
OUT="出力先ディレクトリ"
terraformer import google --resources=monitoring -o $OUT -p '{output}' --state=bucket --bucket=$BUCKET --projects=$PROJECT_ID

※terraformer v0.7.8の場合、terraform v0.12への対応ができていない部分があるので以下を行う必要があります

bucket.tfを修正
terraform 0.12upgrade を実行

※slack通知はauth_tokenがマスクされた状態だったので設定を削除し、terraform state rmで管理から外しました

2. カスタム指標の作成

terraformer v0.7.8はカスタム指標に対応していないため、gcloudコマンドで取得した内容を .tf に変換しました。

gcloud --project=$PROJECT_ID logging metrics list --format=json

このままだとterraform apply時に新規作成しようとしてエラーになってしまうため、terraform importでterraformの管理下に追加します。

3. 設定の適用

手元に一通りの設定が揃ったら適用します。

terraform fmt
terraform validate
terraform plan
terraform apply

※必須フィールドが無い場合はterraform apply時にエラーになるので個別に対応します

2019-07-27

Datastore Emulatorのエンドポイント

GCP

Cloud Datastore エミュレータは起動した後、gcloudコマンドではなくREST APIを使って操作するらしい。
が、そのあたりの情報が全然まとまっていなかったので本体の中をチラ見して必要そうなところを調べてみた。

cloud-datastore-emulator 2.1.0

Method	Path	Description
GET	/	OKを返すだけ
POST	/reset	データをリセットする*1
POST	/persist	データを永続化する*2
POST	/shutdown	datastore emulatorを落とす
POST	/_ah/admin/datastore	`/reset` と同じ
POST	/_ah/admin/quit	`/shutdownと同じ`

ユニットテストで使う際は--no-store-on-diskをつけて起動し、

テストケースごとに POST /reset
テストが終わったらPOST /shutdown

すると良さそう。

*1:--store-on-diskの場合はヌルポ

*2:--no-store-on-diskの場合はnot supportedが返ってくる

2019-06-14

素のVimでGoを書く時のテクニック

vim Go

gorillavim.connpass.com

にて、

外部ネットワークに繋がらない環境でvimとgoしか使えない

という縛りでライブコーディングをしてきました。

実際にそういう環境があるのか?という話はさておき、そのような状況でも以下を駆使してそこそこコードが書けます。

:%!gofmtでコードを整形できる
:r! go docの結果を適当なバッファに出力する
- Vim内でドキュメントが読める
- ドキュメントの内容をCTRL-NやCTRL-Pで補完できる
:set path+=$GOROOT/srcで標準パッケージを検索できるようにする
- :findなどで標準パッケージのディレクトリやファイルを開ける
- :grep*1 で色々と探せる
- 開いたファイルはただ見るだけではなく、補完の対象にもできる

作ったものはGET /fizzbuzz/:numberにアクセスするとFizzBuzzを返すというHTTPサーバです。

package main

import (
    "net/http"
    "strconv"
    "strings"
)

func fizzbuzz(w http.ResponseWriter, r *http.Request) {
    p := strings.TrimPrefix(r.URL.Path, "/fizzbuzz/")
    if p == "" {
        http.NotFound(w, r)
        return
    }

    n, _ := strconv.Atoi(p)
    if n < 1 {
        http.NotFound(w, r)
        return
    }

    switch {
    case n%5 == 0 && n%3 == 0:
        w.Write([]byte("FizzBuzz"))
    case n%5 == 0:
        w.Write([]byte("Buzz"))
    case n%3 == 0:
        w.Write([]byte("Fizz"))
    default:
        w.Write([]byte(p))
    }
    w.Write([]byte("\n"))
}

func main() {
    http.HandleFunc("/fizzbuzz/", fizzbuzz)
    http.ListenAndServe(":8080", nil)
}

ただ当日は1.のgofmtしか使いませんでした。
というのもスパルタンなVimmerに憧れており、元から自動補完は使っておらず、オムニ補完にもそこまで依存しないようにしていたので、このくらいのものであれば無くても特に困らなかったからです。

まあ常に役立つものではありませんが、覚えておくと何かの時に便利かもしれません。

*1:grepコマンドがない場合は:vimgrep

2019-05-18

App Engineのgo111用ディレクトリ構成

Go AppEngine

App Engine Standard EnvironmentでGo1.9を使う時は以下のように、リポジトリのルートをGOPATHとして設定し、appcfg.pyを使ってデプロイをしていました。

.
├── app.yaml
└── src
    └── app
        ├── glide.lock
        ├── glide.yaml
        ├── app.go
        ├── handler
        ├── ...
        └── vendor

app.go

package app

import (
        "net/http"

        "app/handler"
)

func init() {
        http.Handle("/", handler.New())
}

これがgo111のランタイムになると、main関数が必須になり、デプロイコマンドもgcloud app deployに変わります。*1

そのため、以下の条件を満たしつつ、どのようなディレクトリ構成にするのが良いのか考えてみました。

app.yamlのパスは変更しない
GOPATHをリポジトリごとに変更しなくても良いようにする
- src/appはpkgに変更
- app.goはpkg.goに変更
依存関係の管理にgo.modを使う
- リポジトリのルートに配置

1) ./main.goを作成する

.
├── app.yaml
├── go.mod
├── go.sum
├── main.go
└── pkg
    ├── handler
    ├── ...
    └── pkg.go

2) ./cmd/app/main.goを作成し、app.yamlのmainでパスを指定する

.
├── app.yaml
├── cmd
│  └── app
│      └── main.go
├── go.mod
├── go.sum
└── pkg
    ├── handler
    ├── ...
    └── pkg.go

この時、プライベートなパッケージ*2を使っているとCloud Buildで依存関係を解決できません。
対策としては、代わりにvendorを使う、もしくはgo.modのreplaceディレクティブを使う、のどちらかです。

しかし、vendorを使う場合にはgo.modを.gcloudignoreに追加し、GO111MODULEをoffにしないといけません。
また、go.modを使うにはGO111MODULEをonにしないといけません。
GO111MODULEはリポジトリをGOPATHの配下に置くか、外に置かでautoの時の値が変わるため*3、組み合わせが非常に複雑です。

まとめると次のようになります。

依存管理	リポジトリの場所	GO111MODULE	デプロイ可否
go.mod	GOPATH配下	auto(=off)	offだと使用不可
go.mod	GOPATH配下	on	OK
go.mod	GOPATH外	auto(=on)	OK
go.mod	GOPATH外	off	offにできない
vendor	GOPATH配下	auto(=off)	1)はOK、2)はNG
vendor	GOPATH配下	on	NG
vendor	GOPATH外	auto(=on)	NG
vendor	GOPATH外	off	offにできない

※確認する際にCloud Buildで使われたイメージはgcr.io/gae-runtimes/go111_app_builder:go111_20190503_1_11_9_RC00です

正しくgo.modを使えば問題なくデプロイできるため、replace対象のパッケージが管理できるのであればこちらを使うのが良さそうです。
ただ、replace対象のパッケージはgitのsubmodulesやsubtreeで管理することになり、それが煩雑になってしまう可能性があります。

そういった場合、現段階だと1)をGOPATH配下に置くのが無難です。
app.yamlでmainを指定することができませんが、今のプロジェクトでは必要なかったので以下のディレクトリ構成にすることにしました。

.
├── app.yaml
├── go.mod  // デプロイしない
├── go.sum  // デプロイしない
├── main.go
├── pkg
│  ├── handler
│  ├── ...
│  └── pkg.go
└── vendor  // `GO111MODULE=on go mod vendor` で作成

*1:https://cloud.google.com/appengine/docs/standard/go111/go-differences 参照

*2:GitHub Enterprise含む

*3:GOPATH配下: off、GOPATH外: on

2019-04-13

MojaveでGDB 8.3を使う

Mac gdb

1. インストール

brew install gdb --HEAD

2019/04/13時点でインストールされるバージョンは8.3.50。
2019/05/14以降は--HEAD不要。

echo "set startup-with-shell off" >> ~/.gdbinit

を実行するようにと表示されるが、ファイルの場所は$HOME/.config/gdb/initでも良い。

2. 証明書の作成

キーチェーンアクセスを起動し、メニューから

キーチェーンアクセス > 証明書アシスタント > 証明書を作成...

を選択。

以下を入力したら他はデフォルトのまま(期限は伸ばしておいても良い)ひたすら「続ける」を押していく。

名前: gdb-cert
証明書のタイプ: コード署名
✅: デフォルトを無効化

「ログイン」に作成されたgdb-certを「システム」にドラッグ&ドロップし、
証明書の情報を開いて「信頼」の「コード署名」を「常に信頼」に変更。

3. コード署名

gdb-entitlement.xmlを作成する。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.debugger</key>
    <true/>
</dict>
</plist>

署名する。

codesign --entitlements gdb-entitlement.xml -fs gdb-cert $(which gdb)

4. 設定を反映させる

sudo pkill taskgated

2019-03-16

goonのクエリをチューニングした時のメモ

GCP Go

App Engine(Go 1.9)でDatastoreからデータを取得するのにgoonのGoon.Runを使っていたが、プロパティを追加する改修*1をした後、 latencyが遅くなり、DatastoreでDeadline exceededが頻繁に発生するようになってしまった。

とりあえず該当するリクエストをStackdriver Traceで見てみるとdatastore_v3.Nextが7回ほど呼ばれていることがわかった。

まずはこの呼び出し回数を減らせば速くなるだろうと思い、Query.BatchSizeを設定してみたが、呼び出し回数に変化は無く、全く効果がなかった。
それも変だなと思い、試しにデバッグログを仕込んで1回の呼び出しでどれくらいのデータを取得できているのか見てみたところ、なんと90件くらいしか取得できていなかった。

ここまで改修前の状態を確認していなかったので念のため調べてみると、datastore_v3.Nextの呼び出し回数は5回、1回あたりのデータ取得件数は約120件だった。
このことから、原因はプロパティを追加したことでデータのサイズが増え、一度に取得できる件数が減ったことによるDatastoreへのアクセス増ということがわかった。

ということで次はMemcacheを使ってDatastoreへのアクセスを減らすようにしてみた。
方法としては今までのクエリにQuery.KeysOnlyを設定してキーだけを取得するようにし、本体はGoon.GetMultiで取ってくるというシンプルなもの。
しかし、これだと1000件のデータを取得しようとするとGoon.GetMultiがMemcacheにデータを格納する際に大量のメモリを消費してしまうため、エラーになったり、インスタンスが落ちるようになってしまった。
そこでGoon.GetMultiの呼び出しが100件ずつになるようにしてみたところ、エラーは解消されたように見えたが、どうやらMemcacheにデータが乗っておらず、常にDatastoreにアクセスしてしまっていた。
仕方なく50件まで減らしたら安定してキャッシュが効くようになり、ようやく速度が改善されるようになった。

そもそもデータ構造がイマイチっぽいので本来はそこから手を入れるのが良さそうだが、今からそれをやるのもなかなかに厳しい状況なので当分はこれでしのぐことになりそう。

*1:後で確認したらデータサイズが80%ほど増加していた...

2019-02-19

第1回ゴリラ.vimが開催されました

vim

2/18(月)にゴリラ.vim #1が開催され、スタッフ兼発表者として参加してきました。

gorillavim.connpass.com

スタッフになったのはvim-jpのslackでゴリラさんこと@gorilla0513さんがVimの勉強会をやろうとしているのを見かけ、これは前々から思っていた渋谷でVim勉強会をするチャンスなのでは!?と会場提供を申し出たのがきっかけです。

そして当初は発表するネタが思い浮かばなかったのでスタッフに専念するつもりでいたのですが、少し経っても発表者枠が空いており、かつメンバーがVimConf 2018のスピーカーばかりという状態だったため、これは自分も何か話した方が良いんじゃないかと考え、ここ最近使ったgotypeとgo-treeを基にVimと外部コマンドという発表をしてきました。

ちなみに発表・デモは@thincaさんのshowtimeとquickrunを使いました。

gorillavim.connpass.com

全体の発表内容としては、短い時間ながらも初心者向けから上級者向けまであり、とても充実したものとなっていました。
特に前半の発表は自分にもそういう時期があったんだよなぁ、と非常に懐かしい気持ちになりました。

その後、一通り発表が終わった後は懇親会となり、各々がVim トークでとても盛り上がっていました。

渋谷ヒカリエ弊社セミナールームにてゴリラ.Vimが開催されました。懇親会では神々によるvimrcの設定サポートなど、とても和気あいあいとした勉強会でした。開催に協力することができて大変光栄です :)#gorillavim #denatechstudio pic.twitter.com/8u6mFUjACM
— DeNA Tech (@DeNAxTech) 2019年2月18日

開催前からこのイベントは盛り上がる...という予感はありましたが、予想以上に盛り上がり、スタッフとしても発表者としても参加者としても、嬉しい限りです。

トレンド入り！！！！！
#gorillavim pic.twitter.com/UTUbpFpGXv
— ゴリラ (@gorilla0513) February 18, 2019

ということで、今回ご参加いただいた皆様、ありがとうございました。
次回も是非よろしくお願いします。
(#2は少し枠が増えています!)

gorillavim.connpass.com