Skip to content
This repository has been archived by the owner on Dec 17, 2024. It is now read-only.

Support macvlan network #795

Closed
giggio opened this issue Sep 4, 2019 · 6 comments
Closed

Support macvlan network #795

giggio opened this issue Sep 4, 2019 · 6 comments

Comments

@giggio
Copy link

giggio commented Sep 4, 2019

I am using a macvlan network on Docker, and I'm getting an error message:

[SERVICE_STARTUP_FAILED] [no bindings available for 4444/tcp]

On a Macvlan network all ports are exposed, but it seems that Selenoid is not able to understand that somehow.

This is the line that seems to be doing it:

return nil, fmt.Errorf("no bindings available for %v", selenium)

@vania-pooh vania-pooh changed the title "No bindings available" when using macvlan network Support macvlan network Sep 4, 2019
@vania-pooh
Copy link
Member

@giggio we have never used macvlan mode with Docker, so yes - currently Selenoid does not support macvlan I think.

@giggio
Copy link
Author

giggio commented Sep 4, 2019

I was able to get it to work with a workaround. I added solenoid to both networks. This is my docker-compose.yaml (lan_net is a macvlan network, solenoidnet is a regular bridge network):

version: '3.7'
services:
  selenoid:
    build:
      context: .
      dockerfile: Dockerfile.selenoid
    image: lambda3/selenoid
    container_name: selenoid
    environment:
      - TZ=America/Sao_Paulo
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./config/:/etc/selenoid/:ro
    restart: always
    command: [ "-listen", ":4444", "-conf", "/etc/selenoid/browsers.json", "-video-output-dir", "/opt/selenoid/video/", "-container-network", "selenoidnet" ]
    ports:
     - "4444:4444" # unnecessary, but needed because of selenoid
    networks:
      lan_net:
        ipv4_address: 10.237.107.246
      selenoidnet: {}
  selenoidui:
    build:
      context: .
      dockerfile: Dockerfile.selenoidui
    image: lambda3/selenoidui
    container_name: selenoidui
    environment:
      - TZ=America/Sao_Paulo
    restart: always
    depends_on:
      - selenoid
    command: --selenoid-uri=http://selenoid:4444 --listen :80
    networks:
      lan_net:
        ipv4_address: 10.237.107.245
      selenoidnet: {}
networks:
  lan_net:
    external:
      name: lan_net
  selenoidnet:
    external:
      name: selenoidnet

This works, and maybe there is nothing else you need to do, just maybe document it. The containers get created on a bridge network, which is fine, as we only need access to Solenoid and the UI, not the browser containers. I still need to test VNC etc, but this seems fine.

@vania-pooh vania-pooh added the docs label Sep 4, 2019
@vania-pooh vania-pooh added this to the 1.9.3 milestone Sep 4, 2019
@vania-pooh
Copy link
Member

@giggio ok, will document it. Thank you for clarification!

@giggio
Copy link
Author

giggio commented Sep 4, 2019

Ok, I evolved it to a simpler design, adding a reverse nginx proxy. It could be a good alternative to the one I posted above. I leave all the selenoid machinery on one network, not a macvlan, and then I add an nginx proxy to both the selenoid network and the macvlan network. It worked perfectly.

version: '3.7'
services:
  selenoid:
    build:
      context: .
      dockerfile: Dockerfile.selenoid
    image: lambda3/selenoid
    container_name: selenoid
    environment:
      - TZ=America/Sao_Paulo
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./config/:/etc/selenoid/:ro
    restart: always
    command: [ "-listen", ":4444", "-conf", "/etc/selenoid/browsers.json", "-video-output-dir", "/opt/selenoid/video/", "-container-network", "selenoidnet" ]
    networks:
      selenoidnet: null
  selenoidui:
    build:
      context: .
      dockerfile: Dockerfile.selenoidui
    image: lambda3/selenoidui
    container_name: selenoidui
    environment:
      - TZ=America/Sao_Paulo
    restart: always
    depends_on:
      - selenoid
    command: --selenoid-uri=http://selenoid:4444 --listen :80 -allowed-origin *
    networks:
      lan_net:
        ipv4_address: 10.237.107.245
      selenoidnet: null
  selenoidproxy:
    image: nginx:1.17-alpine
    container_name: selenoidproxy
    networks:
      lan_net:
        ipv4_address: 10.237.107.246
      selenoidnet: null
    environment:
      - TZ=America/Sao_Paulo
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./certs/lambda3.com.br.crt:/etc/ssl/lambda3.com.br.crt
      - ./certs/lambda3.com.br.key:/etc/ssl/lambda3.com.br.key
    restart: always
networks:
  lan_net:
    external:
      name: lan_net
  selenoidnet:
    external:
      name: selenoidnet

@vania-pooh
Copy link
Member

vania-pooh commented Oct 6, 2019

@giggio before I add this to docs - could you please clarify what's the reason of using Macvlan networks in your case? According to docs it's mainly useful for legacy applications.

@giggio
Copy link
Author

giggio commented Oct 8, 2019

Using a Macvlan net I am able to assign an ip address to the container that is different from the host. From there I can assign a name from a dns, work on firewall rules etc.
If I don't do that I have to use the Docker host's ip address.

@vania-pooh vania-pooh modified the milestones: 1.9.3, 1.9.4 Oct 27, 2019
vania-pooh added a commit that referenced this issue Dec 18, 2019
Added FAQ section about macvlan network (fixes #795)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants