生railsをローカル環境、Docker環境、ローカルKubernetes環境、Google Kubernetes Engineに徐々にデプロイしていく

railsをGKE（Google Kubernetes Engine）にデプロイしてみて、クラウド開発ってこんな感じか〜みたいな気持ちになりましょう。

対象（になりそうなひと）

• rails・GKE・dockerあたりのキーワードがぐぐらなくてもなんとなくわかる
• mac
• railsでの開発はじめて
• GKEもはじめて
• コンテナベースの開発もはじめて

まあなんでもはじめてでもOKなはず。な状態でもできるような手順にしました。が、そもそもの概念とかはあんまり説明しません。ほかに託します。

いきなりrailsアプリを準備してGKEにデプロイするのは、もうそんなこと出来る人は慣れっこなんでしょ！感がするので、簡単なものからじょじょにステップアップする感じでGKEに向かっていきます。

具体的にどうステップアップしていくかというと

• ローカル環境でrailsアプリ動かす
• docker環境でrailsアプリ動かす
• Kubernetesローカル環境でrailsアプリ動かす
• Google Kubernetes Engine上でrailsアプリ動かす

みたいな感じで、のぼっていくのはいかがでしょうかという流れでいきます

ローカルRails

rubyインストール→railsインストール&Helloアプリ作成→ローカルrailsアプリ起動 をめざして

rubyインストール

個人的好みでanyenv→rbenv→rubyインストール の順で入れます。

• anyenv: **env 系の処理系インストーラをなんでもインストールしてくれる君
• rbenv: **env のruby版。ディレクトリごとに異なるバージョンのrubyをinstallできる。

では順に

anyenv

# anyenvのソースコードをローカルに落とす
git clone https://github.com/riywo/anyenv ~/.anyenv
# 環境変数PATHへの設定追加コマンドをbashの設定に追加。anyenvコマンドを叩くのに必要。
echo 'export PATH=$HOME/.anyenv/bin:$PATH' >> ~/.bash_profile
echo 'eval "$(anyenv init -)"' >> ~/.bash_profile
# シェル再起動と同じ意味
exec $SHELL -l

rbenv

anyenv install rbenv

ruby

# 執筆時点でよさげなものを。適当です。バージョンリストはrbenv install -lで。
rbenv install 2.5.1

これでrubyのインストールはOK。railsアプリつくっていきましょう。

railsインストール&Helloアプリ作成

bundlerでrailsをインストール→railsコマンドでアプリ作成→railsアプリ起動に必要なライブラリをインストール をめざして

railsインストール

# アプリをつくるディレクトリを作成。名前は・・おこのみですがhello-railsにでもしますか。
mkdir hello-rails
cd hello-rails
# さっきインストールしたバージョン2.5.1はここで！！このディレクトリで使う！！！という宣言
rbenv local 2.5.1
# bundleコマンド叩けるようにする
gem install bundle
# Gemfile生成
bundle init

生成したGemfileという名前のファイルのrailsの部分のコメントアウトを外しましょう。

Gemfile

# frozen_string_literal: true
source "https://rubygems.org"
git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }
gem "rails"

そしてこのディレクトリ配下（vendor/bundle配下）にrailsをインストールします。

bundle install --path vendor/bundle

これでrailsアプリを作れる準備が整ったので作成します。今回データベース使うアプリは作成しないのでmysqlの指定とかはしません。あとファイルの上書き確認が出ますが、基本yesでOKです。

bundle exec rails new . -B --skip-turbolinks --skip-test

で、このコマンドでGemfileが書き換わったのでもう一度依存ライブラリをインストールし直します

bundle install

ローカルrailsアプリ起動

railsアプリ起動しまーす

bin/bundle exec rails s -p 3000 -b 0.0.0.0

localhost:3000に接続すると・・・

https://railsguides.jp/images/getting_started/rails_welcome.png

こういう画面がでる。出たら成功。Yey!

control + c で止められます。

はい。最初のミッション ローカル環境でrailsアプリ動かす は達成。

次。 docker環境でrailsアプリ動かす これやります。

ruby on rails on docker

dockerで起動します

インストールまだな方は

Docker Desktop (Mac) - Docker Hub

ここから。

Dockerfile という名前のファイルを作って、このような内容にします。

FROM ruby:2.5.1
# コンテナ内にアプリケーション用ディレクトリを作成
RUN mkdir /hello-rails
# コンテナ内にログインした時に最初にここを参照する
WORKDIR /hello-rails
# ローカルのGemfileをDocker内にコピー
ADD Gemfile /hello-rails/Gemfile
ADD Gemfile.lock /hello-rails/Gemfile.lock
# コンテナ内であらかじめ依存ライブラリをインストールしておく
RUN bundle install
# ローカルのソースコードを全部コンテナ内にコピー
ADD . /hello-rails
# さっきrailsの起動に使ったコマンドをDocker風にするとこうなる。コンテナ起動時に叩かれる。
CMD ["bin/bundle", "exec", "rails", "s", "-p", "3000", "-b", "0.0.0.0"]

rails用のimageをこのDockerfileからビルドしましょう。imageの名前はhello-rails。末尾の . がカレントディレクトリを示していて、dockerコマンドがカレントディレクトリにあるDockerfileを探しにいってくれるという仕組みです。

docker build -t hello-rails .

そして起動

docker run -p 9000:3000 hello-rails

今度はlocalhost:9000に接続すると・・・

Yayできた？できました？Yey！！！

control + c で止められます。

ruby on rails on docker on kubernetes on local

こんどは作ったimageをローカルのKubernetesに乗っけちゃいます。

環境下準備

ローカルKubernetes環境構築まだな方は、下記画面の設定をしてapplyをクリックしましょう。

そしてkubectlコマンドを打てるようにします。

インストールにはHomebrew使います。まだ入れていない人はbrewコマンドを打つためにこれを打ちましょう。

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

そしてbrewコマンドでインストール

brew install kubernetes-cli

参考：

Install and Set Up kubectl

インストール確認のため、 docker-for-desktop のコンテキストが表示されるか確認しましょう。

kubectl config get-contexts

表示されたら成功です。ちゃんとインストールされていることがシェルでも確認できました。もしCURRENT列の*がdocker-for-desktopに設定されていなければ、use-contextコマンドで変えられます。

kubectl config use-context docker-for-desktop

デプロイ用のファイルをつくる

• Ingress：サービス外から内へのロードバランサー
• Service：サービス内から内へのロードバランサー
• Deployment：アプリケーション本体

を示すyamlファイルをそれぞれ用意しましょう。

・・・とその前に、ローカルならではの下準備が必要なのであらかじめやっておきます。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml

これはローカル環境にIngressの実装が存在しないために、Ingressのnginx実装を入れる必要があり、それをローカルKubernetesに適用するコマンドです。GKEなんかだと既存で実装があって、こんなことをしなくてもIngressがapplyできます。

下準備が適用されているかは

kubectl -n ingress-nginx get all

で確認できます。

ではファイルを順に作成していきます。

hello-ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: hello-rails-ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: hello-rails-svc # アクセスを受け渡す先のService名の指定
          servicePort: 80 # サービスが最初に受けるポート番号

hello-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: hello-rails-svc
spec:
  type: NodePort
  selector:
    app: hello-rails
  ports:
  - name: http
    port: 80
    targetPort: 3000 # アプリケーションにアクセスを受け渡す時のポート番号

hello-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-rails-deploy
  labels:
    app: hello-rails
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-rails
  template:
    metadata:
      labels:
        app: hello-rails
    spec:
      containers:
      - name: hello-rails
        image: hello-rails
        imagePullPolicy: IfNotPresent # ローカルイメージ使うには必須の設定
        args: [bin/bundle, exec, 'rails s -p 3000 -b 0.0.0.0']
        ports:
        - containerPort: 3000

これらのファイルが用意できたら、デプロイしていきましょう。

kubectl apply -f FILENAME

か

kubectl apply -f DIRNAME

のコマンドで可能です。 -f というのはファイルでKubernetesのリソースを適用するために必要なコマンドです。指定したものがディレクトリ名の場合は、そのディレクトリ配下にあるyamlファイルが全て適用されます。私はファイル名はディレクトリ名を打つのが面倒なのでよく、yamlが配置されているディレクトリに移動し、

