Ansible в Termux: написание ролей и плейбуков для автоматизации конфигурации Android‑устройств и удалённых Linux‑хостов

Termux позволяет превращать Android‑устройство в удобную «полевую консоль»: вы можете готовить конфигурации, запускать автоматизацию и поддерживать единый подход к управлению системами. Ansible в этом контексте особенно ценен: он работает на основе декларативных плейбуков, поддерживает повторное использование через роли и упрощает согласованную настройку как Android‑окружения, так и удалённых Linux‑хостов.

В результате вы получаете управляемую инфраструктуру: изменения описаны кодом, повторяемы, версионируемы и легче проверяются перед применением.

Предпосылки и ограничения

Перед стартом важно учесть практические моменты:

Вы управляете конфигурацией систем в рамках легитимного доступа (своих устройств и хостов).
Для удалённых Linux‑хостов понадобится доступ по SSH (ключи, пользователя, разрешения).
На Android не все системные сервисы доступны так же, как на Linux. Однако Ansible отлично подходит для управления пакетами Termux, настройкой пользовательских файлов, шаблонами конфигураций и подготовкой окружения.

Ниже мы сосредоточимся на сценариях, которые реально применимы в ежедневной практике: роли для установки зависимостей, настройка dotfiles/конфигураций, а также унификация действий на удалённых Linux‑машинах.

Подготовка окружения в Termux

Начните с базовой установки пакетов в Termux. В этом примере используются команды управления пакетами Termux и Python‑окружение, чтобы затем установить Ansible.

pkg update && pkg upgrade -y
pkg install -y python python-pip openssh git
pip install --upgrade pip
pip install ansible

Проверьте, что Ansible доступен:

ansible --version

Для удалённых хостов потребуется SSH‑клиент. Если вы планируете использовать отдельную виртуальную среду/профиль, можно дополнительно изолировать зависимости через venv, но это уже опционально.

Создание структуры проекта

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

mkdir -p ansible-termux/{roles,group_vars,host_vars}
mkdir -p ansible-termux/playbooks
cd ansible-termux
ansible-galaxy init base_setup
ansible-galaxy init termux_setup
ansible-galaxy init linux_common

Инициализация создаст каталоги defaults, tasks, handlers и т.д. Далее мы заполним их под задачу.

Инвентарь: управление Android и удалёнными Linux

Создайте файл инвентаря. Для простоты используем ini‑формат:

nano -w inventory.ini

Пример:

[android]
localhost ansible_connection=local

[linux]
server1 ansible_host=192.168.1.10 ansible_user=youruser ansible_ssh_private_key_file=/data/data/com.termux/files/home/.ssh/id_rsa
server2 ansible_host=192.168.1.11 ansible_user=youruser ansible_ssh_private_key_file=/data/data/com.termux/files/home/.ssh/id_rsa

Внимание: для Android‑участка мы указываем ansible_connection=local, чтобы плейбуки выполнялись на том же устройстве, где запущен Ansible.

Написание плейбука: общий сценарий

Плейбук обычно собирает набор ролей и связывает их с окружениями. Например, вам нужно:

На Android: подготовить зависимости Termux, развернуть конфиги пользователя.
На Linux: установить набор пакетов, настроить пользователя и файлы конфигурации.

Создадим плейбук playbooks/site.yml:

nano -w playbooks/site.yml

---
- name: Configure Android (Termux) and local environment
  hosts: android
  become: false
  vars:
    termux_home: "{{ lookup('env','HOME') }}"
  roles:
    - termux_setup

- name: Configure remote Linux hosts
  hosts: linux
  become: true
  roles:
    - linux_common
    - base_setup

Сначала выполнится настройка Android, затем — удалённые Linux‑хосты.

Роль termux_setup: задачи для Android

Откроем файл задач: roles/termux_setup/tasks/main.yml.

nano -w roles/termux_setup/tasks/main.yml

Пример роли, которая:

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

---
- name: Update apt repository in Termux
  ansible.builtin.command: pkg update
  changed_when: false

- name: Install required Termux packages
  ansible.builtin.command: pkg install -y {{ item }}
  loop:
    - tmux
    - nano
    - curl
  register: pkg_install
  changed_when: "pkg_install.rc == 0"

- name: Ensure config directory exists
  ansible.builtin.file:
    path: "{{ lookup('env','HOME') }}/.config/mytermux"
    state: directory
    mode: '0755'

- name: Deploy example configuration
  ansible.builtin.copy:
    dest: "{{ lookup('env','HOME') }}/.config/mytermux/app.conf"
    mode: '0644'
    content: |
      [app]
      environment=termux
      log_level=info

Обратите внимание:

Для Termux‑действий часто удобнее использовать ansible.builtin.command / ansible.builtin.shell, но старайтесь избегать лишних оболочек и всегда делайте поведение воспроизводимым.
Файлы конфигурации через copy или template позволяют держать настройки как код.

Роль base_setup: переиспользуемые элементы

Роль base_setup удобно использовать как базовую заготовку: например, настроить пользователя, поставить базовые утилиты, подготовить структуру директорий.

Пусть у вас будет простая версия, которая используется и на удалённых Linux, и потенциально на Android (в случае совместимых задач).

nano -w roles/base_setup/tasks/main.yml

---
- name: Ensure basic utilities are installed
  ansible.builtin.package:
    name:
      - curl
      - git
      - ca-certificates
    state: present

- name: Create common config directory
  ansible.builtin.file:
    path: /etc/myautomation/
    state: directory
    mode: '0755'

- name: Drop a marker file
  ansible.builtin.copy:
    dest: /etc/myautomation/managed_by_ansible
    content: "Managed by Ansible at {{ ansible_date_time.iso8601 }}
"
    mode: '0644'

Роль linux_common: настройка удалённых хостов

Теперь заполним roles/linux_common/tasks/main.yml. Здесь покажем типичный паттерн: пакеты + конфигурация пользователя + сервисы (опционально).

nano -w roles/linux_common/tasks/main.yml

---
- name: Update package cache (Debian/Ubuntu systems)
  ansible.builtin.apt:
    update_cache: true
  when: ansible_facts['os_family'] == 'Debian'

- name: Install Linux packages
  ansible.builtin.package:
    name:
      - htop
      - vim
      - unzip
    state: present

- name: Create application directory
  ansible.builtin.file:
    path: /opt/myapp
    state: directory
    owner: root
    group: root
    mode: '0755'

- name: Deploy application config
  ansible.builtin.copy:
    dest: /opt/myapp/app.yml
    owner: root
    group: root
    mode: '0644'
    content: |
      app:
        mode: production
        logs:
          level: info

Если потребуется управлять сервисами, добавьте handlers и уведомления. Например, перезапуск systemd‑юнита при изменении конфигов.

Переменные: group_vars и host_vars

Чтобы не «зашивать» параметры прямо в роли, выносите их в group_vars и host_vars. Например, для Linux‑хостов:

nano -w group_vars/linux.yml

myapp_mode: "production"
myapp_log_level: "info"

И затем используйте в роли через переменные. Обновите пример конфигурации:

content: |
  app:
    mode: {{ myapp_mode }}
    logs:
      level: {{ myapp_log_level }}

Так вы получите гибкость: один и тот же плейбук обслуживает разные группы хостов.

Проверка изменений и безопасный запуск

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

ansible-playbook -i inventory.ini playbooks/site.yml --check

Для отладки полезен подробный вывод:

ansible-playbook -i inventory.ini playbooks/site.yml --diff -v

А сам запуск:

ansible-playbook -i inventory.ini playbooks/site.yml

Best practices для Termux + Ansible

Держите роли маленькими и сфокусированными. Одна роль — одна логическая зона ответственности (например, «Termux базовые пакеты», «Конфиги приложения», «Linux common utilities»).
Используйте идемпотентность. Старайтесь строить задачи так, чтобы при повторном запуске результат не «дёргался» без причины.
Ставьте шаблоны через template, а не конкатенации. Это уменьшает ошибки и облегчает тестирование.
Фиксируйте структуру проекта. Даже 3–4 роли заметно выигрывают от единого каркаса.
Разделяйте окружения переменными. Не меняйте код — меняйте group_vars/host_vars.

Вариант: создание локальной сети для управления хостами

Если вы хотите управлять удалёнными Linux‑хостами с Android в «полевых условиях», обычно удобнее организовать локальную сеть (например, через доступный роутер/связку устройств) и запускать Ansible по SSH в пределах этой сети. Это упрощает связность и снижает количество переменных. (Важно: речь только о локальной сети, не об обходе блокировок.)

Мини-чеклист для старта

Termux: установили Python и Ansible, проверили ansible --version.
Инвентарь: добавили [android] и [linux].
Роли: написали tasks/main.yml, опционально добавили переменные и handlers.
Плейбук: собрали роли в playbooks/site.yml.
Запуск: прогнали --check и при необходимости --diff.

Заключение

Ansible в Termux — это практичный способ объединить «мобильную» работу с «серверной» автоматизацией в единый подход: декларативные плейбуки, повторно используемые роли и удобная структура проекта. Правильно организованные роли помогают быстро масштабировать автоматизацию: от настройки окружения Termux до согласованной конфигурации удалённых Linux‑хостов по SSH.

Если вам нужна помощь с проектированием структуры ролей, аудитом плейбуков или интеграцией автоматизации под вашу инфраструктуру, обратитесь в РыбинскЛАБ — мы поможем выстроить практичную и безопасную систему управления конфигурациями.