Descrição Geral do Desired State Configuration para Engenheiros
Este documento destina-se a equipas de programadores e operações para compreender os benefícios do PowerShell Desired State Configuration (DSC). Para obter uma vista de nível superior do valor fornecido pelo DSC, veja Desired State Configuration Descrição Geral dos Decisores
Benefícios da Desired State Configuration
O DSC existe para:
- Diminuir a complexidade dos scripts no Windows
- Aumentar a velocidade da iteração
O conceito de "implementação contínua" está a tornar-se mais importante. A implementação contínua significa a capacidade de implementar com frequência, potencialmente muitas vezes por dia. O objetivo destas implementações não é corrigir algo, mas sim publicar algo rapidamente. Ao colocar novas funcionalidades através do desenvolvimento no funcionamento da forma mais suave e fiável possível, reduz o tempo a valor da nova lógica de negócio.
A mudança para a computação na cloud implica uma solução de implementação que utiliza um modelo de modelo "declarativo", em que um ambiente de estado final é declarado como texto e publicado num motor de implementação. Esta técnica de implementação permite uma rápida alteração, em escala, com resiliência contra ameaças de falha, porque em qualquer altura a implementação pode ser repetida de forma consistente para garantir um estado final. A criação de ferramentas e serviços que suportam este estilo de operações através da automatização é uma resposta a estas alterações.
O DSC é uma plataforma que fornece implementação, configuração e conformidade declarativas e idempotentes (repetíveis). A plataforma DSC permite-lhe garantir que os componentes do seu datacenter têm a configuração correta, o que evita erros e impede falhas de implementação dispendiosas. Ao tratar as configurações do DSC como parte do código da aplicação, o DSC permite a implementação contínua. A configuração do DSC deve ser atualizada como parte da aplicação, garantindo que os conhecimentos necessários para implementar a aplicação estão sempre atualizados e prontos para serem utilizados.
"Tenho o PowerShell, porque preciso de Desired State Configuration?"
As configurações do DSC separam a intenção ou "o que quero fazer", da execução ou "como o quero fazer". Isto significa que a lógica de execução está contida nos recursos. Os utilizadores não têm de saber como implementar ou implementar uma funcionalidade quando está disponível um recurso DSC para essa funcionalidade. Isto permite que o utilizador se concentre na estrutura da respetiva implementação.
Por exemplo, os scripts do PowerShell devem ter o seguinte aspeto:
# Create a share in Windows Server 8
New-SmbShare -Name MyShare -Path C:\Demo\Temp -FullAccess Alice -ReadAccess Bob
Este script é simples, compreensível e simples. No entanto, se tentar colocar esse script em produção, terá vários problemas. O que acontece se esse script for executado duas vezes seguidas? O que acontece se o Bob tiver anteriormente Acesso Total à partilha?
Para compensar estes problemas, uma versão "real" do script irá olhar mais de perto para algo como:
# 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
}
}
Este script é mais complexo, com muita lógica e processamento de erros. O script é mais complexo porque já não está a indicar o que pretende fazer, mas como fazê-lo.
O DSC permite-lhe dizer o que pretende fazer e a lógica subjacente é abstraída.
# 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
Este script está formatado de forma limpa e simples de ler. Os caminhos lógicos e o processamento de erros ainda estão presentes na implementação de recursos , mas invisíveis para o autor do script.
Separar o Ambiente da Estrutura
Um padrão comum no DevOps é ter vários ambientes para implementação. Por exemplo, pode existir um ambiente "dev" utilizado para criar rapidamente um protótipo de novo código. O código do ambiente "dev" entra num ambiente de "teste", onde outras pessoas verificam a nova funcionalidade. Por fim, o código entra em "prod" ou no ambiente de produção de sites em direto.
As configurações do DSC acomodam este pipeline dev-test-prod através da utilização de dados de configuração.
Isto abstrai ainda mais a diferença entre a estrutura da configuração dos nós geridos. Por exemplo, pode definir uma configuração que requer um SQL Server, um servidor IIS e um servidor de camada média. Independentemente dos nós que recebem as diferentes partes desta configuração, esses três elementos estarão sempre presentes. Pode utilizar dados de configuração para apontar os três elementos para a mesma máquina para um ambiente de programador, separar os três elementos de três máquinas diferentes para um ambiente de teste e, finalmente, para todos os servidores de produção para o ambiente prod. Para implementar nos diferentes ambientes, pode invocar Start-DscConfiguration com os dados de configuração corretos para o ambiente que pretende direcionar.
