Projetos

Um projeto é um conjunto de recursos que define configurações de nós. Os projetos contêm especificações. Quando um nó é iniciado, ele processa e executa uma sequência de especificações para configurar o nó.

O Azure CycleCloud usa projetos para gerenciar aplicativos clusterizados, como agendadores em lote. No CycleCloud HPCPack, o projeto usa hn e cn especificações para definir as configurações e receitas para o nó cabeça e o nó de computação do HPCPack.

Na seguinte definição de nó parcial, o nó Docker-registry executa três especificações: a especificação bind do projeto Okta versão 1.3.0 e as especificações core e registry do projeto Docker versão 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]]]

A tag à direita é o número da versão do projeto:

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

Um cofre é uma referência a um contêiner e credencial de uma conta de armazenamento. Os nós têm um bloqueio padrão, portanto, nem sempre é necessário especificar este atributo.

O Azure CycleCloud usa uma abreviação para contas de armazenamento. Por exemplo, você pode escrever https://mystorage.blob.core.windows.net/mycontainer como az://mystorage/mycontainer.

O nó usa a ferramenta pogo para descarregar cada projeto ao qual faz referência a partir do repositório.

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

Se você definir um projeto em um nó, mas ele não existir no local de armazenamento esperado, o nó reportará um Software Installation Failure para o CycleCloud.

O CycleCloud tem projetos internos que são executados por padrão em todos os nós para realizar o tratamento especial de volumes, configuração de rede e estabelecer comunicação com o CycleCloud. O sistema espelha automaticamente esses projetos internos no armário.

Você é responsável por espelhar quaisquer projetos extras no armário. A CLI do CycleCloud oferece métodos para compor projetos:

cyclecloud project init myproject

E, espelhar projetos para armários:

cyclecloud project init mylocker

As especificações consistem em scripts Python, shell ou PowerShell.

Criar um novo projeto

Para criar um novo projeto, use o comando cyclecloud project init myproject CLI onde myproject é o nome do projeto que você deseja criar. myproject tem uma default especificação que você pode alterar. O comando cria a árvore de diretórios com arquivos esqueleto que você atualiza com suas próprias informações.

Estrutura do diretório

O comando project cria os seguintes diretórios:

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

O diretório templates contém seus modelos de cluster, enquanto specs contém as especificações que definem seu projeto. O diretório de especificações tem dois subdiretórios: cluster-init e custom chef. O diretório cluster-init contém diretórios com significados especiais, incluindo o diretório scripts (contém scripts que são executados em ordem lexicográfica no nó), arquivos (contém arquivos de dados brutos que vão para o nó) e testes (contém testes que são executados quando você inicia um cluster no modo de teste).

O subdiretório personalizado do chef tem três diretórios: site-cookbooks (para definições de livros de receitas), data_bags (definições de saco de dados) e funções (arquivos de definição de função do chef).

project.ini

_project.ini_ é o arquivo que contém todos os metadados para o seu projeto. Pode conter:

Parâmetro	Descrição
nome	Nome do projeto. Use traços para separar palavras, como order-66-2018.
etiqueta	Nome do projeto. Use um nome de cluster longo com espaços para fins de exibição.
tipo	Três opções: scheduler, application, ou <blank>. Este parâmetro determina o tipo de projeto e gera o modelo apropriado. Padrão: application.
versão	Formato: x.x.x

Cacifos

O conteúdo do projeto é armazenado dentro de um armário. Você pode carregar o conteúdo do seu projeto para qualquer armário definido em sua instalação do CycleCloud executando o comando cyclecloud project upload (locker), onde (locker) é o nome de um armário de armazenamento em nuvem em sua instalação do CycleCloud. Este armário é o destino padrão. Como alternativa, você pode executar o comando cyclecloud locker list para ver quais armários estão disponíveis para você. Você pode visualizar detalhes sobre um armário específico com cyclecloud locker show (locker).

Se adicionar mais de um armário, pode definir o cofre predefinido com cyclecloud project default_target (locker), e em seguida, executar cyclecloud project upload. Você também pode definir um armário padrão global para projetos a serem compartilhados executando o comando cyclecloud project default locker (locker) -global.

Observação

Os armários padrão são armazenados no arquivo de configuração do CycleCloud, geralmente localizado em ~/.cycle/config.ini e não no arquivo project.ini . Esta configuração permite o controle de versão para project.ini.

