Gerenciamento centralizado de partes do app.config para serviços .NET auto-hospedados

Question

Qual será a melhor maneira de lidar com esses cenários, se eles não forem únicos, mas regulares:

• Serviços auto-hospedados em um grande número de máquinas são necessários para serem reorientados para bancos de dados diferentes de maneira centralizada. Por isso, é necessário alterar o app.configs e reiniciar os serviços.
• Todos os serviços precisam obter uma nova configuração de registro (por exemplo), digamos a seção de atualização no App.config e reinicie

Claro que isso pode ser automatizado usando o powershell, mas definitivamente existem ferramentas para isso. Eu sei, que algumas empresas usam sistemas de gerenciamento de configuração para isso - como Sal , Ansible , Chef ou Puppet , mas eles são adequados para esse tipo de tarefa.

Eu também agora sobre a solução Java Spring cloud config , mas não encontrei algo assim para. NET

    

Answer 1

As tarefas que você está descrevendo podem ser resolvidas de várias maneiras. Nenhum caminho é "melhor", pois cada um tem seus prós e contras.

A indústria como um todo tem evoluído de scripts para gerenciamento de configuração para sistemas imutáveis.

Como exemplo, para gerenciar o web.config de um servidor da Web IIS, você emite comandos appcmd.exe. Usamos o Chef e o livro de receitas do IIS para abstrair os recursos idempotentes do comando appcmd.exe.

  iis_config "session sql_provider" do
    cfg_cmd "Foobar/#{site} -section:system.web/sessionState /+\"providers.[name='#{session_name}',connectionString='#{session_connection_string}',type='#{session_type}']\""
    action :set
      notifies :restart, 'iis_site[mysite]'
  end

Aqui tudo dentro de '# {}' é uma variável de chef. Se o recurso for executado, ele acionará a reinicialização do serviço IIS.

A vantagem de não usar o appcmd.exe diretamente, mas abstraindo-o para um recurso, é que um recurso pode facilmente levar variáveis como parâmetros. Dessa forma, você pode escrever seu código uma vez, mas usá-lo em vários datacenters e ambientes. O objetivo final é ser capaz de escrever uma política para cada tipo de servidor e deixar o gerenciamento de configuração colocar o servidor em alinhamento com a política.

Outro exemplo de gerenciamento de um arquivo de configuração de registro dentro do chef.

template "#{node['web']['path']}/log4net.config.xml" do
  source 'wwwroot/log4net.config.erb'
  variables(
    :log_level => node['web']['log4net']['log_level']
  )
  action :create
end

O arquivo xml é então "moldado" como um modelo erb. Tudo no meio <% = -% > é uma variável

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <log4net>
    <root>
      <level value="<%= @log_level -%>"/>

Você pode então executar o chef em uma programação, para que a variável nunca mude. O gerenciamento de configuração coloca o arquivo no estado desejado.

Ansible, Chef, Puppet e Salt operam com princípios muito semelhantes.