Docker：尝试联系同一容器中的应用程序时出现卷曲错误答案

【问题标题】：Docker: Curl errors when attempting to contact app in same containerDocker：尝试联系同一容器中的应用程序时出现卷曲错误
【发布时间】：2016-08-04 08:42:06
【问题描述】：

我在 Docker 和 cURL 方面遇到了一些问题。

我有一个 Docker-compose 容器设置如下：

app:
  image: busybox
  volumes:
    - /home/ben/dev/dummy/www/:/data/www/
    - /home/ben/dev/dummy/logs/:/data/logapache/
    - /home/ben/dev/dummy/flux-entrants/:/data/flux-entrants/
nginx:
  image: docker.dummy.fr/nginx
  volumes_from:
   - app
  ports:
   - 80:80
  links:
   - php
php:
  image: docker.dummy.fr/actus-php
  volumes_from:
   - app
  ports:
   - 9000:9000
  links:
   - db
   - nosql
db:
  image: docker.dummy.fr/mysql-5.6
  environment:
    MYSQL_ROOT_PASSWORD: root
nosql:
  image: docker.dummy.fr/lp-nosql
  ports:
    - "9200:9200"

还有一些 extra_hosts 指令，出于保密原因，我在这里删除了它们，但主机也在 nginx（当然映射到端口 80）和容器 /etc/hosts 中配置

所以，nginx、php、mysql 和 elasticsearch 都在不同的容器中。 nginx 容器 链接到 php 容器，后者链接到另外两个。这工作得很好，特别是没有问题。

在这些容器中，我运行两个 Web 应用程序，如额外的主机所示：一个前端客户端（Symfony 2.8）和一个后端 API（也是 Symfony 2.8）。

现在问题来了。

当我尝试从 php 容器 外部联系 API 应用程序 时，通常是 Postman，或从我的 linux 终端的 cURL cli，或来自 的 cURL >nginx容器，没问题。

但是当 front 应用程序（在同一个容器中）尝试联系 API 应用程序，或者当我尝试从 php 容器内卷曲时，我收到 cURL 错误“连接被拒绝”。详细模式显示甚至没有发送标头。

我以为是端口映射问题，但是更改端口、打开新端口并尝试通过这些端口连接也不起作用。

我尝试通过端口 9000 联系它（用于 nginx 上游并在 docker-compose 中打开），但随后我收到另一个错误：“Recv failure: Connection reset by peer”。详细模式显示标头和请求已正确发送，然后服务器断开连接。

有人遇到过这个问题吗？如果是，您是如何解决的？我在这里搜索但找不到相同的问题。

非常感谢。

编辑：

我刚刚尝试为每个应用程序（前端和 API）制作两组单独的容器（一个 PHP 容器 + 一个 Nginx 容器），将每个应用程序分别安装在自己的容器中，但我仍然遇到同样的问题。我就是不明白。

【问题讨论】：

不清楚从哪个容器内部尝试通过 cURL 建立什么连接？什么是 API？也请附上运行容器的 docker ps 输出。
我有四个容器，其中一个专门用于 php（在 docker-compose 中命名为 php）。在这个容器内有两个不同的 Symfony 应用程序：一个前端客户端应用程序和一个后端/API 应用程序。当我从终端、Postman 或 php 容器之外的任何地方卷曲 API 应用程序时，一切正常。当前端尝试调用 API 时，或者当我尝试从 php 容器内卷曲 API 时，它不起作用。
您能否提供您的 cURL 命令和“docker ps”的输出

标签： php curl nginx docker docker-compose

【解决方案1】：

基本问题是 php 容器 对自身的请求没有发出，因此没有通过 nginx 容器 可以正确调度它们。 p>

我们最终通过在 API 应用程序（在 php 容器内）中使用 symfony 命令php app/console server:start 0.0.0.0:80 进行了快速修复。基本上，我们启动了第二个 php 服务器，然后每个应用程序都有一个服务器，让它们能够正常通信。

适当的修复和（imo）更好的设计是将 nginx 和 php 容器合并为一个容器。为服务器和数据库设置单独的容器似乎是合法的，但是为服务器和解释器设置单独的容器会导致太多问题。

【讨论】：