Google Cloud Platform Japan 公式ブログ: Container Engine

ASP.NET Core アプリを GCP にデプロイする 4 つの方法

2017年10月31日火曜日

.NET Core アプリケーションを App Engine flexible environment で稼働Container EngineApp Engine flexible environmentGoogle Cloud Platform

Cloud Tools for Visual Studio エクステンションを利用して Visual Studio から直接デプロイする

“dotnet publish” によって Framework Dependent Deployment バンドルをデプロイする

カスタム Dockerfile で App Engine flexible environment にデプロイする

カスタム Dockerfile で Container Engine にデプロイする

デプロイを定義し、実行に必要な依存関係がすべて含まれる .dll（アプリケーションのパブリッシュで生成）などのビルドアーティファクト

App Engine の場合は、アプリケーションのデプロイメントファイルのルートにある app.yaml ファイル

方法 1 : Visual Studio から直接デプロイするCloud Tools for Visual Studio

方法 2 : Framework Dependent Deployment バンドルをデプロイするFramework Dependent Deployment バンドル<ItemGroup> <None Include="app.yaml" CopyToOutputDirectory="PreserveNewest" /> </ItemGroup>runtime: aspnetcore env: flex追加で app.yaml の設定を行えば

スタートアッププロジェクトのディレクトリから、お好みの設定で “dotnet publish” コマンドを実行します。以下に例を示します。

dotnet publish -c Release

これで、“bin\\netcore\publish” というディレクトリにリリースビルドがパブリッシュされます。アプリケーションのデプロイメントファイルや、.csproj に app.yaml を追加していた場合はそれも含まれます。

以下のコードを実行して App Engine flexible environment にデプロイします。

gcloud app deploy 
bin\<configuration>\netcore<version>\publish\app.yaml

アプリケーションが App Engine にデプロイされ、アプリケーションを Docker イメージにラップするといった複雑な作業はすべて gcloud が処理してくれます。

方法 3 : カスタム Dockerfile で App Engine にデプロイするruntime: custom env: flex

パブリッシュされたアプリケーション用に Dockerfile を作成する
パブリッシュされたアプリケーションのルートに沿ってこのまま進みたい場合は、Dockerfile を指定し、パブリッシュされたディレクトリをベースにアプリケーションのイメージをビルドします。Dockerfile は次のようになります。

FROM gcr.io/google-appengine/aspnetcore:2.0
ADD ./ /app
ENV ASPNETCORE_URLS=http://*:${PORT}
WORKDIR /app
ENTRYPOINT [ "dotnet", "MainProject.dll" ]

この Dockerfile の例では、ベースイメージとして “gcr.io/google-appengine/aspnetcore:2.0” が使われていることに注目してください。ここでは、App Engine と Container Engine での ASP.NET Core アプリケーションの実行に最適化された Docker イメージを作成しましたが、カスタム Dockerfile にはこのイメージを使用することを強くお勧めします。

Googleでも、デプロイにあたって Dockerfile を生成するときは、このイメージと同じものを使っています。ただし、アプリケーションの .NET Core ランタイムの正しいバージョンを参照するように変更することを忘れないでください。

パブリッシュされたディレクトリに Dockerfile があることを確認するには、.csproj に Dockerfile を追加してください。そうすれば、アプリケーションがパブリッシュされた際に Dockerfile もパブリッシュされます。Dockerfile がスタートアッププロジェクトのルート、つまり .csproj および app.yaml と同じレベルにあると想定し、次のコードを .csproj に追加します。

<ItemGroup>
  <None Include="app.yaml" CopyToOutputDirectory="PreserveNewest" />
  <None Include="Dockerfile" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>

この変更により、“dotnet publish” を実行するたびに、パブリッシュされたディレクトリに両ファイルがコピーされるようになります。デプロイするには、上述の手順に従ってください。

dotnet publish -c Release

gcloud app deploy 
bin\<configuration>\netcore<version>\publish\app.yaml

アプリケーションのコンパイルとパブリッシュを行う Dockerfile を作成する
Linux 上での ASP.NET Core アプリケーションのビルドが可能な場合は、マルチステージ Dockerfile を使うことも検討すべきです。これは、最終的なアプリケーションのイメージをビルドする前に、ビルドプロセス中にリストアとパブリッシュを実行するものです。こうすればデプロイ中にビルドが終わるため、アプリケーションのデプロイがより便利になります。

この場合の Dockerfile は次のとおりです。

# First let’s build the app and publish it.
FROM gcr.io/cloud-builders/csharp/dotnet AS builder
COPY . /src
WORKDIR /src
RUN dotnet restore --packages /packages
RUN dotnet publish -c Release -o /published

# Now let's build the app's image.
FROM gcr.io/google-appengine/aspnetcore:2.0
COPY --from=builder /published /app
ENV ASPNETCORE_URLS=http://*:${PORT}
WORKDIR /app
ENTRYPOINT [ "dotnet", "multistage-2.0.dll" ]

この Dockerfile では、“gcr.io/cloud-builders/csharp/dotnet” というビルダイメージを利用しています。このイメージは、サポート対象となる .NET Core 全バージョンの .NET SDK をラップするものです。

この手法の主なメリットは、app.yaml と Dockerfile をプロジェクトのルートで .csproj の横に置くことができる点です。そのため、アプリケーションをデプロイするには次のコマンドを実行するだけで済みます。

gcloud app deploy app.yaml

これにより、アプリケーションのソースが Cloud Container Builder にアップロードされ、そこでビルドが行われます。結果として得られるビルドアーティファクトは最終的なアプリケーションのイメージを生成するときに使われ、そのイメージは App Engine にデプロイされます。ビルドプロセス中にテストも実行できるので、これを完全な CI/CD（継続的インテグレーション / 継続的デリバリ）ソリューションとすることができます。

方法 4 : Container Engine にデプロイするContainer Engineアプリケーションの Docker イメージを作成するCloud Container RegistryCloud Container Builderkubectl run myservice --image=gcr.io/<your project id>/<app name> --port=8080” という Docker イメージが作成されます。“$PROJECT_ID” は自動的に GCP プロジェクトの ID に置き換えられ、“” にはアプリケーションの名称が入ります。Container Engine クラスタにイメージをデプロイするgcloud components install kubectlgcloud container clusters get-credentialskubectl run myservice --image=gcr.io/<your project id>/<app name> --port=8080注 : ここでは、Docker コンテナがポート 8080 をエクスポートすることを前提としています。これは App Engine flexible environment のデフォルトです。また、ポート 80 からサービスを公開することも前提としています。こうしたデフォルト設定を変更したい場合は、こちらのドキュメントを参考してください。kubectl expose deployment myservice --port=80 --target-port=8080 --type=LoadBalancer最後にこちらこちらのリポジトリ同リポジトリ* この投稿は米国時間 10 月 11 日、C# Team Lead である Ivan Naranjo によって投稿されたもの（投稿はこちら）の抄訳です。- By Ivan Naranjo, C# Team Lead

Rocro株式会社の導入事例：GAE + GKE をフル活用し、高品質な開発者向け SaaS サービスをソニーグループである Rocro株式会社が少数精鋭で開発・運用

2017年10月17日火曜日

Google Container EngineGoogle App EngineRocro株式会社ソニーグループの開発者向けサービスがいよいよ一般公開

『Inspecode』の見やすいダッシュボード。

ソースコード解析実行時にオンデマンドでサーバーを割り当て、解析を並列実行。

そして、それと同時に API ドキュメント生成＆ホスティングサービス『Docstand（ドックスタンド）』もサービスを開始。これは面倒なドキュメントの生成・維持・管理・公開を自動化してくれるというもので、やはり作業の自動化が大きな売りとなっています。さらに近日中には、自動負荷試験サービス『Loadroid（ロードロイド）』も投入予定。これは、手間のかかる負荷試験を簡単なシナリオを書くだけで実施できるようにするというものです。社内のテストでは、これまで 2 週間かかっていた負荷試験（準備期間含む）が、わずか 4 時間で終わってしまったというケースもあるのだとか。

サービスの開発・運用に Google Cloud Platform の先端テクノロジーが活躍

Rocro 構成図

PDFこちら

セキュリティ比較 : コンテナと VM の違いとは

2017年8月22日火曜日

アプリケーションがモジュール化される（モノリスからマイクロサービスへ）

リリースのオーバーヘッドが軽減される（便利なパッケージング形式と、明確に定義された CI/CD）

