Entendendo o caso de uso do Puppet na automação de implementação do Windows [closed]

1

Eu tenho que automatizar algumas tarefas no ambiente Windows. As tecnologias em uso são MS SQL Server 2008, IIS, MSMQ, etc. Todas as dependências para executar o aplicativo são instaladas em uma única máquina. No entanto, no ambiente de produção, as dependências são configuradas em instâncias diferentes. A instalação de dependências (SQL Server, IIS, etc) em qualquer instância é manual até o momento.

A primeira coisa que estou planejando fazer é criar uma imagem de base que contenha todos os componentes dependentes (softwares). Acho que Puppet e Powershell, junto com Jenkins, vão me ajudar nisso. Eu sou novo no Puppet e no Powershell.

Meu objetivo é:
1) automatizar a instalação de softwares na máquina base. 2) usar esta imagem em todos (ou na maioria) ambientes (Dev, Integração, Staging, UAT, Produção)

Ambos os passos acima devem ser automatizados.

Agora a confusão que eu tenho é se eu uso o Powershell para dizer, instalando o SQL Server (e outros softwares também), então onde o Puppet entra em cena? Eu posso invocar este script Powershell do Jenkins para implantar em diferentes ambientes, usando arquivos de configuração personalizados para ambientes. Não estou entendendo o verdadeiro caso de uso do Puppet aqui? Eu deveria estar realmente usando qualquer outra ferramenta como o Docker etc? Por favor me guie.

    
por Technext 13.12.2016 / 07:35

1 resposta

2

PowerShell vs Puppet é a pergunta errada

Isso nem é realmente uma coisa. O Puppet pode executar scripts do PowerShell . Mas há outra grande razão pela qual os dois não são realmente comparáveis.

O PowerShell é processual, o Puppet é declarativo. Você também pode usar o PowerShell com o Puppet , desde que use métodos para fazer com que essas chamadas aos scripts tenham uma verificação de idempotência.

exec { 'rename-guest':
  command   => file('guest/rename-guest.ps1'),
  onlyif    => file('guest/guest-exists.ps1'),
  provider  => powershell,
  logoutput => true,
}

O Puppet também tem relatórios, correção, correção automática de alterações fora do Puppet (conhecido como desvio de configuração) e muitos outros recursos que o tornam uma ferramenta de gerenciamento de configuração e não uma linguagem de script.

O Puppet + PowerShell é uma solução muito mais completa. Agora, vamos examinar os recursos nativos para realmente reduzir o código.

Exemplo - Garanta a instalação do IIS e do ASP.NET

Digamos que você queira executar um script para garantir a instalação do IIS e do ASP.NET. Você precisaria garantir que você fornecesse todas as verificações adequadas para que, se esse script fosse executado mais de uma vez, não ocorresse erro. Você basicamente deseja garantir que o IIS esteja instalado e que o ASP.NET esteja configurado e saia do contrário.

Fazer isso no Puppet é trivial. Digamos que isso esteja sendo implantado em uma caixa do Windows Server 2012:

  windowsfeature { 'Web-WebServer':
    installmanagementtools => true,
  } ->
  windowsfeature { 'Web-Asp-Net45':
  } 

Isso é literalmente , tudo o que você precisa para garantir que o IIS e o ASP.NET estejam instalados. Imagine a quantidade de linhas do PowerShell que você precisaria escrever para fazer o mesmo.

Há um exemplo mais completo disso para configurar um site completo com permissões em puppet-chocolatey_server .

Gerenciando a instalação do SQL Server

Você pode usar o módulo do SQL Server . Aqui está um exemplo (há mais exemplos envolvidos disponíveis):

sqlserver_instance{ 'MSSQLSERVER':
  features              => ['SQL'],
  source                => 'E:/',
  sql_sysadmin_accounts => ['myuser'],
} 

Instalando o software

Isso se torna trivial quando você usa Chocolatey .

  • Sim, o Chocolatey se baseia em instalações autônomas e no PowerShell.
  • Sim, o Chocolatey funciona com zips e binários de tempo de execução.
  • Não, não requer internet.
  • Também não exige que você baixe coisas da internet em tempo de execução.

O Chocolatey é uma ferramenta completa de gerenciamento de software que integra diretamente no Puppet .

As organizações que normalmente usam o Chocolatey não usam o repositório de pacotes da comunidade ( link ) porque os pacotes oferecidos lá são sujeitos a direitos de distribuição e precisam ser baixados de locais oficiais em tempo de execução. As organizações geralmente têm uma tolerância muito baixa para quebras, portanto, criam e hospedam seus próprios pacotes (internamente, eles não têm as legalidades da distribuição). Dessa forma, o processo é completamente seguro, repetitivo e confiável.

package { 'notepadplusplus':
  ensure   => latest,
  provider => 'chocolatey',
  source   => 'https://internal/odata/repo/',
}
    
por 16.12.2016 / 10:47