Миграция Jira Service Desk из «облака» на сервер

Не буду спорить, что использование SaaS-ов, и в частности Jira Service Desk Cloud, удобно и облегчает работу системным администраторам. В целях безопасности или более гибкого управления сервисом, которое не предоставляет «облако», может потребоваться перенос сервиса из «облака» на сервер организации.

Процесс миграции Jira Service Desk(JSD) можно условно разделить на три этапа:

  1. Подготовка резервной копии(бэкапа).
  2. Подготовка сервера. Установка программного обеспечения. Настройка.
  3. Развертывание бэкапа из «облака» на сервере.

К подготовке сервера можно отнести установку операционной системы на сервер, установку программного обеспечения, настройку. Сервер может быть как физическим, так и виртуальным. В моем случае будет использоваться CentOS 7, а программное обеспечение будет автоматически устанавливаться простым скриптом. Установка CentOS 7 описана не будет. Будем считать, что ОС уже установлена.

Технические требования к серверу можно посмотреть по ссылке.


1) Подготовка резервной копии.

Сделаем бэкап нашего «облачного» JSD.

Заходим в системные настройки «облачного» JSD, вкладка «Управление резервным копированием.»

image

Сделаем резервную копию сервера.

Выбираем полную миграцию сервера и загружаем резервную копию. На резервное копирование есть ограничение в 48 часов. То есть, после создания бэкапа, следующий можно будет сделать только через 2 дня.

2) Подготовка сервера. Установка программного обеспечения. Настройка.

Скрипт можно скачать тут любым удобным для вас способом.

Запускаем терминал или подключаемся к серверу по SSH.

Добавим права на выполнение скрипту командой:

sudo chmod +x soft_install_c7.sh

Запускаем скрипт командой:

sudo bash soft_install_c7.sh

image

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

Кроме установки ПО скрипт создаст базу данных(БД) в Postgre Sql

При создании БД скрипт может ругнуться на доступ. Ничего страшного, база будет создана.

image

После завершения исполнения скрипта можно зайти в консоль Postgre Sql и убедится в этом.

image

В процессе исполнение скрипта необходимо будет ввести e-mail и пароль для настройки pgAdmin 4 и ответить на несколько вопросов.

image

Бинарный файл для установки JSD скачается и запустится автоматически. Необходимо будет ответить на несколько вопросов.

image

Порты для работы JSD можно оставить по умолчанию или выбрать другие.

Правила брандмауэра для корректной работы Apache, pgAdmin 4 и JSD добавятся автоматически. По умолчанию скрипт откроет порты 80, 8080 и 5432.

Добавить порт по своему усмотрению можно командой:

sudo firewall-cmd --zone=public —add-port=порт/tcp —permanent

Удалить порт можно командой:

sudo firewall-cmd --zone=public --remove-port=порт/tcp --permanent

Посмотреть все правила брандмауэра можно командой:

sudo firewall-cmd —list-all или sudo iptables -L -n -v —line-numbers

Для перезагрузки брандмауэра используйте команду:

sudo firewall-cmd --reload

image

Исполнение скрипта завершится сообщением — DONE!

В завершении подготовки сервера можно подключить pgAdmin 4 к серверу Postgre Sql через адрес локальной петли — 127.0.0.1, или как вам больше нравится. Измените настройки в pg_hba.conf на актуальные для вашей конфигурации, если это необходимо.

image

Логин и пароль для базы можно посмотреть в скрипте:

База: jsd_db
Пользователи:
Логин:jira Пароль:123
Логин:postgres Пароль:postgres

Можете изменить на свои значения перед запуском скрипта или после, непосредственно в Postgre Sql.

Не забудьте отключить SSL, если вы его не используете. Если pgAdmin 4 не будет соединяться с сервером, попробуйте перезагрузить службу.

sudo service postgresql-11 restart 

Информацию по базам данных вы можете найти в документации Atlassian.

3) Развертывание бэкапа из «облака» на сервере.

В браузере переходим по ip-адресу сервера с указанием порта. По умолчанию порт — 8080. У меня это выглядит так 192.168.1.25:8080

Вы должны увидеть следующее.

image

Я выбираю пункт «выполнить настройку самостоятельно» и на следующей странице указываю настройки для базы данных. После подключение начнется создание базы данных — это займет некоторое время.

image

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

image

Выбираем «импортировать данные».

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

image

Можно сгенерировать триальную лицензию на месяц на сайте Atlassian. Для этого нужно будет зарегистрироваться на сайте. При генерации лицензии необходимо выбрать jira service desk (server).

Перед восстановлением JSD из бэкапа разместите бэкап на сервере в каталоге /var/atlassian/application-data/jira/import

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

image

Вас приветствует страница входа, если все прошло хорошо. Осталось ввести логин и пароль.

image

По умолчанию логин — sysadmin, пароль — sysadmin.

После первого логина вы можете увидеть сообщения об обновлении, также необходимо будет выбрать язык и сделать настройки аккаунта(если необходимо). Чтобы были доступны проекты и задачи восстановленные из бэкапа, необходимо дать права учетной записи по умолчанию, либо поменять пароли учетным записям, которые были перенесены в бэкапе.

На этом перенос JSD из «облака» на сервер закончен.

Еще почитать о миграции можно тут.

Спасибо за внимание, всего хорошего и удачи!

Комментарии 12

    +1

    К сожалению уже бесмысленно переезжать на свой сервер…
    Atlassian сворачиват разработку и поддержку своих серверных продуктов(Jira и Confluence )
    И с февраля 2021 года прекращает продажу серверных лицензий.
    Будет только облачная версия Jira и Confluence.


    https://www.atlassian.com/migration/key-offering-changes?tab=server-key-changes#key-changes

      0
      К сожалению? Отлично же — чем меньше On Premise в интерпрайзе — тем лучше, пример использования IE(6) и Java очень показателен.
        0

        Конечно к сожалению!


        Теперь у меня нет варианта — с облаком доступ к купленному мною сервису будут зависеть не только от моей сети (сейчас это минимальная лицензия на сервере в соседней комнате), а от провайдеров, инженеров атлассиана и воли политиков и санкций (и организации вроде роскомпозора туда же). А ещё я, конечно, верю, что работники атлассиана желают только всеобщего блага и не дадут мои личные данные никому. Но ограничить кто и куда сможет подключаться и сливать данные фаерволлом уже не смогу...

          –2
          Ну т.е теперь пользователи смогут по нормальному использовать сервис вместо неудобных VPN и глупых ограничений от ИБ, да? Т.е как Zoom vs S4B/Lync?
            0

            Теперь хакеры смогут по нормальному ломать сервис и тащить данные, а не тыкаться в неудобный VPN.


            А так да.

          0

          Кому лучше?

            0

            Желаю вам быть материально ответственным за сервис с жёстким SLA, целиком и полностью зависящим от облака.

            0

            Вы не правы. Уходят только редакция стандарт. Датацентр никуда делся и все так же продается. Просто у нее ценник… немножечко другой =)

            0
            В прошлом году столкнулся с переносом одного проекта в Jira (ServiceDesk по сути надстройка над Jira, хотя может устанавливаться и отдельно). Столкнулся с тем, что если проект в облаке уже NextGen, а его люди выбрали по умолчанию, т.к. на тот момент никуда переезжать не собирались, к тому же задействовали имеющийся там функционал Roadmap. Вот его перенос это был нечто, к тому же выяснилось что у них отдельная команда поддержки для облака, отдельная для Selfhosted, которые с честью поиграли в игру «ошибка не на нашем конце, отправляем ваш тикет в ...», в итоге перетащили практически вручную, т.к. весь лимит времени съела переписка с поддержкой, а владельцы проекта оказались еще и демотивированы отсутствием функционала Roadmap, который Atlassian так и не сподобился добавить в серверную версию.

            Касательно развертывания Jira я предложил бы просто использовать… докер, просто и быстро, легко обновлять, для небольшой команды проблем вообще не видел, одни плюсы.
              0
              С Атлассиан не все так просто, как кажется. Но маркетинг на высоте — это надо признать.
              Кстати, насколько удалось выяснить Nextgen проекты нельзя даже забекапить для сервера. Если есть хоть один nextgen-проект — бекап не получится сделать. Пришлось перетаскивать задачи в другие проекты и удалять Nextgen-ы. Тех.поддержка самих Атлассианов и их агентов оставляет желать лучшего и все стоит денег. Сталкивался с таким, что поддержка не решала проблему и я решил ее сам. Может об этом напишу в следующем посте.

              Что касается докера — как раз использовал его для тестирования. Удобно. Но надо понимать, что человек после тебя может не знать докер. К тому же бывают строгие т.з. и стандарты компании, которые не предусматривают докер.
                0
                Что касается докера — как раз использовал его для тестирования. Удобно. Но надо понимать, что человек после тебя может не знать докер. К тому же бывают строгие т.з. и стандарты компании, которые не предусматривают докер.


                Учитывая тренд на микросервисы маловероятно, да и скорее спасибо скажет, т.к. проще обновить докер, если конечно все честно вынес на volume, чем отдельно системный софт и продукты Jira. Тут у каждого свой путь!-)
                  0

                  Надо просто не забыть добавить Докер в требования на вакансию человека после себя

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое