Configuration Discussion à propos d'intégrations continues

[Alex Fatta]

Bonjour !

Bon en premier, je ne sais pas tellement où mettre ce topic. Existe-t-il un topic "général" pour parler de tous types de sujet ?

Bon le vif du topic maintenant.

Suite à ce sujet : https://minecraft.fr/forum/threads/exporter-directement-un-jar-sur-le-ftp.243085/
qui très franchement m'a beaucoup plu (je suis fan du concept !), je souhaitai avoir un peu plus d'infos sur le sujet d'intégration continue, et surtout si il existe des tutos d'installation je les veux bien, parce que entre Docker, Maven et j'en passe, j'ai un peu de mal à m'y retrouver ^^

J'ai créer un compte chez BitBucket qui me semble vraiment très complet, mais là encore j'ai du mal à gérer l'installation de Maven et Docker (sur quelle machine etc...), et je ne saisi pas très bien l'installation nécessaire avec le script en .yml pour l'installation du système de pipeline.

Je pense notamment à @Jukeboy60 ou à @DiscowZombie qui étaient là lors de la première discussion, mais si d'autre ont des propositions, je prends aussi ^^

Voilà ! Je trouve que ce système est très bien pensé et cela évites effectivement que n'importe qui ayant accès aux dossiers aillent trifouiller là où il ne faut pas

Merci à vous !

AlexFatta

 

[DiscowZombie]

Salut,

tout d'abord, et, comme en philosophie, je pense qu'il est important de faire des distinctions conceptuelles. Alors, allons-s'y !

• Gitlab/GitBucket : Ce sont des serveurs Gits, càd qu'ils fonctionnent comme Github : c'est un serveur centralisé sur lequel tu envoies ton code (avec des commandes : git commit/git push...). Ces solutions proposent également de gérer tes Issues directement dessus et pleins de chose qui tourne autour. Cependant, et à l'instar de Github, ils proposent une intégration continue intégrée ! C'est une option qui est activable et, si elle l'est, à chaque nouveau Commit sur le projet, une suite d'action va s’exécuter. Par exemple, pour une application web Python, l'intégration continue va essayer de la lancer et retourner un status positif s'il n'a pas reçu d'erreur. C'est très pratique car tu n'as pas besoin de faire trop de vérifications et tests de ton côté, ils seront faits pour toi. Généralement, ces tests se font dans un Container Docker, avec tous les avantages que ça apporte. Ceci va même plus loin car tu peux pousser extrêmement loin ton intégration continue ; faire des tests pour plusieurs plateformes, pour plusieurs versions, dans un ordre choisi pour qu'il s’arrête s'il obtient une erreur, créer une nouvelle Release si ton programme commit sur master à passé tous les tests avec succès, etc... Les possibilités sont énormes à condition de savoir manier la configuration et les Containers Docker.
• Jetkins : C'est un serveur qui s'occupe quant à lui exclusivement de l'intégration continue dans le sens ou il te permet de créer, déployé et d'automatiser plein de choses sur ton projet ! Il dispose de plusieurs dizaines de plugins et te permet en combinaison avec un serveur Git d'avoir un projet qui "travaille" presque tout seul ! C'est plutôt équivalent à l'intégration continue fournie par Gitlab/GitBucket sauf que ce n'est pas dépendant d'eux.
  
• Maven/Gradle : Ils sont plutôt identiques dans le fonctionnement, ce sont principalement des puissants systèmes de gestion de dépendances en Java càd qu'ils vont t'aider pour la gestion des dépendances et pour la distribution de ton projet (ainsi que sa structure). Ils ont été pensé pour te faciliter la vie et avoir une application plus portable. Ils fonctionnent également avec des plugins et te permettent de bonnes possibilités si tu les pousses bien !
• Docker : La ça devient intéressant. Docker va également te permettre d'automatiser et de simplifier le déploiement d'application ; sous forme d'un paquet ! (comme tes cadeaux à Noël qui sont emballés). Dans ce paquet (Container), il y aura ton application et ses dépendances. Tout ce qui va s’exécuter dans ton Container sera totalement indépendant et isolé du reste du système ! Et là, c'est le jackpot ! Dans le passé, nous utilisions les VM (Machines Virtuels) pour tester nos applications sous différents systèmes et sous différentes versions. Le problème est qu'une VM fait plusieurs centaines de Go, pas très pratique et très peu portable ! Avec notre Container, plus de problèmes, il ne contient que le nécessaire : notre application et nos dépendances que nous avons installée en deux lignes.

J'espère que ces éléments auront permis de déblayer un peu, s'il reste des questions n’hésite surtout pas !


PS: Si j'ai oublié des points importants, ce qui est possible vu l'ampleur du sujet, n’hésitez pas non plus !

 

[JukeBoy_]

Salut, sympa de repartir de ce côté de Minecraft, ou on ne parle que très peu de Minecraft au final eheh.

