プロジェクト

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

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 は、プロジェクトのすべてのメタデータを含むファイルです。 これには次のものが含まれます。

ロッカー

プロジェクトの内容は ロッカー内に保存されます。 プロジェクトの内容は、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を使用してプロジェクトで共有できるグローバルな既定のロッカーを設定することもできます。

プロジェクトの内容をアップロードすると、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 が使用されます。

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

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

[[[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)

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

[[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].

ファイルの場所

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

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 内で使用する場合は、プロジェクトを指定する必要があります。