Multi-container app not working

General
,
1

Hello
I am trying to get a multi-container app to work. Container ibeam connects to a server and establishes a local host on port 5000, container bot queries the ibeam container for data which is then processed in a script.
The app runs, but the bot container can’t access the ibeam container. The app works outside of docker so I think the network connection between them is the issue.
Thanks for your help.

This is my compose file

name: bot-app
services:
  ibeam:
    image: voyz/ibeam
    container_name: ibeam-app
    env_file:
      - env.list
    ports:
      - 127.0.0.1:5000:5000
      - 127.0.0.1:5001:5001
    network_mode: bridge # Required due to clientportal.gw IP restrictions
    restart: 'no' # Prevents IBEAM_MAX_FAILED_AUTH from being exceeded

  bots:
    image: bot-hl
    container_name: bot-hl-app
    networks:
      - default
2

Use 3 backticks before and after code to make it more readable and preserve spacing, which is important for yaml.

1 Like
3

Not quotation marks, backticks as @bluepuma77 suggested. Also indent the yaml properly, please. Here is a more detailed instruction:

Please, format your post according to the following guide: How to format your forum posts
In short: please, use </> button to share codes, terminal outputs, error messages or anything that can contain special characters which would be interpreted by the MarkDown filter. Use the preview feature to make sure your text is formatted as you would expect it and check your post after you have sent it so you can still fix it.

Example code block:

```
echo "I am a code."
echo "An athletic one, and I wanna run."
```

After editing your post, please, write a new comment so users will be notified about the change. Thank you.

1 Like
4

I see you edited your post.Normally I would say there is not enough information as we don’t know how you try to connect, but the fact that you use the bridge network mode ifor ibeam and the default compose project network for bots makes it clear, the two containers are in two different networks and they have to be in the same network in order to communicate. And the “bridge” mode means that the container will be on the default docker bridge not ona custom bridge network created by compose. container names and service names can only be used as domain names in URLs when using the custom (user-defined) docker bridge like those created by compose.

Why did you need to use the bridge mode? Can you explain the comment next to it?

5

Thanks for taking a look.
I didn’t write the ibeam code, I pulled it from a Github repo, the comment is the authors’, and I think it’s needed to access the local host in the container.

vs code test
If I remove the network: bridge line in the ibeam compose file, bot-hl running in vs code can’t access the localhost, but it can access localhost if network:bridge is used.

app network test
I tried removing network:bridge and creating a network in the app compose file (see below), but the bot-hl-app container can’t connect to the ibeam-app localhost.

name: bot-app
services:
  ibeam:
    image: voyz/ibeam
    container_name: ibeam-app
    env_file:
      - env.list
    ports:
      - 127.0.0.1:5000:5000
      - 127.0.0.1:5001:5001
    networks:
      - my-network
    # network_mode: bridge # Required due to clientportal.gw IP restrictions
    restart: 'no' # Prevents IBEAM_MAX_FAILED_AUTH from being exceeded

  bots:
    image: bot-hl
    container_name: bot-hl-app
    networks:
      - my-network

networks:
  my-network:
    external: true
6

If you mean accessing the localhost of the host machine from a container, that is not possible. The only way would be using the host network, which means “I don’t need network isolation”. In which case you couldn’t use port mappings and only one container could have a process using a specific port.

As I described above, that is not possible. The one network mode that uses the host network is network_mode: host. Only with Docker CE, since Docker Desktop runs a virtual machine and the experimental host network mode just adds some workaround to forward request to the hosts localhost whch is not always enough.

Then you could ask the authors on GitHub since we don’t know how the application should work, but normally you would use the default compose network or additional user-defined networks, so containers on the same network could communicate. The default bridge network will not allow you to use a compose service name in a curl command for example.

If you can provide some commands that you can run in a terminal to demostrate what command should work which doesn’t, maybe we realize what the author meant by that bridge mode, but I don’t understand yet.

7

Thanks for your help. I will reach out to the ibeam author.