プロジェクト

[アーティクル]
06/21/2023

プロジェクトは、ノード構成を定義するリソースのコレクションです。プロジェクトには 仕様が含まれています。ノードが起動すると、一連の仕様を処理して実行することによって構成されます。

Azure CycleCloud では、プロジェクトを使用して、バッチスケジューラなどのクラスター化されたアプリケーションを管理します。 CycleCloud HPCPack では、プロジェクトは hn HPCPack ヘッドノードと cn computenode の構成とレシピを定義する仕様と仕様です。

部分的なノード定義を次に示します。 docker-registry ノードでは、okta プロジェクトバージョン 1.3.0 のバインドスペックと、Docker プロジェクトバージョン 2.0.0 のコアおよびレジストリスペックの 3 つの仕様が実行されます。

[[node docker-registry]]
    Locker = base-storage
    [[[cluster-init okta:bind:1.3.0]]]
    [[[cluster-init docker:core:2.0.0]]]
    [[[cluster-init docker:registry:2.0.0]]]

末尾のタグはプロジェクトのバージョン番号です。

[[[cluster-init <project>:<spec>:<project version>]]]

ロッカーは、ストレージアカウントコンテナーと資格情報への参照です。ノードには既定のロッカーがあるため、この属性は厳密には必要ありません。

Azure CycleCloud はストレージアカウントの短縮形を使用するため https://mystorage.blob.core.windows.net/mycontainer 、 az://mystorage/mycontainer として記述できます。

ノードは、pogo ツールを使用してロッカーから参照する各プロジェクトをダウンロードします。

pogo get az://mystorage/mycontainer/projects/okta/1.3.0/bind

プロジェクトがノード上で定義されているが、予想されるストレージの場所に存在しない場合、ノードは CycleCloud に a を報告 Software Installation Failure します。

CycleCloud には、すべてのノードで既定で実行される内部プロジェクトがあり、特別なボリュームとネットワークの処理を実行し、CycleCloud への通信を設定します。これらの内部プロジェクトは自動的にロッカーにミラーリングされます。

ユーザーは、追加のプロジェクトをロッカーにミラーリングする責任があります。 CycleCloud CLI には、プロジェクトを作成するためのメソッドがあります。

cyclecloud project init myproject

とミラー:

cyclecloud project init mylocker

プロジェクトをロッカーに保管します。

仕様は、Python、シェル、または PowerShell スクリプトで構成されます。

新しいプロジェクトの作成

新しいプロジェクトを作成するには、CLI コマンド (作成myprojectするプロジェクトの名前) を使用しますcyclecloud project init myproject。これにより、"myproject" という名前のプロジェクトが作成され、"default" という名前の 1 つの仕様を変更できます。ディレクトリツリーは、独自の情報を含むように修正するスケルトンファイルで作成されます。

ディレクトリの構造

プロジェクトコマンドによって、次のディレクトリが作成されます。

      \myproject
          ├── project.ini
          ├── blobs
          ├── templates
          ├── specs
          │   ├── default
          │     └── cluster-init
          │        ├── scripts
          │        ├── files
          │        └── tests
          │     └── chef
          │         ├── site-cookbooks
          │         ├── data_bag
          │         └── roles

templates ディレクトリにはクラスターテンプレートが保持され、仕様にはプロジェクトを定義する仕様が含まれます。 spec には、cluster-init とカスタムシェフの 2 つのサブディレクトリがあります。 cluster-init には、 スクリプト ディレクトリ (ノード上で辞書式の順序で実行されるスクリプトが含まれます)、 ファイル (ノードに配置される生データファイル)、 テスト (クラスター がテストモードで開始されたときに実行されるテストを含む) など、特別な意味を持つディレクトリが含まれています。

カスタム chef サブディレクトリには、 サイトクックブック (クックブック 定義用)、 data_bags (データバッチ定義) 、ロール ( chef ロール定義ファイル) の 3 つのディレクトリがあります。

project.ini

project.ini は、プロジェクトのすべてのメタデータを含むファイルです。これには次のものが含まれます。

パラメーター	説明
name	プロジェクトの名前。単語はダッシュで区切る必要があります (例: order-66-2018)。
label	プロジェクトの名前。表示目的でクラスターの長い名前 (スペース付き)。
型	スケジューラ、アプリケーション <、空白>の 3 つのオプション。プロジェクトの種類を決定し、適切なテンプレートを生成します。既定値: application
version	形式: x.x.x

ロッカー

プロジェクトの内容は ロッカー内に保存されます。プロジェクトの内容は、CycleCloud インストールで定義されている任意のロッカーにコマンド cyclecloud project upload (locker)を使用してアップロードできます。ここで、(ロッカー) は CycleCloud インストールのクラウドストレージロッカーの名前です。このロッカーは既定のターゲットとして設定されます。または、コマンド cyclecloud locker listで利用可能なロッカーを確認することもできます。特定のロッカーに関する詳細は cyclecloud locker show (locker)、 .

複数のロッカーを追加する場合は、単に実行cyclecloud project uploadして、デフォルトをcyclecloud project default_target (locker)設定することができます。また、コマンド cyclecloud project default locker (locker) -globalを使用してプロジェクトで共有できるグローバルな既定のロッカーを設定することもできます。

Note

既定のロッカーは、project.iniではなく、cyclecloud 構成ファイル (通常は ~/.cycle/config.ini にあります) に格納されます。これは、project.iniをバージョン管理できるようにするために行われます。

プロジェクトの内容をアップロードすると、chef ディレクトリが圧縮され、chef と cluster init の両方がターゲットロッカーに同期されます。これらは次の位置に格納されます。

(locker)/projects/(project)/(version)/(spec_name)/cluster-init
(locker)/projects/(project)/(version)/(spec_name)/chef

BLOB のダウンロード

project.iniで参照されているすべての BLOB をローカル BLOB ディレクトリにダウンロードするために使用 project download します。このコマンドはパラメーターを [locker] 使用し、project.iniに記載されている BLOB をロッカーからローカルストレージにダウンロードしようとします。ファイルが見つからない場合は、エラーが返されます。

プロジェクトのセットアップ

仕様

新しいプロジェクトを作成するときに、1 つの既定の仕様が定義されます。コマンドを使用して、プロジェクトに追加のスペックを cyclecloud project add_spec 追加できます。

バージョン管理

既定では、すべてのプロジェクトの バージョン は 1.0.0 です。 project.ini ファイルで設定することで、プロジェクトの開発と配置時にカスタムバージョンを設定version=x.y.zできます。

たとえば、"locker_url" が "az://my-account/my-container/projects" で、プロジェクトの名前が "Order66" で、バージョンが "1.6.9" で、仕様が "default" の場合、URL は次のようになります。

az://my-account/my-container/projects/Order66/1.6.9/default/cluster-init
az://my-account/my-container/projects/Order66/1.6.9/default/chef

BLOB

BLOB には、プロジェクト BLOB とユーザー BLOB の 2 種類 があります。

Project BLOB

プロジェクト BLOB は、プロジェクトの作成者が提供するバイナリファイルであり、配布できることを前提とします (つまり、再配布が法的に許可されているオープンソースプロジェクトのバイナリファイル)。プロジェクト BLOB はプロジェクトの "BLOB" ディレクトリに移動し、ロッカーにアップロードすると 、/project/BLOB に配置されます。

プロジェクトに BLOB を追加するには、 project.iniにファイルを追加します。

[[blobs optionalname]]
  Files = projectblob1.tgz, projectblob2.tgz, projectblob3.tgz

複数の BLOB をコンマで区切ることができます。プロジェクトの BLOB ディレクトリへの相対パスを指定することもできます。

ユーザー BLOB

ユーザー BLOB は、プロジェクトの作成者が UGE バイナリなど、法的に再配布できないバイナリファイルです。これらのファイルはプロジェクトにパッケージ化されませんが、代わりに手動でロッカーにステージングする必要があります。ファイルは /blobs/my-project/my-blob.tgz にあります。ユーザー BLOB は、project.iniで定義する必要はありません。

任意の BLOB をダウンロードするには、CLI または Chef リソースからコマンドをjetpack_download使用jetpack downloadします。 CycleCloud は最初にユーザー BLOB を検索します。そのファイルが見つからない場合は、プロジェクトレベルの BLOB が使用されます。

Note

プロジェクト BLOB を同じ名前のユーザー BLOB でオーバーライドできます。

クラスターテンプレート内のプロジェクトの指定

プロジェクト構文を使用すると、ノードで複数の仕様を指定できます。プロジェクトを定義するには、次のコマンドを使用します。

[[[cluster-init myspec]]]
  Project = myproject # inferred from name
  Version = x.y.z
  Spec = default  # (alternatively, you can name your own spec to be used here)
  Locker = default  # (optional, will use default locker for node)

Note

'spec' の後に指定される名前は何でもかまいませんが、一部の共通プロパティを定義するためのショートカットとして使用できます。また、使用 > する必要があります。

次のように、特定のノードに複数のスペックを適用することもできます。

