Alternative Architecture DOJO

オルターブースのクラウドネイティブ特化型ブログです。

ADEで小さく始めるPlatform engineering

※本記事はInfocom Advent Calendar 20243日目の記事になります!

こんにちはオルターブースのいけだです!

毎年「寒い寒い!寒すぎる~!」と自宅で騒いでいるので娘がホッカイロをプレゼントしてくれました。 ありがとう。それだけで温まります。

はい、ということで早速ですが、表題の「ADEで小さく始めるPlatform engineering」についての話題に移ります!

Platform Engineering

プラットフォームエンジニアリングとは、開発チームがより安全に、効率的に、そして迅速にソフトウェアを開発できるように、DevOps の原則に基づいたプラクティスです。

プラットフォームエンジニアは、内部開発者プラットフォームを構築し、そしてそのプラットフォームを利用する開発者を顧客と捉え、開発チームがコードを書くことに集中できるようにします。

learn.microsoft.com

内部開発者プラットフォームの主要な目的の1つは認知負荷の削減です。

近年、開発に関わるインフラストラクチャやツールが増加し、それらの設定や管理に多くの時間と労力を費やすことで、開発者の認知負荷が増大しています。

そこで、統一されたプラットフォームで知識を一元化し、シンプルな操作で管理できるようにすることが重要ということですね。

Azure Deployment Environments (ADE)

プラットフォームエンジニアリングと関連性が強いツールといえばIaCです。

例えば、プラットフォームエンジニア (またはそれに代わるロールの方) がIaCテンプレートを管理していて、開発チームが検証環境を自分でつくりたいときに、IaCテンプレートが格納されているリポジトリを案内するケースを考えてみます。

開発者がREADMEの手順通りに実施しても上手くいかず、結局プラットフォームエンジニア自らがIaCテンプレートをデプロイし環境を構築することになる…これは明らかにイケてないですよね…

理想としては、やはり内部プラットフォームが整備されていて、そこでIaCテンプレートが管理されており、開発者はボタンポチでいつでも検証環境をセルフで構築・破棄ができるといった状態が望ましいわけです。

しかし、そんなプラットフォームエンジニアリングの重要性は分かってはいるけれど、内部プラットフォームの整備・構築に時間もリソースも避けない…といった場合にAzure Deployment Environments (ADE) が非常に有用だと考えています。

learn.microsoft.com

ADEを使用することで、GitHubAzure DevOpsのリポジトリで管理されている既存のIaCテンプレートを簡単にカタログ化し、以下のような画面の内部開発者向けのプラットフォームを提供します。プロジェクトごとにRBACで開発チームの権限を管理し、構築可能な環境を適切にコントロールすることができます。

そして開発者は「環境定義の選択」から必要な環境を選び、クリック一つで簡単にデプロイできます。

開発者が利用できる環境定義は、既存のIaCをADEに取り込んでカタログ化することで作成します。ADEはArm TemplateとBicepをネイティブにサポートしており、TerraformやPulumiを使用する場合はカスタムコンテナイメージが必要となります。

Arm TemplateやBicepのテンプレートをすでに作成済みの場合、environment.yamlという環境定義ファイルを追加するだけでADEに取り込めます。 具体例として、以下のようなBicepファイルがあったとします。

main.bicep

param name string = ''

@secure()
param dbPassword string = ''

@description('Location to deploy the environment resources')
param location string = resourceGroup().location

var resourceName = '${name}-${uniqueString(resourceGroup().id)}'

resource appServicePlan 'Microsoft.Web/serverfarms@2021-02-01' = {
  name: 'asp-${resourceName}'
  location: location
  sku: {
    name: 'S1'
  }
  kind: 'linux'
  properties: {
    reserved: true
  }
}

resource appService 'Microsoft.Web/sites@2021-02-01' = {
  name: 'app-${resourceName}'
  location: location
  kind: 'app'
  properties: {
    serverFarmId: appServicePlan.id
    reserved: false
    siteConfig: {
      linuxFxVersion: 'DOCKER|nginx'
    }
  }
}

resource mysqlServer 'Microsoft.DBforMySQL/flexibleServers@2021-05-01' = {
  name: 'mysql-${resourceName}'
  location: location
  sku: {
    name: 'Standard_B1ms'
    tier: 'Burstable'
  }
  properties: {
    version: '5.7'
    administratorLogin: 'mysqladmin'
    administratorLoginPassword: dbPassword
    storage: {
      storageSizeGB: 20
    }
  }
  tags: {
    environment: 'dev'
  }
}

同じディレクトリに環境定義ファイルenvironment.yamlを追加するだけで、ADEで利用できるようになります。

.
├── environment.yaml ← 環境定義ファイルを追加する
└── main.bicep

environment.yaml

name: WebApp
version: 1.0.0
summary: Azure Web App Environment
description: Deploys a web app in Azure without a datastore
runner: Bicep
templatePath: main.bicep

# デプロイ時に指定するパラメーター
parameters:
  - id: dbPassword
    name: dbPassword
    description: 'The password for the database'
    type: string
    required: true
  - id: name
    name: name
    description: 'The name of the resource'
    type: string
    required: true

learn.microsoft.com

リポジトリ内のIaCテンプレートの整理方法については以下が参考になります。

learn.microsoft.com

このように既存のIaCテンプレートがあれば、最小限の工数でADEでのカタログ化ができるため、Platform Engineeringの第一歩としてよい出発点となるのではないでしょうか。

気になった方は、以下のチュートリアルに従って簡単に試すことができますので、ぜひ実践してみてください。

learn.microsoft.com

※Terraformの場合はカスタムコンテナイメージを利用する必要があります。こちらの記事を執筆しているので良ければご参考ください。

さいごに

プラットフォームエンジニアリングは、開発チームが本来の目的である「価値ある機能の開発」に集中できる環境を整えるための重要な取り組みだと考えています。

そこで既存のIaCテンプレートを活用し、少ない工数で内部開発者向けプラットフォームを提供できるAzure Deployment Environments(ADE)は、その第一歩を小さく始めるための強力なツールとなります。(ハンズオンなどの場面でも活用しやすいツールだと思います。)

本記事は以上となります。拙い内容で恐縮ではございますが最後までご覧頂き有難うございました!


サービス一覧 www.alterbooth.com cloudpointer.tech www.alterbooth.com