Rails開発用のDockerComposeワークフローをKubernetesに移行する方法
序章
最新のステートレスアプリケーションを構築する場合、アプリケーションのコンポーネントをコンテナ化するは、分散プラットフォームでのデプロイとスケーリングの最初のステップです。 開発でDockerCompose を使用したことがある場合は、次の方法でアプリケーションを最新化およびコンテナー化できます。
- コードから必要な構成情報を抽出します。
- アプリケーションの状態をオフロードします。
- 繰り返し使用するためにアプリケーションをパッケージ化します。
また、コンテナイメージの実行方法を指定するサービス定義も作成します。
Kubernetes などの分散プラットフォームでサービスを実行するには、Composeサービス定義をKubernetesオブジェクトに変換する必要があります。 これにより、アプリケーションを復元力でスケーリングできます。 Kubernetesへの変換プロセスを高速化できるツールの1つは、 kompose です。これは、開発者がComposeワークフローをKubernetesやOpenShiftなどのコンテナーオーケストレーターに移動するのに役立つ変換ツールです。
このチュートリアルでは、komposeを使用してComposeサービスをKubernetesオブジェクトに変換します。 komposeが提供するオブジェクト定義を開始点として使用し、セットアップで Secrets 、 Services 、およびPersistentVolumeClaimsが使用されるように調整します。 Kubernetesが期待していること。 チュートリアルが終了すると、Kubernetesクラスターで実行されているPostgreSQLデータベースを備えたシングルインスタンスRailsアプリケーションが完成します。 このセットアップは、DockerComposeを使用した開発用のRubyonRailsアプリケーションのコンテナー化で説明されているコードの機能を反映し、ニーズに合わせて拡張できる本番環境に対応したソリューションを構築するための良い出発点になります。
前提条件
- ロールベースのアクセス制御(RBAC)が有効になっているKubernetes1.19+クラスター。 このセットアップではDigitalOceanKubernetesクラスターを使用しますが、別の方法を使用してクラスターを自由に作成できます。
- The
kubectl
ローカルマシンまたは開発サーバーにインストールされ、クラスターに接続するように構成されたコマンドラインツール。 インストールについてもっと読むことができますkubectl
公式ドキュメントにあります。 - Dockerがローカルマシンまたは開発サーバーにインストールされています。 Ubuntu 20.04を使用している場合は、 Ubuntu20.04にDockerをインストールして使用する方法の手順1と2に従ってください。 それ以外の場合は、他のオペレーティングシステムへのインストールについて、公式ドキュメントに従ってください。 必ず非rootユーザーをに追加してください
docker
リンクされたチュートリアルのステップ2で説明されているように、グループ。 - DockerHubアカウント。 これを設定する方法の概要については、DockerHubのこの紹介を参照してください。
ステップ1—komposeをインストールする
komposeの使用を開始するには、プロジェクトのGitHubリリースページに移動し、現在のリリース(この記事の執筆時点ではバージョン 1.22.0 )へのリンクをコピーします。 このリンクを次の場所に貼り付けます curl
最新バージョンのkomposeをダウンロードするコマンド:
- curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-linux-amd64 -o kompose
Linux以外のシステムへのインストールの詳細については、インストール手順を参照してください。
バイナリを実行可能にします。
- chmod +x kompose
あなたにそれを移動します PATH
:
- sudo mv ./kompose /usr/local/bin/kompose
正しくインストールされていることを確認するには、バージョンチェックを実行します。
- kompose version
インストールが成功すると、次のような出力が表示されます。
Output1.22.0 (955b78124)
と kompose
インストールして使用する準備ができたら、Kubernetesに変換するNode.jsプロジェクトコードのクローンを作成できます。
ステップ2—アプリケーションのクローン作成とパッケージ化
アプリケーションをKubernetesで使用するには、プロジェクトコードのクローンを作成し、アプリケーションをパッケージ化して、 kubelet
サービスはイメージをプルできます。
最初のステップは、 DigitalOceanCommunityGitHubアカウントからrails-sidekiqリポジトリのクローンを作成することです。 このリポジトリには、DockerComposeを使用した開発用のRubyonRailsアプリケーションのコンテナ化で説明されているセットアップのコードが含まれています。このコードは、デモRailsアプリケーションを使用してDockerComposeを使用して開発環境をセットアップする方法を示しています。 アプリケーション自体の詳細については、シリーズ Rails onContainersを参照してください。
リポジトリをと呼ばれるディレクトリに複製します rails_project
:
- git clone https://github.com/do-community/rails-sidekiq.git rails_project
に移動します rails_project
ディレクトリ:
- cd rails_project
次に、このチュートリアルのコードを compose-workflow
ブランチ:
- git checkout compose-workflow
OutputBranch 'compose-workflow' set up to track remote branch 'compose-workflow' from 'origin'.
Switched to a new branch 'compose-workflow'
The rails_project
ディレクトリには、ユーザー入力で動作するサメ情報アプリケーションのファイルとディレクトリが含まれています。 コンテナで動作するように最新化されました。機密性の高い特定の構成情報がアプリケーションコードから削除され、実行時に注入されるようにリファクタリングされ、アプリケーションの状態がPostgreSQLデータベースにオフロードされました。
最新のステートレスアプリケーションの設計の詳細については、Kubernetes用アプリケーションのアーキテクチャおよびKubernetes用アプリケーションの最新化を参照してください。
プロジェクトディレクトリには、 Dockerfile
アプリケーションイメージを構築するための手順が記載されています。 今すぐイメージをビルドして、Docker Hubアカウントにプッシュし、Kubernetesセットアップで使用できるようにします。
docker build コマンドを使用して、 -t
フラグ。覚えやすい名前でタグ付けできます。 この場合、イメージにDocker Hubユーザー名のタグを付け、名前を付けます rails-kubernetes
またはあなた自身が選んだ名前:
- docker build -t your_dockerhub_user/rails-kubernetes .
The .
コマンドで、ビルドコンテキストが現在のディレクトリであることを指定します。
イメージの作成には1〜2分かかります。 完了したら、画像を確認します。
- docker images
次の出力が表示されます。
OutputREPOSITORY TAG IMAGE ID CREATED SIZE
your_dockerhub_user/rails-kubernetes latest 24f7e88b6ef2 2 days ago 606MB
alpine latest d6e46aa2470d 6 weeks ago 5.57MB
次に、前提条件で作成したDockerHubアカウントにログインします。
- docker login -u your_dockerhub_user
プロンプトが表示されたら、DockerHubアカウントのパスワードを入力します。 この方法でログインすると、 ~/.docker/config.json
DockerHubのクレデンシャルを使用してユーザーのホームディレクトリにファイルします。
dockerpushコマンドを使用してアプリケーションイメージをDockerHubにプッシュします。 交換することを忘れないでください your_dockerhub_user
独自のDockerHubユーザー名を使用:
- docker push your_dockerhub_user/rails-kubernetes
これで、Kubernetesでアプリケーションを実行するためにプルできるアプリケーションイメージができました。 次のステップは、アプリケーションサービス定義をKubernetesオブジェクトに変換することです。
ステップ3—komposeを使用してComposeサービスをKubernetesオブジェクトに変換する
DockerComposeファイル。ここでは docker-compose.yml
、Composeでサービスを実行する定義を示します。 Composeのserviceは実行中のコンテナーであり、サービス定義には、各コンテナーイメージの実行方法に関する情報が含まれています。 このステップでは、を使用してこれらの定義をKubernetesオブジェクトに変換します kompose
作成する yaml
ファイル。 これらのファイルには、目的の状態を記述するKubernetesオブジェクトのspecsが含まれます。
これらのファイルを使用して、さまざまなタイプのオブジェクトを作成します。 Services 。これにより、コンテナを実行しているPodsに引き続きアクセスできるようになります。 展開。ポッドの望ましい状態に関する情報が含まれます。 PersistentVolumeClaim を使用して、データベースデータのストレージをプロビジョニングします。 実行時に注入される環境変数のConfigMap。 アプリケーションのデータベースユーザーとパスワード用のSecret。 これらの定義の一部はファイルに含まれます kompose
私たちのために作成し、他の人は私たち自身を作成する必要があります。
まず、私たちの定義のいくつかを変更する必要があります docker-compose.yml
Kubernetesで動作するファイル。 新しく作成したアプリケーションイメージへの参照を app
サービス定義を行い、Composeを使用して開発中のアプリケーションコンテナを実行するために使用したバインドマウント、ボリューム、および追加のコマンドを削除します。 さらに、両方のコンテナの再起動ポリシーをKubernetesが期待する動作に一致するように再定義します。
このチュートリアルの手順に従って、 compose-workflow
gitで分岐すると、 docker-compose.yml
作業ディレクトリ内のファイル。
あなたが持っていない場合 docker-compose.yml
次に、このシリーズの前のチュートリアルDockerComposeを使用した開発用のRubyonRailsアプリケーションのコンテナー化にアクセスし、リンクされたセクションのコンテンツを新しいものに貼り付けてください。 docker-compose.yml
ファイル。
でファイルを開く nano
またはお気に入りの編集者:
- nano docker-compose.yml
の現在の定義 app
アプリケーションサービスは次のようになります。
. . .
services:
app:
build:
context: .
dockerfile: Dockerfile
depends_on:
- database
- redis
ports:
- "3000:3000"
volumes:
- .:/app
- gem_cache:/usr/local/bundle/gems
- node_modules:/app/node_modules
env_file: .env
environment:
RAILS_ENV: development
. . .
サービス定義を次のように編集します。
- 交換してください
build:
とのラインimage: your_dockerhub_user/rails-kubernetes
- 以下を削除します
context: .
、 とdockerfile: Dockerfile
行。 - を削除します
volumes
リスト。
完成したサービス定義は次のようになります。
. . .
services:
app:
image: your_dockerhub_user/rails-kubernetes
depends_on:
- database
- redis
ports:
- "3000:3000"
env_file: .env
environment:
RAILS_ENV: development
. . .
次に、下にスクロールして database
サービス定義を作成し、次の編集を行います。
- を削除します
- ./init.sql:/docker-entrypoint-initdb.d/init.sql
ボリュームライン。 ローカルSQLファイルの値を使用する代わりに、POSTGRES_USER
とPOSTGRES_PASSWORD
ステップ4で作成するシークレットを使用してデータベースコンテナに移動します。 - 追加する
ports:
ポート5432のKubernetesクラスタ内でPostgreSQLを利用できるようにするセクション。 - 追加します
environment:
セクションとPGDATA
内部のディレクトリを指す変数/var/lib/postgresql/data
. この設定は、PostgreSQLがブロックストレージを使用するように構成されている場合に必要です。データベースエンジンは、サブディレクトリでデータファイルを見つけることを想定しているためです。
The database
編集が終了すると、サービス定義は次のようになります。
. . .
database:
image: postgres:12.1
volumes:
- db_data:/var/lib/postgresql/data
ports:
- "5432:5432"
environment:
PGDATA: /var/lib/postgresql/data/pgdata
. . .
次に、 redis
を追加してデフォルトのTCPポートを公開するサービス定義 ports:
デフォルトの6379ポートを持つセクション。 追加する ports:
セクションでは、RedisをKubernetesクラスター内で利用できるようにします。 あなたの編集 redis
サービスは次のようになります。
. . .
redis:
image: redis:5.0.7
ports:
- "6379:6379"
編集後 redis
ファイルのセクションに進み、 sidekiq
サービス定義。 と同じように app
サービスでは、ローカルDockerイメージの構築からDockerHubからのプルに切り替える必要があります。 次の編集を行います sidekiq
サービス定義:
- 交換してください
build:
とのラインimage: your_dockerhub_user/rails-kubernetes
- 以下を削除します
context: .
、 とdockerfile: Dockerfile
行。 - を削除します
volumes
リスト。
. . .
sidekiq:
image: your_dockerhub_user/rails-kubernetes
depends_on:
- app
- database
- redis
env_file: .env
environment:
RAILS_ENV: development
entrypoint: ./entrypoints/sidekiq-entrypoint.sh
最後に、ファイルの下部で、 gem_cache
と node_modules
トップレベルからのボリューム volumes
鍵。 キーは次のようになります。
. . .
volumes:
db_data:
編集が終了したら、ファイルを保存して閉じます。
参考までに、完成した docker-compose.yml
ファイルには次のものが含まれている必要があります。
version: '3'
services:
app:
image: your_dockerhub_user/rails-kubernetes
depends_on:
- database
- redis
ports:
- "3000:3000"
env_file: .env
environment:
RAILS_ENV: development
database:
image: postgres:12.1
volumes:
- db_data:/var/lib/postgresql/data
ports:
- "5432:5432"
environment:
PGDATA: /var/lib/postgresql/data/pgdata
redis:
image: redis:5.0.7
ports:
- "6379:6379"
sidekiq:
image: your_dockerhub_user/rails-kubernetes
depends_on:
- app
- database
- redis
env_file: .env
environment:
RAILS_ENV: development
entrypoint: ./entrypoints/sidekiq-entrypoint.sh
volumes:
db_data:
サービス定義を翻訳する前に、 .env
そのファイル kompose
非機密情報を使用してConfigMapを作成するために使用します。 このファイルの詳細については、DockerComposeを使用した開発用のRubyonRailsアプリケーションのコンテナ化のステップ2を参照してください。
そのチュートリアルでは、 .env
私たちに .gitignore
バージョン管理にコピーされないようにするためのファイル。 これは、このチュートリアルのステップ2でrails-sidekiqリポジトリのクローンを作成したときにコピーされなかったことを意味します。 したがって、今すぐ再作成する必要があります。
ファイルを作成します。
- nano .env
kompose
このファイルを使用して、アプリケーションのConfigMapを作成します。 ただし、からすべての変数を割り当てる代わりに app
Composeファイルのサービス定義では、PostgreSQLとRedisの設定のみを追加します。 ステップ4でシークレットオブジェクトを手動で作成するときに、データベース名、ユーザー名、およびパスワードを個別に割り当てます。
次のポートとデータベース名の情報をに追加します .env
ファイル。 必要に応じて、データベースの名前を自由に変更してください。
DATABASE_HOST=database
DATABASE_PORT=5432
REDIS_HOST=redis
REDIS_PORT=6379
編集が終了したら、ファイルを保存して閉じます。
これで、オブジェクトの仕様を使用してファイルを作成する準備が整いました。 kompose
リソースを翻訳するための複数のオプションを提供します。 あなたはできる:
- 作成
yaml
のサービス定義に基づくファイルdocker-compose.yml
とファイルkompose convert
. - を使用してKubernetesオブジェクトを直接作成する
kompose up
. - ヘルムチャートを作成する
kompose convert -c
.
今のところ、サービス定義を次のように変換します yaml
ファイルを追加し、ファイルを追加して修正します。 kompose
作成します。
サービス定義をに変換します yaml
次のコマンドでファイルを作成します。
- kompose convert
このコマンドを実行すると、komposeは作成したファイルに関する情報を出力します。
OutputINFO Kubernetes file "app-service.yaml" created
INFO Kubernetes file "database-service.yaml" created
INFO Kubernetes file "redis-service.yaml" created
INFO Kubernetes file "app-deployment.yaml" created
INFO Kubernetes file "env-configmap.yaml" created
INFO Kubernetes file "database-deployment.yaml" created
INFO Kubernetes file "db-data-persistentvolumeclaim.yaml" created
INFO Kubernetes file "redis-deployment.yaml" created
INFO Kubernetes file "sidekiq-deployment.yaml" created
これらには以下が含まれます yaml
RailsアプリケーションのService、Deployment、ConfigMap、および db-data
PersistentVolumeClaimおよびPostgreSQLデータベースのデプロイメント。 それぞれRedisとSidekiqのファイルも含まれています。
これらのマニフェストをRailsプロジェクトのメインディレクトリから除外するには、次の名前の新しいディレクトリを作成します。 k8s-manifests
次に、 mv
生成されたファイルをそこに移動するコマンド:
- mkdir k8s-manifests
- mv *.yaml k8s-manifests
ついに、 cd
に k8s-manifests
ディレクトリ。 これからは、このディレクトリ内から作業を進めて、物事を整頓します。
- cd k8s-manifests
これらのファイルは良い出発点ですが、アプリケーションの機能をDockerComposeを使用した開発用のRubyonRailsアプリケーションのコンテナー化で説明されているセットアップと一致させるには、いくつかの追加と変更を行う必要があります。そのファイル kompose
が生成されました。
ステップ4—Kubernetesシークレットを作成する
アプリケーションが期待どおりに機能するためには、ファイルにいくつかの変更を加える必要があります。 kompose
作成しました。 これらの変更の最初は、データベースユーザーとパスワードのシークレットを生成し、それをアプリケーションとデータベースの展開に追加することです。 Kubernetesは、環境変数を操作する2つの方法を提供します。ConfigMapsとSecretsです。 kompose
すでに、私たちが含めた非機密情報を使用してConfigMapを作成しています .env
ファイルなので、データベース名、ユーザー名、パスワードなどの機密情報を使用してシークレットを作成します。
シークレットを手動で作成する最初のステップは、データを base64 に変換することです。これは、バイナリデータを含むデータを均一に送信できるエンコードスキームです。
まず、データベース名をbase64でエンコードされたデータに変換します。
- echo -n 'your_database_name' | base64
エンコードされた値を書き留めます。
次に、データベースのユーザー名を変換します。
- echo -n 'your_database_username' | base64
出力に表示される値を再度記録します。
最後に、パスワードを変換します。
- echo -n 'your_database_password' | base64
ここでも出力の値に注意してください。
シークレットのファイルを開きます。
- nano secret.yaml
注:Kubernetesオブジェクトは通常でYAML を使用して定義されます。これはタブを厳密に禁止し、インデントに2つのスペースを必要とします。 いずれかのフォーマットを確認したい場合 yaml
ファイルの場合は、 linter を使用するか、次を使用して構文の有効性をテストできます。 kubectl create
とともに --dry-run
と --validate
フラグ:
- kubectl create -f your_yaml_file.yaml --dry-run --validate=true
一般に、リソースを作成する前に構文を検証することをお勧めします。 kubectl
.
次のコードをファイルに追加して、 DATABASE_NAME
, DATABASE_USER
と DATABASE_PASSWORD
作成したエンコードされた値を使用します。 ここで強調表示されているプレースホルダーの値を、エンコードされたデータベース名、ユーザー名、およびパスワードに必ず置き換えてください。
apiVersion: v1
kind: Secret
metadata:
name: database-secret
data:
DATABASE_NAME: your_database_name
DATABASE_PASSWORD: your_encoded_password
DATABASE_USER: your_encoded_username
シークレットオブジェクトに名前を付けました database-secret
、ただし、好きな名前を付けることができます。
これらのシークレットは、PostgreSQLに接続できるようにRailsアプリケーションで使用されます。 ただし、データベース自体はこれらの同じ値で初期化する必要があります。 次に、3行をコピーして、ファイルの最後に貼り付けます。 最後の3行を編集し、 DATABASE
各変数のプレフィックス POSTGRES
. 最後に変更します POSTGRES_NAME
読み取る変数 POSTGRES_DB
.
あなたの決勝 secret.yaml
ファイルには次のものが含まれている必要があります。
apiVersion: v1
kind: Secret
metadata:
name: database-secret
data:
DATABASE_NAME: your_database_name
DATABASE_PASSWORD: your_encoded_password
DATABASE_USER: your_encoded_username
POSTGRES_DB: your_database_name
POSTGRES_PASSWORD: your_encoded_password
POSTGRES_USER: your_encoded_username
編集が終了したら、このファイルを保存して閉じます。 あなたがしたように .env
ファイル、必ず追加してください secret.yaml
あなたに .gitignore
バージョン管理の対象外にするためのファイル。
と secret.yaml
記述された次のステップは、アプリケーションとデータベースのデプロイメントの両方が、ファイルに追加した値を使用することを確認することです。 シークレットへの参照をアプリケーションのデプロイに追加することから始めましょう。
というファイルを開きます app-deployment.yaml
:
- nano app-deployment.yaml
ファイルのコンテナ仕様には、以下で定義されている次の環境変数が含まれています。 env
鍵:
apiVersion: apps/v1
kind: Deployment
. . .
spec:
containers:
- env:
- name: DATABASE_HOST
valueFrom:
configMapKeyRef:
key: DATABASE_HOST
name: env
- name: DATABASE_PORT
valueFrom:
configMapKeyRef:
key: DATABASE_PORT
name: env
- name: RAILS_ENV
value: development
- name: REDIS_HOST
valueFrom:
configMapKeyRef:
key: REDIS_HOST
name: env
- name: REDIS_PORT
valueFrom:
configMapKeyRef:
key: REDIS_PORT
name: env
. . .
アプリケーションがこれらの値にアクセスできるように、シークレットへの参照を追加する必要があります。 含める代わりに configMapKeyRef
私たちを指すための鍵 env
ConfigMapは、既存の値の場合と同様に、 secretKeyRef
私たちの値を指すための鍵 database-secret
秘密。
の後に次の秘密の参照を追加します - name: REDIS_PORT
可変セクション:
. . .
spec:
containers:
- env:
. . .
- name: REDIS_PORT
valueFrom:
configMapKeyRef:
key: REDIS_PORT
name: env
- name: DATABASE_NAME
valueFrom:
secretKeyRef:
name: database-secret
key: DATABASE_NAME
- name: DATABASE_PASSWORD
valueFrom:
secretKeyRef:
name: database-secret
key: DATABASE_PASSWORD
- name: DATABASE_USER
valueFrom:
secretKeyRef:
name: database-secret
key: DATABASE_USER
. . .
編集が終了したら、ファイルを保存して閉じます。 あなたと同じように secrets.yaml
ファイル、必ず使用して編集内容を検証してください kubectl
スペース、タブ、インデントに問題がないことを確認するには、次のようにします。
- kubectl create -f app-deployment.yaml --dry-run --validate=true
Outputdeployment.apps/app created (dry run)
次に、同じ値をに追加します database-deployment.yaml
ファイル。
編集用にファイルを開きます。
- nano database-deployment.yaml
このファイルでは、次の可変キーのシークレットへの参照を追加します。 POSTGRES_DB
, POSTGRES_USER
と POSTGRES_PASSWORD
. The postgres
imageはこれらの変数を使用可能にして、データベースインスタンスの初期化を変更できるようにします。 The POSTGRES_DB
コンテナの起動時に使用できるデフォルトのデータベースを作成します。 The POSTGRES_USER
と POSTGRES_PASSWORD
一緒に、作成されたデータベースにアクセスできる特権ユーザーを作成します。
これらの値を使用するということは、作成するユーザーがPostgreSQLでのそのロールのすべての管理特権と操作特権にアクセスできることを意味します。 本番環境で作業する場合は、適切なスコープの特権を持つ専用のアプリケーションユーザーを作成する必要があります。
下 POSTGRES_DB
, POSTGRES_USER
と POSTGRES_PASSWORD
変数、シークレット値への参照を追加します。
apiVersion: apps/v1
kind: Deployment
. . .
spec:
containers:
- env:
- name: PGDATA
value: /var/lib/postgresql/data/pgdata
- name: POSTGRES_DB
valueFrom:
secretKeyRef:
name: database-secret
key: POSTGRES_DB
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: database-secret
key: POSTGRES_PASSWORD
- name: POSTGRES_USER
valueFrom:
secretKeyRef:
name: database-secret
key: POSTGRES_USER
. . .
編集が終了したら、ファイルを保存して閉じます。 もう一度、編集したファイルを使用してリントするようにしてください kubectl
とともに --dry-run --validate=true
引数。
シークレットを設定したら、データベースサービスの作成に進み、アプリケーションコンテナが完全にセットアップされて初期化された後でのみ、データベースへの接続を試行するようにすることができます。
ステップ5—PersistentVolumeClaimを変更してアプリケーションフロントエンドを公開する
アプリケーションを実行する前に、データベースストレージが適切にプロビジョニングされ、LoadBalancerを使用してアプリケーションフロントエンドを公開できるようにするために、2つの最終的な変更を行います。
まず、変更しましょう storage
komposeが作成したPersistentVolumeClaimで定義されたresource。 このクレームにより、アプリケーションの状態を管理するために動的にストレージをプロビジョニングできます。
PersistentVolumeClaimsを使用するには、 StorageClass を作成し、ストレージリソースをプロビジョニングするように構成する必要があります。 この例では、 DigitalOcean Kubernetes を使用しているため、デフォルトのStorageClass provisioner
に設定されています dobs.csi.digitalocean.com
—DigitalOceanブロックストレージ。
これを確認するには、次のように入力します。
- kubectl get storageclass
DigitalOceanクラスターを使用している場合は、次の出力が表示されます。
OutputNAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
do-block-storage (default) dobs.csi.digitalocean.com Delete Immediate true 76m
DigitalOceanクラスターを使用していない場合は、StorageClassを作成し、 provisioner
お好みの。 これを行う方法の詳細については、公式ドキュメントを参照してください。
いつ kompose
作成した db-data-persistentvolumeclaim.yaml
、それは設定します storage
resource
私たちの最小サイズ要件を満たしていないサイズに provisioner
. したがって、最小実行可能DigitalOceanブロックストレージユニット:1GBを使用するように、PersistentVolumeClaimを変更する必要があります。 ストレージ要件に合わせて、これを自由に変更してください。
開ける db-data-persistentvolumeclaim.yaml
:
- nano db-data-persistentvolumeclaim.yaml
交換してください storage
の値 1Gi
:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
creationTimestamp: null
labels:
io.kompose.service: db-data
name: db-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
status: {}
また、 accessMode
: ReadWriteOnce
このクレームの結果としてプロビジョニングされたボリュームは、単一のノードによってのみ読み取り/書き込みが行われることを意味します。 さまざまなアクセスモードの詳細については、ドキュメントを参照してください。
終了したら、ファイルを保存して閉じます。
次に、開く app-service.yaml
:
- nano app-service.yaml
DigitalOcean Load Balancer を使用して、このサービスを外部に公開します。 DigitalOceanクラスターを使用していない場合、ロードバランサーについては、クラウドプロバイダーの関連ドキュメントを参照してください。 または、公式の Kubernetesドキュメントに従って、 kubeadm を使用した高可用性クラスターのセットアップを行うこともできますが、この場合、PersistentVolumeClaimsを使用してストレージをプロビジョニングすることはできません。
サービス仕様内で、 LoadBalancer
サービスとして type
:
apiVersion: v1
kind: Service
. . .
spec:
type: LoadBalancer
ports:
. . .
作成するとき app
サービス、ロードバランサーが自動的に作成され、アプリケーションにアクセスできる外部IPが提供されます。
編集が終了したら、ファイルを保存して閉じます。
すべてのファイルが揃ったら、アプリケーションを起動してテストする準備が整いました。
注:編集したKubernetesマニフェストを一連の参照ファイルと比較して、変更がこのチュートリアルと一致することを確認する場合は、コンパニオンGithubリポジトリに一連のテスト済みマニフェストが含まれます。 各ファイルを個別に比較することも、ローカルのgitブランチを切り替えて使用することもできます。 kubernetes-workflow
ブランチ。
ブランチを切り替えることを選択した場合は、必ずコピーしてください secrets.yaml
に追加してから、新しいチェックアウトバージョンにファイルを追加します .gitignore
チュートリアルの前半。
ステップ6—アプリケーションの起動とアクセス
Kubernetesオブジェクトを作成し、アプリケーションが期待どおりに機能していることをテストします。
定義したオブジェクトを作成するには、 kubectlcreateを使用します。 -f
フラグ。これにより、次のファイルを指定できます。 kompose
私たちが書いたファイルと一緒に、私たちのために作成されました。 次のコマンドを実行して、RailsアプリケーションとPostgreSQLデータベース、Redisキャッシュ、Sidekiqサービスとデプロイメントを、Secret、ConfigMap、およびPersistentVolumeClaimとともに作成します。
- kubectl create -f app-deployment.yaml,app-service.yaml,database-deployment.yaml,database-service.yaml,db-data-persistentvolumeclaim.yaml,env-configmap.yaml,redis-deployment.yaml,redis-service.yaml,secret.yaml,sidekiq-deployment.yaml
オブジェクトが作成されたことを示す次の出力が表示されます。
Outputdeployment.apps/app created
service/app created
deployment.apps/database created
service/database created
persistentvolumeclaim/db-data created
configmap/env created
deployment.apps/redis created
service/redis created
secret/database-secret created
deployment.apps/sidekiq created
ポッドが実行されていることを確認するには、次のように入力します。
- kubectl get pods
ここで名前空間を指定する必要はありません。これは、でオブジェクトを作成したためです。 default
名前空間。 複数の名前空間を使用している場合は、必ず -n
これを実行するときにフラグを立てる kubectl create
コマンドと、名前空間の名前。
次のような出力が表示されます。 database
コンテナが起動しています(ステータスは次のいずれかになります Pending
また ContainerCreating
):
OutputNAME READY STATUS RESTARTS AGE
app-854d645fb9-9hv7w 1/1 Running 0 23s
database-c77d55fbb-bmfm8 0/1 Pending 0 23s
redis-7d65467b4d-9hcxk 1/1 Running 0 23s
sidekiq-867f6c9c57-mcwks 1/1 Running 0 23s
データベースコンテナが開始されると、次のような出力が得られます。
OutputNAME READY STATUS RESTARTS AGE
app-854d645fb9-9hv7w 1/1 Running 0 30s
database-c77d55fbb-bmfm8 1/1 Running 0 30s
redis-7d65467b4d-9hcxk 1/1 Running 0 30s
sidekiq-867f6c9c57-mcwks 1/1 Running 0 30s
The Running
STATUS
ポッドがノードにバインドされており、それらのポッドに関連付けられているコンテナが実行されていることを示します。 READY
ポッド内で実行されているコンテナの数を示します。 詳細については、ポッドライフサイクルに関するドキュメントを参照してください。
注:予期しないフェーズが表示された場合 STATUS
列では、次のコマンドを使用してポッドのトラブルシューティングを行うことができることを忘れないでください。
- kubectl describe pods your_pod
- kubectl logs your_pod
アプリケーションが稼働しているので、必要な最後のステップはRailsのデータベース移行を実行することです。 この手順では、デモアプリケーションのPostgreSQLデータベースにスキーマをロードします。
保留中の移行を実行するには、 exec
実行中のアプリケーションポッドに移動し、 rake db:migrate
指図。
まず、次のコマンドを使用してアプリケーションポッドの名前を見つけます。
- kubectl get pods
次の出力で強調表示されているポッド名のように、アプリケーションに対応するポッドを見つけます。
OutputNAME READY STATUS RESTARTS AGE
app-854d645fb9-9hv7w 1/1 Running 0 30s
database-c77d55fbb-bmfm8 1/1 Running 0 30s
redis-7d65467b4d-9hcxk 1/1 Running 0 30s
sidekiq-867f6c9c57-mcwks 1/1 Running 0 30s
そのポッド名を書き留めて、これで実行できます kubectl exec
データベース移行ステップを完了するためのコマンド。
次のコマンドで移行を実行します。
- kubectl exec your_app_pod_name -- rake db:migrate
次のような出力が表示されます。これは、データベーススキーマがロードされたことを示しています。
Output== 20190927142853 CreateSharks: migrating =====================================
-- create_table(:sharks)
-> 0.0190s
== 20190927142853 CreateSharks: migrated (0.0208s) ============================
== 20190927143639 CreatePosts: migrating ======================================
-- create_table(:posts)
-> 0.0398s
== 20190927143639 CreatePosts: migrated (0.0421s) =============================
== 20191120132043 CreateEndangereds: migrating ================================
-- create_table(:endangereds)
-> 0.8359s
== 20191120132043 CreateEndangereds: migrated (0.8367s) =======================
コンテナが実行され、データが読み込まれると、アプリケーションにアクセスできるようになります。 のIPを取得するには app
LoadBalancer、タイプ:
- kubectl get svc
次のような出力が表示されます。
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
app LoadBalancer 10.245.73.142 your_lb_ip 3000:31186/TCP 21m
database ClusterIP 10.245.155.87 <none> 5432/TCP 21m
kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 21m
redis ClusterIP 10.245.119.67 <none> 6379/TCP 21m
The EXTERNAL_IP
に関連付けられている app
serviceは、アプリケーションにアクセスできるIPアドレスです。 あなたが見たら <pending>
のステータス EXTERNAL_IP
列の場合、これはロードバランサーがまだ作成中であることを意味します。
その列にIPが表示されたら、ブラウザでそのIPに移動します。 http://your_lb_ip:3000
.
次のランディングページが表示されます。
Get SharkInfoボタンをクリックします。 新しいサメを作成するためのボタンのあるページが表示されます。
それをクリックし、プロンプトが表示されたら、チュートリアルシリーズの前半のユーザー名とパスワードを入力します。 これらの値を変更しなかった場合、デフォルトは次のとおりです。 sammy
と shark
それぞれ。
フォームに、選択したサメを追加します。 実証するために、 Megalodon Shark
Shark Name フィールドに移動し、 Ancient
Shark Character フィールドへ:
送信ボタンをクリックします。 このサメの情報が表示されたページが表示されます。
これで、Kubernetesクラスターで実行されているPostgreSQLデータベースを使用したRailsアプリケーションのシングルインスタンスセットアップができました。 また、ユーザーが送信したデータを処理するためのRedisキャッシュとSidekiqワーカーもあります。
結論
このチュートリアルで作成したファイルは、本番環境に移行する際の出発点として適しています。 アプリケーションを開発するときに、次の実装に取り組むことができます。
- 一元化されたロギングとモニタリング。 一般的な概要については、Kubernetes用アプリケーションの最新化の関連するディスカッションを参照してください。 KubernetesでElasticsearch、Fluentd、Kibana(EFK)のログスタックを設定する方法を参照して、 Elasticsearch 、Fluentdでログスタックを設定する方法を学ぶこともできます。 、およびKibana。 Istio のようなサービスメッシュがこの機能を実装する方法については、サービスメッシュの概要も確認してください。
- トラフィックをクラスターにルーティングするための入力リソース。 これは、それぞれが独自のLoadBalancerを必要とする複数のサービスを実行している場合、またはアプリケーションレベルのルーティング戦略(A / Bおよびカナリアテストなど)を実装する場合に、LoadBalancerの優れた代替手段です。 詳細については、 DigitalOcean KubernetesでCert-Managerを使用してNginxIngressを設定する方法と、はじめにのサービスメッシュコンテキストでのルーティングに関する関連のディスカッションをご覧ください。サービスメッシュ。
- Kubernetesオブジェクトのバックアップ戦略。 DigitalOceanのKubernetes製品でVeleroを使用してバックアップを実装するためのガイダンスについては、Veleroを使用してDigitalOceanでKubernetesクラスタをバックアップおよび復元する方法を参照してください。