kubernetes学習その４ GCRの認証

　Dockerイメージの保管場所としてGoogle Container Registry(GCR)を用いる場合、同じプロジェクト内の例えばGoogle Container Engine(GKE)なんかでpullする分には認証も要らないのだけど、開発環境としてminikubeだったり他の場所でk8sを動かしたりしている場合には認証を行う必要がある。

blue1st-tech.hateblo.jp

　個人アカウントでの認証を用いる場合とサービスアカウントを発行して用いる場合の２通りを示した。

個人アカウントを用いる場合

　予めgcloudコマンドで認証を済ませた上で、そのトークンをsecretに登録して使用する。

$ kubectl --namespace=$NAMESPACE create secret docker-registry gcr

--docker-server=https://gcr.io

--docker-username=oauth2accesstoken

--docker-password="$(gcloud auth print-access-token)"

--docker-email="$(gcloud auth list --filter=status:ACTIVE --format='value(account)')"

$ kubectl --namespace=$NAMESPACE patch serviceaccount default

-p '{"imagePullSecrets": [{"name": "gcr"}]}'

　このトークンは期限があって一定期間で無効化されるようなので、長期的に使う場合にはたまに明示的に削除した上で再生成してやる必要がある。

$ kubectl --namespace=$NAMESPACE delete secret gcr

サービスアカウントを用いる場合

　CIなんかで恒常的に使う場合はサービスアカウントを発行して用いる。

Configuring Access Control  |  Container Registry  |  Google Cloud Platform

$ kubectl --namespace=$NAMESPACE create secret docker-registry gcr-json-key

--docker-server=https://gcr.io

--docker-username=_json_key

--docker-password="$(cat $PATH_TO_JSON)"

--docker-email="$MAIL_ADDRESS"

$ kubectl --namespace=$NAMESPACE patch serviceaccount default

-p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

docker-email項のメールアドレスにはJSONファイルに記載されたものを用いる。

　そういえば今月のWeb+DB PressはK8sの記事があるみたいですな。著者のブログ読む限りだとかなり共感できる感じで、初手の段階で欲しかった情報が押さえられてそうな雰囲気なんで、これからK8s使ってみようという層は要チェックかなと。

WEB+DB PRESS vol. 99でKubernetes/GKEの記事を書きました。 – Daisuke Maki – Medium

“Kubernetes内で使われている用語とそのコンセプトを理解してからでないとドキュメントが意味不明”“マルチクラウド対応のために抽象化されていてわかるような、わからないような、微妙な感じ”この辺めっちゃ共感

2017/06/19 16:14

WEB+DB PRESS Vol.99