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% і повну прозорість всіх дій.