GCP gcloud dockerコマンドが使えなくなった。
dockerのバージョン18.03までしかサポートしなくなったらしく、
gcloud docker
は使えなくなりました。
対応方法。
$ gcloud auth configure-docker
を実行します。
メモ
docker build -t asia.gcr.io/xxx/yyy . gcloud docker -- push asia.gcr.io/xxx/yyy
のような、２ステップでやってた人は、
docker build -t core-app . docker tag tag-name asia.gcr.io/xxx/yyy docker push asia.gcr.io/xxx/yyy
となる。
GKE(kubernetes) を超要約すると
GKEとは
まずは、これだけのイメージで触ってみると楽だと思う。
Dockerとかコンテナーの初学者や未経験者は、Dockerを1から学ぼうとする人がいるかもしれないが、 まずは触ってみた方がすごく早いと思う。
デプロイするまでの触りとしては、
- Dockerイメージを作る or 適当に選ぶ
- それを使ったPodを作るためのyamlファイル(manifesto)を作る。
- kubectl でデプロイする。
デプロイ kubectl create -f xxxx.yaml 削除 kubectl delete -f xxxx.yaml
ちょっと書いてある事複雑そうに見えるけど、下記を何も考えずにやってみると良いかも
Redis と PHP を使用したゲストブックの作成 | Kubernetes Engine のチュートリアル | Google Cloud
Kind
Deploy
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: sample
spec:
replicas: 1 # 生成するpodsの数
template:
metadata:
labels:
app: sample-app
spec:
containers:
- name: sample-app
image: xxx # podで動かしたいdocker image
imagePullPolicy: Always
env:
# 環境変数はこのブロックに記載
ports:
- containerPort: 8080
Service
apiVersion: v1
kind: Service
metadata:
name: sample-backend
spec:
type: NodePort
selector:
app: sample-app # 管理下にするpod名
ports:
- port: 80 # このサービスで受けるport番号
protocol: TCP
targetPort: 8080 # 管理podに投げるport番号
Ingress
HTTP(S) LB用のManifest
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: sample-ingress
annotations:
kubernetes.io/ingress.global-static-ip-name: xxxx # 予約している静的IP名
spec:
backend:
serviceName: sample-backend # 待機するサービス
servicePort: 80 # 待機するport
Google Cloud pubsub でハマった事。
ハマった事
クライアントライブラリからpublishして、messageidsが返却され成功しているのに、 subscriverで、メッセージが確認できない。
原因
同じ名前で、topicを消して、作り直した。
対応
一度消したトピック名は使わない。
django テストコード mock patch
テストコード ✕ mock ✕ patch
djangoでテストコード書くときに、APIにアクセスする処理をテストするために、mockでpatchした時のメモ。
def _call_api(self, send_data):
"""
api呼ぶだけの関数
:param send_data:
:return: response
"""
return requests.post(self.endpoint, data=send_data)
from unittest import mock
from django.test import TestCase
class ApiBatchTest(TestCase):
# アノテーションで、中身を変えたい関数を指定
@mock.patch('path.to.Class._call_api')
def test_api(self, mock_get):
# mock_get(引数)で、変更したい関数のmockを受取、return_value(戻り値)を好きな状態に書き換える
mock_get.return_value.status_code = 200
mock_get.return_value['status'] = 200
def json():
"""
期待するresponseのjson()の結果っぽく作った。
"""
return {
'result': {
'A': 0.5,
'B': 0.5,
'C': 0.5
},
'attention': 'test',
'status': 200
};
setattr(mock_get.return_value, 'json', json)
# 上記によって、テスト実行される関数の中身のstatus_codeや、response.json()が上記の内容となる。
Google App Engine(GAE) のdeployの話 Part3.1 ~デプロイに失敗しまくる話2~
以前、GAEのデプロイがあるタイミングからエラーループに見舞われると書いたんですが、
全くの勘違いというか、こちらの知識不足でした・・・
djangoで開発していたんですが、settingsのALLOWED_HOSTに、IPやらドメインを指定したことで、 GAEの監視チェックの疎通が失敗してしまうことが原因でした。
回避策は
ALLOWED_HOSTS = [
'*'
]
にすること。
監視のIPが、コロコロと変わるため、追加していっても同様のエラーが発生しました。
もし同じdjango使いの人のお役に立てれば幸いです。
【見落としてしまった原因】 発見が遅れたのは、エラーログをちゃんと見れてなかった(流れすぎてて見る気が失せてた)ためです。
deployが進行すると下記のようなログが出たタイミングでバージョン管理されているので
24e374a2929b: Pushed 52097cf6d5fa: Pushed f22232098317: Pushed 0456c72748aa: Pushed latest: digest: sha256:9723bc8ea076e9f6b0bc2aa8b01336ee3df639ae84433f7dce41c8666a4700c2 size: 4739 DONE
そのあとに、loggingで下記の設定を行うことで、deployに関したlogだけ表示させることができます。
ちゃんとlog見ないとだめですね・・・・
GCP ~Google Cloud Container Builder編~
Google Cloud Container Builder
コンテナ イメージをビルドしてくれるサービスです。
やることはシンプルにビルドなので、ノーガードで攻め込んだら、無知すぎて手痛い洗礼を受けました・・・・ (GCPやり始めてこんなんばっかだな・・・)
まず、サンプルっぽいソースに下記のようにコマンド実行しました。
$ gcloud container builds submit --tag gcr.io/<your-project-name>/sample . Creating temporary tarball archive of 9 file(s) totalling 37.2 KiB before compression. Uploading tarball of [.] to [gs://<your-project-name>_cloudbuild/source/1521708458.84-95f75ef8e09d4812a685644476bc3d91.tgz] Created [https://cloudbuild.googleapis.com/v1/projects/<your-project-name>/builds/6b561f37-83d9-40a6-8059-bf7b65e6e289]. Logs are available at [https://console.cloud.google.com/gcr/builds/6b561f37-83d9-40a6-8059-bf7b65e6e289?project=<your-project-name>]. ------------------------------------------------------------------------------------------- REMOTE BUILD OUTPUT ------------------------------------------------------------------------------------------- starting build "6b561f37-83d9-40a6-8059-bf7b65e6e289" FETCHSOURCE Fetching storage object: gs://<your-project-name>_cloudbuild/source/1521708458.84-95f75ef8e09d4812a685644476bc3d91.tgz#1521708460698522 Copying gs://<your-project-name>_cloudbuild/source/1521708458.84-95f75ef8e09d4812a685644476bc3d91.tgz#1521708460698522... / [1 files][ 12.1 KiB/ 12.1 KiB] Operation completed over 1 objects/12.1 KiB. BUILD Already have image (with digest): gcr.io/cloud-builders/docker unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /workspace/Dockerfile: no such file or directory ERROR ERROR: build step 0 "gcr.io/cloud-builders/docker" failed: exit status 1 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ERROR: (gcloud.container.builds.submit) build 6b561f37-83d9-40a6-8059-bf7b65e6e289 completed with status "FAILURE"
なんやねん・・・・と
結果だけのべる・・・ (ポルナレフのもじろうと思ったけどそんな気力もなくなったので本当に結果だけ)
上記のコマンドは Dockerfileが存在するディレクトリで実行 すること！
僕、kubernetesのyamlとかある、一個上の階層でやっちまってたんです・・・・orz
たったこれだけなのに、すごーく遠回りしました・・・・
ドキュメントもっと親切にしてほしい・・・・
だけど、
「覚えたぞォォ！」
無知すぎてさーせんでした。