kubectl apply -f .

とだけ打ちます。そうすると、現在のディレクトリのyamlファイルをすべて一気にapplyできます。

もしyamlを編集して、その部分だけapplyしたい場合でも、同じコマンドでKubernetesが賢く差分だけapplyしてくれます。

これまでapplyしてきたyamlファイルリソースの状態をを確認しましょう。

kubectl get all

こうすることで、yamlファイル内で指定した

hello-ingress (Ingress), hello-svc (Service), hello-deploy (Deployment)の様子が確認できるはずです。

あ、いや、Ingressは

kubectl get ingress

でないと見れないんでした。注意しましょう。（どうしてなんでしょう？）

ローカルのIngressのセットアップにはほんの少しかかります。 ADDRESS 欄に [localhost](<http://localhost>) と表示されるようになるまで待ちましょう。表示されたらアクセスしてみましょう。

多分ブラウザにセキュアじゃないからと怒られますが、なんとかしてアクセスしましょう。

先ほどと同じように Yay!とブラウザに表示されているはず。表示されたら成功です！晴れてRailsアプリをローカルKubernetesにデプロイすることができました！

クリーンアップ

これから別の場所にアプリケーションをデプロイし直すので、ローカルにデプロイしたアプリケーションを一旦消してしまいます。

アプリケーション本体を消す

kubectl delete -f .

Ingressのnginx実装を消す

kubectl delete -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
kubectl delete -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml

ruby on rails on docker on Google Kubernetes Engine

環境下準備

デプロイのためにプロジェクトを作成し、gcloudのコマンドが打てるようにします。

GCPプロジェクト作成

下記リンクの方法に沿う。が、基本管理画面に入って、プロジェクトの作成をクリックして、作成するだけです。管理画面のリンクはリンク先。

プロジェクトの作成と管理 | Resource Manager のドキュメント | Google Cloud

あ、請求関係の話が出てきてビビるかもですが、GCP登録後は300ドルくらいのクレジットが貰えるので急に破産したりはしません。どれくらい期限が先になるかは登録時期に左右されるようで、人によって60日だったり1年だったりするそう。ちなみに自分の場合は1年でした。

複数のGoogleアカウント管理している人はちゃんと意図したアカウントに作成しているか確認しましょう。間違えて会社や学校のアカウントとかでやらないように。

gcloud

下記リンクの方法に沿う。

Cloud SDK のインストール | Cloud SDK のドキュメント | Google Cloud

対話型インストーラを起動

curl https://sdk.cloud.google.com | bash

なんか色々聞かれるので好みに合わせて答えていきます。ちなみに自分の場合は

• インストールディレクトリはホームディレクトリ下
• usage reportは送信しない
• shell command completionは設定
• ホームディレクトリ下の .bash_profile を上書きした

そしてシェルを再起動

exec -l $SHELL

gcloud環境を初期化

gcloud init

• ログインしろと言われます。 Y をtypeするとブラウザが起動するのでログイン。
• プロジェクトの一覧が出てくるので、先程作成したプロジェクトを選択。
• リージョン設定したいか？と聞かれます。なんかグローバルですごそうな理由が無い限りは東京から変更することはないと思うので、東京に設定。
• asia-northeast1-a と入力すると東京になる。
• それ以外はこんな感じ。

initで色々設定して覚えきれない！忘れた！思うが、それらはいつでも

gcloud config list

で確認できる。安心。

ちなみに会社と個人で設定を分けたいというとき、再び

gcloud init

すれば新しい設定を作れるし、

gcloud config configurations list

で、作った設定の一覧を表示できます。今自分が何の設定なのかも知れる。

そして一覧から設定の名前を選び、activateの後に置くと、設定を変更可能。

gcloud config configurations activate CONFIGURATION_NAME

空のクラスタを作成

準備が整ったのでKubernetesクラスタをつくります。

gcloud container clusters create hello-rails --machine-type=n1-standard-1 --num-nodes=3 --cluster-version=1.10.9-gke.5

ノードの数が複数無いとクラスタっぽくないのでとりあえず3つ立ててます（ --num-nodes=3 ）。ケチりたい人は3の部分を1にすればOK（少々試す程度なら、そんなに価格は変わらないです）。

マシンは n1-standard-1 。standardのうち一番しょぼいの。一覧はこちらからどうぞ。

Machine Types | Compute Engine Documentation | Google Cloud

クラスタのバージョンは指定しないと古めのものが使われて、古めのバージョンでは新しめの機能を使おうとする時に予期しないバグに遭遇しやすいです。現在使えるバージョンをリストアップして、新しめのものを指定しましょう。

バージョンのリストは

gcloud container get-server-config

で確認できます。 validMasterVersions で示されているものから選ぶとgood.

さて、コマンドを打つとクラスタが作成されるが、クラスタの作成にはちょっと時間がかかるので待ちましょう。

作成できたらクラスタの情報を確認。なんかいっぱい出ます。それならちゃんとクラスタがあるということ。

gcloud container clusters describe hello-rails

また、GKEのコンソールでもクラスタの情報を表示できます。GCPのコンソールの左上ハンバーガー→GKE→クラスタ から確認できるはず。

ここからアプリケーションを扱うには kubectl を使います。どうやらGKE特有のリソース（上記のクラスタなど）の確保にはgcloudコマンドを使うが、kubernetesの文脈で扱えることは基本的にkubectlを使うっぽいです。

kubectlを使う下準備として、gcloudコマンド経由でkubectlに認証情報を渡します。こうすることで、あたかもローカルでKubernetesを扱うようにGKEをコントロールできるようになります。

gcloud container clusters get-credentials hello-rails

こうして、kubectl上ではGKEのhelloクラスタが操作対象に設定された。こういう操作対象のことをコンテキストと呼ぶらしく、現在kubectl上で扱えるコンテキストの一覧は

kubectl config get-contexts

で取得できます。コンテキストの切り替えは

kubectl config use-context CONTEXT_NAME

で可能。

さて、kubectl上でクラスタを扱えるようになったので、クラスタのノード（物理的なサーバーのこと）の一覧を取得してみます。

kubectl get nodes

GKE上に作成したクラスタのノード一覧が表示されれば成功！3つのノードがリストになって出てくるはず。これで kubectl で操作したことは即座にGKE上に反映されるようになります。

ここで「会社のリソースを使ってうっかり秘密でクラスタを構築してしまった！」という場合でもgcloudコマンドからいつでもクラスタを消せるので問題ないはず。

gcloud container clusters delete hello-rails

また、Kubernetesは「全部やり直せばそのバグ出ないようになります」みたいな状況になることもよくあるので、そういう時にも有効です。

イメージをGoogle Container RegistryにPushする

さきほどローカルにアプリケーションをデプロイした時は、ローカルに存在するDockerイメージをローカルKubernetesが参照していました。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-rails-deploy
  labels:
    app: hello-rails
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-rails
  template:
    metadata:
      labels:
        app: hello-rails
    spec:
      containers:
      - name: hello-rails
        image: hello-rails # ここでローカルのhello-railsイメージを参照していた
        imagePullPolicy: IfNotPresent # ローカルイメージ使うには必須の設定
        args: [bin/bundle, exec, 'rails s -p 3000 -b 0.0.0.0']
        ports:
        - containerPort: 3000

では、さっき立てた空のクラスタにGKEを使ってそのままアプリケーションをデプロイしようとすると・・・ hello-rails なんてイメージは存在しない。と怒られてしまいます。

GKEにアプリケーションをデプロイするには、GKEから参照できるところにDockerイメージを置く必要があります。

その参照できるところというのが、Google Container Registry(GCR)です。

これからGCRにアプリケーションをデプロイするので、下記ページの ENABLE THE API ボタンを押して、GCRのAPIを有効にしましょう。

Quickstart for Container Registry | Container Registry | Google Cloud

Dockerfileのあるディレクトリに行き、アプリケーションをビルドし直します。

docker build -t hello-rails .

タグ付け。PROJECT-IDの部分は作成したプロジェクトに合わせて編集しましょう。バージョン1.0のタグを付加してます。このタグは、例えばアプリケーションの中身をアップデートした時などに2.0に変えたものを付加し直したりすることで管理します。

docker tag hello-rails gcr.io/[PROJECT-ID]/hello-rails:1.0

プロジェクトIDの確認方法はこちら

Creating and Managing Projects | Resource Manager Documentation | Google Cloud

さあ、早速付加したタグを使って、Google Container RegistryにImageをPushします。

docker push gcr.io/[PROJECT-ID]/hello-rails:1.0

GCRにPushしたImageを参照するように、hello-deployment.yaml を書き換えます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-rails-deploy
  labels:
    app: hello-rails
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-rails
  template:
    metadata:
      labels:
        app: hello-rails
    spec:
      containers:
      - name: hello-rails
        image: gcr.io/[PROJECT-ID]/hello-rails:1.0 # GCRにPushしたImage
        args: [bin/bundle, exec, 'rails s -p 3000 -b 0.0.0.0']
        ports:
        - containerPort: 3000

Kubernetes用yamlファイルがあるディレクトリへ移動して、アプリケーションをデプロイします。

kubectl apply -f .

デプロイ後、アプリケーション全体のデプロイ状況は

kubectl get all

で確認できて、どうやらデプロイできているっぽいようなら、

kubectl get ingress

でアクセス先IPアドレスを確認できます。IPアドレスが表示されたら、アクセスできるようになります。

Webコンソールからはメニュー→Kuberneets Engine→Servicesで、hello-rails-ingressのEndpointがそのままサービスへのリンクになっているはずです。

アクセスできましたか？できた？Yay!

これで晴れて、GKE上にRailsアプリをデプロイできました。

クリーンアップ

きれいさっぱりします。

アプリケーション削除

kubectl delete -f .

クラスタ削除

gcloud container clusters delete hello

これでもう課金されないはずですが、心配であればプロジェクトごと消しましょう。

プロジェクトの作成と管理 | Resource Manager のドキュメント | Google Cloud

コマンド振り返り

shell（rbenvインストールまだな人）

# anyenvのソースコードをローカルに落とす
git clone https://github.com/riywo/anyenv ~/.anyenv
# 環境変数PATHへの設定追加コマンドをbashの設定に追加。anyenvコマンドを叩くのに必要。
echo 'export PATH=$HOME/.anyenv/bin:$PATH' >> ~/.bash_profile
echo 'eval "$(anyenv init -)"' >> ~/.bash_profile
# シェル再起動と同じ意味
exec $SHELL -l
anyenv install rbenv
# 執筆時点でよさげなものを。適当です。バージョンリストはrbenv install -lで。
rbenv install 2.5.1

shell

# アプリをつくるディレクトリを作成。名前は・・おこのみですがhello-railsにでもしますか。
mkdir hello-rails
cd hello-rails
# さっきインストールしたバージョン2.5.1はここで！！このディレクトリで使う！！！という宣言
rbenv local 2.5.1
# bundleコマンド叩けるようにする
gem install bundle
# Gemfile生成
bundle init

Gemfile

# frozen_string_literal: true
source "https://rubygems.org"
git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }
gem "rails"

