Termux и инфраструктура как код: автоматизация Terraform и Ansible с помощью контейнеров в Termux

Termux давно перестал быть только «консолью на телефоне». При грамотной архитектуре он становится рабочей средой для инженерных задач: подготовка инфраструктуры как кода (IaC), запуск Terraform-планов, выполнение Ansible-плейбуков, сбор артефактов и валидация конфигураций. В этом материале покажем, как организовать автоматизацию Terraform и Ansible в Termux с использованием контейнеров — чтобы повторяемость и предсказуемость среды были на уровне «почти как на сервере».

Подход ориентирован на локальные сценарии (в том числе для тестовых стендов) и не затрагивает обход ограничений. Все примеры — на базе законных и штатных возможностей Linux/Android и инструментов с открытым распространением.

Почему контейнеры внутри Termux

Основная проблема «ручного» запуска Terraform/Ansible в Termux — различия версий, библиотек и зависимостей. Контейнеры решают это тремя способами:

Повторяемость: одна и та же сборка контейнера — одна и та же версия инструментов.
Изоляция: зависимости Terraform и Ansible не конфликтуют с остальной системой.
Код как контракт: версия инструментов фиксируется в Dockerfile/образе и становится частью IaC-процесса.

С точки зрения практики вы получаете управляемую «мини-лабораторию»: на телефоне можно готовить, проверять и частично исполнять шаги, не загрязняя базовую среду Termux.

Базовая архитектура (IaC + контейнеры)

Рекомендуемая структура репозитория:

repo/
  terraform/
    modules/
    environments/
      dev/
        main.tf
        variables.tf
        outputs.tf
        terraform.tfvars
  ansible/
    playbooks/
      site.yml
    roles/
      common/
      web/
    inventories/
      dev.ini
  scripts/
    terraform-plan.sh
    terraform-apply.sh
    ansible-run.sh
  containers/
    terraform/
      Dockerfile
    ansible/
      Dockerfile
    shared/
      Dockerfile

Контейнеры создают «контур выполнения» для двух главных движков:

Terraform — планирование и применение изменений инфраструктуры.
Ansible — конфигурация хостов/стендов после (или параллельно) с Terraform.

В Termux вы запускаете сценарии из scripts/, а они вызывают контейнеры с монтированием нужных каталогов.

Настройка Termux: минимальный набор

Дальше предполагаем, что Termux уже установлен и вы умеете работать в консоли. Важно также продумать переменные окружения для путей и ключей (лучше хранить секреты вне репозитория).

Пример типового набора инструментов в Termux:

pkg update
pkg upgrade
pkg install git curl tar unzip

Для контейнеров на Termux обычно используют подходы через пользовательские рантаймы/контейнерные сборки. В зависимости от вашей конфигурации Termux и доступных пакетов путь может отличаться. Общая идея при этом едина: вам нужен механизм «запустить контейнер и смонтировать папку проекта».

Ниже приведены Docker-ориентированные примеры. Если вы используете другой рантайм контейнеров в Termux, логика монтирования и переменных сохраняется, меняется только команда запуска.

Контейнер Terraform: Dockerfile и запуск plan/apply

Пример контейнера Terraform фиксирует версию и обеспечивает предсказуемость:

FROM alpine:3.20

RUN apk add --no-cache bash curl ca-certificates unzip

# Версию Terraform фиксируем явно
ARG TERRAFORM_VERSION=1.10.5
RUN curl -sSL https://releases.hashicorp.com/terraform/${TERRAFORM_VERSION}/terraform_${TERRAFORM_VERSION}_linux_amd64.zip -o /tmp/terraform.zip \
  && unzip /tmp/terraform.zip -d /usr/local/bin \
  && rm -f /tmp/terraform.zip

WORKDIR /workspace

# Для удобства можно объявить переменные, но значения задаются снаружи
ENV TF_IN_AUTOMATION=1

Сборка образа (в Termux из каталога containers/terraform):

docker build -t iac-terraform:1.10.5 .

Запуск terraform plan из сценария:

#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

ENVIRONMENT="${1:-dev}"

PROJECT_ROOT="$(cd "$(dirname "$0")/.." && pwd)"

docker run --rm \
  -v "$PROJECT_ROOT/terraform:/workspace" \
  -w "/workspace/environments/$ENVIRONMENT" \
  -e "AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID:-}" \
  -e "AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY:-}" \
  -e "AWS_REGION=${AWS_REGION:-}" \
  iac-terraform:1.10.5 \
  terraform init -input=false 

docker run --rm \
  -v "$PROJECT_ROOT/terraform:/workspace" \
  -w "/workspace/environments/$ENVIRONMENT" \
  -e "AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID:-}" \
  -e "AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY:-}" \
  -e "AWS_REGION=${AWS_REGION:-}" \
  iac-terraform:1.10.5 \
  terraform plan -input=false -out="tfplan-$ENVIRONMENT.tfplan"

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

мы монтируем каталог terraform/ в /workspace контейнера;
секреты передаются через переменные окружения (не храните ключи в репозитории);
рабочая директория задается -w на конкретное окружение.

Ansible-контейнер: запуск плейбуков из Termux

Контейнер Ansible фиксирует версию и библиотеки:

FROM python:3.12-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
    sshpass \
    ca-certificates \
  && rm -rf /var/lib/apt/lists/*

RUN pip install --no-cache-dir ansible==10.3.0

WORKDIR /workspace

Сборка:

docker build -t iac-ansible:10.3.0 .

Пример сценария запуска плейбука:

#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

ENVIRONMENT="${1:-dev}"
INVENTORY="ansible/inventories/$ENVIRONMENT.ini"

PROJECT_ROOT="$(cd "$(dirname "$0")/.." && pwd)"

docker run --rm \
  -v "$PROJECT_ROOT/ansible:/workspace" \
  -w /workspace \
  iac-ansible:10.3.0 \
  ansible-playbook \
    -i "$INVENTORY" \
    playbooks/site.yml \
    -e "environment=$ENVIRONMENT"

Для аутентификации SSH чаще всего используют агент или ключи. В контейнере вы можете монтировать каталог с known_hosts и ключами или использовать проброс SSH-агента. Конкретная реализация зависит от вашего рантайма контейнеров в Termux.

Связка Terraform → Ansible: общий workflow

Типовой процесс в IaC выглядит так:

Terraform plan — проверить изменения.
Terraform apply — создать/обновить инфраструктуру.
Terraform outputs — получить IP/hostname/параметры для Ansible.
Ansible apply — сконфигурировать сервисы.

Чтобы автоматизировать передачу параметров, удобно сделать генерацию inventory из Terraform outputs. Например, после apply сформировать ansible/inventories/dev.ini или отдельный файл под окружение.

Пример «черновой» утилиты генерации inventory (идея, адаптируйте под свой провайдер):

#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

ENVIRONMENT="${1:-dev}"

PROJECT_ROOT="$(cd "$(dirname "$0")/.." && pwd)"

# Предполагаем, что terraform в контейнере хранит outputs в рабочей директории
# и что вы уже выполнили terraform apply.

docker run --rm \
  -v "$PROJECT_ROOT/terraform:/workspace" \
  -w "/workspace/environments/$ENVIRONMENT" \
  iac-terraform:1.10.5 \
  terraform output -json > "$PROJECT_ROOT/terraform/outputs-$ENVIRONMENT.json"

# Далее распарсить json можно через jq (если установлен) или python.
# Здесь демонстрационный фрагмент с jq:

# jq -r '.web_instances.value[] | "host=\(.ip)"' ...

# Итог: сформировать inventory.
# Пример формата dev.ini:
# [web]
# 1.2.3.4 ansible_user=ubuntu

Ключевой принцип: «инвентарь» становится артефактом контура Terraform, а не ручной операцией.

Окружения, переменные и контроль изменений

Для практичного управления окружениями придерживайтесь:

terraform/environments/<env> — отдельная папка на dev/stage/prod;
tfvars — файлы параметров окружений;
одинаковые версии контейнеров — вы фиксируете инструменты, а значит и поведение;
проверка — храните результаты plan (файл -out) и архивируйте в локальную папку.

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

Пример локальной сети (VPN) для тестового стенда

Если вам нужно развернуть локальный тестовый стенд с несколькими машинами (например, VM/контейнеры) и обеспечить связность, можно организовать локальную сеть через VPN или туннельный режим (только для сценариев подключения внутри тестового контура).

После того как хосты доступны по IP/hostname, Ansible inventory будет ссылаться на эти адреса, а Terraform outputs — помогать с параметрами. При этом не забывайте о правилах безопасности и легальности использования технологий в рамках вашей инфраструктуры.

Пайплайн «одной кнопкой» в Termux

Чтобы запускать процесс регулярно, сделайте один верхнеуровневый скрипт. Пример:

#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

ENVIRONMENT="${1:-dev}"

# 1) plan
bash scripts/terraform-plan.sh "$ENVIRONMENT"

# 2) apply (опционально — только после утверждения)
# bash scripts/terraform-apply.sh "$ENVIRONMENT"

# 3) подтянуть outputs и обновить inventory
# bash scripts/generate-inventory.sh "$ENVIRONMENT"

# 4) ansible
bash scripts/ansible-run.sh "$ENVIRONMENT"

В реальной эксплуатации применяйте «ручной контроль» перед apply или используйте разные режимы выполнения.

Частые ошибки и как их избежать

Несовпадение версий: без контейнеров Terraform/Ansible могут вести себя иначе. Решение — фиксировать версии в контейнерах.
Засорение секретами репозитория: не кладите ключи в git. Решение — переменные окружения и отдельные файлы вне репозитория.
Проблемы с путями: в контейнерах всегда явно задавайте -v и -w.
Непредсказуемый inventory: инвентарь должен генерироваться или обновляться строго по Terraform outputs, а не вручную «по памяти».

Заключение

Termux в связке с контейнеризированной средой для Terraform и Ansible превращается в удобную станцию для работы с инфраструктурой как кодом: вы запускаете единообразные команды, получаете повторяемость за счет фиксированных образов и организуете связку Terraform → Ansible по четкому workflow. Это особенно полезно для тестовых стендов и быстрых циклов разработки, когда важны скорость, воспроизводимость и минимизация ручных операций.

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