A célállapot-konfiguráció áttekintése mérnökök számára
Ez a dokumentum fejlesztői és üzemeltetési csapatok számára készült, hogy megismerje a PowerShell-Desired State Configuration (DSC) előnyeit. A DSC által nyújtott érték magasabb szintű megtekintéséhez tekintse meg Desired State Configuration döntéshozók számára készült áttekintést
A Desired State Configuration előnyei
A DSC a következőhöz létezik:
- A parancsfájlok összetettségének csökkentése a Windowsban
- Az iteráció sebességének növelése
A "folyamatos üzembe helyezés" fogalma egyre fontosabbá válik. A folyamatos üzembe helyezés azt jelenti, hogy gyakran, akár naponta többször is üzembe helyezhetők. Ezeknek az üzemelő példányoknak nem az a célja, hogy kijavítanak valamit, hanem hogy gyorsan közzétehessenek valamit. Az új funkciók lehető leggördülékenyebb és megbízható működésbe hozásával csökkentheti az új üzleti logika idő–érték arányát.
A felhőalapú számítástechnika felé való elmozdulás olyan üzembehelyezési megoldást jelent, amely egy "deklaratív" sablonmodellt használ, ahol a végfelhasználói környezet szövegként van deklarálva és közzétéve az üzembehelyezési motorban. Ez az üzembe helyezési technika lehetővé teszi a gyors, nagy léptékű módosítást, amely rugalmasságot biztosít a meghibásodás veszélyével szemben, mivel az üzembe helyezés bármikor következetesen megismételhető a végső állapot garantálása érdekében. Az ilyen típusú műveleteket automatizálással támogató eszközök és szolgáltatások létrehozása választ ad ezekre a változásokra.
A DSC egy olyan platform, amely deklaratív és idempotens (megismételhető) üzembe helyezést, konfigurálást és megfelelőséget biztosít. A DSC platform lehetővé teszi annak biztosítását, hogy az adatközpont összetevői a megfelelő konfigurációval rendelkezzenek, így elkerülhetők a hibák, és elkerülhetők a költséges üzembehelyezési hibák. A DSC-konfigurációk alkalmazáskód részeként történő kezelésével a DSC lehetővé teszi a folyamatos üzembe helyezést. A DSC-konfigurációt frissíteni kell az alkalmazás részeként, biztosítva, hogy az alkalmazás üzembe helyezéséhez szükséges ismeretek mindig naprakészek és használatra készek legyenek.
"Van PowerShellem, miért van szükségem Desired State Configuration?"
A DSC-konfigurációk elkülönítik a szándékot vagy a "mit szeretnék tenni" a végrehajtástól vagy a "hogyan akarom csinálni" beállítást. Ez azt jelenti, hogy a végrehajtás logikája az erőforrásokban található. A felhasználóknak nem kell tudniuk, hogyan kell implementálni vagy üzembe helyezni egy funkciót, ha az adott szolgáltatáshoz elérhető egy DSC-erőforrás. Ez lehetővé teszi, hogy a felhasználó az üzemelő példány szerkezetére összpontosítson.
A PowerShell-szkripteknek például a következőképpen kell kinéznie:
# Create a share in Windows Server 8
New-SmbShare -Name MyShare -Path C:\Demo\Temp -FullAccess Alice -ReadAccess Bob
Ez a szkript egyszerű, érthető és egyszerű. Ha azonban megpróbálja éles környezetben üzembe helyezni a szkriptet, több problémába ütközik. Mi történik, ha a szkriptet egymás után kétszer futtatják? Mi történik, ha Bob korábban teljes hozzáféréssel rendelkezett a megosztáshoz?
A problémák kompenzálása érdekében a szkript "valódi" verziója közelebb kerül a következőhöz:
# But actually creating a share in an idempotent way would be
$shareExists = $false
$smbShare = Get-SmbShare -Name $Name -ErrorAction SilentlyContinue
if($smbShare -ne $null)
{
Write-Verbose -Message "Share with name $Name exists"
$shareExists = $true
}
if ($shareExists -eq $false)
{
Write-Verbose "Creating share $Name to ensure it is Present"
New-SmbShare @PSBoundParameters
}
else
{
# Need to call either Set-SmbShare or *ShareAccess cmdlets
if ($PSBoundParameters.ContainsKey("ChangeAccess"))
{
#...etc, etc, etc
}
}
Ez a szkript összetettebb, rengeteg logikával és hibakezeléssel. A szkript összetettebb, mert már nem azt adja meg, hogy mit szeretne tenni, hanem azt, hogy hogyan.
A DSC lehetővé teszi, hogy elmondja, mit szeretne tenni, és a mögöttes logika absztrakcióra kerül.
# A configuration is a special kind of PowerShell function
Configuration Sample_Share
{
Import-DSCResource -ModuleName xSmbShare
# Nodes are the endpoint we wish to configure
# A Configuration block can have zero or more Node blocks
Node $NodeName
{
# Next, specify one or more resource blocks
# Resources are simply PowerShell modules that
# implement the logic of "how" to execute a task
xSmbShare MySMBShare
{
Ensure = "Present"
Name = "MyShare"
Path = "C:\Demo\Temp"
ReadAccess = "Bob"
FullAccess = "Alice"
Description = "This is an updated description for this share"
}
}
}
#Run the function to compile the configuration
Sample_Share
#Pass the configuration to the nodes we defined and configure them
Start-DscConfiguration Sample_Share
Ez a szkript tisztán formázott és könnyen olvasható. A logikai útvonalak és a hibakezelés továbbra is jelen van az erőforrás-implementációban, de a szkript szerzője számára láthatatlan.
A környezet és a struktúra szétválasztása
A DevOps gyakori mintája, hogy több környezettel kell rendelkeznie az üzembe helyezéshez. Előfordulhat például, hogy az új kód gyors prototípusához egy "fejlesztői" környezet használható. A "dev" környezetből származó kód egy "teszt" környezetbe kerül, ahol mások ellenőrzik az új funkciókat. Végül a kód a "prod" vagy az élő hely éles környezetébe kerül.
A DSC-konfigurációk ezt a dev-test-prod folyamatot konfigurációs adatok használatával biztosítják.
Ez további kivonatokat ad a konfiguráció struktúrája és a felügyelt csomópontok közötti különbségről. Definiálhat például olyan konfigurációt, amelyhez SQL-kiszolgálóra, IIS-kiszolgálóra és középső rétegbeli kiszolgálóra van szükség. Függetlenül attól, hogy milyen csomópontok kapják meg a konfiguráció különböző részeit, ez a három elem mindig jelen lesz. A konfigurációs adatok segítségével mindhárom elemet ugyanarra a gépre irányíthatja egy fejlesztői környezetben, elkülönítheti a három elemet három különböző gépre egy tesztkörnyezetben, végül pedig az éles környezet összes éles kiszolgálója felé. A különböző környezetekben való üzembe helyezéshez meghívhatja Start-DscConfiguration
a megcélzni kívánt környezet megfelelő konfigurációs adatait.
Lásd még:
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: