このページは Cloud Translation API によって翻訳されました。

Cloud Shell を使用した開発とCloud Code

1. 概要

Cloud Shell はオンラインの開発および運用環境であり、どこからでもブラウザからアクセスできます。gcloud コマンドラインツールや kubectl などのユーティリティがプリロードされたオンラインターミナルでリソースを管理できます。オンラインの Cloud Shell エディタを使用して、クラウドベースのアプリの開発、ビルド、デバッグ、デプロイを行うこともできます。

このラボでは、Cloud Shell と Cloud Shell エディタを操作し、ローカルエミュレータと実際のサービスで Cloud Code を使用してコンテナベースのアプリケーションを作成、デプロイ、テストします。

学習内容

Cloud Shell の主な機能を操作、理解する
Cloud Shell のさまざまな使用パターンを練習する
高度な使用のために Cloud Shell 環境をカスタマイズする
Cloud Code のオプションと機能を理解する
Cloud Code for Kubernetes アプリケーションの詳細を理解する
Minikube などのローカルエミュレータを使用する

前提条件

編集者権限を持つ GCP プロジェクト、GCP アカウント、Cloud Shell へのアクセス権が必要です。
オプションパーツを使用するには、ターミナルエミュレータと Google Cloud SDK がインストールされている必要があります。

2. 設定と要件

セルフペース型の環境設定

Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。この値はいつでも更新できます。
プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常、それが何であるかは関係ありません。ほとんどの Codelab では、プロジェクト ID を参照する必要があります（通常は PROJECT_ID として識別されます）。生成された ID が気に入らない場合は、別のランダムな ID を生成できます。または、ご自身でお試しになることもできます。このステップを終えた後は変更できず、プロジェクト期間中は維持されます。
なお、3 つ目の値は、一部の API で使用される [プロジェクト番号] です。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。

次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に課金されないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクト全体を削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアルプログラムをご利用いただけます。

3. Cloud Shell ターミナルの操作

このセクションでは、Cloud Shell ターミナルの概要、UI の操作方法、機能の使用方法、さらに生産性を向上させるための構成オプションとさまざまな使用方法について学習します。

Cloud Shell には、Cloud Shell ターミナルと Cloud Shell エディタという 2 つの主要なツールがあります。このラボでは、Cloud Shell ターミナルと Cloud Shell という用語を同じ意味で使用していますが、ターミナルエミュレータと IDE を明確に区別するために、エディタは常に Cloud Shell エディタと呼んでいます。

Cloud Shell は、いつでも利用できる Google Compute Engine Debian ベースの Linux マシン（エフェメラル Google Compute Engine）上に構築された、完全に機能するクラウドベースのシェルです。Google Cloud SDK がインストールされ、git、kubectl、kubectx、curl、python3、tmux などの関連ツールが付属しています...

$HOME ディレクトリは Google Cloud によって Cloud Storage 内に保持され、Cloud Shell マシンを起動するたびに自動的にマウントされます。そのため、Cloud Shell マシンがシャットダウンされても、ディレクトリに残った情報は失われません。つまり、Cloud Shell を再度有効にすると、$HOME ディレクトリとそれに対して行ったカスタマイズがそのまま使用できます。

Cloud Shell の起動

console.cloud.google.com に移動します。GCP Console にまだログインしていない場合は、Google 認証情報を入力します。Google Cloud Platform のコンソールのメイン UI が表示されます。
Cloud コンソールのメニューバーセレクタで、作業対象の GCP プロジェクト ID を選択します。

メニューバーの右側、アカウントのアバターの隣にある Cloud Shell を有効にするボタンを探します。

Cloud Shell アイコンをクリックすると Cloud Shell ターミナルが開き、GCP コンソール UI のすぐ下に新しいペインが表示されます。

このペインには Cloud Shell ターミナルがあります。

Cloud Shell ターミナルに移動し、選択した GCP プロジェクト ID を Cloud Shell が認識するため、再度指定する必要はありません。

echo $GOOGLE_CLOUD_PROJECT

これにより、GCP プロジェクト ID が出力されます。この ID は Cloud Shell プロンプトにも表示されます。

ツールの切り替え

Cloud Shell には、いくつかのツールと構成オプションが用意されています。Cloud Shell のメニューにあるオプションを確認します。

バーのボタンをクリックします。これにより、Cloud Shell ターミナルが最大化され、ブラウザのタブスペースがすべて表示されます。

Cloud Shell はブラウザのタブスペースを最大化して占有します。

もう一度クリックします。ブラウザタブ領域は、Cloud コンソールと Cloud Shell の間で共有されるものに戻ります。

新しいタブを開く

Cloud Shell ターミナルでは、タブを必要な数だけ開くことができます。

次のボタンをクリックして新しいタブを開きます。

タブ名の横にある [x] をクリックするか、対応するシェルで「exit」と入力して新しいタブを閉じます。

新しいウィンドウを開く

新しいブラウザウィンドウで Cloud Shell を開くと、Cloud コンソールと Cloud Shell を別のウィンドウに表示できます。

次のボタンをクリックして、Cloud Shell が新しいブラウザタブでどのように開くかを確認します。

Cloud Shell のツールバーオプションが変わりましたが、外観が少し異なります。

次のセクションでは、この新しいブラウザタブで作業を進めます。

tmux によるセッションの転送

Cloud Shell には tmux が含まれています。tmux は、GNU Screen に似た非常に人気のあるターミナルマルチプレクサです。tmux との統合により、Cloud Shell はどこにいてもセッションを保持できます。

以降のステップでは、この概念を練習して、この機能をより深く理解します。

Cloud Shell ターミナルの移動

開いたばかりの Cloud Shell タブで、top コマンドを入力します。

top コマンドを実行すると、Cloud Shell ターミナルで実行されているプロセスがリアルタイムで表示されます。これを使用して、tmux が提供する Cloud Shell のセッション永続性を可視化します。

ブラウザの最初のタブ（Cloud コンソールが表示されているタブ）に戻ります。
先ほど Cloud Shell を新しいウィンドウで開くように設定したため、「Your session was transferred to another browser tab. You can disable this from the "Tmux Settings" option in the Cloud Shell settings menu.」というメッセージが表示されます。
再接続ボタンをクリックします。

これで、2 番目のタブで実行されていたシェルにアクセスできるようになります。top は、開いた状態のままここで実行を継続します。

Cloud Shell を新しいウィンドウで開いた 2 つ目のタブに移動します。
[再接続] をクリックします。ウィンドウを閉じる前に実行されていたトッププロセスを復元します。

tmux でウィンドウを分割する

tmux は、ここで使っていたものよりもはるかに便利です。tmux のチュートリアルはこのラボの範囲外です。詳細については、公式の tmux スタートガイドをご覧ください。

ただし、tmux を使用すると、Cloud Shell にローカルターミナルエミュレータで可能な追加機能がいくつか提供されます。デモのために、端子を並べて分割します。

Cloud Shell で、Ctrl + b、% キーの順に押します。
tmux で、元のペインのすぐ下に新しいペインが作成されることを確認します。

2 番目のペインをクリックし、「exit」と入力します。

ウェブプレビューを利用する

Cloud Shell では、クラウドで実行されている Cloud Shell マシンから自分のコンピュータで実行されているローカルブラウザを経由し、自動ポート転送を確立することもできます。

Cloud Shell に次のように入力します。

python3 -m http.server 8080

右上にある [ウェブでプレビュー] オプションを選択し、[ポート 8080 でプレビュー] を選択します。

新しいタブが開き、そのポートで提供されるデフォルトのページが表示されます。

ポートを変更して、ポート 8080 だけでなく、アプリケーションが Cloud Shell で公開しているポートでもプレビューできます。

その他の Cloud Shell オプションへのアクセス

Cloud Shell には、追加の設定やオプションが用意されています。

Cloud Shell メニューのその他アイコンをクリックして、オプションにアクセスします。

ここで最も関連性の高いオプションは、Cloud Shell にファイルをアップロードまたはダウンロードし、問題が発生した場合に Cloud Shell マシンを再起動する方法です。

4. Cloud Shell エディタの操作

Cloud Shell の最も重要な機能の一つは Cloud Shell エディタです。これは、オープンソースプロジェクトの Eclipse Theia をベースにした本格的な IDE で、Google をはじめとして貢献しています。外観は VSCode と非常によく似ています。どちらも一般的なオープンソースベースコンポーネント（Monaco エディタ、拡張機能モデル、言語サーバープロトコル、デバッグアダプタプロトコルなど）を使用しているためです。

Theia/Cloud Shell エディタはかなり複雑なツールであるため、Cloud Shell エディタのすべての機能について説明することはこのラボの範囲外です。このセクションでは、この Google Cloud の実装で利用できるいくつかの基本コンセプトと独自の機能について説明します。

Cloud Shell エディタへのアクセス

Cloud Shell エディタには、次の 3 つの方法でアクセスできます。

コマンドラインからアクセスする
Cloud Shell メニューからアクセス
ブラウザで URL にアクセスする

以下の手順でこれらの方法を試します

次のコマンドを使用して、コマンドラインから .bashrc を開きます。

cloudshell edit $HOME/.bashrc

メニューから Cloud Shell を開くには、[エディタを開く] ボタンをクリックします。これにより、Cloud Shell ターミナルを開いたまま、Cloud Shell エディタが開きます。Cloud Shell エディタのみのタブ領域をすべて保持したい場合は、[編集] ボタンの右側にあるボタンをクリックしてターミナルを閉じます。これらの 2 つのボタン（[エディタを開く/閉じる] と [ターミナルを開く/閉じる]）で、ブラウザのタブに表示されるツールを指定します。両方をクリックして、コツをつかみましょう。
「ide.cloud.google.com」と入力して、ブラウザの URL バーから Cloud Shell エディタを呼び出します。

Cloud Shell エディタからコマンドラインを使用する

Cloud Shell ターミナルと Cloud Shell エディタは、同じブラウザタブ内に共存していますが、Cloud Shell ターミナルの使用はやめて、Cloud Shell エディタと Cloud Shell エディタ内から利用可能なターミナルだけを使用することもできます。IDE を使い慣れていて、VSCode のさまざまなショートカットやペインのダイナミクスを知っている方であれば、理解しやすいかもしれません。

前述のいずれかの方法で Cloud Shell エディタを開きます。次に、[エディタ] メニューに移動して、[ターミナル >新しいターミナル] をクリックします（またはキーボードで Ctrl+`` キーを押します）。Cloud Shell エディタの下部に新しいターミナルペインが開き、シェルのすべてのニーズに対応できます。

これにより、Cloud Shell ターミナルのように tmux ペイン管理を使用することなく、さまざまなターミナルペインを管理できるようになります。

Cloud Shell 設定のカスタマイズ

Cloud Shell には、外観やカスタマイズなど、カスタマイズオプションがCloud Shell ターミナルの起動構成と詳細な操作。以降のセクションでは、さまざまなオプションについて詳しく説明します。

Cloud Shell ターミナルのメニューに移動し、歯車アイコンをクリックします。いくつかの構成オプションが表示されます。

そのいくつかを確認してください。

カラーテーマ: ライト、ダーク、または一連のカスタムカラー（フォントの色や背景色など、基本的なもの）を使用できます。
文字サイズ: 5 種類のフォントサイズから選択できます
フォント: Courier new または Monospace
Copy settings: ここで、コピーのキーボードショートカットを変更して、一般的な Linux ターミナルエミュレータで使用されているショートカットに類似させることができます。
キーボード: 一部の OS では、Meta キーを Alt にマッピングし（デフォルトでは Meta は ESC）、Alt Gr キーをマッピングします。

シェル環境を構成する

