Exporter (0) Imprimer
Développer tout

Format du fichier manifeste XML

Mis à jour: décembre 2013

Le fichier manifeste XML décrit le contenu du package et spécifie la façon dont le contenu du package est mappé à une structure de répertoire pour chaque rôle. En général, un fichier qui est déployé pour un rôle donné est nécessaire dans d'autres rôles. Le manifeste unique dans le nouveau format de package permet au créateur d'inclure le fichier dupliqué une seule fois, puis de décrire de façon déclarative comment déployer ce fichier vers plusieurs rôles. Le nouveau format de package simplifie la structure d'archive et permet aux créateurs de package d'optimiser les archives qui partagent des fichiers entre rôles ou au sein d'un même rôle. Il en résulte un package de plus petite taille qui peut permettre un déploiement plus rapide vers Windows Azure.

Par convention, le fichier manifeste XML est nommé package.xml. Toutefois, n'importe quel fichier de l'archive peut être utilisé comme manifeste XML tant que la relation pointe vers le fichier manifeste XML et que le fichier manifeste XML est conforme au schéma.

Cette rubrique décrit le format du fichier manifeste XML à l'aide d'exemples. Pour afficher le schéma du fichier manifeste XML, consultez Schéma du fichier manifeste XML.

Le format XML de base est le suivant :

<?xml version="1.0" encoding="utf-8"?>
<PackageDefinition xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/windowsazure">
  <PackageMetaData />
  <PackageContents />
  <PackageLayouts />
</PackageDefinition>

Voici l'espace de noms XML pour le fichier manifeste XML :

http://schemas.microsoft.com/windowsazure

Le manifeste XML contient trois sections. Chaque section est une collection de ressources nommées où tous les noms sont des URI relatifs spécifiés à l'aide de la syntaxe « a/b/c… ». Ces noms sont traités comme respectant la casse lors de la détermination de l'égalité et doivent respecter les conventions normales de codage et d'échappement propres aux URI. Cette rubrique décrit chacune des trois sections dans l'ordre qui suit :

PackageMetaData

La collection PackageMetaData est un magasin de clés/valeurs, où les clés et les valeurs sont des chaînes. Voici un exemple de collection PackageMetaData :

<PackageMetaData>
  <KeyValuePair>
    <Key>http://schemas.microsoft.com/windowsazure/ProductVersion/</Key>
    <Value>1.7.30308.2000 </Value>
  </KeyValuePair>
</PackageMetaData>

La somme des octets UTF-8 qui codent la clé et les valeurs ne doit pas dépasser 1 Mo. Les processeurs de package avec une quantité de métadonnées supérieure à 1 Mo peuvent être rejetés par n'importe quel processeur de package.

Pour éviter les conflits d'espace de noms, les clés de métadonnées doivent être des URI qui respectent les mêmes conventions que celles utilisées par les espaces de noms XML.

PackageContents

La collection PackageContents décrit les fichiers qui constituent le package. Cela comprend le nom du fichier, la longueur, un hachage sha256 facultatif du contenu et le chemin d'accès. Voici un exemple de collection PackageContents :

<PackageContents>
  <ContentDefinition>
    <Name>Content/Example/WithoutHash</Name>
    <ContentDescription>
      <LengthInBytes>123</LengthInBytes>
      <IntegrityCheckHashAlgortihm>None</IntegrityCheckHashAlgortihm>
      <IntegrityCheckHash/>
      <DataStorePath>File00</DataStorePath>
    </ContentDescription>
  </ContentDefinition>
  <ContentDefinition>
    <Name>Content/Example/WithHash</Name>
    <ContentDescription>
      <LengthInBytes>123</LengthInBytes>
      <IntegrityCheckHashAlgortihm>Sha256</IntegrityCheckHashAlgortihm>          <IntegrityCheckHash>AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8=</IntegrityCheckHash>
      <DataStorePath>File01</DataStorePath>
    </ContentDescription>
  </ContentDefinition>
</PackageContents>

Un élément de contenu est un flux nommé d'octets et de ressources d'objet blob de contenu sans limite de taille. Ce flux d'octets peut éventuellement disposer d'un contrôle d'intégrité afin de vérifier que les octets ont été correctement transportés sans altération.

Les valeurs valides pour l'élément IntegrityCheckHashAlgortihm sont None et Sha256. Si None est spécifié, l'élément IntegrityCheckHash doit être l'élément vide. Pour Sha256, la chaîne doit être un codage en base 64 d'octets de hachage. Cette chaîne doit être un type XSD xs:base64Binary.

Les noms sont des URI relatifs et sont traités comme respectant la casse. Chaque élément de contenu comprend un élément DataStorePath. Il s'agit d'un URI relatif qui fait référence au flux d'octets dans l'archive OPC de cet élément. Le nom de DataStorePath est arbitraire. Pour faciliter le désempaquetage et le réempaquetage des fichiers OPC sur différents systèmes de fichiers, veillez à ce que les noms des éléments OPC soient au format US-ASCII et à ce qu'ils soient uniques lorsque la casse n'est pas prise en compte. Vous devez aussi utiliser des noms courts afin de ne pas dépasser les limites imposées aux chemins d'accès du système de fichiers.

