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

AnsibleBeginner
Практиковаться сейчас

Введение

В этой лабораторной работе вы освоите основные навыки развертывания и управления файлами в системе 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.

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

    Установите пакет ansible-core.

    sudo dnf install -y ansible-core

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

    cd ~/project
    mkdir files
  2. Далее создайте простой текстовый файл, который мы будем копировать. Мы используем команду cat с "here document" для создания файла info.txt в каталоге files.

    cat << EOF > ~/project/files/info.txt
    This file was deployed by Ansible.
    It contains important system information.
    EOF
  3. Теперь создайте файл инвентаря Ansible. Инвентарь сообщает Ansible, какие хосты необходимо управлять. Для этой лабораторной работы мы будем управлять локальной машиной. Создайте файл с именем inventory.ini.

    cat << EOF > ~/project/inventory.ini
    localhost ansible_connection=local
    EOF

    В этом инвентаре localhost — это хост, на который мы нацелены. Переменная ansible_connection=local указывает Ansible выполнять задачи непосредственно на управляющем узле, без использования SSH.

  4. Создайте свой первый плейбук 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 означает, что владелец может читать/писать, группа может читать, а остальные не имеют разрешений.
  5. Выполните плейбук с помощью команды 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
  6. Наконец, проверьте, что файл был скопирован правильно и имеет нужные атрибуты. Используйте команду 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.

  1. Сначала убедитесь, что вы находитесь в каталоге проекта.

    cd ~/project
  2. Создайте новый плейбук с именем modify_file.yml. Этот плейбук будет содержать две задачи: одну для добавления одной строки и другую для добавления блока текста в наш существующий файл.

    nano ~/project/modify_file.yml
  3. Добавьте следующее содержимое в ваш плейбук 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: Гарантирует наличие блока.
  4. Выполните плейбук с помощью команды 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
  5. Наконец, проверьте изменения, просмотрев содержимое /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), которое будет отображать специфичную для системы информацию.

  1. Сначала убедитесь, что вы находитесь в каталоге ~/project, и создайте выделенный подкаталог для ваших шаблонов. Стандартной лучшей практикой Ansible является хранение шаблонов Jinja2 в каталоге templates.

    cd ~/project
    mkdir templates
  2. Далее создайте файл шаблона 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 }} — это пользовательская переменная, которую мы определим в нашем плейбуке.
  3. Теперь создайте новый плейбук с именем 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 — это целевой файл на управляемом хосте.
  4. Выполните плейбук.

    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
  5. Проверьте результат. Проверьте содержимое вновь сгенерированного файла /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, гарантируя, что они всегда будут отображать одно и то же сообщение.

  1. Сначала убедитесь, что вы находитесь в каталоге ~/project, и создайте исходный файл для нашего сообщения issue. Мы поместим этот файл в подкаталог files, который вы создали ранее.

    cd ~/project
    cat << EOF > ~/project/files/issue
    Authorized access only.
    All connections are logged and monitored.
    EOF
  2. Создайте новый плейбук с именем deploy_issue.yml. Этот плейбук будет содержать две задачи: одну для копирования файла issue и другую для создания символической ссылки.

    nano ~/project/deploy_issue.yml
  3. Добавьте следующее содержимое в ваш плейбук 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 плейбук завершится ошибкой в такой ситуации.
  4. Выполните плейбук.

    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
  5. Проверьте результат с помощью команды 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.

  1. Сначала убедитесь, что вы находитесь в каталоге ~/project, и создайте новый подкаталог для хранения файлов, которые вы будете получать.

    cd ~/project
    mkdir fetched_logs
  2. Создайте новый плейбук с именем check_and_fetch.yml. Этот плейбук будет содержать задачи для проверки файла и получения лога.

    nano ~/project/check_and_fetch.yml
  3. Добавьте следующее содержимое в ваш плейбук 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 без дополнительных подкаталогов.
  4. Выполните плейбук. Поскольку мы читаем системный лог-файл, используется 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
  5. Проверьте, был ли лог-файл успешно получен. Выведите содержимое каталога 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.

  1. Сначала убедитесь, что вы находитесь в каталоге ~/project.

    cd ~/project
  2. Создайте новый плейбук с именем cleanup.yml. Этот плейбук будет содержать все задачи, необходимые для отмены наших изменений.

    nano ~/project/cleanup.yml
  3. Добавьте следующее содержимое в ваш плейбук 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 отсутствует. Если файл найден, он будет удален. Если файла уже нет, ничего не произойдет, сохраняя идемпотентность.

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

    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
  5. Проверьте, были ли файлы удалены. Вы можете использовать команду 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 для удаления файлов и каталогов, созданных в ходе лабораторной работы, обеспечивая чистое состояние на управляемом хосте.