Debian ベースの Linux マシンでシェルを実行するターミナルエミュレータとして、Linux で行うのと同じ方法でシェル環境をカスタマイズできます。そのため、$HOME に存在する構成ファイル（.bashrc) など）は、新しいログインシェルプロセスが作成されるたびにソース化されます。

Cloud Shell では、Cloud Shell インスタンスが起動されるたびに実行するアクションを、.customize_environment という特別な構成ファイルで指定することもできます。詳しくは、環境のカスタマイズのドキュメントをご覧ください。

Cloud Shell ターミナルにいくつかの構成を追加する演習を行います。Cloud Shell ターミナルに移動し、次のサンプルコードリポジトリのクローンを作成します。

git clone https://gitlab.com/javiercanadillas/cloud-code-getting-started.git

このリポジトリには、Cloud Shell を構成する 2 つの主要イベントのサンプルが含まれています。

Cloud Shell インスタンスが起動されるたびに、$HOME/.customize_environment ファイルが読み取られます。このプロセスの実行ログは /var/log/customize_environment にあります。正常に実行されると /google/devshell/customize_environment_done が作成されます。
新しいシェルプロセスが開始されるたびに（新しいウィンドウ、新しいタブなど）、通常の bash シェル構成ファイルが読み取られます。

次の手順で両方を練習します。

次のコマンドを実行して、リポジトリで提供されるカスタマイズを起動します。

cd cloud-code-getting-started
source set_env_cust.sh

これにより、前述の両方のカスタマイズオプションが設定され、有効になります。

新しいシェルプロンプトが表示されます。.bash_profile ファイルをソースとする bash スクリプトは、デフォルトのプロンプトよりも短いこの新しいプロンプトを構成し、チェックアウトしたブランチや Git ステータスなどの基本的な Git 情報が含まれています。
cloudshell edit コマンドに新しい code エイリアスが追加され、より短くなりました。これを使用して、.bash_profile ファイルの内容を確認します。

code $HOME/.bash_profile

新しくインストールされたコマンド bat を使用して、.customize_environment ファイルの内容を確認します。

bat $HOME/.customize_environment

bat は、広く利用されている Unix ツール cat の拡張バージョンです。bat の出力に、新しい Cloud Shell マシンが起動されるたびに負荷テストツールである hey を再インストールするための apt install コマンドが示されています。

Cloud Shell メニュー（右上のその他アイコン）をクリックして [再起動] を選択し、すべてが機能していることを確認します。

これにより、Cloud Shell のタイムアウトとインスタンスの再作成をシミュレートでき、すべてが正しく構成されていることを確認できます。

Cloud Shell コンテナイメージのカスタマイズ

このカスタマイズオプションを使用すると、追加のパッケージとカスタム構成を使用して、カスタム Cloud Shell 環境として機能する Docker イメージを作成できます。生成されたイメージは、完全にエフェメラルな Cloud Shell インスタンスをスピンアップするため、Cloud Shell VM もそれに接続される $HOME ディレクトリも保持されません。ただし、関数固有の Cloud Shell インスタンスをサードパーティに配信して特定のタスクを最も効率的に実行できるようにするユースケースでは、このイメージの作成が有用です。

前のセクションのように環境をカスタマイズする代わりに、Cloud Shell のスピンアップに使用する新しいイメージで変更をベイクします。これには、カスタム Cloud Shell の起動が速くなるという明白な利点があります。

新しい Cloud Shell イメージの作成

Cloud Shell ターミナルで次のように入力して、Cloud Shell コンテナイメージの作成を開始します。

cloudshell env create-custom-image custom-cloud-shell
cd custom-cloud-shell

これにより、Cloud Shell に新しいディレクトリが作成され、コードをホストするための同じ名前の新しい Cloud Source Repositories リポジトリが作成されます。また、$HOME/custom-cloud-shell/ directory にサンプル Dockerfile のクローンを作成します。

Dockerfile の最後の行に RUN apt install -y hey という行を追加します。

echo "RUN apt install -y hey" >> $HOME/custom-cloud-shell/Dockerfile

これにより、.customize_environment と同じカスタマイズが設定されますが、代わりにコンテナに記述されています。

イメージをローカルでビルドします。

cloudshell env build-local

次のコマンドを実行して、新しいイメージをテストします。

cloudshell env run

イメージ内でシェルになります。

次のコマンドを実行して、hey コマンドがインストールされていることを確認します。

hey

完了したら、「exit」と入力してコンテナを終了します。

exit

変更を Cloud Source Repositories のリポジトリに push し、イメージを Container Registry に push します。

git commit -a -m "Initial commit"
git push origin master
cloudshell env push

新しいイメージをテストする

画像を公開して利用できるようにします。

gsutil iam ch allUsers:objectViewer $(gsutil ls)

公開されている Cloud Shell カスタムインスタンスのテストに使用できる URL を生成します。

echo "https://ssh.cloud.google.com/cloudshell/editor?cloudshell_image=gcr.io/$GOOGLE_CLOUD_PROJECT/custom-cloud-shell"

出力 URL をコピーして新しいブラウザタブに貼り付けると、Cloud Shell カスタムインスタンスが開きます。インスタンスにアクセスすると、フルエフェメラルモードで実行していることを示すバナーが表示されます。

hey コマンドを実行してイメージを再度テストします。

hey

完了したら、エフェメラル Cloud Shell インスタンスを exit して、通常の Cloud Shell を開いているタブに戻り、[再接続] をクリックします。

SSH を使用した Cloud Shell へのリモートアクセス

また、Cloud Shell の機能をローカルコンピュータからリモートで使用することもできます。これには通常、次の 2 つの異なるユースケースが含まれます。

ローカルターミナルから Cloud Shell マシンに SSH 接続する
Cloud Shell のリモート $HOME ディレクトリをローカルでマウントする。

そのためには、Google Cloud SDK をローカルにインストールする必要があります。また、プロジェクト ID と使用する特定の認証情報を使用して構成する必要もあります。

ローカルマシンで実行されているターミナルエミュレータから、次の手順を行います。

GCP プロジェクト ID を設定し、Cloud Shell を使っている Cloud 組織に対応する認証情報でログインします。

gcloud config set project <your project id>
gcloud auth login

リモートの Cloud Shell マシンに SSH 接続します。

gcloud cloud-shell ssh --authorize-session

これで Cloud Shell が起動しますが、ローカルの Terminal エミュレータの機能と構成を使用します。使用しているアプリが tmux をサポートしている場合は、さらに統合を行うことでリモートエクスペリエンスを改善できます。

ローカルマシンから Cloud Shell ホームディレクトリをマウントする

リモートの Cloud Shell インスタンスに SSH 接続できることは便利ですが、ローカル IDE からリモートの Cloud Shell $HOME ディレクトリにアクセスできるようにできるとさらに便利です。これにより、先ほど説明した SSH アクセスと、リモートコードをローカルで編集する機能を組み合わせることができます。

これを行うには、まずローカルマシンからマウントポイントを作成します。

mkdir $HOME/cloudshell

これは Cloud Shell がマウントされるディレクトリです。次に、マウントするために、Cloud Shell インスタンスが起動していることを確認してから、ローカルターミナルに次のように入力します。

$(gcloud cloud-shell get-mount-command $HOME/cloudshell)
cd $HOME/cloudshell

これにより、Cloud Shell をローカルにマウントしてマウントするために発行する必要がある mount コマンドを取得できます。Cloud Shell ホームディレクトリの内容がローカルマシンにマウントされます。

これで、VSCode などの IDE をローカルで開いて、クラウドのリモートのワークスペースを開くことができます。同時に、Cloud Shell への SSH アクセスを使用して IDE 内の [ターミナル] ペインを開き、ローカル IDE にリモートターミナルを統合することもできます。

5. Cloud Code の使用

Cloud Code は Google が開発したプラグインで、デベロッパーはクラウドベースのツールでより効率的に作業できます。VSCode や JetBrains プロダクトなどの複数の IDE とコードエディタで使用でき、利便性のため Cloud Shell エディタにデフォルトで統合されています。Cloud Code には、次のステップで実践できるデベロッパー向けの機能がたくさん用意されています。

Cloud Shell エディタで Cloud Code を探す

クイックアクセスボタンの使用

エディタの左側のペインに次の 4 つのボタンが表示されています。

これらのメニュー項目を使用すると、Cloud Shell エディタから直接 GCP サービスにアクセスして構成できます。

このラボでは、Kubernetes クラスタに焦点を当てます。

ステータスバーの使用

Cloud Shell エディタ UI を介して公開される Cloud Cloud には、さらに 2 つの関連する部分があります。どちらもエディタの下のバーに表示されます。

<>Cloud Code: ここをクリックすると、このチュートリアルで使用するクイックアクションメニューが表示されます。
minikube の制御: クラスタの起動や停止などの基本的なアクションで、ローカルの Kubernetes エミュレータである minikube を制御できます。

Minikube インスタンスの作成

ボタンをクリックして Minikube インスタンスを作成します。

Cloud Code を使用して GKE クラスタを作成する

左側のアイコン Cloud Code - Kubernetes Clusters（）をクリックします。[Cloud Code - KUBERNETES: クラスタ] という新しいペインが左側に表示されます。
[Cloud Code - KUBERNETES: CLUSTERS] の横にある [+] ボタンをクリックし、[Google Kubernetes Engine] を選択します（前に起動した Minikube などの他のオプションを選択することもできます）。

[Create a New GKE Cluster] をクリックします。このオプションを使用すると、右側に新しいペインが読み込まれ、開発クラスタをすばやく作成するための追加情報を入力できます。パネルの指示に沿って、次の情報を入力します。

Autopilot を選択する
リージョン（europe-west-1）を選択する
クラスタに「dev」という名前を付けます。

[クラスタを作成] ボタンをクリックします。これにより、新しい Autopilot クラスタが作成されます。

クラスタ作成プロセスは最長 55 分かかります。クラスタの作成中は、Cloud Code の Kubernetes ペインをもう少し詳しく見てみましょう。

Cloud Code の Kubernetes ペインの探索

先ほど Minikube クラスタを作成しました。準備が整うと、このクラスタが Cloud Code Kubernetes ペインに、指定した名前（minikube）で表示されます。

クラスタは UI に「ACTIVE」と表示されます。この設定は、コマンドラインの現在の Kubernetes コンテキストと同期されます。.

Cloud Code の [Kubernetes] ペインには、次の情報が表示されます。

デフォルトの KubeConfig ファイル: Cloud Code は ~/.kube/config ファイルを読み取り、そのファイルを使用してそこで構成された Kubernetes クラスタに接続し、簡単に操作できるようにします。Kubeconfig ファイルを編集するには、Default Kubeconfig 行にカーソルを合わせ、横に矢印が付いている四角形をクリックします。
登録済みクラスタのさまざまなオブジェクトのブラウズ可能なレンダリング: この例では、前に作成した minikube Minikube クラスタが、そのコンテキスト、Namespace、ノードとともに表示されます。ツリーのノードをいくつか展開してみましょう。アプリケーションをデプロイしていないため、まだ Pod は存在しません。

新しい GKE クラスタが起動して実行されると、左側のペインに minikube Minikube クラスタとともに表示されます。任意のクラスタを右クリックして「アクティブ」にすることができます。実行する Cloud Code アクションのクラスタを選択するという意味です。

6. 完了

お疲れさまでした。これでこの Codelab は終了です。

学習した内容

Cloud Shell の主な機能について説明し、理解しました。
さまざまな Cloud Shell 使用パターンで演習
高度な使用のために Cloud Shell 環境をカスタマイズ
Cloud Code のオプションと機能について理解する
Cloud Code for Kubernetes アプリケーションの詳細を確認しました
Minikube などのローカルエミュレータを使用する