クラウドインフラ構築記

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

2017年12月3日
から hiruta
インターリージョンVPCピアリング #aws #jawsug はコメントを受け付けていません。

インターリージョンVPCピアリング #aws #jawsug

インターリージョンVPCピアリングがサポートされたので、スループットを計測してみました。

インターリージョンVPCピアリングのサポートのお知らせ

現状東京リージョンは対応していないので、USオレゴン(us-west-2)とUSオハイオ(us-east-2)間になります。

インスタンスタイプは、t2.medium(オハイオだとm3.mediumが使えない。。)、計測ツールはiperf3を使いました。

まずは、VPC Peering経由しない場合

 [ 4] 0.00-10.00 sec 72.2 MBytes 60.6 Mbits/sec 131 sender
[ 4] 0.00-10.00 sec 70.6 MBytes 59.2 Mbits/sec receiver
 [ 4] 0.00-10.00 sec 72.2 MBytes 60.6 Mbits/sec 131 sender
[ 4] 0.00-10.00 sec 70.6 MBytes 59.2 Mbits/sec receiver
[ 4] 0.00-10.00 sec 96.3 MBytes 80.7 Mbits/sec 214 sender
[ 4] 0.00-10.00 sec 94.7 MBytes 79.4 Mbits/sec receiver

次に、VPC Peering経由

 [ 4] 0.00-10.00 sec 79.1 MBytes 66.3 Mbits/sec 302 sender
[ 4] 0.00-10.00 sec 77.4 MBytes 64.9 Mbits/sec receiver
 [ 4] 0.00-10.00 sec 52.3 MBytes 43.9 Mbits/sec 227 sender
[ 4] 0.00-10.00 sec 50.4 MBytes 42.3 Mbits/sec receiver
 [ 4] 0.00-10.00 sec 65.8 MBytes 55.2 Mbits/sec 310 sender
[ 4] 0.00-10.00 sec 63.9 MBytes 53.6 Mbits/sec receiver

上記の通り、Peering通さないほうが良くなる結果となった。internet gatewayを出ないので早くなると予想したが予想とは違う結果になった。

VPC Peeringの経路は1ホップであることは確認。

traceroute 172.22.1.114
traceroute to 172.22.1.114 (172.22.1.114), 30 hops max, 60 byte packets
1 ip-172-22-1-114.us-west-2.compute.internal (172.22.1.114) 69.081 ms 71.186 ms 70.115 ms

 

GCPのus-central1とus-west1間のスループットを追加しました。

 [ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 825 MBytes 692 Mbits/sec 1 sender
[ 4] 0.00-10.00 sec 824 MBytes 691 Mbits/sec receiver
 [ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 638 MBytes 535 Mbits/sec 41 sender
[ 4] 0.00-10.00 sec 637 MBytes 534 Mbits/sec receiver
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 827 MBytes 694 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 826 MBytes 693 Mbits/sec receiver

AWSに比べて、リージョン間でも一桁違うスループットを記録。

 

2017年12月2日
から hiruta
S3 Selectを試してみた #aws #jawsug はコメントを受け付けていません。

S3 Selectを試してみた #aws #jawsug

re:invent 2017で発表されたS3 Selectのpreview が通ったので、試してみました。

※S3 Selectはプレビュなので、将来仕様が変わる場合があります。

試したのは、Python SDK 2.7になります。

必要なモジュールは、boto3と、下記からダウンロード、カレントフォルダに展開する必要があります。

 wget http://s3select.s3-website-us-east-1.amazonaws.com/public/python/aws-python-sdk-s3-select-preview-1.0.0.zip

サポートされているリージョンは、下記となっており、東京リージョンのS3 bucketは対応していません。

米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、およびアジアパシフィック (シンガポール)

S3 Selectをサポートしていないリージョンを指定すると、下記エラーメッセージが表示されます。

 botocore.exceptions.ClientError: An error occurred (MethodNotAllowed) when calling the SelectObjectContent operation: The specified method is not allowed against this resource.

サンプルコード


import boto3
from s3select import ResponseHandler
import os
import sys

class PrintingResponseHandler(ResponseHandler):
def handle_records(self, record_data):
print(record_data.decode('utf-8'))

args = sys.argv;

CURRENT_DIR = os.path.abspath(os.path.dirname(__file__))
MODELS_DIR = os.path.join(CURRENT_DIR, 'models')
os.environ['AWS_DATA_PATH'] = MODELS_DIR

expression = args[1]

s3 = boto3.client('s3','us-west-2')
response = s3.select_object_content(
Bucket='xxxxxx',
Key='401307influenza.csv',
SelectRequest={
'ExpressionType': 'SQL',
'Expression': expression ,
'InputSerialization': {
'CompressionType': 'NONE',
'CSV': {
'FileHeaderInfo': 'IGNORE',
'RecordDelimiter': '\n',
'FieldDelimiter': ',',
}
},
'OutputSerialization': {
'CSV': {
'RecordDelimiter': '\n',
'FieldDelimiter': ',',
}
}
}
)

handler = PrintingResponseHandler()
handler.handle_response(response['Body'])

所感

  • S3でGZIPされたファイルに対しても、実行することが可能
  • CSVの場合、Ⅰ行目を抜いて、COUNTしてくれました
  • AVG、SUM、MAX、MINなども使えるとなっているが、現状使い方が悪いのかシンタックスエラーになってしまいます。(GROUP BYは未対応)
  • select s._4 from S3Object where _4 = ‘2017’ のようにselect句とwhere句に同じフィールドで実行するとエラーとなる
 botocore.exceptions.ClientError: An error occurred (InternalError) when calling the SelectObjectContent operation (reached max retries: 4): We encountered an internal error. Please try again.

日本語も表示することは可能(UTF-8に限られます)

現状暗号化されたS3 Objectには対応していない。

暗号化させて、S3 にアップロードして、

 aws s3api put-object --bucket xxxxx --key 401307influenza2.csv --body  401307influenza2.csv --server-side-encryption AES256 --debug

S3 Selectしたところ、以下エラーが返ります。

 botocore.exceptions.ClientError: An error occurred (UnsupportedEncryptionMode) when calling the SelectObjectContent operation: We do not support server side encryption. Please check the service documentation and try again.

あと、検索はフルスキャンになるか情報がなかったので、不明

2017年12月2日
から hiruta
Cloud IoT Coreについて #gcpug #gcpja はコメントを受け付けていません。

Cloud IoT Coreについて #gcpug #gcpja

Cloud IoTを試してみました。Google Cloud Platform Advent Calendar 2017の二日目の記事になります。

Cloud IoT Coreは、現在パブリックβということで、今後仕様が変わる場合があります。現状のものについて記載しています。

Cloud IoT Coreは、Cloud PubSubと違うのは、MQTT(S)機能+デバイス管理機能と考えればいいかと

まず、new device registry 作成

gcloud beta iot registries create my-registry \
--project=my-iot-project \
--region=us-central1 \
--event-pubsub-topic=projects/my-iot-project/topics/device-events

選択可能なリージョン
us-central1
europe-west1
asia-east1

証明書によるデバイス接続となる。
Azure IoTにあるようなCloud IoT自体にIP制限等の機能はない

先日AWS IoTでは、X.509証明書なしでもOAuthのようなトークン認証には現状対応していません。

公開されているサンプルをベースにポイントを記載します。サンプルは下記gitからダウンロードできます。

https://github.com/GoogleCloudPlatform/nodejs-docs-samples.git

最初に、デバイスの証明書を発行

今回のリリースにより、Cloud IoT Coreの顧客は、自らのデバイス鍵を用意し、自身の認証局(CA)を使って署名しておくことで、Cloud IoT Coreの認証プロセスで該当鍵の署名を検証できるようになる。これによりデバイスメーカーは、自らのCAが発行した証明書を用いることで、デバイスをオフライン状態のままで一括して準備できるようになる

 openssl req -x509 -newkey rsa:2048 -keyout rsa_private.pem -nodes -out \
rsa_cert.pem -subj "/CN=unused"
openssl ecparam -genkey -name prime256v1 -noout -out ec_private.pem
openssl ec -in ec_private.pem -pubout -out ec_public.pem

デバイスの追加

gcloud beta iot devices create my-node-device \
--project=my-iot-project \
--region=us-central1 \
--registry=my-registry \
--public-key path=rsa_cert.pem,type=rs256

証明書の更新もgcloud beta iot devices credentials updateで行います

 

Cloud IoT Coreに接続するアプリを作成するには、まず以下Node.js moduleをインストールしておく
“jsonwebtoken”: “7.4.1”,
“mqtt”: “2.7.2” *

実際Cloud IoTに接続するために、利用するパッケージは、mqtt

一意のmqttClient idを付与
const mqttClientId = `projects/${argv.project_id}/locations/${argv.cloud_region}/registries/${argv.registry_id}/devices/${argv.device_id}`;
// With Google Cloud IoT Core, the username field is ignored, however it must be
// non-empty. The password field is used to transmit a JWT to authorize the
// device. The "mqtts" protocol causes the library to connect using SSL, which
// is required for Cloud IoT Core.
const connectionArgs = {
host: argv.mqtt_bridge_hostname,
port: argv.mqtt_bridge_port,
clientId: mqttClientId,
username: 'unused',
password: createJwt(argv.project_id, argv.private_key_file, argv.algorithm),
protocol: 'mqtts'

};

tokenをコネクションを張るごとにワンタイムパスワードを設定

 // Create a JWT to authenticate this device. The device will be disconnected
// after the token expires, and will have to reconnect with a new token. The
// audience field should always be set to the GCP project id.

MQTTS 接続部分

// Create a client, and connect to the Google MQTT bridge.
const client = mqtt.connect(connectionArgs);

 

client.on('connect', () => {
 console.log('connect', arguments);
 // After connecting, publish 'num_messages' messagse asynchronously, at a rate
 // of 1 per second for telemetry events and 1 every 2 seconds for states.
 publishAsync(1, argv.num_messages);
}); 

センサーデータを見立てて、jsonデータを生成

 const temperature = 20 + (Math.randam() * 15);
const humidity = 60 + (Mat<span data-mce-type="bookmark" style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" class="mce_SELRES_start"></span>h.random() * 20);
const data = JSON.stringify({
deviceId: 'my-node-device',
temperature: temperature,
humidity: humidity
});

 

 // Publish "payload" to the MQTT topic. qos=1 means at least once delivery.
// Cloud IoT Core also supports qos=0 for at most once delivery.
console.log('Publishing message:', payload);
client.publish(mqttTopic, data, { qos: 1 });

 

gcloud beta pubsub subscriptions pull --auto-ack projects/my-iot-project/subscriptions/my-subscription

https://cloud.google.com/pubsub/ordering?hl=ja

Cloud pubsub自体処理サーバがロードバランシングしているので、Google Cloud Pub/Sub では、高可用性と拡張性を持ったメッセージ配信サービスを使用できます。これらの機能を使用する場合の妥協点として、サブスクライバーによって受信されるメッセージの順序は保証されません。

時系列にソートさせるには、時刻のデータも一緒に送信させる仕組みは必要

projects/my-iot-project/topics/device-events をトリガーにCloud Functions、Google dataflow等に発火することができる。

/**
* Triggered from a message on a Cloud Pub/Sub topic.
*
* @param {!Object} event The Cloud Functions event.
* @param {!Function} The callback function.
*/

exports.subscribe = function subscribe(event, callback) {
// The Cloud Pub/Sub Message object.
const pubsubMessage = event.data;



// We're just going to log the message to prove that
// it worked.
console.log(Buffer.from(pubsubMessage.data, 'base64').toString());
// Don't forget to call the callback.
callback();
};

Cloud IoT Coreは、現在のところ、東京リージョン(asia-northeast1)にきていないので、IoT device間レイテンシーが気になる。

※日本から最も近いCloud IoT CoreのEdgeはasia-east1(台湾)

さらに、IoTデバイスの最新状態を取得する必要がある顧客は、最後に報告された状態やデバイスのプロパティを含む、物理デバイスの論理表現を管理できるようになる。こういったことを実現するために、デバイスがオフラインになっていても、その状態やプロパティを取得したり、アップデートしたりするためのAPIが用意されている。

gcloud beta iot devices update
-blocked

https://cloud.google.com/sdk/gcloud/reference/beta/iot/devices/update

gcloud beta iot devices credentials update

https://cloud.google.com/sdk/gcloud/reference/beta/iot/devices/credentials/update

 

2017年11月5日
から hiruta
AWS Lambdaを使った負荷試験ツールgoad はコメントを受け付けていません。

AWS Lambdaを使った負荷試験ツールgoad

AWS Lambdaを使った、分散負荷試験ツールgoadについて。Serverless Confのツイートだったと思うが、goadについてあったので、少し使ってみました。

https://github.com/goadapp/goad#usage

https://github.com/goadapp/goad/releases からgoad-osx-x86-64.zipをダウンロード

Lambda workersを作成する関係上、AWSのcredentialsを設定しておく必要がある。
Lambda、SQS、IAM Roleが作成され、Cloudwatch logsにログが記録されます。

Usageページにも下記のように書かれています。

AWS credentials
Goad will read your credentials from ~/.aws/credentials or from the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables (more info).

多重度(-c)も変更できます。header、GET/POST等のhttp methodも設定できたりします。


a$ ./goad -n 100 -c 5 https://www.hogehogehoge.biz
Regional results

Region: ap-northeast-1
TotReqs TotBytes AvgTime AvgReq/s (post)unzip
36 2.6 MB 1.574s 0.64 46 kB/s
Slowest Fastest Timeouts TotErrors
2.627s 1.348s 0 0
Region: eu-west-1
TotReqs TotBytes AvgTime AvgReq/s (post)unzip
33 2.4 MB 1.546s 0.65 47 kB/s
Slowest Fastest Timeouts TotErrors
2.595s 1.353s 0 0
Region: us-east-1
TotReqs TotBytes AvgTime AvgReq/s (post)unzip
33 2.4 MB 1.515s 0.66 48 kB/s
Slowest Fastest Timeouts TotErrors
1.771s 1.370s 0 0

Overall

TotReqs TotBytes AvgTime AvgReq/s (post)unzip
102 7.4 MB 1.545s 1.94 140 kB/s
Slowest Fastest Timeouts TotErrors
2.627s 1.348s 0 0
HTTPStatus Requests
200 102

 

2017年10月15日
から hiruta
Google Cloud Functions Emulatorについて #gcpug はコメントを受け付けていません。

Google Cloud Functions Emulatorについて #gcpug

Google Cloud Functionsのローカルエミュレータとして昨日のGCPUG shonanで話がありました。

ただ、ローカルエミュレータはNode.js v6.11.1必要なので、MBAで動かすにはnodeをインストール(アップグレード)が必要になります。

https://github.com/GoogleCloudPlatform/cloud-functions-emulator/

 brew update
brew upgrade node
npm install -g npm

local emualtorは、下記でインストールできます。

 npm install -g @google-cloud/functions-emulator

v8.7のnode.jsが入ったので、warningがでましたが、functionsのデプロイ(deploy)、呼び出し(call) は問題ありませんでした。

 Warning: You're using Node.js v8.7.0 but Google Cloud Functions only supports v6.11.1

昨日も話されていましたが、Cloud Functionsのデプロイ調子悪いときとか、デバッグに有益かと思われます。

なお、CloudShellだと、functionsのローカルエミュレータはプリインストールされています。

2017年9月24日
から hiruta
cloud-function-python を試してみました。 #gcpug はコメントを受け付けていません。

cloud-function-python を試してみました。 #gcpug

公式には、node.jsのみサポートされていますが、cloud-function-pythonというpython scriptをCloud FunctionsにデプロイするCLIツールがあるので少し試してみました。(cloud-function-pythonはpureなpython sciriptをnode.jsに変換するツールので、直接cloud functionsにはデプロイは行えません。)

ローカルなmac環境をpyenvを利用してpython実行環境を構築しているのだが、通常のpyenv installでインストールされた環境では、py-cloud-fnを実行する際、python-dev、pyton3-devがないようとエラーになってしまう。

 py-cloud-fn -f myfunction.py my-function http 

そこで、pyenv installでshared libraryをサポートしたpythonをインストールする必要があります。

 env PYTHON_CONFIGURE_OPTS="--enable-shared" pyenv install -v 2.7.12

py-cloud-fnでinde.js等がcloudfn/targetフォルダに出力されているので、gcloud beta functions deployをすれば。Cloud Functionsにデプロイすることができます。

※ネイティブなpythonがCloud Functionsにサポートされることを期待したい。

 

2017年8月6日
から hiruta
RDSログのS3保存 はコメントを受け付けていません。

RDSログのS3保存

RDSのログをダウンロードするには、REST APIで取得しますが、一日経過したログはローテーションされて削除されます。

長期保存するには、定期的にS3にダウンロードする仕組みが必要。

そのまま使えるLambda functionが下記に公開されていました。

AWS Lambda function to export Amazon RDS MySQL Query Logs to S3

上記は差分更新に対応していない、圧縮対応とか改良してくれるスクリプトが公開されていました。(python 3対応)

https://github.com/om732/rdslogs2s3

Cloudwatch Eventsのスケジュールで定期起動するには、複数RDSのログを環境変数より変数のほうが都合がいいので両者を組み合わせてスクリプトを作成しました。

https://github.com/webse/rdslog_s3

また、ansibleからLambda functionsもデプロイすることができます。

 - hosts: localhost
tasks:
- name: looped creation
lambda:
name: '{{ item.name }}'
state: present
zip_file: '{{ item.zip_file }}'
runtime: 'python3.6'
role: 'arn:aws:iam::xxxxxxxxxxxx:role/role-test-dv-rdslog'
handler: 'rdslog2s3.lambda_handler'
region: ap-northeast-1
with_items:
- name: rdslog2s3-test
zip_file: rdslog2s3.zip

 

2017年7月20日
から hiruta
Cloud Spanner設計(PK、テーブル分割) #gcpja はコメントを受け付けていません。

Cloud Spanner設計(PK、テーブル分割) #gcpja

本日(ていうか日付変わっていたので昨日)Cloud Spannerの設計について解説セッションがありました。

酒とゲームとインフラとGCP 第6回 〜早く暑気払いしないと死ぬぞ〜@デジタルハリウッド@御茶ノ水! 

分散リレーショナルデータベースを使う上での設計のポイントが話された。

Cloud Spanner概要

 MySQLのスケールアウトが手間がかかるが、Spannerはノード追加削除でスケールアウトが自由自在

 リージョンなものの提供

 今後マルチリージョンを提供

 MySQLでないので意識するとよいパフォーマンスがでる

 低ワークロードではパフォーマンスが出ない

PKの使い方によってはデータが分散しない(データが偏る)

 オートインクリメントだと1ノードで入る(データが分散しない)可能性あるのでサポートしていない

 サポートしないのも1理由

 UUIDを使う ※128bitのを使うといい

 PKの選択でノードの偏りがある場合あり

  日付だと偏るケースがある

インターリーブ

  インターリーブ=親子関係

  関連したデータのロカリテティを管理できる

  関連したデータはあっちこっちにいくことがなくなる

  PKはインデックスいらない

  どこかのSpannerサーバに格納される場合あり

  セカンダリインデックスは、不要な場合は作成しない、できるだけ使わない

gRPC

  gRPCコネクション デフォルト4、最大256

       デフォルトの4で十分とのこと

  負荷試験でもそう変わらない

  try-errorを繰り返す

   セッション

  トランザクションを実行できるコンテキスト

  並列で行われるトランザクションは各自セッションを利用する必要あり

  セッション数=スレッド数

  MAX10,000

    Developer consoleのエラーレート

  abortしたトランザクションは自動リトライしてくれる

  例外がでていなければエラーレートは無視していい

  ノードは分散ストレージのデータを管理している

  ノードを削除すると管理していたスプリットのオーナが変わる

  障害時も同

  (ドキュメントに記載されていないことだが、)2GB per parent record

テーブル分割

    Size-based splits データの容量でテーブル分割

 Load-base splits 負荷によりテーブル分割

  シーケンシャルINSERTだと分割されない

 負荷試験は20-30j実施

 5分だとノードが十分に活用されていない

 負荷試験はデータベースをドロップしないと、正確な負荷試験ができない場合も

 LSM Treeを使っているとレコード削除だけでは削除されない

 テーブルのクリーンアップは一週間かかる

 TPS

ノード削除できない場合がある。データの容量が多すぎる。5TB Writeして1ノードにしても3ノード必要できないので削除できない

75%CPU超えたら、functionsでノード追加などできる

75%を1ノードの負荷目安

Dailyで取っているのでサポートに問い合わせて別のインスタンスに戻せる

Query Plan cache

  IDを変えると3つのキャッシュが作られるのでParameter Binding

 ( JDBCのPrepareStatementと同じ?)

ノード追加すると若干レイテンシーが落ちるが、しばらくすると回復する

リアルユースケース、実データで負荷試験

ロードツール

年内にもロードツールがでる?Dataflow IO

現状公式にはDML(ていうかWrite系SQL)にはサポートされていないが、SQLを書くと、Spannerコードにしてくれるツールを開発されたが、後々OSS化もあるとのこと

Spanner用のWirte系SQLをサポートした(制限有りの)JDBCドライバもあるが

2017年6月15日
から hiruta
Google Cloud Next ’17 in Tokyo の参加セッション聴講メモ(Day 2) #googlenext17 はコメントを受け付けていません。

Google Cloud Next ’17 in Tokyo の参加セッション聴講メモ(Day 2) #googlenext17

ザ・プリンス パークタワー東京で開催中の Google Cloud Next ‘17 in Tokyo に参加しました。

分散データベースCloud Spannerが明日(6/16?)から東京リージョンasia-northeast1で使用可能になることがキーノートで発表されました。

Container Engine 本番環境へのデプロイ

  • コンテナだけではないと思うんだが、一貫性であることが必要
  • 早急にデプロイを
  • Githubリポジトリでkubernates一番活発と言っていたが、最近は、TensorFlowのリポジトリも活発と思う。
  • ローリングアップデート(ダウンタイム無し)、過去のバージョンへの戻し(undo)、ロードバック
  • コンフィグをエクスポートして、再構成も可
  • Build Triggers
    • リポジトリにpushをトリガーにdocker imageも作成、デプロイも
  • demoで使ったコード

 

SORACOMでデバイスとGoogle マシンラーニングの連携で構築するIoTソリューション

  • SORACOM Beamで、Cloud IoT Coreに接続。
    • GCPのcredentialsはBeamで管理
    • JSONトークン発行も
    • Cloud IoT Coreにデータ送ってしまえば、後は、Functions、DataflowでBigQueryに蓄積することも。※Cloud ML Engineで機械学習連携も(BQ、Dataflow等はオートスケールなので、処理量に応じてスケールアウト、インもできるのでIoTシステムとして最適と思われる)
  • SORACOM FunnelをCloud Pub/Subに接続※新機能

Cloud Platform™ (GCP™)で始める IoT 入門セミナー

BigQueryの先進機能

※NEXT SFの元セッション動画

以前は、スタティックツリー。いまはダイナミックつり-。

Sharedの数を変えることが可能。

ブロードジャストJOINの方が早い

JOINに偏りがあると、クエリ速度が遅くなったり、メモリ不足になる場合も

Limitを指定したり、クエリの分割が重要

カウントもapploximateで。(Hyper LogLog+)

フルサイクルのデータ分析を実現・データ分析基盤を活用したデータサイエンスの実践

※NEXT SFの元セッション動画

GCPは、ほほすべてのサービス(Cloud Pub/Sub、Dataflow、BigQuery他)がオートスケール

スケール状態にかかわらず、全く同じコードを使用可能

ハイパーパラメータチューニングも自動できるCloud ML Engine

仮想マシンでこれらのサービスを作ることもできるが、スケールアウトで問題になる。

様々な分野の事例で解説!クラウドGPUを使ったHPCとリモートデスクトップアプリケーション開発

オンプレミスでGPUを構築するより、クラウドGPUは初期投資なし、構築時間削減が可能

NVIDIA® Tesla® P100 も近々使えるなるとのこと

K80より、8倍速い

将来的には、GPUが使えるゾーン展開も。

 

2017年4月30日
から hiruta
Google Datalabにバンドルされていないライブラリを追加するには #gcpug #gcpja はコメントを受け付けていません。

Google Datalabにバンドルされていないライブラリを追加するには #gcpug #gcpja

Google Datalabにバンドルされていないライブラリはデフォルトの状態では使うことはできない。

バンドルされていないライブラリを使うようにするには

https://cloud.google.com/datalab/docs/how-to/adding-libraries

にも記載されている二通りの方法がある

/content/datalab/.config/startup.sh に、datalab起動時に、pip installする記載を書き込むか、オリジナルなdocker イメージを作成する方法があります。

前者だと、datalab delete –delete-disk datalab-test とはすると、startup.shの内容は消えてしまう。永続的にするには、オリジナルdocker imageを作成する方法になります。

 

Dockerfileの作成をまず行います。

 FROM gcr.io/cloud-datalab/datalab:latest

RUN pip install https://storage.googleapis.com/videointelligence-alpha/videointelligence-python.zip

Video Intelligence APIはalpha版ライブラリをインストールする例になります。

dockerイメージのビルド

 docker build -t asia.gcr.io/[project-id]/datalab:1.0 . 

Container Registryにアップロード

 gcloud docker -- push asia.gcr.io/[project-id]/datalab

Datalabインスタンスの作成

 datalab create --image-name asia.gcr.io/[project-id]/datalab:1.0 --disk-size-gb 10 datalab-test