partydrone PRO
Joined 9/28/2019
partydrone PRO said over 2 years ago on Docker on Rails 7 :
`WORKDIR /app` both (1) creates the directory if it doesn't exist and (2) sets it as the current working directory for all subsequent commands in the Dockerfile. For this reason, `RUN mkdir /app` is not necessary. 😉

partydrone PRO said over 2 years ago on Docker on Rails 7 :
If the only reason for having the `base` service is to share configuration, I believe a best practice is to create a custom root-level definition beginning with `x-` and using that.

Also worth noting is the difference between "mapping" ports vs "exposing" ports in a Compose file. When mapping a port (e.g., `- 3000:3000` for the Rails app), you are mapping the port on your local machine to a port on the container. If you only expose a port (e.g., `- 5432` for the database service), Compose maps a random port on your machine to the port on the container. To determine what that random port is, you can run `docker compose ps`.

In the end, your docker-compose.yml file could look like this:

version: "3.8"

x-app: &app
  build:
    args:
      RUBY_VERSION: "3.0.2-apline"
    context: .
    dockerfile: Dockerfile.dev
  depends_on:
    - db
    - redis
  environment:
    - DATABASE_URL=postgres://postgres:postgres@db:5432
  stdin_open: true
  tty: true
  volumes:
    - .:/app:cached
    - bundle:/usr/local/bundle
    - node_modules:/app/node_modules

services:
  db:
    environment:
      - POSTGRES_PASSWORD=postgres
    image: postgresql:14-alpine
    ports:
      - 5432
    restart: always
    volumes:
      - postgres:/var/lib/postgresql/data

  redis:
    image: redis:alpine
    restart: always
  
  web:
    <<: *app
    command: rails s -b 0.0.0.0
    ports:
      - 3000:3000

  css:
    <<: *app
    command: yarn build:css --watch

  js:
    <<: *app
    command: yarn build --watch

volumes:
  bundle:
  node_modules:
  postgres:

partydrone PRO said over 2 years ago on Docker on Rails 7 :
 ☒, I am very interested to know how larger Rails apps perform when developing with Docker Compose on an M1 Mac. Historically, Rails app performance is abysmal when the app gets larger. With several large apps I worked with in a Docker environment on Intel Macs, it often takes 30 seconds or more for pages to load in a browser. The culprit has to do with volume mapping from macOS into a Docker container (see https://github.com/docker/roadmap/issues/7). I tried using docker-sync in the past, and more recently Mutagen, but I'm anxious to see how the M1 Macs perform.

partydrone PRO said over 2 years ago on Docker on Rails 7 :
Another suggestion I would make is to decouple the Linux flavor from the Ruby version passed into the build context. For example, in your Dockerfile, FROM should read:

ARG RUBY_VERSION
FROM ruby:${RUBY_VERSION}-alpine
# …

Then in your docker-compose.yml file, pass only the Ruby version:

service:
  web:
    build:
      args:
        RUBY_VERSION: 2.6.8

The reason for doing this is the Dockerfile uses Alpine-specific commands for installing packages (apk instead of apt). If someone passes in "2.6.8-buster" then they've broken the Dockerfile and the build will fail.

partydrone PRO said about 1 month ago on Bulk Updates :
You were actually on the right track with underscores in your data attributes. You can also create a `data` hash:

<%= check_box_tag :"bulk_ids[]", :all, checked?, data: {bulk_edit_target: "allCheckBox", action: "change->bulk-edit#clicked"} %>

The Rails view helper will convert the underscores into dashes for you and prepend each key in the hash with `data-`:

<input type="checkbox" name="bulk_ids[]" id="bulk_ids_" value="all" data-bulk-edit-target="allCheckBox" data-action="change->bulk-edit#clicked">

Great episode, as always! 🙂

NOTE: I checked this in a Rails 5.1 application. Things may be different in newer versions of Rails. Oh yeah, `checked?` is meant to be pseudo code. 😉