You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> Note: if you're on an ARM machine, you have to add the `--platform` flag to the command above, since the published image is built only for the `x86_64` architecture:
83
+
>
80
84
> ```bash
81
85
> docker run --platform linux/amd64 -p 8080:8080 omniadevs/ic-websocket-gateway --ic-network-url http://host.docker.internal:4943
82
86
> ```
@@ -89,9 +93,9 @@ Make sure you have [Docker Compose](https://docs.docker.com/compose/install/) in
The following sections describe how to use the different compose files to run the gateway with Docker Compose.
97
101
@@ -100,36 +104,34 @@ A visual representation of the containers in the compose files is provided in th
100
104
### Local
101
105
102
106
To run the gateway in a local environment with Docker Compose, follow these steps:
107
+
103
108
1. To run all the required local structure you can execute the [start_local_docker_environment.sh](./scripts/start_local_docker_environment.sh) with the command:
104
-
105
-
```
106
-
./scripts/start_local_docker_environment.sh
109
+
110
+
```
111
+
./scripts/start_local_docker_environment.sh
107
112
```
108
113
109
114
This script simply run a dfx local replica and execute the gateway with the following command:
2. To stop and clean all the local environment, the bash script [stop_local_docker_environment.sh](./scripts/stop_local_docker_environment.sh) is provided. You can execute it with the command:
116
-
117
-
```
118
-
./scripts/stop_local_docker_environment.sh
121
+
122
+
```
123
+
./scripts/stop_local_docker_environment.sh
119
124
```
120
125
121
126
3. The Gateway will print its principal in the container logs, just as explained in the [Standalone](#standalone) section.
122
-
4. If you want to verify that everything started correctly, the bash script [run_test_canister.sh](./scripts/run_test_canister.sh) is provided. This script assumes that the gateway is already running and reachable locally. You can execute it with the command:
123
-
124
-
```
125
-
./scripts/run_test_canister.sh
126
-
```
127
+
4. You can verify that things are working properly by running the tests, see [Testing](#Testing)
127
128
128
129
### Production
129
130
130
131
This configuration uses the [omniadevs/ic-websocket-gateway](https://hub.docker.com/r/omniadevs/ic-websocket-gateway) image.
131
132
132
133
To run the gateway in a production environment with Docker Compose, follow these steps:
134
+
133
135
1. Set the environment variables:
134
136
135
137
```
@@ -140,21 +142,22 @@ To run the gateway in a production environment with Docker Compose, follow these
140
142
3. Open the `443` port (or the port that you set in the `LISTEN_PORT` environment variable) on your server and make it reachable from the Internet.
141
143
4. To run all the required production containers you can execute the [start_prod_docker_environment.sh](./scripts/start_prod_docker_environment.sh) with the command:
142
144
143
-
```
144
-
./scripts/start_prod_docker_environment.sh
145
+
```
146
+
./scripts/start_prod_docker_environment.sh
145
147
```
146
148
147
-
This script first generates the `telemetry/prometheus/prometheus-prod.yml` config file from the `telemetry/prometheus/prometheus-template.yml` template (step required to perform the environment variables substitution) and then runs the gateway with the following command:
149
+
This script first generates the `telemetry/prometheus/prometheus-prod.yml` config file from the `telemetry/prometheus/prometheus-template.yml` template (step required to perform the environment variables substitution) and then runs the gateway with the following command:
148
150
149
151
```
150
152
docker compose -f docker-compose.yml -f docker-compose-prod.yml --env-file .env up -d
151
153
```
152
154
153
155
5. To stop and clean the containers, the bash script [stop_prod_docker_environment.sh](./scripts/stop_prod_docker_environment.sh) is provided. You can execute it with the command:
154
156
155
-
```
156
-
./scripts/stop_prod_docker_environment.sh
157
157
```
158
+
./scripts/stop_prod_docker_environment.sh
159
+
```
160
+
158
161
6. The Gateway will print its principal in the container logs, just as explained in the [Standalone](#standalone) section.
159
162
160
163
#### Obtain a TLS certificate
@@ -198,13 +201,15 @@ The gateway uses the [opentelemetry](https://docs.rs/opentelemetry) crate and [G
198
201
If you're deploying the gateway with Docker (see the [Docker](#docker) section), make sure you set the following varibales in the `.env` file:
@@ -240,19 +245,21 @@ After installing Node.js and dfx, you can run the integration tests as follows:
240
245
241
246
1. Prepare the test environment by installing dependencies and building the components by running the following command:
242
247
```
243
-
./scripts/prepare_integration_tests.sh
248
+
./scripts/prepare_tests.sh
244
249
```
245
250
2. Set the environment variables:
246
251
```
247
252
cp tests/.env.example tests/.env
248
253
```
249
-
When running the tests, the `tests/.env` file is modified by dfx, which will add some variables.
254
+
When running the tests, the `tests/.env` file will be modified by dfx to add some variables.
250
255
3. Run integration tests using the Rust test canister:
256
+
251
257
```
252
258
./scripts/integration_test_rs.sh
253
259
```
254
260
255
-
If you instead want to run tests using the Motoko test canister, run the following command instead:
261
+
If you want to run tests using the Motoko test canister, run the following command instead:
262
+
256
263
```
257
264
./scripts/integration_test_mo.sh
258
265
```
@@ -263,21 +270,21 @@ Tests canisters used in the integration tests can be found in the [tests/src/tes
263
270
264
271
### Local test script
265
272
266
-
After setting up and running the tests for the first time following the steps above, you can use the following command to run the unit and integration tests (using Rust testcanister) together:
273
+
After setting up and running the tests for the first time following the steps above, you can use the following command to run the unit and integration tests (using both the Rust and Motoko testcanisters):
267
274
268
275
```
269
276
./scripts/local_test.sh
270
277
```
271
278
272
279
### Load tests
273
280
274
-
Load tests are provided in the [tests/src/load](./tests/src/load/) folder. You can run them with:
281
+
We use [Artillery](https://github.com/artilleryio/artillery) to run load tests. The load test configuration is provided in the [tests/gateway_load_tests.yml](./tests/gateway_load_tests.yml) file and the source code is provided in the [tests/src/load](./tests/src/load/) folder. You can run them with:
275
282
276
283
```
277
284
./scripts/run_load_test.sh
278
285
```
279
286
280
-
This script requires you to set up the test environment manually, because you usually want to keep an eye on the logs of the different components. You have to start the local replica, start the gateway and deploy the test canister. The [scripts/integration_test_rs.sh](./scripts/integration_test_rs.sh) is a good reference for how to do that.
287
+
This script requires you to set up the test environment manually, because you usually want to keep an eye on the logs of the different components. You have to start the local replica, start the gateway and deploy the test canister. The [scripts/ci_cd_test_load.sh](./scripts/ci_cd_test_load.sh) is a good reference for how to do that.
0 commit comments