エッジとベアメタルのシステムとサーバーを自動的にプロビジョニングして構成するためのベスト プラクティス

Last reviewed 2023-02-23 UTC

このドキュメントでは、次のような環境のエッジで実行されるデバイスに対して、信頼性が高く自動化されたプロビジョニング プロセスと構成プロセスを設計して実装する際のベスト プラクティスを紹介します。

エッジデバイスと IoT デバイスのプロビジョニング プロセスと構成プロセスを設計する場合や、これらのデバイスタイプをプロビジョニングするためのベスト プラクティスについて学習する場合は、このドキュメントをお読みください。

大量のデバイスを手動でプロビジョニングして構成すると、人的エラーが発生しやすく、フリートの拡大に合わせたスケーリングができません。たとえば、重要なプロビジョニングや構成タスクの実行を忘れた場合や、部分的または完全に文書化されていないプロセスに依存している場合などです。完全に自動化された信頼性の高いプロビジョニングと構成のプロセスが、これらの問題の解決に役立ちます。また、製造から廃棄まで、各デバイスのライフサイクルを管理するのに役立ちます。

用語

次の用語は、デバイスの自動プロビジョニングと構成のプロセスを実装および構築する方法を理解するうえで重要です。

  • エッジデバイス: 処理するデータの近くに環境エッジでデプロイするデバイス。
  • プロビジョニング プロセス: デバイスの構成を準備するために完了する必要がある一連のタスク。
  • 構成プロセス: デバイスが特定の環境で動作できるようにするために必要なタスクのセット。
  • 構成管理: 環境とデバイスの構成を管理するために継続的に実行する一連のタスク。
  • ベースイメージ: 自社が作成した、またはデバイスまたは OS のメーカーが作成した、最小限必要なオペレーティング システム(OS)またはファームウェア イメージ。
  • ゴールデン イメージ: デバイス用に作成するか、ベースイメージから準備する不変の OS イメージまたはファームウェア イメージ。ゴールデン イメージには、デバイスで割り当てられたタスクを実行するために必要なすべてのデータと構成情報が含まれます。さまざまなタスクに合わせて、さまざまなゴールデン イメージを準備できます。ゴールデン イメージタイプの類義語には、フレーバー、スピン、アーキタイプがあります。
  • シルバー イメージ: ゴールデン イメージとベースイメージに最小限の変更を適用してデバイス用に準備をする OS またはファームウェア イメージ。シルバー イメージを実行するデバイスは、デバイスがサポートする必要があるユースケースのニーズに応じて、初回起動時にプロビジョニングと構成を完了します。
  • シードデバイス: 外部依存関係なしで環境をブートストラップするデバイス。
  • ネットワーク ブート: デバイスに接続されたストレージ システムから、ソフトウェアと関連する構成情報をネットワークから取得できるようにするテクノロジー セット。

プロビジョニングと構成のプロセスのベスト プラクティス

目標を設定して一般的な誤りを回避するには、次のプロビジョニングと構成のベスト プラクティスを適用します。各ベスト プラクティスについては、それぞれのセクションで説明します。

プロビジョニングと構成のプロセスを自動化する

初回起動時や、必要なときには常に、デバイス内にインストールされたソフトウェア イメージのみを使用してデバイスをプロビジョニングして構成できる必要があります。

プロビジョニングと構成のプロセス中に必要なロジックを実装しないようにするには、プロセスのオーケストレーションと実装に必要なプリミティブを提供するツールを使用します。たとえば、cloud-init とその NoCloud データソースを、スクリプトや構成管理ツール(AnsiblePuppetChef など)とともに使用して、ローカルホストに対して実行できます。

信頼性の高いプロビジョニングと構成のプロセスを設計するには、これらのプロセス中に実行されたすべてのステップとタスクが有効で、可能な限り自動化された手法にする必要があります。たとえば、InSpec などの自動コンプライアンス テスト フレームワークを使用して、プロビジョニングと構成のプロセスが期待どおりに動作していることを確認できます。

このベスト プラクティスは、デバイスのプロビジョニングと構成を完了する必要がある場合に、単一障害点を回避し、手動での介入の必要性をなくす上で役立ちます。

用途に特化したデバイスを避ける

エッジデバイスを設計する場合は、目的と特殊性に関してばらつきを最小限に抑えます。この推奨事項は、すべてのエッジデバイスが互いに等しい必要がある、または同じ目的を共有することを意味するわけではありませんが、可能な限り同種のものにする必要があります。たとえば、サポートする必要があるワークロード タイプによってデバイス アーキタイプを定義できます。その後、これらのアーキタイプのプロパティに従って、デバイスをデプロイして管理できます。

このベスト プラクティスに従うには、特定のアーキタイプのデバイスからデバイスをランダムに選択できることを確認してから、次の操作を行います。

  • 同じアーキタイプの他のデバイスと同様にデバイスを扱います。このようにすることで、運用効率があることを示せます。
  • 追加のカスタマイズを行わずに、デバイスを同じアーキタイプのデバイスに置き換えます。このようにすることで、これらのアーキタイプが正しく実装されていることを示せます。

このベスト プラクティスにより、デバイスのフリートの差異が軽減され、環境やプロビジョニング、構成プロセスの断片化が減ります。

シードデバイスを使用して環境をブートストラップする

デバイスのプロビジョニングと構成の際に、循環依存関係の問題に直面することがあります。デバイスには、プロビジョニングと構成のためのインフラストラクチャのサポートが必要ですが、インフラストラクチャのプロビジョニングと構成が必要なため、インフラストラクチャは整っていません。

これは、シードデバイスを使用することで解決できます。シードデバイスには一時的な特殊用途があります。特殊用途が設計されたタスクを完了すると、デバイスはその動作とステータスを、関連するアーキタイプに適合させます。

たとえば、cloud-init を使用してデバイスを自動的に初期化する場合は、次の方法で cloud-init NoCloud データソースを構成する必要があります。

  1. NoCloud データソースのデータをファイル システムを通じてシードデバイスに提供します。
  2. シードデバイスが特別な目的で専用のプロビジョニングと構成を完了するのを待ちます。これには、ネットワーク経由で他のデバイスに NoCloud データソース データを提供することも含まれます。

    シードデバイスのプロビジョニングと構成のプロセスが、シードデバイスの一時的な特殊用途を削除する条件が満たされるまで待機します。これらの条件の例は次のとおりです。

    • 環境内にネットワーク経由で NoCloud データソース データを提供するデバイスが他にあるか。
    • クラスタ内に十分なノードがあるか。
    • 最初のバックアップは完了したか。
    • 障害復旧サイトの準備はできているか。
  3. シードデバイスからネットワーク