shell

bundle install --path vendor/bundle
bundle exec rails new . -B --skip-turbolinks --skip-test
bundle install
# control + c で停止
bin/bundle exec rails s -p 3000 -b 0.0.0.0

Dockerfile

FROM ruby:2.5.1
# コンテナ内にアプリケーション用ディレクトリを作成
RUN mkdir /hello-rails
# コンテナ内にログインした時に最初にここを参照する
WORKDIR /hello-rails
# ローカルのGemfileをDocker内にコピー
ADD Gemfile /hello-rails/Gemfile
ADD Gemfile.lock /hello-rails/Gemfile.lock
# コンテナ内であらかじめ依存ライブラリをインストールしておく
RUN bundle install
# ローカルのソースコードを全部コンテナ内にコピー
ADD . /hello-rails
# さっきrailsの起動に使ったコマンドをDocker風にするとこうなる。コンテナ起動時に叩かれる。
CMD ["bin/bundle", "exec", "rails", "s", "-p", "3000", "-b", "0.0.0.0"]

shell

docker build -t hello-rails .
# control + c で停止
docker run -p 9000:3000 hello-rails

shell（kubectlインストールまだな人）

# 事前にDockerのKubernetes設定をOnにしておく（詳細はruby on rails on kubernetes on local）
# Homebrew
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
# kubectl
brew install kubernetes-cli
# インストール確認
kubectl config get-contexts
# docker-for-desctopに操作対象を変更
kubectl config use-context docker-for-desktop

