understand porta microsoft management azure virtual-machine cloud-hosting

porta - Azure: ¿Hay alguna forma de implementar diferentes tamaños de instancia para prueba/producción



portal azure web (5)

David Faivre propuso una buena solución . Algunos comentarios míos:

  1. Si su archivo ServiceDefinition contiene enlaces a algunos directorios (por ejemplo, sección), habrá un error causado por el hecho de que el archivo transformado está en el directorio intermedio. Para mi uso, resolví este problema al colocar el archivo transformado junto con el ServiceDefinition.csdef original (no olvides agregar * .transformed en .gitignore):

<TransformXml Source="@(ServiceDefinition)" Destination="ServiceDefinition.csdef.transformed" Transform="$(ServiceDefinitionTransform)" />

  1. $(Configuration) variable $(Configuration) corresponde a la configuración de Build (Debug, Release, etc.). Si desea tener una transformación específica de perfil (correspondiente a ServiceConfiguration..cscfg), debe usar la variable $(TargetProfile) :

<ServiceDefinitionTransform>ServiceDefinition.$(TargetProfile).csdef</ServiceDefinitionTransform>

Tengo un sitio de Windows Azure que se implementa en dos servicios alojados separados. Uno para prueba, uno para producción. Cuando estemos listos para impulsar la producción, aumentamos la implementación de etapas en el servicio de producción, avanzamos y luego realizamos un intercambio VIP. Todo bien.

La pregunta es, ahora queremos pasar de las instancias web de XS, pero realmente no tiene sentido gastar el dinero extra en la implementación de la prueba. ¿Hay alguna forma de usar una instancia XS para la prueba, y luego decir instancias medianas para la producción? Sé que puedo cambiar el número de instancias para cada configuración de servicio, pero solo puedo cambiar el tamaño de la instancia para todas las configuraciones.

Estoy pensando en dejarlo XS en la configuración y luego recordar cambiarlo a Medio antes de desplegarlo en producción. ¿Hay alguna razón por la que no debería hacer esto? ¿Hay una mejor manera?

¡Aclamaciones!

El tamaño de la VM se maneja en el archivo ServiceDefinition.csdef, que es algo que no puede editar al ejecutar o implementar el tiempo. Debería cambiar la configuración en .csdef, volver a empaquetar su solución y luego volver a desplegarla.

Una solución puede ser configurar múltiples proyectos de implementación de Windows Azure. Un proyecto sería su proyecto de "prueba" que tiene el .csdef configurado para usar un XS. Otro proyecto sería el proyecto de "producción" que usa una instancia más grande. Esto le permitiría usar las herramientas estándar de Windows Azure / Visual Studio para administrar el proyecto, lo que puede ser bueno dependiendo de su proceso.

El uso de la transformación como sugirió es mucho más limpio y sin sobrecarga para actualizar todos los archivos después de agregar una sola propiedad.

Este es el xml de transformación para cambiar el tamaño de vm:

<?xml version="1.0"?> <ServiceDefinition name="CloudServiceName" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2015-04.2.6" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <WorkerRole name="WorkerRoleName.Role" vmsize="Medium" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" /> </ServiceDefinition>

Hay algunas maneras de hacerlo ... Una forma más simple es hacer un poco de "pirateo" del archivo CCPROJ:

1) cree un clon del archivo CSDEF para cada entorno que coincida con el Nombre de configuración (Release / Debug / QA / UAT / etc): ServiceDefinition.Release.csdef, ServiceDefinition.Debug.csdef, etc.

2) Agregue esos archivos manualmente al archivo CCPROJ usando un editor de bloc de notas

3) Defina un comando de Pre-Build Event que copie el ServiceDefinition. $ (ConfigurationName) .csdef en ServiceDefintion.csdef

voila, ahora tu ServiceDefintion se adaptará a la configuración que estés usando.

Si quieres ser más elegante o ver más detalles, echa un vistazo a esta entrada de blog que puede ayudarte a cambiar todo tipo de configuraciones al unísono

http://www.paraleap.com/blog/post/Managing-environments-in-a-distributed-Azure-or-other-cloud-based-NET-solution.aspx

Editar: Aquí hay una configuración que funciona. Observe que otros archivos se incluyen como tipo "Ninguno" en lugar de ServiceDefinition para evitar el error de definiciones múltiples.

<ItemGroup> <ServiceConfiguration Include="ServiceConfiguration.Local.cscfg" /> <ServiceConfiguration Include="ServiceConfiguration.Development 1.cscfg" /> <ServiceConfiguration Include="ServiceConfiguration.Development 2.cscfg" /> <ServiceConfiguration Include="ServiceConfiguration.Local Dev 1.cscfg" /> <ServiceConfiguration Include="ServiceConfiguration.Local Dev 2.cscfg" /> <ServiceConfiguration Include="ServiceConfiguration.QA 1.cscfg" /> <ServiceConfiguration Include="ServiceConfiguration.QA 2.cscfg" /> <ServiceConfiguration Include="ServiceConfiguration.Pre-Production 1.cscfg" /> <ServiceConfiguration Include="ServiceConfiguration.Production.cscfg" /> <ServiceDefinition Include="ServiceDefinition.csdef" /> <None Include="ServiceDefinition.Local.csdef" /> <None Include="ServiceDefinition.Development 1.csdef" /> <None Include="ServiceDefinition.Development 2.csdef" /> <None Include="ServiceDefinition.Local Dev 1.csdef" /> <None Include="ServiceDefinition.Local Dev 2.csdef" /> <None Include="ServiceDefinition.QA 1.csdef" /> <None Include="ServiceDefinition.QA 2.csdef" /> <None Include="ServiceDefinition.Pre-Production 1.csdef" /> <None Include="ServiceDefinition.Production.csdef" /> </ItemGroup>

Puede usar la tarea Web Publishing TransformXml MSBuild para transformar solo las partes de la definición de servicio que desee (como puede hacerlo ahora con Web.Config).

  • Cree un archivo ServiceDefinition.[BuildConfigName].csdef junto al archivo ServiceDefinition.[BuildConfigName].csdef (probablemente necesite hacer esto en el Explorador de archivos)
  • Cree el archivo de transformación como si hubiera creado una transformación Web.config. Establecí explícitamente el espacio de nombres raíz, por si acaso, así que mi elemento raíz es:

<ServiceDefinition name="Cloud.JobsWorker" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform" schemaVersion="2013-10.2.2">

  • Añádelo manualmente a tu ccproj usando:

<ServiceDefinition Include="ServiceDefinition.csdef" /> <None Include="ServiceDefinition.Release.csdef" />

  • En la parte inferior de tu proyecto incluye:

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)/Microsoft/VisualStudio/v$(VisualStudioVersion)/Web/Microsoft.Web.Publishing.Tasks.dll" /> <PropertyGroup> <ServiceDefinitionTransform>ServiceDefinition.$(Configuration).csdef</ServiceDefinitionTransform> </PropertyGroup> <Target Name="TransformServiceDefinition" BeforeTargets="ResolveServiceDefinition" Condition="exists(''$(ServiceDefinitionTransform)'')"> <!-- Generate transformed service config in the intermediate directory --> <TransformXml Source="@(ServiceDefinition)" Destination="$(IntermediateOutputPath)%(Filename)%(Extension)" Transform="$(ServiceDefinitionTransform)" /> <!--Force build process to use the transformed configuration file from now on.--> <ItemGroup> <ServiceDefinition Remove="ServiceDefinition.csdef" /> <ServiceDefinition Include="$(IntermediateOutputPath)ServiceDefinition.csdef" /> </ItemGroup> </Target>

Cuando empaqueta o publica su aplicación en la nube, su csdef debe transformarse dependiendo de la configuración de compilación que esté utilizando.

Esto se ha adaptado desde aquí: http://blogs.staykov.net/2011/06/windows-azure-configuration-settings.html