Jira DataCenter - qu'est-ce que c'est? Comment ça marche? Comment déployer?

Présentation

Avec la diffusion de la philosophie Agile, les informaticiens russes acquièrent chaque année de plus en plus d'expertise et de compétences dans le domaine de la personnalisation et de la gestion des produits pour les équipes de développement, dont la plus populaire reste Jira. Cependant, travailler avec sa version la plus ancienne, la plus productive et la plus accessible - Jira Data Center - soulève toujours beaucoup de questions. Dans cet article, je parlerai de certains des principes et mécanismes du Jira DataCenter que nous appliquons dans la pratique. Je vais commencer par une histoire sur la structure du cluster Jira.

Qu'est-ce qu'un Jira DataCenter?

Jira DataCenter est essentiellement une version serveur, mais avec la possibilité d'utiliser une base de données commune et un index partagé.

Il est important de comprendre que le Jira DataCenter lui-même, en tant que produit et en tant qu'application, NE propose PAS de tolérance aux pannes et d'équilibrage de charge. Les modules et les systèmes en sont responsables, auxquels le produit Atlassian n'a aucun lien.

En d'autres termes, Atlassian fournit un support pour travailler dans un cluster, mais le clustering lui-même est implémenté par des moyens externes, dont le choix est assez riche.

Des descriptions détaillées des produits sont disponibles sur le site Web d'Atlassian .

Il existe plusieurs options de construction:

1. Sur sa propre infrastructure
2. Sur Amazon Cloud (AWS)
3. Dans le cloud de MS (Azure)

Cet article décrit une solution pour votre propre infrastructure.

Quels problèmes le Jira DataCenter résout-il?

Jira Data Center vous aide à atteindre les objectifs suivants:

1. Implémentation de la tolérance aux pannes.
2. Assurer un fonctionnement stable sous une charge élevée. Une charge élevée fait référence à des instances à grande échelle / d'entreprise, selon le Guide de dimensionnement Jira .
3. Assurer un fonctionnement continu lorsque la maintenance est nécessaire. À ce stade, j'habiterai séparément. L'application doit souvent être mise à jour et toutes les entreprises n'ont pas la possibilité de le faire rapidement et de manière invisible pour les utilisateurs. Ce problème est résolu en regroupant et en utilisant ce que l'on appelle le schéma de mise à jour Zero Downtime .

Ces problèmes sont résolus grâce au clustering et à une architecture évolutive.

Quels sont les composants d'un Jira DataCenter?

Comme vous pouvez le voir dans la figure ci-dessous, le cluster Jira DataCenter est une collection de plusieurs machines dédiées.


Figure 1. Architecture du centre de données Jira

1. Nœuds d'application (nœuds d'application ou nœuds de cluster). Ils acceptent et traitent toute la charge de travail et les demandes. Le rôle des nœuds est joué par des serveurs ordinaires, avec un contenu et une application installés identiques, ainsi qu'un système de fichiers partagé monté.
2. Système de fichiers (système de fichiers partagé) avec des fonctionnalités standard pour l'importation / exportation de fichiers, plug-ins, mise en cache, etc. Un serveur de fichiers est également un serveur distinct sur lequel un dossier ou une ressource partagée est créé, qui est monté sur les nœuds et utilisé pour les fichiers partagés.
3. Base de données partagée Le serveur de base de données est également, dans ce cas, un serveur distinct et peut être construit sur MS SQL, PostgreSQL, MySQL, Oracle.
4. Équilibreur de charge Il distribue les demandes des utilisateurs et les transmet aux nœuds, et si l'un d'eux échoue, l'équilibreur redirige ses demandes vers d'autres nœuds presque instantanément. Grâce à son travail, les utilisateurs ne remarquent même pas la défaillance d'un nœud. Nous parlerons ci-dessous du travail de l'équilibreur séparément.

Topologie de cluster de centre de données Jira

Je vais vous donner les principes de base selon lesquels un cluster est construit dans JDC:

• Les instances Jira partagent une base de données commune;
• L'index Lucene est répliqué en temps réel et stocké localement par instance;
• les pièces jointes sont stockées dans un référentiel commun;
• Les instances Jira surveillent la cohérence du cache;
• à tout moment, plusieurs instances peuvent être actives en même temps;
• des verrous de cluster sont disponibles;
• l'équilibreur est configuré pour rediriger les demandes uniquement vers les nœuds actifs, alors qu'il ne doit pas transférer les demandes vers les nœuds inactifs et ne peut pas non plus adresser toutes les sessions à un nœud.

Tous les nœuds sont divisés en actifs et passifs. Les nœuds actifs diffèrent en ce qu'ils:

• Traiter les demandes
• Effectuer des processus et des tâches d'arrière-plan
• Les tâches planifiées peuvent être configurées sur un ou plusieurs d'entre eux.
• Dans tous les scénarios pratiques, la situation ressemblera à l'utilisation d'un serveur Jira standard. Par conséquent, les nœuds passifs ne traitent pas les demandes et n'exécutent pas de tâches, mais servent à assumer une charge de travail à court terme (par exemple, au démarrage du système, en chargeant des plugins et / ou en indexant).

La figure ci-dessous montre le fonctionnement du cluster Jira


Figure 2. Un schéma simplifié de l'architecture

À propos des équilibreurs de charge

L'équilibreur peut être n'importe quel serveur sur lequel un proxy inverse est installé ou un périphérique physique. Je vais donner les exemples les plus célèbres d'équilibreurs.

1. Équilibreurs matériels:

• Cisco
• Genévrier
• F5

2. Équilibreurs de logiciels:

• mod_proxy (Apache) - un serveur proxy pour Apache HTTP Server qui prend en charge les protocoles les plus courants et plusieurs algorithmes d'équilibrage de charge différents.

• Varnish est un serveur proxy inverse HTTP et un accélérateur, il est conçu pour les sites à fort trafic. Contrairement à d'autres, ce n'est qu'un serveur proxy et un équilibreur de charge du trafic HTTP. En particulier, Varnish utilise Wikipedia, NY Times, The Guardian et de nombreux autres grands projets.

• Nginx - le serveur Web numéro 1 en popularité parmi les équilibreurs de charge et les solutions proxy pour les sites à fort trafic. Il évolue activement, le constructeur propose une version gratuite et corporate. Utilisé sur de nombreux sites les plus visités au monde, par exemple, WordPress.com, Zynga, Airbnb, Hulu, MaxCDN.

• Nginx Plus - en fait, la version d'entreprise payante susmentionnée de Nginx.

• HAProxy est un outil open source gratuit qui fournit des capacités d'équilibrage de charge et de proxy pour les protocoles TCP / HTTP. Il est rapide et consomme peu de ressources système, compatible avec Linux, Solaris, FreeBSD et Windows.

Une bonne comparaison des serveurs proxy peut être trouvée ici à ce lien .

Procurations directes et inverses

Les équilibreurs de charge peuvent fonctionner aussi bien en proxy direct qu'en reverse proxy. La différence a été bien décrite par l'auteur de ce commentaire sur stackoverflow:

1. «Proxy de transfert» (proxy de transfert). L'événement proxy dans ce cas est que le «proxy direct» récupère les données d'un autre site Web au nom du demandeur d'origine. À titre d'exemple, je vais vous donner une liste de trois ordinateurs connectés à Internet.

X = ordinateur ou ordinateur client sur Internet
Y = site Web proxy, proxy.example.org
Z = le site Web que vous souhaitez visiter est www.example.net
Vous pouvez généralement vous connecter directement à partir de X -> Z. Cependant, dans certains scénarios, il est préférable de Y -> Z au nom de X, qui ressemble à ceci dans une chaîne: X -> Y -> Z.

2. "Proxy inversé" (Proxy inversé). Imaginez la même situation, seul le site Y est configuré avec un proxy inverse. Vous pouvez généralement vous connecter directement à partir de X -> Z. Cependant, dans certains scénarios, l'administrateur de Z est préférable de restreindre ou d'interdire l'accès direct et de forcer les visiteurs à passer par Y en premier. Ainsi, comme précédemment, nous obtenons les données reçues par Y -> Z au nom de X, qui est comme suit: X -> Y -> Z.
Ce cas diffère du «proxy direct» en ce que l'utilisateur X ne sait pas qu'il accède à Z car l'utilisateur X voit qu'il échange des données avec Y. Le serveur Z est invisible pour les clients, et seul le serveur proxy externe Y est visible de l'extérieur . Le proxy inverse ne nécessite pas de configuration côté client. Le client X pense qu'il n'interagit qu'avec Y (X -> Y), mais la réalité est que Y redirige la connexion entière (X -> Y -> Z à nouveau).

Ensuite, nous envisagerons de travailler avec un équilibreur de logiciels.

Quel équilibreur logiciel choisir?

D'après notre expérience, Nginx est le meilleur choix parmi les équilibreurs de logiciels car il prend en charge le mode sessions Sticky et est également l'un des serveurs Web les plus couramment utilisés, ce qui implique une bonne documentation et une popularité suffisante parmi les spécialistes informatiques.

La session persistante est une méthode d'équilibrage de charge dans laquelle les demandes des clients sont envoyées au même serveur de groupe. Nginx a une méthode collante qui utilise des cookies pour équilibrer, mais uniquement dans la version commerciale. Mais il existe un moyen gratuit - l'utilisation de modules externes.

Le module crée un cookie et rend ainsi chaque navigateur unique. Ensuite, un cookie est utilisé pour rediriger les demandes vers le même serveur. S'il n'y a pas de cookie (par exemple, à la première demande), le serveur est sélectionné au hasard.
Vous pouvez en savoir plus sur la méthode collante sur ce lien , ainsi que dans ce Habrapost .

Et maintenant, passons à la partie pratique ...

Instructions pour créer un cluster Jira DataCenter

Pour le clustering, vous pouvez utiliser une instance existante avec Jira installée ou une nouvelle. Dans notre exemple, l'installation de nouvelles instances sur différents OS sera décrite (pour démontrer la polyvalence du système).

1. Commençons par le serveur de base de données. Vous pouvez utiliser à la fois l'existant et en créer un nouveau. Encore une fois, à titre d'illustration, Windows Server 2016 + PostgreSQL 9.4 a été sélectionné. Installez le système d'exploitation, installez le serveur PG, installez l'administrateur PG, ajoutez l'utilisateur et la base de données.

2. Créez le premier nœud sur le système d'exploitation Ubuntu 16.04 LTS. Installez les packages nécessaires, les mises à jour du référentiel.

3. Téléchargez et installez Jira DataCenter, lancez, configurez la base de données (au cas où Atlassian aurait un guide détaillé).

4. Désactivez Jira, désactivez le nœud.
service arrêt jira

5. Pour d'autres manipulations, il est préférable de désactiver temporairement l'exécution automatique de Jira:
update-rc.d -f jira supprimer

6. Nous clonons le nœud éteint.

7. Démarrez le premier nœud, désactivez Jira (par défaut, Jira après l'installation est définie sur l'exécution automatique).

8. Exécutez le deuxième nœud, désactivez Jira.

9. Créez une instance distincte pour l'équilibreur. J'ai choisi Ubuntu 16.04 car il est assez rapide, simple et ne nécessite pas de coûts supplémentaires sous forme de licences.

