Что такое тег в Ansible?

Тег (Tag) в Ansible

Тег (англ. tag) в Ansible — это механизм избирательного выполнения задач (tasks), ролей (roles), блоков (blocks) или даже целых плейбуков (playbooks). Он позволяет назначать именованные метки элементам конфигурации, а затем запускать только те элементы, которые помечены конкретными тегами (или, наоборот, пропускать их). Это мощный инструмент управления выполнением, особенно в сложных сценариях развертывания.

Основные цели использования тегов

• Селективное выполнение (Targeting): Запуск только специфической части конфигурации без необходимости выполнения всего плейбука. Например, только задач, связанных с настройкой веб-сервера (nginx) или только задач развертывания приложения (deploy).
• Пропуск элементов (Skipping): Исключение из выполнения определенных задач (например, --skip-tags "restart").
• Организация и структурирование: Логическая группировка задач по функциональности или этапам (например, setup, config, service).
• Управление этапами деплоя: Возможность разделить один большой плейбук на условные этапы и запускать их независимо друг от друга.

Где можно применять теги

Теги можно назначать почти на всех уровнях:

• Отдельной задаче (task):

  tasks:
    - name: Install Nginx package
      apt:
        name: nginx
        state: latest
      tags:
        - nginx
        - packages
        - install
  

• Блоку задач (block): Тег, примененный к блоку, автоматически применяется ко всем задачам внутри него.

  tasks:
    - block:
        - name: Create app directory
          file:
            path: /opt/myapp
            state: directory
        - name: Copy application files
          copy:
            src: app/
            dest: /opt/myapp
      tags:
        - app_setup
  

• Роли (role): Теги можно назначать при импорте или включении роли.

  roles:
    - role: nginx
      tags: ['web', 'nginx']
  

• Импортируемым плейбукам (import_playbook):

  - import_playbook: database.yml
    tags: database
  

Синтаксис и использование

1. Объявление тегов: Теги объявляются с помощью ключевого слова tags:, за которым следует список.

   tags:
     - tag1
     - tag2
     # Или в одной строке
     tags: ['tag1', 'tag2']
   

2. Запуск с тегами из командной строки:

    *   `ansible-playbook site.yml --tags "nginx,deploy"` — выполнить только задачи с тегами `nginx` ИЛИ `deploy`.
    *   `ansible-playbook site.yml --tags tagged` — выполнить ВСЕ задачи, у которых есть хотя бы один тег (удобно для отладки).

1. Исключение тегов:

    *   `ansible-playbook site.yml --skip-tags "restart,debug"` — выполнить все задачи, КРОМЕ тех, что помечены тегами `restart` или `debug`.

Специальные теги

Ansible имеет набор встроенных, "магических" тегов, которые обрабатываются особым образом:

• always: Задача с этим тегом будет выполняться всегда, если только не указать явное исключение через --skip-tags "always". Крайне полезно для задач логирования или сбора фактов, которые нужны на каждом запуске.

  - name: Gather facts (always runs)
    setup:
    tags: always
  

• never: Задача с этим тегом никогда не будет выполнена по умолчанию. Её можно запустить только явно, указав --tags "never". Используется для задач, которые должны выполняться в исключительных, ручных сценариях.

  - name: Dangerous factory reset (never runs by default)
    command: /usr/bin/reset-everything
    tags: never
  

• tagged и untagged: Это не теги для назначения, а ключевые слова для фильтрации. --tags tagged (как показано выше) и --tags untagged (запустить только задачи без тегов).

Важные нюансы и лучшие практики

• Наследование: Теги, назначенные блоку, роли или импортируемому плейбуку, наследуются всеми задачами внутри. Это мощно, но требует внимательности.
• Повторное использование тегов: Один и тот же тег можно назначать множеству задач в разных местах, что и позволяет группировать их.
• Читаемость: Давайте тегам понятные, составные имена, отражающие их цель (deploy_frontend, security_hardening). Избегайте аббревиатур, которые могут быть непонятны коллегам.
• Документация: В больших проектах полезно вести список всех используемых тегов и их назначения (например, в README.md).
• Не злоупотребляйте always: Это может замедлить выполнение и привести к нежелательным побочным эффектам. Используйте этот тег обдуманно.
• Теги и обработчики (handlers): Обработчики также поддерживают теги. Если задача с тегом service вызывает обработчик restart nginx, и этот обработчик помечен тегом nginx, то логика выполнится корректно.

Практический пример

Рассмотрим плейбук развертывания веб-приложения:

---
- name: Deploy Awesome App
  hosts: webservers
  become: yes

  tasks:
    - name: Update apt cache (always run)
      apt:
        update_cache: yes
      tags: always

    - name: Install Nginx and Python dependencies
      apt:
        name: "{{ item }}"
        state: latest
      loop:
        - nginx
        - python3-pip
      tags:
        - packages
        - nginx

    - name: Deploy application code
      copy:
        src: ../app/
        dest: /var/www/awesome-app/
      tags:
        - deploy
        - app

    - name: Ensure app service is running (skipped by default in dev)
      systemd:
        name: awesome-app
        state: started
        enabled: yes
      tags: never

  handlers:
    - name: Restart Nginx
      systemd:
        name: nginx
        state: restarted
      listen: "restart webserver"
      tags: nginx

Как этим управлять:

• ansible-playbook deploy.yml — выполнит всё, кроме задачи с tags: never.
• ansible-playbook deploy.yml --tags "deploy" — выполнит ТОЛЬКО задачу "Deploy application code" и, возможно, обработчик, если он был уведомлен в этой задаче (в данном примере — нет).
• ansible-playbook deploy.yml --tags "nginx" — установит Nginx и его зависимости, а также выполнит обработчик перезагрузки Nginx (если он был уведомлен).
• ansible-playbook deploy.yml --skip-tags "always" — пропустит обновление apt-кеша.
• ansible-playbook deploy.yml --tags "never" — запустит ТОЛЬКО задачу по включению сервиса приложения, которая по умолчанию отключена.

Таким образом, теги превращают Ansible из инструмента последовательного выполнения скриптов в гибкую систему оркестрации, позволяющую оператору точно контролировать, какие части конфигурации и в какой момент времени должны быть применены. Это критически важный инструмент для построения эффективного CI/CD-пайплайна и управления сложными состояниями инфраструктуры.