コロナ渦によってリモートワークになった人々が増えたと思うんだけどstaging環境どういうふうに構築してるんだろう. どういうふうにっていうのはアクセス制限とかの話なんだけど, オフィス出社だったらオフィスのIPだけ許可すれば良かったけどリモートになると開発者の家のIP全部許可するのは現実的じゃないよねって話についてね. とりあえず今私が考えてるのはこのへん. おとなしくVPNを利用する. gsuiteを利用してoauth2認可できるようにする. k8s化してポートフォワーディングさせる AWSに乗っかってるのでssmでポートフォワーディングする 今のところは 2, 4かなって感じなんだけど2だとapiみたいなのにcurlするときに少しだけめんどくさいかなって思って4をやってみようかって思っている. ssmのポートフォワーディングってfargateにつなぎに行けるんだっけ?
最近話題になってる脆弱性検知ツールのtrivyを利用した. 流れてきには次のような感じである. docker imageのbuild trivyでのscan okだったらregistryにpush trivyはそのままスキャンすると検出してもしなくても exit code として 0 を返す. CircleCI上で検出したときに落とす時は 0 以外を返す必要がある. なので --exit-code 1 を指定する. 好みの問題ではあるが重要度の低い脆弱性は一旦出さないようにしている. --severity HIGH,CRITICAL のように指定すると HIGH , CRITICAL のみを検出できる. OSに入ってるlibraryに脆弱性が存在しているがまだ対応しているバージョンがないというときがある. そういうものを出されても対応ができないので検出しないようにしている. --ignore-unfixed と指定することで対応バージョンが存在しないものを検出結果から除外できる. 実際に利用しているオプションはこうである. $ trivy --exit-code 1 --quiet --severity HIGH,CRITICAL --auto-refresh --ignore-unfixed -c --auto-refresh $DOCKER_IMAGE_REPO:$CIRCLE_BRANCH
ログインユーザーにもcacheを効かせたいときがある. その時はjwt tokenの値を利用してcacheを作れば良い. jwt tokenの名前を jwt_token しよう. まずjwt tokenから値を抜き出す. sub vcl_recv { if (req.http.Cookie ~ "jwt_token=.*") { set req.http.X-TOKEN = regsub(re.group.0, "\;.*", ""); } } 次にcacheのkeyとなるhashを生成する. sub vcl_hash { if (req.http.X-TOKEN) { set req.hash += req.http.X-TOKEN; } set req.hash += req.url; } これでjwt tokenを利用してcacheが作られます. ちなみにログインのたびにjwt tokenは変わるのでログインごとにcacheが破棄されるような挙動になる.
Vary header の内容が冗長性のあるときがある. 例えばこんな感じ Vary: User-Agent, Accept-Encoding, User-Agent とか. こういうのを Vary: User-Agent, Accept-Encoding か Vary: Accept-Encoding, User-Agent したい. かぶってるのを消して追加してしまえば良い. sub vcl_fetch { if (beresp.http.Vary ~ ".*User-Agent.*User-Agent.*") { set beresp.http.Vary = regsuball(beresp.http.Vary, "(,\s*)?User-Agent", ""); set beresp.http.Vary = regsuball(beresp.http.Vary, "^(\s)?(,(\s+)?)+", ""); } if (bresp.http.Vary ~ "^(\s)*$") { set bresp.http.Vary = "User-Agent"; } else { set bresp.http.Vary = bresp.http.Vary + ", User-Agent"; } }
私はGo言語でapiを実装するときしばしばgin-gonic/gin を利用します. マイクロサービスとかでapiが死んだときの検証は結構たいへんです. なのでapiが死んだ状態を再現すべく, gin製のアプリケーションがランダムに 404 とか 503 をランダムに返せるようにするMiddlewareを作成した. alcoholics カオスモンキーとかみたいな利用用途を考えている.
たとえばこんな感じ. $ go env | grep GOPATH GOPATH="/Users/johndoe/go/1.12.0" この仕様になったのに気がついたのはgoの1.12が出た頃だ. 別にgoのversionごとにGOPATHを分けたいわけではないので $HOME/go にGOPATHを戻そうと思う. goenv/libexec/goenv-execでGOPATHを制御しているようで, GOENV_DISABLE_GOPATH=1 を指定すると以前のようにGOPATHを $HOME/go にすることができる.
~/.gitconfig に次の内容を記述する $ cat ~/.gitconfig [url "git@github.com:"] insteadOf = https://github.com/ GIT_TERMINAL_PROMPT=1 をつけて go get する $ go get プライベートリポジトリのパッケージ
GoのプロジェクトをDockerで動かすことがあると思う. 知らんけど. まぁきっとあるんだろう. ちなみに私は何度かある. 私がよく使うDockerfileの設定を書いておく. Dockerのimageをbuildするときに気を使うことが一つだけある. それはimageのサイズを小さくすることである. 何も考えずにGoのプロジェクトをbuildすると多分こんな具合だろう. FROM golang:latest WORKDIR /go/src/hogehoge.com/who/bar COPY . . RUN set -e \ && go build -o /bin/bar main.go WORKDIR / RUN set -e \ && rm -rf /go/src CMD ["bar"] 流石にここまで雑に書くことはなかなか無いだろうが, 一応ビルドして掃除までしている. だが小さくするには不十分である. まずGoのDocker imageがそれなりに大きい. 2018-12-12のlatestの段階で774MBある. $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE golang latest df6ac9d1bf64 3 weeks ago 774MB Goはシングルバイナリのビルド物を生成する. なので実行時にコンパイラは必要ない. GoのbaseになってるDocker imageはDebianである. なのでGoのdocker imageでバイナリを生成してDebianのimageにうつしてやればいいじゃんてなるだろう. Debianのlatestのimageは101MBである. 小さいように見えるがまだダイエットが可能である. alpine Linuxというもっと小さいDocker imageが用意されている....
12/7 (金) に長野県がやっているときどきナガノの制度を利用して長野県へ行ってきた. 長野県にはよく行く(今年20回くらい?)のだがときどきナガノを利用するのを忘れて普通に行ってしまうミスをしてしまう. 今回は忘れずに利用することができた. 行った場所は八ヶ岳とかの拠点で有名な茅野(今年5回目くらい)で茅野駅直結のワークラボ八ヶ岳を利用した. ここのコワーキングスペースのいいところは駅から近いのと御飯食べれるところが近い, 広いしwi-fi安定してるし人が少なくて静かだということである. とりあえず良い. 多分また利用する機会があるので良さはその時に書くとして, そこで何を作っていたかと言うとmessage queueを実装していた. queue worker式のシステムを構築するとき全体の処理速度を制限したい時がある. そのときworker側で制限するのは大変である. worker側でやるとするとworker同士が通信して誰かが全体の速度計算してみんなにこれ以上通信しないでねって教える必要がある. それは大変そうだし作りたくない. なのでqueueのほうで制限することにした. 作ったものはvalveMQというもので, 裏側がmysqlになっていてアプリケーション側はスケールすることができる. まだ試験的な実装なので設定項目とかは作り込んではいない. そういえばこれだけは言っておきたい. 八ヶ岳Octetのソフトクリームは絶対食べるべき.
これは結構前に作ったネタなんだけども, 何らかのアプリケーションをつくったとき設定をjsonだったりyamlで管理することがある. そのとき秘密情報は隠したいみたいな案件があったとする. 設定ファイルをまるごと暗号化してもいいが, jsonとかだとkeyは暗号化せずvalueだけ暗号化しておいたほうが管理上都合がいい時がある. というわけでcryptexというものを作った. cryptexはmap型のvalue部分のみを暗号化するパッケージである. cryptex自体がサポートする暗号化の手法はrsa暗号とAWSのKMSを利用した暗号である. type Encryptor interface を満たす実装をするとほかの暗号方式にも対応が可能であるように実装してある. 暗号化したり暗号化された情報を復号する機能の他にコマンドラインツールを実装したときに使えるように less で内容を確認する機能や任意のエディタを立ち上げ(デフォルトはnano)て編集する機能を提供している. 編集したりlessで確認するときはユーザーに暗号化と復号を意識しなくてもできるようにしている. 質問やバグ報告はissueから受け付けます. 英語でも日本語でも良い.