Docker-compose swagger-ui 不依赖于特定 URL 的设置
Docker-compose swagger-ui setup which doesn't depend on a particular URL
我想将 swagger-ui 添加到我的 docker-compose 设置中。我正在使用 postgres 和 postgrest。我的设置大致如下:
version: '3'
services:
postgrest:
image: postgrest/postgrest
ports:
- 3000:3000
links:
- postgres
postgres:
image: postgres
ports:
- 5432:5432
volumes:
- "./pgdata:/var/lib/postgresql/data"
swagger:
image: swaggerapi/swagger-ui
expose:
- 8080
ports:
- 8080:8080
links:
- postgrest:postgrest
environment:
API_URL: http://localhost:3000
当我在本地测试时,这向我展示了正确的 API 文档 UI。当我部署时,http://localhost:3000 不再提供 OpenAPI 定义,这就中断了。我可以将 API_URL 更改为远程 URL,但是如果我正在测试某些更改,它不会在本地更新,而且这通常似乎无法解决问题。
有没有办法让 swagger 指向 "the postgrest running in the same docker compose setup"?类似于:
swagger:
...
links:
- postgrest:postgrest
environment:
API_URL: http://postgrest:3000
有时 docker compose 可以像这样变魔术,例如在 nginx 中。
提前致谢!
虽然您在 docker-compose.yml
中设置了 API_URL
,但我相信获取规范文件的实际请求是由浏览器完成的。
因此,您的浏览器应该能够解析 URL,而不是 swagger-ui 容器本身。
此外,由于是这种情况,您根本不需要托管远程 Swagger UI。只需有一个单独的 swagger-ui 运行 本地容器,并在需要时在 UI 本身中将 URL 更改为 swagger 文件。
更新:使用SWAGGER_JSON
version: "3"
services:
postgrest:
image: postgrest/postgrest
ports:
- 3000:3000
environment:
PGRST_DB_URI: postgres://app_user:password@postgres:5432/app_db
PGRST_DB_SCHEMA: public
PGRST_DB_ANON_ROLE: app_user
depends_on:
- postgres
postgres:
image: postgres
ports:
- 5435:5432
environment:
POSTGRES_DB: app_db
POSTGRES_USER: app_user
POSTGRES_PASSWORD: password
volumes:
- "./pgdata:/var/lib/postgresql/data"
save-swagger:
image: busybox
depends_on:
- postgrest
volumes:
- swagger-json:/spec
command: >
/bin/sh -c "sleep 15
&& mkdir -p /spec
&& wget -O /spec/swagger.json http://postgrest:3000"
swagger:
image: swaggerapi/swagger-ui
expose:
- 8080
ports:
- 8029:8080
links:
- postgrest:postgrest
environment:
SWAGGER_JSON: /spec/swagger.json
volumes:
- swagger-json:/spec
volumes:
swagger-json:
请注意,使用 sleep
并不是最好的方法。您可以查看更好的选项,例如使用 wait-on / wait-for / wait-for-it
PS:我已尝试 wait-for
和 wait-for-it
,但由于 postgrest
的端点可用,即使与数据库的连接不成功,它正在以 503
进行响应,并且这两个实用程序仅检查 TCP 套接字可用性,因此不会按预期在此处工作。
wait-on
可以工作,因为它会在 HEAD 请求上检查 2xx
,但你需要一个带有 nodejs 的容器,所以我坚持使用 sleep
作为必须完成的最简单的例子。 :)
我想将 swagger-ui 添加到我的 docker-compose 设置中。我正在使用 postgres 和 postgrest。我的设置大致如下:
version: '3'
services:
postgrest:
image: postgrest/postgrest
ports:
- 3000:3000
links:
- postgres
postgres:
image: postgres
ports:
- 5432:5432
volumes:
- "./pgdata:/var/lib/postgresql/data"
swagger:
image: swaggerapi/swagger-ui
expose:
- 8080
ports:
- 8080:8080
links:
- postgrest:postgrest
environment:
API_URL: http://localhost:3000
当我在本地测试时,这向我展示了正确的 API 文档 UI。当我部署时,http://localhost:3000 不再提供 OpenAPI 定义,这就中断了。我可以将 API_URL 更改为远程 URL,但是如果我正在测试某些更改,它不会在本地更新,而且这通常似乎无法解决问题。
有没有办法让 swagger 指向 "the postgrest running in the same docker compose setup"?类似于:
swagger:
...
links:
- postgrest:postgrest
environment:
API_URL: http://postgrest:3000
有时 docker compose 可以像这样变魔术,例如在 nginx 中。
提前致谢!
虽然您在 docker-compose.yml
中设置了 API_URL
,但我相信获取规范文件的实际请求是由浏览器完成的。
因此,您的浏览器应该能够解析 URL,而不是 swagger-ui 容器本身。
此外,由于是这种情况,您根本不需要托管远程 Swagger UI。只需有一个单独的 swagger-ui 运行 本地容器,并在需要时在 UI 本身中将 URL 更改为 swagger 文件。
更新:使用SWAGGER_JSON
version: "3"
services:
postgrest:
image: postgrest/postgrest
ports:
- 3000:3000
environment:
PGRST_DB_URI: postgres://app_user:password@postgres:5432/app_db
PGRST_DB_SCHEMA: public
PGRST_DB_ANON_ROLE: app_user
depends_on:
- postgres
postgres:
image: postgres
ports:
- 5435:5432
environment:
POSTGRES_DB: app_db
POSTGRES_USER: app_user
POSTGRES_PASSWORD: password
volumes:
- "./pgdata:/var/lib/postgresql/data"
save-swagger:
image: busybox
depends_on:
- postgrest
volumes:
- swagger-json:/spec
command: >
/bin/sh -c "sleep 15
&& mkdir -p /spec
&& wget -O /spec/swagger.json http://postgrest:3000"
swagger:
image: swaggerapi/swagger-ui
expose:
- 8080
ports:
- 8029:8080
links:
- postgrest:postgrest
environment:
SWAGGER_JSON: /spec/swagger.json
volumes:
- swagger-json:/spec
volumes:
swagger-json:
请注意,使用 sleep
并不是最好的方法。您可以查看更好的选项,例如使用 wait-on / wait-for / wait-for-it
PS:我已尝试 wait-for
和 wait-for-it
,但由于 postgrest
的端点可用,即使与数据库的连接不成功,它正在以 503
进行响应,并且这两个实用程序仅检查 TCP 套接字可用性,因此不会按预期在此处工作。
wait-on
可以工作,因为它会在 HEAD 请求上检查 2xx
,但你需要一个带有 nodejs 的容器,所以我坚持使用 sleep
作为必须完成的最简单的例子。 :)