2024年7月23日 【Google Cloud】第2回:Apigee ハイブリッドでAPIをデプロイしてみた~Helmでインストール・デプロイ編~ Apigee GKE Google Cloud 検索する Popular tags 生成AI(Generative AI) Looker Studio BigQuery AlloyDB Google Workspace 事例紹介 Cloud SQL Category Google Cloud Author Google Cloud研究開発チーム SHARE 目次 Apigeeハイブリッドを構築するためのインストールツールについて Helmとは Helmを利用したApigee ハイブリッドのインストール APIのデプロイ まとめ Content 「Apigee ハイブリッドでAPIをデプロイしてみた」の記事シリーズの第2回になります。 本記事では、Helmを利用したApigee ハイブリッドのインストールとAPIのデプロイについて、ご紹介します。 【Google Cloud】第1回:Apigee ハイブリッドでAPIをデプロイしてみた~概要・GKE構築編~ 【Google Cloud】第2回:Apigee ハイブリッドでAPIをデプロイしてみた~Helmでインストール・デプロイ編~ ★本記事 Apigeeハイブリッドを構築するためのインストールツールについて Apigeeハイブリッドを構築するためにはインストールツールを使用する必要があります。 以下2つがインストールツールとなります。 ・Helm ・apigeectl apigeectlについては、Apigee ハイブリッド バージョン 1.12 から非推奨となりました。 参考リンク 新規でApigeeハイブリッドを構築する場合はHelmを使用することが推奨されています。 Helmとは Helmは、kubernetes環境におけるパッケージマネージャとして広く利用されるツールです。 個別のコンテナイメージをデプロイする方法とは異なり、Helmチャートと呼ばれるテンプレートを用いて、アプリケーションに必要なコンポーネントをまとめてデプロイ・管理することが可能です。 Helmを利用したApigee ハイブリッドのインストール 管理ワークステーションから以下のステップでApigee ハイブリッドをインストールしていきます。 前提 ・構築を行うVMwareや管理ワークステーションについては、こちらの記事をご覧ください ・「パート1:プロジェクトと組織を設定する」の設定が完了していること ・Apigee ハイブリッド バージョン 1.11を使用して構築を実施 ・Helm バージョン 3.15を使用して構築を実施 (Helm バージョン 3.10 以上が必須条件) Helm チャートをダウンロード ・Helmのインストールを実施する curl -LO https://get.helm.sh/helm-v3.15.0-linux-amd64.tar.gz tar zxvf helm-v3.15.0-linux-amd64.tar.gz ・作業で必要なディレクトリ構成の準備する (今回は~/apigee-hybrid/helm-chartsとしているが、任意のディレクトリ名で良い) mkdir -p apigee-hybrid/helm-charts cd apigee-hybrid/helm-charts/ export APIGEE_HELM_CHARTS_HOME=$PWD echo $APIGEE_HELM_CHARTS_HOME ・Helm チャートをローカルのストレージにコピーする export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts export CHART_VERSION=1.11.1 helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar apigee 名前空間の作成 ・Apigeeハイブリッドの作業を行うスペースの作成する(NAMESPACEは任意の名前を設定する)/ kubectl create namespace NAMESPACE サービスアカウントの作成 ・サービスアカウントの作成を行う。作成する環境に合わせてコマンドを変更してください 本記事では検証目的のため、非本番環境用のサービスアカウントを作成する 本番環境の場合は、コンポーネントごとにサービスアカウントを作成することが推奨されているため、公式ドキュメントをご参照ください。 $APIGEE_HELM_CHARTS_HOME/apigee-operator/etc/tools/create-service-account \ --env non-prod \ --dir $APIGEE_HELM_CHARTS_HOME/apigee-datastore ・サービスアカウントを参照する必要のある他のディレクトリにサービスアカウントをコピーする 以下コマンド内のmy_project_id-apigee-non-prod.jsonは、ご自身の環境で発行されたファイルに置き換えてください。 cp $APIGEE_HELM_CHARTS_HOME/apigee-datastore/my_project_id-apigee-non-prod.json $APIGEE_HELM_CHARTS_HOME/apigee-telemetry/ cp $APIGEE_HELM_CHARTS_HOME/apigee-datastore/my_project_id-apigee-non-prod.json $APIGEE_HELM_CHARTS_HOME/apigee-org/ cp $APIGEE_HELM_CHARTS_HOME/apigee-datastore/my_project_id-apigee-non-prod.json $APIGEE_HELM_CHARTS_HOME/apigee-env/ TLS証明書の作成 ・本記事では、検証目的のため、自己証明書を作成する 本番環境では、第三者機関で署名された正規の証明書を利用してください。 以下コマンド内のドメイン名「helm.example.com」は、ご自身の環境に置き換えてください。 検証目的のため、証明書の期限は任意です (本記事では1年で作成する例です) openssl req -nodes -new -x509 -keyout $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/certs/keystore.key -out APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/certs/keystore.pem -subj '/CN='helm.example.com'' -days 365 オーバーライドの作成 ・オーバーライド用のyamlファイルを作成する 構成する環境によりyamlファイルの中身が異なります。本記事では、検証目的のため、非本番環境用の設定例を記載しております。 本番環境用やWorkload Identityを利用する場合は、公式ドキュメントをご参照ください。 vi $APIGEE_HELM_CHARTS_HOME/overrides.yaml ▶yamlファイルを表示する◀ instanceID: "INSTANCE_ID" ## インスタンスID namespace: NAMESPACE ## namespace gcp: projectID: PROJECT_ID ## プロジェクトID region: REGION ## リージョン k8sCluster: name: USER_CLUSTER_NAME ## ユーザークラスター名 region: REGION ## リージョン org: ORG_NAME ## Apigee ハイブリッド組織のID envs: - name: ENVIRONMENT_NAME ## 環境グループ名 serviceAccountPaths: # Provide the path relative to the chart directory. synchronizer: NON_PROD_SERVICE_ACCOUNT_FILEPATH ## サービスアカウントのパス # For example: "PROJECT_ID-apigee-non-prod.json" runtime: NON_PROD_SERVICE_ACCOUNT_FILEPATH ## サービスアカウントのパス # For example: "PROJECT_ID-apigee-non-prod.json" udca: NON_PROD_SERVICE_ACCOUNT_FILEPATH ## サービスアカウントのパス # For example: "PROJECT_ID-apigee-non-prod.json" cassandra: hostNetwork: false # Set to false for single region installations and multi-region installations # with connectivity between pods in different clusters, for example GKE installations. # Set to true for multi-region installations with no communication between # pods in different clusters, for example GKE On-prem, GKE on AWS, Anthos on bare metal, # AKS, EKS, and OpenShift installations. # See Multi-region deployment: Prerequisites replicaCount: 1 # Use 1 for non-prod or "demo" installations and multiples of 3 for production. # See Configure Cassandra for production for guidelines. ingressGateways: - name: INGRESS_NAME ## Apigee Ingressゲートウェイ名 replicaCountMax: 10 # svcAnnotations: # optional. If you are on AKS, see Known issue #260772383 # SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE virtualhosts: - name: ENVIRONMENT_GROUP_NAME ## 環境グループ名 selector: app: apigee-ingressgateway ingress_name: INGRESS_NAME ## Apigee Ingressゲートウェイ名 sslCertPath: PATH_TO_CERT_FILE ## 生成した自己署名証明書ファイルのパス sslKeyPath: PATH_TO_KEY_FILE ## 生成した自己署名 TLS 鍵のパス mart: serviceAccountPath: NON_PROD_SERVICE_ACCOUNT_FILEPATH ## サービスアカウントのパス # Provide the path relative to the chart directory. # For example: "PROJECT_ID-apigee-non-prod.json" connectAgent: serviceAccountPath: NON_PROD_SERVICE_ACCOUNT_FILEPATH ## サービスアカウントのパス # Provide the path relative to the chart directory. # Use the same service account for mart and connectAgent # For example: "PROJECT_ID-apigee-non-prod.json" logger: enabled: true # enabled by default # See apigee-logger in Service accounts and roles used by hybrid components. serviceAccountPath: NON_PROD_SERVICE_ACCOUNT_FILEPATH ## サービスアカウントのパス # Provide the path relative to the chart directory. # For example: "PROJECT_ID-apigee-non-prod.json" metrics: serviceAccountPath: NON_PROD_SERVICE_ACCOUNT_FILEPATH ## サービスアカウントのパス # Provide the path relative to the chart directory. # For example: "PROJECT_ID-apigee-non-prod.json" udca: serviceAccountPath: NON_PROD_SERVICE_ACCOUNT_FILEPATH ## サービスアカウントのパス # Provide the path relative to the chart directory. # For example: "PROJECT_ID-apigee-non-prod.json" watcher: serviceAccountPath: NON_PROD_SERVICE_ACCOUNT_FILEPATH ## サービスアカウントのパス # Provide the path relative to the chart directory. # For example: "PROJECT_ID-apigee-non-prod.json" Synchronizer アクセスの有効化 ・Google Cloudユーザーアカウントに「roles/apigee.admin」が割り当てられているか確認する gcloud projects get-iam-policy ${PROJECT_ID} \ --flatten="bindings[].members" \ --format='table(bindings.role)' \ --filter="bindings.members:your_account_email" ・権限がない場合は以下コマンドで権限を付与する gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member user:your_account_email \ --role roles/apigee.admin ・gcloud認証情報の取得する export TOKEN=$(gcloud auth print-access-token) echo $TOKEN ・Synchronizerアクセスを有効にする gcloud iam service-accounts list --project ${PROJECT_ID} --filter "apigee-synchronizer" ・Synchronizerに必要な権限の有効化する curl -X POST -H "Authorization: Bearer ${TOKEN}" \ -H "Content-Type:application/json" \ "https://apigee.googleapis.com/v1/organizations/${ORG_NAME}:setSyncAuthorization" \ -d '{"identities":["'"serviceAccount:apigee-synchronizer@${ORG_NAME}.iam.gserviceaccount.com"'"]}' ・APIを呼び出し、サービスアカウントのリストを取得する curl -X GET -H "Authorization: Bearer $TOKEN" \ -H "Content-Type:application/json" \ "https://apigee.googleapis.com/v1/organizations/${ORG_NAME}:getSyncAuthorization" >> { >> "identities": [ >> "serviceAccount:apigee-non-prod@sts-am-rd.iam.gserviceaccount.com" >> ], >> "etag": "BwYZGy9Z5HI=" >> } cert-manager のインストール ・Anthos オンプレミス -(VMware)では不要なため未実施 参考リンク Apigee ハイブリッド CRD のインストール ・ドライランを実行する kubectl apply -k apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run=server ・インストールを実行する kubectl apply -k apigee-operator/etc/crds/default/ \ --server-side \ --force-conflicts \ --validate=false クラスタの準備状況を確認 ・kubectlのコンテキストを確認する kubectl config current-context ・出力されてた内容が今回インストールしているユーザークラスター名と一致しない場合、以下コマンドでコンテキストを設定する gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_LOCATION \ --project $PROJECT_ID ・cluster-checkディレクトリの作成 mkdir $APIGEE_HELM_CHARTS_HOME/cluster-check ・apigee-k8s-cluster-ready-check.yamlを作成する vi $APIGEE_HELM_CHARTS_HOME/cluster-check/apigee-k8s-cluster-ready-check.yaml ▶yamlファイルを表示する◀ apiVersion: v1 kind: ServiceAccount metadata: name: apigee-k8s-cluster-ready-check --- apiVersion: batch/v1 kind: Job metadata: name: apigee-k8s-cluster-ready-check spec: template: spec: hostNetwork: true serviceAccountName: apigee-k8s-cluster-ready-check containers: - name: manager image: gcr.io/apigee-release/hybrid/apigee-operators:1.11.1 command: - /manager args: - --k8s-cluster-ready-check env: - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP securityContext: runAsGroup: 998 runAsNonRoot: true runAsUser: 999 restartPolicy: Nev ・テストを実行する kubectl apply -f $APIGEE_HELM_CHARTS_HOME/cluster-check/apigee-k8s-cluster-ready-check.yaml ・Kubernetes Job のステータスを確認する kubectl get pods | grep apigee-k8s-cluster-ready-check >> apigee-k8s-cluster-ready-check-62ltd 0/1 Error 0 54s >> apigee-k8s-cluster-ready-check-qcthq 0/1 Error 0 74s 本記事のように、Errorとなった場合は、PodのKubernetesログを確認して原因を特定してください。 kubectl logs apigee-k8s-cluster-ready-check-62ltd >> {"level":"error","ts":1716455313.7790627,"caller":"clusterreadycheck/check.go:88","msg":"Name: Cassandra DNS Check, TroubleShooting link: https://link-to-troubleshooting, Error: DNS resolution was successful but IP doesn't match POD IP","controller":"PreInstallCheck","stacktrace":"edge-internal.git.corp.google.com/k8s-controllers.git/provisioning/controllers/clusterreadycheck.Verify\n\t/go/src/edge-internal/k8s-controllers/provisioning/controllers/clusterreadycheck/check.go:88\nmain.main\n\t/go/src/edge-internal/k8s-controllers/provisioning/main.go:241\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:267"} ログにて「Error: DNS resolution was successful but IP doesn’t match POD IP」が出力されており、シングルリージョンで構築を進めているため、今回のケースは無視して問題ない内容 (参考リンク) ・クリーンアップする kubectl delete -f $APIGEE_HELM_CHARTS_HOME/cluster-check/apigee-k8s-cluster-ready-check.yaml Apigee ハイブリッド のインストール ・以下コンポーネントをインストールしてい ・Apigee オペレーター(値1:operator 値2:apigee-operator NAMESPACE:apigee-system) ・Apigee データストア(値1:datastore 値2:apigee-datastore NAMESPACE:apigee) ・Apigee テレメトリー(値1:telemetry 値2:apigee-telemetry NAMESPACE:apigee) ・Apigee Redis(値1:redis 値2:apigee-redis NAMESPACE:apigee) ・Apigee Ingress Manager(値1:”ORG_NAME” 値2:apigee-org NAMESPACE:apigee) ・Apigee 組織(値1:”ENV_NAME” 値2:apigee-env NAMESPACE:apigee) ※コマンドに—set env=ENV_NAMEを追加 ・Apigee 環境(値1:”ENV_GROUP_NAME” 値2:apigee-virtualhost NAMESPACE:apigee) ※コマンドに—set envgroup=ENV_GROUP_NAMEを追加 ・ドライランを実行する helm upgrade 値1 値2/ \ --install \ --namespace NAMESPACE \ --atomic \ -f overrides.yaml \ --dry-run ・インストールを実行する helm upgrade 値1 値2/ \ --install \ --namespace NAMESPACE \ --atomic \ -f overrides.yaml APIのデプロイ Google CloudからAPIをデプロイし呼び出してみる 今回は検証目的のため、デフォルトのKubernetes Serviceを使用して確認しますが、本番環境の場合は、公式ドキュメントを参照し、独自のKubernetes Serviceを作成することを推奨します.。 Apigee IngressサービスのIPを確認 ・Apigee Ingressサービスの外部IPを確認する kubectl get svc -n apigee -l app=apigee-ingressgateway >> NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE >> ingressgateway_name LoadBalancer xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx 15021:31971/TCP,443:32696/TCP 14h ヘルスチェック ・先ほど確認したApigee Ingressサービスの外部IPを使用してヘルスチェックを実行 curl -H 'User-Agent: GoogleHC/' https://helm.example.com/healthz/ingress -k --resolve "helm.example.com:443:xxx.xxx.xxx.xxx" >> Apigee Ingress is healthy APIプロキシをデプロイ ・Google CLoud上からtest用のAPIをプロキシを作成する。 Proxy nameは任意の名前 Base Pathは、URLのパスとなるものを入力 Targetは、APIの実態となるターゲットのエンドポイントを入力 ・APIが作成された。 ・デプロイしたいApigee環境を指定してAPIをデプロイする。 Environmentはご自身の環境に合わせてご選択ください。 本番環境用や検証環境用などの用途に合わせてご用意いただくと良いと思います。 ・APIがデプロイされた。 APIプロキシの呼び出し ・管理ワークステーションからデプロイしたAPIを呼び出す curl -H Host:helm.example.com --resolve helm.example.com:$INGRESS_PORT:192.168.100.183 https://helm.example.com:443/myproxy -k >> Hello, Guest! ・Apigeeを構築したVMからAPIを呼び出す まとめ 本記事では、Helmを利用してApigee ハイブリッドのインストールとAPIのデプロイについて、ご紹介いたしました。 Kubernetesを既にご利用の方については、馴染みのあるHelmが利用が可能なことと思います。 Helmの利用が推奨されているため、本記事の手順がご参考になれば幸いです。 関連コンテンツ 【Google Cloud】第1回:Apigee ハイブリッドでAPIをデプロイしてみた~概要・GKE構築編~ by Google Cloud研究開発チームon 2024年7月23日 頂きましたご意見につきましては、今後のより良い商品開発・サービス改善に活かしていきたいと考えております。 よくわかった 実際につかってみたい よくわからなかった APIの運用管理で困っている Author Google Cloud研究開発チーム 株式会社システムサポート(STS)のGoogle Cloud研究開発チームです。 実際に技術検証した事例を中心に記事発信していきます。 Apigee GKE Google Cloud 2024年7月23日 【Google Cloud】第2回:Apigee ハイブリッドでAPIをデプロイしてみた~Helmでインストール・デプロイ編~ Category Google Cloud 前の記事を読む 【Google Cloud】第1回:Apigee ハイブリッドでAPIをデプロイしてみた~概要・GKE構築編~ 次の記事を読む 【Google Cloud】第1回:GKE on VMwareを構築してみた~概要編~ Recommendation オススメ記事 2023年9月5日 Google Cloud 【Google Cloud】Looker Studio × Looker Studio Pro × Looker を徹底比較!機能・選び方を解説 2023年8月24日 Google Cloud 【Google Cloud】Migrate for Anthos and GKEでVMを移行してみた(1:概要編) 2022年10月10日 Google Cloud 【Google Cloud】AlloyDB と Cloud SQL を徹底比較してみた!!(第1回:AlloyDB の概要、性能検証編) BigQuery ML ワークショップ開催のお知らせ 生成AI導入支援パッケージ Discovery AI導入支援パッケージ Google Cloud ホワイトペーパー 新着記事 2024年9月2日 4koma 【4コマ漫画】SEひつじは定時退社の夢を見る ~ダウングレード~ 2024年8月29日 Google Cloud 【Google Cloud】Cloud NGFW Standard を試してみた 2024年8月29日 Google Cloud 【Google Cloud】Cloud Storage FUSE Read Cache を試してみた HOME Google Cloud 【Google Cloud】第2回:Apigee ハイブリッドでAPIをデプロイしてみた~Helmでインストール・デプロイ編~ ご意見・ご相談・料金のお見積もりなど、お気軽にお問い合わせください。 お問い合わせはこちら HOME Categories お知らせ イベント・セミナー Google Cloud Google Workspace モバイル インフラ 技術開発 ブログ 4koma Tags 生成AI(Generative AI) Looker Studio BigQuery AlloyDB Google Workspace 事例紹介 Cloud SQL STSエンジニアリングマガジン 「サイタル」