Partager via


Cmdlets PowerShell Web Deploy

par Shaikh Owais

Web Deploy V3.0 est fourni avec des cmdlets PowerShell pour effectuer la plupart des tâches prises en charge par l’API Web Deploy [Microsoft.Web.Deployment]. Découvrez-en plus sur l’API ici. Ces cmdlets se trouvent dans le composant logiciel enfichable nommé WDeploySnapin3.0 qui est installé et inscrit en tant que composant logiciel enfichable sur une installation classique ou ultérieure du déploiement web. Pour utiliser ces cmdlets, ajoutez le composant logiciel enfichable chaque fois que la console PowerShell est démarrée ou ajoutez le composant logiciel enfichable au profil PowerShell pour que toutes les consoles chargent automatiquement le composant logiciel enfichable.

Pour l’ajouter lorsque la console PowerShell est chargée, exécutez la commande suivante dans la fenêtre de la console :

Add-PSSnapin WDeploySnapin3.0

Pour l’ajouter au profil PowerShell, exécutez la commande suivante dans la fenêtre de la console :

  1. Si vous disposez déjà d’un profil PowerShell, rendez vous directement à l’étape 4.
  2. Créez un dossier WindowsPowerShell sous <Mes documents>.
  3. Créez un fichier appelé Microsoft.PowerShell_profile.ps1
  4. Ajoutez cette ligne au fichier de profil PowerShell : « Add-PSSnapin WDeploySnapin3.0 »

Quelques points à noter :

  1. La console PowerShell s’exécute en 64 bits sur les systèmes 64 bits et s’exécute dans .Net 2.0, sauf jusqu’à Windows8. Si vous rencontrez des problèmes liés à l'un de ces éléments ou aux deux, reportez-vous à la section de résolution des problèmes pour trouver des solutions.
  2. Toutes les cmdlets qui créent un package Web Deploy créent des paramètres pour les tâches les plus courantes et les cmdlets qui le consomment acceptent les valeurs de paramètre.
  3. Il n’existe qu’une seule cmdlet pour supprimer un site ou une application en dessous.
  4. Web Deploy a des paramètres, mais ils sont orthogonaux aux paramètres d’applet de commande PowerShell. Lorsque des paramètres sont référencés dans ce document, cela implique des paramètres de cmdlets. Les paramètres Web Deploy ont été spécifiquement appelés paramètres Web Deploy.

I. Fichier de paramètres de publication

Toutes les cmdlets fournies ci-dessous peuvent s’exécuter sur un artefact distant, tel qu’un serveur distant ou une base de données distante. Vous aurez néanmoins besoin d’autre informations en plus des informations de connexion. Par exemple, vous avez besoin du nom du serveur distant, de la chaîne de connexion aux bases de données distante, de savoir si vous souhaitez autoriser la publication sur un serveur avec un certificat de test, etc. Pour faciliter l’utilisation, le transfert d’informations d’identification de l’administrateur du serveur vers le consommateur, etc. un nouveau type de fichier regroupant ces paramètres a été créé. Ce fichier est appelé fichier de paramètres de publication se terminant par .publishsettings. Il est utilisé par Visual Studio pour la publication ainsi que par WebMatrix.

Pour pouvoir créer un tel fichier qui sera utilisé par d’autres cmdlets et pour pouvoir le modifier, vous pouvez utiliser la commande New-WDPublishSettings. Si aucun nom de fichier n’est spécifié, il crée un fichier dans votre répertoire de documents avec le nom <new guid>.publishsettings. Ce chemin d’accès s’affiche lorsque le fichier est créé. Si un nom de fichier est spécifié et que le fichier n’existe pas, il sera créé comme décrit ci-dessus dans le dossier spécifié par le chemin d’accès. Néanmoins, le chemin d’accès au fichier doit être valide. Si le fichier existe, seules les valeurs des attributs que vous avez spécifiés lors de l'exécution de la commande seront modifiées, à l'exception des attributs du fichier qui sont inconnus et qui seront supprimés

Exemple : cet exemple obtient un objet d’informations d’identification, puis le transmet à la nouvelle cmdlet de fichier de paramètres de publication, ainsi qu’à d’autres paramètres

$cred = Get-Credential
New-WDPublishSettings -ComputerName owais-1 -Site Site1 -Credentials $cred -AllowUntrusted -SiteUrl "https://www.mywebsite.com" -FileName C:\pprofiles\mywebsite.publishsettings -AgentType wmsvc
Get-WDPublishSettings cmdlet allows to load values from a publish setting file into PublishSettings object.
$publishsettings=Get-WDPublishSettings C:\pprofiles\mywebsite.publishsettings

II. Sauvegarde

Toutes les cmdlets de sauvegarde ont un paramètre positionnel (il s’agit du deuxième, à l’exception de backup-wdserver où il s’agit du premier paramètre positionnel) appelé sortie. Cela prend un chemin d’accès au dossier dans lequel vous souhaitez créer la sauvegarde. La sauvegarde est toujours un package zip Web Deploy. Vous pouvez en savoir plus sur les packages de déploiement web sur le fournisseur de packages. Si aucun chemin d’accès n’est spécifié, les sauvegardes sont créées dans un dossier nommé « Copie de sauvegarde Web Deploy » sous le dossier documents de l’utilisateur. Les copies sauvegarde sont nommées machinename_nameofproviderused_[Siteorapporfoldername(Optional)]_timestamp.zip.

Toutes ces cmdlets fonctionnent localement par défaut, sauf si les informations du serveur distant sont fournies en transmettant un fichier de paramètres de publication pour le paramètre SourcePublishSettings.

A. IIS

Toutes les cmdlets IIS fonctionnent sur IIS 7 ou sur les versions ultérieures

1. Server (Serveur)

Backup-WDServer

Description : Cette commande, sans aucun argument, sauvegarde le serveur actuel sur lequel elle est exécutée. Il utilise le fournisseur de serveur web connu pour cette opération. Par conséquent, le package créé contient tous les artefacts qui seraient contenus dans un package de serveur web. Pour en savoir plus sur ce fournisseur, cliquez ici.

Paramètres de la cmdlet : le paramètre ConfigOnly vous permet d’exclure tout le contenu tandis que les paramètres SkipFileList et SkipFolderList vous permettent d’exclure de manière sélective un ou plusieurs fichiers ou dossiers du package.

Exemples :

Cela sauvegarde tous les éléments du serveur web à l’exception du contenu :

Backup-WDServer -SourcePublishSettings c:\profiles\myserver.publishsettings -ConfigOnly

Créez une liste des fichiers qui doivent être ignorés. Il s’agit d’expressions régulières standard.

$list = @('\\site2\\iisstart.htm','\\site2\\welcome.png')
Backup-WDServer –SkipFileList $list

Vous pouvez également modifier cette option pour ignorer tous les fichiers sous site2 en modifiant la liste en $list=@('\site2\')

2. Site

Backup-WDSite

Description : Cette opération sauvegarde un site IIS avec ses paramètres et son contenu à l’aide du fournisseur apphostconfig. Pour en savoir plus sur ce fournisseur, cliquez ici.

Paramètres de la cmdlet : le nom du site spécifié par le paramètre de site ou par le fichier de paramètres de publication est sauvegardé. La valeur du paramètre de site remplace la spécification des paramètres de publication pour le nom du site.

ConfigOnly peut être utilisé pour créer une sauvegarde sans contenu. Si le site utilise un pool d’applications autre que celui par défaut, utilisez le paramètre switch includeAppPool pour que ce package fonctionne sur d’autres serveurs qui n’ont peut-être pas le même pool d’applications. Cela regroupe le pool d’applications dans le package.

Paramètres de déploiement web générés automatiquement : deux types de paramètres sont créés :

  1. Un paramètre permettant à l’utilisateur de modifier le nom du site sur lequel la sauvegarde du site sera appliqué.
  2. Un autre paramètre permettant à l’utilisateur de modifier le chemin physique du site et chaque application web sous ce site sera appliqué.

Par conséquent, si j’ai un site avec trois applications en dessous, j’obtiendrai 4 paramètres de chemin d’accès physique à part et un paramètre de nom de site.

Exemples :

Backup-WDSite "Default Web Site" -ConfigOnly
Backup-WDSite MySite –IncludeAppPool
Backup-WDSite MySite -SkipFileList $list

3. Application web

Backup-WDApp

Description : cette opération sauvegarde une application web à l’aide du fournisseur iisApp. Pour en savoir plus sur ce fournisseur, cliquez ici. Voici un bon article qui explique ce qu’est une application web et quelle est la différence entre un site, une application et un répertoire virtuel dans IIS.

Paramètres de la cmdlet : le nom du site spécifié par le paramètre de site ou par le fichier de paramètres de publication est sauvegardé. Si aucun d'entre eux n'est spécifié, une erreur est générée. La valeur du paramètre de l’application remplace la spécification des paramètres de publication pour le nom du site. Les paramètres SkipFileList et SkipFolderList vous permettent d’exclure sélectivement un ou plusieurs fichiers ou dossiers du package.

Paramètres de déploiement web générés automatiquement : création d’un paramètre permettant de modifier le nom de l’application ou du site lors de la restauration ou de l’installation.

$list = @('\\iisstart\.htm')
Backup-WDApp "Default web site/app" -SkipFileList $list

B. Base de données

1. MSSql

Backup-WDSqlDatabase

Description : Sauvegarde d’une base de données Microsoft SQL Server à l’aide du fournisseur dbfullsql. Ce fournisseur utilise SMO pour générer un script sur la base de données et expose plus de 100 paramètres de fournisseur pour contrôler la façon dont la base de données est scriptée. Ceci est abordé en détail ici.

Paramètres de la cmdlet : sauvegarde de la chaîne de connexion spécifiée par le paramètre de base de données ou SQLServerDBConnectionString dans le fichier de paramètres de publication. La valeur du paramètre de base de données remplace la spécification des paramètres de publication pour SQLServerDBConnectionString. Les paramètres du fournisseur exposés par ce fournisseur dbfullsql peuvent être transmis à l’aide du paramètre SourceSettings. scriptdropsfirst est un paramètre très utilisé qui si l'objet existe, dépose les scripts de l'objet. Un autre paramètre fournisseur des options de script SMO consiste à définir scriptdata sur false pour extraire simplement le schéma.

Paramètres de déploiement web générés automatiquement : un paramètre est créé pour modifier la chaîne de connexion aux bases de données lors de la restauration ou de l’installation

Exemples :

New-WDPublishSettings -ComputerName serverName -MSSqlConnectionString "Data Source=localhost;Initial Catalog=MyDb;User id=MyDbUser;Password=MyPassword" -FileName d:\SQLdb.PublishSettings -Credential serverName\Administrator
Backup-WDSQLDatabase -SourcePublishSettings D:\SQLdb.PublishSettings
Backup-WDSQLDatabase -Database "Data Source=localhost;Initial Catalog=MyDb;User id=MyDBUser;Password=MyPassword" -SourceSettings @{ copyAllUsers='false'; scriptDropsFirst='true'; }

2. MySql

Backup-WDMySQLDatabase

Description : Cette opération sauvegarde une base de données MySql Server à l’aide du fournisseur dbmysql. Ce fournisseur utilise mysqldump pour générer un script sur la base de données. Ceci est abordé en détail ici.

Paramètres de la cmdlet : sauvegarde de la chaîne de connexion spécifiée par le paramètre de base de données ou mySQLDBConnectionString dans le fichier de paramètres de publication. La valeur du paramètre de base de données remplace la spécification des paramètres de publication pour mySQLDBConnectionString. Les paramètres du fournisseur peuvent être transmis à l’aide du paramètre SourceSettings. Les paramètres couramment utilisés sont includeData et includeSchema. Par défaut, ces valeurs sont définies sur true.

Paramètres de déploiement web générés automatiquement : un paramètre est créé pour modifier la chaîne de connexions aux bases de données lors de la restauration ou de l’installation

New-WDPublishSettings -ComputerName serverName -MySqlConnectionString "Data Source=localhost;database=MyDb;Uid=MyDbUser;pwd=MyPassword" -FileName d:\MySQLdb.PublishSettings -Credential serverName\Administrator
Backup-WDMySQLDatabase -Database 'Server=localhost;Database=MyDb;Uid=MyDbUser;pwd=MyPassword’
Backup-WDMySqlDatabase –SourcePublishSettings d:\mysqldb.publishsettings

III. Restaurer

Toutes les cmdlets de restauration prennent le package Web Deploy à restaurer comme premier paramètre positionnel.

WebDeploy prend en charge le concept de paramétrage des packages, ce qui vous permet de modifier quelques aspects lors de la restauration (sans modifier le package). Par exemple, lors de la restauration, vous pouvez choisir de spécifier la valeur de la chaîne de connexions aux bases de données qui est différente de celle contenue dans le package à l'aide des paramètres WebDeploy (votre package doit contenir un paramètre de chaîne de connexion.)

Selon la façon dont le package a été généré, le package Web Deploy peut avoir un ou plusieurs paramètres. Ces cmdlets de restauration inspectent le package et ajoutent des paramètres PowerShell dynamiques à la collection. Par conséquent, si un package contient un paramètre Web Deploy nommé « Parameter1 », vous trouverez un paramètre PowerShell portant le nom « Parameter1 ». Toutefois, les paramètres dynamiques présentent leurs propres problèmes dans PowerShell et cela fonctionne uniquement s’il n’y a pas d’espace dans le nom des packages ou dans le chemin d’accès au fichier.

Toutes ces cmdlets de restauration ont également un paramètre « Parameters » qui vous permet de spécifier manuellement de nouvelles valeurs de paramètre lors de la restauration. Ce paramètre « Parameters » prend l’objet Dictionnaire PowerShell pour les paires de valeurs de nom des paramètres Web Deploy.

Pour connaître les paramètres Web Deploy définis dans n’importe quel package Web Deploy, vous pouvez simplement ouvrir le fichier zip dans l’Explorateur Windows et examiner le fichier parameters.xml présent à la racine du package. Tout paramètre Web Deploy qui n’a pas de valeur par défaut ou de valeur doit être spécifié. Ajoutez tous ces paramètres dans un fichier xml et transmettez-le en tant que valeur pour le paramètre ParameterValuesFile. Vous pouvez générer ce fichier comme indiqué ici ou le générer manuellement. Son format est le suivant

<parameters>
  <setParameter name="name1" value="value1" />
  <setParameter name="name2" value="value2" />
</parameters>

La cmdlet Get-WDParameters peut lire ce fichier et le convertir en objet de paramètres WebDeploy (dictionnaire), qui est accepté par toutes les cmdlets de restauration.

Si un package est restauré sans spécifier de valeur pour les paramètres qu'il contient, le comportement par défaut sera d'écraser les ressources à partir desquelles le package a été créé à l'origine. Par exemple, si je crée un package à partir de site1 à l’aide de backup-wdsite site1, lorsque je restaure ce package à l’aide de la cmdlet de restauration sans fournir de valeurs aux paramètres de ce package, site1 est remplacé par ce que contient le package, aussi bien le contenu et que la configuration. Il en va de même pour toutes les cmdlets de restauration.

Toutes ces cmdlets restaurent localement, sauf lorsque le fichier de paramètres de publication de destination est spécifié, auquel cas la même opération se produit sur un serveur distant via le service de gestion web (WMSvc) ou le service Web Deployment Agent.

A. IIS

1. Server (Serveur)

Restore-WDServer

Description : restaure un package de serveur web. Généralement, on sauvegarde un serveur avant d’apporter une modification et en cas de défaillance, le serveur peut être rétabli en appliquant le package de sauvegarde Web Deploy créé avant d’effectuer les modifications.

$folderList = @(‘\\app_data’)
Restore-WDServer D:\OWAIS-1_WebServer_20120419121214.zip -DestinationPublishSettings c:\destinationServer.publishSettings –SkipFolderList $folderList

2. Site

Restore-WDSite

Description : restaure un package de site IIS. Si le package a deux paramètres nommés « Chemin physique du site » et « Nom du site », ils sont exposés en tant que paramètre PowerShell dynamique SitePhysicalPath et SiteName. Cette commande crée un site site1 avec un c:\site1chemin d’accès physique. Si aucune valeur n’est spécifiée pour ces paramètres, la restauration s’applique au même site et au même contenu, en remplaçant les modifications que vous pouvez avoir sur le site.

Paramètres : vous pouvez utiliser skipfolderlist et skipfilelist pour empêcher certains dossiers et/ou fichiers d’être copiés dans le contenu du site.

Restore-WDSite C:\defaultsite.zip -SitePhysicalPath c:\site1 -SiteName site1
Restore-WDSite -Package 'D:\Users\Administrator\Documents\Web Deploy Backups\IIS-Server_AppHostConfig_Default Web Site_20120417100827.zip' -skipFolderList @('App_Data')  -verbose

3. Application

Restore-WDApp

Description : cette opération restaure une application web. Backup-WDApp crée un package avec un paramètre pour modifier le nom de l’application au moment de l’installation. Cette opération peut être utilisée pour restaurer l’application dans une autre application lors de la restauration. Le site doit exister lors du déploiement sur une application sous un site. L’application sera créée par ce package, mais le site ne sera pas créé.

Exemples :

Restore-WDApp C:\myappbackup.zip -ApplicationPathParam1 "Default web site\app1"

B. Base de données

Restore-WDDatabase

Description : si la base de données n'existe pas, cette opération crée une nouvelle base de données appelée « clients » (pour autant que l'utilisateur actuel dispose des autorisations nécessaires à cette opération) et exécute le script sur cette base. Si cette opération est exécutée sans aucune valeur pour les paramètres de déploiement dynamique de Web Deploy, la base de données originale à partir de laquelle ce package a été créé sera écrasée. Notez que si le paramètre scriptDropsFirst n’a pas été utilisé lors de la création du package, l’application à une base de données avec du contenu existant en conflit échoue. Cette cmdlet peut être utilisée pour restaurer une sauvegarde MSSql ou MySQL. Vous pouvez uniquement restaurer une base de données MS SQL avec une sauvegarde créée à l’aide de Backup-WDSQLDatabase et avec une sauvegarde Backup-WDMySqlDatabase pour Ma base de données SQL.

Exemples :

Backup-WDSqlDatabase "server=.\sqlexpress;integrated security=SSPI;database=customers" "C:\dbbackup.zip"
Restore-WDDatabase c:\dbbackup.zip –DatabaseConnectionStringParam1 "server=.\sqlexpress;integrated security=SSPI;database=customers_copy"
Backup-WDMySqlDatabase "server=localhost;uid=someuser;pwd=somepwd;database=coolDb" "C:\dbbackup.zip"
Restore-WDDatabase c:\dbbackup.zip –DatabaseConnectionStringParam1 "server=localhost;uid=someuser;pwd=somepwd;database=coolDb_copy"

C. Package générique

Restore-WDPackage

Description : cette cmdlet peut être utilisée pour appliquer n’importe quel package Web Deploy. Il existe plusieurs façons de créer ou d’obtenir un package Web Deploy, par exemple en téléchargeant un package galerie d’applications open source, en créant un package dans Visual Studio, à l’aide de l’outil en ligne de commande msdeploy.exe (plus d’informations ici) ou en utilisant les cmdlets Backup-WD* mentionnées précédemment dans ce document. Par exemple, pour installer wordpress sur un site web IIS Server Default en tant qu’application nommée wordpress, il faut télécharger le package wordpress à partir de la galerie d’applications dans un dossier appelé packages. Toutes les valeurs par défaut pour les paramètres du package wordpress fonctionnent comme c’est le cas, mais il vous suffit de spécifier les valeurs pour deux paramètres requis : le mot de passe mysql administrateur et non administrateur.

Paramètres :

Restore-WDPackage c:\Packages\wordpress.zip -DBAdminPassword mysecretserverpassword –DBPassword mysqllocalpassword

IV. Remove

Remove-WDSite -Site NonWorkingSite

Cette commande supprime la définition du site nommé nonworkingsite dans applicationHost.config ainsi que le contenu du répertoire du site

V. Obtenir et définir l’infrastructure du pool d’applications

Ces cmdlets vous permettent de lire et de modifier la version du .net Framework apppool.

Get-WDAppPoolFx "default web site"
managedRuntimeVersion
---------------------
v2.0
Set-WDAppPoolFx "default web site" -AppPoolFrameworkVersion v4.0
Get-WDAppPoolFx "default web site"
managedRuntimeVersion
---------------------
v4.0

VI. Définir WDACL

Cette cmdlet peut être utilisée pour définir des acls sur le contenu d’un site. Par exemple, supposons que j’ai un site, site1 et que j’essaie de donner à l’utilisateur un accès en lecture u1.

Tout d’abord, je vérifie les autorisations actuelles.

$ret = Get-Acl C:\site1
$ret.Access
I don’t see u1 in the list. Let me give the user u1 access as follows
Set-WDAcl "site1" -SetAclUser u1
Check whether this worked
$ret = Get-Acl C:\site1
$ret.Access
I see that u1 has been given read access as below. [I have not pasted the other permissions on this folder. Just the u1 part]
FileSystemRights  : Read, Synchronize
AccessControlType : Allow
IdentityReference : MOSHAIKH1\u1
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

VII. Appeler

Vous pouvez appeler des commandes ou des scripts sur un système distant à l’aide de destinationpublishsettings et afficher les résultats de l’exécution à distance en temps réel. Vous devez être administrateur sur le système distant pour pouvoir exécuter le fournisseur runcommand à distance. Pour en savoir plus sur ce fournisseur, cliquezici. La durée maximale par défaut pendant laquelle MWD Api attend que le script ou la commande se termine est de 5 secondes. Si vous souhaitez augmenter cette durée d’exécution, vous pouvez spécifier des valeurs plus élevées pour waitInterval et waitAttempts, comme illustré dans l’exemple ci-dessous.

A. Script

Invoke-WDScript C:\my.cmd –Verbose

Cela exécute le script et vous pourrez voir la sortie de la commande si vous l’exécutez avec des commentaires.

B. Commande

$settings = @ { waitInterval = 3000; waitAttempts = 25;}
Invoke-WDCommand "dir c:\mydirectory /s/b" -DestinationSettings $settings

La commande sera exécutée et aucune sortie ne sera affichée puisque verbose n'a pas été spécifié. Toutefois, cette commande attendra 3 secondes entre chaque intervalle de temps et effectuera 25 itérations d'attente. Dans tous les cas, l’exécution du processus se poursuit au maximum pendant 75 secondes.

VIII. Synchronisation

Ces cmdlets prennent une source et une destination et se synchronisent entre elles. La source n’est jamais modifiée. La raison pour laquelle j'utilise le mot source au lieu de client est que les termes client et serveur sont très confus dans le domaine de la synchronisation. Vous pouvez potentiellement synchroniser le serveur local avec un serveur distant. Dans ce cas, le serveur distant est la source et le serveur local est la destination. Vous pouvez également exécuter la cmdlet PowerShell sur l’ordinateur 1 et synchroniser les ordinateurs 2 et 3. Pour utiliser une source distante et/ou une destination, vous devez fournir un fichier de paramètres de publication qui peut être créé à l’aide de la première cmdlet mentionnée dans ce document. Toutes les cmdlets de synchronisation prennent également en charge les paramètres sourceSettings et destinationSettings pour pouvoir définir de manière sélective les paramètres du fournisseur pour la source ou la destination ou les deux.

A. IIS

1. Server (Serveur)

Je souhaite synchroniser deux serveurs IIS 7.5, Owais-1 et Owais-2. Je commence par créer un fichier publishsettings pour chacun d’eux puis je synchronise les serveurs. Comme je n'ai pas spécifié mes informations d'identification, cette opération réussira si je suis administrateur sur ces deux systèmes.

New-WDPublishSettings -ComputerName owais-1 -AgentType MSDepSvc -FileName c:\owais1.publishsettings
Publish settings file created at: 'c:\owais1.publishsettings'.
New-WDPublishSettings -ComputerName owais-2 -AgentType MSDepSvc -FileName c:\owais2.publishsettings
Publish settings file created at: 'c:\owais2.publishsettings'.
Sync-WDServer -SourcePublishSettings c:\owais1.publishSettings -DestinationPublishSettings c:\owais2.publishSettings

2. Site

Dans la commande suivante, le site2 sera créé s’il n’existait pas et j’ai également modifié le chemin d’accès physique (le contenu sera donc copié dans le nouveau dossier c:\site2) et la liaison du site.

Sync-WDSite site1 Site2 -SitePhysicalPath c:\site2 -SiteBinding "*:8078:" -IncludeAppPool

3. Application

J’ai une application s’exécutant sous le site web par défaut. Je veux la déplacer sous Site1. La commande suivante me permet de le faire.

Sync-WDApp "Default Web Site/drupal" "site1/drupal"

Maintenant que j'ai testé le fonctionnement de ma nouvelle application drupal, je vais supprimer l'application drupal d'origine sous le site web par défaut.

Remove-WDSite "Default Web Site/drupal"

B. Base de données

Les cmdlets précédentes vous ont montré comment sauvegarder et restaurer une base de données à l’aide d’un package Web Deploy. Toutefois, vous pouvez également synchroniser une base de données vers ou à partir d’un script .sql ou la synchroniser directement avec une autre instance de base de données à l’aide des cmdlets Sync-WDSQLDatabase et Sync-WDMySQLDatabase.

1. MSSql

Sync-WDSQLDatabase "server=.\sqlexpress;uid=sa;pwd=********;database=umbracodb" "server=.\sqlexpress;uid=sa;pwd=************;database=sometestdb"

Cela crée une base de données appelée sometestdb (si elle n’existe pas déjà) et synchronise le schéma et les données.

Sync-"server=.\sqlexpress;uid=sa;pwd=********;database=umbracodb"  c:\umbraco.sql

Cela crée un script de la base de données umbracodb dans umbraco.sql au chemin indiqué ci-dessus.

2. MySql

Sync-WDMySQLDatabase "server=localhost;uid=root;pwd=********;database=wordpress265" "server=localhost;uid=root;pwd=************;database=wordpress265_new"

Cela crée une base de données appelée wordpress265_new (si elle n’existe pas déjà) et synchronise le schéma et les données.

Sync-WDMySQLDatabase "server=localhost;uid=root;pwd=***************;database=wordpress265" c:\wordpress.sql

Cela crée un script de la base de données wordpress265 dans wordpress.sql au chemin d’accès indiqué ci-dessus.

C. Tout le reste

Pour une synchronisation générale non couverte par les autres cmdlets mentionnées ci-dessus, vous pouvez utiliser la cmdlet Sync-WDManifest. Il s’agit d’une synchronisation générale du fournisseur de manifeste prise en charge par l’API MWD. Pour plus d'informations à ce sujet, cliquez ici. Le manifeste est une collection de fournisseurs, de chemins d’accès de fournisseur et de paramètres de fournisseur dans un fichier xml. La structure est la suivante : le nœud racine du fichier XML est considéré comme le nom d'un fournisseur aux fins de la synchronisation actuelle. Par conséquent, il ne peut pas s’agir du nom d’un des fournisseurs connus comme indiqué dans la liste ici. Il peut ensuite avoir des nœuds enfants dont le nom de l'élément correspond au fournisseur que vous souhaitez inclure dans la synchronisation. Un attribut de chemin représente le chemin d’accès de ce fournisseur et il est obligatoire. Ajoutez ensuite des paires de valeurs d'attributs pour chaque paramètre du fournisseur que vous souhaitez utiliser pour l'opération de synchronisation en cours.

Ce cmdlet a besoin de deux manifestes : un pour la source et un pour la destination. Le manifeste est toujours exécuté dans l’ordre spécifié. Si le fournisseur prend en charge une opération de validation, comme le fournisseur apphostconfig qui fonctionne avec les sites IIS, la validation n'est pas appelée tant que la synchronisation n'est pas terminée. Par conséquent, si vous avez un fournisseur qui s'attend à ce qu'un site existe après un fournisseur qui le crée, cela échouera puisque le site n'a pas encore été validé. Dans l’exemple suivant, je vais synchroniser une application et inclure une base de données que l’application utilise avec elle dans le manifeste.

Manifeste source :

<demoManifest>
  <iisApp path="Site1" />
  <dbfullsql path="server=.\sqlexpress;integrated security=SSPI;database=customers" />
</demoManifest>

Manifeste de destination :

<demoManifest>  <iisApp path="Site2" />  <dbfullsql path="server=.\sqlexpress;integrated security=SSPI;database=customers_demo_cpy" /></demoManifest>Sync-WDManifest C:\sourceManifest.xml C:\destManifest.xmlWARNING: Cannot connect to the database 'customers_demo_cpy'.Retrying operation 'Add' on object dbFullSql (server=.\sqlexpress;uid=sa;database=customers_demo_cpy). Attempt 1 of 5.Manifest         : C:\sourceManifest.xmlManifest-Dest    : C:\destManifest.xmlTimeTaken        : 0:10Errors           : 0Warnings         : 0BytesCopied      : 0ObjectsDeleted   : 0ObjectsUpdated   : 0ObjectsAdded     : 3TotalChanges     : 3ParameterChanges : 0