Projetos
Um projeto é uma coleção de recursos que definem configurações de nó. Os projetos contêm especificações. Quando um nó começa, é configurado processando e executando uma sequência de especificações.
O Azure CycleCloud utiliza projetos para gerir aplicações agrupadas, como agendadores de lotes. No CycleCloud HPCPack, o projeto é uma hn especificação e cn especificação que definem as configurações e receitas para headnode e computenode HPCPack.
Abaixo está uma definição parcial do nó. O nó de registo de estivar terá três especificações: ligar as especificações da versão 1.3.0 do projeto okta, bem como as especificações de núcleo e registo da versão 2.0.0 do projeto docker:
[[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 etiqueta de fuga é o número da versão do projeto.
[[[cluster-init <project>:<spec>:<project version>]]]
Um armário é uma referência a um recipiente de conta de armazenamento e credencial. Os nós têm um armário predefinido, por isso este atributo não é estritamente necessário.
O Azure CycleCloud utiliza uma abreviatura para contas de armazenamento, pelo https://mystorage.blob.core.windows.net/mycontainer que pode ser escrita como az://mystorage/mycontainer.
O nó irá descarregar cada projeto que faz referência a partir do cacifo utilizando a ferramenta pogo:
pogo get az://mystorage/mycontainer/projects/okta/1.3.0/bind
Se um projeto for definido num nó mas não existir no local de armazenamento esperado, então o nó reportará um Software Installation Failure ao CycleCloud.
O CycleCloud tem projetos internos que funcionam por padrão em todos os nós para executar o volume especial e o manuseamento de rede e comunicação de configuração para o CycleCloud. Estes projetos internos são espelhados automaticamente no armário.
O utilizador é responsável por espelhar quaisquer projetos adicionais para o cacifo. O CycleCloud CLI tem métodos para compor projetos:
cyclecloud project init myproject
e espelho:
cyclecloud project init mylocker
projetos para armários.
As especificações são compostas por scripts de pitão, concha ou powershell.
Criar um novo projeto
Para criar um novo projeto, utilize o comando cyclecloud project init myprojectCLI, onde myproject está o nome do projeto que pretende criar. Isto criará um projeto chamado "myproject", com uma única especificação chamada "padrão" que pode alterar. A árvore do diretório será criada com ficheiros de esqueletos que irá alterar para incluir a sua própria informação.
Estrutura do Diretório
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 irá manter os seus modelos de cluster, enquanto as especificações conterão as especificações que definem o seu projeto. especificação tem duas subdireitações: cluster-init e chef personalizado. O cluster-init contém diretórios que têm um significado especial, como o diretório de scripts (contém scripts que são executados por ordem lexicográfica no nó), ficheiros (ficheiros 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 personalizado do chef tem três diretórios: livros de receitas de sites (para definições de livro de receitas), data_bags (definições de databag) e papéis (ficheiros de definição de função do chef).
project.ini
project.ini é o ficheiro que contém todos os metadados para o seu projeto. Pode conter:
| Parâmetro | Descrição |
|---|---|
| name | O nome do projeto. As palavras devem ser separadas por traços, por exemplo, ordem-66-2018 |
| etiqueta | O nome do projeto. Nome comprido (com espaços) do cluster para fins de exibição. |
| tipo | Três opções: programador, aplicação, <em branco>. Determina o tipo de projeto e gera o modelo apropriado. Predefinição: aplicação |
| versão | Formato: x.x.x |
Armários
Os conteúdos do projeto são armazenados dentro de um armário. Pode fazer o upload do conteúdo do seu projeto para qualquer locker definido na sua instalação CycleCloud através do comando cyclecloud project upload (locker), onde (locker) é o nome de um armário de armazenamento em nuvem na sua instalação CycleCloud. Este cacifo será definido como o alvo padrão. Em alternativa, pode ver quais os cacifos disponíveis para si com o comando cyclecloud locker list. Os detalhes sobre um cacifo específico podem ser vistos com cyclecloud locker show (locker).
Se adicionar mais do que um armário, pode definir o seu padrão com cyclecloud project default_target (locker), em seguida, simplesmente executar cyclecloud project upload. Também pode definir um armário padrão global que pode ser partilhado por projetos com o comando cyclecloud project default locker (locker) -global.
Nota
Os armários predefinidos serão armazenados no ficheiro config cyclecloud (normalmente localizado em ~/.cycle/config.ini), não no project.ini. Isto é feito para permitir que project.ini seja controlado pela versão.
O upload dos conteúdos do seu projeto irá fechar os diretórios do chef e sincronizar tanto o chef como o cluster no seu armário alvo. Estes serão armazenados em:
- (cacifo)/projetos/(projeto)/(versão)/spec_name)/cluster-init
- (cacifo)/projetos/(projeto)/(versão)/(spec_name)/chef
Blob Download
Utilize project download para descarregar todas as bolhas referenciadas no project.ini para o seu diretório de blobs local. O comando utiliza o [locker] parâmetro e tentará descarregar bolhas listadas em project.ini do cacifo para o armazenamento local. Um erro será devolvido se os ficheiros não puderem ser localizados.
Configuração do projeto
Especificações
Ao criar um novo projeto, é definida uma especificação padrão única. Pode adicionar especificações adicionais ao seu projeto através do cyclecloud project add_spec comando.
Controlo de versões
Por predefinição, todos os projetos têm uma versão de 1.0.0. Pode definir uma versão personalizada à medida que desenvolve e implementa projetos definindo version=x.y.z o ficheiro project.ini .
Por exemplo, se "locker_url" fosse "az://my-account/my-container/projects", o projeto chamava-se "Order66", a versão era "1.6.9", e a especificação é "padrão", o seu 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
Existem dois tipos de bolhas: bolhas de projeto e bolhas de utilizador.
Projeto Blobs
Os Project Blobs são ficheiros binários fornecidos pelo autor do projeto com o pressuposto de que podem ser distribuídos (ou seja, um ficheiro binário para um projeto open source que legalmente pode redistribuir). O Project Blobs vai para o diretório "blobs" de um projeto, e quando enviado para um cacifo, eles serão localizados em /project/blobs.
Para adicionar bolhas a projetos, adicione os ficheiros ao seu project.ini:
[[blobs optionalname]]
Files = projectblob1.tgz, projectblob2.tgz, projectblob3.tgz
Várias bolhas podem ser separadas por uma vírgula. Também pode especificar o caminho relativo para o diretório blob do projeto.
Bolhas de utilizador
As Bolhas de Utilizador são ficheiros binários que o autor do projeto não pode redistribuir legalmente, como binários UGE. Estes ficheiros não são embalados com o projeto, mas devem ser encenados manualmente para o cacifo. Os ficheiros serão localizados em /blobs/my-project/my-blob.tgz. As bolhas do utilizador não precisam de ser definidas no project.ini.
Para descarregar qualquer bolha, use o jetpack download comando do CLI, ou o jetpack_download recurso Chef. CycleCloud procurará primeiro a bolha do utilizador. Se esse ficheiro não estiver localizado, será utilizada a bolha de nível de projeto.
Nota
É possível sobrepor uma bolha de projeto com uma bolha de utilizador com o mesmo nome.
Especifique o projeto dentro de um modelo de cluster
A sintaxe do projeto permite-lhe especificar várias especificações nos seus nós. Para definir um projeto, utilize 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)
Nota
O nome especificado após 'especificação' pode ser qualquer coisa, mas pode e deve ser usado como atalho para definir algumas propriedades comuns > .
Também pode aplicar várias especificações a um dado nó da seguinte forma:
[[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 automaticamente o nome do projeto, o nome das especificações e a versão com os cólons, o CycleCloud pode analisar esses valores nas definiçõ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, pode partilhar uma especificação comum entre todos os nós e, em seguida, executar uma especificação personalizada no nó do programador:
[[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
Isto aplicaria tanto as common especificações como scheduler as especificações ao nó do programador, aplicando apenas as common especificações e execute especificações ao nó de execução.
Por predefinição, as especificações serão executadas na ordem que são mostradas no modelo, executando as especificações herdadas primeiro. Order é um número inteiro opcional definido para um padrão de 1000, e pode ser usado para definir a ordem das especificações.
Se apenas um nome for especificado na definição [[[cluster-init]]] , será assumido como o nome de especificação. Por exemplo:
[[[cluster-init myspec]]]
Project = myproject
Version = 1.0.0
é uma configuração de especificações válida na qual Spec=myspec é implícita pelo nome.
run_list
Pode especificar uma lista de execução no projeto ou nível de especificações dentro do seu project.ini:
[spec scheduler]
run_list = role[a], recipe[b]
Quando um nó inclui a especificação "scheduler", o run_list definido será automaticamente anexado a qualquer lista de execução previamente definida. Por exemplo, se o meu run_list definido em baixo [configuration] fosse run_list = recipe[test], a lista final seria run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].
Também pode substituir uma lista de runlist ao nível de especificações num nó. Isto substituirá quaisquer run_list incluídos 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 candidaturas definida no projeto seria ignorada e as que precedem seriam utilizadas. A lista final no nó seria então run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init].
Nota
runlists são específicos para chef e não se aplicam de outra forma.
Localizações de arquivos
Os ficheiros do chef com fecho serão descarregados durante a fase de arranque do nó. Eles são descarregados para $JETPACK_HOME/system/chef/tarballs e desapertados para $JETPACK_HOME/system/chef/chef-repo/, e usados ao convergir o nó.
Nota
Para executar livros de receitas personalizados, deve especificá-los no run_list para o nó.
Os ficheiros cluster-init serão descarregados para /mnt/cluster-init/(project)/(spec)/. Para "my-project" e "my-spec", verá os seus scripts, ficheiros e testes localizados em /mnt/cluster-init/my-project/my-spec.
Projetos de Sincronização
Os projetos CycleCloud podem ser sincronizados a partir de espelhos para o armazenamento de nuvens locais do cluster. Desaver um atributo SourceLocker numa [cluster-init] secção dentro do seu modelo. O nome do cacifo especificado será usado como a fonte do projeto, e o conteúdo será sincronizado com o seu cacifo no início do cluster. Também pode usar o nome do cacifo como primeira parte do nome do cluster-init. Por exemplo, se o armário de origem era "cyclecloud", as duas definições seguintes 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 grandes
Os projetos suportam ficheiros grandes. Ao nível superior de um projeto recém-criado, você verá um diretório "blobs" para os seus grandes ficheiros (bolhas). Por favor, note que as bolhas colocadas neste diretório têm um propósito específico, e agirão de forma diferente dos itens dentro do diretório de "ficheiros".
Os itens dentro do diretório "blobs" são de especificações e versão independentes: qualquer coisa em "bolhas" pode ser partilhada entre especificações ou versões de projeto. Como exemplo, um instalador para um programa que muda raramente pode ser armazenado dentro de "blobs" e referenciado dentro do seuproject.ini. À medida que itera nas versões do seu projeto, esse ficheiro único permanece o mesmo e só é copiado para o seu armazenamento em nuvem uma vez, o que poupa no custo de transferência e armazenamento.
Para adicionar uma bolha, basta colocar um ficheiro no diretório "blobs" e editar o seu project.ini para fazer referência a esse ficheiro:
[blobs]
Files=big_file1.tgz
Quando utilizar o project upload comando, todas as bolhas referenciadas no project.ini serão transferidas para o armazenamento em nuvem.
Ficheiros de Registo
Os ficheiros de registo gerados ao executar o cluster-init estão localizados em $JETPACK_HOME/logs/cluster-init/(projeto)/(spec).
Executar ficheiros
Quando um script de cluster-init é executado com sucesso, um ficheiro é colocado em /mnt/cluster-init/.run/((spec) para garantir que não é executado novamente numa convergência subsequente. Se quiser voltar a executar o script, elimine o ficheiro apropriado neste diretório.
Diretórios de Script
Quando o CycleCloud executa scripts no diretório de scripts, irá adicionar variáveis ambientais ao caminho e nome das especificações e diretórios do 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 como se segue:
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 apenas
Para executar apenas os scripts de cluster-init:
jetpack converge --cluster-init
A saída do comando irá tanto para STDOUT como para jetpack.log. Cada script também terá a sua saída registada para:
$JETPACK_HOME/logs/cluster-init/(project)/(spec)/scripts/(script.sh).out
Chef personalizado e especificações composíveis
Cada especificação tem um diretório de chef nele. Antes de uma convergência, cada especificação será desatado e extraída para o chef-repo local, substituindo quaisquer livros de receitas, papéis e sacos de dados existentes com o mesmo nome. Isto é feito na ordem que as especificações são definidas, por isso, no caso de uma colisão de nomeação, a última especificação definida sempre vencerá.
download de jetpack
Para descarregar uma bolha dentro de um script de cluster-init, use o comando jetpack download (filename) para retirá-lo do diretório blobs. Executar este comando a partir de um script de cluster-init determinará o projeto e URL base para si. Para usá-lo num contexto não-cluster-init, você precisará especificar o projeto (ver -- ajuda para mais informações).
Para os utilizadores de chef, foi criado um jetpack_download LWRP:
jetpack_download "big-file1.tgz" do
project "my-project"
end
No chef, a localização de descarregamento padrão é #{node[:jetpack][:downloads]}. Para alterar o destino do ficheiro, utilize o seguinte:
jetpack_download "foo.tgz" do
project "my-project"
dest "/tmp/download.tgz"
end
Quando usado dentro do chef, você deve especificar o projeto.