寿命が短いため、陳腐化したパッケージの残存リスクが低減される（数か月～数年が数時間～数日へ）

稼働後に、最初の状態からの逸脱が発生しにくい（ワークロードが短命で、簡単に再構築や再プッシュが行えるため、メンテナンスのための直接アクセスが減る）

コンテナのセキュリティ境界にまつわる誤解Google Container EngineフルマネージドノードKubernetesAppArmortaint and toleration陳腐化したパッケージの排除CVEVerizon Data Breach Investigation Report, 2015フルマネージドノード一元的なガバナンスのために

VM は不透明なアプリケーションパッケージング形式であり、デプロイ前に内容を検査して一覧化するためのワークフローを効率的な形で確立することが難しい。

VM イメージ管理は標準化されておらず、広く採用されてもいないため、プロジェクトにデプロイされたことのあるすべてのイメージを追跡することは難しい。

VM ワークロードは寿命が長く、しかもアプリケーションおよび OS の更新やメンテナンスの際に管理者によって頻繁に操作されるため、それが原因でデプロイ時のもともとの状態から大きく逸脱してしまうことがある。

セキュリティに対する責任の共有まとめGoogle Cloud Platformこちらのウェブページ* この投稿は米国時間 8 月 9 日、Product Manager である Jianing Guo によって投稿されたもの（投稿はこちら）の抄訳です。- By Jianing Guo, Product Manager

Codefresh による Kubernetes と Container Engine への自動デプロイ

2017年8月22日火曜日

編集部注 : 今回は、Google のパートナーである Codefresh の投稿をお届けします。Codefresh はこのほど、社名と同名のデリバリツールと Google Container Engine の密接な統合により、Kubernetes へのコンテナのデプロイを容易にしました。本稿では、この統合と、Container Engine へのデリバリを数分で自動化する方法が詳しく紹介されています。4 つのステップで Kubernetes へのデプロイを開始ステップ 1 : Google Cloud でクラスタを作成Google Cloud Console

ステップ 2 : Codefresh を Google Cloud Platform（GCP）に接続Codefresh

ステップ 3 : クラスタを追加

ステップ 4 : デプロイを開始！

ステップ 5（オプション）: 生成された Yaml ファイルを調整ビルド、テスト、デプロイパイプラインを接続

GCP と Codefresh の共催ウェビナーのご案内こちら1お試しください1 通常の利用条件が適用されます。* この投稿は米国時間 8 月 8 日、Codefresh の CEO である Raziel Tabib 氏によって投稿されたもの（投稿はこちら）の抄訳です。- By Raziel Tabib, CEO, Codefresh

ゲスト投稿 : MLB ファン向けの新サービスを Container Engine で構築した Loot Crate

2017年8月19日土曜日

編集部注 : Loot Crate は、ゲームやポップカルチャーなどのファンの間ではよく知られた企業で、テーマごとのお楽しみボックスを 65 万人の会員に毎月届けています。同社はバックエンドサービスを Heroku で構築していますが、新たに手がけた “Sports Crate” サービスでは Rails アプリを Google Container Engine でコンテナ化し、Jenkins で継続的デプロイを行っています。本稿ではその概要を紹介しましょう。

Container EngineJenkins による継続的デプロイVic IglesiasJenkins Multibranch PipelinesKubernetes での継続的デプロイGoogle Cloud StorageRake タスクGoogle Container Registryローカルの開発環境で秘密情報の管理を改善RailtieTLS の解除と負荷分散Ingress リソースNginx Ingress ControllerGoogle Cloud Platform自動スケーリングとモニタリングKubernetes の Horizontal Pod AutoscalingDatadog の Kubernetes AgentPagerDutyStackdriverサービス始動

* この投稿は米国時間 7 月 12 日、Loot Crate の DevOps 担当 Director である Greg Brown によって投稿されたもの（投稿はこちら）の抄訳です。- By Greg Brown, Director, DevOps, Loot Crate

ソニーネットワークコミュニケーションズ株式会社の導入事例：BigQuery の導入でデータサイエンティストが “価値ある仕事” に集中できるように

2017年8月17日木曜日

BigQueryCloud DataflowCloud Pub/SubContainer Engineソニーネットワークコミュニケーションズ株式会社脱「80：20 ルール」に向けて GCP を導入

GCP の成長が、我々のビジネスも成長させていく

Cloud DatalabCloud MLCloud Dataprepこちらこちら

Container Engine のアップデート : Kubernetes 1.7 に対応し、セキュアなハイブリッドワークロードを強力にサポート

2017年7月27日木曜日

Google Cloud PlatformGoogle Container EngineKubernetesエンタープライズセキュリティContainer-Optimized OSSRE

今回のリリースから kubelet は知る必要のあるオブジェクトだけにアクセスするようになります。Node authorizer（ベータ）により、kubelet の API アクセスは、スケジューリングされたポッドに属するリソース（秘密情報など）に制限されます。この機能は、不正侵入されたノードや信頼されていないノードからのクラスタ保護を強化します。

機密性の高いワークロードでは、ネットワークの分離がセキュリティ上の重要な手段となります。Kubernetes の Network Policy API は、相互通信を許可するポッドをお客様が指定できるようにすることで、多層防御を提供し、マルチテナンシーのセキュリティを向上させます。ポリシーの強制は、アルファクラスタでも有効にできるようになりました。

Google Cloud Load Balancing（GCLB）による HTTP の再暗号化によって、GCLB からサービスバックエンドまでの間でも HTTPS が使えるようになりました。これは、お客様から多くのリクエストが寄せられていた機能です。Google のグローバルネットワークに入ったあとでもデータは完全に暗号化されており、それがお客様に安心感をもたらします。

ポッド間のネットワークの分離（Network Policy）

ノード間のリソースの分離（Node authorizer）

クラスタリソースの一元管理（RBAC）

ハイブリッドネットワーキング

すべてのプライベート IP アドレス（RFC-1918）サポートの GA（正式リリース）により、プライベート IP の範囲内でクラスタ作成やリソースアクセスが可能になり、既存ネットワークで Container Engine クラスタを使用する際の能力が拡張されます。

Internal Load Balancing（ベータ）を介してサービスにアクセスできます。これにより、Kubernetes と非 Kubernetes がプライベートネットワークで相互アクセスできるようになります 1。

ソース IP の保存が GA（正式リリース）となり、アプリケーションは、Kubernetes から提供されているサービスのクライアント IP アドレスを完全に認識して動作できるようになりました。

エンタープライズのための拡張性API Aggregationservice catalogDynamic Admission Control

Initializers は、Kubernetes オブジェクトの作成時に変更を加えることができます。Initializers を使用すれば、デプロイされるすべてのポッドに Istio サイドカーコンテナを注入することで、Container Engine アルファクラスタに Istio 機能を追加できます。

Webhooks により、エンタープライズポリシーをチェックできます。たとえば、デプロイされたコンテナが自社のセキュリティ監査に合格していることを確認できます。

移行ワークロードの多様性

ローリングアップデートを含む StatefulSet Update strategies（ベータ）から選択します。

並列あるいは順序指定のポッドプロビジョニングにより、ロールアウトのスピードを最適化できます。Kafka などのステートフルアプリケーションで特に役に立ちます。

アルファクラスタデベロッパーの作業効率向上

自動修復機能（ベータ）は不健全な状態のノードを監視し、デベロッパーの手を煩わせることなく自動的に修復します。

今回のリリースでは自動アップグレード機能（ベータ）にノードレイヤでの Pod Disruption Budgets が組み込まれ、インフラストラクチャやアプリケーションコントローラのアップグレードを予測可能で安全なものにしています。

キャパシティが不要な場合に備え、ノードプールのスケーリングで 0 もしくは 1 をサポートします。

最もコスト効果の高い方法で自動スケーリングする料金ベースの Expander をサポートします。

類似ノードのグループをバランスよくスケールアウトします。複数のゾーンにまたがるクラスタで役に立ちます。

Container Engine の UI

Container Engine サポートリージョンの拡大GCP リージョン

シドニー（australia-southeast1）

シンガポール（asia-southeast1）

オレゴン（us-west1）

ロンドン（europe-west2）

リージョンリリースノート

家電製品の設計や開発をビジネスとしているヨーロッパ屈指のテクノロジー企業 BQ は、Container Engine でプリエンプティブル VM を有効活用することで、クラウドホスティングのコストを約 60 % 削減しつつ、15 から 350 へとサービスを迅速に拡張できました。詳しくはこちらをご覧ください。

ソーシャルメディアのネットワーキングプラットフォームである Meetup は、Container Engine の助けを借りて、オンプレミスデータセンターのモノリシックアプリケーションから、マルチクラウド対応のアジャイルなマイクロサービスアーキテクチャへと移行しました。その結果、エンジニアリングチームは他のチームから独立した形で機能開発とロードマップ策定を進める自律性を獲得し、それによってリリーススケジュールは早まり、創造性が発揮され、新機能が増えました。ケーススタディはこちらをご覧ください。

サブスクリプションボックス界のリーディング企業である Loot Crate は、Container Engine 上で Rails アプリケーションをすばやく本番対応に仕上げ、需要に応じてスケーリングできるようにするとともに、ダウンタイムなしのデプロイを実現するパイプラインを立ち上げました。同社が Jenkins を使って継続的デプロイパイプラインを構築した過程については、こちらの記事をご覧ください。

無料試用今すぐお試しくださいContainer Engine の Slack チャンネルこちら* この投稿は米国時間 7 月 12 日、Container Engine の Group Product Manager である Aparna Sinha によって投稿されたもの（投稿はこちら）の抄訳です。- By Aparna Sinha, Group Product Manager, Container Engine

ソリューションガイド : 本番運用に向けた Container Engine 環境の準備

2017年6月29日木曜日

Google Container EngineGoogle Cloud Platformソリューションガイド

ソリューションガイドこちらのドキュメント* この投稿は米国時間 6 月 8 日、Cloud Solutions Architect である Vic Iglesias によって投稿されたもの（投稿はこちら）の抄訳です。- By Vic Iglesias, Cloud Solutions Architect

ゲスト投稿 : Codefresh と Google Cloud による組み込みレジストリとワンクリックデプロイ

2017年5月2日火曜日

編集部注 : 今回は、Docker ネイティブな継続的インテグレーション / 継続的デリバリ（CI/CD）プラットフォームを提供している Codefresh の投稿をお届けします。Kubernetes、Google Container Registry と統合された Codefresh を使用すれば、クラウドネイティブなアプリケーションのビルド、テスト、Container Engine 上の Kubernetes を含む Google Cloud へのデプロイが簡単になります。Container RegistryGoogle Container Engine

組み込みレジストリのメリット

テストフローに組み込まれているため、イメージの品質管理が向上します。

ビルドアシストイメージ（たとえば、Java や他のコンパイル言語で使われるもの）は、開発スペースにきちんと構造化されています。

Codefresh ではイメージにメタデータ（たとえば、テスト結果、コミット情報、イメージの SHA、ログ、イシュー ID など）を付加できるので、デベロッパー向けのサンドボックス的なレジストリが作れます。

組み込みレジストリはビルドマシンに「近い」ので、ビルドスピードが向上します。

ベータテストへの参加Kubernetes へのワンクリックデプロイKubernetes へのデプロイに関するドキュメント

deploy-to-kubernetes-staging: image: codefreshio/kubernetes-deployer:master tag: latest working-directory: ${{initial-clone}} commands: - /deploy/bin/deploy.sh ./root environment: - ENVIRONMENT=${{ENVIRONMENT}} - KUBERNETES_USER=${{KUBERNETES_USER}} - KUBERNETES_PASSWORD=${{KUBERNETES_PASSWORD}} - KUBERNETES_SERVER=${{KUBERNETES_SERVER}} - DOCKER_IMAGE_TAG=${{CF_REVISION}}Container Engine への移行Codefresh と Docker 用 CI/CDhttps://codefresh.io/組み込みレジストリのベータテスト* この投稿は米国時間 4 月 19 日、Codefresh の CEO and Co-founder である Raziel Tabib によって投稿されたもの（投稿はこちら）の抄訳です。- By Raziel Tabib, CEO and Co-founder, Codefresh

Container Engine で Kubernetes 1.6 が利用可能に

2017年4月18日火曜日

Google Container EngineKubernetes 1.6

サポートされるノード数が 2.5 倍に : 私たちは、お客様が必要とするワークロードがいかに大規模であっても対応できるよう注力しました。Container Engine は、サポートするクラスタサイズがこれまでの最大 2,000 ノードから最大 5,000 ノードに増えながらも、クラスタパフォーマンスに関する厳しい SLO（サービスレベル目標）を一貫して掲げています。私たちには、世界で最も人気の高い部類のアプリ（Pokemon GO など）を Container Engine でホスティングしてきた実績があります。こうしたスケーラビリティの向上により、最大級のワークロードも処理できるようになっています。

フルマネージドノード : Container Engine は、お客様の Kubernetes マスターを常に健全な状態に保っています。お客様の Kubernetes ノードのフルマネージドサービスも新たにオプションとして用意しています。ノードの自動アップグレード機能と自動修復機能をお客様が有効にすると、それぞれクラスタの最新バージョンへのアップデートと、クラスタノードの正常稼働の維持が自動的に行われます。これらの機能の詳細については、こちらの記事をご覧ください。

Container-Optimized OS の正式リリース : Container Engine は、Kubernetes の安全で信頼性の高い運用方法として設計されています。Google Cloud でのコンテナの実行に特化して設計され、ロックダウンされた（各種の制限が課された）OS である Container-Optimized OS を使用することで、安全でパフォーマンスが高く、信頼できるエクスペリエンスを確実に提供し、コンテナワークロードを適切に処理できます。Container-Optimized OS の詳細については、こちらの記事をご覧ください。

Kubernetes と Container Engine でより良いノード管理を

2017年4月13日木曜日

Google Container Engine自動ノード管理ノードの自動アップグレード

gcloud beta container clusters create CLUSTER --zone ZONE --enable-autoupgrade gcloud beta container node-pools create NODEPOOL --cluster CLUSTER --zone ZONE --enable-autoupgradeこちらのドキュメントノードの自動修復

gcloud beta container clusters create CLUSTER --zone ZONE --enable-autorepair gcloud beta container node-pools create NODEPOOL --cluster CLUSTER --zone ZONE --enable-autorepairこちらのドキュメントノードアップグレードの改善podTerminationGracePeriodコードン（cordon）、およびドレインするReplicaSetsDeploymentsアップグレードのキャンセル、再開、ロールバック

アップグレードされていないノードは旧バージョンのままです。

作業中のノードはアップグレード完了まで進みます。

アップグレード済みのノードは新バージョンのままです。

ノードの状態 / アクション	キャンセル	ロールフォワード	ロールバック
アップグレード中	最後まで実行	－	－
アップグレード済み	そのまま	そのまま	ロールバック
アップグレード前	そのまま	アップグレード	そのまま

ぜひお試しを！Google Cloud Platform今すぐ Container Engine をお試しください* この投稿は米国時間 4 月 4 日、Software Engineer である Maisem Ali によって投稿されたもの（投稿はこちら）の抄訳です。- By Maisem Ali, Software Engineer

Orbitera が Google Cloud のマネージド Kubernetes 環境に移行

2017年3月3日金曜日

OrbiteraGoogle Container Engine最も人気Pokemon GoGoogle Compute EngineGoogle App EngineCloud SQLGoogle Cloud PlatformGoogle StackdriverSlack チャンネル。* この投稿は米国時間 2 月 15 日、Google Cloud の Vice President of Engineering である Eyal Manor によって投稿されたもの（投稿はこちら）の抄訳です。- By Eyal Manor, Vice President of Engineering, Google Cloud

Container Engine 最新版 : Kubernetes 1.5、自動ノード管理、ステートフルアプリ、HIPAA に対応

2016年12月22日木曜日

Google Cloud PlatformKubernetes 1.5 リリースGoogle Container Engine

ノードの自動アップグレードと自動修復により、クラスタ管理が容易に

新しい “kubefed” ツールがサポートされ、クラウド間フェデレーションが簡素化

主要なクラスタアドオンの自動スケーリングにより、重要なクラスタサービスのアップタイムが向上

StatefulSets（旧称 : PetSets）がベータ段階に入り、Container Engine でステートフルワークロードが実行可能に

HIPAA 準拠により、HIPAA 規制の対象となるワークロードがコンテナで実行可能に（Google Cloud の標準的な Business Associate Agreement に同意した後）

GroupBy : Container Engine を使用して、新しい電子商取引アプリケーション機能の顧客への継続的デリバリをサポートしています。同社の顧客には、The Container Store や Urban Outfitters、CVS Health といった小売企業が含まれています。

「Google Container Engine は、私たちが Docker コンテナの管理やオーケストレーションを行ううえで必要としているオープン性、安定性、スケーラビリティを提供してくれます。今年、私たちのお客様のところで、ブラックフライデー（米国における感謝祭翌日の金曜日。年末商戦の初日）とサイバーマンデー（感謝祭翌週の月曜日。ネットショッピングが盛況）の間にサービスの停止やダウンタイム、中断はまったく発生しませんでした。Google Container Engine はそれに一役買っています」 - GroupBy の最高技術責任者（CTO）、Will Warren 氏

MightyTV : ビデオリコメンデーションエンジンで使用されるワークロードを Container Engine に移し、従来の仮想マシンでの実行時と比較して 33 % のコストを削減しました。さらに、サードパーティ製の監視およびログサービスを削除できたほか、自身で Kubernetes を管理せずに済むようになりました。

kubernetes-users メーリングリストSlack の kubernetes-users チャンネルこちら* この投稿は米国時間 12 月 19 日、Google Container Engine の Product Manager である David Aronchick によって投稿されたもの（投稿はこちら）の抄訳です。- Posted by David Aronchick, Product Manager, Google Container Engine

Cloud Deployment Manager の基本的な使い方

2016年11月29日火曜日

Google Cloud Deployment ManagerGoogle Compute EngineGoogle Container EngineGoogle BigQueryGoogle Cloud StorageGoogle Cloud SQLGoogle Cloud Platform

YAML で記述された設定ファイル

Jinja 2.7.3 または Python 2.7 に準拠したテンプレートファイル

特定のテンプレートを使用する場合に、設定ファイルが満たしていなければならない一連のルールを定義するスキーマファイル

設定ファイルサポートされるリソースとそのプロパティ$ gcloud deployment-manager types listInfrastructure as Code Deployment Manager の仕組み

net-config.yaml : 設定ファイル

network.jinja : テンプレートファイル

instance.jinja : テンプレートファイル

テンプレートを使う理由

テンプレートで宣言すると、クラウドリソース定義の管理やメンテナンス、再利用が簡単になります。テンプレートを再利用すれば、設定ファイルでリソースを最初から最後まで定義することを繰り返さなくて済みます。これにより、確実に統一された形でリソースを定義できます。

テンプレートの記述言語は Python と Jinja2 から選べます。Jinja2 のほうが Python よりもシンプルですが、そのぶん非力です。Jinja2 は、YAML と同じ構文を使いつつ、条件分岐やループを使用できるようにしたものです。それに対し、Python テンプレートは Jinja2 よりも強力で、テンプレートのコンテンツの生成方法をプログラムのように記述できます。

テンプレート変数を使用すると、テンプレートに渡せる値を設定ファイルで宣言できるので、テンプレートを再利用しやすくなります。テンプレートをいちいち書き直さなくても、設定ファイルごとにパラメータの値を変えられるのです。たとえば、本番インスタンスに対して別々のゾーンのテストインスタンスをデプロイしたい場合は、ゾーン値を表す変数をテンプレートに宣言します。そして、実際のゾーン値は設定ファイルから渡すようにするわけです。

環境変数も、さまざまなプロジェクトやデプロイでテンプレートを再利用するうえで便利です。環境変数は、デプロイしようとしているリソースではなく、プロジェクト ID やデプロイ名といったものを定義します。

Deployment Manager によるサンプルリソースのデプロイネットワークのテンプレートファイル

サブネット名

IP の範囲

web

10.177.0.0/17

data

10.178.128.0/17

インスタンスのテンプレートファイル

設定ファイル

“imports” プロパティ

gcloud コマンドAPI$ gcloud deployment-manager deployments create net --configuration net-config.yaml

$ gcloud deployment-manager deployments delete net

次のステップオンプレミス環境と接続する VPNDeployment Manager サンプル設定私たちにお知らせください

* この投稿は米国時間 11 月 21 日、Solutions Architect である Grace Mollison によって投稿されたもの（投稿はこちら）の抄訳です。

- Posted by Grace Mollison, Solutions Architect