Проекты

Проект — это коллекция ресурсов, определяющих конфигурации узлов. Проекты содержат спецификации. При запуске узла он настраивается путем обработки и выполнения последовательности спецификаций.

Azure CycleCloud использует проекты для управления кластеризованными приложениями, такими как планировщики пакетной службы. В CycleCloud HPCPack проект представляет собой hn спецификацию и cn спецификацию, которая определяет конфигурации и рецепты для головного узла и вычислительного узла HPCPack.

Ниже приведено определение частичного узла. Узел docker-registry будет запускать три спецификации: привязать спецификацию из проекта okta версии 1.3.0, а также основные спецификации и спецификации реестра из проекта Docker версии 2.0.0:

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

Если проект определен на узле, но не существует в ожидаемом расположении хранилища, узел будет сообщать в Software Installation Failure CycleCloud.

CycleCloud имеет внутренние проекты, которые выполняются по умолчанию на всех узлах для выполнения специальной обработки томов и сети и настройки связи с CycleCloud. Эти внутренние проекты автоматически отражаются в хранилище.

Пользователь отвечает за зеркальное отображение дополнительных проектов в хранилище. Интерфейс командной строки CycleCloud содержит методы создания проектов:

cyclecloud project init myproject

и зеркальное отображение:

cyclecloud project init mylocker

проекты для блокировщиков.

Спецификации состоят из скриптов Python, оболочки или PowerShell.

Создание нового проекта

Чтобы создать проект, используйте команду cyclecloud project init myprojectCLI, где myproject имя создаваемого проекта. При этом будет создан проект с именем myproject с одной спецификацией с именем default, которую можно изменить. Дерево каталогов будет создано со скелетными файлами, которые будут изменены, чтобы включить собственную информацию.

Структура каталогов

Следующие каталоги будут созданы командой проекта:

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

Каталог шаблонов будет содержать шаблоны кластера, а спецификации будут содержать спецификации , определяющие проект. спецификация содержит два подкаталога: cluster-init и custom chef. Cluster-init содержит каталоги, которые имеют особое значение, такие как каталог сценариев (содержит скрипты, выполняемые в лексикографическом порядке на узле), файлы (необработанные файлы данных, которые будут помещены на узел) и тесты (содержат тесты , выполняемые при запуске кластера в тестовом режиме).

В подкаталоге настраиваемого шеф-повара есть три каталога: поваренные книги (для определений повара), data_bags (определения баз данных) и роли (файлы определения ролей шеф-повара).

project.ini

project.ini — это файл, содержащий все метаданные проекта. Он может содержать:

Запирающиеся шкафчики

Содержимое проекта хранится в хранилище. Содержимое проекта можно передать в любой шкафчик, определенный в установке CycleCloud, с помощью команды cyclecloud project upload (locker), где (locker) — это имя облачного хранилища в вашей установке CycleCloud. Этот шкафчик будет установлен в качестве целевого объекта по умолчанию. Кроме того, вы можете увидеть, какие блокировщики доступны для вас с помощью команды cyclecloud locker list. Подробные сведения о конкретном хранилище можно просмотреть с помощью cyclecloud locker show (locker).

При добавлении нескольких шкафчиков можно задать значение по умолчанию cyclecloud project default_target (locker), а затем просто запустить cyclecloud project upload. Вы также можете задать глобальный хранилище по умолчанию, к которому можно предоставить общий доступ для проектов с помощью команды cyclecloud project default locker (locker) -global.

Отправка содержимого проекта запакует каталоги chef и синхронизирует и chef, и кластер инициализацию с целевым хранилищем. Они будут храниться по адресу:

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

Скачивание BLOB-объектов

Используется project download для скачивания всех больших двоичных объектов, на которые ссылается project.ini, в локальный каталог больших двоичных объектов. Команда использует [locker] этот параметр и попытается скачать большие двоичные объекты, перечисленные в project.ini из хранилища в локальное хранилище. Если не удается найти файлы, возвращается ошибка.

Настройка проекта

Спецификации

При создании проекта определяется одна спецификация по умолчанию. Вы можете добавить дополнительные спецификации в проект с помощью cyclecloud project add_spec команды.

Управление версиями

По умолчанию все проекты имеют версию 1.0.0. Настраиваемую версию можно задать при разработке и развертывании проектов, задав version=x.y.z в файлеproject.ini .

Например, если "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-объекты project

Blob-объекты project — это двоичные файлы, предоставляемые автором проекта с предположением, что они могут быть распределены (т. е. двоичный файл для проекта открытый код, который вы законно можете распространить). Blob-объекты project попадают в каталог "BLOB-объекты" проекта, и при отправке в хранилище они будут находиться в папке /project/blobs.

Чтобы добавить большие двоичные объекты в проекты, добавьте файлы в project.ini:

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

Несколько больших двоичных объектов могут быть разделены запятыми. Можно также указать относительный путь к каталогу BLOB-объектов проекта.

Blob-объекты пользователей

Blob-объекты пользователей — это двоичные файлы, которые автор проекта не может законно распространить, например двоичные файлы UGE. Эти файлы не упаковываются вместе с проектом, но вместо этого должны быть поставлены в хранилище вручную. Файлы будут расположены в папке /blobs/my-project/my-blob.tgz. Пользовательские BLOB-объекты не нужно определять в project.ini.

Чтобы скачать любой большой двоичный объект, используйте jetpack download команду из интерфейса командной jetpack_download строки или ресурса Chef. CycleCloud сначала будет искать большой двоичный объект пользователя. Если этот файл не найден, будет использоваться большой двоичный объект уровня проекта.

Задание проекта в шаблоне кластера

Синтаксис проекта позволяет указать несколько спецификаций на узлах. Чтобы определить проект, используйте следующее:

[[[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 , так и scheduler спецификации к узлу планировщика, применяя common только спецификации и execute спецификации к выполнению nodearray.

По умолчанию спецификации будут выполняться в том порядке, в котором они отображаются в шаблоне, сначала выполняя унаследованные спецификации. Order — необязательный целочисленный набор по умолчанию 1000, который можно использовать для определения порядка спецификаций.

Если в определении [[[cluster-init]]] указано только одно имя, оно будет считаться именем спецификации. Пример:

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

— допустимая настройка спецификации, в которой Spec=myspec подразумевается имя.

список запуска.

Список выполнения можно указать на уровне проекта или спецификации в project.ini:

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

Если узел содержит спецификацию "планировщик", run_list определен автоматически добавляется в любой ранее определенный список выполнения. Например, если мой run_list определен в разделе [configuration]run_list = recipe[test], окончательный список выполнения будет run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].

Вы также можете перезаписать список выполнения на уровне спецификации на узле. Это заменит все run_list, включенные в project.ini. Например, если мы изменили определение узла следующим образом:

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

Местоположение файлов

Zippped 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 можно синхронизировать из зеркал в локальное облачное хранилище кластера. Задайте атрибут SourceLocker для [cluster-init] раздела в шаблоне. Имя указанного хранилище будет использоваться в качестве источника проекта, а содержимое будет синхронизировано с хранилищем при запуске кластера. Вы также можете использовать имя шкафчика в качестве первой части имени cluster-init. Например, если исходный хранилище было "cyclecloud", следующие два определения одинаковы:

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

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

Хранилище больших файлов

Проекты поддерживают большие файлы. На верхнем уровне созданного проекта вы увидите каталог больших двоичных объектов для больших файлов (BLOB-объектов). Обратите внимание, что большие двоичные объекты, размещенные в этом каталоге, имеют определенную цель и будут действовать не так, как элементы в каталоге files.

Элементы в каталоге "BLOB-объекты" являются спецификациями и версиями независимо: все, что в "БОЛЬШИХ двоичных объектах" можно совместно использовать между спецификациями или версиями проекта. Например, установщик программы, изменяющейся редко, можно хранить в больших двоичных объектах и ссылаться на нее в project.ini. При итерации по версиям проекта один файл остается неизменным и копируется только в облачное хранилище один раз, что экономит затраты на передачу и хранение.

Чтобы добавить большой двоичный объект, просто поместите файл в каталог "BLOB-объекты" и измените project.ini для ссылки на этот файл:

[blobs]
  Files=big_file1.tgz

При использовании project upload команды все BLOB-объекты, на которые ссылается project.ini, будут переданы в облачное хранилище.

Файлы журнала

Файлы журналов, созданные при выполнении cluster-init, находятся в файле $JETPACK_HOME/logs/cluster-init/(project)/(spec).

Запуск файлов

При успешном выполнении скрипта cluster-init файл помещается в файл /mnt/cluster-init/.run/(project)/(spec), чтобы убедиться, что он не выполняется повторно на последующем конвергенте. Если вы хотите снова запустить скрипт, удалите соответствующий файл в этом каталоге.

Каталоги скриптов

Когда CycleCloud выполняет скрипты в каталоге скриптов, он добавит переменные среды в путь и имя спецификации и каталогов проекта:

CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH

В Linux проект с именем test-project со спецификацией default будет иметь пути следующим образом:

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-repo, заменяя все существующие книги, роли и контейнеры данных одинаковыми именами. Это делается в порядке определения спецификаций, поэтому в случае столкновения именования последний определенный спецификация всегда выиграет.

jetpack download

Чтобы скачать большой двоичный объект в скрипте cluster-init, используйте команду jetpack download (filename) , чтобы извлечь его из каталога BLOB-объектов. Выполнение этой команды из скрипта cluster-init определяет проект и базовый URL-адрес. Чтобы использовать его в контексте, отличном от cluster-init, необходимо указать проект (дополнительные сведения см. в разделе --help).

Для пользователей 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 необходимо указать проект.