Proyectos

Un proyecto es una colección de recursos que definen configuraciones de nodo. Los proyectos contienen especificaciones. Cuando se inicia un nodo, se configura mediante el procesamiento y la ejecución de una secuencia de especificaciones.

Azure CycleCloud usa proyectos para administrar aplicaciones agrupadas, como planificadores de ejecución por lotes. En CycleCloud HPCPack, el proyecto son las especificaciones de hn y cn que definen las configuraciones y recetas para el nodo principal y el nodo de proceso de HPCPack.

En la siguiente definición de nodo parcial, el nodo docker-registry ejecuta tres especificaciones: las especificaciones bind de la versión 1.3.0 del proyecto Okta, más las especificaciones core y registry de la versión 2.0.0 del proyecto 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]]]

La etiqueta final es el número de versión del proyecto:

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

Una caja de seguridad es una referencia a un contenedor de la cuenta de almacenamiento y su credencial. Los nodos tienen un locker predeterminado, por lo que este atributo no es estrictamente necesario.

Azure CycleCloud usa una abreviatura para las cuentas de almacenamiento, por lo que https://mystorage.blob.core.windows.net/mycontainer se puede escribir como az://mystorage/mycontainer.

El nodo usa la herramienta pogo para descargar cada proyecto al que hace referencia desde el locker:

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

Si un proyecto está definido en un nodo, pero no existe en la ubicación de almacenamiento esperada, el nodo notificará un Software Installation Failure a CycleCloud.

CycleCloud tiene proyectos internos que se ejecutan de forma predeterminada en todos los nodos para realizar un volumen especial y controlar la red y configurar la comunicación con CycleCloud. Se crean reflejos de estos proyectos internos automáticamente en la caja de seguridad.

El usuario es responsable de crear reflejo de los proyectos adicionales en la caja de seguridad. La CLI de CycleCloud tiene métodos para crear proyectos:

cyclecloud project init myproject

y crear reflejo de proyectos en cajas de seguridad:

cyclecloud project init mylocker

Las especificaciones se componen de scripts de Python, Shell o PowerShell.

Crear un nuevo proyecto

Para crear un nuevo proyecto, use el comando cyclecloud project init myproject de la CLI donde myproject es el nombre del proyecto que desea crear. myproject tiene una default especificación que puede cambiar. El árbol de directorios se crea con archivos de plantilla que tú modificas para incluir tu propia información.

Estructura de directorios

El comando del proyecto crea los directorios siguientes:

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

El directorio templates contiene las plantillas de clúster, mientras que las especificaciones contienen las especificaciones que definen el proyecto. Spec tiene dos subdirectorios: cluster-init y chef personalizado. Cluster-init contiene directorios con un significado especial, incluido el directorio scripts (contiene scripts que se ejecutan en orden lexicográfico en el nodo), archivos (contiene archivos de datos sin procesar que se colocan en el nodo) y pruebas (contiene pruebas que se ejecutan cuando se inicia un clúster en modo de prueba).

El subdirectorio custom chef tiene tres directorios: site-cookbooks (para las definiciones de la guía paso a paso), data_bags (definiciones de bolsas de datos) y roles (archivos de definición de roles de chef).

project.ini

_project.ini_ es el archivo que contiene todos los metadatos del proyecto. Puede contener:

Parámetro	Descripción
nombre	El nombre del proyecto y los guiones deben separar palabras; por ejemplo, order-66-2018.
etiqueta	Nombre del proyecto; Un nombre de clúster largo (con espacios) es para fines de visualización.
tipo	Tres opciones: programador, aplicación, <en blanco>. Este parámetro determina el tipo de proyecto y genera la plantilla adecuada. Predeterminada: aplicación
Versión	Formato: x.x.x

Armarios

El contenido del proyecto se almacena dentro de una caja de seguridad. Puede cargar el contenido del proyecto en cualquier caja de seguridad definida en la instalación de CycleCloud a través del comando cyclecloud project upload (locker), donde (locker) es el nombre de una caja de seguridad de almacenamiento en la nube en la instalación de CycleCloud. Esta caja de seguridad se establece como destino predeterminado. Como alternativa, puede ver qué casilleros están disponibles con el comando cyclecloud locker list. Los detalles sobre cualquier caja de seguridad específica se pueden ver con cyclecloud locker show (locker).

Si agrega más de un locker, puede establecer el valor predeterminado con cyclecloud project default_target (locker)y, a continuación, ejecutar cyclecloud project upload. También puede usar el comando cyclecloud project default locker (locker) -global para establecer un bloqueo predeterminado global para compartir entre proyectos.

Nota:

Los casilleros predeterminados se almacenan en el archivo de configuración de CycleCloud, normalmente ubicados en ~/.cycle/config.ini y no en el archivo deproject.ini . Esta configuración permite el control de versiones de project.ini.

Al cargar el contenido del proyecto, se comprimen los tres directorios de chef personalizados y se sincronizan tanto el chef personalizado como el cluster-init en la caja de seguridad de destino. Estos se almacenan dentro de:

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

Descarga de blobs

Use project download para descargar todos los blobs a los que se hace referencia en project.ini al directorio de blobs locales. El comando usa el parámetro [locker] e intenta descargar blobs enumerados en project.ini del locker al almacenamiento local. Se devuelve un error si no se pueden encontrar los archivos.

Configuración del proyecto

Especificaciones

Al crear un proyecto, se define una default especificación. Puede usar el cyclecloud project add_spec comando para agregar especificaciones adicionales al proyecto.

Versionamiento

De forma predeterminada, todos los proyectos tienen una versión de 1.0.0. Puede establecer una versión personalizada a medida que desarrolle e implemente proyectos estableciendo version=x.y.z en el archivo project.ini .

Por ejemplo, si locker_url es az://my-account/my-container/projects, el nombre del proyecto es "Order66", la versión es 1.6.9 y la especificación es default, la dirección URL es:

• 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

Bloques

Hay dos tipos de blobs: blobs de proyecto y blobs de usuario.

Blobs de proyectos

Los autores de proyectos proporcionan blobs de proyecto, que son archivos binarios que se pueden distribuir (es decir, archivos binarios para un proyecto de código abierto que alguien puede redistribuir legalmente). Los blobs del proyecto entran en el directorio blobs de un proyecto y se encuentran en /project/blobs cuando se cargan en una caja de seguridad.

Para agregar blobs a los proyectos, agregue los archivos a project.ini:

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

Se hay varios, se pueden separar mediante una coma. También puede especificar la ruta de acceso relativa al directorio de blobs del proyecto.

Blobs de usuario

Los blobs de usuario son archivos binarios, como archivos binarios de Univa Grid Engine, que el autor del proyecto no puede redistribuir legalmente. Estos archivos no se empaquetan con el proyecto y deben almacenarse provisionalmente en la caja de seguridad. Los archivos se encuentran en /blobs/my-project/my-blob.tgz. No es necesario definir blobs de usuario en project.ini.

Para descargar cualquier blob, use el comando jetpack download de la CLI o el recurso de Chef jetpack_download. CycleCloud busca primero el blob de usuario y usa el blob de nivel de proyecto si no encuentra el archivo.

Nota:

Es posible invalidar un blob de proyecto con un blob de usuario con el mismo nombre.

Especificar proyecto dentro de una plantilla de clúster

La sintaxis del proyecto permite especificar varias especificaciones en los nodos. Para definir un proyecto, use lo siguiente:

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

Nota:

El nombre especificado después spec puede ser cualquier cosa, pero puede y debe usarse como acceso directo para definir algunas propiedades comunes.

En el ejemplo siguiente se muestra cómo también puede aplicar varias especificaciones a un nodo determinado:

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

CycleCloud usa dos puntos para separar el nombre del proyecto, el nombre de especificación y la versión y analizar automáticamente esos valores en la configuración adecuada de Project/Version/Spec:

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

Las especificaciones también se pueden heredar entre nodos. Por ejemplo, puede compartir una especificación común entre todos los nodos y, a continuación, ejecutar una especificación personalizada en el nodo 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

Este proceso aplica tanto las especificaciones common como scheduler al nodo planificador, solo aplicando las especificaciones common y execute al arreglo de nodos execute.

De forma predeterminada, las especificaciones se ejecutan en el orden en que se muestran en la plantilla y las especificaciones heredadas se ejecutan primero. Order es un entero opcional con un valor predeterminado de 1000 que puede definir el orden de las especificaciones.

Si solo se especifica un nombre en la [[[cluster-init]]] definición, se supone que es el nombre de la especificación. La siguiente configuración de especificación es válida y donde el nombre indica Spec=myspec:

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

run_list

Puede especificar una lista de ejecución a nivel de proyecto o de especificación en project.ini:

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

Cuando un nodo incluye la scheduler especificación, el run_list definido se anexa automáticamente a cualquier run_list definido previamente. Por ejemplo, si el run_list definido en [configuration] era run_list = recipe[test], el run_list final es run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].

También puede sobrescribir un run_list en el nivel de especificación de un nodo. Esto reemplaza cualquier run_list incluido en project.ini. Por ejemplo, puede cambiar la definición del nodo a lo siguiente:

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

