Надстройка до най-новата Jira с най-новата версия на MariaDB Server

При разработването на MariaDB Server ние използваме Atlassian Jira като софтуер за проследяване на проблеми и проекти, но и за планиране. Ние използваме Jira от 2012 г., когато мигрирахме от Launchpad. В този момент използвахме Jira в облака на Atlassian, но няколко години по-късно решихме да инсталираме собствен екземпляр на Jira и да го стартираме върху MariaDB Server. По-рано написах публикация в блог за това.

Jira върху MariaDB Server все още НЕ се поддържа. Jira поддържа MySQL, но официално все още не MariaDB. Разбира се, искаме възможно най-много софтуерни продукти, които да поддържат MariaDB Server, за да улесним нашите клиенти и потребители. Не сме сами с мисленето по този начин. Искането за поддръжка на MariaDB сървър в Jira се намира тук, а по-широкото искане за поддръжка на MariaDB сървър в продуктите на Atlassian като цяло се намира тук. Добавете своя глас, за да се надяваме, че MariaDB Server ще бъде официално поддържан скоро. Но работата е там, че въпреки че не се поддържа официално, комбинацията от Jira и MariaDB работи чудесно. Наскоро надстроихме до най-новата Jira и най-новата версия на MariaDB.

Актуализиране на добавките на Jira

Jira има много плъгини и версиите на плъгини трябва да са съвместими с версията на Jira, която работи. Има инструмент, включен в Jira, Jira Update Check за добавки, който се намира в URL адреса /plugins/servlet/upm/check. Използвайте този инструмент, за да актуализирате всички добавки до версии, които ще се поддържат във версията на Jira, до която ще надстроите.

Спиране на достъпа до Jira

Нека да продължим с действителното надграждане. Започнете с това да направите Jira недостъпен за потребителите, като предоставите страница за поддръжка на всеки, който се опитва да получи достъп до Jira. Това се прави лесно с Nginx. В местоположението директива в конфигурацията на Nginx, проверете за файл за поддръжка и ако бъде намерен, го покажете за всички URL адреси.

...
location / {
if (-f $document_root/maintenance.html) {
return 503;
}
...
error_page 503 @maintenance;

местоположение @maintenance {
пренапишете ^(.*)$ /maintenance.html break;
}

Резервно копие на база данни и директории

Преди да започнете надстройка, разбира се, трябва да се уверите, че съществуват резервни копия. Когато става въпрос за Jira, човек трябва да има пълно архивиране на базата данни и на директориите, които Jira използва за съхранение на прикачени файлове и изображения на потребителски аватар. Имахме инструмент за архивиране, работещ на сървъра, произвеждащ пълни архиви на дневна база. Освен това направих и дъмп на база данни, използвайки помощната програма за изхвърляне.

Архивиране на база данни с помощната програма dump:

$ mysqldump -u username -p databasename > jiradb20180907.sql
$ tar -zcvf jiradb20180907.tar.gz jiradb20180907.sql

Архивни прикачени файлове и аватари:

$ tar -zcvf attachments20180908.tar.gz /data/jira/data/attachments/
$ tar -zcvf avatars20180908.tar.gz /data/jira/data/avatars/

Копирайте архивните файлове на друг сървър, в случай че нещо се обърка в процеса на надстройка.

Надстройка на ОС

Нашият Jira сървър работеше с Ubuntu 14.04 и докато надграждахме софтуера, ние също искахме да надстроим операционната система. Няма да навлизам в подробностите за надстройката на Ubuntu, но по принцип пуснах do-release-upgrade два пъти, за да накарам сървъра до Ubuntu 18.04. Имаше няколко неща, които трябваше да направя. Трябваше да създам файла /etc/update-manager/release-upgrades.d/unauth.cfg и да добавя следното. Това трябваше да позволи на библиотеки, които процесът на надграждане на версията не може да удостовери, които бяха библиотеки Galera и MariaDB.

[Distro]
AllowUnauthenticated=yes

След надстройката премахнете файла unauth.cfg.

В моя случай надстройката (от 16.04 на 18.04) промени конфигурацията на SSH сървъра и вече не можех да SSH към сървъра. Предполагам, че избрах „Да“ някъде, където не трябваше. За щастие имах достъп до конзолата и конфигурирах SSH ръчно.

Nginx се надгражда по време на надстройка на ОС. Проверете, като изпълните командата:nginx -v

Надстройка на MariaDB сървър

В нашия случай имахме инсталиран MariaDB Server 10.1. Това бяха стъпките, за да го получите до последната стабилна версия на GA на MariaDB Server:

• Спиране на MariaDB Server 10.1:sudo service mysql stop
• Деинсталиране на 10.1:sudo apt премахва mariadb-server
• Добавете хранилище на MariaDB Server 10.2. Ще използвам скрипта за настройка на хранилището mariadb.com:
  curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash -s — –mariadb-server-version=mariadb-10.2
  За повече информация относно скрипта на хранилището, моля, вижте документацията.
• Инсталиране 10.2:sudo apt инсталира mariadb-server
• Проверете дали MariaDB Server 10.2 работи и работи
• Спри MariaDB:sudo service mysql stop
• Деинсталиране на 10.2:sudo apt премахва mariadb-server
• Добавете хранилище на MariaDB Server 10.2. Отново ще използвам скрипта за настройка на хранилището mariadb.com:
  curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash -s — –mariadb-server-version=mariadb-10.3
• Инсталиране 10.3:sudo apt инсталира mariadb-server
• Проверете дали MariaDB 10.3 работи и работи. Проверете този datadir в /etc/mysql/my.cnf сочи към директорията, в която имате вашите файлове с база данни

JDBC, MariaDB Connector/J актуализация

Преди да преминем към надграждане на самата Jira, нека първо да актуализираме JDBC драйвера, за да не се налага да рестартирате Jira няколко пъти. Актуализирането на MariaDB Connector/J е направо. Вземете най-новата версия на Connector/J от downloads.mariadb.com, поставете я в директорията lib на Jira и премахнете старата:

$ wget https://downloads.mariadb.com/Connectors/java/connector-java-2.3.0/mariadb-java-client-2.3.0.jar
$ mv /opt/atlassian/jira/lib/mariadb-java-client-2.1.2.jar ~
$ mv mariadb-java-client-2.3.0.jar /opt/atlassian/jira/lib/

Надстройка на Jira

Накрая надстройте Jira с инсталатора на Jira:

• Инсталаторът на Jira е достъпен тук:https://www.atlassian.com/software/jira/download
• Резервно копие на jira конфигурация:sudo tar -zcvf conf20180909.tar.gz /opt/atlassian/jira/conf
• Stop Jira:sudo service jira stop
• Стартиране на надстройката:sudo ./atlassian-jira-software-7.12.1-x64.bin
• Следвайте инструкциите на инсталатора
• Опитайте да стартирате Jira:sudo service jira start (което няма да работи, тъй като server.xml е заменен)
  

Както беше казано в последната стъпка, Jira няма да стартира, защото инсталаторът е заменил конфигурационния файл server.xml. Сега трябва да го промените обратно към вашата конфигурация. Лесен начин да го направите е да направите разлика между server.xml, който сте имали преди, и този нов. След като конфигурацията е на място, стартирайте Jira.

Също така не забравяйте да премахнете (или преименувате) файла support.html, използван от Nginx, в случай че сте използвали този начин за поставяне на Jira в режим на поддръжка.

След като Jira стартира и работи отново, всичко работи добре. Няколко дни по-късно научихме, че има едно нещо, което не работи както преди. Използваме Tableau за отчитане и сме инсталирали добавката „Всичко в едно Tableau Connector за Jira“. Оказа се, че тази добавка генерира SQL SELECT заявки, които имат колоната ROWS в тях. ROWS е запазена дума в 10.3, така че когато се иска колона, наречена по този начин, трябва да поставите отметка обратно на името, т.е. „ROWS“. За щастие компанията зад тази добавка също искаше да се увери, че добавката работи за нас и след като открихме причината, те ни предоставиха нова версия на добавката няколко часа по-късно.

Има още едно нещо, което трябваше да направя. Използвахме предишна архивна версия, която не е съвместима с MariaDB Server 10.3. Препоръчваме ви да използвате MariaDB Backup за вашите архиви. Темата заслужава отделна публикация в блога и ще стигна до нея малко по-късно.

След надстройката ни през септември, най-новата версия на Jira работи и работи през цялото време върху най-новата версия на MariaDB, обслужваща потребителите на Jira на MariaDB.