Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to change absolute path (perhaps, only in container context) #283

Open
rafaeldev opened this issue Feb 12, 2025 · 2 comments
Open

Comments

@rafaeldev
Copy link

rafaeldev commented Feb 12, 2025

Hi everyone!

I'm using Grover in a docker context where a container is running rails (called web) and another container is running chrome (called pdf)

When I render an image, for example, which brings my asset_host value in the asset path:
<img src="http://localhost:3000/assets/insert-your-logo-e3833ddb.png" />

To workaround it, I replace http://localhost:3000 with a host containerized name, in this case, http://web:3000

Is it good to consider replacing the absolute host by configuration?

Below, the main points of by code:

docker-compose.yml

services:
  web:
    build:
      context: .
      dockerfile: Dockerfile
      target: dev
    command: bash -c "./bin/dev"
    volumes:
      - .:/myapp
    ports:
      - "3000:3000"
    environment:
      RAILS_ENV: development
    stdin_open: true
    tty: true

  pdf:
    image: browserless/chrome:latest
    ports:
      - "3001:3000"
    restart: always
    environment:
      LOG_LEVEL: info
      MAX_CONCURRENT_SESSIONS: 1
      PREBOOT_CHROME: "true"
      CHROME_FLAGS: >
        --no-sandbox 
        --disable-setuid-sandbox 
        --disable-dev-shm-usage 
        --disable-gpu 
        --no-first-run 
        --disable-sync
        --disable-features=HttpsUpgrades

initializers/grover.rb

# frozen_string_literal: true

Grover.configure do |config|
  app_url = ENV.fetch("APP_URL", "http://web:3000")
  options = {
    format: "A4",
    print_background: true,
    margin: { top: "5mm", bottom: "5mm" },
    browser_ws_endpoint: ENV.fetch("BROWSER_WS_ENDPOINT", "ws://pdf:3000"),
    display_url: app_url,
    skip_chromium_download: true,
    puppeteer: {
      args: %w[
        --no-sandbox
        --disable-setuid-sandbox
      ]
    }
  }

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

  config.options = options
  config.root_url = app_url
end

I created a method (inside ApplicationController) to reuse in controllers which render pdf files:

def render_to_pdf(options)
    filename = options.delete(:filename)
    html = render_to_string(**options)
    html = html.gsub("http://localhost:3000", "http://web:3000") # <-- POINT WHERE DO THE REPLACE

    puts "html: #{html}"

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

Thanks!

@rafaeldev rafaeldev changed the title Change host name Option to change absolute path (perhaps, only in container context) Feb 12, 2025
@abrom
Copy link
Contributor

abrom commented Feb 17, 2025

You could potentially set this via the asset host config

config.asset_host = 'http://web:3000'

So long as your docker host can also resolve web appropriately

Although doing what you're doing doesn't seem overly harmful.. assuming you control the content being rendered. You could potentially make the search a little more explicit to minimise any accidental find/replaces. ie something like (not tested):

html.gsub(%r{(href|src)=(['"])http://localhost:3000([^"'])*['"]}, "\\1=\\2http://web:3000\\3\\2")

href="http://localhost:3000/foo/bar" => href="http://web:3000/foo/bar"

@rafaeldev
Copy link
Author

Thanks for your reply, @abrom

The change on config.asset_host changes the browser load asset behavior. I'm satisfied with the "workaround" but could it stay as a lib config behavior? Does it make sense?

I don't know if my scenario is common, otherwise, we can close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants