Управление хостами z/OS UNIX с помощью Ansible

Ansible и z/OS UNIX System Services

UNIX System Services может поддерживать необходимые зависимости для управляемого узла Ansible, включая запуск Python и создание интерактивных процессов оболочки через SSH-подключения. Ansible может выполнять операции на узлах UNIX System Services, изменяя файлы, каталоги и т. д. с помощью модулей ansible.builtin. Кроме того, любые действия, которые можно выполнить, вводя команды в оболочке UNIX System Services, можно включить в плейбук Ansible и автоматизировать.

Среда z/OS

Большинство систем обрабатывают файлы в одном из двух режимов — двоичном или текстовом с кодировкой UTF-8, — однако IBM z/OS, включая UNIX System Services, поддерживает дополнительный, третий режим — текст с кодировкой EBCDIC. Ansible умеет обрабатывать двоичные данные и текстовые данные в кодировке UTF-8, но не данные в кодировке EBCDIC. Это не обязательно является ограничением: просто требуется добавить задачи для преобразования файлов из исходной кодировки и обратно. Пользователь Ansible, управляющий узлами z/OS UNIX, должен понимать, с какими файлами работает его автоматизация.

Тип файла (двоичный или текстовый) и его кодировку можно хранить в «тегах» файла. Теги файлов — это концепция z/OS UNIX System Services (часть Enhanced ASCII), предназначенная для различения двоичных файлов, текстовых файлов в кодировке UTF-8 и текстовых файлов в кодировке EBCDIC.

Поведение по умолчанию для файла или потока без тегов определяется программой. Например, IBM Open Enterprise SDK for Python по умолчанию использует кодировку UTF-8.

Модули Ansible не считывают и не распознают теги файлов. Пользователь должен определить тип удалённых данных и правильно назначить им теги. Данные, передаваемые на удалённые хосты z/OS UNIX через Ansible, по умолчанию кодируются в UTF-8 и не получают тегов. Назначить тег файлу можно с помощью дополнительной задачи, использующей модуль ansible.builtin.command.

- name: Tag my_file.txt as UTF-8.
  ansible.builtin.command: chtag -tc iso8859-1 my_file.txt

Оболочка z/OS, доступная в z/OS UNIX System Services, по умолчанию использует кодировку EBCDIC для потоков данных без тегов. Ansible отправляет в оболочку z/OS текстовые данные без тегов в кодировке UTF-8, тогда как оболочка ожидает, что данные без тегов закодированы в EBCDIC. Это несоответствие кодировок можно устранить, задав переменную среды PYTHONSTDINENCODING: в результате канал, используемый Python, будет помечен указанной кодировкой. Для тегов файлов и каналов можно настроить автоматическое преобразование между ASCII и EBCDIC, однако ими пользуются только программы z/OS UNIX, поддерживающие теги.

Использование модулей ansible.builtin в z/OS UNIX

Модули ansible.builtin исходят из предположения, что все текстовые данные (файлы и каналы/потоки) закодированы в UTF-8. В z/OS текстовые данные (файлы или потоки) могут быть закодированы как в EBCDIC, так и в UTF-8, поэтому необходимо тщательно определять правильную кодировку целевых данных.

Ниже приведены некоторые примечания и полезные советы по использованию модулей ansible.builtin в z/OS UNIX. Это далеко не исчерпывающий список. Прежде чем использовать модули Ansible, необходимо сначала настроить удалённую среду.

• ansible.builtin.command / ansible.builtin.shell

  Модули command и shell отлично подходят для автоматизации задач, для которых уже существуют решения в командной строке. При использовании этих модулей следует учитывать, что в зависимости от конфигурации системы оболочка z/OS (/bin/sh) может возвращать вывод в EBCDIC. Параметры переменных среды LE правильно преобразуют помеченные потоки и возвращают Ansible читаемый вывод. Однако некоторые программы командной строки могут возвращать вывод в UTF-8 без тега канала. В этом случае автоматическое преобразование может ошибочно предположить, что вывод имеет кодировку EBCDIC, попытаться преобразовать его и выдать нечитаемые данные. Если исходная кодировка известна, можно использовать возможность модуля ansible.builtin.shell объединять команды в цепочки с помощью каналов и передавать вывод в iconv. В этом примере может понадобиться выбрать другие кодировки для параметров «to» и «from», соответствующие кодировкам ваших файлов.

  ansible.builtin.shell: "some_pgm | iconv -f ibm-1047 -t iso8859-1"
  

• ansible.builtin.raw

  По замыслу модуль raw игнорирует все настройки удалённой среды. Однако для управляемых узлов z/OS UNIX System Services требуется настроить базовые параметры. Чтобы использовать этот модуль с UNIX System Services, задайте минимальный набор переменных среды в виде последовательности инструкций export перед нужной командой.

  ansible.builtin.raw: |
      export _BPXK_AUTOCVT: "ON" ;
      export _CEE_RUNOPTS: "FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)" ;
      export _TAG_REDIR_ERR: "txt" ;
      export _TAG_REDIR_IN: "txt" ;
      export _TAG_REDIR_OUT: "txt" ;
      echo "hello world!"
  

  В качестве альтернативы можно использовать упомянутые выше модули ansible.builtin.command или ansible.builtin.shell, которые настраивают заданную удалённую среду для каждой задачи.

• ansible.builtin.copy / ansible.builtin.fetch

  Модули ansible.builtin НЕ назначают теги файлам автоматически, а существующие теги файлов не учитываются и не сохраняются. При выполнении операций copy/fetch можно обрабатывать файлы как двоичные — целостность данных при этом не нарушается. Однако не забудьте восстановить тег файла после его возврата в z/OS UNIX, поскольку теги не сохраняются. Для назначения тега файлу используйте модуль command:

  - name: Tag my_file.txt as UTF-8.
    ansible.builtin.command: chtag -tc iso8859-1 my_file.txt
  

• ansible.builtin.blockinfile / ansible.builtin.lineinfile

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

• ansible.builtin.script

  Встроенный модуль script копирует локальный файл скрипта во временный файл на удалённом целевом узле и запускает его. На целевых узлах z/OS UNIX System Services возникает проблема: когда используемая оболочка z/OS пытается прочитать файл скрипта, она считает его закодированным в EBCDIC, поскольку файл не получает тег текстового файла UTF-8, и не может правильно прочитать или запустить скрипт. Один из обходных вариантов — вручную копировать локальные файлы на управляемые узлы (ansible.builtin.copy ) и преобразовывать файлы или назначать им теги (с помощью модуля ansible.builtin.command). При таком обходном решении теряются некоторые удобства модуля script, например автоматическое удаление файла скрипта после запуска. Однако эти шаги легко выполнить в дополнительных задачах плейбука.

  - name: Copy local script file to remote node.
    ansible.builtin.copy:
      src: "{{ playbook_dir }}/local/scripts/sample.sh"
      dest: /u/ibmuser/scripts/
  
  - name: Tag remote script file.
    ansible.builtin.command: "chtag -tc ISO8859-1 /u/ibmuser/scripts/sample.sh"
  
  - name: Run script.
    ansible.builtin.command: "/u/ibmuser/scripts/sample.sh"
  

  Ещё один обходной вариант — хранить локальные файлы скриптов в кодировке EBCDIC. На управляющем узле Ansible они могут быть нечитаемыми, но будут корректно скопированы на целевые узлы z/OS UNIX System Services в кодировке EBCDIC, и скрипт запустится. Этот подход позволяет использовать встроенные возможности модуля script, но управление локальными нечитаемыми файлами EBCDIC затрудняет их сопровождение.

Настройка удалённой среды

Некоторые параметры Language Environment (LE) обеспечивают автоматическое преобразование кодировок и автоматическое назначение тегов файлам, необходимые Python в системах z/OS UNIX (IBM Open Enterprise SDK for Python ).

При настройке удалённой среды для любых управляемых узлов z/OS UNIX укажите следующие параметры:

_BPXK_AUTOCVT: "ON"
_CEE_RUNOPTS: "FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)"

_TAG_REDIR_ERR: "txt"
_TAG_REDIR_IN: "txt"
_TAG_REDIR_OUT: "txt"

Удалённую среду Ansible можно настроить с помощью переменных среды в следующих местах:

• инвентаризация — inventory.yml, group_vars/all.yml или host_vars/all.yml
• плейбук — переменная environment в начале плейбука.
• блок или задача — ключевое слово environment.

Подробнее см. в разделе Настройка удалённой среды.

Настройка удалённого интерпретатора Python

Для выполнения большинства модулей на удалённом хосте Ansible требуется интерпретатор Python. Ansible проверяет наличие Python по «умолчанию» в пути /usr/bin/python.

В z/OS UNIX интерпретатор Python3 (из IBM Open Enterprise SDK for Python) часто установлен по другому пути, обычно похожему на: /usr/lpp/cyp/v3r12/pyz.

Путь к интерпретатору Python можно задать с помощью переменной инвентаризации Ansible ansible_python_interpreter. Например:

zos1 ansible_python_interpreter:/usr/lpp/cyp/v3r12/pyz

Если интерпретатор Python не найден в расположении по умолчанию на целевом хосте, может появиться ошибка со следующим сообщением: /usr/bin/python: FSUM7351 not found

Подробнее см. в разделе: Что делать, если на удалённом компьютере нет интерпретатора Python по пути /usr/bin/python?.

Настройка удалённой оболочки

Управляемый узел z/OS UNIX System Services включает несколько оболочек. В настоящее время поддерживается только оболочка z/OS, расположенная по пути /bin/sh. Чтобы настроить оболочку, которую управляющий узел Ansible использует на целевом узле, задайте переменную инвентаризации ansible_shell_executable. Например:

zos1 ansible_shell_executable=/bin/sh

Включение конвейерной обработки Ansible

Включите ANSIBLE_PIPELINING в файле ansible.cfg.

При включённой конвейерной обработке Ansible передаёт код любого модуля удалённому целевому узлу через канал stdin Python и запускает его за один вызов, вместо того чтобы сначала копировать данные во временные файлы, а затем считывать их из этих файлов. Подробнее о конвейерной обработке см. в разделе: Конвейерная обработка.

Рекомендуется включить это поведение, поскольку Python помечает свои каналы соответствующей кодировкой, что снижает вероятность ошибок кодирования. Кроме того, использование каналов stdin Python эффективнее, чем операции ввода-вывода с файлами.

Добавьте следующие настройки в среду для любых задач, выполняемых на управляемых узлах z/OS UNIX.

PYTHONSTDINENCODING: "cp1047"

Если конвейерная обработка Ansible включена, но свойство PYTHONSTDINENCODING настроено неправильно, может возникнуть следующая ошибка. Обратите внимание: шестнадцатеричное значение '\x81' ниже может различаться в зависимости от источника ошибки:

SyntaxError: Non-UTF-8 code starting with '\\x81' in file <stdin> on line 1, but no encoding declared; see https://peps.python.org/pep-0263/ for details

Нечитаемые символы

Нечитаемые символы в выводе плейбука чаще всего возникают из-за несоответствия кодировок EBCDIC. Ещё раз проверьте правильность настройки удалённой среды. Также проверьте ожидаемые кодировки файлов как на удалённом узле, так и на управляющем узле. Модули ansible.builtin предполагают, что все текстовые данные закодированы в UTF-8, тогда как в z/OS UNIX может использоваться EBCDIC. Во многих системах z/OS UNIX кодировка по умолчанию для файлов без тегов — EBCDIC. Такое различие в настройках по умолчанию легко приводит к неправильной интерпретации данных: преобразование EBCDIC в UTF-8 может не выполниться автоматически либо преобразование данных, уже закодированных в UTF-8, может быть запущено ошибочно.

Использование z/OS в качестве управляющего узла

В настоящее время операционную систему z/OS нельзя настроить для работы в качестве управляющего узла Ansible. Интерфейс z/OS UNIX System Services также нельзя настроить для работы в качестве управляющего узла Ansible, несмотря на соответствие стандарту POSIX.

На платформе IBM Z доступны следующие варианты использования системы в качестве управляющего узла:

• IBM z/OS Container Extensions (zCX)
• Red Hat OpenShift on IBM zSystems and LinuxONE
• Linux on IBM Z