クラウドインフラ構築記

現在AWSの構築支援に携わっております。今注視しているのは、GKE、BigQuery、Google Dataflowなどサービスを展開しているGoolge Cloud Platformです。

2018年12月15日
から hiruta
CloudBuild 事始め はコメントを受け付けていません。

CloudBuild 事始め

Container Builder 改め、CloudBuildについて、すこし試してみました。

CloudBuildの詳細についてはこちらです。
https://cloud.google.com/cloud-build/

CloudBuild用のコンテナを使って、CI処理を組んでいきます。対応ランタイムは下記となる。

Bazel、Curl、Docker、Dotnet、Gcloud、Git、Go、Gradle、Gsutil、Kubectl、Mvn、Npm、Wget、yarn

cloudbuild.ymlの例。Cloud Functionsのデプロイ例。Cloud Buildとリージョンちがくても問題はない。

 steps:
- name: gcr.io/cloud-builders/gcloud
args:
- "functions"
- "deploy"
- "http"
- "--entry-point=hello_test_http"
- "--region=us-central1"
- "--runtime=python37"
- "--trigger-http" 
 gcloud builds submit --config cloudbuild.yaml . 

権限周りではまったこを一点。

1度下記エラーがでたことがあった。

 Already have image (with digest): gcr.io/cloud-builders/gcloud
ERROR: (gcloud.beta.functions.deploy) ResponseError: status=[403], code=[Forbidden], message=[The caller does not have permission]
ERROR: build step 0 "gcr.io/cloud-builders/gcloud" failed: exit status 1

IAMの権限エラーによるものとなりますので、cloudbuildのserviceaccountに付与してやる必要がある

 gcloud iam service-accounts add-iam-policy-binding ${PROJECT}@appspot.gserviceaccount.com \
--member=serviceAccount:${NUM}@cloudbuild.gserviceaccount.com \
--role=roles/iam.serviceAccountUser --project=${PROJECT}

GCEインスタンスから、GCP APIを叩く場合も、同じく失敗することがあります。以前は大丈夫だったが、仕様が変更になったのか。

2018年12月4日
から hiruta
GCEのネットワークスループットについて はコメントを受け付けていません。

GCEのネットワークスループットについて

16vCPUsのインスタンス(n1-standard-16)で同ゾーンでネットワークスループットを計算しました。

GCEのインスタンスの場合、以下のようにコア毎に2GBpsの制限がある。8コア以上のインスタンスタイプの場合、16GBpsに制限されている。g1-small等の「shared-core machine type」は1GBpsに制限されている。

https://cloud.google.com/vpc/docs/quota?authuser=0#per_instance

1多重でした結果

 hiruta@instance-2:~$ iperf3 -c 10.80.10.2
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 10.2 GBytes 8.72 Gbits/sec 3647 sender
[ 4] 0.00-10.00 sec 10.2 GBytes 8.72 Gbits/sec receiver

1多重で8GBps!

16多重で


hiruta@instance-2:~$ iperf3 -c 10.80.10.2 -P 16

[SUM] 0.00-10.00 sec 16.3 GBytes 14.0 Gbits/sec 173799 sender
[SUM] 0.00-10.00 sec 16.3 GBytes 14.0 Gbits/sec receiver

しっかり、16Gbpsで制限かかっているようだ。

2018年11月20日
から hiruta
Generating Signed URLs をgsutilコマンドにて #gcpug はコメントを受け付けていません。

Generating Signed URLs をgsutilコマンドにて #gcpug

Generating Signed URLsをgcloudでしてみました。

https://cloud.google.com/storage/docs/access-control/signing-urls-with-helpers

※aws s3 presignに相当する機能になります。

ConsoleではService accounsのページでservice account keysを作成できますが、gcloudでは、「roles/iam.serviceAccountKeyAdmin」を付与しないと、下記のエラーメッセージが出力されます。

