Service Fabric から AKS への単純なアプリの移行

この記事では、「Service Fabric から AKS へのワークロードの移行」に記載されている概念情報の一部を実装するのに役立つワークロード移行の例を示します。 そちらの記事では、Azure Kubernetes Service (AKS) について、および AKS と Azure Service Fabric の比較について説明しています。 また、ワークロードを移行するときに計算に入れる必要のある考慮事項も説明しています。

この例では、既にコンテナ化されている Windows ベースの Service Fabric アプリケーションに焦点を当てています。 Azure Service Fabric と Azure Kubernetes Service はどちらも Windows コンテナーと Linux コンテナーをサポートしています。 アプリケーションがコンテナ化されていない場合は、コンテナ化できるかどうか調査することをご検討ください。 アプリケーション用のコンテナー イメージを構築することは、アプリケーションを Azure Kubernetes Service にデプロイするための前提条件です。 Service Fabric プログラミング モデル (Reliable Services、Reliable Actors、ASP.NET Core、ゲスト実行可能ファイル) に依存しているアプリケーションの場合、いくらかのリファクタリングが必要と考えられます。

アプリケーションのコンテナ化の詳細については、「AKS 用のアプリケーションの準備」を参照してください。 ASP.NET アプリケーションのコンテナ化の詳細については、「ASP.NET アプリのコンテナ化と AKS への移行」を参照してください。

前提条件

移行を開始する前に、以下が必要です。

• Azure Container Registry に保存されているアプリケーション コンテナー イメージ。

• Azure リソースを構成するために使用できる Bash 環境。

  • Azure Cloud Shell を使用すると、ブラウザーから作業できます。 詳細については、「Azure Cloud Shell の Bash のクイックスタート」を参照してください。

  • ローカル インストールを使用する場合は、 az login コマンドを使用して Azure CLI にサインインします。 認証プロセスを完了するには、ターミナルに表示される手順に従います。 その他のサインイン オプションについては、 Azure CLI でのサインインに関するページを参照してください。

    Azure CLI を初めて使用するときは、プロンプトが表示されたら、Azure CLI 拡張機能をインストールする必要があります。 拡張機能の詳細については、 Azure CLI で拡張機能を使用する方法に関するページを参照してください。

• kubectl Kubernetes コマンド ライン ツール。 お使いの環境でまだ利用できない場合は、次のコマンドを実行してインストールできます。

  az aks install-cli
  

移行の手順

最初の手順は、Kubernetes で Windows ノード プールを構築するために必要なリソースを設定することです。 これを行うには、「AKS クラスター上に Windows Server コンテナーを作成する」のガイダンスに従いますが、「アプリケーションをデプロイする」のセクションまで進んだら、そこで 必ず停止 してください。 そこから、この記事の手順に従います。

Service Fabric 構成マニフェストを AKS マニフェストに変換することは重要な手順です。 続くセクションでは、以下を示します。

• 基本的な Service Fabric デプロイに使用できるサービス マニフェスト XML。
• Kubernetes Deployment および Service オブジェクトを作成する、機能的に同等の AKS マニフェスト。

これらの 2 つのマニフェストは、各サービスに特有の機能パラダイムに基づいているため、一対一では対応しませんが、意図するところは同じです (これらのサンプルでは、変数に <VARIABLE DESCRIPTION> という形式を使用します)。

AKS マニフェストで、 Deployment オブジェクトは Pod と ReplicaSetの宣言型な更新機能を提供します。 Service オブジェクトは、一連のポッド上でネットワーク サービスとして実行されているアプリケーションを公開します。

Service Fabric サービス マニフェストのサンプル

<?xml version="1.0" encoding="utf-8"?>