El uso de este run_list hace que se omita la run_list definida en el proyecto. El run_list final del nodo se convierte en run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init].

Nota:

Las listas de ejecución son específicas de chef y no se aplican en caso contrario.

Ubicación de archivos

Los archivos de Chef comprimidos se descargaron durante la fase de arranque del nodo. Se descargan en $JETPACK_HOME/system/chef/tarballs*, se descomprimen en $JETPACK_HOME/system/chef/chef-repo/, y se usan para hacer converger el nodo.

Nota:

Para ejecutar libros de cocina personalizados, debe especificarlos en el "run_list" del nodo.

Los archivos "cluster-init" se descargan en /mnt/cluster-init/(project)/(spec)/. Para my-project y my-spec, los scripts, los archivos y las pruebas se encuentran en /mnt/cluster-init/my-project/my-spec.

Sincronizar proyectos

Los proyectos de CycleCloud se pueden sincronizar desde espejos en el almacenamiento local en la nube del clúster. Establezca un atributo SourceLocker en una [cluster-init] sección dentro de la plantilla. El nombre de la caja de seguridad especificada se usa como origen del proyecto y el contenido se sincroniza con la caja de seguridad al iniciar el clúster. También puede usar el nombre de la caja de seguridad como la primera parte del nombre de cluster-init. Por ejemplo, si el casillero de origen es cyclecloud, las dos definiciones siguientes son las mismas:

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

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

Almacenamiento de archivos grandes

Los proyectos admiten archivos grandes. En la parte superior de un proyecto recién creado, encontrará un blobs directorio para los archivos grandes (blobs). Tenga en cuenta que los blobs colocados en este directorio tienen un propósito específico y actúan de forma diferente a los elementos del files directorio.

Los elementos del blobs directorio actúan independientemente de las especificaciones y versiones. Todo lo que haya en blobs se puede compartir entre especificaciones o versiones de proyecto. Por ejemplo, un instalador para un programa que cambia con poca frecuencia se puede almacenar en blobs y referenciarse dentro de project.ini. A medida que iteras en las versiones de tu proyecto, ese único archivo se mantiene igual y se copia una vez en el almacenamiento en la nube, lo que ahorra en los costos de transferencia y almacenamiento.

Para agregar un blob, coloque un archivo en el blobs directorio y edite el project.ini para hacer referencia a ese archivo:

[blobs]
  Files=big_file1.tgz

Cuando se usa el project upload comando , todos los blobs a los que se hace referencia en project.ini transferencia al almacenamiento en la nube.

Archivos de registro

Los archivos de registro generados al ejecutar cluster-init se encuentran en $JETPACK_HOME/logs/cluster-init/(project)/(spec).

Ejecutar archivos

Cuando un script cluster-init se ejecuta correctamente, se coloca un archivo en /mnt/cluster-init/.run/(project)/(spec) para garantizar que no se ejecute nuevamente durante una convergencia posterior. Si desea volver a ejecutar el script, elimine el archivo adecuado en este directorio.

Directorios de scripts

Cuando CycleCloud ejecuta scripts en el scripts directorio, agrega variables de entorno a la ruta de acceso y al nombre de los directorios spec y project.

CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH

En Linux, un proyecto denominado test-project con una especificación de default tiene las siguientes rutas de acceso:

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

Ejecución solo de scripts

Para ejecutar solamente los scripts de cluster-init:

jetpack converge --cluster-init

La salida del comando va a STDOUT y como jetpack.log. La salida de cada script también se registra en:

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

Custom chef y Composable Specs

Cada especificación contiene un directorio chef. Antes de una convergencia, cada especificación se descomprime y extrae en el repositorio chef-repo local, y reemplaza las guías paso a paso, los roles y las bolsa de datos existentes con los mismos nombres. Esto se hace en el orden en que se definen las especificaciones para que la última especificación definida siempre gana en el caso de un conflicto de nomenclatura.

Descargar Jetpack

Para descargar un blob dentro de un script cluster-init, use el comando jetpack download (filename) para extraerlo del blobs directorio. La ejecución de este comando desde un script cluster-init determina el proyecto y la dirección URL base automáticamente. Para usarlo en un contexto que no sea cluster-init, debe especificar el proyecto (consulte --help para obtener más información).

En el ejemplo siguiente se muestra cómo crear un jetpack_download proveedor de recursos ligero para los usuarios de Chef:

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

En chef, la ubicación de descarga predeterminada es #{node[:jetpack][:downloads]}. Para cambiar el destino del archivo, use lo siguiente:

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

Cuando se utiliza en Chef, es preciso especificar el proyecto.