$ gcloud iam service-accounts keys create ~/key.json --iam-account gcs-signurl2@xxxxxxxxxxxxxxxxxxx.iam.gserviceaccount.com
ERROR: (gcloud.iam.service-accounts.keys.create) PERMISSION_DENIED: Permission iam.serviceAccountKeys.create is required to perform this operation on service account projects/-/serviceAccounts/gcs-signurl2@xxxxxxxxxxxxxxxxxxx.iam.gserviceaccount.com.

まず、下記コマンドで権限付与しておく必要があります。

gcloud projects add-iam-policy-binding xxxxxxxxxxxxxxxxxxx --member serviceAccount:gcs-signurl@xxxxxxxxxxxxxxxxxxx.iam.gserviceaccount.com --role roles/iam.serviceAccountKeyAdmin

上記実行後に、gcloud iam service-accounts keys createコマンドを実行します。

次に、Generating Signed URLs with gsutilでテンポラリなURLを作成自体はできますが、テンポラリURLをブラウザからアクセスする場合、オブジェクトへの参照権限をサービスアカウントに付与しておく必要があります。

gcloud projects add-iam-policy-binding xxxxxxxxxxxxxxxxxxx --member=serviceAccount:gcs-signurl@xxxxxxxxxxxxxxxxxxx.iam.gserviceaccount.com --role=roles/storage.objectViewer

あとは、Generating Signed URLs with gsutilを実行すればテンポラリなURLを発行することができます。
(この場合10分間有効なURLとなります。)

$ gsutil signurl -d 10m Desktop/key.json gs://gcs-to-bigquery/2.5_month.csv
URL HTTP Method Expiration Signed URL
gs://gcs-to-bigquery/2.5_month.csv GET 2018-11-18 18:14:07

10分間経過すると下記エラーとなります。

<Error>
<Code>ExpiredToken</Code>
<Message>The provided token has expired.</Message>
<Details>
Request signature expired at: 2018-11-18T09:14:07+00:00
</Details>
</Error>

2018年7月29日
から hiruta
Cloud Functions To CloudSQL #gcpug はコメントを受け付けていません。

Cloud Functions To CloudSQL #gcpug

Cloud Functionsから直接接続できます。(CloudSQL Direct Connect)

公式には、Node.js版しか記載されていませんが、GCP Next SF 2018 でβになったpython 3.7でも可能なので、ポイントを記載します。

公式のCloudSQL Direct Connectは以下を参照してください。

https://cloud.google.com/functions/docs/sql

functionsデプロイ時に必要なモジュールを記載。(mysql-connector-python)

requirements.txt

 google-cloud-logging==1.6.0
mysql-connector-python==8.0.11

次にコード

CloudSQL接続情報とかをまず設定します。unix socketに対して接続する設定になります。


import mysql.connector

connectionName = 'gcp-project-id:asia-east1:web2-db'
config = {
'user': 'dbuser',
'password': 'xxxxxx',
'unix_socket': '/cloudsql/' + connectionName,
'database': 'database'
}

Cloud Functions python 3.7 runtimeは、Flask microframeworkというフレームワークでコーディングします。

 def hello_sql(request):
"""HTTP Cloud Function.
Args:
request (flask.Request): The request object.
Returns:
The response text, or any set of values that can be tuned into a
Response object using `make_response
<http://flask.pocoo.org/docs/0.12/api/#flask.Flask.make_response>`.
"""
request_json = request.get_json()
if request_json and 'exec_cmd' in request_json:
exec_cmd = request_json['exec_cmd']

ここで、ポイント

Connection Poolに接続するのが、max connection を1にすること

Functionsはイベントトリブンなので、コネクションリソースを枯渇することを防ぐ上で。

公式にも以下記載されています。

When using a connection pool, it is important to set the maximum connections to 1. This may seem counter-intuitive, however, creating more than one concurrent connection per function instance may cause rapid exhaustion of connection resources (see Maximum Concurrent Connections below for more detail). Cloud Functions limits concurrent executions to 1 per instance. This means you will never have a situation where two requests are being processed by a single function instance at the same time, so in most situations only a single database connection is needed.


