Oddzielanie danych konfiguracji i środowiska
Dotyczy: Windows PowerShell 4.0, Windows PowerShell 5.0
Może być przydatne oddzielenie danych używanych w konfiguracji DSC od samej konfiguracji przy użyciu danych konfiguracji. W ten sposób można użyć jednej konfiguracji dla wielu środowisk.
Jeśli na przykład tworzysz aplikację, możesz użyć jednej konfiguracji dla środowisk deweloperskich i produkcyjnych, a następnie użyć danych konfiguracji do określenia danych dla każdego środowiska.
Co to są dane konfiguracji?
Dane konfiguracji to dane zdefiniowane w tabeli skrótów i przekazywane do konfiguracji DSC podczas kompilowania tej konfiguracji.
Aby uzyskać szczegółowy opis tabeli skrótów ConfigurationData , zobacz Using configuration data (Używanie danych konfiguracji).
Prosty przykład
Przyjrzyjmy się bardzo prostemu przykładowi, aby zobaczyć, jak to działa. Utworzymy jedną konfigurację, która gwarantuje, że usługi IIS znajdują się w niektórych węzłach, a funkcja Hyper-V jest obecna w innych:
Configuration MyDscConfiguration {
Node $AllNodes.Where{$_.Role -eq "WebServer"}.NodeName
{
WindowsFeature IISInstall {
Ensure = 'Present'
Name = 'Web-Server'
}
}
Node $AllNodes.Where{$_.Role -eq "VMHost"}.NodeName
{
WindowsFeature HyperVInstall {
Ensure = 'Present'
Name = 'Hyper-V'
}
}
}
$MyData =
@{
AllNodes =
@(
@{
NodeName = 'VM-1'
Role = 'WebServer'
},
@{
NodeName = 'VM-2'
Role = 'VMHost'
}
)
}
MyDscConfiguration -ConfigurationData $MyData
Ostatni wiersz tego skryptu kompiluje konfigurację, przekazując $MyData jako wartość Parametr ConfigurationData .
Wynikiem jest utworzenie dwóch plików MOF:
Directory: C:\DscTests\MyDscConfiguration
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 3/31/2017 5:09 PM 1968 VM-1.mof
-a---- 3/31/2017 5:09 PM 1970 VM-2.mof
$MyData Określa dwa różne węzły, z których każdy ma własne NodeName i Role. Konfiguracja dynamicznie tworzy bloki Node przez pobranie kolekcji węzłów z $MyData (w szczególności $AllNodes) i filtruje ją względem Role właściwości.
Definiowanie środowisk programistycznych i produkcyjnych przy użyciu danych konfiguracji
Przyjrzyjmy się kompletnemu przykładowi, który używa jednej konfiguracji do konfigurowania środowisk deweloperskich i produkcyjnych witryny internetowej. W środowisku projektowym zarówno usługi IIS, jak i SQL Server są instalowane w jednym węźle. W środowisku produkcyjnym usługi IIS i SQL Server są instalowane w oddzielnych węzłach. Użyjemy pliku psd1 danych konfiguracji, aby określić dane dla dwóch różnych środowisk.
Plik danych konfiguracji
Zdefiniujemy dane środowiska deweloperskiego i produkcyjnego w pliku o nazwie DevProdEnvData.psd1 w następujący sposób:
@{
AllNodes = @(
@{
NodeName = "*"
SQLServerName = "MySQLServer"
SqlSource = "C:\Software\Sql"
DotNetSrc = "C:\Software\sxs"
WebSiteName = "New website"
},
@{
NodeName = "Prod-SQL"
Role = "MSSQL"
},
@{
NodeName = "Prod-IIS"
Role = "Web"
SiteContents = "C:\Website\Prod\SiteContents\"
SitePath = "\\Prod-IIS\Website\"
},
@{
NodeName = "Dev"
Role = "MSSQL", "Web"
SiteContents = "C:\Website\Dev\SiteContents\"
SitePath = "\\Dev\Website\"
}
)
}
Plik skryptu konfiguracji
Teraz w konfiguracji, która jest zdefiniowana w .ps1 pliku, filtrujemy węzły zdefiniowane w DevProdEnvData.psd1 ramach ich roli (MSSQL, Devlub obu) i odpowiednio je konfigurujemy. Środowisko programistyczne ma zarówno SQL Server, jak i usługi IIS w jednym węźle, podczas gdy środowisko produkcyjne ma je w dwóch różnych węzłach. Zawartość witryny jest również inna, jak określono we właściwościach SiteContents .
Na końcu skryptu konfiguracji wywołujemy konfigurację (skompilujemy ją w dokumencie MOF), przekazując DevProdEnvData.psd1 jako $ConfigurationData parametr .
Uwaga: Ta konfiguracja wymaga modułów
xSqlPsixWebAdministrationzainstalowania ich w węźle docelowym.
Zdefiniujmy konfigurację w pliku o nazwie MyWebApp.ps1:
Configuration MyWebApp
{
Import-DSCResource -ModuleName PSDesiredStateConfiguration
Import-DSCResource -ModuleName xSqlPs
Import-DSCResource -ModuleName xWebAdministration
Node $AllNodes.Where{$_.Role -contains "MSSQL"}.NodeName
{
# Install prerequisites
WindowsFeature installdotNet35
{
Ensure = "Present"
Name = "Net-Framework-Core"
Source = "c:\software\sxs"
}
# Install SQL Server
xSqlServerInstall InstallSqlServer
{
InstanceName = $Node.SQLServerName
SourcePath = $Node.SqlSource
Features = "SQLEngine,SSMS"
DependsOn = "[WindowsFeature]installdotNet35"
}
}
Node $AllNodes.Where{$_.Role -contains "Web"}.NodeName
{
# Install the IIS role
WindowsFeature IIS
{
Ensure = 'Present'
Name = 'Web-Server'
}
# Install the ASP .NET 4.5 role
WindowsFeature AspNet45
{
Ensure = 'Present'
Name = 'Web-Asp-Net45'
}
# Stop the default website
xWebsite DefaultSite
{
Ensure = 'Present'
Name = 'Default Web Site'
State = 'Stopped'
PhysicalPath = 'C:\inetpub\wwwroot'
DependsOn = '[WindowsFeature]IIS'
}
# Copy the website content
File WebContent
{
Ensure = 'Present'
SourcePath = $Node.SiteContents
DestinationPath = $Node.SitePath
Recurse = $true
Type = 'Directory'
DependsOn = '[WindowsFeature]AspNet45'
}
# Create the new Website
xWebsite NewWebsite
{
Ensure = 'Present'
Name = $Node.WebSiteName
State = 'Started'
PhysicalPath = $Node.SitePath
DependsOn = '[File]WebContent'
}
}
}
MyWebApp -ConfigurationData DevProdEnvData.psd1
Po uruchomieniu tej konfiguracji tworzone są trzy pliki MOF (po jednym dla każdego nazwanego wpisu w tablicy AllNodes ):
Directory: C:\DscTests\MyWebApp
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 3/31/2017 5:47 PM 2944 Prod-SQL.mof
-a---- 3/31/2017 5:47 PM 6994 Dev.mof
-a---- 3/31/2017 5:47 PM 5338 Prod-IIS.mof
Korzystanie z danych innych niż węzły
Możesz dodać dodatkowe klucze do tabeli skrótów ConfigurationData dla danych, które nie są specyficzne dla węzła. Poniższa konfiguracja zapewnia obecność dwóch witryn internetowych. Dane dla każdej witryny sieci Web są definiowane w tablicy AllNodes . Plik Config.xml jest używany dla obu witryn internetowych, dlatego definiujemy go w dodatkowym kluczu o nazwie NonNodeData. Należy pamiętać, że możesz mieć dowolną liczbę dodatkowych kluczy i możesz nadać im dowolną nazwę. NonNodeData nie jest słowem zastrzeżonym, to właśnie postanowiliśmy nazwać dodatkowy klucz.
Dostęp do dodatkowych kluczy uzyskuje się przy użyciu specjalnej zmiennej $ConfigurationData. W tym przykładzie ConfigFileContents uzyskuje się dostęp do wiersza:
Contents = $ConfigurationData.NonNodeData.ConfigFileContents
File w bloku zasobów.
$MyData =
@{
AllNodes =
@(
@{
NodeName = "*"
LogPath = "C:\Logs"
},
@{
NodeName = "VM-1"
SiteContents = "C:\Site1"
SiteName = "Website1"
},
@{
NodeName = "VM-2"
SiteContents = "C:\Site2"
SiteName = "Website2"
}
);
NonNodeData =
@{
ConfigFileContents = (Get-Content C:\Template\Config.xml)
}
}
configuration WebsiteConfig
{
Import-DscResource -ModuleName xWebAdministration -Name MSFT_xWebsite
node $AllNodes.NodeName
{
xWebsite Site
{
Name = $Node.SiteName
PhysicalPath = $Node.SiteContents
Ensure = "Present"
}
File ConfigFile
{
DestinationPath = $Node.SiteContents + "\\config.xml"
Contents = $ConfigurationData.NonNodeData.ConfigFileContents
}
}
}
Zobacz też
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla