Google Cloudアカウントの購入：GCP Artifact RegistryとGKEを基盤としたDockerデプロイメントの構築例

クラウド 2026-05-30 阅读 14

クラウドネイティブを扱い、Kubernetesをいじったことがある方なら、多くが「コンテナイメージの配布」や「クラスターへのデプロイ」に苛まれる苦労を味わっていることでしょう。

従来の自前構築のプロセスは、一般的に次のような流れです。ローカルでコードを記述し、Dockerイメージとしてビルドした後、オープンソースのプライベートレジストリであるHarborまたはDocker Hubへプッシュします。続いて、K8sノード用のストリーム取得用認証情報（シークレット）を自ら管理する必要があります。認証情報が期限切れになると、GKE（Google Kubernetes Engine）クラスタで大量のエラーが発生します。

イメージプルバックオフ

（イメージのプルに失敗）という心霊的なエラー。さらに、ミラーリングレジストリとコンピューティングクラスタが異なるデータセンターに配置されているため、数GB級の大型イメージを地域間でプルする際には、莫大なインターネット回線料金に加え、イライラするほど遅いプルのレイテンシが発生します。

Google Cloud（GCP、グーグルクラウド）の最新のエコシステムにおいては、まさに教科書に載るような企業向けの黄金コンビが存在します。

Artifact Registryを活用してコンテナ資産を管理し、GKEと連携して完全自動のコンテナオーケストレーションおよびスケジューリングを実現します。

両者の無敵さの根源は

基盤レベルの権限が自然に統合されている（IAMに基づく）

。面倒なKubernetes Secretの設定を一切必要とせず、GKEノードは高いセキュリティが確保された内部ネットワーク帯域幅で、数秒単位でイメージをプルし、ローリングアップデートを完了できます。

今日は難しい分散システムの理論には触れず、あらゆる公式用語の専門用語も一切排除します。直接ゼロから始めて、手でWebアプリケーションを梱包して、大手工場の生産基準でGKE生産クラスタに安定して配置します。

第一段階：深層的な分解――クラウドネイティブなデリバリーのための「三次元立体的世界モデル」

コマンドを実際に打ち込む前に、コードが公開用のインターネット環境にデプロイされるまでの全ライフサイクルを、頭の中でしっかりと整理しておかなければなりません。企業向けの包括的なCI/CDパイプラインは、以下の三つの中核的構成要素によって堅固に構築されています。

コンテナ埠頭: GCP次世代の専用製品ライブラリ (古いGCRに全面的に取って代わる)。パッケージ化されたDockerミラーバージョンを保管し、googleの大手メーカーレベルの脆弱性スキャン機能を持っています。

計算エンジン (GKEクラスタ): グーグルがホストするK8sサービス。基礎的なMasterノードを管理する必要はなく、宣言的なYAMLファイルで「コピーのWebコンテナを3つ走る」と伝えるだけでバックグラウンドで自動的に安定させます。

セキュリティゲート (IAMロール): これは鍵なしの貫通の鍵です。私たちはGKEのノードに特定のアイデンティティ (Service Account) をつけて、生まれつきArtifactレジストリミラーを読む特権を持っている。

第二段階：環境の準備――GCP上にインフラストラクチャーの領域を構築する

ローカル環境に既にインストールおよび設定されていることを確認してください

よかったです

gcloud

CLI (googleクラウドコマンドラインツール) とDockerエンジン。

1.コアAPIを活性化する (荒涼とした第一歩)

ターミナルで次のコマンドを入力し、使用するGoogle Cloudの基盤エンジンをすべて有効化します。

バッシュ

gcloud services enable container.googleapis.com artifactregistry.googleapis.com

2. プライベートイメージレジストリの作成（Artifact Registry）

私たちは中国台湾地域で

アジア東1

、国内アクセスの遅延が極めて低い）Docker専用のレポジトリを構築し、プロジェクトIDは仮にとします

マイ-GKEプロジェクト

バッシュ

gcloud artifacts repositories create gke-repo \

--リポジトリ形式=docker

--ロケーション=asia-east1

--Description = "GKEプロダクションイメージリポジトリ"

3. マネージド型GKEクラスター（Autopilotモード）の作成

中小企業やK8sの複雑な調整に苦しめられたくないチームには

自動運転モードを選択することを強くお勧めします

。ノードのCPUとメモリの割り当てを管理する必要はありません。グーグルはあなたのPodの宣言に基づいて完全に柔軟に伸縮し、あなたが実行しているPodだけが実際にお金を消費します。

バッシュ

Gcloud containerクラスターズcreate-auto prod-gke-cluster \

--ロケーション=asia-east1

(クラスターを作るのに約3〜5分かかりますが、コーヒーを飲んで辛抱強く待ってください。)

第三段階: 実戦演習一 -- ローカルコードの「コンテナ化」とプッシュアップ

ローカルに非常に簡単なWebアプリケーション (Node.jsでもPythonでも) があると仮定して、ローカルで傍受します

八千八十

ポート。

1.ハードコア生産級Dockerfileの作成

「プロジェクトルート」で、新規作成します

Dockerfile

# 公式軽量ベースミラーを使用

FROM alpine:3.18

# 実行時依存をインストールする (Pythonの例)

RUN apk add --no-cache python3 py3-pip

WORKDIR /app

PY . /app

# ビジネスポートを暴露する

8080を公開する

# Webサービスを開始する

CMD ["python3", "-m", "http.server", "8080"]

2.結合暗号: ローカルDockerとGCPの認証を構成する

多くの人がここでプッシュするとエラーになります。DockerはデフォルトでGCPの倉庫を知らないからです。私たちは

gcloud

セキュリティ証明書をローカルのDocker構成ファイルに直接注入します

バッシュ

gcloud auth configure-docker asia-east1-docker.pkg.dev

3. コンパイルし、タグを付けて強力にストリーミング配信する

Artifactレジストリの標準仕様に基づいて、ミラーにクラウドパスを持つ仕様名を付け、次のようにプッシュします

バッシュ

# コンパイルしてv1.0バージョンにパッケージ化する

Dockerビルド-t asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app: v1.0.

# 全力でクラウドをプッシュ

Docker push asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:v1.0

プログレスバーが終わった後、GCPコンソールのArtifactレジストリページに入ると、ミラーが安定してクラウドに横たわっていて、グーグルはバックグラウンドで自動的にosの脆弱性をスキャンしていることがわかります。

第4段階：実戦演習2―宣言型YAMLによるGKEクラスターのデプロイ

鏡像がクラウドになったので、GKEがそれを実際にサービスを提供できる容器(Pod) にするにはどうすればいいですか?K8sの世界では、私たちは電源を入れないで、私たちは書いています

YAMLのプロファイル

。

確立したばかりのGKEクラスタにローカルで接続し、認証証明書を取得します

バッシュ

Gcloud containerクルスターズget-credentials prod-gke-cluster ---location = asia-east1

ローカルに新しい名前を作ります。

Deployment.yaml

の書類は、以下の大手工場の多国籍構造規範に合致する宣言式コードを貼り付ける

ヤムル

ApiVersion: apps/v1

種類: デプロイメント

メタデータ:

名前：webアプリケーションデプロイメント

ラベル:

App: web-se

サービス

仕様:

レプリカ数: 3 # 高可用性の冗長化を固定化：常時3つのコンテナレプリカを保持し、1つが障害になった場合は自動で新しいレプリカを起動します

セレクター:

マッチラベル:

アプリケーション: ウェブサービス

テンプレート:

メタデータ:

ラベル:

アプリケーション: ウェブサービス

仕様:

コンテナ:

-名前: webコンテナ

# 先ほどArtifact Registryにプッシュしたイメージのパスを正確に指定します

イメージ：asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:v1.0

スポーツ:

-コンテナポート: 8080

リソース: # リソースの仕様を厳しく制限し、悪質なコードによってクラスタのリソースが使い尽くされるのを防ぐ

制限:

CPU: 「500m」

メモリ: "512Mi"

リクエスト:

CPU: 「200m」

メモリ: "256Mi"

---

APIバージョン: v1

種類: サービス

メタデータ:

名前：web-app-lb-service

仕様:

タイプ: LoadBalancer # GKEがGoogleのネットワーク基盤層に対して、高防御機能を備えたグローバルなパブリック負荷分散IPを自動で申請するようにします

セレクター:

アプリケーション: ウェブサービス

スポーツ:

-プロトコル：TCP

ポート: 80 # フロントエンドのパブリックネットワークへの入口となるポート

targetPort: 8080 # コンテナ内部の実際のポートに対応します

ターミナルでワンクリックデプロイコマンドを実行し、この設計図をGKEに投入します。

バッシュ

kubectl apply -f deployment.yaml

第5段階：奇跡を目の当たりにする瞬間――本番環境での検証と障害シミュレーション

デプロイが完了した後、私たちはKubernetesの「天眼コマンド」を用いてインフラの立ち上がりを監視します。

バッシュ

kubectl get p

オーディーエス

画面に緑色のマークが3つ点灯するのをご覧いただけます

ランニング

ステータスのPod。

ここがポイントです：このプロセスにおいて、私たちは一切のイメージプルシークレットを設定していません。それでも、GKEはネイティブなIAMの権限に基づき、Artifact Registry内のプライベート・イメージを安全に取得しています！

続いて、Googleが割り当てたパブリックIPの負荷分散用外部ゲートウェイを確認します。

バッシュ

Kubectl get service web-app-lb-service

あなたは見るでしょう

外部IP

欄に、金のように貴重なパブリックの静的IPアドレスが表示されました（例えば

34.120.x.x

）ブラウザーにこのIPアドレスを入力すれば、ページは瞬時に表示されます。あなたのクラウドネイティブなWebサービスが、いよいよパブリックネットワークでその名をとどろかせます！

生産環境を模擬する「肉体溶断演習」

GKEの自己修復機能を検証するため、あえてバックグラウンドで障害を発生させました。実行中のコンテナ（ポッド）を手動で削除する:

バッシュ

kubectl delete pod web-app-deployment-xxxxxx-xxxxx

削除した瞬間、再びページやサイトを更新します

まったくの遅延や途切れがありません

（残りの2つのレプリカがトラフィックを引き受けているため）。さらに驚くべきことに

Kubectl get pods

そのとき、わずか数秒で新しいPodが自動的に起動し、正常状態になっていることに気づくでしょう。これがGKEが宣言的なコピーセットを自動的に維持するエースの威力である。

第六段階: 多国籍雲原生業務のピット血涙史

このソリューションがきちんと動作すれば、あなたはクラウドネイティブの最も高いハードルをすでに越えたことになります。しかし、本当の企業レベルの高合併環境で生きていくには、設計者として、すぐに配置を二次的に強化して、次の二つの見えない穴を防ぐ必要があります

1.絶対に使用しない

最新の

タグ（リリース管理の諸悪の根源）

多くのチームが手間を省こうとして、ローカルでイメージをビルドするたびにタグを付けています

マイ・ウェブ・アプリ:最新

ラベルを押し上げます。YAMLにも記されています

イメージ: ...:latest

。

災害発生時：オンラインのコードにバグが見つかり緊急ロールバックが必要になったとき、すべての過去バージョンがlatestによって上書きされてしまっていることに気づくでしょう。さらに、Kubernetesの基盤にはイメージのキャッシュメカニズムが備わっており、ローカルにlatestタグのイメージがすでに存在していると、たとえ新しいコードをプッシュしたとしても、処理を省略してローカルの古いイメージをそのまま再利用してしまうことがあります。その結果、新しいバージョンがまったくデプロイされないという事態が生じる可能性があります。

大手企業の標準的な対応策：latestの使用は徹底的に排除する。プッシュするたびに、意味のあるバージョン番号 (v1.0、v1.1など) を使用するか、または

GitのコミットIDをそのまま使用します。新バージョンをリリースする際には、YAMLファイルのバージョン番号を更新し、GKEによる完全なローリングアップデートを実行することで、サービスのダウンタイムなしでデプロイを行います。

2. Artifact Registryの自動クリーンアップ（ライフサイクル管理）がフリーズする

開発チームがCI/CD自動化パイプライン (GitHub action、GitLab CIなど) を構成すると、コードが統合されるたびに、いくつかのGBのミラーがArtifactレジストリに自動的に生成されます。もし放置すれば、数か月後には倉庫に何千、何万もの古いディスクイメージが山積みになり、月末のGoogle Cloud Storageの請求額は経営者を痛い目に遭わせることになるでしょう。

ハイレベルなコスト削減テクニック：Artifact Registryのリポジトリ設定で、「クリーンアップポリシー（Cleanup Policies）」を有効にします。

冷たい資産の自動消去ルール：次のいずれかのルールを設定する。「タグが一切付いていない一時的な中間イメージについては、7日を経過したものを直ちに物理的に破棄する」、または「バージョンタグが付いたイメージについては、最新の20バージョンのみを保持し、古いものは自動で消去する」。システムに自動的に断捨離を任せれば、企業のクラウド資産にかかる高額な未使用ストレージ料金を削減できます。

まとめ

GCP Artifact RegistryとGKEを基盤とするクラウドネイティブなデプロイメントの実装例において、その核となる産業レベルの真髄は、実は次の十六文字に集約されます。

ミラーバージョンがロックされ、安全なプルがなく、コピーが安定していると宣言され、倉庫が自動的にクリーンアップされます

。

この一連の閉ループ型の最強コンビにより、面倒なサーバー環境の設定や複雑なネットワーク負荷分散の構築、さらには障害発生を人手で逐一監視するといった苦役から、あなたは完全に解放されます。すべてのリソースをコードとビジネスそのものに集中し、グーグルが誇る世界トップクラスのクラウドネイティブインフラ上では、お客様のアプリケーションは無限の弾力性と自動的な災害復旧機能を備えた、一流企業ならではの強みを享受できます。

gcloud services enable container.googleapis.com artifactregistry.googleapis.com

2. プライベートイメージレジストリの作成（Artifact Registry）

私たちは中国台湾地域で

アジア東1

、国内アクセスの遅延が極めて低い）Docker専用のレポジトリを構築し、プロジェクトIDは仮にとします

マイ-GKEプロジェクト

バッシュ

gcloud artifacts repositories create gke-repo \

--リポジトリ形式=docker

--ロケーション=asia-east1

--説明

Ption = "GKEプロダクション画像リポジトリ"

3. マネージド型GKEクラスター（Autopilotモード）の作成

中小企業やK8sの複雑な調整に苦しめられたくないチームには

自動運転モードを選択することを強くお勧めします

バッシュ

Gcloud containerクラスターズcreate-auto prod-gke-cluster \

--ロケーション=asia-east1

(クラスターを作るのに約3〜5分かかりますが、コーヒーを飲んで辛抱強く待ってください。)

第3段階：実戦演習1―ローカルコードのコンテナ化とクラウドへのプッシュ

あなたがローカルに非常に単純なWebアプリケーション（Node.jsでもPythonでも構いません）を持っており、それがローカルでリッスンしていると仮定します。

八千八十

ポート。

1.ハードコア生産級Dockerfileの作成

プロジェクトのルートディレクトリに、新しく一つ作成します

Dockerfile

# 公式の軽量ベースイメージを使用する

FROM alpine:3.18

# 実行時依存をインストールする (Pythonの例)

RUN apk add --no-cache python3 py3-pip

WORKDIR /app

COPY . /app

# ビジネスポートの公開

8080を公開する

# Webサービスを開始する

CMD ["python3", "-m", "http.server", "8080"]

2. 結合用の暗号：ローカルのDockerとGCPの認証を設定する

多くの人がここでストリーミングを行うとエラーが発生します。これは、DockerがデフォルトでGCPのレジストリを認識していないためです。私たちは……させる必要があります

gcloud

セキュリティ資格情報をローカルのDocker設定ファイルに直接挿入する：

バッシュ

gcloud auth configure-docker asia-east1-docker.pkg.dev

3. コンパイルし、タグを付けて強力にストリーミング配信する

Artifactレジストリの標準仕様に基づいて、ミラーにクラウドパスを持つ仕様名を付け、次のようにプッシュします

バッシュ

# コンパイルしてv1.0バージョンにパッケージ化する

Dockerビルド-t asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:

V1.0.

# 全力でクラウドをプッシュ

docker push asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:v1.0

進捗バーが完了すると、GCPコンソールのArtifact Registryページに移動し、イメージが確実にクラウド上に配置されていることを確認できます。さらに、Googleはバックグラウンドで自動的にOSの脆弱性スキャンを実施しています。

第4段階：実戦演習2―宣言型YAMLによるGKEクラスターのデプロイ

ミラーがクラウドにアップロードされました。では、GKEはどのようにしてそれを取り込んで、実際にサービスを提供できるコンテナ（ポッド）へと起動させるのでしょうか。Kubernetesの世界では、サーバーの起動コマンドを直接打つのではなく、私たちはYAMLファイルを記述します。

YAMLのプロファイル

。

確立したばかりのGKEクラスタにローカルで接続し、認証証明書を取得します

バッシュ

gcloud container clusters get-credentials prod-gke-cluster --location=asia-east1

ローカルに新しい名前を作ります。

デプロイメント.yaml

の書類は、以下の大手工場の多国籍構造規範に合致する宣言式コードを貼り付ける

ヤムル

ApiVersion: apps/v1

種類: デプロイメント

メタデータ:

名前：webアプリケーションデプロイメント

ラベル:

アプリケーション: ウェブサービス

仕様:

レプリカ数: 3 # 高可用性の冗長化を固定化：常時3つのコンテナレプリカを保持し、1つが障害になった場合は自動で新しいレプリカを起動します

セレクター:

マッチラベル:

アプリケーション: ウェブサービス

テンプレート:

メタデータ:

ラベル:

アプリケーション: ウェブサービス

仕様:

コンテナ:

-名前: webコンテナ

# 先ほどArtifact Registryにプッシュしたイメージのパスを正確に指定します

イメージ：asia-east1-docker.pkg.dev/my-gke-project/gke-repo/my-web-app:v1.0

スポーツ:

-コンテナポート: 8080

Resources: # リソース仕様を厳しく制限し、やくざコードに搾られないようにする

ドライクラスタ

制限:

CPU: 「500m」

メモリ: "512Mi"

リクエスト:

CPU: 「200m」

メモリ: "256Mi"

---

APIバージョン: v1

種類: サービス

メタデータ:

名前：web-app-lb-service

仕様:

タイプ: LoadBalancer # GKEがGoogleのネットワーク基盤層に対して、高防御機能を備えたグローバルなパブリック負荷分散IPを自動で申請するようにします

セレクター:

アプリケーション: ウェブサービス

スポーツ:

-プロトコル：TCP

ポート: 80 # フロントエンドのパブリックネットワークへの入口となるポート

targetPort: 8080 # コンテナ内部の実際のポートに対応します

ターミナルでワンクリックデプロイコマンドを実行し、この設計図をGKEに投入します。

バッシュ

kubectl apply -f deployment.yaml

第5段階：奇跡を目の当たりにする瞬間――本番環境での検証と障害シミュレーション

デプロイが完了した後、私たちはKubernetesの「天眼コマンド」を用いてインフラの立ち上がりを監視します。

バッシュ

ポッドを取得する

画面に緑色のマークが3つ点灯するのをご覧いただけます

ランニング

ステータスのPod。

続いて、Googleが割り当てたパブリックIPの負荷分散用外部ゲートウェイを確認します。

バッシュ

kubectl get service web-app-lb-service

あなたは見るでしょう

外部IP

欄に、金のように貴重なパブリックの静的IPアドレスが表示されました（例えば

34.120.x.x

本番環境を模した「メタモルフォーゼ演習」

GKEの自己修復機能を検証するため、あえてバックグラウンドで障害を発生させました。実行中のコンテナ（ポッド）を手動で削除する:

バッシュ

kubectl delete pod web-app-deployment-xxxxxx-xxxxx

削除した瞬間、あなたは再びブラシに行きます

新しいページ、ウェブサイト

まったくの遅延や途切れがありません

（残りの2つのレプリカがトラフィックを引き受けているため）。さらに驚くべきことに、再び実行すると

ポッドを取得する

そのとき、わずか数秒で新しいPodが自動的に起動し、正常状態になっていることに気づくでしょう。これこそが、GKEが宣言型のレプリカセットを自動的に管理するという最大の強みです。

第6段階：多国籍クラウドネイティブ事業における苦難の教訓

このソリューションがきちんと動作すれば、あなたはクラウドネイティブの最も高いハードルをすでに越えたことになります。しかし、本番の企業向け高並行環境で生き残るためには、アーキテクトとして、直ちに設定を二次的に強化し、次の二つの見えない重大な落とし穴を防ぐ必要があります。

1. 決して使用しない