Централизованное управление частями app.config для собственных служб .NET

Question

Что будет лучшим способом справиться с этими сценариями, если они не разовые, а регулярные:

• Самостоятельно размещаемые сервисы на довольно большом количестве машин должны быть переназначены в другую базу данных централизованным способом. Так что требуется изменить app.configs и перезапустить сервисы.
• Все службы должны получить новую конфигурацию регистрации (например), скажем, обновить раздел в App.config и перезапустить

Конечно, это можно автоматизировать с помощью powershell, но для этого определенно есть инструменты. Я знаю, что некоторые компании используют для этого системы управления конфигурациями - например, Salt, Ansible, Chef или Puppet, но подходят ли они для такого рода задач.

Я также сейчас о решении Java Spring конфигурации облака, но не нашел что-то подобное для .NET

Answer 1

Задачи, которые вы описываете, могут быть решены несколькими способами. Ни один из способов не является "лучшим", поскольку у каждого есть свои плюсы и минусы.

Индустрия в целом развивается от сценариев к управлению конфигурациями и неизменным системам.

Например, чтобы управлять web.config веб-сервера IIS, вы запускаете команды appcmd.exe. Мы используем Chef и IIS cookbook для абстрагирования идемпотентных ресурсов команды 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

Здесь все внутри '# {}' является переменной chef. Если ресурс запускается, он запускает перезапуск службы IIS.

Преимущество не прямого использования appcmd.exe, а его абстрагирования от ресурса в том, что ресурс может легко принимать переменные в качестве параметров. Таким образом, вы можете написать свой код один раз, но использовать его в нескольких центрах обработки данных и средах. Конечная цель состоит в том, чтобы иметь возможность написать политику для каждого типа сервера и позволить управлению конфигурацией привести сервер в соответствие с политикой.

Еще один пример управления файлом конфигурации журнала внутри 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

Затем XML-файл "шаблонизируется" как шаблон erb. Все, что между <% = -%> является переменной

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

Затем вы можете запустить chef по расписанию, так что если переменная когда-либо изменится. Управление конфигурацией переводит файл в желаемое состояние.

Ansible, Chef, Puppet и Salt работают по очень схожим принципам.