AzureにMinecraft統合版サーバを立ち上げる(技術解説編)

azure, minecraft
目次

はじめに

Azure上でDocker containerを利用したマイクラサーバ(統合版)を立ち上げます。

前回の以下の記事でAzure上にマイクラサーバをデプロイする手順については記載しましたが、本記事では中で使っている(少し工夫した)技術情報をピックアップして解説します。

AzureにMinecraft統合版サーバを立ち上げる(デプロイ編)

キーワードとしては

  • Azure Storage BLOBをNFSv3でDockerコンテナからマウント
  • Linux VM(Flatcar)デプロイ時にdocker-compose他、必要な設定を実施

といったところです。

インフラ全体構成

以下のような構成になっています。

img

ストレージ

マイクラデータを保存するStorage Accountはいわゆる階層型名前空間に対応したAzure Data Lake Storage Gen2的なやつを使います。

Azure Blob Storage でのネットワーク ファイル システム (NFS) 3.0 プロトコルのサポート

気づくとストレージの種類が増えたり名前が変わったりと混乱していますｗ

ストレージアカウントのプロパティで特に設定で注意が必要なのは以下の部分です。

  properties: {
    isNfsV3Enabled: true
    isHnsEnabled: true
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
    networkAcls: {
      bypass: 'AzureServices'
      defaultAction: 'Deny'
      ipRules: empty(myIp) ? [] : [
        {
          value: myIp
          action: 'Allow'
        }
      ]
    }
    supportsHttpsTrafficOnly: true
    accessTier: 'Hot'
  }
}

https://github.com/katakura/azure-minecraft-bedrock-server/blob/57c824d9b8dc62c5b58f7ae284f4b088e30bac18/deploy.bicep#L127-L153

プライベートエンドポイント

NFSv3はプロトコル的に認証がサポートされていないため、クライアント(Linux)からの接続には信頼されたネットワーク(≒閉域ネットワーク)からのみ行えます。

ストレージはサービスエンドポイント(指定したサブネットからのみ通信可能)と、プライベートエンドポイント(指定したサブネットにプライベートIPを割り当てる)が利用できますが、今回はより面倒?なプライベートエンドポイントを利用しました。

https://github.com/katakura/azure-minecraft-bedrock-server/blob/57c824d9b8dc62c5b58f7ae284f4b088e30bac18/deploy.bicep#L168-L223

Private DNS Zoneを利用しなくて、単純にプライベートIPでストレージにアクセスさせるのでもいいのですが、プライベートエンドポイントが割り当てるIPアドレスは固定化できず、一式デプロイ中にこの動的に割り当てられたIPアドレスをVMに渡すのが、ちょっと手間だったので真面目にPrivate DNS Zoneも使っています。

Ignision

Flatcar Container OSで推奨しているカスタムデプロイの手法として、Ingnisionを利用します。

元情報はContainer Linux Config(YAML)で定義します(マイクラサーバへ渡す環境変数とかもろもろ)、その後Config transpilerを使ってIgnition Config(json)に変換後、VMデプロイ時のcustom-dataとして渡しています(base64)

config.ymlを見てもらうとわかるのですが、以下の構成を行っています。

  • docker-compose用環境変数ファイルの作成(minecraft.env)
  • docker-compose実行ファイルのダウンロード
  • マイクラサーバ起動用docker-compose.ymlの作成
  • カスタムスクリプト(get-azure-env.sh)の作成
  • systemdへbeserver.serviceの登録

user-data

VMのデプロイ時に外から情報を渡すのに、user-dataが便利です。

Azure 仮想マシンのユーザー データ

今回はVMデプロイ前に作成したストレージの「アカウント名」「NFS共有名」をuser-dataとしてVMに渡しています。

    osProfile: {
      computerName: vmName
      adminUsername: adminUsername
      adminPassword: adminPassword
      customData: empty(customData) ? loadFileAsBase64('./config.json') : customData
    }
    diagnosticsProfile: {
      bootDiagnostics: {
        enabled: true
      }
    }
    userData: base64('${st.name},${blobContainerName}') // set storage account name and container name to VM meta data
  }`

https://github.com/katakura/azure-minecraft-bedrock-server/blob/57c824d9b8dc62c5b58f7ae284f4b088e30bac18/deploy.bicep#L307

このストレージアカウント名、共有名はVMのOS起動時に取得して、マイクラのDockerコンテナ起動時のボリュームマウントに使用しています。

起動シーケンス

デプロイ完了後は以下のシーケンスでマイクラサーバが起動します。

  1. OS起動
  2. beserver.service起動(systemd)
    1. user-dataからストレージアカウント名、共有名を取得後docker-compose用に「.env」に環境変数として設定
    2. docker-composeからマイクラサーバ起動

/etc/systemd/system/beserver-service を見ると判りますが、start, stop, reloadすべてただdocker-composeを呼んでいるだけですね。でも、このおかげで非常に楽にVM起動→マイクラサーバの起動までの流れが確立されました。

おわりに

他にも細々と小ネタをdeploy.bicepには含まれていますので、これからbicepを始めるといった人には参考になるところもあるかと思います。（変な言い回し）

自分的には今回は「Azure 仮想マシンのユーザー データ」がいろいろ応用出来て仕事にも活用できるかもー？と思いました。

img