PackageLayouts

La collection PackageLayouts mappe des ressources de contenu à une disposition spécifique de fichiers et de répertoires sur une machine virtuelle Windows Azure. La disposition de fichiers inclut les heures de création et de modification, ainsi qu'un chemin relatif. Les chemins d'accès doivent être considérés comme étant spécifiques à un système de fichiers cible donné. La syntaxe du chemin d'accès étant dépendante du système d'exploitation, elle doit être traitée comme une valeur opaque. Les dispossitions étant simplement une description du mappage, la taille d'une disposition est proportionnelle au nombre de fichiers dans la disposition et non à la taille du contenu. Cela signifie que les auteurs de package peuvent éventuellement inclure d'autres dispositions par la suite (par exemple, une disposition qui cible Linux et une qui cible le système d'exploitation Windows), puis générer des packages agnostiques du système d'exploitation. Toutefois, dans la version 1.7 du Kit de développement logiciel Windows Azure SDK, les packages doivent respecter les conventions Windows.

La collection PackageLayouts mappe le contenu des packages à une disposition spécifique de fichiers et de répertoires sur une machine virtuelle Windows Azure. Les dispositions de package sont nommées, et plusieurs dispositions peuvent être associées à un même package. Chaque disposition explique comment extraire le flux d'octets d'un élément de contenu de package dans un fichier sur un système de fichiers cible. Chaque disposition est une liste de chemins d'accès de fichiers uniques respectant les conventions d'affectation de noms du système de fichiers cible. Les auteurs de package peuvent éventuellement inclure d'autres dispositions et générer des packages agnostiques du système d'exploitation. Par exemple, un package peut inclure une disposition qui cible Linux et une qui cible Windows. La disposition inclut également les métadonnées des fichiers, telles que les heures de création et de modification UTC, ainsi que les attributs de lecture seule.

L'exemple suivant d'une collection PackageLayouts contient deux dispositions nommées fileCollection1 et fileCollection2. Ces deux dispositions décrivent la création de deux fichiers à partir des ressources de package Content/Example/WithoutHash et Content/Example/WithHash. Toutefois, elles mappent le contenu à des noms de fichier différents. Dans fileCollection1, les noms de fichier sont uniques en ce qui concerne la casse. Dans fileCollection2, les noms diffèrent uniquement par la casse. Cet exemple illustre un format d'empaquetage conçu de manière agnostique. Il montre aussi que les auteurs de package créant des dispositions de fichier doivent avoir connaissance des conventions du système de fichiers cible. La deuxième disposition de fichier, fileCollection2, peut uniquement être extraite sur un système d'exploitation dont le système de fichiers respecte la casse. Notamment, la chaîne codée dans l'argument FilePath est traitée comme une clé opaque lorsque la casse est prise en compte.

<PackageLayouts>
    <LayoutDefinition>
      <Name>fileColletion1</Name>
      <LayoutDescription>
        <FileDefinition>
          <FilePath>Readme.txt</FilePath>
          <FileDescription>
            <DataContentReference>Content/Example/WithoutHash</DataContentReference>
            <CreatedTimeUtc>2012-02-01T01:16:33.9633733Z</CreatedTimeUtc>
            <ModifiedTimeUtc>2012-02-01T01:16:33.9643734Z</ModifiedTimeUtc>
            <ReadOnly>false</ReadOnly>
          </FileDescription>
        </FileDefinition>
        <FileDefinition>
          <FilePath>ReadmeToo.txt</FilePath>
          <FileDescription>
            <DataContentReference>Content/Example/WithHash</DataContentReference>
            <CreatedTimeUtc>2012-02-01T01:16:33.9643734Z</CreatedTimeUtc>
            <ModifiedTimeUtc>2012-02-01T01:16:33.9643734Z</ModifiedTimeUtc>
            <ReadOnly>false</ReadOnly>
          </FileDescription>
        </FileDefinition>
      </LayoutDescription>
    </LayoutDefinition>
    <LayoutDefinition>
      <Name>fileColletion2</Name>
      <LayoutDescription>
        <FileDefinition>
          <FilePath>README</FilePath>
          <FileDescription>
            <DataContentReference>Content/Example/WithoutHash</DataContentReference>
            <CreatedTimeUtc>2012-02-01T01:16:33.9643734Z</CreatedTimeUtc>
            <ModifiedTimeUtc>2012-02-01T01:16:33.9643734Z</ModifiedTimeUtc>
            <ReadOnly>false</ReadOnly>
          </FileDescription>
        </FileDefinition>
        <FileDefinition>
          <FilePath>Readme</FilePath>
          <FileDescription>
            <DataContentReference>Content/Example/WithHash</DataContentReference>
            <CreatedTimeUtc>2012-02-01T01:16:33.9643734Z</CreatedTimeUtc>
            <ModifiedTimeUtc>2012-02-01T01:16:33.9643734Z</ModifiedTimeUtc>
            <ReadOnly>false</ReadOnly>
          </FileDescription>
        </FileDefinition>
      </LayoutDescription>
    </LayoutDefinition>
  </PackageLayouts>

Voir aussi

Afficher:
© 2015 Microsoft