Nous aidons régulièrement nos clients à planifier et à mettre en œuvre des solutions de haute disponibilité (HA) sur site et dans le cloud et dans des réseaux étroits (espacés) / hybrides, et pour une variété d’outils – par ex. Atlassian Bitbucket, GitLab, Jira, Artifactory, SonarQube, GitHub et plus encore.
On nous demande souvent «quelle solution HA est la meilleure dans le domaine de la gestion du code et de la gestion de la configuration logicielle – GitLab ou Bitbucket?»
En fait, le sujet de HA lui-même est un sujet complexe, pour plusieurs raisons:
- Il pourrait y avoir de nombreuses façons de mettre en œuvre HA
- La solution dépend des besoins de chaque client (est-ce uniquement à des fins d’équilibrage de charge ou pour éviter un déni de service?
- Cela dépend du nombre de points de défaillance uniques que le client est prêt à absorber (voire pas du tout)
- Cela dépend également du budget (plus la disponibilité est «élevée», plus il faut de budget)
Et parfois, les clients disent qu’ils veulent de la haute disponibilité, mais en pratique, ils veulent simplement dire une reprise après sinistre (DR)…
Pour y répondre de manière simple, je prouverai l’affirmation suivante:
Étant donné la solution HA de Bitbucket («Data Center») comme expliqué ici, et étant donné la solution HA de GitLab comme expliqué ici, GitLab, en utilisant le package Omnibus, peut fournir HA (pour la redondance et la haute disponibilité) pour tous les composants afin d’obtenir une HA horizontale pour l’ensemble solution, alors que Bitbucket ne peut pas fournir de redondance pour tous les composants.
Preuves:
- Dans Bitbucket, le code lui-même, en tant que dépôt git, repose sur un NFS partagé (comme indiqué dans le diagramme du lien ci-dessus). En cas de panne de NFS ou de perte d’informations, tout sera perdu.Dans GitLab, à partir de la version 13.0 (sortie en mai 2020), vous pouvez créer un Gitaly Cluster, il existe donc plusieurs copies du dépôt git et il n’y a pas un seul point de défaillance (explication détaillée dans l’article que nous avons écrit alors – ici) De plus, exécuter git sur NFS aura généralement des problèmes de performances (un problème connu).
- Étant donné que les informations de chaque session sont stockées sur le serveur d’applications de Bitbucket, des sessions peuvent être perdues lors du basculement vers un autre serveur (basculement). Cela signifie que les sessions seront perdues et que tous les utilisateurs devront se reconnecter, tandis que certaines informations seront complètement perdues (ceci est explicitement mentionné dans l’article Atlassian ci-dessus).GitLab utilise Redis dans la configuration HA afin qu’une telle situation ne se produise pas.
- La solution standard d’Atlassian fournit une base de données partagée – qui est un point de défaillance unique.Le package Omnibus de GitLab prend en charge la haute disponibilité des bases de données afin de pouvoir l’implémenter plus facilement.
- GitLab HA peut multiplier chaque composant pour une mise à l’échelle (comme expliqué dans le diagramme ci-dessus)
- Les deux produits fournissent une solution HA active / active (bien qu’avec des différences significatives comme indiqué ci-dessus)
- GitLab est souvent utilisé comme un outil CI / CD (en plus d’être un outil SCM), et la solution HA fournit également une couverture complète pour les aspects CI / CD (tels que la haute disponibilité des pipelines en cours d’exécution et le déploiement).
- Bitbucket on-prem, en revanche, n’inclut pas de solution CI / CD – il y a donc un autre avantage significatif à GitLab ici: en mettant en place une solution HA, il est possible de «faire d’une pierre deux coups».
- Il existe une tendance à confondre les solutions HA avec les solutions DR. Par conséquent, la mise en miroir intelligente de Bitbucket expliquée ici n’est pas une solution HA. Il donne une solution DR partielle de réplication des référentiels, mais sans les métadonnées qui les accompagnent.
- Dans GitLab, une solution DR plus complète peut être mise en œuvre à l’aide de «GitLab Geo», qui donne également des informations DR autour du dépôt telles que les comptes utilisateurs, les problèmes, les demandes de fusion, les groupes, les données de projet et plus encore.
L’article ci-dessus ne doit pas être interprété comme un conseil général pour tous les types de clients et d’utilisateurs.
Il peut y avoir des différences d’un client à l’autre (contactez-nous pour recevoir nos recommandations individuelles couvertes par la garantie).
Mise à jour 10.26.2020:
Comme le dernier plan d’Atlassian est de déprécier les versions de Bitbucket Server (y compris Jira Server) et de se concentrer sur les solutions cloud, et puisque la version Bitbucket Data Center repose en fin de compte sur la version Server (comme écrit ici: “Bitbucket Data Center et Bitbucket Server sont en fait les même version de Bitbucket »), l’avenir de la version Data Center est trouble, et nous ne savons pas ce que l’entreprise en fera à l’avenir.
P.S Les clients ont également demandé quelle solution serait la moins chère en termes de coûts de licence et de prix (et TCO). Je ne répondrai pas ici car les vendeurs changent très souvent les prix. Nous nous ferons un plaisir de vous répondre en détail lorsque vous nous contacterez.
EGDS ALMtoolbox est le représentant officiel de GitLab et de Hashicorp en France.
Contactez nous pour un devis ou pour une question:+33 (0)1 84 17 53 28
ou par email : devops.fr@almtoolbox.com
