Skip to content

Latest commit

 

History

History
231 lines (163 loc) · 13.8 KB

README-ja.md

File metadata and controls

231 lines (163 loc) · 13.8 KB

マルチクラウド（アプリケーション）インフラストラクチャ

🌍 利用可能な言語: English | 中文 (Chinese) | 日本語 (Japanese)

注意: これは素晴らしいクラウドネイティブコミュニティの 🌟 コントリビューター によってもたらされました！

このステップバイステップのチュートリアルでは、Crossplaneを使用してアプリケーションサービスのためのRedis、PostgreSQL、Kafkaインスタンスをプロビジョニングします。

CrossplaneとCrossplane Compositionsを使用して、これらのコンポーネントのプロビジョニング方法を統一し、エンドユーザー（アプリケーションチーム）からこれらのコンポーネントの場所を隠蔽することを目指します。

アプリケーションチームは、他のKubernetesリソースと同様に、宣言的なアプローチでこれらのリソースを要求できるようにする必要があります。これにより、チームは環境パイプラインを使用して、アプリケーションサービスとアプリケーションが必要とするインフラストラクチャコンポーネントの両方を設定できます。

Crossplaneのインストール

Crossplaneをインストールするには、Kubernetesクラスターが必要です。第2章で行ったように、KinDを使用してクラスターを作成できます。

Crossplaneを独自の名前空間にHelmを使用してインストールしましょう：

helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update

helm install crossplane --namespace crossplane-system --create-namespace crossplane-stable/crossplane --version 1.15.0 --wait

次に、Crossplane Helmプロバイダーと、Helmプロバイダーが代わりにチャートをインストールできるようにするための新しいClusterRoleBindingをインストールします。

kubectl apply -f crossplane/helm-provider.yaml

数秒後、設定されたプロバイダーを確認すると、HelmがINSTALLEDおよびHEALTHYと表示されるはずです：

❯ kubectl get providers.pkg.crossplane.io
NAME            INSTALLED   HEALTHY   PACKAGE                                                    AGE
provider-helm   True        True      xpkg.upbound.io/crossplane-contrib/provider-helm:v0.17.0   49s

次に、Helmプロバイダーにクラスター内でチャートをインストールするためのin-cluster設定を使用するよう指示するProviderConfigを作成します。

kubectl apply -f crossplane/helm-provider-config.yaml

これで、アプリケーションが必要とするすべてのコンーネントを提供するために、データベースとメッセージブローカーのCrossplane compositionsをインストールする準備が整いました。

Crossplane Compositionsを使用したオンデマンドのアプリインフラストラクチャ

Key-Valueデータベース（Redis）、SQLデータベース（PostgreSQL）、メッセージブローカー（Kafka）のCrossplane Composite Resource Definitions (XRDs)をインストールする必要があります。

kubectl apply -f resources/definitions

次に、対応するCrossplane CompositionsとInitialization Dataをインストールします：

kubectl apply -f resources/compositions
kubectl apply -f resources/config

Crossplane Compositionリソース（app-database-redis.yaml）は、どのクラウドリソースを作成し、どのように一緒に設定する必要があるかを定義します。Crossplane Composite Resource Definition (XRD)（app-database-resource.yaml）は、アプリケーション開発チームがこのタイプのリソースを作成することで新しいデータベースをすぐに要求できるようにする簡略化されたインターフェースを定義します。

CompositionsとComposite Resource Definitions (XRDs)については、resources/ディレクトリを確認してください。

アプリケーションインフラストラクチャをプロビジョニングしましょう

次のコマンドを実行して、チームが使用する新しいKey-Valueデータベースをプロビジョニングできます：

kubectl apply -f my-db-keyvalue.yaml

my-db-keyvalue.yamlリソースは次のようになっています：

apiVersion: salaboy.com/v1alpha1
kind: Database
metadata:
  name: my-db-keyvalue
spec:
  compositionSelector:
    matchLabels:
      provider: local
      type: dev
      kind: keyvalue
  parameters: 
    size: small

provider: local、type: dev、kind: keyvalueいうラベルを使用していることに注意してください。これにより、Crossplaneはラベルに基づいて適切なcompositionを見つけることができます。この場合、HelmプロバイダーはローカルのRedisインスタンスを作成しました。

次のコマンドを使用してデータベースのステータスを確認できます：

> kubectl get dbs
NAME              SIZE    MOCKDATA   KIND       SYNCED   READY   COMPOSITION                     AGE
my-db-keyavalue   small   false      keyvalue   True     True    keyvalue.db.local.salaboy.com   97s

default名前空間に新しいRedisインスタンスが作成されたことを確認できます。

同じ手順に従って、次のコマンドを実行してPostgreSQLデータベースをプロビジョニングできます：

kubectl apply -f my-db-sql.yaml

これで2つのdbsが表示されるはずです：

> kubectl get dbs
NAME              SIZE    MOCKDATA   KIND       SYNCED   READY   COMPOSITION                     AGE
my-db-keyavalue   small   false      keyvalue   True     True    keyvalue.db.local.salaboy.com   2m
my-db-sql         small   false      sql        True     False   sql.db.local.salaboy.com        5s

各データベースに対して1つずつ、2つのPodが実行されていることを確認できます：

> kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
my-db-keyavalue-redis-master-0   1/1     Running   0          3m40s
my-db-sql-postgresql-0           1/1     Running   0          104s

4つのKubernetesシークレット（2つのhelmリリース用と2つの新しく作成されたインスタンスに接続するための認証情報を含む）があるはずです：

> kubectl get secret
NAME                                    TYPE                 DATA   AGE
my-db-keyavalue-redis                   Opaque               1      2m32s
my-db-sql-postgresql                    Opaque               1      36s
sh.helm.release.v1.my-db-keyavalue.v1   helm.sh/release.v1   1      2m32s
sh.helm.release.v1.my-db-sql.v1         helm.sh/release.v1   1      36s

同様に、Kafkaメッセージブローカーの新しいインスタンスをプロビジョニングできます：

kubectl apply -f my-messagebroker-kafka.yaml

そして、次のコマンドで一覧表示できます：

> kubectl get mbs
NAME          SIZE    KIND    SYNCED   READY   COMPOSITION                  AGE
my-mb-kafka   small   kafka   True     True    kafka.mb.local.salaboy.com   2m51s

Kafkaはデフォルト設定を使用する場合、シークレットを作成する必要はありません。

3つの実行中のポッド（Kafka用、Redis用、PostgreSQL用）が表示されるはずです。

> kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
my-db-keyavalue-redis-master-0   1/1     Running   0          113s
my-db-sql-postgresql-0           1/1     Running   0          108s
my-mb-kafka-0                    1/1     Running   0          100s

注意: 同じリソース名を使用してデータベースやメッセージブローカーを削除して再作成する場合は、PersistentVolumeClaimsを削除することを忘れないでください。これらのリソースは、DatabaseやMessageBrokerリソースを削除しても削除されません。

これで、クラスターリソースが処理できる数だけ、データベースやメッセージブローカーのインスタンスを作成できます！

カンファレンスアプリケーションをデプロイしましょう

さて、2つのデータベースとメッセージブローカーが実行されているので、アプリケーションサービスがこれらのインスタンスに接続されていることを確認する必要があります。まず、Conference ApplicationチャートでHelmの依存関係を無効にし、アプリケーションがインストールされるときにデータベースとメッセージブローカーがインストールされないようにする必要があります。これは、install.infrastructureフラグをfalseに設定することで実現できます。

そのために、新しく作成したデータベースに接続するためのサービスの設定を含むapp-values.yamlファイルを使用します：

helm install conference oci://registry-1.docker.io/salaboy/conference-app --version v1.0.0 -f app-values.yaml

app-values.yamlの内容は次のようになります：

install:
  infrastructure: false
frontend:
  kafka:
    url: my-mb-kafka.default.svc.cluster.local
agenda:
  kafka:
    url: my-mb-kafka.default.svc.cluster.local
  redis: 
    host: my-db-keyavalue-redis-master.default.svc.cluster.local
    secretName: my-db-keyavalue-redis
c4p: 
  kafka:
    url: my-mb-kafka.default.svc.cluster.local
  postgresql:
    host: my-db-sql-postgresql.default.svc.cluster.local
    secretName: my-db-sql-postgresql
notifications: 
  kafka:
    url: my-mb-kafka.default.svc.cluster.local

app-values.yamlファイルが、例示ファイルで指定したデータベース（my-db-keyavalueとmy-db-sql）とメッセージブローカー（my-mb-kafka）の名前に依存していることに注意してください。異なる名前で他のデータベースとメッセージブローカーを要求した場合は、このファイルを新しい名前で適応させる必要があります。

アプリケーションポッドが起動すると、ブラウザでhttp://localhost:8080にアクセスしてアプリケーションにアクセスできるはずです。 ここまでたどり着いた場合、Crossplane Compositionsを使用してマルチクラウドインフラストラクチャをプロビジョニングできるようになりました。@asarenkansahによって貢献されAWS Crossplane Compositions Tutorialをチェックしてください。アプリケーションインフラストラクチャのプロビジョニングをアプリケーションコードから分離することで、クラウドプロバイダー間のポータビリティを可能にするだけでなく、アプリケーションサービスをプラットフォームチームが管理できるインフラストラクチャと接続できるようになります。

クリーンアップ

このチュートリアル用に作成したKinDクラスターを削除したい場合は、次のコマンドを実行できます：

kind delete clusters dev

次のステップ

Google Cloud Platform、Microsoft Azure、Amazon AWSなどのクラウドプロバイダーにアクセスできる場合は、これらのプラットフォーム用のCrossplaneプロバイダーを強くお勧めします。これらのプロバイダーをインストールし、Crossplane Helmプロイダーを使用する代わりにクラウドリソースをプロビジョニングすることで、これらのツールがどのように機能するかについての実際の経験を得ることができます。

第5章で言及したように、マネージドサービスとして提供されていないインフラストラクチャコンポーネントを必要とするサービスをどのように扱いますか？ Google Cloud Platformの場合、プロビジョニングできるマネージドKafkaサービスは提供していません。HelmチャートまたはVMを使用してKafkaをインストールするか、KafkaをGoogle PubSubなどのマネージドサービスに切り替えますか？同じサービスの2つのバージョンを維持しますか？

まとめと貢献

このチュートリアルでは、アプリケーションインフラストラクチャのプロビジョニングをアプリケーションのデプロイメントから分離することに成功しました。これにより、異なるチームがオンデマンドでリソースを要求し（Crossplane compositionsを使用）、独立して進化できるアプリケーションサービスを提供できるようになります。

開発目的でHelmチャートの依存関係を使用し、アプリケーションの完全に機能するインスタンスをすぐに稼働させることは素晴らしいです。より重要な環境では、ここで示したようなアプローチを採用したいかもしれません。このアプローチでは、各サービスが必要とするコンポーネントとアプリケーションを接続する複数の方法があります。

このチュートリアルを改善したいですか？issueを作成するか、Twitterでメッセージを送るか、プルリクエストを送信してください。