GitHub Actions を使った Azure Kubernetes Service (AKS) へのコンテナーのビルド、テスト、デプロイ
GitHub アクションを使用すると、自動化されたソフトウェア開発ライフサイクル ワークフローを柔軟に構築できます。 複数の Kubernetes アクションを使うと、GitHub Actions を使って Azure Container Registry (ACR) から Azure Kubernetes Service (AKS) へコンテナーをデプロイできます。
前提条件
- アクティブなサブスクリプションが含まれる Azure アカウント。 お持ちでない場合は、無料のアカウントを作成してください。
- GitHub アカウント。 お持ちでない場合は、無料でサインアップしてください。
- GitHub Actions を使用する場合は、Azure と GitHub リポジトリの間の統合を構成する必要があります。 統合を構成するには、「GitHub Actions を使用して Azure に接続する」を参照してください。
- ACR がアタッチされている既存の AKS クラスター。 お持ちでない場合は、「Azure Kubernetes Service (AKS) から Azure Container Registry (ACR) の認証を受ける」を参照してください。
AKS 向けの GitHub Actions
GitHub Actions を使うと、GitHub 内からソフトウェア開発ワークフローを自動化できます。 詳細については、Azure 向けの GitHub Actions に関する記事を参照してください。
次の表は、AKS に使うことができるアクションの一覧です。
名前 | 説明 | 詳細 |
---|---|---|
azure/aks-set-context |
kubectl コマンドを使うように、または実行するように、その他のアクションに対してターゲット AKS クラスター コンテキストを設定します。 | azure/aks-set-context |
azure/k8s-set-context |
kubectl コマンドを使うように、または実行するように、その他のアクションに対してターゲット Kubernetes クラスター コンテキストを設定します。 | azure/k8s-set-context |
azure/k8s-bake |
Helm、kustomize、または kompose を使ったデプロイに使うマニフェスト ファイルをベイクします。 | azure/k8s-bake |
azure/k8s-create-secret |
Kubernetes クラスターに汎用シークレットまたは docker-registry シークレットを作成します。 | azure/k8s-create-secret |
azure/k8s-deploy |
マニフェストを Kubernetes クラスターにデプロイします。 | azure/k8s-deploy |
azure/k8s-lint |
マニフェスト ファイルの検証または lint を行います。 | azure/k8s-lint |
azure/setup-helm |
ランナーに特定のバージョンの Helm バイナリをインストールします。 | azure/setup-helm |
azure/setup-kubectl |
ランナーに特定のバージョンの kubectl をインストールします。 | azure/setup-kubectl |
azure/k8s-artifact-substitute |
コンテナー イメージのタグまたはダイジェストを更新します。 | azure/k8s-artifact-substitute |
azure/aks-create-action |
Terraform を使用して AKS クラスターを作成します。 | azure/aks-create-action |
azure/aks-github-runner |
GitHub Actions のセルフホステッド エージェントを設定します。 | azure/aks-github-runner |
azure/acr-build |
ACR を使ってコンテナーをビルドします。 | azure/acr-build |
AKS で GitHub Actions を使う
たとえば、変更が GitHub リポジトリにプッシュされるたびに、GitHub Actions を使用してアプリケーションを AKS クラスターにデプロイできます。 この例では、Azure Vote アプリケーションを使用します。
注意
この例では、ACR および AKS クラスターでの認証にサービス プリンシパルを使用します。 または、OPEN ID Connect (OIDC) を構成し、OIDC を使用するように azure/login
アクションを更新することもできます。 詳細については、OpenID Connect 認証を使った Azure ログインの設定に関する記事を参照してください。
リポジトリをフォークして更新する
Azure Vote リポジトリに移動して、[フォーク] を選びます。
azure-vote-front
イメージに ACR を使うようにazure-vote-all-in-one-redis.yaml
を更新します。<registryName>
は自分のレジストリの名前に置き換えます。... containers: - name: azure-vote-front image: <registryName>.azurecr.io/azuredocs/azure-vote-front:v1 ...
更新した
azure-vote-all-in-one-redis.yaml
をリポジトリにコミットします。
シークレットを作成する
az ad sp create-for-rbac
コマンドを使って、Contributor
ロールでリソース グループにアクセスするサービス プリンシパルを作成します。<SUBSCRIPTION_ID>
を Azure アカウントのサブスクリプション ID に、<RESOURCE_GROUP>
を ACR を含むリソース グループの名前に置き換えます。az ad sp create-for-rbac \ --name "ghActionAzureVote" \ --scope /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP> \ --role Contributor \ --json-auth
出力は次の出力例のようになります。
{ "clientId": <clientId>, "clientSecret": <clientSecret>, "subscriptionId": <subscriptionId>, "tenantId": <tenantId>, ... }
リポジトリの設定に移動し、[セキュリティ]>[シークレットと変数]>[アクション] を選びます。
シークレットごとに [新しいリポジトリ シークレット] を選び、シークレットの名前と値を入力します。
シークレット名 シークレット値 AZURE_CREDENTIALS az ad sp create-for-rbac
コマンドからの JSON 出力全体。service_principal <clientId>
の値。service_principal_password <clientSecret>
の値。subscription <subscriptionId>
の値。テナント <tenantId>
の値。使用) レジストリの名前。 repository azuredocs resource_group リソース グループの名前。 cluster_name ご利用のクラスターの名前。
シークレットの作成の詳細については、暗号化されたシークレットに関するページを参照してください。
アクション ファイルを作成する
リポジトリに
.github/workflows/main.yml
を作成して、次のコンテンツを貼り付けます。name: build_deploy_aks on: push: paths: - "azure-vote/**" jobs: build: runs-on: ubuntu-latest steps: - name: Checkout source code uses: actions/checkout@v3 - name: ACR build id: build-push-acr uses: azure/acr-build@v1 with: service_principal: ${{ secrets.service_principal }} service_principal_password: ${{ secrets.service_principal_password }} tenant: ${{ secrets.tenant }} registry: ${{ secrets.registry }} repository: ${{ secrets.repository }} image: azure-vote-front folder: azure-vote branch: master tag: ${{ github.sha }} - name: Azure login id: login uses: azure/login@v1.4.3 with: creds: ${{ secrets.AZURE_CREDENTIALS }} - name: Set AKS context id: set-context uses: azure/aks-set-context@v3 with: resource-group: '${{ secrets.resource_group }}' cluster-name: '${{ secrets.cluster_name }}' - name: Setup kubectl id: install-kubectl uses: azure/setup-kubectl@v3 - name: Deploy to AKS id: deploy-aks uses: Azure/k8s-deploy@v4 with: namespace: 'default' manifests: | azure-vote-all-in-one-redis.yaml images: '${{ secrets.registry }}.azurecr.io/${{ secrets.repository }}/azure-vote-front:${{ github.sha }}' pull-images: false
on
セクションには、アクションをトリガーするイベントが含まれています。 サンプルのファイルでは、変更がazure-vote
ディレクトリにプッシュされたときにアクションがトリガーされます。steps
セクションには、次のような個別の各アクションが含まれています。- "ソース コードのチェックアウト" は、GitHub Actions チェックアウト アクションを使用して、リポジトリを複製します。
- "ACR ビルド" は、Azure Container Registry ビルド アクションを使用して、イメージをビルドし、それをレジストリにアップロードします。
- "Azure ログイン" は、Azure ログイン アクションを使用して、Azure アカウントにサインインします。
- "AKS コンテキストの設定" は、Azure AKS コンテキスト設定アクションを使用して、AKS クラスターのコンテキストを設定します。
- "kubectl のセットアップ" は、Azure AKS Kubectl のセットアップ アクションを使用して、ランナーに kubectl をインストールします。
- "AKS へのデプロイ" は、Azure Kubernetes デプロイ アクションを使って、アプリケーションを Kubernetes クラスターにデプロイします。
.github/workflows/main.yml
ファイルをリポジトリにコミットします。アクションが動作していることを確認するには、
azure-vote/azure-vote/config_file.cfg
を次の内容で更新します。# UI Configurations TITLE = 'Azure Voting App' VOTE1VALUE = 'Fish' VOTE2VALUE = 'Dogs' SHOWHOST = 'false'
更新した
azure-vote/azure-vote/config_file.cfg
をリポジトリにコミットします。リポジトリで、[アクション] を選び、ワークフローが動作していることを確認します。 次に、ワークフローに緑色のチェックマークが付いており、更新されたアプリケーションがクラスターにデプロイされていることを確認します。
次のステップ
AKS の次のスターター ワークフローを確認します。 詳細については、「スターター ワークフローの使用」を参照してください。
Azure Kubernetes Service