Azure: esiste un modo per distribuire diverse dimensioni di istanza per test/produzione

Question

Ho un sito Windows Azure che viene distribuito su due servizi host separati. Uno per il test, uno per la produzione. Quando siamo pronti a spingere verso la produzione, creiamo una distribuzione temporanea nel servizio di produzione, spingiamo lì, quindi eseguiamo uno scambio VIP. Tutto bene.

La domanda è, ora vogliamo passare da istanze Web XS, ma non ha davvero senso spendere i soldi extra per la distribuzione di test. C'è un modo per usare un'istanza XS per il test e quindi dire istanze medie per la produzione? So che posso cambiare il numero di istanze per ogni configurazione del servizio, ma posso solo cambiare la dimensione dell'istanza per tutte le configurazioni.

Sto pensando di lasciarlo XS nella configurazione, e poi di ricordarlo di passare a Media prima di distribuirlo in produzione. C'è qualche ragione per cui non dovrei farlo? C'è un modo migliore?

Cheers!

Answer 1

ci sono alcuni modi per fare questo ... modo più semplice è quello di fare un po ' "hacking" del file CCPROJ:

1) creare un clone del file CSDEF per ogni ambiente che corrisponde alla configurazione nome (uscita/Debug/QA/SVS/etc): ServiceDefinition.Release.csdef, ServiceDefinition.Debug.csdef, ecc

2) Aggiungere i file manualmente al file CCPROJ utilizzando un editor di blocco note

3) Definire un comando Pre-Build Event che copia ServiceDefinition. $ (ConfigurationName) .csdef in ServiceDefintion.cs def

voila, ora il tuo ServiceDefintion si adatterà alla configurazione che stai utilizzando.

Se si desidera ottenere più elaborato o vedere più dettagli, controlla questo blog che può aiutare a passare tutti i tipi di impostazioni all'unisono

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

Edit: Ecco un config che funziona. Si noti che altri file sono inclusi come tipo "Nessuno" anziché ServiceDefinition per evitare l'errore di definizioni multiple.

<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> 

Answer 2

La dimensione della VM viene gestita nel file ServiceDefinition.csdef, che non è possibile modificare in fase di esecuzione o di distribuzione. Dovresti modificare le impostazioni in .csdef, riconfezionare la tua soluzione e quindi ridistribuire.

Una soluzione potrebbe essere l'impostazione di più progetti di distribuzione di Windows Azure. Un progetto sarebbe il tuo progetto "test" che ha il .csdef configurato per utilizzare un XS. Un altro progetto sarebbe il progetto "produzione" che utilizza un'istanza più grande. Ciò consentirebbe di utilizzare gli strumenti standard di Windows Azure/Visual Studio per gestire il progetto, il che potrebbe essere utile in base al processo.

Answer 3

È possibile utilizzare la Pubblicazione Web TransformXml compito MSBuild di trasformare solo le parti del servicedefinition si vuole (come si può fare ora con web.config).

• Creare un file ServiceDefinition.[BuildConfigName].csdef accanto al file ServiceDefinition.csdef (probabilmente avrete bisogno di fare questo in Esplora file)
• Creare il file di trasformazione come ci si è creato un web.config trasformare.Ho impostato esplicitamente spazio dei nomi root, nel caso in cui, quindi il mio elemento principale è:

<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"> 

• aggiungerlo manualmente al vostro ccproj utilizzando:

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

• In fondo del tuo progetto:

<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> 

Quando impacchettate o pubblicate la vostra app cloud, il vostro csdef dovrebbe essere trasformato a seconda della configurazione di build che state utilizzando.

Questo è adattato da qui: http://blogs.staykov.net/2011/06/windows-azure-configuration-settings.html

Answer 4

Uso trasformazione come David Faivre suggerito è molto più pulito e senza il sovraccarico di aggiornare tutti i file dopo l'aggiunta singola proprietà.

Questa è la trasformazione XML per cambiare la dimensione 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> 

Answer 5

David Faivre ha proposto una good solution. Pochi commenti per:

1. Se il file servicedefinition contiene link ad alcune directory (sezione per esempio), che ci sarà un errore causato dal fatto che il file trasformato si trova nella directory intermedia. Per il mio uso Ho risolto questo problema inserendo file trasformato al fianco ServiceDefinition.csdef originale (non dimenticare di aggiungere * .transformed in .gitignore):

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

2. $(Configuration) variabile corrisponde alla configurazione di Build (Debug, Release ecc.). Se si desidera avere il profilo di trasformazione specifico (corrispondente a ServiceConfiguration..cscfg), è necessario utilizzare $(TargetProfile) variabile:

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