Support for remote chromium?

[brendon]

Just wondering if Ferrum supports connecting to a remote chromium instance?

I'm using Kamal for deployment and currently generate PDF's with grover configured to connect to a Kamal accessory that just runs a chromium server. It works quite well but grover still depends on node for this even though it doesn't install chrome locally:

https://github.com/Studiosity/grover?tab=readme-ov-file#remote-chromium

I'd like to get rid of node as a runtime dependency as it makes my builds really large.

[excid3]

See the Ferrum docs. There's a Docker section in the readme. https://github.com/rubycdp/ferrum

We're just a layer on top. 👍

[brendon]

Excellent, thank you for that. I found the url option and was going to give it a whirl after lunch, so thank you for confirming that. :)

[excid3]

Let me know how it goes! Would love to have that setup explained in our docs.

[brendon]

Will do :) Just in the process of converting my grover call. I've found most of the options but just wondered about these two:

          wait_until: "networkidle0",
          wait_for_function: 'window.vueStatus === "loaded"',

I think the network one is wait_for_idle_options: { connections: 0, duration: 0.5, timeout: 30 } though I don't think there's an actual timeout with puppeteer, rather it's the global timeout.

Any tips for the function style of wait?

[excid3]

I'm not sure, but seems like you may have to do that yourself with Ferrum. Maybe a loop and eval that JavaScript snippet every Xs until a maximum is surpassed?

You'll have to pass a block to render_pdf to do that.

[brendon]

Ah interesting, yep that makes sense. Just noticed the bit at the bottom regarding debugging.

[rafaeldev]

Hi everyone!

I'm use Grover with a chrome on external machine to create PDF. For my context, user requests a PDF from page and it download the file generated in same request.
To avoid install chrome on each web machine in production, I created a docker instance to handle all requests. The connection between web instances and pdf instance, is over WebSocket. The image used to handle this requests is browserless/chrome:latest because it is the only image which supports WebSocket wrapper implementation.

Below, that's my files used in development environment

pseudo-docker-compose.yml

services:
  web:
    <<: *app-build
    command: bash -c "./bin/dev"
    volumes:
      - .:/myapp:cached
      - bundle:/usr/local/bundle
      - node_modules:/myapp/node_modules
    ports:
      - "3000:3000"
    depends_on:
      - db
      - redis
    environment:
      RAILS_ENV: development
      SERVER_KIND: web
    extra_hosts:
      - "host.docker.internal:host-gateway"

  pdf:
    image: browserless/chrome:latest
    ports:
      - "3001:3000"
    restart: always
    environment:
      MAX_CONCURRENT_SESSIONS: 5
      CONCURRENT: 5
      CONNECTION_TIMEOUT: 10000
      TIMEOUT: 10000
      LOG_LEVEL: info
      ENABLE_HTTP: "true"
      QUEUED: 10
      PREBOOT_CHROME: "true"
      CHROME_FLAGS: >
        --no-sandbox
        --disable-setuid-sandbox
        --disable-dev-shm-usage
        --disable-gpu
        --no-first-run
        --disable-sync
        --disable-features=HttpsUpgrades
    healthcheck:
      test: [ "CMD", "curl", "--fail", "http://localhost:3000/metrics" ]
      interval: 30s
      timeout: 5s
      retries: 3

Always when I need generate pdf, I start pdf container.

My grove initializer:

Grover.configure do |config|
  app_url = ENV.fetch("APP_URL", "http://web:3000")
  options = {
    format: "A4",
    print_background: true,
    margin: { top: "2mm", bottom: "2mm", left: "0mm", right: "0mm" },
    browser_ws_endpoint: ENV.fetch("BROWSER_WS_ENDPOINT", "ws://pdf:3000"),
    display_url: app_url,
    skip_chromium_download: true,
    timeout: Rails.env.production? ? 30_000 : 10_000,
    viewport: { width: 1280, height: 800 },
    puppeteer: {
      args: %w[
        --no-sandbox
        --disable-setuid-sandbox
        --disable-dev-shm-usage
        --disable-gpu
        --no-first-run
        --disable-sync
        --disable-features=HttpsUpgrades
      ],
    },
  }

  Rails.logger.info "INITIALIZING GROVER WITH OPTIONS: #{options}"

  config.options = options
  config.root_url = app_url
end

and finally, the #render_to_pdf

def render_to_pdf(options)
  filename = options.delete(:filename)
  html = render_to_string(**options)

  # this is to assets requests work
  if Rails.env.development?
    app_url = ENV.fetch("APP_URL", "http://web:3000")
    html = html.gsub("http://localhost:3000", app_url)
  end

  # skip robots indexing for PDF files
  response.set_header("X-Robots-Tag", "noindex, noarchive, nosnippet")

  send_data Grover.new(html).to_pdf,
            filename: filename,
            type: "application/pdf",
            disposition: "inline"
end

[brendon]

That's pretty much what I'm currently doing too, but I want to not have my full node setup in my production image, so removing puppeteer would be good :) Will keep plugging away at it today and see where I get :)

[brendon]

@excid3, sorry this has turned into a troubleshooting session. I think my big issue is that the stylesheets and javascript don't seem to be loading. It's probably a problem with the base_url replacement functionality but I can't find a way to inspect the HTML of a page after it's been processed for urls. Is there a way? I might just jump into my local copy of your code and hack in there to log it out :)

[brendon]

Looks like I mistook base_url for Grover's display_url. I think it might be better to use Grover's method of request interception to set manually supplied HTML as it basically fools Chrome into 'loading' a page at a particular display_url and then injects the HTML via an intercept of the page request. This way Chrome thinks it's requesting a particular URL and all the relative urls in the document just work and don't need to be modified ahead of time. Here's the code:

https://github.com/Studiosity/grover/blob/ef0992a2da6aeada6bdd6d761d334425a5c8baf3/lib/grover/js/processor.cjs#L224-L240

I might do up a PR for this.

[excid3]

Oh nice, I would like to see that.

[brendon]

No worries :) Take a look and let me know if you can see room for improvement. I think it'd be good to have a test or two but need some suggestions as this doesn't appear to be an area of the gem that's tested currently.

[jpmagido]

Hello,
Here a minimalist configuration with alpine chrome if you like to try it out:

• Node is not needed
• chromium binary not needed

docker-compose.yml

  web:
    build:
      context: .
      dockerfile: Dockerfile.dev
    env_file: .env
    ports:
      - '3000:3000'

  chrome:
    image: zenika/alpine-chrome
    command:
      - --no-sandbox
      - --remote-debugging-address=0.0.0.0
      - --remote-debugging-port=9222
    ports:
      - "9222:9222"

You can checkout the chrome instance in your favorite browser with http://localhost:9222/json/version

Then you can setup a custom browser for your FerrumPdf config:

browser = ::ChromiumBrowser.new.perform
::FerrumPdf.browser = browser
pdf = ::FerrumPdf.render_pdf(
    url: root_url(host: web:3000), # add any rails url you like, make sure to add your web_app host too
)
browser.quit if browser
pdf

note that for your custom browser to be able to instanciate, you'll need to retrieve some data from your chrome container:

class ChromiumBrowser
  def perform
    ::Ferrum::Browser.new(ws_url: browser_ws_url)
  end

  private

  def browser_ws_url
    "ws://chrome:9222/devtools/browser/#{debugger_browser_id}"
  end

  def debugger_browser_id
    debugger_browser_url['webSocketDebuggerUrl'].split('/').last
  end

  def debugger_browser_url
    # do the equivalent of curl -H "Host: localhost" http://chrome:9222/json/version
  end
end

don't hesitate to comment on it if you know better ways of if it helped you :)

[brendon]

Ah interesting, I didn't know about the alpine package. Have you tried running it in the other security modes? --no-sandbox is the least secure. I can't remember how the browserless container does it. This is my current one:

  chrome:
    registry:
      <<: *gchr
    image: browserless/chromium
    role: web
    env:
      clear:
        TIMEOUT: 55000
        CONCURRENT: 5
    options:
      expose:
        - 3000
      cpuset-cpus: 7-11

Some configuration there that is particular to my environment, but I had issues with timeout being too short and not enough concurrent browsers. I also pin to just a few CPU's on the server so as not to screw up my other processes when doing large runs of screenshots.

[brendon]

Also, please be wary of using that docker image. It appears the original author is no longer involved and his previous employer may be now pushing images up: https://github.com/jlandure/alpine-chrome/blob/master/README.md

jlandure/alpine-chrome#272 (comment)

[jpmagido]

Yes i also could make it work with browserless/chromium, it's much simpler.

docker-compose.yml

chrome-test:
  image: ghcr.io/browserless/chromium
  ports:
    - '3000:3000'

::Ferrum::Browser.new(
  ws_url: 'ws://chrome-test:3000',
  process_timeout: 30,
  timeout: 20,
)

Good catch on the zenika former maintainer.

I tried the seccomp setup without success for now but only locally on M3 macbook and i have permissions error, maybe the chrome profile is not compatible.
I'll try and post about it on a debian VPS for further investigations.

But on my case, the --no-sandbox might be enough.
I only use the chrome browser from inside my infrastructure and only use it for pdf generation on my own web_app.

---

Also note that the browserless containers are free for open-source projects but not for commercial ones.
https://github.com/browserless/browserless?tab=readme-ov-file#-licensing