fly-apps/dockerfile-rails

Add more clarity on deb packages being build or runtime dependencies

Closed this issue · 5 comments

Consider adding a new option or more information in README about installing deb packages needed for gem compilation and those needed for runtime.

It's about a situation when the app needs a gem for Postgresql, MySQL and MSSQL server to work (as well as GEOS for geospatial extensions). In this case, simply using the -add option does not help, and you have to assign different packages in the section:

FROM base as build

# Install packages needed to build gems and node modules
RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y build-essential default-libmysqlclient-dev git libpq-dev node-gyp pkg-config python-is-python3 \
    freetds-dev libgeos-dev

than the packages needed here:

FROM base

# Install packages needed for deployment
RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y \
    default-libmysqlclient-dev default-mysql-client freetds-bin libgeos-* libvips nodejs postgresql-client && \
    rm -rf /var/lib/apt/lists /var/cache/apt/archives

Apparently --add only adds packages required to build gems.

I am also curious if this tool is to be used to create Docker images for development or is it intended to be only for building production images? I'm asking because here is hardcoded RAILS_ENV production

rubys commented

From https://github.com/rubys/dockerfile-rails#add-a-packageenvironment-variablebuild-argument :

Each of these can be tailored to a specific build phase by adding -base, -build, or -deploy after the flag name (e.g --env-build:). If no such suffix is found, the default for arg is -base, and the default for the rest is -deploy.

Is this what you are looking for? Did you just miss it, or do you have any suggestions on how to make it more clear?

I am also curious if this tool is to be used to create Docker images for development or is it intended to be only for building production images? I'm asking because here is hardcoded RAILS_ENV production

If adding a '--dev' option would be of value, I have no objection. I'm about to merge in the following change rails/rails#47594 which would obviously need to only apply to production. I'd also drop the setting of BUNDLE_WITHOUT in development.

oh I'm sorry, looks like I had it before my eyes. On the other hand, maybe the fact that it was not immediately readable for me means that we should add an example here, even the one I gave, where in build we need freetds-dev and in base freetds-bin as runtime dependency.

Regarding --dev do we have some overlap here with what docked provides? or perhaps these two tools should be merged ?

rubys commented

we should add an example here

Care to make a pull request? I'd like to keep the front page compact, but anything is fair game on additional pages.

do we have some overlap here with what docked provides?

At the moment, quite different use cases. dockerfile-rails assumes that you have an application. docked assumes that you have nothing and want to run rails new inside an empty container. If you want to complete the picture, I would also include things like VSCode which lets you operate inside a container the same way you would if the code was local.

Care to make a pull request? I'd like to keep the front page compact, but anything is fair game on additional pages.

Gotcha, will do, probably just one phrase.

At the moment, quite different use cases.

Not necessarily, but I get your point. These commands from docked are used for further development after the application is created and could as well be used after "dockerizing" a legacy project

docked rails generate scaffold post title:string body:text
docked rails db:migrate
docked rails server

this is the "overlap" I meant

Hey folks, I just wanted to leave a small bit of feedback to this issue. I was using this project today for an app that leverages SQL Server, and therefor needs freetds-dev to build.

The example @januszm left in the README was extremely valuable today, and I just wanted to thank you for adding it, and @rubys for allowing it in such prime real estate. In addition to helping configure the output, it helps highlight the difference between build and runtime binary deps. A lot of context in such a small example. (Particularly useful that it's the exact example I was trying to add ;))