インスタンスでのその他のタスクの実行

以下は、インスタンスを使用して実行する可能性のあるその他のタスクです。

始める前に

インスタンスとローカルのパソコン間でのファイルのコピー

gcloud compute scp を使用して、Linux インスタンスとローカルのパソコンの間でファイルを転送します。

gcloud compute scp my-instance:~/file-1 \
    my-instance:~/file-2 \
    ~/local-dir

ローカルマシンからインスタンスにファイルをコピーするには:

gcloud compute scp ~/local-dir/file-1 \
    my-instance:~/remote-destination

Compute Engine で実行されているかどうかの検出

システムが特定のクラウド環境内で動作しているかどうかを検出することは、システムで行われる通常の作業です。次の手順を実行すると、Compute Engine で実行されているかどうかを検出できます。

メタデータ サーバーの使用

メタデータ サーバーを使用して、アプリケーションやスクリプトが Compute Engine インスタンス内で実行されているかどうかを簡単に検出できます。サーバーにリクエストを行うときに、メタデータ サーバーからの応答には、Metadata-Flavor: Google ヘッダーが含まれます。このヘッダーを確認して、Compute Engine で実行されているかどうかを確実に検出できます。

たとえば、次の curl リクエストは Metadata-Flavor: Google ヘッダーを返し、リクエストが Compute Engine インスタンス内から行われていることを示します。


me@my-inst:~$ curl metadata.google.internal -i


HTTP/1.1 200 OK
Metadata-Flavor: Google
Content-Type: application/text
Date: Thu, 10 Apr 2014 19:24:27 GMT
Server: Metadata Server for VM
Content-Length: 22
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

0.1/

computeMetadata/

その他のメソッドの使用

Linux

Linux インスタンスの場合、dmidecode ツールを使用して /proc/mem の DMI/SMBIOS 情報に直接アクセスできます。次のコマンドを実行すると、dmidecode ツールから「Google Compute Engine」が出力され、アプリケーションやスクリプトが Google Compute Engine で実行されていることがわかります。

my@myinst:~$ sudo dmidecode -s system-product-name | grep "Google Compute Engine"
Google Compute Engine

Windows

Windows インスタンスでは、「Google」がシステムのメーカーとモデルとしてリストされます。msinfo32.exe などのユーティリティを使用して、この情報を検索できます。たとえば、msinfo32 は次の情報を表示します。

Google をメーカーとモデルとして表示する msinfo32 の画面(クリックして拡大)
Google をメーカーとモデルとして表示する msinfo32 の画面(クリックして拡大)

Windows インスタンスでプログラムによってこの情報を確認する場合は、Windows Management Instrumentation(WMI)アプリケーションを作成してそれに一部修正を加えます。

インスタンスのエラーの処理方法

残念ながら、個々のインスタンスに障害が発生することがあります。予想外の停止やハードウェアのエラー、その他のシステム障害など、さまざまな原因が考えられます。そうした状況を緩和するために、永続ディスクを使用して、データを定期的にバックアップする必要があります。

インスタンスに障害が発生した場合は、障害が発生したときと同じルート永続ディスク、メタデータ、インスタンスの設定を使用して自動的に再起動されます。インスタンスの自動再起動の動作を管理するには、スケジュール設定オプションの設定方法をご覧ください。

一般的に、1 つのインスタンスの障害でアプリケーションに壊滅的な影響が及ばないように、システムを十分堅牢に設計する必要があります。詳細については、堅牢なシステムの設計をご覧ください。

UUID によるインスタンスの特定

仮想マシンはそれぞれ、Linux イメージの dmidecode ツールからアクセスできる Universally Unique Identifier(UUID)を持っています。UUID は、仮想マシンのプロジェクト ID、ゾーン、インスタンス名から計算されます。インスタンスの UUID は、Compute Engine の仮想マシンごとに固有であり、インスタンスの存続期間中は一定です。UUID は、仮想マシンの再起動まで保持され、同じインスタンス名を持つ仮想マシンが同じプロジェクトとゾーンで削除されて再作成されると、UUID も同様に処理されます。

Linux インスタンスで UUID を探すには、仮想マシンから次のコマンドを実行します。

me@myinst:~$ sudo dmidecode -t system | grep UUID

ツールで、次のような応答が出力されます。

  UUID: FE0C672D-324F-25F1-052C-6C50FA8B7397

パッケージのインストールとインスタンスの設定

インスタンスの作成者は、プロジェクトに追加するインスタンスに対する管理者権限を持ち、SUDO リストに自動的に追加されます。

インスタンスに管理者としてログインしている場合は、通常の Linux コンピュータと同じ方法で、パッケージをインストールしてインスタンスを設定できます。たとえば、次に示すように、Apache をインストールできます。


user@myinst:~$ sudo apt-get update && sudo apt-get install apache2
Reading package lists... Done

Building dependency tree
Reading state information... Done
The following extra packages will be installed:

[...]

インスタンスとローカルのパソコン間でのファイルのコピーで説明しているように、gcloud compute scp を使用してローカルのパソコンとインスタンスの間でファイルを移動できます。

注意すべき点として、apt-get を実行するには、マシンがインターネットにアクセスできなければなりません。つまり、外部 IP アドレス、またはインターネット プロキシへのアクセスのどちらかが必要です。

Compute Engine は、保留中のインフラストラクチャのメンテナンス イベントの一部として、仮想マシンのライブ マイグレーションや終了と再起動を試行する直前に、仮想マシンのメタデータ サーバーの特殊な属性を変更します。maintenance-event 属性は、イベントの前後に更新され、これらのイベントが差し迫っているときに検知できます。この情報を利用して、メンテナンス イベントの前後に実行したいスクリプトやコマンドを自動化できます。

詳細については、メタデータ サーバーのドキュメント ページで透過的メンテナンスの通知のセクションをご覧ください。

すべてのインスタンスのリスト

instances list を呼び出すことで、プロジェクトのすべてのインスタンスのリストを表示できます。

gcloud compute instances list
NAME               ZONE          MACHINE_TYPE  INTERNAL_IP    EXTERNAL_IP     STATUS
example-instance   us-central1-a n1-standard-1 10.105.155.92  173.255.114.53  RUNNING
example-instance-2 us-central1-a n1-standard-1 10.181.215.203 146.148.32.59   RUNNING

デフォルトでは、gcloud compute は利用可能なすべてのゾーンですべてのリソースの集約リストを提供します。1 つのゾーンのみのリソースのリストが必要な場合は、リクエストで --zones フラグを指定します。

API では、集約リソースのリスト、またはゾーン内のリソースのリストを取得するために、2 つの別個のメソッドへのリクエストを行う必要があります。集約リストに関するリクエストを行うには、リソースの aggregatedList URI に対して GET リクエストを行い、プロジェクトを独自のプロジェクト ID で置き換えます。

https://www.googleapis.com/compute/v1/projects/myproject/aggregated/instances

クライアント ライブラリでは、instances().aggregatedList 関数に対するリクエストを行います。

def listAllInstances(auth_http, gce_service):
  request = gce_service.instances().aggregatedList(project=PROJECT_ID)
  response = request.execute(auth_http)

  print response

ゾーン内のインスタンスのリストに関するリクエストを行うには、以下の URL に GET リクエストを行い、プロジェクトを独自のプロジェクト ID に置き換え、ゾーンをインスタンスのゾーンに置き換えます。

https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-f/instances

API クライアント ライブラリで、instances().list リクエストを行います。

def listInstances(auth_http, gce_service):
  request = gce_service.instances().list(project="myproject",
    zone="us-central1-f")
  response = request.execute(auth_http)

  print response

プリエンプティブ インスタンスを使用したコスト削減

Google Compute Engine は、通常のインスタンスよりはるかに低コストで作成および実行できるプリエンプティブ インスタンスを提供しています。アプリケーションがフォールト トレラントであり、インスタンスの不安定さに耐えることができる場合、プリエンプティブ インスタンスによって Compute Engine のコストを大幅に削減できます。詳細については、プリエンプティブ インスタンスのドキュメントをご覧ください。

インスタンスへのネットワーク タイム プロトコル(NTP)の設定

イベントの注意深いシーケンシングに依存する多くのソフトウェア システムでは、安定していて一貫性のあるシステム クロックが利用されます。ほとんどのサービスによって書き込まれるシステムログには、タイムスタンプが含まれます。これは、システムのさまざまなコンポーネントの間で発生する問題のデバッグに役立ちます。システム クロックとの同期を維持するために、Compute Engine のインスタンスは、ネットワーク タイム プロトコル(NTP)を使用するよう事前に設定されます。

サーバーの時間と同期するだけでなく、NTP は、まれな事例である、うるう秒でも役立ちます。うるう秒では、地球の回転の変化に合わせるために、UTC 時間を 1 秒調整します。地球の回転速度は気候や地質学的な出来事に応じて不定期に変化するため、うるう秒は定期的な間隔で起こるわけではありません。これまでのうるう秒では、ウェブ上のさまざまなサービスやアプリケーションに大きな影響が生じてきました。NTP サーバーにより、うるう秒の間でも、すべてのサーバーが同じ時刻を報告するようになります。

このセクションでは、うるう秒の場合でも適切に動作するように、仮想マシンで NTP サーバーを構成する方法について説明します。

Google NTP サーバーと leap smear

Unix 時間のうるう秒は、一般的に 1 日の最後の秒を繰り返すことで実装されます。これは、タイムスタンプの増加のみを想定しているソフトウェアで問題が発生する可能性があります。この問題を回避するために、Google のタイムサーバーは、20 時間(つまり、うるう秒イベントの前後 10 時間)をかけて、追加の 1 秒を「不鮮明」にします。これによりコンピュータは、追加の 1 秒を、繰り返されるタイムスタンプのように一度に認識しなくなります。この方法によって、一貫性のあるタイムスタンプに依存するシステムでのリスクが減少します。すべての Compute Engine の仮想マシンのインスタンスで、Google NTP 内部サービスを使用するように設定することをおすすめします。

インスタンスの NTP の構成

Google では、pool.ntp.org など、外部の NTP サービスがどのようにうるう秒を処理するか予測できません。可能な限り、Compute Engine の仮想マシンでは外部の NTP ソースを使用しないことをお勧めします。さらに、Google の NTP サービスと外部サービスの両方を使用すると、システム時間に予測できない変更が発生する可能性があります。外部の NTP ソースを 1 つだけ使用する方が、混在して使用するよりは望ましいですが、pool.ntp.org などの外部 NTP サービスは、うるう秒の処理にステッピングを使用する傾向があります。その結果、仮想マシンがタイムスタンプの繰り返しを認識する可能性があります。

最も安全なアプローチは、Compute Engine の仮想マシンが NTP サーバーを 1 つだけ使用するようにし、そのサーバーを、Google が提供する内部 NTP サーバーにするよう設定することです。外部 NTP サーバーと Google NTP サーバーを組み合わせて使用すると、予期しない動作が発生する可能性があるため、一緒に使用することはしないでください。

仮想マシンが適切に構成されていることを確認するには、次の手順を実行します。

Linux

  1. ssh を使用して、インスタンスに接続します。

    Console

    1. GCP Console の [VM インスタンス] ページに移動します。
    2. 設定するインスタンスの横にある [ssh] ボタンをクリックします。

      [SSH] ボタンのスクリーンショット

    gcloud

    gcloud コマンドライン ツールで、以下を実行します。

    gcloud compute instances ssh INSTANCE
    

  2. インスタンスで ntpq -p を実行して、NTP の構成の現在の状態を確認します。

    $ ntpq -p
    
    
         remote           refid      st t when poll reach   delay   offset  jitter
    
    ==============================================================================
    *metadata.google 255.28.23.83     2 u   27   64    1    0.634   -2.537   2.285
    *217.162.232.173 130.149.17.8     2 u  191 1024  176   79.245    3.589  27.454
    

    1 つのレコードが metadata.google または metadata.google.internal を指している場合、変更する必要はありません。複数のソースが表示されている場合は、metadata.google と公開されているソース(pool.ntp.org など)が一緒に使用されているため、ソースを更新して外部の NTP サービスを削除する必要があります。

    この例では、2 つのレコードがあり、1 つは metadata.google を指し、もう 1 つは外部アドレスを指しています。複数のソースがあるため、*217.162.232.173 アドレスを削除して NTP サーバーを更新する必要があります。

    1. 外部ソースを削除して NTP サーバーを構成します。

      NTP サーバーを構成するには、任意のテキスト エディタで /etc/ntp.conf ファイルを編集します。構成の servers セクションを探して、Google 以外の NTP ソースをすべて削除します。

    $ vim /etc/ntp.conf
    
    ...
    # You do need to talk to an NTP server or two (or three).
    #server ntp.your-provider.example
    ...
    server metadata.google.internal iburst
    

    /etc/ntp.conf ファイルを編集し終わったら、NTP サービスを再起動します。再起動のためのコマンドは、Linux のディストリビューションによって異なる可能性があります。

    $ sudo service ntp reload
    1. 設定を確認します。ntpq -p コマンドをもう一度実行して、変更内容を確認します。
    $ ntpq -p
    
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *metadata.google 255.28.23.83     2 u   27   64    1    0.634   -2.537   2.285
    

Windows

  1. GCP Console の [VM インスタンス] ページに移動します。
  2. ログインする Windows インスタンスの横にある [RDP] ボタンをクリックします。

    [SSH] ボタンのスクリーンショット

  3. ログインしたら、[Powershell] アイコンを右クリックして、[管理者として実行] をクリックします。

    [Powershell] アイコンのスクリーンショット

  4. コマンド プロンプトが読み込まれたら、次のコマンドを実行して、現在の NTP 構成を確認します。

    PS C:\Windows\system32>w32tm /query /configuration
    [Configuration]
    ...
    Type: NTP (Local)
    NtpServer: metadata.google.internal,
    ...
    

    1 つのレコードが metadata.google または metadata.google.internal を指している場合、変更する必要はありません。複数のソース(metadata.google と公開されているソースが一緒に使用されている)が表示されている場合は、外部サーバーを削除する必要があります。NTP サーバーの設定については、Windows のガイドに従ってください。

Google の NTP サーバーの leap smearing 機能は、時間に影響を受けやすいシステムで 1 秒を繰り返すことに関するリスクを管理できる、便利な方法です。NTP サービスの中には、ほとんどのソフトウェア システムで受け入れることができる回避策を提供しているものがあります。Google の leap smearing NTP サービスと、公開されている NTP ステッピング サービスを一緒に使用しないでください。

Google のクラウド外のデバイスを「不鮮明にされた(smeared)」時間に同期させるには、Google Public NTP を使用します。このプロトコルは、Compute Engine 仮想マシン インスタンスに提供されたのと同じ不鮮明化を使用します。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Compute Engine ドキュメント