Как создать свой инвентарь

Ansible работает с несколькими управляемыми узлами или «хостами» в вашей инфраструктуре одновременно, используя список или группу списков, известных как инвентарь. После определения вашего инвентаря вы используете шаблоны, чтобы выбрать хосты или группы, с которыми Ansible должен взаимодействовать.

По умолчанию расположение инвентаря — это файл, называемый /etc/ansible/hosts. Вы можете указать другой файл инвентаря в командной строке, используя опцию -i <path>. Вы также можете использовать несколько файлов инвентаря одновременно и/или получать инвентарь из динамических или облачных источников или разных форматов (YAML, ini и так далее), как описано в работе с динамическим инвентарем. Введенные в версию 2.4, Ansible имеют плагины инвентаря для повышения гибкости и настраиваемости.

• Основные принципы инвентаря: форматы, хосты и группы

  • Группы по умолчанию
  • Хосты в нескольких группах
  • Добавление диапазонов хостов
• Добавление переменных в инвентарь

• Назначение переменной одному устройству: переменные хоста

  • Псевдонимы инвентаря

• Назначение переменной многим устройствам: переменные группы

  • Наследование значений переменных: переменные группы для групп групп
• Организация переменных хоста и группы
• Как объединяются переменные
• Использование нескольких источников инвентаря

• Подключение к хостам: параметры инвентаря поведения

  • Типы подключений, отличные от SSH

• Примеры настройки инвентаря

  • Пример: Один инвентарь на одну среду
  • Пример: Группировка по функции
  • Пример: Группировка по расположению

Основные принципы инвентаря: форматы, хосты и группы

Файл инвентаря может быть в одном из многих форматов в зависимости от используемых плагинов инвентаря. Наиболее распространённые форматы — INI и YAML. Базовый файл INI /etc/ansible/hosts может выглядеть следующим образом:

mail.example.com

[webservers]
foo.example.com
bar.example.com

[dbservers]
one.example.com
two.example.com
three.example.com

Заголовки в квадратных скобках — это имена групп, которые используются для классификации хостов и определения, какие хосты вы контролируете в определённые моменты и с какой целью. Имена групп должны соответствовать тем же правилам, что и создание допустимых имён переменных.

Вот тот же базовый файл инвентаря в формате YAML:

all:
  hosts:
    mail.example.com:
  children:
    webservers:
      hosts:
        foo.example.com:
        bar.example.com:
    dbservers:
      hosts:
        one.example.com:
        two.example.com:
        three.example.com:

Группы по умолчанию

Существует две группы по умолчанию: all и ungrouped. Группа all содержит каждый хост. Группа ungrouped содержит все хосты, не принадлежащие другим группам помимо all. Каждый хост всегда будет принадлежать как минимум двум группам (all и ungrouped или all и какой-либо другой группе). Хотя all и ungrouped всегда присутствуют, они могут быть неявными и не отображаться в списках групп, как group_names.

Хосты в нескольких группах

Вы можете (и, вероятно, будете) размещать каждый хост в нескольких группах. Например, веб-сервер производства в дата-центре в Атланте может быть включён в группы [prod], [atlanta] и [webservers]. Вы можете создавать группы, которые отслеживают:

• Что — Приложение, стек или микросервис (например, серверы баз данных, веб-серверы и так далее).
• Где — Дата-центр или регион, для работы с локальным DNS, хранилищем и так далее (например, восток, запад).
• Когда — Этап разработки, чтобы избежать тестирования на производственных ресурсах (например, prod, test).

Расширение предыдущего файла инвентаря YAML для включения чего, когда и где будет выглядеть следующим образом:

all:
  hosts:
    mail.example.com:
  children:
    webservers:
      hosts:
        foo.example.com:
        bar.example.com:
    dbservers:
      hosts:
        one.example.com:
        two.example.com:
        three.example.com:
    east:
      hosts:
        foo.example.com:
        one.example.com:
        two.example.com:
    west:
      hosts:
        bar.example.com:
        three.example.com:
    prod:
      hosts:
        foo.example.com:
        one.example.com:
        two.example.com:
    test:
      hosts:
        bar.example.com:
        three.example.com:

Вы можете видеть, что one.example.com существует в группах dbservers, east и prod.

Вы также можете использовать вложенные группы, чтобы упростить prod и test в этом инвентаре, для того же результата:

all:
  hosts:
    mail.example.com:
  children:
    webservers:
      hosts:
        foo.example.com:
        bar.example.com:
    dbservers:
      hosts:
        one.example.com:
        two.example.com:
        three.example.com:
    east:
      hosts:
        foo.example.com:
        one.example.com:
        two.example.com:
    west:
      hosts:
        bar.example.com:
        three.example.com:
    prod:
      children:
        east:
    test:
      children:
        west:

Дополнительные примеры организации инвентарей и группировки хостов см. в разделе Примеры настройки инвентаря.

Добавление диапазонов хостов

Если у вас много хостов с похожим шаблоном, вы можете добавить их в виде диапазона вместо отдельного перечисления каждого имени хоста:

В формате INI:

[webservers]
www[01:50].example.com

В формате YAML:

...
  webservers:
    hosts:
      www[01:50].example.com:

Вы можете указать шаг (приращения между номерами последовательности) при определении числового диапазона хостов:

В формате INI:

[webservers]
www[01:50:2].example.com

В формате YAML:

...
  webservers:
    hosts:
      www[01:50:2].example.com:

Для числовых шаблонов можно включать или исключать ведущие нули по желанию. Диапазоны включают крайние значения. Вы также можете определить алфавитные диапазоны:

[databases]
db-[a:f].example.com

Добавление переменных в инвентарь

Вы можете хранить значения переменных, относящихся к конкретному хосту или группе в инвентаре. Начать можно с добавления переменных непосредственно к хостам и группам в вашем основном файле инвентаря. Однако по мере добавления всё большего количества управляемых узлов в ваш Ansible-инвентарь, вы, скорее всего, захотите хранить переменные в отдельных файлах переменных хостов и групп. Подробности см. в определении переменных в инвентаре.

Назначение переменной одному устройству: переменные хоста

Вы можете легко назначить переменную одному хосту, а затем использовать её в будущих задачах. В формате INI:

[atlanta]
host1 http_port=80 maxRequestsPerChild=808
host2 http_port=303 maxRequestsPerChild=909

В формате YAML:

atlanta:
  hosts:
    host1:
      http_port: 80
      maxRequestsPerChild: 808
    host2:
      http_port: 303
      maxRequestsPerChild: 909

Уникальные значения, такие как нестандартные порты SSH, хорошо подходят в качестве переменных хоста. Вы можете добавить их в ваш Ansible-инвентарь, добавив номер порта после имени хоста с двоеточием:

badwolf.example.com:5309

Переменные подключения также хорошо подходят в качестве переменных хоста:

[targets]

localhost              ansible_connection=local
other1.example.com     ansible_connection=ssh        ansible_user=myuser
other2.example.com     ansible_connection=ssh        ansible_user=myotheruser

Псевдонимы инвентаря

Вы также можете определить псевдонимы в своём инвентаре:

В формате INI:

jumper ansible_port=5555 ansible_host=192.0.2.50

В формате YAML:

...
  hosts:
    jumper:
      ansible_port: 5555
      ansible_host: 192.0.2.50

В приведённом выше примере при работе Ansible с псевдонимом хоста «jumper» произойдёт подключение к 192.0.2.50 на порту 5555. См. параметры поведения инвентаря, чтобы дополнительно настроить подключение к хостам.

В общем случае это не лучший способ определения переменных, которые описывают вашу системную политику. Установка переменных в основном файле инвентаря — это просто сокращение. См. Организация переменных хоста и группы для рекомендаций по хранению значений переменных в отдельных файлах в каталоге «host_vars».

Назначение переменной многим устройствам: переменные группы

Если все хосты в группе имеют одинаковое значение переменной, вы можете применить эту переменную ко всей группе сразу. В формате INI:

[atlanta]
host1
host2

[atlanta:vars]
ntp_server=ntp.atlanta.example.com
proxy=proxy.atlanta.example.com

В формате YAML:

atlanta:
  hosts:
    host1:
    host2:
  vars:
    ntp_server: ntp.atlanta.example.com
    proxy: proxy.atlanta.example.com

Переменные группы — удобный способ применения переменных ко многим хостам одновременно. Однако перед выполнением Ansible всегда сглаживает переменные, включая переменные инвентаря, на уровне хоста. Если хост является членом нескольких групп, Ansible читает значения переменных из всех этих групп. Если вы назначаете разные значения одной и той же переменной в разных группах, Ansible выбирает, какое значение использовать, в соответствии с внутренними правилами объединения.

Наследование значений переменных: переменные группы для групп групп

Можно создавать группы групп, используя суффикс :children в INI или запись children: в YAML. Вы можете применять переменные к этим группам групп, используя :vars или vars::

В INI:

[atlanta]
host1
host2

[raleigh]
host2
host3

[southeast:children]
atlanta
raleigh

[southeast:vars]
some_server=foo.southeast.example.com
halon_system_timeout=30
self_destruct_countdown=60
escape_pods=2

[usa:children]
southeast
northeast
southwest
northwest

В YAML:

all:
  children:
    usa:
      children:
        southeast:
          children:
            atlanta:
              hosts:
                host1:
                host2:
            raleigh:
              hosts:
                host2:
                host3:
          vars:
            some_server: foo.southeast.example.com
            halon_system_timeout: 30
            self_destruct_countdown: 60
            escape_pods: 2
        northeast:
        northwest:
        southwest:

Если вам нужно хранить списки или данные хешей или вы предпочитаете хранить переменные, специфичные для хоста и группы, отдельно от файла инвентаризации, см. Организация переменных хоста и группы.

Дочерние группы имеют несколько свойств, которые следует отметить:

• Любой хост, являющийся членом дочерней группы, автоматически является членом родительской группы.
• Переменные дочерней группы будут иметь более высокий приоритет (переопределение) переменных родительской группы.
• Группы могут иметь несколько родителей и детей, но не циклические отношения.
• Хосты также могут входить в несколько групп, но будет только один экземпляр хоста, объединяющий данные из нескольких групп.

Организация переменных хоста и группы

Хотя вы можете хранить переменные в основном файле инвентаризации, хранение отдельных файлов переменных хоста и группы может помочь вам организовать значения переменных более эффективно. Файлы переменных хоста и группы должны использовать синтаксис YAML. Допустимые расширения файлов включают ‘.yml’, ‘.yaml’, ‘.json’ или без расширения файла. См. Синтаксис YAML, если вы новичок в YAML.

Ansible загружает файлы переменных хоста и группы, выполняя поиск по путям, относительным к файлу инвентаризации или файлу книги задач. Если ваш файл инвентаризации по адресу /etc/ansible/hosts содержит хост с именем «foosball», который принадлежит двум группам, «raleigh» и «webservers», этот хост будет использовать переменные в файлах YAML по следующим адресам:

/etc/ansible/group_vars/raleigh # can optionally end in '.yml', '.yaml', or '.json'
/etc/ansible/group_vars/webservers
/etc/ansible/host_vars/foosball

Например, если вы группируете хосты в своей инвентаризации по центрам обработки данных, и каждый центр обработки данных использует свой собственный NTP-сервер и сервер базы данных, вы можете создать файл под названием /etc/ansible/group_vars/raleigh для хранения переменных для группы raleigh:

---
ntp_server: acme.example.org
database_server: storage.example.org

Вы также можете создать каталоги, названные в честь ваших групп или хостов. Ansible будет читать все файлы в этих каталогах в лексикографическом порядке. Пример с группой «raleigh»:

/etc/ansible/group_vars/raleigh/db_settings
/etc/ansible/group_vars/raleigh/cluster_settings

Все хосты в группе «raleigh» будут иметь доступ к переменным, определенным в этих файлах. Это может быть очень полезно для сохранения организации ваших переменных, когда один файл становится слишком большим или когда вы хотите использовать Ansible Vault для некоторых переменных группы.

Вы также можете добавить каталоги group_vars/ и host_vars/ в каталог книги задач. Команда ansible-playbook по умолчанию ищет эти каталоги в текущей рабочей директории. Другие команды Ansible (например, ansible, ansible-console, и так далее) будут искать только group_vars/ и host_vars/ в каталоге инвентаризации. Если вы хотите, чтобы другие команды загружали переменные групп и хостов из каталога книги задач, вы должны указать опцию --playbook-dir в командной строке. Если вы загружаете файлы инвентаризации как из каталога книги задач, так и из каталога инвентаризации, переменные из каталога книги задач будут переопределять переменные, заданные в каталоге инвентаризации.

Хранение файла инвентаризации и переменных в репозитории Git (или другом системе контроля версий) — отличный способ отслеживать изменения в инвентаризации и переменных хостов.

Как объединяются переменные

По умолчанию переменные объединяются/сглаживаются для конкретного хоста перед запуском книги задач. Это позволяет Ansible сосредоточиться на хосте и задаче, поэтому группы фактически не сохраняются за пределами инвентаризации и сопоставления хостов. По умолчанию Ansible переопределяет переменные, включая те, что определены для группы и/или хоста (см. DEFAULT_HASH_BEHAVIOUR). Порядок/приоритет (от низкого к высокому):

• группа all (потому что она является «родительской» для всех остальных групп)
• родительская группа
• дочерняя группа
• хост

По умолчанию Ansible объединяет группы на одном уровне родитель/дочерний в порядке ASCII, и последняя загруженная группа переписывает предыдущие группы. Например, переменные a_group будут объединены с b_group, а переменные b_group, соответствующие переменным a_group, перепишут их.

Вы можете изменить это поведение, задав переменную группы ansible_group_priority для изменения порядка объединения групп одного уровня (после разрешения порядка родитель/дочерний). Чем больше число, тем позже она будет объединена, получив более высокий приоритет. Эта переменная по умолчанию равна 1, если не задана. Например:

a_group:
  vars:
    testvar: a
    ansible_group_priority: 10
b_group:
  vars:
    testvar: b

В этом примере, если у обеих групп одинаковый приоритет, результат обычно был бы testvar == b, но поскольку мы придаём a_group более высокий приоритет, результатом будет testvar == a.

Использование нескольких источников инвентаризации

Вы можете одновременно использовать несколько источников инвентаризации (каталоги, динамические скрипты инвентаризации или файлы, поддерживаемые плагинами инвентаризации), передавая несколько параметров инвентаризации из командной строки или настраивая ANSIBLE_INVENTORY. Это может быть полезно, когда вы хотите одновременно нацеливаться на разные среды, такие как staging и production, для конкретного действия.

Укажите два источника из командной строки так:

ansible-playbook get_logs.yml -i staging -i production

Помните, что если в инвентаризациях есть конфликты переменных, они разрешаются в соответствии с правилами, описанными в Как объединяются переменные и Приоритет переменных: где следует поместить переменную?. Порядок слияния контролируется порядком параметров источника инвентаризации. Если [all:vars] в инвентаризации staging определяет myvar = 1, но инвентаризация production определяет myvar = 2, книга задач будет запущена с myvar = 2. Результат будет обратным, если книга задач будет запущена с -i production -i staging.

Объединение источников инвентаризации с каталогом

Вы также можете создать инвентаризацию, объединив несколько источников и типов источников в каталоге. Это может быть полезно для объединения статических и динамических хостов и управления ими как одной инвентаризацией. Следующая инвентаризация объединяет источник плагина инвентаризации, динамический скрипт инвентаризации и файл со статическими хостами:

inventory/
  openstack.yml          # configure inventory plugin to get hosts from Openstack cloud
  dynamic-inventory.py   # add additional hosts with dynamic inventory script
  static-inventory       # add static hosts and groups
  group_vars/
    all.yml              # assign variables to all hosts

Вы можете указать этот каталог инвентаризации следующим образом:

ansible-playbook example.yml -i inventory

Может быть полезно контролировать порядок слияния источников инвентаризации, если есть конфликты переменных или зависимости групп групп от других источников инвентаризации. Инвентаризации объединяются в лексикографическом порядке согласно именам файлов, поэтому результат можно контролировать, добавляя префиксы к файлам:

inventory/
  01-openstack.yml          # configure inventory plugin to get hosts from Openstack cloud
  02-dynamic-inventory.py   # add additional hosts with dynamic inventory script
  03-static-inventory       # add static hosts
  group_vars/
    all.yml                 # assign variables to all hosts

Если 01-openstack.yml определяет myvar = 1 для группы all, 02-dynamic-inventory.py определяет myvar = 2, а 03-static-inventory определяет myvar = 3, книга задач будет запущена с myvar = 3.

Дополнительную информацию о плагинах инвентаризации и динамических скриптах инвентаризации см. в разделах Плагины инвентаризации и Работа с динамической инвентаризацией.

Подключение к хостам: поведенческие параметры инвентаризации

Как описано выше, указание следующих переменных управляет тем, как Ansible взаимодействует с удалёнными хостами.

Подключение к хосту:

ansible_connection

Тип подключения к хосту. Это может быть имя любого из плагинов подключения Ansible. Типы протоколов SSH — smart, ssh или paramiko. По умолчанию — smart. Типы, не основанные на SSH, описаны в следующем разделе.

Общие для всех подключений:

ansible_host

Имя хоста для подключения, если оно отличается от псевдонима, который вы хотите ему присвоить.

ansible_port

Номер порта подключения, если он не по умолчанию (22 для ssh)

ansible_user

Имя пользователя для подключения к хосту

ansible_password

Пароль для аутентификации на хосте (никогда не храните эту переменную в открытом виде; всегда используйте vault. См. Держите зашифрованные переменные видимыми безопасно)

Специфичные для подключения SSH:

ansible_ssh_private_key_file

Файл закрытого ключа, используемый ssh. Полезно, если используются несколько ключей, и вы не хотите использовать агент SSH.

ansible_ssh_common_args

Это значение всегда добавляется в командную строку по умолчанию для sftp, scp и ssh. Полезно для настройки ProxyCommand для определенного хоста (или группы).

ansible_sftp_extra_args

Это значение всегда добавляется в командную строку sftp по умолчанию.

ansible_scp_extra_args

Это значение всегда добавляется в командную строку scp по умолчанию.

ansible_ssh_extra_args

Это значение всегда добавляется в командную строку ssh по умолчанию.

ansible_ssh_pipelining

Определяет, использовать ли SSH-каналы. Это может переопределить значение pipelining в ansible.cfg.

ansible_ssh_executable (добавлен в версии 2.2)

Это значение переопределяет стандартное поведение использования системного ssh. Это может переопределить значение ssh_executable в ansible.cfg.

Масштабирование привилегий (см. Масштабирование привилегий Ansible для получения более подробной информации):

ansible_become

Эквивалентно ansible_sudo или ansible_su, позволяет принудительно включить масштабирование привилегий

ansible_become_method

Позволяет установить метод масштабирования привилегий

ansible_become_user

Эквивалентно ansible_sudo_user или ansible_su_user, позволяет указать пользователя, к которому происходит масштабирование привилегий

ansible_become_password

Эквивалентно ansible_sudo_password или ansible_su_password, позволяет установить пароль для масштабирования привилегий (никогда не храните эту переменную в открытом виде; всегда используйте хранилище. См. Безопасное хранение зашифрованных переменных)

ansible_become_exe

Эквивалентно ansible_sudo_exe или ansible_su_exe, позволяет указать исполняемый файл для выбранного метода масштабирования

ansible_become_flags

Эквивалентно ansible_sudo_flags или ansible_su_flags, позволяет задать флаги, передаваемые выбранному методу масштабирования. Это также можно установить глобально в ansible.cfg в опции sudo_flags

Параметры среды удалённого узла:

ansible_shell_type

Тип оболочки целевой системы. Не следует использовать эту настройку, если не задан ansible_shell_executable для оболочки, несовместимой с Bourne (sh). По умолчанию команды форматируются с использованием синтаксиса sh. Установка значений csh или fish заставит команды, выполняемые на целевых системах, следовать синтаксису этой оболочки.

ansible_python_interpreter

Путь к интерпретатору Python на целевом узле. Это полезно для систем с несколькими установками Python или если он не расположен по пути /usr/bin/python, например, на системах *BSD, или если /usr/bin/python не является интерпретатором Python версии 2.X. Мы не используем механизм /usr/bin/env, так как он требует правильной настройки пути удалённого пользователя и предполагает, что исполняемый файл python имеет имя python, в то время как фактический исполняемый файл может называться, например, python2.6.

ansible_*_interpreter

Подходит для языков, таких как Ruby или Perl, и работает аналогично ansible_python_interpreter. Заменяет shebang модулей, которые будут выполняться на этом узле.

ansible_shell_executable

Устанавливает оболочку, которую контроллер Ansible будет использовать на целевой машине, переопределяет executable в ansible.cfg, по умолчанию /bin/sh. Изменять следует только в случае, если невозможно использовать /bin/sh (например, если /bin/sh не установлен на целевой машине или не может быть запущен с помощью sudo).

Примеры из файла конфигурации Ansible-INI:

some_host         ansible_port=2222     ansible_user=manager
aws_host          ansible_ssh_private_key_file=/home/example/.ssh/aws.pem
freebsd_host      ansible_python_interpreter=/usr/local/bin/python
ruby_module_host  ansible_ruby_interpreter=/usr/bin/ruby.1.9.3

Типы соединений, не использующие SSH

Как уже упоминалось в предыдущем разделе, Ansible выполняет playbook через SSH, но не ограничивается этим типом соединения. С помощью параметра ansible_connection=<connector> для конкретного узла можно изменить тип соединения. Доступны следующие типы соединений, не использующие SSH:

local

Этот соединитель может использоваться для развертывания playbook на самом контроллере.

docker

Этот соединитель развертывает playbook непосредственно в контейнеры Docker, используя локальный клиент Docker. Обрабатываются следующие параметры:

ansible_host

Имя контейнера Docker для подключения.

ansible_user

Имя пользователя для работы внутри контейнера. Пользователь должен существовать внутри контейнера.

ansible_become

Если установлено значение true, то будет использоваться become_user для работы внутри контейнера.

ansible_docker_extra_args

Может быть строкой с любыми дополнительными аргументами, понимаемыми Docker, которые не являются специфичными для команды. Этот параметр в основном используется для конфигурации удалённого демона Docker.

Вот пример мгновенного развертывания в созданных контейнерах:

- name: Create a jenkins container
  community.general.docker_container:
    docker_host: myserver.net:4243
    name: my_jenkins
    image: jenkins

- name: Add the container to inventory
  ansible.builtin.add_host:
    name: my_jenkins
    ansible_connection: docker
    ansible_docker_extra_args: "--tlsverify --tlscacert=/path/to/ca.pem --tlscert=/path/to/client-cert.pem --tlskey=/path/to/client-key.pem -H=tcp://myserver.net:4243"
    ansible_user: jenkins
  changed_when: false

- name: Create a directory for ssh keys
  delegate_to: my_jenkins
  ansible.builtin.file:
    path: "/var/jenkins_home/.ssh/jupiter"
    state: directory

Полный список доступных плагинов и примеры можно найти в Списке плагинов.

Примеры настройки инвентаризации

См. также Пример настройки Ansible, в котором представлены инвентаризация вместе с playbooks и другими элементами Ansible.

Пример: Одна инвентаризация на среду

Если вам нужно управлять несколькими средами, иногда целесообразно определять только узлы одной среды в одной инвентаризации. Таким образом, например, сложнее случайно изменить состояние узлов в среде «test», когда вы на самом деле хотели обновить некоторые серверы в среде «staging».

Для вышеупомянутого примера можно создать файл inventory_test.

[dbservers]
db01.test.example.com
db02.test.example.com

[appservers]
app01.test.example.com
app02.test.example.com
app03.test.example.com

Этот файл содержит только узлы, являющиеся частью среды «test». Определите машины «staging» в другом файле с именем inventory_staging.

[dbservers]
db01.staging.example.com
db02.staging.example.com

[appservers]
app01.staging.example.com
app02.staging.example.com
app03.staging.example.com

Чтобы применить playbook с именем site.yml ко всем серверам приложения в тестовой среде, используйте следующую команду:

ansible-playbook -i inventory_test -l appservers site.yml

Пример: Группировка по функциям

В предыдущем разделе вы уже видели пример использования групп для объединения узлов, выполняющих одинаковые функции. Это позволяет, например, определять правила брандмауэра в playbook или роли, затрагивающие только серверы базы данных.

- hosts: dbservers
  tasks:
  - name: Allow access from 10.0.0.1
    ansible.builtin.iptables:
      chain: INPUT
      jump: ACCEPT
      source: 10.0.0.1

Пример: Группировка по местоположению

Другие задачи могут быть сосредоточены на местоположении узла. Например, db01.test.example.com и app01.test.example.com находятся в ЦОД1, а db02.test.example.com — в ЦОД2.

[dc1]
db01.test.example.com
app01.test.example.com

[dc2]
db02.test.example.com

На практике вы можете даже смешивать все эти подходы, так как вам может потребоваться в один день обновить все узлы в конкретном дата-центре, а в другой день — все серверы приложений независимо от их местоположения.