Azure: Czy istnieje sposób wdrożenia różnych rozmiarów instancji dla testów/produkcji

Question

Mam witrynę Windows Azure, która jest wdrażana w dwóch osobnych usługach hostowanych. Jeden do testu, drugi do produkcji. Kiedy jesteśmy gotowi, aby przejść do produkcji, rozpoczynamy wdrożenie etapowe w usłudze produkcyjnej, pchamy tam, a następnie przeprowadzamy wymianę VIP. Wszystko dobrze.

Pytanie brzmi: teraz chcemy przesunąć się z instancji XS Web, ale nie ma sensu wydawać dodatkowych pieniędzy na wdrożenie testowe. Czy istnieje sposób użycia instancji XS do testu, a następnie wypowiedzenia średnich instancji dla produkcji? Wiem, że mogę zmienić liczbę instancji dla każdej konfiguracji usługi, ale mogę tylko zmienić rozmiar instancji dla wszystkich konfiguracji.

Zastanawiam się nad pozostawieniem go XS w konfiguracji, a następnie pamiętam, aby zmienić go na Medium przed wdrożeniem do produkcji. Czy jest jakikolwiek powód, dla którego nie powinienem tego robić? Czy istnieje lepszy sposób?

Pozdrawiam!

Answer 1

Istnieje kilka sposobów, aby to zrobić ... prostszym sposobem jest zrobić trochę „hacking” pliku CCPROJ:

1) stworzenia klona pliku CSDEF dla każdego środowiska, które odpowiada konfiguracji Nazwa (Release/Debug/QA/UAT/etc): ServiceDefinition.Release.csdef, ServiceDefinition.Debug.csdef itp

2) Dodaj te pliki ręcznie do pliku CCPROJ za pomocą notatnika edytor

3) Zdefiniuj polecenie Przed kompilacją zdarzenia, które skopiuje definicję ServiceDefinition. $ (ConfigurationName) .csdef do ServiceDefintion.cs def

voila, teraz ServiceDefintion dostosuje się do konfiguracji, z której korzystasz.

Jeśli chcesz uzyskać hodowcy lub zobaczyć więcej szczegółów, zajrzyj do tego wpisu, które mogą pomóc przełączyć wszystkie rodzaje ustawień w zgodzie

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

Edit: Tutaj jest config, który działa. Zauważ, że inne pliki są dołączane jako typ "Brak" zamiast ServiceDefinition, aby uniknąć błędu wielu definicji.

<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

Rozmiar maszyny wirtualnej jest obsługiwany w pliku ServiceDefinition.csdef, który nie można edytować podczas uruchamiania ani wdrażania. Będziesz musiał zmienić ustawienie w pliku .csdef, przepakować rozwiązanie, a następnie ponownie wdrożyć.

Jednym z rozwiązań może być skonfigurowanie wielu projektów wdrażania Windows Azure. Jeden projekt byłby twoim "testowym" projektem, który ma .csdef skonfigurowany do używania XS. Kolejnym projektem byłby projekt "produkcji", który wykorzystuje większą instancję. Umożliwi to korzystanie ze standardowych narzędzi Windows Azure/Visual Studio do zarządzania projektem - co może być miłe w zależności od procesu.

Answer 3

Można użyć Web Publishing TransformXml MSBuild zadanie przekształcić tylko części ServiceDefinition chcesz (jak można to zrobić teraz z web.config).

• Utwórz plik ServiceDefinition.[BuildConfigName].csdef obok pliku ServiceDefinition.csdef (prawdopodobnie będziesz musiał to zrobić w File Explorer)
• Utwórz plik transformacji jakbyś którą stworzył Web.config przekształcać.I jawnie ustawić nazw root, na wszelki wypadek, więc moja elementem głównym jest:

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

• ręcznie dodać go do ccproj używając:

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

• Na dole twojego projektu to:

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

Podczas pakowania lub publikowania aplikacji chmurowej plik csdef powinien zostać przekształcony w zależności od konfiguracji kompilacji, której używasz.

ten przystosowany jest stąd: http://blogs.staykov.net/2011/06/windows-azure-configuration-settings.html

Answer 4

Stosując transformację jako David Faivre sugerował jest znacznie czystsze i bez obciążania zaktualizować wszystkie pliki po dodaniu jedną właściwość.

To xml transformacja do zmiany rozmiaru 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 zaproponował good solution. Kilka komentarzy ode mnie:

1. Jeśli plik ServiceDefinition zawiera linki do niektórych katalogów (np. Sekcji), wówczas wystąpi błąd spowodowany faktem, że plik przekształcony znajduje się w katalogu pośrednim. Dla mojego użytku I rozwiązać ten problem poprzez umieszczenie przekształcony plik obok oryginalnego ServiceDefinition.csdef (nie zapomnij dodać * .transformed do .gitignore):

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

2. $(Configuration) zmienna odpowiada konfiguracji kompilacji (debugowanie, zwalnianie itp.). Jeśli chcesz mieć profil konkretnej obróbce (odpowiadający ServiceConfiguration..cscfg), trzeba użyć $(TargetProfile) zmienna:

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