Pour tout problème contactez-nous par mail : support@froggit.fr | La FAQ :grey_question: | Rejoignez-nous sur le Chat :speech_balloon:

Skip to content
Snippets Groups Projects
Commit b851b020 authored by Plumtree3D's avatar Plumtree3D
Browse files

fix: removed unpublished blogposts

parent 9f12d33c
No related branches found
No related tags found
No related merge requests found
Pipeline #27524 passed
Stage: build
Stage: 🧪 test
Stage: 📝 publish
Stage: 🧽 clean
This commit is part of merge request !22. Comments created here will be created in the context of that merge request.
Hide whitespace changes
Inline Side-by-side
blog/2021/2021-05-17-mettre-en-cache-les-images-docker-pour-reduire-le-nombre-dappels-au-dockerhub-depuis-votre-infrastructure-ci-cd.md deleted 100644 → 0
+ 0
− 114
View file @ 9f12d33c
---
title: "Mettre en cache les images Docker pour réduire le nombre d'appels au DockerHub depuis votre infrastructure CI/CD"
authors: "aboudreault"
date: "2021-05-17"
slug: "mettre-en-cache-les-images-docker-pour-reduire-le-nombre-dappels-au-dockerhub-depuis-votre-infrastructure-ci-cd"
tags:
- "ci-cd"
- "conteneurs"
- "devops"
- "docker"
- "froggit"
- "gitlab"
image: "Screenshot_20210116_175700.png"
---
Docker a annoncé qu'il va limiter le nombre de _pull requests_ faites à son service dans son offre gratuite. Nous partageons nos stratégies pour atténuer l'impact de cette nouvelle limitation de _pull requests_ pour les utilisateurs et les clients qui gèrent leur propre instance GitLab.
<!-- truncate -->
Le 24 août 2020, [Docker a annoncé des changements dans son modèle d'abonnement](https://www.docker.com/blog/scaling-docker-to-serve-millions-more-developers-network-egress/) et a initié un mouvement vers des limitations basées sur la consommation. Ces limitations concernent le nombre d'images de conteneurs Docker qui peuvent être extraites. Cela prend effet le 1er novembre 2020. Pour les _pull requests_ faites par des utilisateurs anonymes, la limitation est à présent de 100 _pulls requests_ toutes les 6 heures; les utilisateurs authentifiés ont une limite de 200 _pull requests_ par 6 heures.
En tant que membre de la communauté globale du DevOps, nous avons tous pris l'habitude de compter sur Docker comme partie intégrante des [processus CI / CD](https://about.gitlab.com/blog/2020/10/30/mitigating-the-impact-of-docker-hub-pull-requests-limits/topics/ci-cd/). Il n'est pas surprenant que chez GitLab, ils ont eu des retours de plusieurs membres de la communauté ainsi que de clients qui souhaitaient des conseils car ce changement de limitation Docker pouvait affecter leur flux de travail CI/CD en production.
## Utiliser un miroir de registre
Vous pouvez utiliser la fonctionnalité de miroir de registre pour connaître le nombre de _pull requests_ d'images générées sur DockerHub. Quand le miroir est configuré et GitLab Runner indique à Docker d'extraire des images, Docker va vérifier le miroir en premier; si c'est la première fois que l'image est extraite, une connexion va être faite à DockerHub. Les extractions suivantes de cette image utiliserons ensuite votre miroir au lieu de se connecter au DockerHub. [Vous pouvez trouver plus de détails sur comment ça marche ici.](https://docs.docker.com/registry/recipes/mirror/#how-does-it-work)
## Si vous êtes un utilisateur ou un client de GitLab SaaS
Pour les Shared Runners sur GitLab.com ils utilisent le miroir Google pour les images du Docker Hub. Cela signifie que les utilisateurs des CI jobs sur GitLab Shared Runners ne seront pas affectés par cette nouvelle politique concernant les pull requests. Ils vont continuer à surveiller l'impact de ces changements effectués par Docker.
## SI vous auto-hébergez des GitLab Runners
Tout d'abord, vérifiez si votre fournisseur d'hébergement ou de cloud ne vous fournit pas déjà un miroir de registre d'images. Si c'est le cas, c'est sûrement l'option la plus simple et la plus performante. Si pour une quelconque raison un registre de miroir hébergé ne peut pas être utilisé, l'administrateur peut installer son propre [miroir DockerHub](https://docs.docker.com/registry/recipes/mirror/).
## Démarrer le miroir de registre
Veuillez suivre les instructions dans [la documentation GitLab](https://docs.gitlab.com/runner/configuration/speed_up_job_execution.html):
1. Connectez-vous sur une machine dédiée où le proxy de miroir de registre tournera
2. Assurez-vous que [Docker Engine](https://docs.docker.com/install/) est installé sur cette machine
3. Créez un nouveau registre de conteneur
![](../images/Screenshot_20210116_175700.png)
Vous pouvez modifier le numéro de port (`6000`) pour exposer le registre avec un port différent. Cela démarrera le serveur avec `http`. Si vous souhaitez activer TLS (`https`) suivez la [documentation officielle](https://docs.docker.com/registry/configuration/#tls).
4. Vérifiez l'adresse IP du serveur :
![](../images/Screenshot_20210116_175830.png)
De préférence, choisissez l'adresse IP du réseau privé. Le réseau privé est généralement la solution la plus rapide pour les communications interne entre les machines d'un seul fournisseur (DigitalOcean, AWS, Azure..). Généralement, l'utilisation d'un réseau privé n'est pas prise en compte dans votre limite de bande passante mensuelle.
5. Le registre Docker sera accessible sous `MY_REGISTRY_IP:6000`
## Configurer Docker pour l'utiliser
La partie finale est d'avoir le processus `dockerd` configuré pour qu'il utilise votre miroir quand `docker pull` tourne.
### Docker
Ajouter l'option `--registry-mirror` lorsque vous démarrez le daemon Docker `dockerd` manuellement ou editez `/etc/docker/daemon.json` et ajoutez la clé et la valeur `registry-mirrors` pour que le changement soit permanent.
![](../images/Screenshot_20210116_175904.png)
### `docker+machine` executor
Mettez à jour le fichier de configuration du GitLab Runner `config.toml` pour spécifier [engine-registry-mirror à l'intérieur des paramètres MachineOptions.](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-container-registry-mirroring)
### [Docker-in-Docker](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-workflow-with-docker-executor) pour construire des images Docker
Il y a différentes manière d'y parvenir, et cela dépend de votre configuration. Vous en trouverez une liste complète dans notre [documentation](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#enable-registry-mirror-for-dockerdind-service).
## Vérifiez que ça fonctionne
### Assurez-vous que Docker est configuré pour utiliser le miroir
Si vous exécutez `docker info` où `dockerd` est configuré pour utiliser le miroir vous devriez voir ce qui suit apparaître :
![](../images/Screenshot_20210116_180200.png)
### Vérifiez le catalogue du registre
[L'API Docker Registry](https://docs.docker.com/registry/spec/api/) peut vous montrer quel dépôt il a mis en cache localement.
Etant donné que nous avons executé `docker pull node` pour la première fois avec `dockerd` configuré pour utiliser le miroir nous pouvons le voir [en listant les dépots](https://docs.docker.com/registry/spec/api/#listing-repositories).
![](../images/Screenshot_20210116_180255.png)
### Vérifiez les logs du registre
Lorsque vous faites des pull d'images vous devriez voir des logs venir concernant les informations demandées en exécutant `docker logs registry`, où `registry` est le nom du conteneur qui exécute le miroir.
![](../images/Screenshot_20210116_180328.png)
## Des alternatives aux miroirs DockerHub
Mettre en place un miroir de registre Docker peut également augmenter vos coûts d'infrastructure. Avec les nouvelles [limites de débit DockerHub,](https://docs.docker.com/docker-hub/download-rate-limit/) il pourrait être utile d'authentifier les _pulls_ au lieu d'avoir votre limite augmentée ou pas de limite du tout (suivant votre abonnement).
Il y a différentes façons de s'authentifier avec DockerHub sur GitLab CI et c'est [documenté en détail](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#define-an-image-from-a-private-container-registry). Voici quelques exemples:
1. la variable `DOCKER_AUTH_CONFIG` est fournie.
2. le fichier `config.json` est placé dans le répertoire `$HOME/.docker`de l'utilisateur exécutant le processus GitLab Runner.
3. Lancez `docker login` si vous utilisez un flux de travail [Docker-in-Docker](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-workflow-with-docker-executor).
## En résumé
Comme vous pouvez le voir, il y a plusieurs manières de s'adapter aux nouvelles limites du Docker Hub et nous encourageons les utilisateurs à choisir la plus pertinente suivant les besoins de leur organisation. Outre les options décrites dans cet article, il est également possible de rester dans l'écosystème GitLab en utilisant le [GitLab Container Proxy, qui sera bientôt disponible pour les utilisateurs Core](https://about.gitlab.com/blog/2020/10/30/minor-breaking-change-dependency-proxy/).
Vous cherchez des utilisateurs ou une instance GitLab hébergée en France ? **[Rejoignez la Communautés Froggit](http://froggit.fr/)**.
**Crédits** [![](../images/by-sa.png)](https://creativecommons.org/licenses/by-sa/4.0/deed.fr) Le contenu de cet article est en Licence Libre Creative Commons Cet article est une traduction [issue du site de GitLab.](https://about.gitlab.com/blog/2020/10/30/mitigating-the-impact-of-docker-hub-pull-requests-limits/)
blog/2021/2021-05-26-comment-les-variables-ci-cd-pre-remplies-faciliteront-le-fonctionnement-des-pipelines.md deleted 100644 → 0
+ 0
− 95
View file @ 9f12d33c
---
title: "Comment les variables CI/CD pré-remplies faciliteront le fonctionnement des pipelines"
date: "2021-05-26"
authors: "aboudreault"
slug: "comment-les-variables-ci-cd-pre-remplies-faciliteront-le-fonctionnement-des-pipelines"
tags:
- "ci-cd"
- "gitlab"
- "devops"
- "froggit"
- "integration-continue"
image: "multi-project-pipelines.jpg"
---
#### Apprenez-en plus sur cette future version et sur la manière dont les variables pré-remplies permettront de gagner du temps et des réduire les erreurs.
<!-- truncate -->
![](../images/multi-project-pipelines.jpg)
[Les variables CI/CD](https://about.gitlab.com/topics/ci-cd/) sont une façon utile de personnaliser les pipelines selon leur environnement. Mais comment faire lorsque vous avez besoin d'outrepasser une variable ou que vous avez besoin de faire fonctionner un pipeline manuellement ? Ces scénarios peuvent poser problème.
- Comment faire lorsque vous ne savez pas quelles variables / valeurs mettre ?
- Que se passe t-il si vous faites une erreur ?
Avoir à saisir manuellement des variables et des valeurs est fastidieux et sujet à erreur. De plus, un utilisateur ne connaît pas forcément toutes les différentes valeurs / variables qu'il a besoin d'entrer. Dans GitLab 13.7, ils ont ajouté une fonctionnalité qui vous aide à résoudre ces problèmes en générant des variables pré-remplies à partir de votre fichier `.gitlab-ci.yml.` quand vous exécutez un pipeline.
## Qu'est ce que les variables CI/CD ?
[Les variables CI/CD](https://docs.gitlab.com/ee/ci/variables/README.html) sont des valeurs dynamiques assignées à des environnements. Ces variables d'environnement affectent la manière dont les processus en cours d'exécution se comportent sur un système d'exploitation. Les variables permettent aux équipes de customiser des tâches dans GitLab CI/CD.
Il y a deux endroits où les équipes peuvent définir les variables :
\-> Le fichier `.gitlab-ci.yml.` -> Le fichier GitLab Runner `config.toml.`
Les variables CI/CD peuvent être très utiles, mais comment faire si vous avez besoin d'outrepasser une variables ou d'exécuter un pipeline manuellement ? Vous pourriez faire ça si les résultats de pipeline (par exemple, une compilation de code) sont requis en dehors de l'exécution normale du pipeline. Les équipes pourraient aussi opter pour des déploiements manuels en production et le besoin d'arrêter le pipeline de manière prématurée. Exécuter un pipeline manuellement n'est pas inhabituel mais [définir les variables](https://docs.gitlab.com/ee/ci/variables/where_variables_can_be_used.html) et les rentrer dans un pipeline manuel n'a pas toujours été un processus simple.
Premièrement, les équipes ont besoin d’exécuter un pipeline / une tâche manuellement et ensuite naviguent dans la vue d'ensemble. Ensuite, ils doivent sélectionner toutes les variables requises à partir du menu déroulant sur la page “_Run Pipeline_”. Si les développeurs ne connaissent pas toutes les variables nécessaires par cœur, ils vont devoir vérifier leurs sources et faire des allers-retours. Si il y a de nombreuses paires clés / valeurs à entrer, cela peut être particulièrement laborieux.
## Les variables pré-remplies : Qu'est-ce que c'est ?
Dans la 13.7, ils ont lancés une fonctionnalité qui va simplifier ce processus. A présent, le formulaire “_Run pipeline_” va [générer des variables pré-remplies](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) pour votre pipeline en fonction des définitions de variables dans votre fichier `.gitlab-ci.yml`.La réponse à cette fonctionnalité de la part de la communauté GitLab fût enthousiaste.
![pre-filled variables issue](../images/pre-filled-variables.png)
## _Les gens sont enthousiasmés par les variables pré-remplies !_
## Les bénéfices des variables pré-remplies
L’intérêt des variables pré-remplies est d’accroître l'efficacité et de réduire les petites frustrations qui rendent les tâches plus difficiles qu'elles ne devraient.
Les variables pré-remplies vont réduire :
- Les frustrations liées aux valeurs de menus-déroulants
- Les frictions liées au choix de mauvaises valeurs
- Re-exécuter et débugger les pipelines à cause de mauvaises valeurs
- Les erreurs et les actions cliquables
\[caption id="" align="aligncenter" width="1280"\]![](../images/Run-pipeline.gif) Les variables pré-remplies en action\[/caption\]
Pour les équipes qui déploient manuellement en production, les variables pré-remplies vont faciliter cette étape de révision, de sorte que tout personne disposant des bonnes autorisations va pouvoir déclencher manuellement le pipeline de déploiement. Si le relecteur à besoin de faire une exception, il peut aussi outrepasser une variable si c'est nécessaire.
Les variables pré-remplies vont aider les équipes à gagner du temps, réduire les erreurs et rendre le processus de pipeline manuel plus souple. Pensez-vous que nous avons raté quelque chose ou qu'il y a de meilleurs manières de fluidifier encore ce processus ? Laissez un commentaire et dites nous ce que vous en pensez. Tout le monde peut contribuer.
## Les futures sorties GitLab CI
Les variables pré-remplies sont seulement une des fonctionnalités d'intégration continue. Les équipes de GitLab sortent de [nouvelles fonctionnalités](https://about.gitlab.com/upcoming-releases/) le 22 chaque mois et n'importe qui peut contribuer sur ces sujets.
## En savoir plus sur CI / CD
- [Vous voulez un pipeline CI / CD plus efficace? Essayez nos conseils de pro](https://about.gitlab.com/blog/2020/07/29/effective-ci-cd-pipelines/)
- [Webcast: 7 hacks CI / CD](https://about.gitlab.com/webcast/7cicd-hacks/)
- [Comment utiliser les modèles de pipeline CI / CD de GitLab](https://about.gitlab.com/blog/2020/09/23/get-started-ci-pipeline-templates/)
Vous cherchez des utilisateurs ou une instance GitLab hébergée en France ? **[Rejoignez la Communautés Froggit](http://froggit.fr/)**.
**Crédits** [![](../images/by-sa.png)](https://creativecommons.org/licenses/by-sa/4.0/deed.fr) Le contenu de cet article est en Licence Libre Creative Commons Cet article est une traduction [issue du site de GitLab.](https://about.gitlab.com/blog/2020/10/30/mitigating-the-impact-of-docker-hub-pull-requests-limits/)
blog/2023/2023-11-03-rendez_vos_revues_de_code_plus-efficaces.md deleted 100644 → 0
+ 0
− 75
View file @ 9f12d33c
---
title: "Rendez vos revues de code plus efficaces !"
date: "2023-11-03"
authors:
- "cchaudier"
- "tmichel"
slug: "rendez_vos_revues_de_code_plus-efficaces"
categories:
- "devops"
tags:
- "apprentissage"
- "devops"
- "froggit"
- "gitlab"
image: "pre-commit1.jpg"
---
#### De la gestion du temps au déblocage, découvrez les secrets pour des revues de code plus efficaces.
<!-- truncate -->
Comme la plupart des entreprises, la revue de code chez GitLab prend une place importante dans leur flux de travail. Cependant, il est clair qu'en observant les résultats du sondage [_2020 Global DevSecOps_](https://about.gitlab.com/developer-survey/), on constate que la revue de code peut être une des raisons majeures qui mènent à un retard dans _les releases_ et une frustration globale. Une vaste majorité d'entreprises mènent des revues de code (certaines font même ça quotidiennement) mais cela est potentiellement une perte de temps.
Cependant, la revue de code peut être faite de manière efficace et je peux en parler en connaissance de cause car j'ai été mainteneur pendant 3 ans. Voici un aperçu de mon rituel éprouvée qui me permet de passer en revue et de fusionner du code rapidement et efficacement pour aider les autres à ne pas être bloqués à cause de moi. Bien entendu, ce rituel marche pour _moi_ mais il peut différer légèrement d'une personne à l'autre. Voici ce que je fais :
## 1\. La gestion du temps
Je commence ma journée par passer en revue les demandes de fusion. Je me donne une heure pour commencer et je m'astreint à cette tâche jusqu'à ce que ma _“to do list”_ Gitlab n'a plus de demande de fusion qui nécessite une vérification. J'aime bien faire ça le matin car c'est le moment de la journée où je suis le plus concentré et à même de faire les vérifications sans être trop distrait.
M'atteler aux revues après cette heure-ci est compliqué. J'ai d'autres tâches à effectuer également et une fois que j'ai vérifié toutes les demandes de fusion sur ma liste, je laisse ma liste tranquille jusqu'au lendemain. Bien évidemment, comme toute règle, on finit par l'enfreindre. Suivant la taille des demandes de fusion, \*_Je peux m'assurer de les vérifier avant que ma journée ne se termine pour être sûr que personne d'autre sur un autre fuseau horaire ne soit pas bloqué par celle-ci. \*_
## 2\. Débloquer les autres en premier
Devoir attendre X heures / jours avant d'obtenir un retour n'est pas l'idéal pour l'auteur d'une demande de fusion. Plus vite ils obtiennent un retour et plus vite la demande de fusion peut être effectuée et livrée. Faire attendre les auteurs ne fait que créer de l'incertitude et peut signifier que d'autres tâches sont retardées.
C'est la raison pour laquelle je trouve important d'examiner une demande de fusion aussi vite que je le peux. Chez Gitlab, ils ont pour objectif d'apporter une première réponse en 2 jours (_[2 day Service Level Objective](https://about.gitlab.com/handbook/engineering/workflow/code-review/#first-response-slo)_ en anglais) pour le retour de la part des personnes qui s'occupent de la revue de code. Pour ma part, j'essaye toujours de faire mieux que ça et d'apporter une première réponse dans la journée-même.
## 3\. Se concentrer sur le code, pas la fonctionnalité
Ce point pourrait susciter beaucoup de discussions : au lieu de se concentrer sur la fonctionnalité, concentrez-vous sur le code.
Un grand nombre de demandes de fusion que j'examine proviennent de différents groupes, avec des fonctionnalités que je ne comprend pas totalement ou avec des fonctionnalités que je ne peux pas tester. Je pourrais passer beaucoup de temps à lire le code d'une fonctionnalité et le problème pour comprendre de quoi il s'agit, mais cela signifie passer plus de temps à ne pas examiner le code de quelqu'un d'autre. De plus, si je faisais cela avec **toutes** les demandes de fusion, j'aurais du mal à m'en tenir à ma limite de temps.
Qui est le plus à même d'examiner la fonctionnalité du coup ? Le _product designer_ (UX) ou le _product manager_ comprennent tous les deux la fonctionnalité en cours de travail et sont plus compétents pour trouver des bugs et guider la fonctionnalité dans la bonne direction. Il est important que quelqu'un dans l'équipe UX examine la fonctionnalité pour s'assurer que cela correspond aux designs et à la vision qu'ils avaient imaginés pour la fonctionnalité. Si une demande de fusion n'a pas d'examen UX au moment où je dois l'examiner, je vais normalement demander à l'auteur (ou demander à un _product designer_ moi-même) que l'UX soit examiné avant que je fusionne la demande de fusion.
Cependant, ce point est aussi quelque chose auquel je ne tient pas toujours. Si une demande de fusion touche à une zone qui m'est familier et que je peux affirmer en voyant le code qu'un bug est présent, je vais le tester localement et fournir un maximum de _feedback_ pour aider l'auteur à comprendre le bug. Plus vous, en tant qu'examinateur, travaillez avec le code, plus il est simple de trouver des bugs dans le code. Cela fait 4 ans que je travaille sur la _codebase_ de Gitlab et voir d'où les bugs pourraient émerger est devenu une seconde nature pour moi.
## 4\. Chercher à comprendre : Poser des questions
Il est simple de suggérer des changements dans le code que je passe en revue mais parfois ce que je suggère n'est peut-être pas juste. Il est important qu'au lieu de juste suggérer un changement, vous vous demandiez toujours si l'auteur pense que c'est le bon changement. Discuter d'un changement aide l'examinateur et l'auteur à comprendre le code déjà existant ainsi que le code étant suggéré. Peut-être que la suggestion avait déjà été testée par l'auteur. Être ouvert à la discussion aide à obtenir la bonne solution.
Cependant, il arrive parfois que des suggestions de changements soient faites autour du _legacy code_, c'est à dire du code qui existe depuis longtemps sans avoir été mis à jour pour la documentation. Dans des cas, la conclusion peut être que de la dette technique ne soit crée. Ce n'est pas grave. Nous devrions chercher des [solutions ennuyeuses](https://about.gitlab.com/handbook/values/#boring-solutions) en premier mais aussi comprendre qu'une solution plus optimale ne soit nécessaire à l'avenir.
## Pour résumer
Passer en revue du code efficacement est une compétence qui s'apprend en pratiquant. Prendre le temps de trouver un flux de travail qui vous correspond est aussi important. Au fil des années où j'ai fais des revues de code, je me suis astreint à ces astuces. Pourtant, je suis loin d'être parfait; je suis constamment en train d'apprendre de nouvelles et des manières différentes d'optimiser mon flux de travail pour la revue de code. J'adorerais entendre d'autres conseils et d'autres flux de travail. C'est grâce aux discussions que nous pouvons nous améliorer et nous pousser à être les meilleurs possibles.
Vous cherchez des utilisateurs ou une instance GitLab hébergée en France ? **[Rejoignez la Communautés Froggit](http://froggit.fr/)**.
**Crédits** [![](../images/by-sa.png)](https://creativecommons.org/licenses/by-sa/4.0/deed.fr) Le contenu de cet article est en Licence Libre Creative Commons Cet article est une traduction [issue du site de GitLab.](https://about.gitlab.com/blog/2020/04/24/parent-child-pipelines)
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment

Froggit est fièrement fabriqué avec amour par Lydra avec des Logiciels Libres et hébergé en France chez Scaleway | Status du service