<ServiceManifest Name="<APP NAME>"
                 Version="1.0.0"
                 xmlns="http://schemas.microsoft.com/2011/01/fabric"
                 xmlns:xsd="https://www.w3.org/2001/XMLSchema"
                 xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <ServiceTypes>
    <StatelessServiceType ServiceTypeName="<SERVICE NAME>" UseImplicitHost="true" />
  </ServiceTypes>
 
  <!-- Code package is your service executable file. -->
  <CodePackage Name="code" Version="1.0.0">
    <EntryPoint>
      <ContainerHost>
        <ImageName><YOUR IMAGE></ImageName>
        <Commands></Commands>
      </ContainerHost>
    </EntryPoint>
    <!-- Pass environment variables to your container. -->
    <EnvironmentVariables>
      <EnvironmentVariable Name="HttpGatewayPort" Value=""/>
      <EnvironmentVariable Name="BackendServiceName" Value=""/>
    </EnvironmentVariables>
 
  </CodePackage>
 
  <ConfigPackage Name="Config" Version="1.0.0" />
 
  <Resources>
    <Endpoints>
      <Endpoint Name="<HTTP ENDPOINT NAME>" UriScheme="http" Port="80" Protocol="http"/>
    </Endpoints>
  </Resources>
</ServiceManifest>

AKS マニフェストのサンプル

apiVersion: apps/v1
kind: Deployment
metadata:
  name: <APP NAME>
  labels:
    app: <APP NAME>
spec:
  replicas: 1
  template:
    metadata:
      name: <APP NAME>
      labels:
        app: <APP NAME>
    spec:
      nodeSelector:
        "kubernetes.io/os": windows
      containers:
      - name: <SERVICE NAME>
        image: <YOUR IMAGE>
        resources:
          limits:
            cpu: 1
            memory: 800M
        ports:
          - containerPort: 80
    - env:
        - name: HttpGatewayPort
          value: ""
        - name: BackendServiceName
          value: ""
  selector:
    matchLabels:
      app: <APP NAME>
---
apiVersion: v1
kind: Service
metadata:
  name: <SERVICE NAME>
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 80
  selector:
    app: <SERVICE NAME>

Kubernetes には構成オプションの大きなセットが用意されており、これは経験豊富な開発者にとって有用です。 しかし、それらをあまりにも多く使用すると、マニフェストが大きくて複雑なものになってしまいます。 単純な移行の実装については、「デプロイと YAML マニフェスト」を確認することをお勧めします。

マニフェストが準備できたら、それを適用するだけで済み、アプリを監視できます。

kubectl apply -f <YOUR MANIFEST>.yaml
kubectl get deploy <APP NAME>
kubectl get service <SERVICE NAME> --watch

Note

この例では既定の Kubernetes 名前空間が使用されていますが、これは一般に基本的なシナリオでのみ使用されます。 Kubernetes では、1 つのクラスター内でリソースのグループを分離するメカニズムが名前空間により提供されます。 名前空間は、セキュリティ、ネットワーク、リソースの境界を適用するうえで重要です。 アプリケーションにとって最良の構成を決定するには、Kubernetes の namespace のドキュメントを参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

• Ally Ford | プロダクト マネージャー II
• Paolo Salvatori | プリンシパル カスタマー エンジニア
• Brandon Smith | プログラム マネージャー II

その他の共同作成者:

• Mick Alberts | テクニカル ライター
• Ayobami Ayodeji | シニア プログラム マネージャー
• Moumita Dey Verma | シニア クラウド ソリューション アーキテクト

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• AKS のリリース ノート、 AKS ロードマップ、 Azure の更新情報により、AKS の最新情報を入手します。
• 最新の Windows サーバー イメージ を使用して、セキュリティの維持、パフォーマンスの向上、オーバーヘッドの削減に役立てます。
• AKS リリース トラッカー を使用して、Kubernetes の最新バージョンを遅れずに適用します。
• 最新の SDK for .NET ワークロードを使用します。
• ロード テストとパフォーマンス チューニングの実行を検討し、AKS ポッドに適用される CPU とメモリのクォータを定期的に評価します (「Azure Monitor を使用して AKS を監視する」)。
• AKS ランディング ゾーン アクセラレータ を使用して、AKS にワークロードを実装し、ベスト プラクティスを適用します。

関連リソース

• Service Fabric から AKS へのワークロードの移行
• AKS の 2 日目の運用ガイド
• AKS クラスターのベースライン アーキテクチャ
• AKS アーキテクチャの設計