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

Fix spelling

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

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

@ -68,7 +68,7 @@ As such, many reverse-proxies are capable of transmitting GRPC requests.
This is the case of [Caddy](https://woodpecker-ci.org/docs/administration/proxy#caddy), a brief example of which is given, [Traefik](https://woodpecker-ci.org/docs/administration/proxy#traefik).
But `nginx` also [supports the transmission of GRPC requests](https://www.nginx.com/blog/nginx-1-13-10-grpc/).
When a GRPC request is received by the reverse-proxy, it sees an HTTP/2 request similar to :
When a GRPC request is received by the reverse-proxy, it sees an HTTP/2 request similar to:
```
POST /pkg.Service/Function HTTP/2.0
@ -88,7 +88,7 @@ Each *Service* is declared within a package (*pkg*), then *Functions* complete t
All calls are `POSTs`.
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>
@ -135,7 +135,7 @@ For example:
## `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 {
@ -181,7 +181,7 @@ This causes a large number of reconnections for the Woodpecker agent, visible in
{"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\""}
The agent will reconnect itself, but we can reduce the occurrence of this reconnection (whose main benefit is to do nothing until the server wakes us up), by adding this line to our configuration `nginx` :
The agent will reconnect itself, but we can reduce the occurrence of this reconnection (whose main benefit is to do nothing until the server wakes us up), by adding this line to our configuration `nginx`:
```
location /proto.Woodpecker/Next {

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).
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 ?
<!-- 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`.
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>
@ -137,7 +137,7 @@ Par exemple :
## 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 {
@ -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.
`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\""}