クラウドインフラ構築記

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

2015年9月15日
から hiruta
JAWS-UGコンテナ支部vol.2 に参加しました。 #jawsug #jawsug_ct はコメントを受け付けていません

JAWS-UGコンテナ支部vol.2 に参加しました。 #jawsug #jawsug_ct

昨日、AmazonにてJAWS-UGコンテナ支部に参加しました。

ECSのサービス担当者によるAmazon ECS Case Study and Use Case

コンテナ

利用率の監視、モニタリングの監視が必要。セキュリティも。

コンテナの状態(Runningしているのか、Stoppingしているか）

コンテナ、クラスタが多くなると、管理も大変になる。ここで、AmazonECS、Kubernetes（Google Container Engine）が必要に。

AmazonECS

クラスタの中で複数のジョブスケジューラを起動できる。他のAWSサービス（EBS、ELB、Cloudformation等)との連携が可能。

シンプルなAPI

DockerHubに登録されているDocker イメージをpull、runするので、pullするのに時間がかかる、DockerHubにイメージを置くのがセキュリティ的に二の足を踏む場合も。

Google Container Registry に相当するサービスが望まれる。あと、コンフィグがjsonフォーマットだけでなく、yamlでも記載できれば。

ユースケース

バッチジョブ

マルチスケジュール機能を活用してバッチ処理に最適。

http://thinkit.co.jp/story/2015/04/10/5855

継続的インテグレーション

immutable infrastrure。サーバー使い捨て。コンテナの起動の高速な点を活用。

分散アプリケーション、マイクロサービス

MVCモデルでWebアプリケーションを開発デプロイすると規模も大きくなる。この反面、1 functionにサービス提供するのにコンテナには最適と考える。

IoT向けのサーバリソースにdockerも選択肢の1つになるのか。

PaasS。マルチテナントに適用しやすくなる。

IMAG0395

cloudpack 鈴木様のスライドより

すべてのインスタンスで動かしたいコンテナがあればAmazonECS Taskで動かせる読み物はこちら。

https://aws.amazon.com/jp/blogs/compute/running-an-amazon-ecs-task-on-every-instance/

EC2→ECS

EC2の資源をそのまま載せ替えることもできるが、2-Tier アーキテクチャで作り直すのがいい。

コンテナはSierの点から運用保守とか考えると導入しずらいのも事実。

Blue-Green Deployment with ECS and monitoring by はてな

ECSでBlue-Green deploymentを行うとすると、Taskのhost portをずらす、Delete/CreateLoadBalancerListenerがアトミックでないので、一時的に紐付けいているものがいなくなることも。この点、HA Proxyで解決できること

モニタリングは、ベーシックな監視はcgroup。詳細は、　https://docs.docker.com/articles/runmetrics/

 

docker in docker 。コンテナの中で、コンテナの話も。docker in dockerは正直実運用には。。。

https://blog.docker.com/2013/09/docker-can-now-run-within-docker/

https://github.com/tehranian/dind-jenkins-slave

docker in dockerとjenkins (Ci)との連携も

https://github.com/jpetazzo/dind

 

2015年9月13日
から hiruta
Datadogで、fluentd、nginxも監視してみました。 はコメントを受け付けていません

Datadogで、fluentd、nginxも監視してみました。

Datadogで、Fluentd、nginxについても監視が可能。

dd-system

Nginxのモジュールngx_http_stub_statusが有効である必要があります。組み込まれているかどうかは、nginx -Vで確認が可能です。

/etc/nginx/conf.d/virtual.conf

location /nginx_status {
stub_status on;
access_log off;
}

datadogの設定ファイルを作成します。.exampleでサンプルがおいてあるので、コピーして作成すればstatus urlを変更すれば完了。

/etc/dd-agent/conf.d/nginx.yaml


init_config:

instances:
# For every instance, you need an `nginx_status_url` and can optionally
# supply a list of tags. This plugin requires nginx to be compiled with
# the nginx stub status module option, and activated with the correct
# configuration stanza. On debian/ubuntu, this is included in the
# `nginx-extras` package. For more details, see:
#
# http://docs.datadoghq.com/integrations/nginx/
#

- nginx_status_url: http://localhost/nginx_status/

dd-nginx

/etc/td-agent/td-agent.conf


<source>
type monitor_agent
bind 0.0.0.0
port 24220
</source>

<match *>
id plg1
type forward
<server>
host localhost
</server>
</match>

設定を反映するには、fluentdを再起動します。

systemctl restart td-agent

下記コマンドで取得できるようになれば設定が反映されています。

curl -s http://127.0.0.1:24220/api/plugins.json

次に、datadogの設定ファイルを作成します。nginxと同様exampleからコピーでほぼ完了。

/etc/dd-agent/conf.d/fluentd.yaml


init_config:

instances:
# Every instance requires a `monitor_agent_url`
# Optional, set `plugin_ids` to monitor a specific scope of plugins.
- monitor_agent_url: http://localhost:24220/api/plugins.json
plugin_ids:
- plg1
# Optional, set 'tag_by' to specify how to tag metrics. By default, metrics are tagged with `plugin_id`
#- monitor_agent_url: http://example.com:24220/api/plugins.json
# tag_by: type

dd-fluentd

最後に、datadogのagentを再起動します。

sytemctl restart datadog-agent

設定が反映されているか下記コマンドで確認できます。

dd-agent info
 fluentd
-------
- instance #0 [OK]
- Collected 3 metrics, 0 events & 2 service checks

nginx
-----
- instance #0 [OK]
- Collected 7 metrics, 0 events & 2 service checks

それ以外にも、RabbitMQ、Cassandra、HA Proxy等監視できるプロダクトが豊富になっています。
 

2015年9月6日
から hiruta
Cassandra Meetup Tokyo 2015, Summerに参加してきました。 #cassandrameetupjp はコメントを受け付けていません

Cassandra Meetup Tokyo 2015, Summerに参加してきました。 #cassandrameetupjp

9月4日、Yahoo! Japanの方でCassandra Meetup Tokyo 2015が行われました。

Cassandraは、NoSQLの技術になり、DynamoDB、Google BigTableの仲間に入ります。

Apache Sparkと組み合わせることで、強力な分析基盤を構築することも可能。

Cassandra Meetup Tokyo 2015, Summer with Apache Cassandra Chief Evangelist, Patrick McFadin

Cassandra は、マスターレス、peer-to-peerで稼働するので、SPOFになり得ない、耐障害性にも優れています。

Wather Stationから気象データを収集するユースケースを話されましたが、Cassandraは、IoT deviceのデータ収集にも使用可能。

Apache Sparkと組み合わせられる。Apache Sparkは、In-Memoryで高速でデータ分析が行える特徴を持っており、Spark Streaming、SQL、機械学習(Machine Learning)、GraphXのコンポーネントもあります。

data processingを聞くと、Google Dataflowが思い浮かんだ。ClouderaがGoogle DataflowをSparkに統合する計画も。

http://jp.techcrunch.com/2015/01/21/20150120google-partners-with-cloudera-to-bring-cloud-dataflow-to-apache-spark/

Partition and Token Range

Cassandra dataをスキャンするには、token ringを使って、マルチノードにアクセスする。

Cassndaraから抽出したデータをCassndaraに書き出すことも。

spanBy

groupByより効率良くグルーピングできる。

Cassandraとsparkを使った yahooの事例

50を超えるyahooのサービスで利用されていること。

StorageにSSDを利用することで、QPS 6倍、レイテンシ1/10と性能向上が図れる。

Sparkはデータの可視化に。Sparkは、In-memoryで高速ではあるが、hadoopオーバーヘッド、HDFSの点でも、hadoopより高速と言える。

MySQLで4,000万レコードの更新がある場合、レプリケーション遅延が発生していた。

RDB系だとトランザクション量が多いとレプリカ遅延(RepliaLag)が発生する。トランザクション量が多い場合、NoSQL系が。

BlockTransferServiceが現状SSLされていないことも。

CyberAgentでの事例

Cassandraの導入。

jenkins、ansible + SensuでCassandraを使った運用。Masterレスなので、SPOFがない、ノードを増やすことで、スケールアウトも。

cpu/mem/nw/latency/fd はもちろん、jvmのGC、Cassandra_Status、Cassandra clusterのheathの監視を行っている。

repair & cleanupを7日。NW断があった障害に関しても、データロストはなかった。

書き込みを一端止めて、snapshotを取得することで、PITRに近いこともできるのでは。組み込まれることを期待。

Cassandra Tools

EC2でCassandraを使う場合、Ec2MultiRegionSnitch、 Ec2Snitchを確認。

  •  cassandra-stress
    • Cassandra負荷掛けツール。read/writeで負荷を掛けることが可能。
  • cassandra-stressd
    • 長時間負荷をかける場合は、こちら
  • cassandra.in.sh
  • json2sstable
  • sstable2json
    • deprecatedされており、Cassandra 3.0では廃止予定
  • sstablelevelreset
  • sstableofflinelevel
  • sstablerepairreset
  • sstablesplit
  • token-generator
    • 最適なtokenを算出してくれる

AWS上でCassandra環境構築する場合は、　cassandgo

参加者に、enterprise版のCassandraが入った2Gのusbメモリ。

P1000410

 

http://www.infoq.com/jp/news/2014/11/netflix-cassandra

http://www.infoq.com/jp/news/2014/11/netflix-cassandra

2015年8月30日
から hiruta
GKEのコンテナをDatadogで監視 はコメントを受け付けていません

GKEのコンテナをDatadogで監視

3-datadog-docker

※glcoud compoents updateでCloud SDKを最新にしておきます。

GKEクラスタを作成

 

gcloud container clusters create test-cluster --zone asia-east1-a --machine-type g1-small --num-nodes 1 --network stage-network

指定しないと、n1-standard-1とクラスタノード数3で起動します。

gcloud containers コマンドのデフォルトクラスタを「test-cluster」に設定します。

gcloud config set container/cluster test-cluster

kubectlとの連携

gcloud container clusters get-credentials

作成したクラスタの確認

gcloud container clusters describe test-cluster --zone asia-east1-a

作成するコンテナ用jsonを作成します。jsonだけでなく、yamlでも作成可能です。

{
 "kind": "Pod",
 "apiVersion": "v1",
 "metadata": {
 "name": "nginx",
 "namespace": "default"
 },
 "spec": {
 "containers": [
 {
 "name": "nginx",
 "image": "nginx",
 "imagePullPolicy": "Always",
 "ports": [
 {
 "containerPort": 22,
 "name": "ssh",
 "protocol": "TCP"
 }
 ]
 }
 ]
 }
}

Pods (Containers)を作成します。

kubectl create -f nginx.json
kubectl describe pods nginx

コンテナを削除する場合は、以下コマンドで完了。

kubectl delete -f nginx.json

作成したコンテナを確認します。Node Clusterも確認できます。Datadog Agentをインストールする際、sshログインする必要があります。

kubectl get pods nginx -o wide
NAME READY STATUS RESTARTS AGE NODE
nginx 1/1 Running 0 -340s gke-test-cluster-919cf59d-node-zgrc

Containerが起動すれば、Runningになるかと思います。内部的にイメージになんらか問題が生じて、Containersが起動できなくなっているケースもあります。Node Cluseterにログイン後、docker ps -aで、Containerは確認できます。（Datadogを使えば、コンテナの状態も確認できると思われます。）

Datadogに登録

Datadogの登録は割愛します。



 


ホストサーバーにDatadog Agentをインストール


Datadogのダッシュボードにある左メニューのIntegrationのAgentを選んで、「Debian」を選択します。 すると1行ペラっとコマンド出てきますから、それをコピーします。


DD_API_KEY=XXXXXXXXXXXXXXXXXXXXXXX bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)"


 


ホストサーバーからDocker Agentをインストール


IntegrationのAgentを選んで、「CoreOS」を選択します。


docker run -d --name dd-agent -h `hostname` -v /var/run/docker.sock:/var/run/docker.sock -v /proc/mounts:/host/proc/mounts:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e API_KEY=XXXXXXXXXXXXXXXXXXXXXXX datadog/docker-dd-agent


Docker 用監視ファイルの設定


サンプルのdocker用yamlファイルが置かれているので、リネームして、agentを起動します。




cp /etc/dd-agent/conf.d/docker.yaml.example /etc/dd-agent/conf.d/docker.yaml


dd-agent start

		
								
				
		
	

			


								
				



	

				
2015年8月16日

		から hiruta

		CloudSQLについて、TPC-Cベンチマークしてみました。 #gcpja はコメントを受け付けていません

	

    
	

			
CloudSQLについて、TPC-Cベンチマークしてみました。 #gcpja

	

        
	

					
Amazon Auroraに引き続き、CloudSQLのベンチマークを測定してみました。Cloud SQLに、Amazon Aurora相当のインスタンスタイプがないので、厳密な比較はできませんが、参考程度に。


ベンチマーク環境


ベンチマークの種類


RDBMSのベンチマークで一般的なTPCのオンライントランザクション処理の指標である「TPC-C」を行います。

ベンチマーク用ツールはMySQLのOracle ACEである平塚氏が作成したJdbcRunnerのTPC-C簡易実装であるTiny TPC-Cを使用します。


使用データ






Table
Record




customer
480000




district
160




item
100000




new_orders
144000




order_line
4799437




orders
480000




stock
1600000




warehouse
16






CloudSQLは以下の状態で行いました。






インスタンスクラス
DB Engine version
備考




D8
5.6.26
Engineのバージョンは明示的には指定不可






メモリ4G※CPU情報については公開されていませんので、コア数は不明。mysqlのバージョンもmysqlに接続して確認。gcloudとDeveloper Consoleから確認はできない。


測定用インスタンスは、CloudSQLと同じリージョンにあるpreemptible VM (n1-standard-1)で。


検証用とかにPreeemtible VMお得で便利です。


結果






多重度
Throughput(tps)
Response time (90%tile)





New-Order
Payment
Order-Status
Delivery
Stock-Level
New-Order
Payment
Order-Status
Delivery
Stock-Level




1
6.3
6.3
0.6
0.6
0.6
125
56
10
174
6




4
 16.7
 16.7
 1.7
 1.7
 1.7
 198
 146
 10
 245
 6




16
 43.1
 43.1
 4.3
 4.3
 4.3
 377
 290
 10
 397
 7




32
59.7
59.7
6.0
6.0
6.0
556
335
16
555
13






Cloud SQLは、IPv6にも対応、Repliaなどにも対応しているので、今後期待できるサービスです。


Cloud SQLはGCEのネットワークに配置することができないので、今後改善してほしいところ。

		
								
				
		
	

			


								
				



	

				
2015年8月16日

		から hiruta

		Amazon Auroraをベンチマークしてみました。 はコメントを受け付けていません

	

    
	

			
Amazon Auroraをベンチマークしてみました。

	

        
	

					
Amazon Auroraのベンチマークを測定してみました。


ベンチマーク環境


ベンチマークの種類


RDBMSのベンチマークで一般的なTPCのオンライントランザクション処理の指標である「TPC-C」を行います。

ベンチマーク用ツールはMySQLのOracle ACEである平塚氏が作成したJdbcRunnerのTPC-C簡易実装であるTiny TPC-Cを使用します。


使用データ






Table
Record




customer
480000




district
160




item
100000




new_orders
144000




order_line
4799437




orders
480000




stock
1600000




warehouse
16






RDSは以下の状態で行いました。






インスタンスクラス
DB Engine version
備考




db.r3.xlarge
Aurora 5.6.10a
Engineのバージョンは明示的には指定不可






RDSと測定用クライアント(r3.xlarge)は別AZに配置。


結果






多重度
Throughput(tps)
Response time (90%tile)





New-Order
Payment
Order-Status
Delivery
Stock-Level
New-Order
Payment
Order-Status
Delivery
Stock-Level




1
9.9
9.9
1.0
1.0
1.0
93.20
20
10
113
7




4
37.9
37.9
3.8
3.8
3.8
95
22
10
116
8




16
129.2
129.2
12.9
12.9
12.9
107
32
12
131
9




32
198.3
198.3
19.8
19.8
19.8
133
66
14
163
13






 






多重度
CPU使用率
DiskQueueDepth(Count)




1
10%
9




4
30%
16




16
80%
13




32
92%
25






まとめ


多重度1でquery_cache_typeを変更して測定してみましたが、on/offの差は見られませんでした。


また、RDSと測定用クライアントを同一AZに配置した場合に比べて、3割程度の性能劣化が見られました。


以下は、測定用クライアントとRDSが同一AZにあった場合の結果になります。






多重度
Throughput(tps)
Response time (90%tile)





New-Order
Payment
Order-Status
Delivery
Stock-Level
New-Order
Payment
Order-Status
Delivery
Stock-Level




16
195.5
195.6
19.6
19.6
19.6
67
27
7
91
9






 

		
								
				
		
	

			


								
				



	

				
2015年7月28日

		から hiruta

		July Tech Festa 2015に7/25参加しました。 #jtf2015 はコメントを受け付けていません

	

    
	

			
July Tech Festa 2015に7/25参加しました。 #jtf2015

	

        
	

					
7/25 産業技術大学院大学で行われた　July Tech Festa 2015に行ってきました。


以下のセッションに参加しました。


IoT時代のデバイスクラスタHashicorp consulを用いたIntel Edisonクラスタの構成


fogとクラウドどう役割分担させるのがポイント。fogはリアルタイムの処理を行い、クラウド側では大量データ蓄積、分析・学習に利用する。


実際構築したシステムの技術の解説。MQTT、Wi-Fi Mesh Network、Consul


MQTTは、TLSで暗号化が推奨。


Wi-Fi Mesh Networkは、SPOFにならないとか良い点もあるが、デフォルトカーネルでは動かず、カーネルビルドが要。→


Consul 運用自動化ツール。Wi-Fi  Mesh Networkと相性が良い。Go 1.4 x86 32bitのバイナリで動かせる。


真剣にDocker運用を考える人に、各種監視ツールとサービスを比


Dockerの監視を自作(DIY)で、それとも、SaaSの監視サービスでまかないか。


Docker  Containerの監視粒度は、1回/5分では不十分。1データ/1秒、一年間保存位しないとNG


CloudWatchの監視粒度とかではDocker Containers監視は不十分ということに。


Docker Containers監視を自作(DIY)で求められる監視粒度が満足できればいいが、そうは簡単ではない。


SaaS系の監視サービスだと、サービス終了した場合はどうするか個人的には気になる。


New Relic、App Dynamics、Mackerel、Signakfx、libratoについて、一丁一端がある。


DatadogがDocker Containers監視については現状ベストとのことに。


今話題のAnsibleのモジュールをゼロから自分で作ってみよう


標準で提供されているモジュールだけでも十分だが、かゆいところまでしたい場合はモジュールを作成する。


