web-dev-qa-db-fra.com

Comment préparer MAAS à la diffusion d'images sur OpenStack?

J'ai Openstack prêt avec MAAS , comment préparer le cloud avec des images Ubuntu afin de pouvoir le déployer avec Juju?

jujumaasopenstack
5
Jorge Castro

Préparation de MAAS pour Juju et OpenStack à l'aide de Simplestreams

Lorsque Juju démarre un nuage, il a besoin de deux informations essentielles:

  1. L'outil de l'image à utiliser lors du démarrage de nouvelles instances de calcul.
  2. L'URL à partir de laquelle télécharger la version correcte d'une archive d'outils.

Ces informations nécessaires sont stockées dans un format de métadonnées JSON appelé "simplestreams". Pour les services de cloud public pris en charge tels que Amazon Web Services, HP Cloud, Azure, etc., aucune action n'est requise de la part de l'utilisateur final. Toutefois, ceux qui configurent un cloud privé ou qui souhaitent modifier le fonctionnement (par exemple, utiliser une image différente d'Ubuntu) peuvent créer leurs propres métadonnées, après en avoir compris un peu le fonctionnement.

Le format simplestreams est utilisé pour décrire les éléments associés de manière structurelle. Voir le projet Launchpad lp: simplestreams . Ci-dessous, nous verrons comment Juju détermine les métadonnées à utiliser et comment créer vos propres images et outils et que Juju les utilise à la place des valeurs par défaut.

Flux de travail de base

Qu'il s'agisse d'images ou d'outils, Juju utilise un chemin de recherche pour essayer de trouver les métadonnées appropriées. Les composants de chemin d'accès (dans l'ordre de recherche) sont les suivants:

  1. Emplacement fourni par l'utilisateur (spécifié par les paramètres tools-metadata-url ou image-metadata-url config).
  2. Stockage en nuage de l'environnement.
  3. Emplacements spécifiques du fournisseur (par exemple, point de terminaison de la distorsion trapézoïdale si Openstack).
  4. Un emplacement Web avec des métadonnées pour les clouds publics pris en charge - https://streams.canonical.com

Les métadonnées peuvent être signées en ligne ou non signées. Nous indiquons qu'un fichier de métadonnées est signé en utilisant l'extension '.sjson'. Les métadonnées signées sont d'abord recherchées dans chaque emplacement du chemin et, si aucune d'entre elles n'est trouvée, des métadonnées non signées sont tentées avant de passer à l'emplacement du chemin suivant.

Juju est livré avec des clés publiques utilisées pour valider l'intégrité des métadonnées des images et des outils obtenues de https://streams.canonical.com . Donc, Juju utilisera immédiatement n'importe quel nuage public pris en charge, à l'aide de métadonnées signées. La configuration de métadonnées pour un cloud privé (par exemple Openstack) nécessite la génération de métadonnées à l'aide d'outils fournis avec Juju.

Contenu des métadonnées de l'image

Les métadonnées d'image utilisent un type de contenu de flux les plus simples, "image-id". L'identifiant du produit est formé comme suit:

com.ubuntu.cloud:server:<series_version>:<Arch>

Par exemple:

com.ubuntu.cloud:server:14.04:AMD64

Les images non publiées (p. Ex. Bêta, quotidienne, etc.) ont des ID de produit tels que:

com.ubuntu.cloud.daily:server:13.10:AMD64