[[node scheduler]]
  [[[cluster-init myspec]]]
  Project = myproject
  Version = x.y.z
  Spec = default  # (alternatively, you can name your own spec to be used here)
  Locker = default  # (optional, will use default locker for node)

[[[cluster-init otherspec]]]
Project = otherproject
Version = a.b.c
Spec = otherspec  # (optional)

プロジェクト名、スペック名、バージョンをコロンで区切ることで、CycleCloud はこれらの値を自動的に適切な Project/Version/Spec 設定に解析できます。

[[node scheduler]]
  AdditionalClusterInitSpecs = $ClusterInitSpecs
  [[[cluster-init myproject:myspec:x.y.z]]]
  [[[cluster-init otherproject:otherspec:a.b.c]]]

スペックはノード間で継承することもできます。たとえば、すべてのノード間で共通のスペックを共有し、スケジューラノードでカスタムスペックを実行できます。

[[node defaults]]
[[[cluster-init my-project:common:1.0.0]]]
Order = 2 # optional
[[node scheduler]]
[[[cluster-init my-project:scheduler:1.0.0]]]
Order = 1 # optional

[[nodearray execute]]
[[[cluster-init my-project:execute:1.0.0]]]
   Order = 1 # optional

これにより、スケジューラノードに common spec と scheduler spec の両方が適用されますが、execute nodearray には spec と execute spec のみが適用commonされます。

既定では、スペックはテンプレートに表示されている順序で実行され、継承されたスペックが最初に実行されます。 Order は省略可能な整数で、既定値の 1000 に設定され、スペックの順序を定義するために使用できます。

定義に [[[cluster-init]]] 指定された名前が 1 つだけの場合は、仕様名と見なされます。次に例を示します。

[[[cluster-init myspec]]]
Project = myproject
Version = 1.0.0

は、名前で暗黙的に示される Spec=myspec 有効な仕様設定です。

run_list

project.ini内のプロジェクトレベルまたはスペックレベルでランリストを指定できます。

[spec scheduler]
run_list = role[a], recipe[b]

ノードに仕様 "scheduler" が含まれている場合、定義されたrun_listは、以前に定義したランリストに自動的に追加されます。たとえば、私のrun_listが定義 [configuration] されている run_list = recipe[test]場合、最終的なランリストは run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].

また、ノードのスペックレベルでランリストを上書きすることもできます。これにより、project.iniに含まれるすべてのrun_listが置き換えられます。たとえば、ノード定義を次のように変更した場合は、次のようになります。

[cluster-init test-project:scheduler:1.0.0]
run_list = recipe[different-test]

プロジェクトで定義されているランリストは無視され、代わりに上記が使用されます。その後、ノードの最後のランリストは run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init].

Note

runlist は chef に固有であり、それ以外の場合は適用されません。

ファイルの場所

zip 圧縮された chef ファイルは、ノードの起動のブートストラップフェーズ中にダウンロードされます。 これらは $JETPACK_HOME/system/chef/tarballs にダウンロードされ、$JETPACK_HOME/system/chef/chef-repo/に解凍され、ノードの収束時に使用されます。

Note

カスタムクックブックを実行するには、ノードのrun_listでそれらを指定する必要があります。

cluster-init ファイルは /mnt/cluster-init/(project)/(spec)/にダウンロードされます。 "my-project" と "my-spec" の場合、スクリプト、ファイル、テストが /mnt/cluster-init/my-project/my-spec に表示されます。

プロジェクトの同期

CycleCloud プロジェクトは、ミラーからクラスターローカルクラウドストレージに同期できます。テンプレート内のセクションに [cluster-init] SourceLocker 属性を設定します。指定されたロッカーの名前がプロジェクトのソースとして使用され、内容はクラスターの開始時にロッカーに同期されます。また、クラスター初期化名の最初の部分としてロッカーの名前を使用することもできます。たとえば、ソースロッカーが "cyclecloud" の場合、次の 2 つの定義は同じです。

[cluster-init my-project:my-spect:1.2.3]
  SourceLocker=cyclecloud

[cluster-init cyclecloud/my-proect:my-spec:1.2.3]

大きなファイルストレージ

プロジェクトでは、大きなファイルがサポートされます。新しく作成されたプロジェクトの最上位には、大きなファイル (BLOB) の "BLOB" ディレクトリが表示されます。このディレクトリに配置された BLOB には特定の目的があり、"files" ディレクトリ内の項目とは異なる動作をします。

