J'installe un serveur GitLab dans mon entreprise et maintenant j'y ajoute GitLab CI.
Avant de commencer cette tâche, j'aimerais comprendre s'il y a des inconvénients à exécuter mes coureurs sur le même serveur utilisé par GitLab et GitLab CI.
J'ai lu qu'il y avait des problèmes de sécurité, mais nous ne l'utilisons qu'en interne, donc je ne pense pas que cela pourrait être un problème.
Un développeur interne veut nuire à l'entreprise (car considère qu'il est sous-payé, parce que son patron dort avec sa femme; la raison n'a pas d'importance) Il commet un test unitaire qui, lorsqu'il est exécuté, au lieu de tester l'application, recherche le référentiel GitLab et l'efface. Au prochain commit, surprise, tout le code source du projet est perdu (mais vous faites des sauvegardes et vous les testez, non?)
Ou le même développeur remarque que les sauvegardes du référentiel sont configurées sur la même machine. Il modifie cette configuration par le biais d'un test unitaire, de sorte que la sauvegarde contient désormais un référentiel différent et attend un mois, la durée de conservation des sauvegardes. Maintenant que toutes les sauvegardes sont corrompues, il peut valider son test unitaire qui efface le code source du serveur.
Ou un stagiaire veut vendre le code source à la concurrence. Vous avez soigneusement configuré l'accès, en le limitant uniquement à ce dont il a besoin pour son travail. Dans le même temps, il a un accès illimité au référentiel lui-même grâce aux tests unitaires, étant capable de faire le vidage complet.
À moins que les tests unitaires soient exécutés dans un contexte d'autorisations limitées et ne puissent accéder à rien au-delà des répertoires et des fichiers dont ils ont besoin pour les tests, mélanger le serveur CI avec le serveur qui conserve votre référentiel est en effet dangereux.
Un autre problème est que le serveur de contrôle de version devrait être rapide. Le serveur CI installé sur la même machine peut ralentir les validations.
Nous sommes 3 développeurs ... si quelqu'un d'entre nous veut nuire à l'entreprise, il peut le faire de mille façons = (... Le seul problème serait donc les performances lentes, mais si j'utilise une belle machine, je ne devrais pas avoir de grandes ? ennuis, à droite Merci!
Fès Vrasta
ps: et chroot? Vous ne pouvez pas être utilisé pour sécuriser le processus?
Fez Vrasta
4
@FezVrasta: si la sécurité n'est pas un problème dans votre cas, ni les performances, le seul avantage d'avoir des machines distinctes que je peux voir est la future évolutivité. Mais franchement, faire des changements avant l'apparition de problèmes d'évolutivité ressemble à une optimisation prématurée.
Arseni Mourzenko
@FezVrasta: "qu'en est-il de chroot? Ne peut pas être utilisé pour sécuriser le processus?" - Je n'ai pas assez de compétences en sécurité Unix pour répondre à cette question.
Arseni Mourzenko du
0
Étant donné qu'il n'y a pas de serveur central «omniscient» pour git, ce n'est pas mauvais comme ce serait le cas avec d'autres systèmes de contrôle de code source.
Pourvu qu'il y ait un syk automatique du serveur git hors site vers le serveur gther anthère (qui est testé), je ne serais pas préoccupé par cette configuration dans une petite entreprise.
Idéalement, je voudrais voir les développeurs pousser leurs modifications sur le serveur git du serveur offset, puis sur le serveur CI pour retirer les charges du serveur offset - de cette façon, le serveur hors site est testé à chaque enregistrement.
Si les développeurs faisaient toujours leur part du serveur sur site pour gagner du temps, ce n'est pas un problème.
si j'ai besoin de 2 serveurs ... pourquoi ne devrais-je pas simplement exécuter des coureurs sur le 2ème serveur?
Fez Vrasta
@FezVrasta, le " serveur hors site " peut être n'importe qui qui vous vendra de l'hébergement git, il ne doit pas nécessairement être un serveur que vous possédez. De plus, comme c'est sur Internet, il sera lent de tirer.
Ian
1
Je l'installe pour mon entreprise, nous utilisons nos propres serveurs ...
Étant donné qu'il n'y a pas de serveur central «omniscient» pour git, ce n'est pas mauvais comme ce serait le cas avec d'autres systèmes de contrôle de code source.
Pourvu qu'il y ait un syk automatique du serveur git hors site vers le serveur gther anthère (qui est testé), je ne serais pas préoccupé par cette configuration dans une petite entreprise.
Idéalement, je voudrais voir les développeurs pousser leurs modifications sur le serveur git du serveur offset, puis sur le serveur CI pour retirer les charges du serveur offset - de cette façon, le serveur hors site est testé à chaque enregistrement.
Si les développeurs faisaient toujours leur part du serveur sur site pour gagner du temps, ce n'est pas un problème.
la source