Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
por Owais Shaikh
Web Deploy V3.0 viene con cmdlets de PowerShell para llevar a cabo la mayoría de las tareas que admite la API de Web Deploy [Microsoft.Web.Deployment]. Puede leer más sobre esta API aquí. Estos cmdlets están en el complemento denominado WDeploySnapin3.0 que se instala y registra como complemento en una instalación típica o superior de la implementación web. Para utilizar estos cmdlets, puede agregar el complemento cada vez que se inicie la consola de PowerShell, o añadirlo al perfil de PowerShell, lo que hará que todas las consolas carguen el complemento automáticamente.
Para agregar cuando se cargue la consola de PowerShell, ejecute el siguiente comando en la ventana de consola:
Add-PSSnapin WDeploySnapin3.0
Para agregarlo al perfil de PowerShell:
- Si ya tiene un perfil de PowerShell, vaya al paso 4.
- Cree una carpeta de WindowsPowerShell en <Mis documentos>.
- Creación de un archivo denominado Microsoft.PowerShell_profile.ps1
- Agregue esta línea al archivo de perfil de PowerShell: "Add-PSSnapin WDeploySnapin3.0"
Algunos puntos a tener en cuenta:
- La consola de PowerShell se ejecuta en sistemas de 64 bits y se ejecuta en .Net 2.0 excepto hasta Windows8. Si tiene problemas debido a uno o a ambos, consulte la sección de solución de problemas para ver las soluciones.
- Todos los cmdlets que crean un paquete de Web Deploy crean parámetros para las tareas más comunes y los cmdlets que lo consumen aceptan valores de parámetro.
- Solo hay un cmdlet de eliminación para eliminar un sitio o una aplicación debajo de él.
- Web Deploy tiene parámetros, pero son ortogonales para los parámetros del cmdlet de PowerShell. Cuando se hace referencia a los parámetros en este documento, implica parámetros de cmdlet. Los parámetros de Web Deploy se han destacado específicamente como parámetros de Web Deploy.
I. Archivo de configuración para publicación
Todos los cmdlets proporcionados a continuación tienen la capacidad de ejecutarse en un artefacto remoto, como un servidor remoto o una base de datos remota. Estos requieren más que solo las credenciales. Por ejemplo, necesita el nombre del servidor remoto, la cadena de conexión de base de datos remota, si desea permitir la publicación en un servidor con un certificado de prueba, etc. Para facilitar el uso, la transferencia de información de credenciales del administrador del servidor al consumidor, etc. se ha originado un nuevo tipo de archivo que agrupa esta configuración. Este archivo se denomina archivo de configuración de publicación que termina en .publishsettings. Visual Studio lo usa para su publicación, así como para WebMatrix.
Para poder crear este tipo de archivo para su consumo por otros cmdlets y editarlo se puede usar el cmdlet New-WDPublishSettings . Si no se especifica ningún nombre de archivo, creará un nuevo archivo en el directorio de documentos con el nombre <guid.publishsettings>. Esta ruta de acceso se mostrará cuando se cree el archivo. Si se especifica un nombre de archivo y el archivo no existe, se creará como se describió anteriormente en la carpeta especificada por la ruta de acceso, pero la ruta de acceso al archivo debe ser válida. Si el archivo solo existe los valores de los atributos especificados durante la ejecución del comando se modificarán, excepto los atributos del archivo que son desconocidos y se quitarán.
Ejemplo: este ejemplo obtiene un objeto de credencial y, a continuación, lo pasa al nuevo cmdlet de archivo de configuración de publicación junto con otros parámetros.
$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. Copia de seguridad
Todos los cmdlets de copia de seguridad tienen un parámetro posicional (es el segundo, excepto backup-wdserver, donde es el primer parámetro posicional) denominado output. Esto toma una ruta de acceso a la carpeta donde desea crear la copia de seguridad. La copia de seguridad siempre es un paquete ZIP de Web Deploy. Puede obtener más información sobre Paquetes de implementación web en Proveedor de paquetes. Si no se especifica ninguna ruta de acceso, las copias de seguridad se crean en una carpeta denominada "Copias de seguridad de web deploy" en la carpeta de documentos del usuario. Las copias de seguridad se denominan machinename_nameofproviderused_[Siteorapporfoldername(Optional)]_timestamp.zip.
Todos estos cmdlets funcionarán localmente de forma predeterminada a menos que se proporcione información del servidor remoto pasando un archivo de configuración de publicación para el parámetro SourcePublishSettings.
A. IIS
Todos los cmdlets de IIS funcionarán con la versión 7 o posterior instalada de IIS.
1. Servidor
Backup-WDServer
Descripción: sin ningún argumento realiza una copia de seguridad del servidor actual donde se ejecuta este comando. Usa el proveedor de servidores web conocido para esta operación. Por lo tanto, el paquete creado contiene todos los artefactos que se incluirán en un paquete de servidor web. Puede obtener más información sobre este proveedor aquí.
Parámetros de cmdlet: el parámetro ConfigOnly permite excluir todo el contenido mientras que los parámetros SkipFileList y SkipFolderList permiten excluir de forma selectiva uno o varios archivos o carpetas del paquete.
Ejemplos:
Esto hará una copia de seguridad de todo el servidor web, excepto el contenido:
Backup-WDServer -SourcePublishSettings c:\profiles\myserver.publishsettings -ConfigOnly
Cree una lista de los archivos que se deben omitir. Se trata de expresiones regulares estándar.
$list = @('\\site2\\iisstart.htm','\\site2\\welcome.png')
Backup-WDServer –SkipFileList $list
También puede cambiar esto para omitir todos los archivos de site2 cambiando la lista a $list=@('\site2\')
2. Sitio
Backup-WDSite
Descripción: se realizará una copia de seguridad de un sitio de IIS junto con su configuración y contenido mediante el proveedor apphostconfig. Puede obtener más información sobre este proveedor aquí.
Parámetros del cmdlet: se realiza una copia de seguridad del nombre del sitio especificado por el parámetro de sitio o por el archivo de configuración de publicación. El valor del parámetro de sitio invalida la especificación de configuración de publicación para el nombre del sitio.
ConfigOnly se puede usar para crear una copia de seguridad sin contenido. Si el sitio usa un grupo de aplicaciones no predeterminado, para que este paquete funcione en otros servidores que podrían no tener el mismo grupo de aplicaciones, use el parámetro switch includeAppPool. Esto agrupará el grupo de aplicaciones en el paquete.
Parámetros de Web Deploy generados automáticamente: se crean dos tipos de parámetros:
- Parámetro para permitir que el usuario cambie el nombre del sitio donde se aplicará la copia de seguridad del sitio.
- Otro parámetro para permitir que el usuario cambie la ruta de acceso física del sitio y todas las aplicaciones web de ese sitio.
Por lo tanto, si tengo un sitio con tres aplicaciones debajo, obtendré 4 parámetros de ruta de acceso física aparte y un parámetro de nombre de sitio.
Ejemplos:
Backup-WDSite "Default Web Site" -ConfigOnly
Backup-WDSite MySite –IncludeAppPool
Backup-WDSite MySite -SkipFileList $list
3. Aplicación web
Backup-WDApp
Descripción: se realizará una copia de seguridad de una aplicación web mediante el proveedor iisApp. Obtenga más información sobre este proveedor aquí. Este es un buen artículo que explica qué es una aplicación web y cuál es la diferencia entre un sitio, una aplicación y un directorio virtual en IIS.
Parámetros del cmdlet: se realiza una copia de seguridad del nombre de la aplicación especificado por el parámetro de aplicación o por el archivo de configuración de publicación. Si no se especifica ninguno de ellos, se produce un error. El valor del parámetro de aplicación invalida la especificación de configuración de publicación para el nombre del sitio. Los parámetros SkipFileList y SkipFolderList permiten excluir de forma selectiva uno o varios archivos o carpetas del paquete.
Los parámetros de Web Deploy generados automáticamente: se crea un parámetro para cambiar el nombre de la aplicación o el sitio durante la restauración o instalación.
$list = @('\\iisstart\.htm')
Backup-WDApp "Default web site/app" -SkipFileList $list
B. Base de datos
1. MSSql
Backup-WDSqlDatabase
Descripción: se realizará una copia de seguridad de una base de datos de Microsoft SQL Server mediante el proveedor dbfullsql. Este proveedor usa SMO para generar un script de la base de datos y expone más de 100 configuraciones de proveedor para controlar la manera en que se genera el script de la base de datos. Esto se trata en detalle aquí.
Parámetros del cmdlet: se realiza una copia de seguridad de la cadena de conexión especificada por el parámetro Database o SQLServerDBConnectionString en el archivo de configuración de publicación. El valor del parámetro de base de datos invalida la especificación de configuración de publicación para SQLServerDBConnectionString. La configuración del proveedor expuesta por este proveedor dbfullsql se puede pasar mediante el parámetro SourceSettings. Una configuración muy utilizada es scriptdropsfirst, que genera scripts para eliminar objetos si estos ya existen. Otra configuración de proveedor de las opciones de scripting de SMO es configurar scriptdata en false para extraer solo el esquema.
Parámetros de Web Deploy generados automáticamente: se crea un parámetro para cambiar la cadena de conexión de la base de datos durante la restauración o la instalación.
Ejemplos:
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
Descripción: se realizará una copia de seguridad de una base de datos del servidor MySql mediante el proveedor dbmysql. Este proveedor usa mysqldump para exportar la base de datos. Esto se trata en detalle aquí.
Parámetros del cmdlet: se realiza una copia de seguridad de la cadena de conexión especificada por el parámetro Database o mySQLDBConnectionString en el archivo de configuración de publicación. El valor del parámetro de base de datos invalida la especificación de configuración de publicación para mySQLDBConnectionString. La configuración del proveedor se puede pasar mediante el parámetro SourceSettings. La configuración usada habitualmente es includeData e includeSchema. De forma predeterminada, se establecen en true.
Parámetros de Web Deploy generados automáticamente: se crea un parámetro para cambiar la cadena de conexión de la base de datos durante la restauración o la instalación.
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. Restaurar
Todos los cmdlets de restauración toman el paquete Web Deploy para restaurar como primer parámetro posicional.
WebDeploy admite el concepto de parametrización de los paquetes, lo que le permite cambiar algunos aspectos durante la restauración (sin modificar el paquete). Por ejemplo, durante la restauración, puede especificar el valor de la cadena de conexión de base de datos que es diferente de lo que está dentro del paquete mediante parámetros WebDeploy (debe tener el parámetro de cadena de conexión presente en el paquete).
En función de cómo se creó el paquete, es posible que el paquete web Deploy tenga uno o varios . Estos cmdlets de restauración inspeccionan el paquete y agregan parámetros dinámicos de PowerShell a la colección. Por lo tanto, si un paquete tiene un parámetro web Deploy denominado "Parameter1", encontrará un parámetro de PowerShell con el nombre "Parameter1". Sin embargo, los parámetros dinámicos tienen sus propios problemas en PowerShell y esto solo funcionará si los paquetes no tienen un espacio en su nombre o en la ruta de acceso al archivo.
Como alternativa, todos estos cmdlets de restauración también tienen un parámetro "Parameters" que permite especificar manualmente nuevos valores de parámetro durante la restauración. Este parámetro "Parameters" acepta el objeto Dictionary de PowerShell para los pares de nombre y valor de los parámetros de Web Deploy.
Para averiguar los parámetros de Web Deploy definidos en cualquier paquete de Web Deploy, simplemente puede abrir el archivo ZIP en el Explorador de Windows y examinar el archivo parameters.xml presente en la raíz del paquete. Cualquier parámetro de Web Deploy que no tenga un valor predeterminado debe tener un valor especificado. Agregue todos estos parámetros en un archivo xml y páselo como valor para el parámetro ParameterValuesFile. Puede generar este archivo como se indica aquí o manualmente. El formato es
<parameters>
<setParameter name="name1" value="value1" />
<setParameter name="name2" value="value2" />
</parameters>
El cmdlet Get-WDParameters puede leer este archivo y convertirlo en un diccionario de parámetros de WebDeploy, que es aceptado por todos los cmdlets de restauración.
Si se restaura un paquete sin especificar un valor para los parámetros dentro, el comportamiento predeterminado se sobrescribiría los recursos desde los que se creó originalmente el paquete. Por ejemplo, si creo un paquete a partir de site1 mediante el uso de backup-wdsite site1, cuando restauro este paquete mediante el cmdlet restore sin proporcionar ningún valor a los parámetros de este paquete, site1 se sobrescribirá con cualquier cosa que el paquete contenga, tanto contenido como configuración. Lo mismo sucede con todos los cmdlets de restauración.
Todos estos cmdlets se restauran localmente, excepto cuando se especifica el archivo de configuración de publicación de destino, en cuyo caso se produciría la misma operación exacta en un servidor remoto a través del servicio de administración web (WMSvc) o el servicio agente de implementación web.
A. IIS
1. Servidor
Restore-WDServer
Descripción: restaura un paquete de servidor web. El uso común consiste en realizar una copia de seguridad de un servidor antes de realizar un cambio y, en caso de error, el servidor se puede revertir aplicando el paquete de copia de seguridad de Web Deploy creado antes de realizar los cambios.
$folderList = @(‘\\app_data’)
Restore-WDServer D:\OWAIS-1_WebServer_20120419121214.zip -DestinationPublishSettings c:\destinationServer.publishSettings –SkipFolderList $folderList
2. Sitio
Restore-WDSite
Descripción: restaura un paquete de sitio de IIS. Si el paquete tiene dos parámetros denominados "Ruta física del sitio" y "Nombre del sitio", se exponen como parámetro de powershell dinámico SitePhysicalPath y SiteName. Este comando creará un nuevo sitio, site1, con la ruta de acceso física c:\site1. Si no se especifica ningún valor para estos parámetros, la restauración se aplicará al mismo sitio y contenido, sobrescribiendo los cambios que pueda tener en el sitio.
Parámetros: es posible que quiera usar skipfolderlist y skipfilelist para excluir algunas carpetas o archivos de que se copien en el contenido del sitio.
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. Aplicación
Restore-WDApp
Descripción: esto restaurará una aplicación web. Backup-WDApp crea el paquete con un parámetro para cambiar el nombre de la aplicación en tiempo de instalación. Esto se puede usar para restaurar la aplicación en otra aplicación durante la restauración. El sitio debe existir al momento de implementar en una aplicación dentro de un sitio. Este paquete creará la aplicación, pero no se creará el sitio.
Ejemplos:
Restore-WDApp C:\myappbackup.zip -ApplicationPathParam1 "Default web site\app1"
B. Base de datos
Restore-WDDatabase
Descripción: si la base de datos no existe, se creará una nueva base de datos denominada clientes (siempre que el usuario actual tenga permisos para esta operación) y ejecute el script en ella. Si se ejecuta sin ningún valor para los parámetros dinámicos de Web Deploy, se sobrescribirá la base de datos original desde la que se creó este paquete. Tenga en cuenta que si no se usó la configuración scriptDropsFirst al crear el paquete, se producirá un error al aplicar a una base de datos con contenido existente en conflicto. Este cmdlet se puede usar para restaurar una copia de seguridad de MSSql o MySQL. Solo puede restaurar una base de datos MS SQL con una copia de seguridad creada mediante Backup-WDSQLDatabase y Mi base de datos SQL con una copia de seguridad creada mediante Backup-WDMySqlDatabase.
Ejemplos:
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. Paquete genérico
Restore-WDPackage
Descripción: este cmdlet se puede usar para aplicar cualquier paquete de Web Deploy. Hay varias maneras de crear o obtener un paquete web Deploy, como descargar un paquete de la Galería de aplicaciones de código abierto, crear un paquete en Visual Studio, usar la herramienta de línea de comandos msdeploy.exe (más información) o usar los cmdlets Backup-WD* indicados anteriormente en el documento. Por ejemplo, para instalar wordpress en un sitio web predeterminado del servidor IIS como una aplicación denominada wordpress, descargue el paquete de wordpress de la galería de aplicaciones en una carpeta denominada paquetes. Todos los valores predeterminados de los parámetros del paquete de wordpress funcionarán tal como está, pero solo tiene que especificar los valores de dos parámetros necesarios: admin y non admin mysql password.
Parámetros:
Restore-WDPackage c:\Packages\wordpress.zip -DBAdminPassword mysecretserverpassword –DBPassword mysqllocalpassword
IV. Eliminar
Remove-WDSite -Site NonWorkingSite
Este comando eliminará la definición del sitio denominado nonworkingsite en applicationHost.config, así como el contenido del directorio del sitio.
V. Obtener y establecer marco de grupo de aplicaciones
Estos cmdlets le permiten leer y cambiar la versión de apppool .net Framework.
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. Establecer WDACL
Este cmdlet se puede usar para establecer acls en el contenido de un sitio. Por ejemplo, supongamos que tengo un sitio, site1 y estoy intentando conceder acceso de lectura al usuario u1.
En primer lugar, comprué los permisos actuales.
$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. Invoke
Puede invocar comandos o scripts en un sistema remoto mediante destinationpublishsettings y ver los resultados de la ejecución remota en tiempo real. Debe ser administrador del sistema remoto para poder ejecutar el proveedor runcommand de forma remota. Puede obtener más información sobre este proveedor aquí. El tiempo de espera máximo predeterminado de la API MWD para que finalice el script o comando especificado es de 5 segundos. Si desea aumentar este tiempo de ejecución, puede especificar valores más altos para waitInterval y waitAttempts, como se muestra en el ejemplo siguiente.
A. Script
Invoke-WDScript C:\my.cmd –Verbose
Esto ejecutará el script y podrá ver la salida del comando si lo ejecuta con detalles.
B. Comando
$settings = @ { waitInterval = 3000; waitAttempts = 25;}
Invoke-WDCommand "dir c:\mydirectory /s/b" -DestinationSettings $settings
Esto ejecutará el comando y no se mostrará ninguna salida, ya que no se especificó el modo verboso. Sin embargo, esto esperará 3 segundos entre cada expiración de tiempo y realizará 25 iteraciones de espera. En todo, la ejecución del proceso continuará como máximo durante 75 segundos.
VIII. Sincronización
Estos cmdlets toman un origen y un destino y se sincronizan entre ellos. El origen nunca se modifica. La razón por la que uso la palabra "fuente" en lugar de "cliente" es porque "cliente" y "servidor" son términos muy confusos en la sincronización. Puede sincronizar el servidor local con un servidor remoto. En este caso, el servidor remoto es el origen y el servidor local es el destino. Como alternativa, puede ejecutar el cmdlet de PowerShell en la máquina 1 y sincronizar máquinas 2 y 3. Para usar un origen remoto o un destino, debe proporcionar un archivo de configuración de publicación que se puede crear mediante el primer cmdlet mencionado en este documento. Todos los cmdlets de sincronización también admiten parámetros sourceSettings y destinationSettings para poder establecer selectivamente la configuración del proveedor para el origen o el destino o ambos.
A. IIS
1. Servidor
Quiero sincronizar dos servidores IIS 7.5, Owais-1 y Owais-2. Primero crearé un archivo publishsettings para cada uno y, a continuación, sincronizaré los servidores. Puesto que no especifiqué mis credenciales, esto se realizará correctamente si soy administrador en esos dos sistemas.
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. Sitio
En el siguiente comando, se creará el sitio 2 si no existía y también he modificado la ruta de acceso física (el contenido se copiará en la nueva carpeta c:\site2) y la configuración de enlace del sitio.
Sync-WDSite site1 Site2 -SitePhysicalPath c:\site2 -SiteBinding "*:8078:" -IncludeAppPool
3. Aplicación
Tengo una aplicación que se ejecuta en el sitio web predeterminado. Quiero mover esto en Site1. El siguiente comando lo hará.
Sync-WDApp "Default Web Site/drupal" "site1/drupal"
Ahora que he probado que mi nueva aplicación de Drupal funciona correctamente, eliminaré la aplicación original bajo el sitio web predeterminado.
Remove-WDSite "Default Web Site/drupal"
B. Base de datos
Los cmdlets anteriores han mostrado cómo puede realizar copias de seguridad y restaurar una base de datos mediante un paquete web Deploy, pero también puede sincronizar una base de datos con o desde un script de .sql o sincronizar directamente con otra instancia de base de datos mediante los cmdlets Sync-WDSQLDatabase y Sync-WDMySQLDatabase.
1. MSSql
Sync-WDSQLDatabase "server=.\sqlexpress;uid=sa;pwd=********;database=umbracodb" "server=.\sqlexpress;uid=sa;pwd=************;database=sometestdb"
Esto creará una nueva base de datos denominada sometestdb (si aún no existe) y sincronizará el esquema y los datos.
Sync-"server=.\sqlexpress;uid=sa;pwd=********;database=umbracodb" c:\umbraco.sql
Esto generará un script de la base de datos umbracodb en umbraco.sql en la ruta especificada arriba.
2. MySql
Sync-WDMySQLDatabase "server=localhost;uid=root;pwd=********;database=wordpress265" "server=localhost;uid=root;pwd=************;database=wordpress265_new"
Esto creará una nueva base de datos denominada wordpress265_new (si aún no existe) y sincronizará el esquema y los datos.
Sync-WDMySQLDatabase "server=localhost;uid=root;pwd=***************;database=wordpress265" c:\wordpress.sql
Esto generará un script de la base de datos wordpress265 en wordpress.sql en la ruta indicada anteriormente.
C. Todo lo demás
Para la sincronización de uso general que no está cubierta por los otros cmdlets indicados anteriormente, puede usar el cmdlet Sync-WDManifest. Se trata de una sincronización general del proveedor de manifiestos compatible con la API MWD. Puede leer más sobre él aquí. El Manifiesto es una colección de proveedores, rutas de acceso de proveedor y configuraciones del proveedor en un archivo XML. La estructura es que el nodo raíz del archivo xml se considera el nombre de un proveedor con el fin de la sincronización actual. Por lo tanto, no puede ser el nombre de ninguno de los proveedores conocidos tal como se indica en la lista aquí. A continuación, puede tener nodos secundarios con el nombre del elemento que coincida con el proveedor que desea incluir en la sincronización. Un atributo path representa la ruta de acceso de ese proveedor y es obligatoria. A continuación, agregue pares de valor de atributo para cada configuración de proveedor que quiera aprovechar para la operación de sincronización actual.
Este cmdlet necesita dos manifiestos: uno para el origen y otro para el destino. El manifiesto siempre se ejecuta en el orden especificado. Si el proveedor admite una operación de confirmación de cambios, como el proveedor 'apphostconfig' que funciona con sitios de IIS, no se realiza la confirmación a menos que se complete la sincronización. Por lo tanto, si tiene un proveedor que espera que un sitio exista después de que otro proveedor lo haya creado, esto fallará porque el sitio aún no se ha validado. En el ejemplo siguiente, sincronizaré una aplicación e incluiré una base de datos que la aplicación usa junto con ella en el manifiesto.
Manifiesto de fuente
<demoManifest>
<iisApp path="Site1" />
<dbfullsql path="server=.\sqlexpress;integrated security=SSPI;database=customers" />
</demoManifest>
Manifiesto de destino:
<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