nemunaire/nemunai.re
1
0
Fork 0
Code Issues Pull Requests 1 Releases Activity

Fix spelling

Browse Source
This commit is contained in:
nemunaire 2023-10-27 17:22:42 +02:00
parent 075b635446
commit ac3ecece99
2 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/en/post/woodpecker-ci-mixing-http-grpc-on-one-domain-nginx/index.md
View File

@ -88,7 +88,7 @@ Each *Service* is declared within a package (*pkg*), then *Functions* complete t
All calls are `POSTs`. All calls are `POSTs`.
So we need to extract the various HTTP routes used by each protobuf service. So we need to extract the various HTTP routes used by each protobuf service.
Let's take a look at the following file for Wookpecker : Let's take a look at the following file for Woodpecker:
<https://github.com/woodpecker-ci/woodpecker/blob/main/pipeline/rpc/proto/woodpecker.proto> <https://github.com/woodpecker-ci/woodpecker/blob/main/pipeline/rpc/proto/woodpecker.proto>
@ -135,7 +135,7 @@ For example:
## `nginx` configuration ## `nginx` configuration
So here's what our `nginx` configuration might look like, using a single : So here's what our `nginx` configuration might look like, using a single domain:
``` ```
server { server {

10
content/fr/post/woodpecker-ci-mixing-http-grpc-on-one-domain-nginx/index.md
View File

@ -11,9 +11,9 @@ tags:
J'ai installé le service d'intégration continue [Woodpecker](https://woodpecker-ci.org/), afin de remplacer [DroneCI](https://drone.io), que [l'entreprise l'ayant racheté a décidé de l'enterrer](https://github.com/harness/gitness#where-is-drone). J'ai installé le service d'intégration continue [Woodpecker](https://woodpecker-ci.org/), afin de remplacer [DroneCI](https://drone.io), que [l'entreprise l'ayant racheté a décidé de l'enterrer](https://github.com/harness/gitness#where-is-drone).
Woodpecker étant un fork de la dernière version libre de Drone, son utilisation est globalement semblable. Woodpecker étant un fork de la dernière version libre de Drone, son utilisation est globalement semblable.
Néanmoins, les équipes ont suivies des orientations différentes sur certains aspects, et la communication avec les agents/*runners*, qui se faisaient avant au moyen de websockets, est réalisée dans Woodpecker au moyen du protocole GRPC. Néanmoins, les équipes ont suivi des orientations différentes sur certains aspects, et la communication avec les agents/*runners*, qui se faisaient avant au moyen de websockets, est réalisée dans Woodpecker au moyen du protocole GRPC.
La solution proposée par la [documentation de Woodpecker](https://woodpecker-ci.org/docs/administration/proxy#caddy) est d'utiliser 2 domaines : un sera utilisé pour l'interface web et l'API REST, le second sera utilisé pour GRPC. La solution proposée par la [documentation de Woodpecker](https://woodpecker-ci.org/docs/administration/proxy#caddy) est d'utiliser 2 domaines : un sera utilisé pour l'interface web et l'API REST, le second pour GRPC.
Est-ce vraiment nécessaire ? Est-ce vraiment nécessaire ?
<!-- more --> <!-- more -->
@ -90,7 +90,7 @@ Chaque *Service* est déclaré au sein d'un paquetage (*pkg*), des *Fonctions* c
Tous les appels sont des `POST`. Tous les appels sont des `POST`.
Il convient donc d'extraire les différentes routes HTTP utilisées par chaque service protobuf. Il convient donc d'extraire les différentes routes HTTP utilisées par chaque service protobuf.
Voyons le fichier suivant pour Wookpecker : Voyons le fichier suivant pour Woodpecker :
<https://github.com/woodpecker-ci/woodpecker/blob/main/pipeline/rpc/proto/woodpecker.proto> <https://github.com/woodpecker-ci/woodpecker/blob/main/pipeline/rpc/proto/woodpecker.proto>
@ -137,7 +137,7 @@ Par exemple :
## Configuration `nginx` ## Configuration `nginx`
Voici donc à quoi pourrait ressemble notre configuration `nginx`, en utilisant un seul domaine : Voici donc à quoi pourrait ressembler notre configuration `nginx`, en utilisant un seul domaine :
``` ```
server { server {
@ -179,7 +179,7 @@ Woodpecker déclare une fonction `Next` qui attend les informations d'un prochai
Ce temps d'attente est généralement très variable, plutôt très long si votre CI n'est pas sollicitée en permanence. Ce temps d'attente est généralement très variable, plutôt très long si votre CI n'est pas sollicitée en permanence.
`nginx` va prendre l'initiative, par défaut, d'arrêter toute requête inactive depuis plus de 60 secondes. `nginx` va prendre l'initiative, par défaut, d'arrêter toute requête inactive depuis plus de 60 secondes.
Cela occasionne un grand nombre reconnexion pour l'agent Woodpecker, visible dans les journaux de l'agent : Cela occasionne un grand nombre de reconnexions pour l'agent Woodpecker, visibles dans les journaux de l'agent :
{"level":"error","error":"rpc error: code = Unavailable desc = unexpected HTTP status code received from server: 504 (Gateway Timeout); transport: received unexpected content-type \"text/html\"","time":"2023-10-27T11:28:51Z","message":"grpc error: wait(): code: Unavailable: rpc error: code = Unavailable desc = unexpected HTTP status code received from server: 504 (Gateway Timeout); transport: received unexpected content-type \"text/html\""} {"level":"error","error":"rpc error: code = Unavailable desc = unexpected HTTP status code received from server: 504 (Gateway Timeout); transport: received unexpected content-type \"text/html\"","time":"2023-10-27T11:28:51Z","message":"grpc error: wait(): code: Unavailable: rpc error: code = Unavailable desc = unexpected HTTP status code received from server: 504 (Gateway Timeout); transport: received unexpected content-type \"text/html\""}