shell

# ローカルデプロイのためにIngressのnginx実装を準備
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml
# 確認
kubectl -n ingress-nginx get all
# yamlファイルを作成
mkdir kube
cd kube
touch hello-ingress.yaml
touch hello-service.yaml
touch hello-deployment.yaml
cd ../

hello-ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: hello-rails-ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: hello-rails-svc # アクセスを受け渡す先のService名の指定
          servicePort: 80 # サービスが最初に受けるポート番号

hello-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: hello-rails-svc
spec:
  type: NodePort
  selector:
    app: hello-rails
  ports:
  - name: http
    port: 80
    targetPort: 3000 # アプリケーションにアクセスを受け渡す時のポート番号

hello-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-rails-deploy
  labels:
    app: hello-rails
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-rails
  template:
    metadata:
      labels:
        app: hello-rails
    spec:
      containers:
      - name: hello-rails
        image: hello-rails
        imagePullPolicy: IfNotPresent # ローカルイメージ使うには必須の設定
        args: [bin/bundle, exec, 'rails s -p 3000 -b 0.0.0.0']
        ports:
        - containerPort: 3000

shell

# kubeディレクトリ配下のリソースをすべて適用
kubectl apply -f kube
# 確認
kubectl get all
# Ingress状況確認&ブラウザを開いてアクセス、デプロイ確認
kubectl get ingress
# クリーンアップ
# アプリケーション本体を消す
kubectl delete -f kube
# Ingressのnginx実装を消す
kubectl delete -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
kubectl delete -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml

shell（gcloudインストールまだな人）

# インストール。対話的に色々聞かれる。
curl <https://sdk.cloud.google.com> | bash
# シェル再起動
exec -l $SHELL
# gcloud環境を初期化。ログイン、プロジェクト選択、リージョン設定
gcloud init
# 確認
gcloud config list
# 設定一覧
gcloud config configurations list

shell

# 利用可能なclusterバージョン確認
gcloud container get-server-config
# クラスタ作成
gcloud container clusters create hello-rails --machine-type=n1-standard-1 --num-nodes=3 --cluster-version=1.10.9-gke.5
# 確認
gcloud container clusters describe hello-rails
# kubectlに認証情報を渡す
gcloud container clusters get-credentials hello-rails
# GKE向け設定になっているか確認
kubectl config get-contexts
# コンテキスト切り替え
kubectl config use-context CONTEXT_NAME
# Node確認
kubectl get nodes
# アプリケーションリビルド
docker build -t hello-rails .
# ビルドしたimageにタグ付け
docker tag hello-rails gcr.io/[PROJECT-ID]/hello-rails:1.0
# GCRにPush
docker push gcr.io/[PROJECT-ID]/hello-rails:1.0

hello-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-rails-deploy
  labels:
    app: hello-rails
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-rails
  template:
    metadata:
      labels:
        app: hello-rails
    spec:
      containers:
      - name: hello-rails
        image: gcr.io/[PROJECT-ID]/hello-rails:1.0 # GCRにPushしたImage
        args: [bin/bundle, exec, 'rails s -p 3000 -b 0.0.0.0']
        ports:
        - containerPort: 3000

shell

# リソースをGKEに適用
kubectl apply -f kube
# デプロイ確認
kubectl get all
# アクセス先IP確認、ブラウザを開いてアクセス。
kubectl get ingress
# クリーンアップ
# アプリケーション削除
kubectl delete -f kube
# クラスタ削除
gcloud container clusters delete hello-rails