10. Installez nginx (l'exemple utilisé la version 1.13.4).

11. Téléchargez et décompressez nginx-sticky-module-ng:
git clone bitbucket.org/nginx-goodies/nginx-sticky-module-ng.git

12. Préparez nginx pour la recompilation et l'ajout d'un module.

13. Compilez nginx avec le module nginx-sticky-module-ng. Dans mon cas, la ligne de compilation s'est révélée comme ceci:
./configure --prefix = / etc / nginx --sbin-path = / usr / sbin / nginx --modules-path = / usr / lib / nginx / modules --conf-path = / etc / nginx / nginx. conf --error-log-path = / var / log / nginx / error.log --http-log-path = / var / log / nginx / access.log --pid-path = / var / run / nginx. pid --lock-path = / var / run / nginx.lock --http-client-body-temp-path = / var / cache / nginx / client_temp --http-proxy-temp-path = / var / cache / nginx / proxy_temp --http-fastcgi-temp-path = / var / cache / nginx / fastcgi_temp --http-uwsgi-temp-path = / var / cache / nginx / uwsgi_temp --http-scgi-temp-path = / var / cache / nginx / scgi_temp --user = nginx --group = nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module - -avec-http_flv_module --avec-http_gunzip_module --avec-http_gzip_static_module --avec-http_mp4_module --avec-http_random_index_module --avec-http_realip_module --avec-http_secure_link_module --avec-http_secure_link_module --avec-http_sl -with-http_sub_module --with-ht tp_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt = '- g -O2 -fstack-protector - param = ssp-buffer-size = 4 -Wformat -Werror = format-security -Wp, -D_FORTIFY_SOURCE = 2 -fPIC '--with-ld-opt =' - Wl, -Bsymbolic-functions -Wl, -z, relro -Wl, -z, maintenant -Wl, - as-needed -pie '--add-module = / usr / local / src / nginx-sticky-module-ng

14. Recherchez le fichier /etc/nginx/nginx.conf, copiez-le dans .bak, configurez nginx pour inverser le mode proxy.

15. Ensuite, nous avons besoin d'un serveur de fichiers (de préférence également tolérant aux pannes). Par exemple, j'ai choisi un serveur Windows, où j'ai créé une boule NFS.

16. Sur chaque nœud, nous installons des packages pour la prise en charge NFS:
apt-get install nfs-common

17. Créez le dossier / media / jira et exécutez:
chmod -R 0777 / media / Jira

18. Montez la boule NFS en tant que boule partagée (il est nécessaire de la monter non pas dans le dossier racine, mais, par exemple, dans / media / jira) - EVERY NODE

19.1. De plus, il est possible d'effectuer soit un montage manuel (simple):
sudo mount -t nfs -O uid = 1000, iocharset = utf-8 xx.xx.xx.xx: / jira / media / jira
où xx.xx.xx.xx est l'adresse IP du serveur avec la boule NFS

19.2. Ou montage automatique immédiat (au démarrage du système d'exploitation):
mcedit / etc / fstab
À la fin, vous devez ajouter la ligne:
192.168.7.239:/jira / media / jira nfs user, rw 0 0
Ensuite, enregistrez et quittez.

20. Attribuez l'ID: le premier nœud node1, sur le deuxième node2 et ainsi de suite.
#Cet ID doit être unique sur l'ensemble du cluster
jira.node.id = node1
# L'emplacement du répertoire personnel partagé pour tous les nœuds Jira
jira.shared.home = / media / jira

21. Exécutez la jira sur le premier nœud
service jira start
vérifier:
allez dans système -> infos système -> recherchez le cluster ON et le numéro de nœud.

22. Configurer l'équilibrage nginx

23. Depuis auparavant, nous avons désactivé le démarrage automatique de Jira sur les nœuds, puis nous pouvons l'activer avec la commande:
update-rc.d -f jira enable

24. Nous vérifions le fonctionnement du cluster et ajoutons des nœuds si nécessaire.

Ordre de démarrage du cluster

1. Activer le serveur de système de fichiers partagé
2. Activer l'équilibreur de charge
3. Activez node1
4. Activez node2
5. ...

Ordre d'arrêt du cluster

1. Arrêtez Jira sur les deux nœuds avec la commande de service Jira stop
2. Désactivez le nœud 2
3. Désactivez le nœud 1
4. Désactivez l'équilibreur de charge
5. Désactivez le serveur de système de fichiers

C’est tout ...

Bien sûr, la méthode décrite n'est pas la seule vraie. Ce n'est là qu'un moyen de mise en œuvre.

J'exprime ma gratitude à mes collègues pour leur aide dans la préparation du matériel.
Commentez, posez des questions et merci de votre attention.