Gdzie ustawiasz i uzyskujesz dostęp do parametrów konfiguracji czasu wykonywania na środowisko dla sieci szkieletowej usług?


82

W przypadku dwóch środowisk, lokalnego i chmury, jak skonfigurować niestandardowe ustawienia lub parametry zasobów, takich jak bazy danych Sql, konta magazynu itp ... Idealnie byłoby to jedna nazwa parametru wywoływana w kodzie, aby powiedzieć, że wskazuje kontekst DbContext na konkretny bazy danych, które w konfiguracjach dla środowiska lokalnego lub chmury są różne. Dziękuję Ci.


Chociaż chciałbym, aby włączyli kod aplikacji do faktycznego wykorzystania konfiguracji, Microsoft pokazuje, jak skonfigurować ją w następującym artykule: docs.microsoft.com/en-us/azure/service-fabric/ ...
Adam Plocher

Odpowiedzi:


145

Aby mieć zmienne środowiskowe na potrzeby uruchamiania usługi Service Fabric lokalnie iw chmurze, należy wykonać następujące czynności:

  1. Dodaj sekcję konfiguracji niestandardowej i parametry do pliku Settings.xml projektu Service / Actor (znajdującego się w katalogu \ PackageRoot \ Config \ Settings.xml w katalogu głównym projektu). Pozostaw parametry puste, ponieważ będziemy je ustawiać w innym miejscu dla danego środowiska. Oto przykład.
<?xml version="1.0" encoding="utf-8" ?>
<Settings xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<!-- Add your custom configuration sections and parameters here -->
    <Section Name="UserDatabase">
        <Parameter Name="UserDatabaseConnectionString" Value="" />
    </Section>
</Settings>
  1. W pliku ApplicationManifest.xml projektu sieci szkieletowej usług będą <ServiceManifestImport>elementy dla każdego z dołączonych projektów. Poniżej znajduje się <ConfigOverrides>element, w którym zadeklarujemy, jakie wartości dla naszych konfiguracji zostaną zastąpione przez wartości ustawione na środowisko w lokalnych i chmurowych plikach xml pod ApplicationParameters w naszym projekcie usługi Service Fabric. W tym samym pliku ApplicationManifest.xml musisz dodać parametr, który będzie obecny w lokalnych i chmurowych plikach xml, w przeciwnym razie zostaną one nadpisane podczas kompilacji.

Kontynuując powyższy przykład, tak zostałoby to ustawione.

<Parameters>
    <Parameter Name="ServiceName_InstanceCount" DefaultValue="-1" />
    <Parameter Name="UserDatabaseConnectionString" DefaultValue="" />
</Parameters>
<ConfigOverrides>
    <ConfigOverride Name="Config">
        <Settings>
            <Section Name="UserDatabase">
                <Parameter Name="UserDatabaseConnectionString" Value="[UserDatabaseConnectionString]" />
            </Section>
        </Settings>
    </ConfigOverride>
</ConfigOverrides>
  1. W plikach local.xml i cloud.xml w obszarze ApplicationParameters w projekcie usługi Service Fabric określ zmienne specyficzne dla środowiska, takie jak te.
<?xml version="1.0" encoding="utf-8"?>
<Application xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="fabric:/AppFabricName.ServiceFabric" xmlns="http://schemas.microsoft.com/2011/01/fabric">
    <Parameters>
        <Parameter Name="ServiceName_InstanceCount" Value="1" />
        <Parameter Name="UserDatabaseConnectionString" Value="Server=(localdb)\MsSqlLocalDb;Database=Users;User=ReadOnlyUser;Password=XXXXX;" />
    </Parameters>
</Application>
  1. Wreszcie, w swoim Service / Actor możesz uzyskać dostęp do tych zmiennych konfiguracyjnych dla środowiska, w ten sposób.
var configurationPackage = Context.CodePackageActivationContext.GetConfigurationPackageObject("Config");

var connectionStringParameter = configurationPackage.Settings.Sections["UserDatabase"].Parameters["UserDatabaseConnectionString"];

101
Mogę po prostu powiedzieć „fuj!”. Jest to beznadziejnie zagmatwane w przypadku prostego ustawienia opartego na środowisku. Jest to dojrzałe do pewnego wysiłku deweloperów zespołu SF.
BrettRobi

Nie jestem pewien, czego mi brakuje, ale mój Context nie ma CodePackageActivationContext. Widzę w moich usługach bezstanowych, że jest przekazywany konstruktorowi do OwinCommunicationListener. Ale nie jestem pewien, skąd wziąć to w Aktor?
Steve

7
Zapytał przedwcześnie. Komentarze tutaj: azure.microsoft.com/en-us/documentation/articles/… Wskaż na użycie tego: CodePackageActivationContextivationContext = FabricRuntime.GetActivationContext ();
Steve

11
Jest to znacznie lepsze niż rzeczywista dokumentacja, dziękuję! Zgodziłem się również, że jest to bardzo zawiłe ... napraw ten zespół SF!
naspinski

2
Pojawiał się problem polegający na tym, że te ustawienia nie były zastępowane. Musisz zdefiniować parametry powyżej ServiceManifestImport(dziecko ApplicationManifest), ale ConfigOverridesmusisz w nim wejść (dziecko ServiceManifestImport).
Mardoxx

42

Możesz po prostu użyć zmiennych środowiskowych, tak jak każdej innej aplikacji, działa to również z plikiem wykonywalnym gościa w ramach usługi Service Fabric, w przeciwieństwie do settings.xmltego, ponieważ wymaga to wbudowanego środowiska uruchomieniowego usługi Service Fabric.

W swojej aplikacji możesz uzyskać dostęp do zmiennych środowiskowych, tak jak do każdej innej aplikacji .net, poprzez GetEnvironmentVariablemetodę Environmentklasy:

var baseUri = Environment.GetEnvironmentVariable("SuperWebServiceBaseUri");

Następnie musimy ustawić domyślne wartości zmiennych środowiskowych, odbywa się to w ServiceManifest.xmlpliku manifestu usługi.

<?xml version="1.0" encoding="utf-8" ?>
<ServiceManifest Name="MyServicePkg" Version="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <!-- snip -->
    <CodePackage Name="Code" Version="1.0.0">
        <!-- snip -->
        <EnvironmentVariables>
            <EnvironmentVariable Name="SuperWebServiceBaseUri" Value="http://localhost:12345"/>
        </EnvironmentVariables>
    </CodePackage>
    <!-- snip -->
</ServiceManifest>

Te zmienne środowiskowe można następnie zastąpić w ApplicationManifest.xmlpliku przy użyciu następującego kodu:

<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="ChileTargetType" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
    <Parameters>
        <!-- snip -->
    </Parameters>
    <ServiceManifestImport>
        <ServiceManifestRef ServiceManifestName="MyServicePkg" ServiceManifestVersion="1.0.0" />
        <EnvironmentOverrides CodePackageRef="Code">
            <EnvironmentVariable Name="SuperWebServiceBaseUri" Value="https://the-real-live-super-base-uri.com/"/>
        </EnvironmentOverrides>
    </ServiceManifestImport>
    <!-- snip -->
</ApplicationManifest>

Można to następnie sparametryzować jak każde inne ustawienie manifestu aplikacji przy użyciu local.xmli cloud.xml.

<?xml version="1.0" encoding="utf-8"?>
<Application xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="fabric:/AppFabricName.ServiceFabric" xmlns="http://schemas.microsoft.com/2011/01/fabric">
    <Parameters>
        <Parameter Name="MyService_SuperWebServiceBaseUri" Value="https://another-base-uri.com/" />
    </Parameters>
</Application>

Następnie będziemy musieli zaktualizować, ApplicationManifest.xmlaby obsługiwał te parametry;

<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="ChileTargetType" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
    <Parameters>
        <Parameter Name="MyService_SuperWebServiceBaseUri" DefaultValue="https://the-real-live-super-base-uri.com/" />
    </Parameters>
    <ServiceManifestImport>
        <ServiceManifestRef ServiceManifestName="MyServicePkg" ServiceManifestVersion="1.0.0" />
        <EnvironmentOverrides CodePackageRef="Code">
            <EnvironmentVariable Name="SuperWebServiceBaseUri" Value="[MyService_SuperWebServiceBaseUri]"/>
        </EnvironmentOverrides>
    </ServiceManifestImport>
    <!-- snip -->
</ApplicationManifest>

2
Lepszy

2
Ten link też mi pomógł: binaryradix.com/2016/10/…
Darrel K.

7

Powyższe odpowiedzi dobrze wyjaśniają, jak to się robi. Chcę dodać sidemark, dlaczego jest to „ zawiłe ”:

Musi tak być, ponieważ usługi mają być samowystarczalne. Powinny działać domyślnie w każdej aplikacji, z którą są połączone. Niezależnie od manifestu aplikacji. Usługa może więc polegać tylko na parametrach, które są przynajmniej wstępnie zdefiniowane w jej własnej konfiguracji.

Te ustawienia wstępne mogą być następnie nadpisane przez aplikację. To jedyne uniwersalne podejście.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.