Kyma runtimeのCommunity Code Challengeをやってみた - Week1

この記事は chillSAP 夏の自由研究2022、8/3の記事として執筆しています。

はじめに

SAP Community Code Challengeとは、ある技術トピックについて週ごとに課題が出され、参加者は課題を実施した結果をSAP Communityにあるグループのスレッドに投稿する、というものです。その技術を知ってもらう、触ってもらうことを目的としている（と思われる）ため、内容は比較的簡単になっています。参加申し込みは不要で、週ごとの課題も締め切りがあるわけではないので、気軽に参加することができます。最近では以下のCommunity Code Challengeが実施されています。

• SAP Community Code Challenge – Testing UI5 Apps with wdi5: wdi5というUI5のテストフレームワークを使ってみる
• SAP Community Code Challenge – Let’s set sail for Cloud Native Island! : Kyma runtimeを使ってCloud Nativeな開発に触れてみる

この記事では、Kyma runtimeのCode Challengeに参加して、開発の方法やその裏の仕組みについてわかったことをまとめていきます。私はこれまでKyma runtimeでの開発はしたことがなく、Cloud Founeryとの共通点や違いについて気になっていました。Code Challengeで実際に触ってみることで、そのあたりの感覚がつかめればよいなと思います。

Kyma runtimeのCode Challenge情報

• ブログ ⇒ SAP Community Code Challenge – Let’s set sail for Cloud Native Island!
• 週ごとの課題 ⇒ SAP Community Code Challenge Cloud Native - Challenges
• スレッド ⇒ SAP Community Code Challenge - Let's set sail for Cloud Native Island!

シリーズの記事

• Kyma runtimeのCommunity Code Challengeをやってみた - Week1 （この記事）
• Kyma runtimeのCommunity Code Challengeをやってみた - Week2 （デプロイの方法）
• Kyma runtimeのCommunity Code Challengeをやってみた - Week3 （認証の設定）
• Kyma runtimeのCommunity Code Challengeをやってみた - Week4 （Horizontal Autoscaler）

Week1の課題

この記事ではWeek1の課題について見ていきます。課題の内容はこちらに書かれていますが、以下のようになっています。

1. Youtubeで2 Minutes of Cloud Nativeシリーズを見て、Kubernatesの概要を知る
2. BTPのFree Tierアカウントを取得する（trialアカウントでも問題なくできました）
3. Kyma runtimeを有効化する
4. SAP-samples/sap-community-code-challenge-cloud-nativeのリポジトリをフォークし、自分のローカルにクローンして実行してみる
5. GitHub Container RegistryからDockerイメージを取得するための認証情報を設定したシークレットを作成する
6. サービスをBTPのKyma runtimeにデプロイして実行する

上記を実施したあと、デプロイされたサービスとサービスのURLをCode Challengeのスレッドに投稿することがWeek1のミッションとなっています。

Week1で学んだこと

Week1の課題を通して学んだのは以下のようなことです。

1. Kyma runtimeへのデプロイの仕組み

Cloud FoundryへのデプロイとKyma runtimeへのデプロイを図に表してみました。

Cloud Foundryへのデプロイ

MTAの仕組みを使ってCloud Foundryにデプロイする場合、mta.yamlに設定を書いてビルドします。mta.yamlは自分のローカルにあるプロジェクトを参照します。ビルドの結果、アプリケーションのコンテンツを含んだ.mtarファイルができます。.mtarファイルをCloud Foundryのスペースにデプロイします。

Kyma runtimeへのデプロイ

Kyma runtimeへのデプロイの場合、まずDockerfileを作成し、実行環境の設定をするとともにローカルにあるプロジェクトをコピーして実行環境に入れます。Dockerfileを使用して作成するDockerイメージをDocker HubやGitHubのPackage registryにプッシュします。デプロイはdeployment.yamlファイルを使用して行います。deployment.yamlファイルにDocker HubやGitHub registryにあるDockerイメージを指定します。デプロイ時にKyma runtimeが指定されたレジストリからイメージを引っ張ってきて実行環境を作成します。

Cloud FouneryへのデプロイとKyma runtimeへのデプロイの大きな違いは、Cloud Founeryへのデプロイではアプリケーションコンテンツのみデプロイするのに対し、Kyma runtimeの場合はDockerイメージを使用して実行環境も含めて指定するという点だと思いました。Cloud Foundryの場合、実行環境はBuildpackというものが用意されており、mta.yamlの中でbuildpackを指定するだけでした。

mta.yamlでのBuildpackの指定

 - name: sample-srv
   type: nodejs
   path: gen/srv
   parameters:
     buildpack: nodejs_buildpack

Week1の課題では、最初にCode ChallengeのGitリポジトリをローカルにクローンして、そこからデプロイを行っていたので、始めはローカルのプロジェクトの内容がデプロイされているのかと思っていました。しかし、実際はdeployment.yamlの中で以下のようにsap-samples/sap-community-code-challenge-cloud-native:latestにあるイメージを指定しており、このイメージを引っ張ってきてデプロイしているのでした。

deployment.yaml

      containers:
      - name: hello-community
        image: ghcr.io/sap-samples/sap-community-code-challenge-cloud-native:latest

2. シークレットの作成の目的

ステップ5で以下のコマンドを実行し、regcredという名前のシークレットを作成します（名前は任意）。これは、デプロイ時にKymaがGitHub registryからイメージを引っ張れるようにするためです。なお、Dockerイメージがパブリックなレジストリに存在する場合は、シークレットは不要です。

kubectl create secret docker-registry regcred \
  --namespace <k8s-namespace> \
  --docker-server=ghcr.io \
  --docker-email=<github-email-address> \
  --docker-username=<github-username> \
  --docker-password=<github-personal-access-token>

作成したシークレットはBTPのKymaコンソールで見られるようになっています。

deployment.yamlファイルでimagePullSecretsにシークレットを指定することで、そのシークレットを使用することができます。なお、以下をコメントアウトしてみてもデプロイは可能でした。さらにKyma側でregcredを削除してもデプロイ可能でした。今回使用したイメージがパブリックなものだったため、シークレットは実際には不要だったのかなと思いました。

      imagePullSecrets:
      - name: regcred

参考

• Concepts/Configuration/Secrets/Container image pull secrets
• Containers/Images/Use Cases

3. oidc-loginのインストール（kubectlのプラグインの仕組み）

シークレットの作成やデプロイの際にはKyma runtimeへの認証が必要になります。oidc-loginというkubectlのプラグインをインストールすると、認証が必要なタイミングでブラウザが開き、BTPのユーザ、パスワードを入力して認証を行うことができます。私はプラグインのインストールでつまづいて、kubectlのプラグインの仕組みについて調べたのでここに残しておきます。

何がうまくいかなかったか

odic-loginのインストールについて、こちらのチュートリアルに以下の説明があります。

On Windows, it is recommended to use the release binaries to install the kubectl oidc-login plugin. The installation of the kubectl oidc-login plugin using Chocolatey and Krew could cause issues.

Windowsの場合、krewおよびChocolateyを使ったインストールができるとされているのですが、この方法だと問題が起きるので、チュートリアルではバイナリを使ってインストールすることが推奨されています。ただ、バイナリを使ったインストールの方法がよくわからなかったため、私はChocolateyでインストールしました。すると、kubectl create secretでシークレットを作成する際にodic-loginのプラグインが見つからないというエラーが出ました。

原因

kubectlはkubectl-で始まる実行ファイルをプラグインとして認識します。以下のコマンドでインストールされているプラグインを一覧で見ることができます。

kubectl plugin list

Chocolateyでインストールした場合、chocolatey\bin\の配下に実行ファイルが格納されます。この際にファイル名がkubeloginとなっておりkubectl-始まりでないため、プラグインとして認識されていない状態でした。

参考：Discovering plugins

対応

ファイル名をkubectl-odic-login.exeに書き換えました。

結果、プラグインの一覧に出てくるようになり、シークレットの作成も成功しました。

The following compatible plugins are available:

C:\ProgramData\chocolatey\bin\kubectl-convert.exe
C:\ProgramData\chocolatey\bin\kubectl-oidc_login.exe

参考

以下のブログがKymaへのデプロイの仕組みを理解するのに役立ちました。
Kyma for Dymmies: First Simple App in SAP Cloud Platform, Kyma runtime