[hbyecoding]

fix 类型

问题描述

当前 OpenVSX 的 Docker 部署存在以下问题：

1. Server 服务启动失败 (Exit 127)
2. Elasticsearch 健康检查失败
3. 服务依赖关系配置不合理

修复内容

Docker 配置优化

1. 修改 server 镜像

   • 从 openjdk:17 更改为 openjdk:17-bullseye
   • 添加必要工具: curl, findutils 等

2. 优化 Elasticsearch 配置

   • 调整内存设置
   • 改进健康检查机制
   • 优化启动顺序

3. 服务依赖关系

   • 移除不必要的 cli 服务
   • 保留并优化 webui 服务
   • 完善服务间的依赖关系配置

文档改进

1. 新增 docs/docker-deployment-fix.md
   • 详细的部署步骤说明
   • 配置示例和最佳实践
   • 常见问题排查指南

验证方法

1. 清理现有容器和卷:

docker-compose down -v

2. 使用新配置启动服务:

docker-compose --profile openvsx up -d

3. 验证服务状态:

docker-compose ps
docker-compose logs

hongbo@coduora openvsx (fix/docker-deployment) $ docker-compose ps -a
Name Command State Ports

---

openvsx_elasticsearch_1 /bin/tini -- /usr/local/bi ... Up (healthy) 0.0.0.0:9200->9200/tcp,:::9200->9200/tcp,
0.0.0.0:9300->9300/tcp,:::9300->9300/tcp
openvsx_postgres_1 docker-entrypoint.sh postgres Up 0.0.0.0:5432->5432/tcp,:::5432->5432/tcp
openvsx_server_1 bash -c Up (health: starting) 0.0.0.0:8080->8080/tcp
apt-get update ...
openvsx_webui_1 docker-entrypoint.sh sh -c ... Up 0.0.0.0:3000->3000/tcp

例如 docker-compose logs -f server

server_1 | Downloading https://services.gradle.org/distributions/gradle-8.1.1-bin.zip
server_1 | ...........10%............20%............30%............40%............50%............60%............70%............80%...........90%............100%
server_1 |
server_1 | Welcome to Gradle 8.1.1!
server_1 |
server_1 | Here are the highlights of this release:
server_1 | - Stable configuration cache
server_1 | - Experimental Kotlin DSL assignment syntax
server_1 | - Building with Java 20
server_1 |
server_1 | For more details see https://docs.gradle.org/8.1.1/release-notes.html
server_1 |
server_1 | Starting a Gradle Daemon (subsequent builds will be faster)
server_1 | 2025-06-10T05:24:21.496Z INFO [openvsx-server,,] 680 --- [openvsx-server] [ restartedMain] [ ] o.eclipse.openvsx.RegistryApplication : Started RegistryApplication in 15.715 seconds (process running for 16.369)

4. 检查3000 是否curl 通：

curl -I localhost:3000
HTTP/1.1 200 OK
X-Powered-By: Express
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Last-Modified: Tue, 10 Jun 2025 01:45:47 GMT
ETag: W/"160-1975783d7e1"
Content-Type: text/html; charset=UTF-8
Content-Length: 352
Date: Tue, 10 Jun 2025 05:25:07 GMT
Connection: keep-alive
Keep-Alive: timeout=5

5. 检查 PostgreSQL: 5432

telnet localhost 5432

Trying 127.0.0.1... # 正在尝试连接到本地主机的 IP 地址
Connected to localhost. # 成功连接到本地主机
Escape character is '^]'. # 退出 telnet 的快捷键是 Ctrl + ]

6. 检查 8080 是否 healthy:

curl http://localhost:8080/actuator/health

curl http://localhost:8080/actuator/health
{"status":"UP","groups":["liveness","readiness"]}

注意事项

• 首次启动时 Elasticsearch 可能需要 1-2 分钟完成初始化
• 我这里的 compose 是 v1 版本的 ， 用的是 docker-compose 命令

[netomi]

Thanks for this, and apologies it sat so long.

I went through it against the current docker-compose.yml. Two of your changes have since landed independently — the ES_JAVA_OPTS memory settings and the memlock ulimits are both in main now — and some of the rest was overtaken by the file moving on (the base image is eclipse-temurin:25-jdk these days, so the openjdk:17-bullseye fix no longer applies).

But three of the problems you reported are still there, and I have opened #2182 for them:

1. The profiles are broken. docker compose --profile openvsx up fails with service "server" depends on undefined service "postgres": invalid compose project, because server is in the openvsx profile and postgres is not. Adding those services to the profile — exactly what you did — is the fix. Our own doc/development.md gives that command as the way to start a dev stack, so it is the first thing a new contributor hits.

2. The elasticsearch healthcheck names a host that does not exist (elasticsearch01). From inside the container it is exit 6 while the cluster is green, so it never went healthy.

3. The server healthcheck could only ever exit 127 — the same class of failure you hit, just moved to a newer base image: eclipse-temurin:25-jdk has no curl, wget, nc or python. I used bashs /dev/tcp rather than apt-get install curl on every start, so there is no network round trip per up, but your diagnosis was right.

And with 2 and 3 fixed, depends_on: condition: service_healthy finally works, which was the ordering problem you originally described.

#2182 credits you and closes this one. Sorry again for the delay — the report was correct, it just needed re-basing onto a file that had changed a lot underneath it.