Развертывал ли Jira Configs

Опыт развертывания и управления конфигурациями Jira

Да, я неоднократно занимался развертыванием конфигураций Jira как для Jira Software, так и для Jira Service Management. Это критически важная задача для обеспечения стабильности, воспроизводимости и контроля версий инфраструктуры Atlassian. Моя работа была сосредоточена на превращении развертывания из ручного, подверженного ошибкам процесса в автоматизированный, идемпотентный и управляемый кодом (Infrastructure as Code, IaC).

Под "конфигурациями" в данном контексте я подразумеваю не просто файлы jira-config.properties, а весь спектр артефактов, определяющих состояние и поведение инстанса:

• Схемы проектов (Workflow, Issue Type, Screen, Field Configuration).
• Глобальные настройки (разрешения, уведомления, настройки почты, внешние интеграции).
• Конфигурация приложений и плагинов (например, ScriptRunner, Automation for Jira).
• Данные (проекты, группы пользователей, глобальные разрешения).

Методологии и инструменты

Для автоматизации этого процесса я использовал комбинацию следующих подходов и инструментов:

1. Infrastructure as Code (IaC) для базового развертывания

Для первоначальной установки Jira на виртуальные машины или контейнеризации использовались:

• Ansible для провижининга ВМ: установка Java, создание пользователей, настройка системных лимитов, деплой дистрибутива Jira.

  # Пример фрагмента Ansible-роли для установки Jira
  - name: Install Jira
    unarchive:
      src: "https://product-downloads.atlassian.com/software/jira/downloads/{{ jira_version }}.tar.gz"
      dest: /opt
      remote_src: yes
    register: jira_extracted
  
  - name: Create Jira user
    user:
      name: jira
      system: yes
      shell: /bin/bash
  
  - name: Set Jira home directory permissions
    file:
      path: "{{ jira_home }}"
      state: directory
      owner: jira
      group: jira
      mode: '0755'
  

• Docker & Docker Compose для контейнеризованных развертываний. Создание кастомных образов с предустановленными плагинами и конфигурациями.

  # Dockerfile на основе официального образа
  FROM atlassian/jira-software:latest
  
  # Копирование предварительно скачанных и лицензированных плагинов
  COPY plugins/*.jar /opt/atlassian/jira/atlassian-jira/WEB-INF/lib/
  
  # Копирование кастомных конфигов (например, для БД)
  COPY server.xml /opt/atlassian/jira/conf/
  USER root
  RUN chown jira:jira /opt/atlassian/jira/conf/server.xml
  USER jira
  

2. Управление конфигурацией через REST API и CLI Tools

После запуска инстанса основная работа велась через API для идемпотентного применения настроек.

• Atlassian CLI (Built-in) и REST API: Для автоматизации создания проектов, схем, добавления пользователей.

  # Пример создания проекта через CLI (в реальности чаще python + requests)
  # Это концептуальный пример
  jira --action createProject \
       --project "DEV" \
       --name "Development" \
       --lead "admin" \
       --template "Scrum software development"
  

    На практике чаще использовался **Python с библиотекой `requests`** для более гибкого скриптинга.

```python
import requests
from requests.auth import HTTPBasicAuth

JIRA_URL = "https://jira.example.com"
AUTH = HTTPBasicAuth("admin", "admin")

# Создание новой схемы workflow
workflow_data = {
    "name": "DEV Workflow",
    "description": "Automated deployment",
    "statuses": [...],
    "transitions": [...]
}
response = requests.post(
    f"{JIRA_URL}/rest/api/3/workflow",
    json=workflow_data,
    auth=AUTH,
    headers={"Content-Type": "application/json"}
)
```

• Terraform Provider for Jira (community): Хотя он не официальный, для декларативного описания некоторых сущностей (проекты, фильтры, настройки плагинов) это мощный инструмент.

  resource "jira_project" "devops_project" {
    key  = "DEVOPS"
    name = "DevOps Platform"
    lead = "jane.doe"
    project_type_key = "software"
    workflow_scheme = data.jira_workflow_scheme.scrum.id
    notification_scheme = data.jira_notification_scheme.default.id
    permission_scheme = data.jira_permission_scheme.default.id
  }
  

3. Бэкенд: Базы данных и хранилище

• База данных: Настройка и миграция с встроенной БД на внешнюю (PostgreSQL или AWS RDS/Aurora). Конфигурация пулов соединений в dbconfig.xml.
• Хранилище файлов (Shared Home): Настройка JIRA_HOME на сетевом хранилище (NFS, Amazon EFS, S3 через fuse-драйвер) для кластерных конфигураций.

Ключевые практики и решения проблем

1. Версионирование всего: Все конфигурационные скрипты, схемы workflows (в формате XML), Dockerfile, Ansible-роли хранились в Git. Изменения проходили через Pull Request и код-ревью.
2. Паттерн "Золотой образ" (Golden Image): Для ускорения развертывания создавался предварительно настроенный образ (AMI для AWS, Container Image), включающий обновления, лицензированные плагины и базовые конфигурации.
3. Плавные обновления (Zero-Downtime Upgrades): В кластерной конфигурации выводил ноды по одной из балансировщика нагрузки, обновлял и возвращал в строй.
4. Резервное копирование и DR: Автоматизированные бэкапы БД (через pg_dump или снапшоты RDS) и JIRA_HOME (в S3). Регулярное тестирование процедуры восстановления.
5. Интеграция в CI/CD пайплайн: Процесс развертывания конфигурации был частью пайплайна в Jenkins или GitLab CI. Например, при мерже в ветку prod автоматически запускался playbook Ansible, применявший изменения к production-инстансу.

Основные сложности, с которыми сталкивался:

• Отсутствие идемпотентности у некоторых операций через API, что требовало написания сложной логики "проверь, а потом создай/обнови".
• Зависимости между объектами (проект → схема → workflow) требовали четкого порядка выполнения скриптов.
• Миграция данных и конфигураций между инстансами (Dev → Stage → Prod) решалась через инструменты типа Atlassian's native backup/restore для данных и кастомные скрипты на основе API для конфигураций.

Таким образом, развертывание конфигураций Jira — это комплексный процесс, требующий глубокого понимания архитектуры продукта, навыков автоматизации и строгого следования принципам DevOps для обеспечения надежности и управляемости системы.