Projetos

Um projeto é uma coleção de recursos que definem configurações de nó. Os projetos contêm especificações. Quando um nó é iniciado, ele é configurado processando e executando uma sequência de especificações.

O Azure CycleCloud usa projetos para gerenciar aplicativos clusterizados, como agendadores de lote. No CycleCloud HPCPack, o projeto é uma especificação e cn especificação hn que definem as configurações e as receitas do headnode e do computenode HPCPack.

Abaixo está uma definição de nó parcial. O nó docker-registry executará três especificações: associar especificação do projeto okta versão 1.3.0, bem como especificações principais e de registro do projeto do 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 marca à direita é o número da versão do projeto.

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

Um armário é uma referência a um contêiner de conta de armazenamento e credencial. Os nós têm um armário padrão, portanto, esse atributo não é estritamente necessário.

O Azure CycleCloud usa uma abreviação para contas de armazenamento, portanto https://mystorage.blob.core.windows.net/mycontainer , pode ser gravado como az://mystorage/mycontainer.

O nó baixará cada projeto referenciado do cofre usando a ferramenta pogo:

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

Se um projeto for definido em um nó, mas não existir no local de armazenamento esperado, o nó relatará um Software Installation Failure ao CycleCloud.

O CycleCloud tem projetos internos executados por padrão em todos os nós para executar o volume especial e a comunicação de configuração e manipulação de rede para o CycleCloud. Esses projetos internos são espelhados automaticamente no armário.

O usuário é responsável por espelhar quaisquer projetos adicionais no cofre. A CLI do CycleCloud tem métodos para redigir projetos:

cyclecloud project init myproject

e espelho:

cyclecloud project init mylocker

projetos para armários.

As especificações são compostas por scripts python, shell ou powershell.

Criar um novo projeto

Para criar um novo projeto, use o comando cyclecloud project init myprojectda CLI, onde myproject está o nome do projeto que você deseja criar. Isso criará um projeto chamado "myproject", com uma única especificação chamada "padrão" que você pode alterar. A árvore de diretório será criada com arquivos esqueleto que você alterará para incluir suas próprias informações.

Estrutura de diretórios

Os seguintes diretórios serão criados pelo comando do projeto:

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

O diretório de modelos manterá seus modelos de cluster, enquanto as especificações conterão as especificações que definem seu projeto. spec tem dois subdiretórios: cluster-init e chef personalizado. cluster-init contém diretórios que têm significado especial, como o diretório de scripts (contém scripts executados em ordem lexicográfica no nó), arquivos ( arquivos de dados brutos a serem colocados no nó) e testes (contém testes a serem executados quando um cluster é iniciado no modo de teste).

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

project.ini

project.ini é o arquivo que contém todos os metadados do projeto. Ele pode conter:

Armários

O conteúdo do projeto é armazenado dentro de um armário. Você pode carregar o conteúdo do seu projeto em qualquer armário definido em sua instalação do CycleCloud por meio do comando cyclecloud project upload (locker), em que (locker) é o nome de um cofre de armazenamento em nuvem em sua instalação do CycleCloud. Esse armário será definido como o destino padrão. Como alternativa, você pode ver quais armários estão disponíveis para você com o comando cyclecloud locker list. Detalhes sobre um armário específico podem ser exibidos com cyclecloud locker show (locker).

Se você adicionar mais de um armário, poderá definir seu padrão com cyclecloud project default_target (locker), em seguida, simplesmente executar cyclecloud project upload. Você também pode definir um armário padrão global que pode ser compartilhado por projetos com o comando cyclecloud project default locker (locker) -global.

Carregar o conteúdo do projeto fechará os diretórios do chef e sincronizará o chef e o cluster em seu armário de destino. Elas serão armazenadas em:

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

Blob Download

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 tentará baixar blobs listados em project.ini do armário para o armazenamento local. Um erro será retornado se os arquivos não puderem ser localizados.

Instalação do projeto

Especificações

Ao criar um novo projeto, uma única especificação padrão é definida. Você pode adicionar especificações adicionais ao projeto por meio do cyclecloud project add_spec comando.

Controle de versão

Por padrão, todos os projetos têm uma versão 1.0.0. Você pode definir uma versão personalizada à medida que desenvolve e implanta projetos configurando version=x.y.z no arquivo project.ini .

Por exemplo, se "locker_url" fosse "az://my-account/my-container/projects", o projeto se chamava "Order66", a versão era "1.6.9" e a especificação é "padrão", sua URL seria:

• 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

Blobs

Há dois tipos de blob: blobs de projeto e blobs de usuário.

Blobs do Projeto

Os Blobs do Projeto são arquivos binários fornecidos pelo autor do projeto com a suposição de que eles podem ser distribuídos (ou seja, um arquivo binário para um projeto código aberto que você tem permissão legal para redistribuir). Os Blobs do Projeto entram no diretório "blobs" de um projeto e, quando carregados em um armário, eles estarão localizados em /project/blobs.

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

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

Vários blobs podem ser separados por uma vírgula. Você também pode especificar o caminho relativo para o diretório de blob do projeto.

Blobs de usuário

Blobs de usuário são arquivos binários que o autor do projeto não pode redistribuir legalmente, como binários UGE. Esses arquivos não são empacotados com o projeto, mas devem ser preparados manualmente para o armário. Os arquivos estarão localizados em /blobs/my-project/my-blob.tgz. Blobs de usuário não precisam ser definidos no project.ini.

Para baixar qualquer blob, use o jetpack download comando da CLI ou o jetpack_download recurso Chef. O CycleCloud procurará primeiro o blob do usuário. Se esse arquivo não estiver localizado, o blob no nível do projeto será usado.

Especificar Projeto dentro de um modelo de cluster

A sintaxe do projeto permite que você especifique várias especificações em seus nós. Para definir um projeto, use o seguinte:

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

Você também pode aplicar várias especificações a um determinado nó da seguinte maneira:

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

Ao separar o nome do projeto, o nome da especificação e a versão com dois pontos, o CycleCloud pode analisar esses valores nas configurações apropriadas Project/Version/Spec automaticamente:

[[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, em seguida, 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

Isso aplicaria as especificações e scheduler as common especificações ao nó do agendador, ao mesmo tempo em que aplicava apenas as common especificações e execute a nodearray de execução.

Por padrão, as especificações serão executadas na ordem em que forem mostradas no modelo, executando as especificações herdadas primeiro. Order é um inteiro opcional definido como um padrão de 1000 e pode ser usado para definir a ordem das especificações.

Se apenas um nome for especificado na [[[cluster-init]]] definição, ele será considerado o nome da especificação. Por exemplo:

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

é uma configuração de especificação válida na qual Spec=myspec está implícita pelo nome.

run_list

Você pode especificar uma lista de execução no nível do projeto ou da especificação em seu project.ini:

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

Quando um nó incluir a especificação "agendador", o run_list definido será acrescentado automaticamente a qualquer runlist definido anteriormente. Por exemplo, se meu run_list definido em [configuration] , run_list = recipe[test]a lista de execução final seria run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].

Você também pode substituir uma lista de execução no nível de especificação em um nó. Isso substituirá qualquer run_list incluído no project.ini. Por exemplo, se alterarmos a definição do nó para o seguinte:

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

A lista de execução definida no projeto seria ignorada e a acima seria usada em vez disso. A lista de execução final no nó seria run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init]então .

Locais de arquivo

Os arquivos de chef compactados serão baixados durante a fase de inicialização da inicialização do nó. Eles são baixados para $JETPACK_HOME/system/chef/tarballs e descompactados para $JETPACK_HOME/system/chef/chef-repo/, e usados ao convergir o nó.

Os arquivos cluster-init serão baixados para /mnt/cluster-init/(project)/(spec)/. Para "my-project" e "my-spec", você verá seus scripts, arquivos e testes localizados em /mnt/cluster-init/my-project/my-spec.

Sincronizando projetos

Os projetos do CycleCloud podem ser sincronizados de espelhos no armazenamento em nuvem local do cluster. Defina um atributo SourceLocker em uma [cluster-init] seção dentro do modelo. O nome do armário especificado será usado como a origem do projeto e o conteúdo será sincronizado com o seu armário no início do cluster. Você também pode usar o nome do armário como a primeira parte do nome cluster-init. Por exemplo, se o cofre de origem for "cyclecloud", as duas definições a seguir serã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 dão suporte a arquivos grandes. No nível superior de um projeto recém-criado, você verá um diretório "blobs" para seus arquivos grandes (blobs). Observe que os blobs colocados neste diretório têm uma finalidade específica e agirão de forma diferente dos itens dentro do diretório "arquivos".

Os itens dentro do diretório "blobs" são independentes de especificação e versão: qualquer coisa em "blobs" pode ser compartilhada entre especificações ou versões do projeto. Por exemplo, um instalador de um programa que é alterado com pouca frequência pode ser armazenado em "blobs" e referenciado em seu project.ini. À medida que você itera em versões do seu projeto, esse único arquivo permanece o mesmo e só é copiado para o armazenamento em nuvem uma vez, o que economiza no custo de transferência e armazenamento.

Para adicionar um blob, basta colocar um arquivo no diretório "blobs" e editar sua project.ini para fazer referência a esse arquivo:

[blobs]
  Files=big_file1.tgz

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

Arquivos de log

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

Executar Arquivos

Quando um script cluster-init é executado com êxito, um arquivo é colocado em /mnt/cluster-init/.run/(project)/(spec) para garantir que ele não seja executado novamente em um convergente subsequente. Se você quiser executar o script novamente, exclua o arquivo apropriado neste diretório.

Diretórios de script

Quando o CycleCloud executa scripts no diretório de scripts, ele adicionará variáveis de ambiente ao caminho e ao nome dos diretórios de especificação e projeto:

CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH

No Linux, um projeto chamado "test-project" com uma especificação de "padrão" teria caminhos da seguinte maneira:

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 scripts somente

Para executar SOMENTE os scripts cluster-init:

jetpack converge --cluster-init

A saída do comando irá para STDOUT e jetpack.log. Cada script também terá sua saída registrada em:

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

Chef personalizado e especificações redigiráveis

Cada especificação tem um diretório chef nele. Antes de convergir, cada especificação será inserida e extraída no chef-reppo local, substituindo todos os livros de receitas, funções e sacos de dados existentes com os mesmos nomes. Isso é feito na ordem em que as especificações são definidas, portanto, no caso de uma colisão de nomenclatura, a última especificação definida sempre ganhará.

download do jetpack

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

Para usuários chef, um jetpack_download LWRP foi criado:

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:

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

Quando usado no chef, você deve especificar o projeto.