"BLOB" ディレクトリ内の項目は、仕様とバージョンに依存しません。"BLOB" 内の項目は、スペックまたはプロジェクトバージョン間で共有できます。たとえば、まれに変更されるプログラムのインストーラーは、"BLOB" 内に格納し、 project.ini内で参照できます。プロジェクトのバージョンを反復処理すると、その 1 つのファイルは同じままで、クラウドストレージに 1 回だけコピーされるため、転送とストレージのコストが節約されます。

BLOB を追加するには、ファイルを "BLOB" ディレクトリに配置し、 project.ini を編集してそのファイルを参照します。

[blobs]
  Files=big_file1.tgz

このコマンドを project upload 使用すると、project.iniで参照されているすべての BLOB がクラウドストレージに転送されます。

ログファイル

cluster-init の実行時に生成されるログファイルは 、$JETPACK_HOME/logs/cluster-init/(project)/(spec)にあります。

ファイルの実行

cluster-init スクリプトが正常に実行されると、ファイルは /mnt/cluster-init/.run/(project)/(spec) に配置され、後続のコンバージで再度実行されないようにします。スクリプトをもう一度実行する場合は、このディレクトリ内の適切なファイルを削除します。

スクリプトディレクトリ

CycleCloud は、scripts ディレクトリでスクリプトを実行すると、spec ディレクトリとプロジェクトディレクトリのパスと名前に環境変数を追加します。

CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH

Linux では、"default" という仕様の "test-project" という名前のプロジェクトには、次のようなパスがあります。

CYCLECLOUD_PROJECT_NAME = test-project
CYCLECLOUD_PROJECT_PATH = /mnt/cluster-init/test-project
CYCLECLOUD_SPEC_NAME = default
CYCLECLOUD_SPEC_PATH = /mnt/cluster-init/test-project/default

スクリプトのみを実行する

cluster-init スクリプトのみを実行するには:

jetpack converge --cluster-init

コマンドからの出力は、stdOUT と jetpack.log の両方に送信されます。各スクリプトには、次の出力も記録されます。

      $JETPACK_HOME/logs/cluster-init/(project)/(spec)/scripts/(script.sh).out

カスタムシェフとコンポーザブルスペック

各仕様には chef ディレクトリがあります。収束する前に、各スペックは未解凍になり、ローカルの chef-repo に抽出され、既存のクックブック、ロール、およびデータバッグは同じ名前に置き換わります。これは、スペックが定義されている順序で行われるので、名前付けの競合の場合は、最後に定義されたスペックが常に優先されます。

jetpack のダウンロード

cluster-init スクリプト内で BLOB をダウンロードするには、コマンド jetpack download (filename) を使用して BLOB ディレクトリからプルします。 cluster-init スクリプトからこのコマンドを実行すると、プロジェクトとベース URL が決定されます。非クラスター init コンテキストで使用するには、プロジェクトを指定する必要があります (詳細については、--help を参照してください)。

Chef ユーザーの場合は、 jetpack_download LWRP が作成されています。

jetpack_download "big-file1.tgz" do
  project "my-project"
  end

chef では、既定のダウンロード場所は #{node[:jetpack][:downloads]}. ファイルの変換先を変更するには、次のコマンドを使用します。

jetpack_download "foo.tgz" do
  project "my-project"
  dest "/tmp/download.tgz"
end

chef 内で使用する場合は、プロジェクトを指定する必要があります。

次の方法で共有

プロジェクト

新しいプロジェクトの作成

ディレクトリの構造

project.ini

ロッカー

BLOB のダウンロード

プロジェクトのセットアップ

仕様

バージョン管理

BLOB

Project BLOB

ユーザー BLOB

クラスターテンプレート内のプロジェクトの指定

run_list

ファイルの場所

プロジェクトの同期

大きなファイルストレージ

ログファイル

ファイルの実行

スクリプトディレクトリ

スクリプトのみを実行する

カスタムシェフとコンポーザブルスペック

jetpack のダウンロード

その他のリソース

次の方法で共有

プロジェクト

新しいプロジェクトの作成

ディレクトリの構造

project.ini

ロッカー

BLOB のダウンロード

プロジェクトのセットアップ

仕様

バージョン管理

BLOB

Project BLOB

ユーザー BLOB

クラスター テンプレート内のプロジェクトの指定

run_list

ファイルの場所

プロジェクトの同期

大きなファイル ストレージ

ログ ファイル

ファイルの実行

スクリプト ディレクトリ

スクリプトのみを実行する

カスタム シェフとコンポーザブル スペック

jetpack のダウンロード

その他のリソース

クラスターテンプレート内のプロジェクトの指定

大きなファイルストレージ

ログファイル

スクリプトディレクトリ

カスタムシェフとコンポーザブルスペック