try:
cnx = mysql.connector.connect(pool_name="mypool",
pool_size = 1,
**config)
exec_cmd = cnx.is_connected()
if cnx.is_connected():
cur = cnx.cursor()
cur.execute('select * from wp_options limit 1 ')
result = cur.fetchall()
except:
exec_cmd = cnx.is_connected()
finally:
cur.close()
cnx.close()

return f'Hello, {result}!' 

αテスト時は、event handlingがでなくても、デバッグしづらかったのですが、最近、python コードのエラーも場合でも、functionsがcrashした場合でも、Trackbackが出るようになっています。

2018年7月16日
から hiruta
HTTPS用にIngress リソースの作成について はコメントを受け付けていません。

HTTPS用にIngress リソースの作成について

Podsをexternalからアクセスさせるには、Serviceが必要になる。

上記Type LoadBalancer は、HTTPになるので、HTTPSは、Ingressを使う必要があります。

https://kubernetes.io/docs/concepts/services-networking/ingress/

IngressとPodの中継するため、NodePortを作っておきます。Ingressからヘルスチェックとして、NodePortを使います。

 kubectl expose deployment web-app --target-port=80 --type=NodePort 

Let’s encryptのSSL証明書はSecretsに登録しておきます。

 kubectl create secret tls custom-tls-cert 

ingress用のyaml

 apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: basic-ssl-ingress
spec:
tls:
- hosts:
- www.totalsolution.biz
secretName: custom-tls-cert
rules:
- host: www.totalsolution.biz
http:
paths:
- backend:
serviceName: web-app
servicePort: 80
path: / 

ヘルスチェックが通るまでしばらく時間がかかります。

2018年7月8日
から hiruta
kubernatesでRegional Persistent Disksを使うには #gcpug はコメントを受け付けていません。

kubernatesでRegional Persistent Disksを使うには #gcpug

Regional Persistent Disksについて

Persistent Disksは1ゾーンのみで使用できるものだが、Regional Persistent Disks は異なるゾーンにインスタンスにアタッチができる。
ディスクの内容はレプリケーションしてくれる。

regional persistent disks provide durable storage and replication of data between two zones in the same region.

Persistent Disksの作成

 gcloud beta compute disks create web-disk-2 --size 30GB --type pd-ssd --region asia-east1 --replica-zones asia-east1-a,asia-east1-b 

–replica-zonesに、2ゾーンを指定する。ただし、3 ゾーンを指定すると、–replica-zones: too many args となり、作成できない。

最初に作成されたディスクの確認をします。

 $ gcloud beta compute disks list
NAME LOCATION LOCATION_SCOPE SIZE_GB TYPE STATUS
web-disk-2 asia-east1 region 30 pd-ssd READY  

7/8現在、Web コンソールからはRegional Persistent Disksを確認できない。

regional diskのwriteモードでのアタッチは1インスタンスしかできないことは、Persistent Disksと同じ
Persistent Disksだと、ROMだと別のインスタンスにアタッチが可能

Regional Persistent Disksについては下記を参照してください。
https://cloud.google.com/compute/docs/disks/regional-persistent-disk

kubernatesでRegional Persistent Disksを使うには

regional diskをPersistentVolumeで使う場合、下記のように、PersistentVolumeを作成します
( failure-domain.beta.kubernetes.io/zoneタグが要)
※https://kubernetes.io/docs/concepts/storage/volumes/

 apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
failure-domain.beta.kubernetes.io/zone: asia-east1-a__asia-east1-b
spec:
storageClassName: manual
capacity:
storage: 30Gi
accessModes:
- ReadWriteOnce
gcePersistentDisk:
pdName: web-disk-2
fsType: ext4 

kubernetesのmaster versionは、1.10が必要(1.10.5-gke.0で動確)
それ以下だとPersistentVolumeでエラーとなります。

 $ kubectl create -f test.yml
Error from server (Forbidden): error when creating "test.yml": persistentvolumes "task-pv-volume" is forbidden: error querying GCE PD volume web-disk-2: The regional PD feature is only available via the GCE Alpha API. Enable "GCEDiskAlphaAPI" in the list of "alpha-features" in "gce.conf" to use the feature. 

次に、PersistentVolumeClaimの作成

 kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: task-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 30Gi
 $ kubectl create -f task-pv-claim.yml
persistentvolumeclaim "task-pv-claim" created
$ kubectl get pvc task-pv-claim
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
task-pv-claim Bound task-pv-volume 30Gi RWO manual 9s
$ kubectl get pv task-pv-volume
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
task-pv-volume 30Gi RWO Retain Bound default/task-pv-claim manual 

task-pv-claimをPodからマウントするコンフィグを作成

 apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: web-app
labels:
app: WebApp
spec:
template:
metadata:
labels:
app: mysql-client
spec:
containers:
- name: web
image: asia.gcr.io/xxxxxxxxxxxxxxx/nginx:latest
ports:
- containerPort: 8080
env:
- name: WORDPRESS_DB_HOST
value: 127.0.0.1:3306
# These secrets are required to start the pod.
# [START cloudsql_secrets]
- name: WORDPRESS_DB_USER
valueFrom:
secretKeyRef:
name: cloudsql-db-credentials
key: username
- name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: cloudsql-db-credentials
key: password
# [END cloudsql_secrets]
volumeMounts:
- name: task-pv-storage
mountPath: /www
- name: php-fpm
image: asia.gcr.io/xxxxxxxxxxxxxxx/php-fpm:latest
ports:
- containerPort: 9000
# Change <INSTANCE_CONNECTION_NAME> here to include your GCP
# project, the region of your Cloud SQL instance and the name
# of your Cloud SQL instance. The format is
# $PROJECT:$REGION:$INSTANCE
# [START proxy_container]
- name: cloudsql-proxy
image: gcr.io/cloudsql-docker/gce-proxy:1.11
command: ["/cloud_sql_proxy",
"-instances=xxxxxxxxxxxxxxx:asia-east1:web2-db=tcp:3306",
"-credential_file=/secrets/cloudsql/credentials.json"]
volumeMounts:
- name: cloudsql-instance-credentials
mountPath: /secrets/cloudsql
readOnly: true
# [END proxy_container]
# [START volumes]
volumes:
- name: cloudsql-instance-credentials
secret:
secretName: cloudsql-instance-credentials
- name: task-pv-storage
persistentVolumeClaim:
claimName: task-pv-claim
# [END volumes] 
 kubectl apply -f deployment.yml 

でデプロイし、Podにログインして、Regional Persistent Disksが、マウントされていることを確認しました。

 root@web-app-84dcf8d8c8-vdnjp:/# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 100G 0 disk