本当に足りない機能をモジュールで作成するのがいい。(今回のセッションではSolarisのホスト名変更が標準では対応していないので、モジュールを書いて、pull requestした話がありました。）


開発したモジュールを標準モジュールに取り組んでもらうには、いくつかのルールがある。説明、利用例に準拠させる必要がります。


仮想化とストレージの新しい形！ハイパーコンバージインフラの技術解説


オンプレのストレージ仮想化は、スモールスタートしずらい


安価なストレージ仮想化では、SANのポート、ストレージヘッドの性能に制限


拡張する場合、非効率なサイロ化


そこで、ソフトウェア処理で何とかするのが、Nutanix


Googleが描く、MapReduceを超えたビックデータの世界


Googleのコンテナ技術Borg


Google BigQuery


Googleも初期には、oracleとかRDBを使っていたが、膨大なGooogle検索のインデックスを管理するPBサイズになり、対応しきれなくなったとのこと。BigQueryのサービスが生まれた。インフラをあまりしらないユーザも使える。最適化されていたクエリ（糞クエリ）も高速で実行が可能。管理者不要、パフォーマンス劣化がない


1,000億行Read(フルスキャン)しても、20秒かからない。


RDBだと、一台のマシンで1日かかることも。


BigQueryがなぜ速いのかの説明。カラム指向ストレージ。カラム毎に異なるストレージに入れるので、クエリ実行効率、圧縮効率もいい


数千台のサーバーで並列実行。他のクラウドだとマネできない。


RasPiからBigQueryにも。fluent-plugin-bigqueryを使う場合、GCEだと、AWSでいうIAM Roleに相当する自動でアクセスするcredentailsを取得する仕組みがRasPiとかIoT deviceだと使えないのが課題。


Google Dataflow


機械学習（Machine Learning）


実行環境側でshared。Kinesisの場合、sharedをKinesis Streamを作成する際、指定する必要があるが、スケールも自動でしてくれる。

		
								
				
		
	

			


								
				



	

				
2015年7月18日

		から hiruta

		Amazon Linuxのdocker イメージをGoogle Container Registryからpull・run #gcpja はコメントを受け付けていません

	

    
	

			
Amazon Linuxのdocker イメージをGoogle Container Registryからpull・run #gcpja

	

        
	

					
Amazon Linuxのdocker imageを作成し、Google Container Registryにアップロードを行い、


Amazon Linuxのdocker イメージを作成する方法については、http://dev.classmethod.jp/cloud/aws/docker-serverspec-configspec-ci/　を参照にしました。


AmazonLinux dockerイメージをローカルのdocker環境にインポートします。


# docker import < amazonssh.tar


# docker tag amazonssh asia.gcr.io/#your-project-id#/amazonssh


Google Container Registryにアップロードを行います。


# gcloud docker push asia.gcr.io/#your-project-id#/amazonssh
The push refers to a repository [asia.gcr.io/#your-project-id#/amazonssh] (len: 1)
Sending image list
Pushing repository asia.gcr.io/#your-project-id#/amazonssh (1 tags)


適当なVMインスタンスを起動します。GCSへのリード書き込み権限を付与することを忘れずに。


# gcloud compute instances create instance-test-docker --image centos-7  --scopes https://www.googleapis.com/auth/devstorage.read_write


dockerのインストール、起動


# yum install docker


# service docker start


asia リージョンのバケットにアップしたので、gcr.ioで見つからないとエラーとなります。


# docker pull gcr.io/your-project-id/amazonssh
Trying to pull repository gcr.io/your-project-id/amazonssh ... not found
FATA[0000] Error: image your-project-id/amazonssh:latest not found


Google Container Registryからdocker イメージを取得します。


# docker pull asia.gcr.io/your-project-id/amazonssh
Trying to pull repository asia.gcr.io/your-project-id/amazonssh ...
3fe81e712d9e: Download complete
a09fe07f3274: Download complete
81bcdeaea41c: Download complete
7ad48843769c: Download complete
9b15589bc305: Download complete
48fc49b0c3fa: Download complete
25a9a1b3f0d0: Download complete
cbfa77630235: Download complete
76ab5065c4b2: Download complete
Status: Downloaded newer image for asia.gcr.io/your-project-idamazonssh:lat


docker イメージがpullできていることを確認できます。


# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
asia.gcr.io/your-project-id/amazonssh latest 3fe81e712d9e 2 weeks ago 874.1 MB


docker containerを起動


# docker run -h amazonssh -t 3fe81e712d9e /bin/bash
Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5534906edb50 3fe81e712d9e:latest "/bin/bash" 17 seconds ago Up 16 seconds 22/tcp agitated_fermi


GCEでAmazon Linuxの環境を構築することも可能となります。


Container-Optimized Compute Engine Instancesでインスタンス起動時にContainer Registryから取得して、Containerを起動することも可能ですが、こちらについては、別途機会に。

		
								
				
		
	

			


								
				



	

				
2015年7月12日

		から hiruta

		Cloud Source Repositoryを使用してみました。 #gcpja はコメントを受け付けていません

	

    
	

			
Cloud Source Repositoryを使用してみました。 #gcpja

	

        
	

					
Google Cloud Platformには、git リポジトリ、Cloud Source Repositoryが提供されています。現在ベータといことで、無料で使うことが可能。(500MBのサイズ制限は有り）


ローカル環境に、Chef、knife-soloの環境を構築


curl -L https://www.opscode.com/chef/install.sh | 


/opt/chef/embedded/bin/gem install knife-solo --no-ri --no-rdoc


knife solo init knife-solo


cd knife-solo


Chefのリポジトリでgit local repositoryとして初期化


git init 


すべてのファイルをgitの管理下に


git add -A


git commit -m 'first commit'


Generate and store your Git credentials


screencapture-console-developers-google-com-project-skillful-fx-531-clouddev-source-repo-1436674845613


生成されたものを、.netrcに貼り付ける。


git config credential.helper gcloud.cmd


gitのリモートレポジトリとしてgoogleの下記URLを登録


git remote add google https://source.developers.google.com/p/your-project-id/


Cloud repositoryにアップロード


git push --all google


Developer Consoleから下記のように確認できるようになります。


screencapture-console-developers-google-com-project-skillful-fx-531-clouddev-source-browse-vDFBdy1OoJh-master-1436673896028


 


プライベートリポジトリとして使うことができます。プライベートリポジトリx1しか作成できないようです。

		
								
				
		
	

			


								
				



	

				
2015年6月23日

		から hiruta

		EFS(Elastic File System)のスナップショットオプションはない？ はコメントを受け付けていません

	

    
	

			
EFS(Elastic File System)のスナップショットオプションはない？

	

        
	

					
Elastic File SystemのFeedback（バックアップについて）を送ったら、下記回答が得られました。


We do not currently have a “snapshots” feature, but you can use standard file system tools and practices such as performing an rsync to another file system, running a script to take regular rsync-based differential backups, creating ad-hoc copies of individual directories, using third party backup tools, etc. to protect your data against logical corruption.


EFSは、snapshotsは対応していないとのこと。rsyncのような標準のシステムツールでバックアップするてことになる模様。サードパティ用のバックアップを併用するのがいいようです。


ある時間から復元するようなことはできない。バックアップの設計は別途必要か。