L'index de métadonnées et les fichiers de produit doivent obligatoirement se trouver dans l'arborescence suivante (par rapport à l'URL associée à chaque composant de chemin):

<path_url>
  |-streams
      |-v1
         |-index.(s)json
         |-product-foo.(s)json
         |-product-bar.(s)json

Le fichier d'index doit s'appeler "index. (S) json" (sjson pour signé). Les différents fichiers de produit sont nommés en fonction des valeurs de chemin contenues dans le fichier d'index.

Les métadonnées des outils utilisent un type de contenu simplestreams de "contenu-téléchargement". L'identifiant du produit est formé comme suit:

"com.ubuntu.juju:<series_version>:<Arch>"

Par exemple:

"com.ubuntu.juju:12.04:AMD64"

L'index de métadonnées et les fichiers de produit doivent obligatoirement se trouver dans l'arborescence suivante (par rapport à l'URL associée à chaque composant de chemin). En outre, les outils que Juju doit télécharger sont également attendus.

  |-streams
  |   |-v1
  |      |-index.(s)json
  |      |-product-foo.(s)json
  |      |-product-bar.(s)json
  |
  |-releases
      |-tools-abc.tar.gz
      |-tools-def.tar.gz
      |-tools-xyz.tar.gz

Le fichier d'index doit s'appeler "index. (S) json" (sjson pour signé). Le nom de l'archive du fichier de produit et des outils correspond à tout ce qui se trouve dans les fichiers d'index/produit.

Configuration

Pour les clouds publics pris en charge, aucune configuration supplémentaire n'est requise. les choses fonctionnent immédiatement. Toutefois, à des fins de test ou pour des déploiements dans le cloud non pris en charge, Juju doit savoir où trouver les outils et quelle image exécuter. Même pour les clouds publics pris en charge où toutes les métadonnées requises sont disponibles, l'utilisateur peut placer ses propres métadonnées dans le chemin de recherche pour remplacer ce qui est fourni par le cloud.

Celles-ci sont initialement spécifiées dans le fichier .juju/environments.yaml (puis copiées dans le fichier jenv lors du démarrage de l'environnement). Pour les images, utilisez image-metadata-url; pour les outils, utilisez tools-metadata-url. Les URL peuvent pointer vers un conteneur/compartiment lisible dans le monde dans le cloud, une adresse fournie par un serveur http ou même un répertoire partagé accessible à toutes les instances de nœud exécutées dans le cloud.

Supposons un serveur http Apache avec l'URL de base https://juju-metadata, donnant accès aux informations sur <base>/images et <base>/tools. Le fichier yaml de l’environnement Juju peut contenir les entrées suivantes (une ou les deux):

tools-metadata-url: https://juju-metadata/tools 
image-metadata-url: https://juju-metadata/images

Les fichiers requis à chaque emplacement correspondent à la structure de répertoires décrite précédemment. Pour un répertoire partagé, utilisez une URL de la forme file:///sharedpath.

Si aucune métadonnée correspondante n'est trouvée dans l'URL spécifiée par l'utilisateur, la recherche dans le stockage en nuage de l'environnement est effectuée. Aucune configuration utilisateur n'est requise ici - tous les environnements Juju sont configurés avec un stockage en nuage qui est utilisé pour stocker des informations d'état, des charms, etc. La configuration du stockage en nuage dépend du fournisseur; pour les nuages ​​Amazon et Openstack, le stockage est défini par la valeur "compartiment de contrôle", pour Azure, la valeur "nom-compte-stockage" est pertinente.

La structure de répertoires (facultative) dans le stockage en nuage est la suivante:

  |-tools
  |   |-streams
  |       |-v1
  |   |-releases
  |
  |-images
      |-streams
          |-v1

Bien entendu, si seules les métadonnées d'image personnalisées sont requises, le répertoire des outils ne sera pas requis, et inversement.

Notez que si juju bootstrap est exécuté avec l'option --upload-tools, les outils et les métadonnées sont placés conformément à la structure ci-dessus. C'est pourquoi les outils sont alors disponibles pour Juju.

Les fournisseurs peuvent autoriser des emplacements supplémentaires à rechercher des métadonnées et des outils. Pour OpenStack, les noeuds finaux Keystone peuvent être créés par l'administrateur du cloud. Ceux-ci sont définis comme suit:

juju-tools la valeur décrite ci-dessus dans la table Outils de métadonnées. Le produit diffuse la valeur <chemin_url> comme décrit ci-dessus dans la section Contenu des métadonnées de l'image.

De la même manière, d'autres fournisseurs peuvent spécifier des emplacements, même si la mise en œuvre varie.

Il s’agit de l’emplacement par défaut utilisé pour rechercher des métadonnées d’image et d’outils. Il est utilisé si aucune correspondance n’a été trouvée précédemment dans l’un des emplacements ci-dessus. Aucune configuration utilisateur n'est requise.

Le déploiement d'un cloud privé pose deux problèmes principaux:

  1. Les identifiants d’image seront spécifiques au nuage.
  2. Souvent, l'accès Internet externe est bloqué

Le problème 1 signifie que les métadonnées d’identité d’image doivent être générées et mises à disposition.

Le problème 2 signifie que les outils doivent être mis en miroir localement pour les rendre accessibles.

Les outils Juju existent pour vous aider à générer et valider des métadonnées d’image et d’outils. Pour les outils, il est souvent plus facile de simplement refléter https://streams.canonical.com/tools. Toutefois, les métadonnées d'image ne peuvent pas être simplement mises en miroir car les identifiants d'image proviennent du fournisseur de stockage en nuage. Ils doivent donc être générés et validés à l'aide des commandes décrites ci-dessous.

Les outils de métadonnées Juju disponibles sont visibles à l’aide de la commande help:

juju help metadata

Le flux de travail global est:

  • Générer des métadonnées d'image
  • Copier les métadonnées de l'image dans le chemin de recherche des métadonnées
  • Facultatif, miroir des outils sur quelque part dans le chemin de recherche de métadonnées
  • Configurez éventuellement tools-metadata-url et/ou image-metadata-url

Générer des métadonnées d'image à l'aide de

juju metadata generate-image -d <metadata_dir>

Au minimum, la commande ci-dessus doit connaître l'id de l'image à utiliser et un répertoire dans lequel écrire les fichiers.

D'autres paramètres requis, tels que la région, la série, l'architecture, etc., proviennent de l'environnement Juju actuel (ou d'un environnement spécifié avec l'option -e). Ces paramètres peuvent également être remplacés sur la ligne de commande.

La commande de métadonnées de l'image peut être exécutée plusieurs fois avec différentes régions, séries et architectures. Elle s'ajoute aux fichiers de métadonnées. Une fois que tous les identifiants d’image requis ont été ajoutés, les fichiers json d’index et de produit peuvent être téléchargés vers un emplacement situé dans le chemin de recherche des métadonnées Juju. Selon la section Configuration, cela peut être spécifié quelque part par le paramètre image-metadata-url ou par le stockage du cloud, etc.

Exemples:

  1. image-metadata-url

    • télécharger le contenu de sur http://somelocation
    • définir image-metadata-url sur http://somelocation/images

  2. Stockage en ligne

Si elle est exécutée sans paramètre, la commande de validation extraira tous les détails requis de l’environnement Juju actuel (ou comme spécifié par -e) et affichera l’ID d’image qu’elle utiliserait pour créer une instance. Vous pouvez également spécifier une série, une région, une architecture, etc. sur la ligne de commande pour remplacer les valeurs de la configuration de l'environnement.

Généralement, les outils et les métadonnées associées sont mis en miroir à partir de https://streams.canonical.com/tools. Cependant, il est possible de générer manuellement des métadonnées pour une archive d'outils personnalisée.

Tout d’abord, créez une archive des outils pertinents et placez-la dans un répertoire structuré comme suit:

<tools_dir>/tools/releases/

Générez maintenant des métadonnées pertinentes pour les outils en exécutant la commande:

juju generate-tools -d <tools_dir>

Enfin, le contenu de peut être téléchargé à un emplacement dans le chemin de recherche de métadonnées Juju. Selon la section Configuration, cela peut être spécifié quelque part par le paramètre tools-metadata-url ou les paramètres du chemin de stockage du cloud, etc.

Exemples:

  1. outils-metadata-url

    • télécharger le contenu du répertoire tools vers http://somelocation
    • définir tools-metadata-url sur http://somelocation/tools

  2. Stockage en ligne

télécharger le contenu directement sur le stockage en nuage de l'environnement

Comme pour les métadonnées d'image, la commande de validation est utilisée pour garantir que Juju dispose des outils suivants:

juju metadata validate-tools

Les mêmes commentaires s'appliquent. Exécutez l'outil de validation sans paramètres pour utiliser les détails de l'environnement Juju ou remplacez les valeurs requises sur la ligne de commande. Voir juju help metadata validate-tools pour plus de détails.

L'étape suivante:

9
Jorge Castro