Gopher道場#3 LT会資料

1. vendoring が無くなると
Go x Github private repo x Docker
運⽤用が地味に⾯面倒になって困る話 (未完)
Itsuki Sakitsu

2. ⾃自⼰己紹介：猟師系webエンジニア

3. とあるGoプロジェクト

4. コードはGithub private repoで管理理

5. コードは
別のGithub private repoにも依存
想定ケース
• マイクロサービスが相互のgrpcサービスクライアントを参照
• ⾃自作ライブラリを切り出してprivate repoで管理理

6. 素直にDockerfileを書くと…
Go get -d -v ./… がfail

7. Dockerイメージに
認可情報が無いので通信拒否

8. →認可情報を渡せばよい？

9. 動くが…どうなんだろう？
—build-arg等を利利⽤用してGithub認可トークンを渡し、.netrcに保存
• github認可トークンは「アカウント」単位、無関係な個⼈人リポジトリも参照可
• ビルド専⽤用のgithubアカウント発⾏行行…？

11. 救世主：depの濫⽤用
(実質vendoring)

12. depは何をしてくれるのか？
使い⽅方は `brew install dep` してから `dep init` とか `dep ensure` するだけ
1. Gopkg.lock による依存バージョンの管理理
2. 同時に全依存コードを リポジトリ直下の vendorフォルダ以下に永続化してくれる
• Private repoからのダウンロードもマシンローカルの認可情報を使うので当然普通に動く

13. dep導⼊入後のDockerfile
• 事前に dep ensure を実⾏行行、COPY . . でvendorフォルダごと⼀一括でCOPYする
• 不不必要に認可情報を取り回す必要なし
• Dockerfileもビルドコマンドもスッキリ
※コード改変毎に go getが⾛走るが、実質ダウンロードは発⽣生しない

14. vendorフォルダごと渡すため
githubとの通信は不不要

16. ところがどっこい…

17. Dep → vgo移⾏行行の流れ？

18. vgoでは依存の永続化先が変わる
$GOPATH/pkg/mod配下で⼀一括管理理
• vendorフォルダは使わない
• 環境全体で⼀一括管理理するのでリソース効率は良い

19. Go公式もvendoringは無くしたい
というお気持ち (当⾯面は残すとか)
意訳：vendoring消そうと思ってたけどフィー
ドバック⾊色々あったから残すことにはしたよ

20. dep導⼊入後のDockerfile
• 事前に dep ensure を実⾏行行、COPY . . でvendorフォルダごと⼀一括でCOPYする
• 依存コードが全てあるので後続のgo getは実質不不要
• 認可情報も渡す必要がなくなり、Dockerfileも起動コマンドもスッキリ
• コード改変毎に go getされてしまうが、動くのはCOPYだけなので実害なし

21. →go mod vendor で当座を凌ぐ
意訳：Go mod vendorコマンドを実⾏行行すれば
vendor 配下にビルドとテストに必要な全依存を
永続化するやで

22. 1. おとなしくgithub認可トークンをdockerfileに⻝⾷食わせる？
• 適切に運⽤用すればセキュリティ懸念も少ないはず
• ビルド専⽤用のアカウントとトークンを⽤用意するとか
2. Go build処理理はいっそローカルで実⾏行行？
• Go versionなど、ビルド環境⾃自体に差分が⽣生まれる懸念が
3. $GOPATH直下でdocker buildして /pkg/mod 配下を COPY でぶち込む？
• Docker build毎に cd させられるのが流⽯石にちょっと…
4. Github enterpriseを使う？
• そもそもprivate repoを使うことをやめればよいのだ
最終的なベスプラは⾒見見えぬまま