Настройка Rundeck для управления задачами на серверах

# docker-compose.yml services:
  rundeck:
    image: rundeck/rundeck:5.3.0
    environment:
      RUNDECK_GRAILS_URL: https://rundeck.mycompany.com
      RUNDECK_SERVER_FORWARDED: "true"
      RUNDECK_DATABASE_DRIVER: org.postgresql.Driver
      RUNDECK_DATABASE_URL: jdbc:postgresql://postgres:5432/rundeck
      RUNDECK_DATABASE_USERNAME: rundeck
      RUNDECK_DATABASE_PASSWORD: ${DB_PASSWORD}
      RUNDECK_SECURITY_HTTPHEADERS_PROVIDER_CSP_ENABLED: "false"
    volumes:
      - rundeck_data:/home/rundeck/server/data
      - ./etc/framework.properties:/home/rundeck/etc/framework.properties:ro
    ports:
      - "4440:4440"
    depends_on:
      - postgres
  postgres:
    image: postgres:15
    environment:
      POSTGRES_DB: rundeck
      POSTGRES_USER: rundeck
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data

В framework.properties — настройка Node sources (инвентарь серверов) и SSH-ключей:

framework.ssh.keypath=/home/rundeck/.ssh/rundeck-deploy
framework.ssh.user=deploy
framework.projects.dir=/home/rundeck/projects

Сравнение архитектур: standalone vs кластер

Пошаговая инструкция развёртывания

1. Аудит инфраструктуры: список серверов, версии ОС, доступность по SSH.
2. Выбор архитектуры: standalone или кластер. Для кластера настраиваем балансировку через HAProxy.
3. Развёртывание с PostgreSQL, настройка persistence и резервного копирования.
4. Импорт SSH-ключей в Key Storage (а не на диск).
5. Создание 10-15 типовых job'ов: перезапуск сервисов, очистка логов, сбор метрик, деплой артефактов.
6. Настройка RBAC: группы пользователей (admin, developer, operator), политики запуска.
7. Интеграция с системой оповещений: Slack, email, PagerDuty.
8. Документация и обучение команды: 2-часовой workshop, инструкции по эксплуатации.

Job definition как код (IaC)

Jobs экспортируются в YAML — это Infrastructure as Code для задач. Пример job "Restart Application Service":

---
- id: restart-app-service
  name: Restart Application Service
  description: "Gracefully restart the application on target nodes"
  group: Operations/Services
  nodefilters:
    dispatch:
      threadcount: 5
      keepgoing: false
      excludePrecedence: true
    filter: 'tags: app-server +env:${option.environment}'
  options:
    - name: environment
      label: Environment
      values: [staging, production]
      required: true
      enforced: true
    - name: service_name
      label: Service Name
      default: myapp
      required: true
  sequence:
    keepgoing: false
    strategy: node-first
    commands:
      - script: |
          #!/bin/bash
          set -euo pipefail
          SERVICE="${option.service_name}"
          echo "Checking service status..."
          systemctl is-active "$SERVICE" || { echo "Service not running"; exit 1; }
          echo "Stopping $SERVICE..."
          systemctl stop "$SERVICE"
          sleep 2
          echo "Starting $SERVICE..."
          systemctl start "$SERVICE"
          echo "Waiting for health check..."
          sleep 5
          systemctl is-active "$SERVICE" && echo "OK" || { echo "FAILED to start"; exit 1; }
  notification:
    onfailure:
      plugin:
        type: slack-incoming-webhook
        configuration:
          webhook_url: ${globals.slack_ops_webhook}
          message: "Job FAILED: ${job.name} on ${node.name}"
    onsuccess:
      email:
        recipients: [email protected]
        subject: "Rundeck: ${job.name} completed"
---

tags: app-server +env:${option.environment} — фильтрация нод по тегам с подстановкой опции из формы запуска. Один job работает и на staging, и на production в зависимости от выбора. Мы используем GitOps: job-ы версионируются в репозитории, изменения проходят code review.

Настройка RBAC для операторов

Rundeck использует policy-based ACL. Пример для команды поддержки:

# /etc/rundeck/acls/support.aclpolicy
description: Support team - read and run pre-approved jobs only
context:
  project: '.*'
for:
  job:
    - allow: [read, run]
      match:
        group: 'Operations/.*'
  node:
    - allow: [read]
  project:
    - allow: [read]
by:
  group: support-team

Эта политика даёт read и run на job'ы группы Operations, но запрещает создание новых job'ов и прямой доступ к нодам. Мы настраиваем RBAC под каждую роль: разработчики могут запускать деплой, операторы — только перезапуск, администраторы — всё.

Типовые сценарии использования Rundeck

Почему Key Storage лучше хранения ключей на диске?

SSH-ключи на диске — уязвимость. Rundeck Key Storage хранит ключи в зашифрованном виде в БД или интеграции с HashiCorp Vault. Команда rd keys upload --path keys/project/myproject/deploy-key --type privateKey --file ~/.ssh/deploy_rsa загружает ключ в защищённое хранилище. В рамках внедрения мы настраиваем Key Storage и ротацию ключей по расписанию. Rundeck Key Storage в 3 раза безопаснее хранения ключей на диске — данные шифруются AES-256. Это критично для соответствия стандартам безопасности PCI DSS и SOC 2.

Сроки и стоимость внедрения

Базовое развёртывание с 10-15 job'ами и RBAC занимает 2-3 дня. Для сложной инфраструктуры (кластер, интеграция с Vault, CI/CD) сроки увеличиваются до 5-7 дней. Стоимость рассчитывается индивидуально после аудита. Мы предлагаем предварительную оценку за 1 день — проанализируем вашу инфраструктуру и подготовим точный план. Свяжитесь с нами для консультации. Опыт: 5+ лет работы с Rundeck, более 20 проектов автоматизации, гарантия SLA 99.9%.

Закажите внедрение Rundeck под ключ — получите централизованное управление задачами без доступа к SSH. Мы гарантируем сокращение времени на рутинные операции на 80% и полную прозрачность всех действий.