Remote Instance with docker

[loranger]

Hello,

Did one of you was able to make Browsershot works with remote instance using docker ?

I'd like to use it remoteley, inspired by jamesjudd, but failed.

version: '3'

services:

  nginx:
    (...)

  php-fpm:
    (...)

  chrome:
    image: 'zenika/alpine-chrome:80'
    entrypoint: ["chromium-browser", "--headless", "--disable-gpu", "--disable-software-rasterizer", "--disable-dev-shm-usage", "--no-sandbox", "--remote-debugging-address=0.0.0.0", "--remote-debugging-port=9222"]
    ports:
        - 9222:9222
    networks:
      - web

(...)

networks:
  web:
    external: true

Browsershot/Puppeteer always try to spawn a local chrome even if I use a remote instance

    Browsershot::url('https://www.ebsi.te')
        ->setRemoteInstance('chrome', 9222)
        ->save($pathToImage);

[mouuuton]

@loranger did you manage to make it work?

[loranger]

Unfortunately, no.
I gave up :(

[pablodiegoss]

It's been a long time since you asked, but I got it working on Docker. Well... not a simple solution, but may help someone in the future.

1- Getting a static IP

The first problem is that browsershot doesn't work with DNS names for services on docker, only IPs.

So:

->setRemoteInstance('chrome', 9222)
# Should be the docker internal IP
->setRemoteInstance('172.0.X.X', 9222)

However we usually don't have control over IPs on composes and containers.
For that to work, you will need to create a network or override the default and manually specify your IPs. IPs are given sequentially, so for the static ones, i've set the last ones to avoid problems with other services you might have on your compose.

services:
  chrome:
    image: your_chrome_image
    ports:
      - "9222:9222"
    networks:
      default:
        ipv4_address: 10.0.0.254

  web:
    image:
    ports:
      - "80:80"
    networks:
      default:
        ipv4_address: 10.0.0.253
    depends_on:
      chrome:
        condition: service_started

networks:
  default:
    name: your_docker_network
    driver: bridge
    ipam:
     config:
       - subnet: 10.0.0.0/16
         gateway: 10.0.0.1

Now you can confidently use `10.0.0.254" as your chrome IP, since you've forced it.

->setRemoteInstance('10.0.0.254', 9222)

2- Static content

The compose above might have solved your issues, but... If you have static content linked inside the html locally, now we have the reverse problem, the container running chrome doesn't know how to resolve the URLs for stuff like "http://localhost/mywebsite/user_profile_picture.jpg", since inside the chrome container "localhost" means the container running chrome, and not your webserver container. So that becomes a whole mess with chrome and you will need to teach your container to solve these DNS queries, with something like this:

  chrome:
    image: your_chrome_image
    ports:
      - "9222:9222"
    command: google-chrome \
      --headless \
      --disable-gpu \
      --remote-debugging-address=0.0.0.0 \
      --remote-debugging-port=9222 \
      --disable-software-rasterizer \
      --font-render-hinting=none \
      --no-sandbox \
      --host-resolver-rules='MAP * 10.0.0.253' # * is to map all dns requests to 10.0.0.253 which is the web server
      # https://bugs.chromium.org/p/chromium/issues/detail?id=798793
    networks:
      default:
        ipv4_address: 10.0.0.254

Here we override the host resolver rules, and all the chrome init command for that one thing. to use `MAP yourdomain.com or * (If your HTML doesn't contain anything that isnt present on your web server) to point to 10.0.0.253, which is the IP for the webserver set in the above example.

3- File paths

Since now you are running separate containers, you also will need a volume to share files between containers, because if you send specify a file for "/var/www/app/my_file.html" to be converted to a PDF, that file needs to exist inside the chrome container which is doing the remote conversion.

services:
  chrome:
    ...
    volumes:
      - ./my_data:/path/to/data
 
  web:
   ...
    volumes:
      - ./my_data:/path/to/data

End result

In the end, your compose file will look something like this:

services:
  chrome:
    image: your_chrome_image
    ports:
      - "9222:9222"
    volumes:
      - ./my_data:/path/to/data
    command: google-chrome \
      --headless \
      --disable-gpu \
      --remote-debugging-address=0.0.0.0 \
      --remote-debugging-port=9222 \
      --disable-software-rasterizer \
      --font-render-hinting=none \
      --no-sandbox \
      --host-resolver-rules='MAP my_domain.com 10.0.0.253' # * is to map all dns requests to 10.0.0.253 which is the web server
      # https://bugs.chromium.org/p/chromium/issues/detail?id=798793
    networks:
      default:
        ipv4_address: 10.0.0.254

  web:
    image:
    ports:
      - "80:80"
    volumes:
      - ./my_data:/path/to/data
    networks:
      default:
        ipv4_address: 10.0.0.253
    depends_on:
      chrome:
        condition: service_started

networks:
  default:
    name: your_docker_network
    driver: bridge
    ipam:
     config:
       - subnet: 10.0.0.0/16
         gateway: 10.0.0.1

And after all this journey, you will be able to run:

    Browsershot::url('https://www.ebsi.te')
        ->setRemoteInstance('10.0.0.254', 9222)
        ->save($pathToImage);

and... MAYBE it will hopefully work.

Hope it helps.

[ericktucto]

This config is correct. I worked with similar config and Browsershot generated pdf

[cheycron]

Instead of establishing a static IP for the container, you can assign a hostname ('browser' in my case) and use the php function gethostbyname(), which by assigning the hostname will return the IP.