Termux давно стал удобной «мобильной консолью» для администраторов и DevOps-инженеров: можно работать удалённо, быстро запускать диагностику, готовить конфигурации и поддерживать инфраструктуру в привычном командном стиле. В этой статье рассмотрим практический подход к автоматизированному управлению инфраструктурой в Microsoft Azure и DigitalOcean с помощью Terraform (Infrastructure as Code) и Ansible (конфигурация и эксплуатация), используя Termux как точку управления.
Подход ориентирован на легальную и безопасную эксплуатацию: управление выполняется через официальные API облаков, а доступ к ресурсам обеспечивается корректной настройкой ключей и переменных окружения.
Архитектура решения: роли Termux, Terraform и Ansible
Предложим рабочую схему, которая хорошо масштабируется:
- Termux — управляющая среда (клиент): хранит репозиторий сценариев, выполняет Terraform и Ansible, формирует отчёты и логи.
- Terraform — описывает инфраструктуру: сети, вычислительные ресурсы, ключи доступа, сопутствующие сущности.
- Ansible — конфигурирует и обслуживает сервера: установка пакетов, настройка пользователей, базовая hardening-настройка, деплой приложений (при необходимости).
Логика простая: сначала Terraform создаёт/обновляет инфраструктуру, затем Ansible подключается к созданным хостам и приводит их к требуемому состоянию.
Требования и подготовка рабочей среды в Termux
Начнём с базовой подготовки. В Termux потребуется пакетный менеджер и установка нужных инструментов.
pkg update && pkg upgrade -y
pkg install -y git openssh curl wget tar unzipДальше подготовим директории и репозиторий:
mkdir -p ~/iac/azure-do
cd ~/iac/azure-do
git clone <ваш_репозиторий_с_кодом> .Если вы ещё не имеете структуры проекта, обычно удобно разделять:
- terraform/ — модули и провайдеры для Azure и DigitalOcean
- ansible/ — плейбуки, роли, шаблоны
- inventory/ или генерацию инвентаря
- scripts/ — вспомогательные скрипты (генерация inventory, проверка переменных)
Аутентификация: переменные окружения и доступы
Чтобы Terraform и Ansible работали корректно, нужно подготовить креденшалы:
- Для Azure: обычно используется Service Principal (tenant id, client id, client secret) либо managed identity (если Terraform выполняется в среде с ролями). В нашем случае Termux чаще всего выступает клиентом, значит применяется Service Principal.
- Для DigitalOcean: API token.
- Для Ansible: SSH-доступ к создаваемым инстансам (ключи/пользователь/политики доступа).
Рекомендуется хранить секреты в переменных окружения, а не в репозитории. Например:
export TF_VAR_azure_subscription_id="<subscription_id>"
export TF_VAR_azure_tenant_id="<tenant_id>"
export TF_VAR_azure_client_id="<client_id>"
export TF_VAR_azure_client_secret="<client_secret>"
export TF_VAR_digitalocean_token="<do_token>"
export TF_VAR_ssh_public_key="<ваш_ssh_pub_key>"
export TF_VAR_ssh_private_key_path="$HOME/.ssh/id_rsa"Проверка SSH-ключа в Termux:
ls -l ~/.ssh
ssh-keygen -y -f ~/.ssh/id_rsa > /dev/null && echo "SSH key OK"Terraform: инфраструктура для Azure и DigitalOcean
Terraform позволяет описать ресурсы декларативно. Важно сделать проект модульным: отдельные модули для Azure и для DigitalOcean, единый интерфейс переменных и выходов (outputs) для передачи IP/hostname в Ansible.
Пример: провайдеры и базовая структура
В файле, например terraform/providers.tf, может быть задано:
terraform {
required_version = ">= 1.5.0"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 3.0"
}
digitalocean = {
source = "digitalocean/digitalocean"
version = "~> 2.0"
}
}
}
provider "azurerm" {
features {}
subscription_id = var.azure_subscription_id
tenant_id = var.azure_tenant_id
client_id = var.azure_client_id
client_secret = var.azure_client_secret
}
provider "digitalocean" {
token = var.digitalocean_token
}Пример: вычисления (виртуальная машина/инстанс) и выходы
Ресурсы будут зависеть от ваших требований (регион, размер, сеть, образ). Концептуально вам нужно:
- Создать инстансы в Azure и DigitalOcean
- Открыть доступ по SSH строго с нужных адресов (или через корректные security groups/NSG)
- Вернуть IP адреса и имя пользователя
Схема outputs:
output "azure_hosts" {
value = {
for k, v in azurerm_linux_virtual_machine.vm : k => {
host = v.public_ip_address
user = "azureuser"
ip = v.public_ip_address
platform = "azure"
}
}
}
output "do_hosts" {
value = {
for k, v in digitalocean_droplet.vm : k => {
host = v.ipv4_address
user = "root"
ip = v.ipv4_address
platform = "digitalocean"
}
}
}Важно: при реальной реализации пользователь и образы должны соответствовать тому, как вы планируете настраивать ОС в Ansible (например, не использовать root, если у вас есть отдельный администраторский пользователь).
Прогон Terraform в Termux
Выполните:
cd terraform
terraform init
terraform fmt -check
terraform validate
terraform plan -out tfplan
terraform apply tfplanДля передачи результатов в Ansible удобно получить outputs в JSON:
terraform output -json > ../ansible/terraform-outputs.jsonСбор инвентаря для Ansible
Чтобы Ansible мог подключиться к новым хостам, инвентарь должен содержать IP/hostname и пользователя. Есть несколько вариантов: статический инвентарь или генерация на основании Terraform outputs.
Пример генерации inventory (условно) с использованием jq. Убедитесь, что jq установлен:
pkg install -y jqПример скрипта генерации, например ansible/generate-inventory.sh:
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
OUT="../ansible/inventory.ini"
JSON="terraform-outputs.json"
cat > "$OUT" <<EOF
[azure]
EOF
jq -r '.azure_hosts.value | to_entries[] | "(.value.host) ansible_user=(.value.user)"' "$JSON" >> "$OUT"
cat >> "$OUT" <<EOF
[digitalocean]
EOF
jq -r '.do_hosts.value | to_entries[] | "(.value.host) ansible_user=(.value.user)"' "$JSON" >> "$OUT"Затем запуск:
chmod +x ansible/generate-inventory.sh
cd ansible
./generate-inventory.shAnsible: конфигурация серверов после создания
Теперь Ansible подключается к инстансам и выполняет плейбук. Убедимся, что известен путь к приватному ключу и корректные параметры SSH.
Пример файла ansible.cfg
cat > ansible.cfg <<'EOF'
[defaults]
inventory = inventory.ini
host_key_checking = False
retry_files_enabled = False
stdout_callback = yaml
forks = 10
EOFПример плейбука (bootstrap)
Создадим ansible/playbooks/bootstrap.yml:
- name: Bootstrap hosts
hosts: all
become: true
vars:
ansible_ssh_private_key_file: "{{ lookup('env', 'TF_VAR_ssh_private_key_path') }}"
tasks:
- name: Ensure apt cache updated (Debian/Ubuntu)
ansible.builtin.apt:
update_cache: true
when: ansible_facts.os_family == "Debian"
- name: Install common packages
ansible.builtin.apt:
name:
- curl
- ca-certificates
state: present
when: ansible_facts.os_family == "Debian"
- name: Create admin user (пример логики)
ansible.builtin.user:
name: admin
state: present
when: ansible_facts.os_family == "Debian"В реальном проекте вы учтёте различия дистрибутивов Azure/DO, требования безопасности и корпоративные стандарты (например, запрет паролей, настройка firewall, управление ключами).
Запуск Ansible из Termux
export ANSIBLE_HOST_KEY_CHECKING=False
ansible-playbook -i inventory.ini -u admin --private-key "$TF_VAR_ssh_private_key_path" playbooks/bootstrap.ymlЕсли вы используете переменную ansible_user из инвентаря, команду можно упростить, оставив только плейбук и ключ.
Сетевая связность: доступ по SSH и локальная сеть (VPN)
Для управления удалёнными серверами обычно требуется сетевой доступ по SSH. Если вам нужно объединить ваши сети для администрирования как локальную сеть, можно использовать VPN, чтобы клиенты/инструменты Termux имели адреса в одной адресной схеме с инстансами.
Важно: VPN не применяется для обхода ограничений. На стороне облаков и хостов всё равно должны быть корректно настроены правила доступа (security groups/NSG/firewall), а также аутентификация по ключам.
Надёжность: state Terraform, идемпотентность и контроль изменений
Чтобы управление было воспроизводимым:
- Terraform state: используйте удалённое хранилище state (например, Azure Storage для Azure и аналогичное решение для других облаков) в зависимости от вашей стратегии. Это предотвращает конфликты при параллельных изменениях.
- Идемпотентность Ansible: плейбуки должны корректно повторно применяться без непредсказуемых эффектов.
- Логи: сохраняйте stdout/stderr и outputs, чтобы можно было восстановить цепочку действий.
Безопасность и соответствие лучшим практикам
В контексте Termux и мобильного рабочего места особенно важны:
- Ограничение доступа к секретам: не отправляйте токены/ключи в репозитории и не выводите их в лог без необходимости.
- Использование SSH ключей вместо паролей.
- Принцип минимальных привилегий для Service Principal и API token.
- Разделение окружений (dev/stage/prod) по отдельным рабочим директориям и/или workspace.
Минимальный сценарий “сделай развернуть”
Ниже — компактный порядок действий, который обычно работает в реальных проектах:
cd ~/iac/azure-do/terraform
terraform init
terraform plan -out tfplan
terraform apply tfplan
terraform output -json > ../ansible/terraform-outputs.json
cd ../ansible
./generate-inventory.sh
ansible-playbook playbooks/bootstrap.ymlЗаключение
Termux отлично подходит как «портативная панель управления» для автоматизации в облаках: Terraform берёт на себя создание и изменение инфраструктуры в Azure и DigitalOcean, а Ansible приводит сервера к требуемому состоянию. Такой подход упрощает повторяемость, ускоряет поставку изменений и помогает выстраивать управляемые процессы эксплуатации.
Если вам нужна помощь с настройкой модулей Terraform, корректной генерацией inventory, шаблонами ролей Ansible и выстраиванием безопасного контура доступа — обращайтесь в РыбинскЛАБ. Мы помогаем внедрять DevOps-практики и автоматизацию инфраструктуры под ваши требования и процессы.