Déjà, très bon premier débroussaillage par DiscowZombie ! Simple et concis.
Je vais simplement détailler un peu le côté VM / Docker, mais je vais pas pouvoir en faire le tour, c'est un pavé avec énormément d'utilités.

C'est parti :
Un serveur physique, ce n'est rien de plus qu'un PC sans écran, stocké dans une baie de stockage. Il possède une mémoire vive, des CPU, et du stockage.
Là on s'est dit : "D'accord très bien j'ai un PC de 128 GO de RAM, 16 VCPU et 4 TO de stockage, mais moi mes clients, jamais ils veulent louer autant de puissance, ou alors pas en une seule fois ! Jamais je ne peux être rentable en achetant un gros serveur et en faisant tourner qu'une seule application !"
ET HOP ! Révolution : le cloud computing. Cette révolution a pu exister grâce à un principe : on prend ce gros serveur physique, et on le découpe en autant de "Machine Virtuelle" qu'on veut.
On se retrouve donc avec des serveurs (comme ceux qu'on loue aujourd'hui), avec 2/4/8 GO etc... Alors que le serveur physique lui fait toujours 128 GO de RAM, 16 VCPU et 4 TO de stockage. C'est mieux pour amortir l'investissement d'un gros serveur.

Et que vient faire Docker dans tout ça ? C'est encore une autre façon de penser.
On reprend le principe des VM, mais on les rend éphémère. Là où une VM possède son propre stockage et un OS complet (Linux / Windows / IBM etc..), un container docker lui possède le minimum vital : 256mo de ram / le minimum d'un OS / très peu d'options déjà installées etc.. Comme une feuille vierge, ou un feuille imprimable en autant d'exemplaire qu'on veut. On part de cette version, on fait ce qu'on veut dessus, et quand on en a plus besoin, on le supprime. L'espace est ainsi libéré.

Après pour les cas d'applications, je peux pas te faire une liste exhaustive mais si tu veux des exemples n'hésite pas !

Dans le cas de BitBucket, à quoi servent Docker et Jenkins ?

Alors, tu ne les verras jamais, mais ce sont bien eux qui sont derrière le fonctionnement des Pipelines. Comment ça fonctionne, j'espère que ça t'aidera.

--> GIT signale un changement dans le projet.
--> Jenkins reçoit cette mise à jour.
--> Il regarde s'il doit faire quelque chose, s'il y a un job pour lui.
Il regarde donc s'il y a un fichier YML dans ton projet. (jenkins peut aussi avoir des jobs en "dur", le code est dans la config du jenkins, il l'éxécute sans regarder ton GIT)
--> OUI ! Il y en a un ! Il prend donc ce fichier et commence à le lire.
--> Il lance un container Docker "vide", une config minimale (ce genre de chose https://hub.docker.com/_/alpine/ ou alors une image spéciale, contenant déjà les paquets nécessaires, Python par exemple).
--> Il commence a lire step par step ce qu'il doit faire, et exécute chaque commande Linux à l'intérieur de ce container.
--> Une fois fini il passe au step suivant, qui est un autre build.
--> A la fin les containers meurent, car ils n'ont plus d'utilité.

Cas d'exemple, pour déployer sur le Cloud Amazon, dans ton YML :

image: node:7.5.0

pipelines:
default:
- step:
script:
- apt-get update && apt-get install -y python-dev
- curl -O https://bootstrap.pypa.io/get-pip.py
- python get-pip.py
- pip install awscli
- aws s3 sync --delete . s3://<S3 bucket>

Ici l'image docker "Node:7.5.0" est utilisée, ensuite le step te dit de prendre un docker vierge , et d’exécuter les commandes linux citées dans "Script"

A savoir :
- Mettre a jour ce que le container contient, et installer python.
- Faire une requête à cette adresse et récupérer le fichier qui s'y trouve.
- Exécuter ce script avec python (car .py c'est du python).
- Installer la librairie Amazon, qui permet de communiquer avec le Cloud Amazon.
- Synchroniser ton serveur amazon avec ton GIT local.

Tu viens de faire une pipeline BitBucket, qui étrangement, respecte la façon d'écriture Jenkins !

C'est fou tout ce qu'on apprend en jouant a Minecraft

Hésite pas si tu veux d'autres infos !

 

[Alex Fatta]

Bonjour !

Bon cela fait 2 jours que le lis vos messages en boucle et je les compare avec ce que j'ai appris sur les différents sites traitants du sujet. Le concept me parais déjà beaucoup plus clair ! Bon j'ai trifouillé pas mal de temps, j'ai installé jenkins en solo pour voir comment ca fonctionne, je me suis renseigné sur Docker etc... bien que je n'ai pas pus tester Docker.

Donc, si je comprends bien, j'utilise Github desktop afin de commit et de push mon code sur Gitbucket. Dans les fichiers, je joins un fichier .yml (récupérable depuis Gitbucket) et Gitbucket le détecte et il exécute les commandes à l'intérieur (par exemple arrêter les serveurs, mettre les nouveaux fichiers etc...) en shell. Et ca roule ?

En tout cas le système me semble très bien penser

AlexFatta

 

[DiscowZombie]

Salut,

Donc, si je comprends bien, j'utilise Github desktop afin de commit et de push mon code sur Gitbucket. Dans les fichiers, je joins un fichier .yml (récupérable depuis Gitbucket) et Gitbucket le détecte et il exécute les commandes à l'intérieur (par exemple arrêter les serveurs, mettre les nouveaux fichiers etc...) en shell. Et ca roule ?

c'est effectivement ça. Pour avoir quelques infos techniques pour BitBucket, voici quelques liens :

• https://bitbucket.org/product/features/pipelines
• https://www.atlassian.com/continuous-delivery/continuous-integration-tutorial
• https://www.atlassian.com/continuous-delivery/continuous-deployment-tutorial

En tout cas le système me semble très bien penser

Oui, c'est très bien foutu !

 

[Alex Fatta]

Hey !

Alors du coup je me posais la question suivante : comment je relie Bitbucket à la machine qui héberge les serveurs ? Pour le coup j'ai eu du mal à trouver :/

Également, tu sais si c'est possible de centraliser les codes (cad tous les membres du staff upload etc...) puis ensuite de tout push vers les serveurs MC en exécutant les commandes contenues dans le .yml ? Autrement dit, tout le monde upload sur Bitbucket, puis une fois que tout est prêt, d'exécuter le .yml, pas qu'il s'exécute à chaque push/commit

AlexFatta

PS : je ne suis pas encore allé voir les liens que tu as donné

 

[DiscowZombie]

Re,

Alors du coup je me posais la question suivante : comment je relie Bitbucket à la machine qui héberge les serveurs ? Pour le coup j'ai eu du mal à trouver :/

si tu build de ta machine, ce ne serais pas un souci, mais sinon il faut que tu fasses en sorte que si le build n'a pas d'erreur, il te génère un jar valide pour que tes machines puissent aller le télécharger. Il y a peut-être possibilité de faire ça un peu mieux, il faudrait voir avec @Jukeboy60.

Également, tu sais si c'est possible de centraliser les codes (cad tous les membres du staff upload etc...) puis ensuite de tout push vers les serveurs MC en exécutant les commandes contenues dans le .yml ? Autrement dit, tout le monde upload sur Bitbucket, puis une fois que tout est prêt, d'exécuter le .yml, pas qu'il s'exécute à chaque push/commit

Pour chaque commit, ton projet va essayer de build. S'il arrive au bout, tu peux générer un jar ; il ne suffit ensuite que tes machines le DL (même cas que le 1). Cependant, il ne faudra pas qu'elles download les jars "dev" (qui seront par exemple sur une branche dev) mais seulement ceux du code lorsqu’il est poussé sur master ! Après, ceci se passe au niveau de ta config

 

[JukeBoy_]

Salut ! Je vois que tu avances pas mal ! Pour répondre à tes questions.

Alors du coup je me posais la question suivante : comment je relie Bitbucket à la machine qui héberge les serveurs ? Pour le coup j'ai eu du mal à trouver :/

Si ton hébergeur dispose d'une solution clef en main pour ce genre de procédés, dans ce cas tu auras juste à utiliser son API, ses services ou la documentation qu'il te fourni.
Dans ce style :
- https://aws.amazon.com/fr/blogs/apn/announcing-atlassian-bitbucket-support-for-aws-codedeploy/
- https://confluence.atlassian.com/bitbucket/deploy-to-microsoft-azure-900820699.html

Si ce n'est pas le cas, place tes accès FTP en variable globale (c'est une option de bitbucket, tu peux les appeler en variable après avec ton YML).
Et utilise la bonne solution standard du FTP, comme tu fais surement en ce moment, mais automatisé du coup : https://gist.github.com/mcnamee/aa141afde5c0359c568c169a56f100d7

Pour éviter tout soucis, je te recommande de mettre une sécurité sur tes commandes, comme un temps d’exécution maximal de 30secs ou 2mins, pour éviter de trop consommer de crédits en cas de galère.

Également, tu sais si c'est possible de centraliser les codes (cad tous les membres du staff upload etc...) puis ensuite de tout push vers les serveurs MC en exécutant les commandes contenues dans le .yml ?

Comme dit par @DiscowZombie, il faut faire en sorte que la Master ne soit modifié que quand le push des serveurs est voulu. Après, il y a la méthode de dire a ton build de ne se lancer que quand le bouton "OK" est appuyé. Le build commence, mais ton step n'est pas commencé, rien n'est consommé le temps que tu n'appuies pas sur le bouton. Il suffit de terminer le build (= erreur mais pas grave car tu ne voulais pas de toutes façons), ou de le laisser en attente (moins propre).
Tu trouveras la doc ici : https://confluence.atlassian.com/bitbucket/run-pipelines-manually-861242583.html

J'espère que ça va bien se passer ! Bonne chance pour la suite