vendoring が無くなると Go x Github private repo x Docker 運用が地味に面倒になって困る話 (未完)
- 1. vendoring が無くなると Go x Github private repo x Docker 運?用が地味に?面倒になって困る話 (未完) Itsuki Sakitsu
- 3. とある骋辞プロジェクト
- 5. コードは 別のGithub private repoにも依存 想定ケース ? マイクロサービスが相互のgrpcサービスクライアントを参照 ? ?自作ライブラリを切り出してprivate repoで管理理
- 6. 素直にDocker?leを書くと… Go get -d -v ./… がfail
- 8. →认可情报を渡せばよい？
- 12. depは何をしてくれるのか？ 使い?方は `brew install dep` してから `dep init` とか `dep ensure` するだけ 1. Gopkg.lock による依存バージョンの管理理 2. 同時に全依存コードを リポジトリ直下の vendorフォルダ以下に永続化してくれる ? Private repoからのダウンロードもマシンローカルの認可情報を使うので当然普通に動く
- 13. dep導?入後のDocker?le ? 事前に dep ensure を実?行行、COPY . . でvendorフォルダごと?一括でCOPYする ? 不不必要に認可情報を取り回す必要なし ? Docker?leもビルドコマンドもスッキリ ※コード改変毎に go getが?走るが、実質ダウンロードは発?生しない
- 16. ところがどっこい…
- 20. dep導?入後のDocker?le ? 事前に dep ensure を実?行行、COPY . . でvendorフォルダごと?一括でCOPYする ? 依存コードが全てあるので後続のgo getは実質不不要 ? 認可情報も渡す必要がなくなり、Docker?leも起動コマンドもスッキリ ? コード改変毎に go getされてしまうが、動くのはCOPYだけなので実害なし
- 21. →go mod vendor で当座を凌ぐ 意訳：Go mod vendorコマンドを実?行行すれば vendor 配下にビルドとテストに必要な全依存を 永続化するやで
- 22. 1. おとなしくgithub認可トークンをdocker?leに??食わせる？ ? 適切に運?用すればセキュリティ懸念も少ないはず ? ビルド専?用のアカウントとトークンを?用意するとか 2. Go build処理理はいっそローカルで実?行行？ ? Go versionなど、ビルド環境?自体に差分が?生まれる懸念が 3. $GOPATH直下でdocker buildして /pkg/mod 配下を COPY でぶち込む？ ? Docker build毎に cd させられるのが流?石にちょっと… 4. Github enterpriseを使う？ ? そもそもprivate repoを使うことをやめればよいのだ 最終的なベスプラは?見見えぬまま