包含多个服务的 Docker 容器
我正在尝试构建一个包含 3 个应用程序的容器，例如：
- Grafana；
- 节点-RED；
- NGINX。
因此，我只需要公开一个 por，例如：
端口 3001/grafana 上的 NGINX 反向代理重定向到端口 3000 上的 grafana； 端口 3001/nodered 上的 NGINX 反向代理重定向到端口 1880 上的 nodered。
在您看来，这有意义吗？或者说这种架构与 docker compose 相比不可行？
I am trying to build a container containing 3 applications, for example:
- Grafana;
- Node-RED;
- NGINX.
So I will just need to expose one por, for example:
NGINX reverse proxy on port 3001/grafana redirects to grafana on port 3000 and;
NGINX reverse proxy on port 3001/nodered redirects to nodered on port 1880.
Does it make any sense in your vision? Or this architecture is not feasible if compared to docker compose?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果我正确理解，您的担心是仅公开开设一个港口。
为此，最好是构建3个单独的容器，每个容器都有自己的服务，均在同一Docker Network 中。您可以像虚拟网络中所描述的那样插入服务，而不是在同一容器中。
为什么 ？由于容器是专门设计的，可以为单个应用程序保存环境，以便提供隔离并减少兼容性问题，因此所有网络配置都在更高级别的所有网络配置中，在容器之外进行。
在同一容器中，将所有服务放在挫败同一容器中，这些都提到了容器化应用程序的优势。几乎就像您甚至不使用容器一样。
If I understand correctly, your concern is about opening only one port publicly.
For this, you would be better off building 3 separate containers, each with their own service, and all in the same docker network. You could plug your services like you described within the virtual network instead of within the same container.
Why ? Because containers are specifically designed to hold the environment for a single application, in order to provide isolation and reduce compatibility issues, with all the network configuration done at a higher level, outside of the containers.
Having all your services inside the same container thwart these mentioned advantages of containerized applications. It's almost like you're not even using containers.