Skip to content

Commit caf3eab

Browse files
luisfcorreialuisfcorreia
authored
Translation of Grid Documentation to pt-br (SeleniumHQ#1251)
[deploy site]
1 parent 997a48e commit caf3eab

File tree

2 files changed

+154
-179
lines changed

2 files changed

+154
-179
lines changed

‎website_and_docs/content/documentation/grid/architecture.pt-br.md

Lines changed: 123 additions & 141 deletions
Original file line numberDiff line numberDiff line change
@@ -1,120 +1,104 @@
11
---
2-
title: "Grid Architecture"
3-
linkTitle: "Grid Architecture"
2+
title: "Arquitectura da Grid"
3+
linkTitle: "Arquitectura da Grid"
44
weight: 10
55
aliases: [
66
"/pt-br/documentation/grid/grid_architecture"
77
]
88
---
99

10-
{{% pageinfo color="warning" %}}
11-
<p class="lead">
12-
<i class="fas fa-language display-4"></i>
13-
Page being translated from
14-
English to Portuguese. Do you speak Portuguese? Help us to translate
15-
it by sending us pull requests!
16-
</p>
17-
{{% /pageinfo %}}
10+
A Grid está desenhada como um conjunto de componentes, em que cada tem
11+
o seu papel crucial em manter a Grid. Isto pode parecer um pouco complicado,
12+
mas esperamos que este documento ajude a esclarecer alguma confusão.
1813

19-
The Grid is designed as a set of components that all fulfill a role in
20-
maintaining the Grid. It can seem quite complicated, but hopefully
21-
this document can help clear up any confusion.
14+
## Os componentes chave
2215

23-
## The Key Components
24-
25-
The main components of the Grid are:
16+
Os componentes principais da Grid são:
2617

2718
<dl>
2819
<dt>Event Bus
29-
<dd>Used for sending messages which may be received asynchronously
30-
between the other components.
20+
<dd>Usado para enviar mensagens que podem ser recebidas de forma assíncrona
21+
entre os outros componentes.
3122

3223
<dt>New Session Queue
33-
<dd>Maintains a list of incoming sessions which have yet to be
34-
assigned to a Node by the Distributor.
24+
<dd>Mantém uma lista de pedidos de sessão que serão assignadas a um Node
25+
pelo Distributor.
3526

3627
<dt>Distributor
37-
<dd>Responsible for maintaining a model of the available locations in
38-
the Grid where a session may run (known as "slots") and taking any
39-
incoming <a
40-
href="https://w3c.github.io/webdriver/#new-session">new
41-
session</a> requests and assigning them to a slot.
28+
<dd>Responsável por manter um modelo das localizações da Grid (slots) onde uma
29+
sessão pode ser lançada e também por aceitar novos
30+
<a href="https://w3c.github.io/webdriver/#new-session">pedidos de sessão</a>
31+
e assignar a um slot livre.
4232

4333
<dt>Node
44-
<dd>Runs a <a
45-
href="https://w3c.github.io/webdriver/#dfn-sessions">WebDriver
46-
session</a>. Each session is assigned to a slot, and each node has
47-
one or more slots.
34+
<dd>Executa uma <a href="https://w3c.github.io/webdriver/#dfn-sessions">
35+
sessão WebDriver</a>. Cada sessão é assignada a um slot e cada Node tem
36+
um ou mais slots.
4837

4938
<dt>Session Map
50-
<dd>Maintains a mapping between the <a
51-
href="https://w3c.github.io/webdriver/#dfn-session-id">session
52-
ID</a> and the address of the Node the session is running on.
39+
<dd>Mantém um mapeamento entre um <a
40+
href="https://w3c.github.io/webdriver/#dfn-session-id">ID de sessão</a>
41+
e o endereço do Node onde a sessão está a ser executada.
5342

5443
<dt>Router
55-
<dd>Acts as the front-end of the Grid. This is the only part of the
56-
Grid which <i>may</i> be exposed to the wider Web (though we strongly
57-
caution against it). This routes incoming requests to either the
58-
New Session Queue or the Node on which the session is running.
44+
<dd>Este é o ponto de entrada da Grid. É também a única parte da Grid
45+
que <i>poderá</i> estar exposta à Internet (embora nós não recomendemos).
46+
Este componente reencaminha novos pedidos para New Session Queue ou
47+
para o Node onde a sessão esteja a ser executada
5948
</dl>
6049

61-
While discussing the Grid, there are some other useful concepts to
62-
keep in mind:
63-
64-
* A **slot** is the place where a session can run.
65-
* Each slot has a **stereotype**. This is the minimal set of
66-
capabilities that a [new session][] session request must match
67-
before the Distributor will send that request to the Node owning
68-
the slot.
69-
* The **Grid Model** is how the Distributor tracks the state of the
70-
Grid. As the name suggests, this may sometimes fall out of sync
71-
with reality (perhaps because the Distributor has only just
72-
started). It is used in preference to querying each Node so that
73-
the Distributor can quickly assign a slot to a New Session request.
74-
75-
## Synchronous and Asynchronous Calls
76-
77-
There are two main communication mechanisms used within the Grid:
78-
79-
1. Synchronous "REST-ish" JSON over HTTP requests.
80-
2. Asynchronous events sent to the Event Bus.
81-
82-
How do we pick which communication mechanism to use? After all, we
83-
could model the entire Grid in an event-based way, and it would work
84-
out just fine.
85-
86-
The answer is that if the action being performed is synchronous
87-
(eg. most WebDriver calls), or if missing the response would be
88-
problematic, the Grid uses a synchronous call. If, instead, we want to
89-
broadcast information to anyone who's interested, or if missing the
90-
response doesn't matter, then we prefer to use the event bus.
91-
92-
One interesting thing to note is that the async calls are more
93-
decoupled from their listeners than the synchronous calls are.
94-
95-
## Start Up Sequence and Dependencies Between Components
96-
97-
Although the Grid is designed to allow components to start up in any
98-
order, conceptually the order in which components starts is:
99-
100-
1. The Event Bus and Session Map start first. These have no other
101-
dependencies, not even on each other, and so are safe to start in
102-
parallel.
103-
2. The Session Queue starts next.
104-
3. It is now possible to start the Distributor. This will periodically
105-
connect to the Session Queue and poll for jobs, though this polling
106-
might be initiated either by an event (that a New Session has been
107-
added to the queue) or at regular intervals.
108-
4. The Router(s) can be started. New Session requests will be directed
109-
to the Session Queue, and the Distributor will attempt to find a
110-
slot to run the session on.
111-
5. We are now able to start a Node. See below for details about how
112-
the Node is registered with the Grid. Once registration is
113-
complete, the Grid is ready to serve traffic.
114-
115-
You can picture the dependencies between components this way, where a
116-
"✅" indicates that there is a synchronous dependency between the
117-
components.
50+
Ao falar da Grid, há alguns conceitos úteis a ter em mente:
51+
52+
* Um **slot** é o sítio onde uma sessão pode ser executada
53+
* Cada slot tem um **stereotype**. Isto é um conjunto mínimo de capacidades
54+
que um pedido de [nova sessão][new session] terá que corresponder antes que o
55+
Distributor envie esse pedido ao Node que tenha esse slot
56+
* O **Grid Model** é como o Distributor mantém o estado actual da Grid.
57+
Como o nome sugere, este modelo pode perder o sincronismo com a realidade.
58+
Este mecanismo é preferível do que estar a questionar cada Node, e
59+
desta forma, o Distributor rapidamente consegue alocar uma nova sessão a um slot.
60+
61+
62+
## Chamadas Síncronas e Assíncronas
63+
64+
Existem duas formas de comunicação dentro da Grid:
65+
66+
1. Chamadas Síncronas "REST-ish" que usam JSON sobre pedidos HTTP.
67+
2. Eventos Assíncronos enviados para o Event Bus.
68+
69+
Como é que escolhemos que tipo de mecanismo de comunicação a usar?
70+
Afinal, podiamos ter escolhido usar apenas comunicação baseada em eventos
71+
e tudo iria funcionar sem problemas.
72+
73+
No entanto a resposta correcta é, se a acção em curso é síncrona, por exemplo
74+
a maioria das chamadas WebDriver, ou se perder uma resposta é problemático,
75+
a Grid usa chamadas síncronas. Se quisermos propagar informação que pode ter
76+
várias partes interessadas, ou se perder a mensagem não for crítico,
77+
a Grid usará o event bus.
78+
79+
Um facto interessante a notar é que as chamadas assíncronas estão menos
80+
"presas" aos processos que as executam do que todas as chamadas síncronas.
81+
82+
## Sequência de início e dependencias entre componentes
83+
84+
Embora a Grid seja desenhada para permitir que os componentes possam iniciar
85+
em qualquer ordem, conceptualmente é esperado que a ordem de início seja:
86+
87+
1. O Event Bus e o Session Map iniciam primeiro. Estes componentes não tem qualquer
88+
dependencia, nem mesmo entre eles e como tal, podem iniciar em paralelo.
89+
2. A Session Queue inicia de seguida
90+
3. O Distributor inicia. Irá periodicamente procurar novos pedidos de sessão
91+
na Session Queue, embora possa também receber um evento de um pedidos de sessão.
92+
4. O Router pode ser agora iniciado. Novos pedidos de sessão são direccionados para
93+
a Session Queue, o Distributor tentará encontrar um slot onde a sessão possa ser
94+
executada.
95+
5. O Node pode ser iniciado, veja mais abaixo os detalhes de como o Node se
96+
regista na Grid. Uma vez que o registo esteja concluído, a Grid estará
97+
pronta a receber pedidos.
98+
99+
Nesta tabela pode ser visualizada a dependencia ente os vários componentes.
100+
Um "✅" indica que a dependência é síncrona.
101+
118102

119103
| | Event Bus | Distributor | Node | Router | Session Map | Session Queue |
120104
|---------------|-----------|-------------|------|--------|-------------|---------------|
@@ -125,66 +109,64 @@ components.
125109
| Session Map | | | | | X | |
126110
| Session Queue | ✅ | | | | | X |
127111

128-
## Node Registration
112+
## Registo de Node
129113

130-
The process of registering a new Node to the Grid is lightweight.
114+
O processo de registar um Node na Grid é um processo "leve".
131115

132-
1. When the Node starts, it should emit a "heart beat" event on a
133-
regular basis. This heartbeat contains the [node status].
134-
2. The Distributor listens for the heart beat events. When it sees
135-
one, it attempts to `GET` the `/status` endpoint of the Node. It
136-
is from this information that the Grid is set up.
116+
1. Quando um Node inicia, vai publicar um evento "heart beat" numa
117+
base regular. Este evento contém o estado do Node.
118+
2. O Distributor escuta os eventos "heart beat" e quando obtém um,
119+
tenta um `GET` ao endpoint `/status` do Node. A Grid é
120+
preparada com base nesta informação.
137121

138-
The Distributor will use the same `/status` endpoint to check the Node
139-
on a regular basis, but the Node should continue sending heart beat
140-
events even after started so that a Distributor without a persistent
141-
store of the Grid state can be restarted and will (eventually) be up
142-
to date and correct.
122+
O Distributor irá usar regularmente o endpoint `/status` para continuar
123+
a obter o estado do Node. Por seu lado, o Node continua a publicar um
124+
evento "heart beat" mesmo depois do registo ter sido concluído com
125+
sucesso.
126+
Isto é feito para que mesmo que um Distributor não tenha um estado
127+
da Grid possa reiniciar e assim obter novamente uma visão do estado
128+
da Grid e assim ficar actualizado.
143129

144-
### The Node Status Object
130+
### Objecto Node Status
145131

146-
The Node Status is a JSON blob with the following fields:
132+
O Node Status é um blob JSON com os seguintes campos:
147133

148-
| Name | Type | Description |
134+
| Nome | Tipo | Descrição |
149135
|------|------|-------------|
150-
| availability | string | A string which is one of `up`, `draining`, or `down`. The important one is `draining`, which indicates that no new sessions should be sent to the Node, and once the last session on it closes, the Node will exit or restart. |
151-
| externalUrl | string | The URI that the other components in the Grid should connect to. |
152-
| lastSessionCreated | integer | The epoch timestamp of when the last session was created on this Node. The Distributor will attempt to send new sessions to the Node that has been idle longest if all other things are equal. |
153-
| maxSessionCount | integer | Although a session count can be inferred by counting the number of available slots, this integer value is used to determine the maximum number of sessions that should be running simultaneously on the Node before it is considered "full". |
154-
| nodeId | string | A UUID used to identify this instance of the Node. |
155-
| osInfo | object | An object with `arch`, `name`, and `version` fields. This is used by the Grid UI and the GraphQL queries. |
156-
| slots | array | An array of Slot objects (described below) |
157-
| version | string | The version of the Node (for Selenium, this will match the Selenium version number) |
158-
159-
It is recommended to put values in all fields.
160-
161-
### The Slot Object
162-
163-
The Slot object represents a single slot within a Node. A "slot" is
164-
where a single session may be run. It is possible that a Node will
165-
have more slots than it can run concurrently. For example, a node may
166-
be able to run up 10 sessions, but they could be any combination of
167-
Chrome, Edge, or Firefox; in this case, the Node would indicate a "max
168-
session count" of 10, and then also say it has 10 slots for Chrome, 10
169-
for Edge, and 10 for Firefox.
170-
171-
| Name | Type | Description |
136+
| availability | string | Uma string com `up`, `draining`, ou `down`. A mais importante é `draining`, que indica que não devem ser enviados novos pedidos de sessão para o Node e assim que a última sessão termine, o Node irá reiniciar ou concluir. |
137+
| externalUrl | string | Uma URI que os outros componentes da Grid se devem ligar. |
138+
| lastSessionCreated | integer | Um timestamp da última sessão que foi criada neste Node. O Distributor irá tentar enviar novos pedidos de sessão para o Node que esteja parado há mais tempo. |
139+
| maxSessionCount | integer | Embora seja possível inferir o número máximo de sessões a partir da lista de slots disponíveis, este número é usado para determinar qual é o máximo de sessões que este Node pode executar em simultâneo antes que se considere que está "cheio". |
140+
| nodeId | string | Um identificador UUID para esta instância do Node. |
141+
| osInfo | object | Um objecto contendo os campos `arch`, `name`, e `version`. Isto é usado pela Grid UI e pelas queries GraphQL. |
142+
| slots | array | Um array de objectos Slot (descritos na secção seguinte) |
143+
| version | string | A versão do Node (para Selenium, será igual à versão do Selenium) |
144+
145+
É recomendado que todos os campos tenham valores.
146+
147+
### O Objecto Slot
148+
149+
O objecto Slot representa um slot dentro de um Node. Um "slot" é onde uma sessão consegue ser executada. É possível que um Node tenha mais do que um Slot capaz de executar ao mesmo tempo.
150+
Por exemplo, um Node pode ser capaz de executar até 10 sessões em simultâneo, mas podem ser uma qualquer combinação de Chrome, Firefox ou Edge e neste caso, o Node irá indicar 10 como o
151+
número máximo de sessões, indicando que podem ser 10 Chrome, 10 Firefox e 10 Edge.
152+
153+
| Nome | Tipo | Descrição |
172154
|------|------|-------------|
173-
| id | string | UUID to refer to the slot |
174-
| lastStarted | string | When the slot last had a session started, in ISO-8601 format |
175-
| stereotype | object | The minimal set of [capabilities][capabilities] this slot will match against. A minimal example is `{"browserName": "firefox"}` |
176-
| session | object | The Session object (see below) |
155+
| id | string | Um identificador UUID para este slot |
156+
| lastStarted | string | timestamp no formato ISO-8601 contendo a data em que a última sessão iniciou |
157+
| stereotype | object | Conjunto mínimo de [capacidades][capabilities] que fazem match com este slot. O exemplo mínimo será por exemplo `{"browserName": "firefox"}` |
158+
| session | object | O objecto Session (descrito na secção seguinte) |
177159

178-
### The Session Object
160+
### O Objecto Session
179161

180-
This represents a running session within a slot
162+
Representa uma sessão em execução dentro de um Slot
181163

182-
| Name | Type | Description |
164+
| Nome | Tipo | Descrição |
183165
|------|------|-------------|
184-
| capabilities | object | The actual capabilities provided by the session. Will match the return value from the [new session][new session] command |
185-
| startTime | string | The start time of the session in ISO-8601 format |
186-
| stereotype | object | The minimal set of [capabilities][capabilities] this slot will match against. A minimal example is `{"browserName": "firefox"}` |
187-
| uri | string | The URI used by the Node to communicate with the session |
166+
| capabilities | object | A lista de capacidades fornecidas pela sessão. Irá coincidir com o valor obtido pelo comando [nova sessão][new session] |
167+
| startTime | string | timestamp no formato ISO-8601 contendo a data em que a última sessão iniciou |
168+
| stereotype | object | Conjunto mínimo de [capacidades][capabilities] que fazem match com este slot. O exemplo mínimo será por exemplo `{"browserName": "firefox"}` |
169+
| uri | string | A URI usada pelo Node para comunicar com a sessão |
188170

189171
[capabilities]: https://w3c.github.io/webdriver/#dfn-merging-capabilities
190172
[new session]: https://w3c.github.io/webdriver/#new-session

0 commit comments

Comments
 (0)