Развертывание и управление файлами в RHEL с помощью Ansible

Введение

В этой лабораторной работе вы освоите основные навыки развертывания и управления файлами в системе Red Hat Enterprise Linux (RHEL) с использованием Ansible. Вы получите практический опыт работы с наиболее распространенными и мощными модулями Ansible, предназначенными для файловых операций, начиная от простого развертывания файлов и заканчивая более сложными манипуляциями с содержимым и управлением состоянием.

Вы начнете с использования модуля ansible.builtin.copy для передачи статического файла и установки его атрибутов. Далее вы модифицируете содержимое файлов с помощью lineinfile и blockinfile, а также сгенерируете пользовательское сообщение дня (MOTD) с помощью модуля ansible.builtin.template. Лабораторная работа также охватывает создание символических ссылок, проверку состояний файлов с помощью stat, получение логов с помощью fetch и очистку управляемых файлов, предоставляя всесторонний обзор возможностей Ansible по управлению файлами.

Копирование статического файла и установка атрибутов с помощью модуля `ansible.builtin.copy`

На этом шаге вы научитесь использовать один из наиболее фундаментальных модулей Ansible: ansible.builtin.copy. Этот модуль используется для передачи файлов с вашего управляющего узла (виртуальной машины LabEx) в указанное место на управляемых хостах. В нашем случае управляемым хостом будет сам localhost. Помимо простого копирования, модуль copy позволяет точно контролировать атрибуты файла, такие как владелец, группа и права доступа, что крайне важно для правильной настройки системы.

Сначала настроим среду нашего проекта. Вся наша работа будет проводиться в каталоге ~/project.

Перейдите в каталог проекта и создайте подкаталог для наших исходных файлов. Это распространенная практика для поддержания порядка в проекте.

Установите пакет ansible-core.
```
sudo dnf install -y ansible-core
```
Затем перейдите в каталог проекта и создайте подкаталог для наших исходных файлов.
```
cd ~/project
mkdir files
```
Далее создайте простой текстовый файл, который мы будем копировать. Мы используем команду cat с "here document" для создания файла info.txt в каталоге files.
```
cat << EOF > ~/project/files/info.txt
This file was deployed by Ansible.
It contains important system information.
EOF
```
Теперь создайте файл инвентаря Ansible. Инвентарь сообщает Ansible, какие хосты необходимо управлять. Для этой лабораторной работы мы будем управлять локальной машиной. Создайте файл с именем inventory.ini.
```
cat << EOF > ~/project/inventory.ini
localhost ansible_connection=local
EOF
```
В этом инвентаре localhost — это хост, на который мы нацелены. Переменная ansible_connection=local указывает Ansible выполнять задачи непосредственно на управляющем узле, без использования SSH.
Создайте свой первый плейбук Ansible. Этот плейбук будет содержать инструкции по копированию файла. Используйте nano или cat для создания файла с именем copy_file.yml.
```
nano ~/project/copy_file.yml
```
Добавьте следующее содержимое в файл. Этот плейбук определяет одну задачу: скопировать info.txt в каталог /tmp/ и установить его атрибуты.
```
---
- name: Deploy a static file to localhost
  hosts: localhost
  tasks:
    - name: Copy info.txt and set attributes
      ansible.builtin.copy:
        src: files/info.txt
        dest: /tmp/info.txt
        owner: labex
        group: labex
        mode: "0640"
```
Давайте разберем параметры в задаче copy:
- src: files/info.txt: Путь к исходному файлу на управляющем узле, относительно расположения плейбука.
- dest: /tmp/info.txt: Абсолютный путь, по которому файл будет размещен на управляемом хосте.
- owner: labex: Устанавливает владельцем файла пользователя labex.
- group: labex: Устанавливает группой файла группу labex.
- mode: '0640': Устанавливает права доступа к файлу. 0640 означает, что владелец может читать/писать, группа может читать, а остальные не имеют разрешений.

Выполните плейбук с помощью команды ansible-playbook. Флаг -i указывает наш файл инвентаря.

ansible-playbook -i inventory.ini copy_file.yml

Вы должны увидеть вывод, указывающий на успешное выполнение плейбука, примерно следующий:

PLAY [Deploy a static file to localhost] ***************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Copy info.txt and set attributes] ****************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Наконец, проверьте, что файл был скопирован правильно и имеет нужные атрибуты. Используйте команду ls -l для проверки прав доступа, владельца и группы.
```
ls -l /tmp/info.txt
```
Вывод должен показать, что labex является владельцем и группой, а права доступа установлены как -rw-r-----.
```
-rw-r----- 1 labex labex 72 Jul 10 14:30 /tmp/info.txt
```
Вы также можете просмотреть содержимое файла, чтобы убедиться, что он был скопирован полностью.
```
cat /tmp/info.txt
```
```
This file was deployed by Ansible.
It contains important system information.
```

Вы успешно использовали модуль ansible.builtin.copy для развертывания файла и настройки его атрибутов в вашей локальной системе.

Изменение содержимого файла с помощью `lineinfile` и `blockinfile`

На этом шаге вы научитесь изменять существующие файлы на управляемом хосте, не заменяя файл целиком. Ansible предоставляет мощные модули для этой цели: ansible.builtin.lineinfile для управления отдельными строками и ansible.builtin.blockinfile для управления многострочными блоками текста. Они чрезвычайно полезны для таких задач, как изменение настроек конфигурации или добавление записей в файлы журналов.

Мы продолжим работать с файлом info.txt, который вы создали на предыдущем шаге и который находится по пути /tmp/info.txt.

Сначала убедитесь, что вы находитесь в каталоге проекта.
```
cd ~/project
```
Создайте новый плейбук с именем modify_file.yml. Этот плейбук будет содержать две задачи: одну для добавления одной строки и другую для добавления блока текста в наш существующий файл.
```
nano ~/project/modify_file.yml
```
Добавьте следующее содержимое в ваш плейбук modify_file.yml. Этот плейбук нацелен на localhost и использует lineinfile и blockinfile для добавления содержимого в /tmp/info.txt.
```
---
- name: Modify an existing file
  hosts: localhost
  tasks:
    - name: Add a single line of text to a file
      ansible.builtin.lineinfile:
        path: /tmp/info.txt
        line: This line was added by the lineinfile module.
        state: present

    - name: Add a block of text to an existing file
      ansible.builtin.blockinfile:
        path: /tmp/info.txt
        block: |
          ## BEGIN ANSIBLE MANAGED BLOCK
          This block of text consists of two lines.
          They have been added by the blockinfile module.
          ## END ANSIBLE MANAGED BLOCK
        state: present
```
Давайте рассмотрим используемые модули:
- ansible.builtin.lineinfile: Этот модуль гарантирует наличие определенной строки в файле. Если строка уже существует, Ansible ничего не делает, что делает задачу идемпотентной.
  - path: Файл для изменения.
  - line: Строка текста, которая должна присутствовать в файле.
  - state: present: Гарантирует наличие строки. Вы можете использовать state: absent для ее удаления.
- ansible.builtin.blockinfile: Этот модуль управляет блоком текста, окруженным маркерами строк (например, ## BEGIN ANSIBLE MANAGED BLOCK). Это идеально подходит для управления разделами конфигурации.
  - path: Файл для изменения.
  - block: Многострочная строка для вставки. | — это синтаксис YAML для литерального блока, сохраняющий переносы строк.
  - state: present: Гарантирует наличие блока.

Выполните плейбук с помощью команды ansible-playbook и вашего файла inventory.ini.

ansible-playbook -i inventory.ini modify_file.yml

Вывод покажет, что обе задачи внесли изменения в файл.

PLAY [Modify an existing file] *************************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Add a single line of text to a file] *************************************
changed: [localhost]

TASK [Add a block of text to an existing file] *********************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Наконец, проверьте изменения, просмотрев содержимое /tmp/info.txt.
```
cat /tmp/info.txt
```
Вы должны увидеть исходное содержимое, за которым следует новая строка и новый блок текста.
```
This file was deployed by Ansible.
It contains important system information.
This line was added by the lineinfile module.
## BEGIN ANSIBLE MANAGED BLOCK
This block of text consists of two lines.
They have been added by the blockinfile module.
## END ANSIBLE MANAGED BLOCK
```
Если вы запустите плейбук снова, Ansible сообщит ok=3 и changed=0, потому что содержимое уже присутствует, демонстрируя идемпотентность этих модулей.

Генерация пользовательского MOTD с помощью модуля `ansible.builtin.template`

На этом шаге вы перейдете от копирования статических файлов к генерации динамических файлов с использованием модуля ansible.builtin.template. Этот модуль использует движок шаблонов Jinja2 для создания файлов, настроенных с помощью переменных и системной информации, известной как "факты" (facts), которые Ansible собирает с ваших управляемых хостов. Мы создадим динамическое сообщение дня (MOTD), которое будет отображать специфичную для системы информацию.

Сначала убедитесь, что вы находитесь в каталоге ~/project, и создайте выделенный подкаталог для ваших шаблонов. Стандартной лучшей практикой Ansible является хранение шаблонов Jinja2 в каталоге templates.
```
cd ~/project
mkdir templates
```
Далее создайте файл шаблона Jinja2. Этот файл, motd.j2, будет содержать структуру нашего MOTD с заполнителями для динамических данных. Расширение .j2 является распространенным соглашением для шаблонов Jinja2.
```
nano ~/project/templates/motd.j2
```
Добавьте следующее содержимое в файл. Обратите внимание на синтаксис {{ ... }}, который обозначает заполнитель для переменной или факта.
```
#################################################################
##          Welcome to {{ ansible_facts['fqdn'] }}
#
## This is a {{ ansible_facts['distribution'] }} system.
## System managed by Ansible.
#
## For support, contact: {{ admin_email }}
#################################################################
```
В этом шаблоне:
- {{ ansible_facts['fqdn'] }} будет заменено полным доменным именем хоста (Fully Qualified Domain Name).
- {{ ansible_facts['distribution'] }} будет заменено названием дистрибутива Linux (например, RedHat).
- {{ admin_email }} — это пользовательская переменная, которую мы определим в нашем плейбуке.
Теперь создайте новый плейбук с именем template_motd.yml. Этот плейбук будет использовать шаблон для генерации файла /etc/motd.
```
nano ~/project/template_motd.yml
```
Добавьте следующее содержимое. Этот плейбук требует повышенных привилегий (become: true) для записи в каталог /etc. Он также определяет пользовательскую переменную admin_email.
```
---
- name: Deploy a custom MOTD from a template
  hosts: localhost
  become: true
  vars:
    admin_email: admin@labex.io
  tasks:
    - name: Generate /etc/motd from template
      ansible.builtin.template:
        src: templates/motd.j2
        dest: /etc/motd
        owner: root
        group: root
        mode: "0644"
```
Ключевые параметры в этом плейбуке:
- become: true: Это указывает Ansible использовать sudo для выполнения задачи, что необходимо для записи в /etc/motd.
- vars: В этом разделе мы определяем пользовательские переменные, такие как admin_email.
- ansible.builtin.template: Модуль, который обрабатывает шаблон Jinja2. src указывает на наш файл .j2, а dest — это целевой файл на управляемом хосте.

Выполните плейбук.

ansible-playbook -i inventory.ini template_motd.yml

Вывод должен подтвердить успешное выполнение задачи.

PLAY [Deploy a custom MOTD from a template] ************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Generate /etc/motd from template] ****************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Проверьте результат. Проверьте содержимое вновь сгенерированного файла /etc/motd.
```
cat /etc/motd
```
Вы увидите отрендеренный вывод с замененными плейсхолдерами Jinja2 фактическими системными фактами и пользовательской переменной, которую вы определили. fqdn будет соответствовать имени хоста вашей лабораторной среды.
```
#################################################################
##          Welcome to host.labex.io
#
## This is a RedHat system.
## System managed by Ansible.
#
## For support, contact: admin@labex.io
#################################################################
```

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

Развертывание вспомогательных файлов и создание символической ссылки с помощью `copy` и `file`

На этом шаге вы объедините свои знания модуля copy с новым, универсальным модулем: ansible.builtin.file. В то время как copy используется для передачи содержимого, file используется для управления состоянием файлов, каталогов и символических ссылок на управляемом хосте. Вы будете использовать его для создания каталогов, установки разрешений и, что наиболее важно для этого упражнения, создания символических ссылок.

Наш сценарий заключается в настройке сообщений перед входом в систему, отображаемых системой. Во многих системах Linux /etc/issue отображается локальным пользователям терминала, а /etc/issue.net отображается удаленным пользователям (например, через SSH). Мы развернем один файл issue, а затем создадим символическую ссылку, чтобы /etc/issue.net указывал на /etc/issue, гарантируя, что они всегда будут отображать одно и то же сообщение.

Сначала убедитесь, что вы находитесь в каталоге ~/project, и создайте исходный файл для нашего сообщения issue. Мы поместим этот файл в подкаталог files, который вы создали ранее.
```
cd ~/project
cat << EOF > ~/project/files/issue
Authorized access only.
All connections are logged and monitored.
EOF
```
Создайте новый плейбук с именем deploy_issue.yml. Этот плейбук будет содержать две задачи: одну для копирования файла issue и другую для создания символической ссылки.
```
nano ~/project/deploy_issue.yml
```
Добавьте следующее содержимое в ваш плейбук deploy_issue.yml. Этот плейбук требует повышенных привилегий (become: true) для управления файлами в каталоге /etc/.
```
---
- name: Configure system issue files
  hosts: localhost
  become: true
  tasks:
    - name: Copy custom /etc/issue file
      ansible.builtin.copy:
        src: files/issue
        dest: /etc/issue
        owner: root
        group: root
        mode: "0644"

    - name: Ensure /etc/issue.net is a symlink to /etc/issue
      ansible.builtin.file:
        src: /etc/issue
        dest: /etc/issue.net
        state: link
        force: yes
```
Давайте проанализируем новую задачу ansible.builtin.file:
- src: /etc/issue: Когда state установлен в link, src указывает файл, на который должна указывать символическая ссылка.
- dest: /etc/issue.net: Это путь, по которому будет создана сама символическая ссылка.
- state: link: Этот важный параметр указывает модулю file создать символическую ссылку, а не обычный файл или каталог.
- force: yes: Это полезная опция, которая обеспечивает идемпотентность. Если /etc/issue.net уже существует как обычный файл, Ansible удалит его и создаст ссылку. Без force: yes плейбук завершится ошибкой в такой ситуации.

Выполните плейбук.

ansible-playbook -i inventory.ini deploy_issue.yml

Вывод покажет, что обе задачи успешно внесли изменения.

PLAY [Configure system issue files] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Copy custom /etc/issue file] *********************************************
changed: [localhost]

TASK [Ensure /etc/issue.net is a symlink to /etc/issue] ************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Проверьте результат с помощью команды ls -l. Эта команда предоставляет подробный список, который четко показывает символические ссылки.
```
ls -l /etc/issue /etc/issue.net
```
Вывод должен показать, что /etc/issue является обычным файлом, а /etc/issue.net — символической ссылкой, указывающей на него. Буква l в начале разрешений для /etc/issue.net указывает, что это ссылка.
```
-rw-r--r--. 1 root root 65 Jul 10 15:00 /etc/issue
lrwxrwxrwx. 1 root root 10 Jul 10 15:00 /etc/issue.net -> /etc/issue
```

Теперь вы успешно развернули файл конфигурации и использовали модуль ansible.builtin.file для создания символической ссылки, что является распространенным и мощным шаблоном для управления конфигурациями системы.

Проверка состояния файла с помощью `stat` и получение логов с помощью `fetch`

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

Мы создадим плейбук, который сначала проверит существование файла /etc/motd, созданного ранее, а затем получит файл журнала пакетного менеджера DNF (/var/log/dnf.log) в локальный каталог на вашей виртуальной машине LabEx.

Сначала убедитесь, что вы находитесь в каталоге ~/project, и создайте новый подкаталог для хранения файлов, которые вы будете получать.
```
cd ~/project
mkdir fetched_logs
```
Создайте новый плейбук с именем check_and_fetch.yml. Этот плейбук будет содержать задачи для проверки файла и получения лога.
```
nano ~/project/check_and_fetch.yml
```
Добавьте следующее содержимое в ваш плейбук check_and_fetch.yml. Этот плейбук использует stat для получения сведений о файле, register для сохранения этих сведений в переменной, debug для отображения переменной и fetch для получения лог-файла.
```
---
- name: Check file status and fetch logs
  hosts: localhost
  become: true
  tasks:
    - name: Check if /etc/motd exists
      ansible.builtin.stat:
        path: /etc/motd
      register: motd_status

    - name: Display stat results
      ansible.builtin.debug:
        var: motd_status.stat

    - name: Fetch the dnf log file from managed host
      ansible.builtin.fetch:
        src: /var/log/dnf.log
        dest: fetched_logs/
        flat: yes
```
Давайте разберем ключевые концепции:
- register: motd_status: Это важная функция Ansible. Она берет весь вывод задачи и сохраняет его в новой переменной с именем motd_status.
- ansible.builtin.debug: Этот модуль используется для вывода значений во время выполнения плейбука. Здесь мы выводим объект stat из нашей зарегистрированной переменной (motd_status.stat), чтобы увидеть свойства файла.
- ansible.builtin.fetch: Этот модуль извлекает файл с управляемого хоста.
  - src: Путь к файлу, который нужно получить с управляемого хоста.
  - dest: Каталог на управляющем узле (вашей виртуальной машине LabEx), куда будет сохранен файл.
  - flat: yes: По умолчанию fetch создает структуру подкаталогов, соответствующую хосту и пути источника. flat: yes упрощает это, копируя файл непосредственно в каталог dest без дополнительных подкаталогов.

Выполните плейбук. Поскольку мы читаем системный лог-файл, используется become: true для получения необходимых разрешений.

ansible-playbook -i inventory.ini check_and_fetch.yml

Вывод покажет результаты проверки stat в задаче отладки, за которыми последует задача fetch.

PLAY [Check file status and fetch logs] ****************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Check if /etc/motd exists] ***********************************************
ok: [localhost]

TASK [Display stat results] ****************************************************
ok: [localhost] => {
    "motd_status.stat": {
        "exists": true,
        "gid": 0,
        "isreg": true,
        "mode": "0644",
        "path": "/etc/motd",
        ...
    }
}

TASK [Fetch the dnf log file from managed host] ********************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=4    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Проверьте, был ли лог-файл успешно получен. Выведите содержимое каталога fetched_logs.
```
ls -l ~/project/fetched_logs/
```
Вы должны увидеть файл dnf.log, который теперь хранится локально на вашем управляющем узле.
```
total 4
-rw-r--r--. 1 labex labex 1234 Jul 10 15:30 dnf.log
```

Теперь вы узнали, как проверять свойства файлов без внесения изменений и как извлекать важные файлы с ваших управляемых систем обратно на ваш управляющий узел.

Очистка управляемых файлов на хосте с помощью модуля `file`

На последнем этапе вы узнаете, как использовать модуль ansible.builtin.file для обеспечения отсутствия файлов и каталогов в системе. Важной частью управления конфигурацией является не только создание и изменение ресурсов, но и их последующая очистка. Установив параметр state в значение absent, вы можете указать Ansible удалить файлы, символические ссылки или даже целые каталоги.

В завершение этой лабораторной работы мы напишем один плейбук "очистки", который удалит все артефакты, созданные нами на предыдущих шагах: /tmp/info.txt, /etc/motd, /etc/issue и символическую ссылку /etc/issue.net.

Сначала убедитесь, что вы находитесь в каталоге ~/project.
```
cd ~/project
```
Создайте новый плейбук с именем cleanup.yml. Этот плейбук будет содержать все задачи, необходимые для отмены наших изменений.
```
nano ~/project/cleanup.yml
```
Добавьте следующее содержимое в ваш плейбук cleanup.yml. Этот плейбук использует список задач, каждая из которых нацелена на один из созданных нами файлов. Обратите внимание, что become: true установлен на уровне плейбука, поэтому все задачи будут выполняться с повышенными привилегиями.
```
---
- name: Clean up managed files from the system
  hosts: localhost
  become: true
  tasks:
    - name: Remove the temporary info file
      ansible.builtin.file:
        path: /tmp/info.txt
        state: absent

    - name: Remove the custom MOTD file
      ansible.builtin.file:
        path: /etc/motd
        state: absent

    - name: Remove the custom issue file
      ansible.builtin.file:
        path: /etc/issue
        state: absent

    - name: Remove the issue.net symbolic link
      ansible.builtin.file:
        path: /etc/issue.net
        state: absent
```
Ключевым моментом этого плейбука является параметр state: absent в каждой задаче. Он указывает модулю file убедиться, что элемент по указанному path отсутствует. Если файл найден, он будет удален. Если файла уже нет, ничего не произойдет, сохраняя идемпотентность.

Выполните плейбук очистки.

ansible-playbook -i inventory.ini cleanup.yml

Вывод покажет, что каждая задача успешно внесла изменение, удалив файл.

PLAY [Clean up managed files from the system] **********************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Remove the temporary info file] ******************************************
changed: [localhost]

TASK [Remove the custom MOTD file] *********************************************
changed: [localhost]

TASK [Remove the custom issue file] ********************************************
changed: [localhost]

TASK [Remove the issue.net symbolic link] **************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=5    changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Проверьте, были ли файлы удалены. Вы можете использовать команду ls для проверки их наличия. Команда сообщит, что не может получить к ним доступ, потому что они отсутствуют.
```
ls /tmp/info.txt /etc/motd /etc/issue /etc/issue.net
```
Ожидаемый вывод — серия ошибок, подтверждающих успешность очистки.
```
ls: cannot access '/tmp/info.txt': No such file or directory
ls: cannot access '/etc/motd': No such file or directory
ls: cannot access '/etc/issue': No such file or directory
ls: cannot access '/etc/issue.net': No such file or directory
```

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

Резюме

В этой лабораторной работе вы изучили основы управления файлами в системах RHEL с использованием Ansible. Вы начали с использования модуля ansible.builtin.copy для передачи статического файла на управляемый хост, одновременно устанавливая определенное владение и права доступа. Затем вы изучили, как изменять существующие файлы, гарантируя наличие определенной строки с помощью lineinfile и управляя многострочными блоками текста с помощью blockinfile. Ключевым навыком, который вы освоили, было создание динамического содержимого файлов с использованием модуля ansible.builtin.template и синтаксиса Jinja2 для создания настраиваемого сообщения дня (MOTD), заполненного системными фактами.

Кроме того, вы отработали развертывание вспомогательных файлов и создание символических ссылок с помощью модуля ansible.builtin.file. Чтобы убедиться в успешности ваших развертываний, вы использовали модуль stat для проверки состояния и атрибутов файлов, а также модуль fetch для извлечения файлов, таких как журналы, с управляемого хоста обратно на управляющий узел. Наконец, вы научились выполнять операции очистки, используя модуль file с параметром state: absent для удаления файлов и каталогов, созданных в ходе лабораторной работы, обеспечивая чистое состояние на управляемом хосте.

Развертывание и управление файлами в RHEL с помощью Ansible

Введение

Копирование статического файла и установка атрибутов с помощью модуля ansible.builtin.copy

Изменение содержимого файла с помощью lineinfile и blockinfile

Генерация пользовательского MOTD с помощью модуля ansible.builtin.template

Развертывание вспомогательных файлов и создание символической ссылки с помощью copy и file

Проверка состояния файла с помощью stat и получение логов с помощью fetch

Очистка управляемых файлов на хосте с помощью модуля file