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 en clúster, como programadores por lotes. En CycleCloud HPCPack, el proyecto es una hn especificación y cn especificación que definen las configuraciones y recetas para el nodo principal y el nodo de proceso de HPCPack.
A continuación se muestra una definición de nodo parcial. El nodo docker-registry ejecutará tres especificaciones: enlazar especificaciones de la versión 1.3.0 del proyecto okta, así como especificaciones básicas y del registro de la versión 2.0.0 del proyecto de 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 cuentas de almacenamiento y a una credencial. Los nodos tienen una caja de seguridad predeterminada, 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 descargará cada proyecto al que hace referencia desde la caja de seguridad mediante la herramienta pogo:
pogo get az://mystorage/mycontainer/projects/okta/1.3.0/bind
Si un proyecto se define en un nodo pero no existe en la ubicación de almacenamiento esperada, el nodo notificará a Software Installation Failure 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. Estos proyectos internos se reflejan automáticamente en la caja de seguridad.
El usuario es responsable de reflejar cualquier proyecto adicional en la caja de seguridad. La CLI de CycleCloud tiene métodos para crear proyectos:
cyclecloud project init myproject
y reflejo:
cyclecloud project init mylocker
proyectos en taquillas.
Las especificaciones se componen de scripts de Python, Shell o PowerShell.
Crear un nuevo proyecto
Para crear un proyecto, use el comando cyclecloud project init myprojectde la CLI , donde myproject es el nombre del proyecto que desea crear. Esto creará un proyecto denominado "myproject", con una sola especificación denominada "default" que puede cambiar. El árbol de directorios se creará con los archivos de esqueleto que modificará para incluir su propia información.
Estructura de directorios
El comando del proyecto creará los directorios siguientes:
\myproject
├── project.ini
├── blobs
├── templates
├── specs
│ ├── default
│ └── cluster-init
│ ├── scripts
│ ├── files
│ └── tests
│ └── chef
│ ├── site-cookbooks
│ ├── data_bag
│ └── roles
El directorio templates contendrá las plantillas de clúster, mientras que las especificaciones contendrán las especificaciones que definen el proyecto. La especificación tiene dos subdirectorios: cluster-init y chef personalizado. cluster-init contiene directorios que tienen un significado especial, como el directorio scripts (contiene scripts que se ejecutan en orden lexicográfico en el nodo), archivos (archivos de datos sin procesar que se colocarán en el nodo) y pruebas (contiene pruebas que se ejecutarán cuando se inicia un clúster en modo de prueba).
El subdirectorio chef personalizado tiene tres directorios: site-cookbooks (para definiciones de libros de cocina), data_bags (definiciones de databag) 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 |
|---|---|
| name | Nombre del proyecto. Las palabras deben estar separadas por guiones, por ejemplo, order-66-2018. |
| etiqueta | Nombre del proyecto. Nombre largo (con espacios) del clúster con fines de visualización. |
| tipo | Tres opciones: programador, aplicación, <en blanco>. Determina el tipo de proyecto y genera la plantilla adecuada. Valor predeterminado: aplicación |
| version | 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 establecerá como destino predeterminado. Como alternativa, puede ver qué taquillas están disponibles con el comando cyclecloud locker list. Los detalles sobre una caja de seguridad específica se pueden ver con cyclecloud locker show (locker).
Si agregas más de una caja de seguridad, puedes establecer el valor predeterminado con cyclecloud project default_target (locker), simplemente ejecuta cyclecloud project upload. También puede establecer una caja de seguridad predeterminada global que se pueda compartir mediante proyectos con el comando cyclecloud project default locker (locker) -global.
Nota
Las taquillas predeterminadas se almacenarán en el archivo de configuración cyclecloud (normalmente ubicado en ~/.cycle/config.ini), no en el project.ini. Esto se hace para permitir que project.ini se controlen las versiones.
Al cargar el contenido del proyecto, se comprimirán los directorios de chef y se sincronizarán tanto chef como cluster init en la caja de seguridad de destino. Estos se almacenarán en:
- (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 el project.ini al directorio de blobs local. El comando usa el [locker] parámetro e intentará descargar blobs enumerados en project.ini desde el almacén al almacenamiento local. Se devolverá un error si no se pueden encontrar los archivos.
Configuración del proyecto
Especificaciones
Al crear un proyecto, se define una sola especificación predeterminada. Puede agregar especificaciones adicionales al proyecto mediante el cyclecloud project add_spec comando .
Control de versiones
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" era "az://my-account/my-container/projects", el proyecto se denominaba "Order66", la versión era "1.6.9" y la especificación es "predeterminada", la dirección URL sería:
- 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
Datos BLOB
Hay dos tipos de blobs: blobs de proyecto y blobs de usuario.
Blobs de proyecto
Los blobs de proyecto son archivos binarios proporcionados por el autor del proyecto con la suposición de que se pueden distribuir (es decir, un archivo binario para un proyecto de código abierto que se le permite redistribuir legalmente). Los blobs de proyecto van al directorio "blobs" de un proyecto y, cuando se cargan en una caja de seguridad, se encuentran en /project/blobs.
Para agregar blobs a proyectos, agregue los archivos a la project.ini:
[[blobs optionalname]]
Files = projectblob1.tgz, projectblob2.tgz, projectblob3.tgz
Varios blobs 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 que el autor del proyecto no puede redistribuir legalmente, como archivos binarios UGE. Estos archivos no se empaquetan con el proyecto, sino que deben almacenarse provisionalmente en la caja de seguridad manualmente. Los archivos se ubicarán en /blobs/my-project/my-blob.tgz. No es necesario definir blobs de usuario en el project.ini.
Para descargar cualquier blob, use el jetpack download comando de la CLI o el jetpack_download recurso chef. CycleCloud buscará primero el blob de usuario. Si ese archivo no se encuentra, se usará el blob de nivel de proyecto.
Nota
Es posible invalidar un blob de proyecto con un blob de usuario con el mismo nombre.
Especificar el 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, will use default locker for node)
Nota
El nombre especificado después de "spec" puede ser cualquier cosa, pero puede y debe usarse como acceso directo para definir algunas > propiedades comunes.
También puede aplicar varias especificaciones a un nodo determinado de la siguiente manera:
[[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)
Al separar el nombre del proyecto, el nombre de la especificación y la versión con dos puntos, CycleCloud puede analizar esos valores automáticamente en la configuración adecuada 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 del 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
Esto aplicaría las common especificaciones y scheduler al nodo del programador, al mismo tiempo que solo aplica las common especificaciones y execute a la ejecución de nodearray.
De forma predeterminada, las especificaciones se ejecutarán en el orden en que se muestran en la plantilla, ejecutando primero las especificaciones heredadas. Order es un entero opcional establecido en un valor predeterminado de 1000 y se puede usar para 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. Por ejemplo:
[[[cluster-init myspec]]]
Project = myproject
Version = 1.0.0
es una configuración de especificación válida en la que Spec=myspec está implícito el nombre.
run_list
Puede especificar una lista de ejecución en el nivel de proyecto o especificación dentro de la project.ini:
[spec scheduler]
run_list = role[a], recipe[b]
Cuando un nodo incluye la especificación "scheduler", el run_list definido se anexará automáticamente a cualquier lista de ejecución definida previamente. Por ejemplo, si mi run_list definido en [configuration] era run_list = recipe[test], la lista de ejecución final sería run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].
También puede sobrescribir una lista de ejecución en el nivel de especificación de un nodo. Esto reemplazará cualquier run_list incluida en el project.ini. Por ejemplo, si cambiamos la definición del nodo a lo siguiente:
[cluster-init test-project:scheduler:1.0.0]
run_list = recipe[different-test]
La lista de ejecución definida en el proyecto se omitiría y, en su lugar, se usaría lo anterior. La lista de ejecución final del nodo sería 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 chef comprimidos se descargarán durante la fase de arranque del inicio del nodo. Se descargan en $JETPACK_HOME/system/chef/tarballs y se descomprimen en $JETPACK_HOME/system/chef/chef-repo/, y se usan al converger el nodo.
Nota
Para ejecutar libros de cocina personalizados, debe especificarlos en el run_list para el nodo.
Los archivos cluster-init se descargarán en /mnt/cluster-init/(project)/(spec)/. Para "my-project" y "my-spec", verá los scripts, los archivos y las pruebas ubicados en /mnt/cluster-init/my-project/my-spec.
Sincronizar proyectos
Los proyectos de CycleCloud se pueden sincronizar desde reflejos en el almacenamiento en la nube local del clúster. Establezca un atributo SourceLocker en una sección dentro de la [cluster-init] plantilla. El nombre de la caja de seguridad especificada se usará como origen del proyecto y el contenido se sincronizará con la caja de seguridad en el inicio del clúster. También puede usar el nombre de la caja de seguridad como primera parte del nombre cluster-init. Por ejemplo, si el almacén de origen era "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 el nivel superior de un proyecto recién creado, verá un directorio "blobs" para los archivos grandes (blobs). Tenga en cuenta que los blobs colocados en este directorio tienen un propósito específico y actuarán de forma diferente a los elementos del directorio "archivos".
Los elementos del directorio "blobs" son independientes de la especificación y la versión: cualquier elemento de "blobs" se puede compartir entre especificaciones o versiones del proyecto. Por ejemplo, un instalador de un programa que cambia con poca frecuencia se puede almacenar en "blobs" y hacer referencia a él dentro de laproject.ini. A medida que recorre en iteración las versiones del proyecto, ese único archivo permanece igual y solo se copia en el almacenamiento en la nube una vez, lo que ahorra en el costo de transferencia y almacenamiento.
Para agregar un blob, basta con colocar un archivo en el directorio "blobs" y editar el project.ini para hacer referencia a ese archivo:
[blobs]
Files=big_file1.tgz
Al usar el project upload comando , todos los blobs a los que se hace referencia en el project.ini se transferirán 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 asegurarse de que no se ejecuta de nuevo en una convergente posterior. Si desea volver a ejecutar el script, elimine el archivo adecuado en este directorio.
Directorios de script
Cuando CycleCloud ejecuta scripts en el directorio scripts, agregará variables de entorno a la ruta de acceso y el nombre de los directorios de especificación y proyecto:
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" tendría rutas de acceso de la siguiente manera:
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
Ejecutar solo scripts
Para ejecutar SOLO los scripts cluster-init:
jetpack converge --cluster-init
La salida del comando irá a STDOUT, así como a jetpack.log. Cada script también tendrá su salida registrada en:
$JETPACK_HOME/logs/cluster-init/(project)/(spec)/scripts/(script.sh).out
Especificaciones de chef y composable personalizadas
Cada especificación tiene un directorio chef en él. Antes de una convergente, cada especificación se eliminará y extraerá en el repositorio chef-repo local, reemplazando los libros de cocina, roles y bolsas de datos existentes con los mismos nombres. Esto se hace en el orden en que se definen las especificaciones, por lo que en el caso de una colisión de nomenclatura, la última especificación definida siempre ganará.
descarga de jetpack
Para descargar un blob dentro de un script cluster-init, use el comando jetpack download (filename) para extraerlo del directorio de blobs. La ejecución de este comando desde un script cluster-init determinará el proyecto y la dirección URL base automáticamente. Para usarlo en un contexto que no sea cluster-init, deberá especificar el proyecto (consulte --help para obtener más información).
Para los usuarios de chef, se ha creado un jetpack_download LWRP:
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 usa en chef, debe especificar el proyecto.