|-sda1 8:1 95.9G 0 part /etc/hosts
|-sda2 8:2 0 16M 0 part
|-sda3 8:3 0 2G 0 part
|-sda4 8:4 0 16M 0 part
|-sda5 8:5 0 2G 0 part
|-sda6 8:6 512B 0 part
|-sda7 8:7 0 512B 0 part
|-sda8 8:8 16M 0 part
|-sda9 8:9 0 512B 0 part
|-sda10 8:10 0 512B 0 part
|-sda11 8:11 8M 0 part
`-sda12 8:12 0 32M 0 part
sdb 8:16 0 30G 0 disk /www 

 

2018年6月24日
から hiruta
nginx + php-fpm + cloudsql proxyのPodを作成手順メモ #gcpja はコメントを受け付けていません。

nginx + php-fpm + cloudsql proxyのPodを作成手順メモ #gcpja

nginx + php-fpm + cloudsql proxy のコンテナで構成されたPod、External Load BalancerのServiceを構築したときのメモになります。

Kubernets Enginesを作成します。Preemptible VM Nodeで作成しています。

 gcloud container clusters create test-cluster --machine-type=g1-small --network=product-network --subnetwork=prod-asia --preemptible 

CloudSQLへの接続ユーザ情報からsecretを作成しておきます。

 kubectl create secret generic cloudsql-db-credentials --from-literal=username=proxyuser --from-literal=password=xxxxx 

CloudSQL Admin、CloudSQL Client、CloudSQL Editorの権限を持つIAMを作成、credentials.jsonを取得します

 kubectl create secret generic cloudsql-instance-credentials --from-file=credentials.json=credentials.json 

各構成しているnginx、php-fpmは下記を参考に作成しました。

GCRにイメージをpushする前にGCRと認証済みにしておき必要があります。以下コマンドを実行しておきます。

 gcloud auth configure-docker 

docker pushするには、下記も必要になります。

 docker login -u oauth2accesstoken -p "$(gcloud auth print-access-token)" https://asia.gcr.io 

 

Pod構成ファイルの作成

 apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: mysql-client
labels:
app: mysql-client
spec:
template:
metadata:
labels:
app: mysql-client
spec:
containers:
- name: web
image: asia.gcr.io/[project-id]/nginx:latest
ports:
- containerPort: 8080
env:
- name: WORDPRESS_DB_HOST
value: 127.0.0.1:3306
# These secrets are required to start the pod.
# [START cloudsql_secrets]
- name: WORDPRESS_DB_USER
valueFrom:
secretKeyRef:
name: cloudsql-db-credentials
key: username
- name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: cloudsql-db-credentials
key: password
# [END cloudsql_secrets]
- name: php-fpm
image: asia.gcr.io/[project-id]/php-fpm:latest
ports:
- containerPort: 9000
# Change <INSTANCE_CONNECTION_NAME> here to include your GCP
# project, the region of your Cloud SQL instance and the name
# of your Cloud SQL instance. The format is
# $PROJECT:$REGION:$INSTANCE
# [START proxy_container]
- name: cloudsql-proxy
image: gcr.io/cloudsql-docker/gce-proxy:1.11
command: ["/cloud_sql_proxy",
"-instances=[project-id]:asia-east1:web2-db=tcp:3306",
"-credential_file=/secrets/cloudsql/credentials.json"]
volumeMounts:
- name: cloudsql-instance-credentials
mountPath: /secrets/cloudsql
readOnly: true
# [END proxy_container]
# [START volumes]
volumes:
- name: cloudsql-instance-credentials
secret:
secretName: cloudsql-instance-credentials
# [END volumes] 

Service用構成ファイルの作成

 apiVersion: v1
kind: Service
metadata:
name: web
spec:
ports:
-
port: 80
targetPort: 8080
selector:
app: mysql-client
type: LoadBalancer

Podから作成しておきます。

  kubectl create -f deployment.yaml 
  kubectl create -f service-web.yaml 

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/ にも記載されている通り、SSL termination する場合は、Ingress resourceが必要になります。

2018年5月13日
から hiruta
[StandardSQL] 過去スナップショット参照方法について #gcpug はコメントを受け付けていません。

[StandardSQL] 過去スナップショット参照方法について #gcpug

Legacy SQLのTable Decorators に該当するものが、Standard SQLにないものか

issue https://issuetracker.google.com/issues/35905931のコメントをみて、発見したことですが、FOR SYSTEM TIME AS OFというものがあることが判明

https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax#from-clause

制限

FROM句で、ARRAY scan、UNNEST operator、WITH句によって定義されたtable expressionも使えない。

過去7日のタイムスタンプである必要がある、もちろん、未来日付はNG

データリカバリの確認

 bq query --use_legacy_sql=false 'DELETE FROM dlp_output.earthquake_data WHERE true' 

と過去データレコードを全部削除ののち、

 bq query --destination_table xxxxxxxxxxxxxx:dlp_output.earthquake_data --append --use_legacy_sql=false 'SELECT * FROM dlp_output.earthquake_data FOR SYSTEM TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR);'

Amazon Auroraにも、過去レコードに戻す機能(Amazon Aurora Backtrack)が最近リリースされましたが、
クラスタの内容を過去(72Hours)に戻してしまうので、クエリで過去の情報を確認するものではない。

https://aws.amazon.com/blogs/aws/amazon-aurora-backtrack-turn-back-time/

2018年3月26日
から hiruta
Google-Provided Templates #gcpug はコメントを受け付けていません。

Google-Provided Templates #gcpug

Google Dataflow用のGoogleがテンプレートを提供してくれている。Dataflowをパラメータを指定することでDataflowを手軽に使うことができるものです。

現在提供されているテンプレートは以下となります。

  • WordCount
  • Cloud Pub/Sub to BigQuery
  • Cloud Storage Text to Cloud Pub/Sub
  • Cloud Pub/Sub to Cloud Storage Text
  • Cloud Datastore to Cloud Storage Text
  • Cloud Storage Text to BigQuery
  • Cloud Storage Text to Cloud Datastore
  • Bulk Decompress Cloud Storage Files

その中のCloud Storage Text to BigQuery について、

テンプレートで指定するパラメータは以下となっている。

実行方法として、Google Cloud Platform consoleもしくは、Google OAuth 2.0されたREST API で実行できます。

https://cloud.google.com/dataflow/docs/reference/rest/v1b3/projects.templates/launch#authorization

 

が、そのまま実行させると、inputパラメータを指定すると、invailidとなります。

outputTableの、my-project-nameは、project-idでないとprojectが見つからないと怒られます。

 {
"parameters": {
"javascriptTextTransformFunctionName": "transform",
"JSONPath": "gs://**********/schema.json",
"javascriptTextTransformGcsPath": "gs://**********/my_function.js",
"inputFilePattern": "gs://**********/*.csv",
"outputTable": "*************:testdataset.testtable",
"bigQueryLoadingTemporaryDirectory": "gs://**********/tmp"
},
"jobName": "test-job",
"environment": {
"tempLocation": "gs://**********/temp",
"zone": "us-central1-f"
}
}

テンプレートのソースを確認しても、InputFilePatternパラメータが必須となっているので、inputFilePatternの間違いであるのは確実です。

2018年2月25日
から hiruta
GCS Triggerイベントから返される値がおかしい #gcpug はコメントを受け付けていません。

GCS Triggerイベントから返される値がおかしい #gcpug

GCS Triggerイベントから返される値が、おかしい場合がある。

以下簡単なコードを用意し、

 exports.bqbilling =function(event,callback) {
const file = event.data;
console.log(' file ', file); }

以下でfunctionsをデプロイを行いました。

 gcloud beta functions deploy bqbilling --trigger-resource upload_bucket_us --trigger-event google.storage.object.finalize 

以下2パターンでGCSバケットにコピーしてみました。

 gsutil cp billing-2018-02-23.json gs://upload_bucket_us 
 gsutil cp billing-2018-02-23.json gs://upload_bucket_us/billing-2018-02-23.json 

後者が、下記file.nameに、billing-2018-02-23.json/billing-2018-02-23.jsonと重複して入ってしまう。

 file : { bucket: 'upload_bucket_us', contentLanguage: 'en', contentType: 'application/json', crc32c: 'oV5QaA==', etag: 'CICXiNWhwNkCEAE=', generation: '1519534106348416', id: 'upload_bucket_us/billing-2018-02-23.json/billing-2018-02-23.json/1519534106348416', kind: 'storage#object', md5Hash: 'YhMH7RRG8oPxYj1lTapNBw==', mediaLink: 'https://www.googleapis.com/download/storage/v1/b/upload_bucket_us/o/billing-2018-02-23.json%2Fbilling-2018-02-23.json?generation=1519534106348416&alt=media', metageneration: '1', name: 'billing-2018-02-23.json/billing-2018-02-23.json', selfLink: 'https://www.googleapis.com/storage/v1/b/upload_bucket_us/o/billing-2018-02-23.json%2Fbilling-2018-02-23.json', size: '67081', storageClass: 'NEARLINE', timeCreated: '2018-02-25T04:48:26.346Z', timeStorageClassUpdated: '2018-02-25T04:48:26.346Z', updated: '2018-02-25T04:48:26.346Z' } 

gcloudは、190.0.1(最新版)で試しました。