Ao carregar o conteúdo do seu projeto, o CycleCloud compacta os três diretórios personalizados do Chef e sincroniza tanto o Chef personalizado quanto o cluster-init com o repositório de destino. Esses arquivos são armazenados em:

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

Blob Baixar

Use project download para baixar todos os blobs referenciados no project.ini para o diretório de blobs local. O comando usa o [locker] parâmetro e tenta baixar blobs listados em project.ini do locker para o armazenamento local. Se o comando não conseguir localizar os ficheiros, devolve um erro.

Configuração do Projeto

Especificações

Ao criar um novo projeto, você define uma default especificação. Use o cyclecloud project add_spec comando para adicionar mais especificações ao seu projeto.

Gestão de Versões

Por padrão, todos os projetos usam a versão 1.0.0. Estabeleça uma versão personalizada enquanto desenvolve e implanta projetos definindo version=x.y.z no arquivo project.ini .

Por exemplo, se o locker_url for az://my-account/my-container/projects, o nome do projeto é "Order66", a versão é 1.6.9 e a especificação é default, suas URLs são:

• 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

Blocos

Existem dois tipos de blobs: blobs de projeto e blobs de usuário.

Blobs de Projeto

Os autores do projeto fornecem blobs de projeto, que são arquivos binários que eles podem distribuir (por exemplo, arquivos binários para um projeto de código aberto que alguém pode redistribuir legalmente). Os blobs de projeto vão para o blobs diretório de um projeto e são localizados em /project/blobs quando você os carrega para um repositório.

Para adicionar blobs a projetos, adicione os arquivos ao seu project.ini:

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

Separe vários blobs com uma vírgula. Você também pode especificar o caminho relativo para a pasta de blobs do projeto.

Blobs de usuário

Os blobs de usuário são arquivos binários, como binários do Univa Grid Engine, que o autor do projeto não pode redistribuir legalmente. Você não empacota esses arquivos com o projeto. Você deve colocá-los manualmente no armário. Os arquivos estão localizados em /blobs/my-project/my-blob.tgz. Não é necessário definir blobs de usuário no project.ini.

Para baixar qualquer blob, use o comando da CLI jetpack download ou o recurso Chef jetpack_download. O CycleCloud procura o blob do usuário primeiro e usa o blob no nível do projeto se não conseguir localizar o arquivo.

Observação

Um blob de usuário pode substituir um blob de projeto se eles tiverem o mesmo nome.

Especificar projeto dentro de um modelo de cluster

A sintaxe do projeto permite especificar várias especificações em seus nós. Para definir um projeto, use o seguinte código:

[[[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; uses the default locker for node)

Observação

O nome especificado depois spec pode ser qualquer coisa. Use-o como um atalho para definir algumas propriedades comuns.

O exemplo a seguir mostra como você pode aplicar várias especificações a um nó:

[[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; uses the default locker for node)

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

O CycleCloud usa dois pontos para separar o nome do projeto, o nome da especificação e a versão. Ele converte automaticamente esses valores para as Project/Version/Spec configurações.

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

As especificações também podem ser herdadas entre nós. Por exemplo, você pode compartilhar uma especificação comum entre todos os nós e executar uma especificação personalizada no nó do agendador:

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

Esse processo aplica tanto as especificações common como scheduler ao nó de agendamento e aplica apenas as especificações common e execute ao array de nós execute.

Por padrão, as especificações são executadas na ordem em que são mostradas no modelo e as especificações herdadas são executadas primeiro. Order é um inteiro opcional com um padrão de 1.000 que você pode usar para definir a ordem das especificações.

Se você especificar apenas um nome na [[[cluster-init]]] definição, o processo assumirá que é o nome da especificação. A seguinte configuração de especificação é válida e usa o nome Spec=myspec:

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

lista_de_execução

Pode especificar uma lista de execução no nível do projeto ou da especificação dentro do seu project.ini:

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

Quando um nó inclui a especificação scheduler, o run_list que definir é automaticamente anexado a qualquer run_list definida anteriormente. Por exemplo, se o run_list sob [configuration] for run_list = recipe[test], o run_list final será run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].

Você também pode substituir run_list ao nível de especificação em um nó. Esta substituição run_list remove todos os run_list incluídos no project.ini. Por exemplo, pode alterar a definição de um nó para a definição seguinte:

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

O uso dessa run_list faz com que o run_list definido no projeto seja ignorado. A run_list final no nó passa a ser run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init].

Observação

As listas de execução aplicam-se apenas ao Chef.

Locais dos arquivos

O nó baixa os arquivos compactados do Chef durante a fase de inicialização do nó. O nó baixa os ficheiros para $JETPACK_HOME/system/chef/tarballs*, descompacta-os em $JETPACK_HOME/system/chef/chef-repo/, e os usa para convergir o nó.

Observação

Para executar livros de receitas personalizados, é necessário adicioná-los ao run_list do nó.

O nó baixa os arquivos cluster-init para /mnt/cluster-init/(project)/(spec)/. Para my-project e my-spec, seus scripts, arquivos e testes estão em /mnt/cluster-init/my-project/my-spec.

Sincronizar projetos

Você pode sincronizar projetos do CycleCloud a partir de espelhos para o armazenamento em nuvem local do cluster. Defina um SourceLocker atributo em uma [cluster-init] seção dentro do seu modelo. O nome do repositório que você especificar é a fonte do projeto, e os conteúdos são sincronizados com o seu repositório quando o cluster é iniciado. Você também pode usar o nome do armário como a primeira parte do cluster-init nome. Por exemplo, se o cofre de origem for cyclecloud, as duas definições a seguir são as mesmas:

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

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

Armazenamento de arquivos grande

Os projetos suportam arquivos grandes. No nível superior de um projeto recém-criado, você vê um blobs diretório para seus arquivos grandes (blobs). Os blobs que você coloca neste diretório servem a uma finalidade específica e agem de forma diferente dos itens dentro do files diretório.

Os itens dentro do blobs diretório agem independentemente das especificações e versões. Você pode compartilhar qualquer coisa em blobs entre especificações ou versões do projeto. Por exemplo, você pode armazenar um instalador para um programa que muda com pouca frequência dentro de blobs e fazer referência a ele em seu project.ini. À medida que realizas iterações nas versões do teu projeto, esse único ficheiro permanece o mesmo e é copiado para o armazenamento na nuvem apenas uma vez, o que reduz os custos de transferência e armazenamento.

Para adicionar um blob, coloque um arquivo no diretório e edite o blobsproject.ini para fazer referência a esse arquivo:

[blobs]
  Files=big_file1.tgz

Quando você usa o comando, ele transfere todos os blobs referenciados no project.ini para o project upload armazenamento em nuvem.

Ficheiros de registo

Os arquivos de log gerados ao executar cluster-init estão localizados em $JETPACK_HOME/logs/cluster-init/(project)/(spec).

Executar ficheiros

Quando um script de inicialização de cluster é executado com êxito, ele coloca um ficheiro em /mnt/cluster-init/.run/(project)/(spec) para garantir que o script não seja executado novamente numa convergência subsequente. Para executar o script novamente, exclua o arquivo apropriado neste diretório.

Diretórios de script

Quando CycleCloud executa scripts no diretório scripts, ele adiciona variáveis de ambiente ao caminho e ao nome dos diretórios spec e project.

CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH

No Linux, um projeto chamado test-project com uma especificação de default tem os seguintes caminhos:

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

Executar apenas scripts

Para executar apenas scripts cluster-init, use o seguinte comando:

jetpack converge --cluster-init

O comando envia sua saída para STDOUT e para jetpack.log. A saída de cada script também é registrada em:

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

Chef personalizado e especificações componíveis

Cada especificação contém um diretório de chef. Antes de convergir um nó, o processo descompacta e extrai cada especificação para o chef-repo local, substituindo quaisquer cookbooks, roles e data bags existentes por nomes correspondentes. O processo segue a ordem na qual você define as especificações, portanto, a última especificação definida vence se houver um conflito de nomenclatura.

baixar jetpack

Para baixar um blob dentro de um script cluster-init, use o comando jetpack download (filename) para retirá-lo do blobs diretório. A execução deste comando a partir de um script cluster-init permite determinar o projeto e a URL base para você. Para usá-lo em um contexto não-cluster-init, você precisa especificar o projeto (consulte --help para obter mais informações).

O exemplo a seguir mostra como criar um fornecedor de jetpack_download recursos leve para utilizadores do Chef:

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

No chef, o local de download padrão é #{node[:jetpack][:downloads]}. Para alterar o destino do arquivo, use o seguinte código:

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

Ao usar o comando dentro do chef, você deve especificar o projeto.