Docker challenges — How to install gems?

[keithschacht]

Hey @robacarp, in my branch I needed to install a new gem. I couldn't quite figure out how to do this with the docker setup. I tried running docker compose run base bundle install and within that particular process it clearly installed the gem, but I tried restarting the main docker compose up and it was missing the gem in that process.

Then I tried modifying the docker-entrypoint to add bundle install right above the db:prepare, and I also had the idea to re-run docker compose build. One of those two things fixed it, but I'm not sure which one. :)

Was my mistake simply that I needed to go straight to docker compose build? Does that install gems?

Or do I actually need to commit my change to the docker-entrypoint and from now on we just kill the up process and restart it to install gems?

[keithschacht]

Oh, actually, while discussing docker compose I once had the issue where I killed the process and restarted it and I got the error A server is already running (pid: 1, file: /rails/tmp/pids/server.pid).

I remember that one of our contributors got this issue once as well. In order to fix it I needed to do run base sh and rm the file. Could we attempt to auto-delete that file on every start just to avoid that happening again?

[robacarp]

That was a weird situation for sure. That pidfile is really meant to handle something different than running rails in docker, and it's not really helpful to propagate back to the host via the volume. It's actually really reasonable to run more than one container locally and have them all running traffic behind a local load balancer.

• If possible, that file (and probably all of /rails/tmp) should be blacklisted from the volume. Perhaps we can add that explicitly in the compose file or the dockerignore file somehow, but I'm not drawing any confident memories about it.
• We could rewire the configuration in the docker entrypoint so that the pidfile is written to /tmp (or somewhere else on the ephemeral disk)
• As a last resort, we could rm the file automatically or issue a more helpful warning about it. I'm hesitant to automatically delete the file because if we do that, and there is actually a zombie rails process hanging around, a user would then have to go spelunking about in ps aux in order to find the process and terminate it, and the error will be more opaque not less. When the file is there you can quickly get the PID of the server and issue a QUIT or KILL to it, or at least determine if it actually exists.

[robacarp]

Running docker compose up --build will rebuild and install gems. We could certainly add a script to the repo to make that more obvious, this is a pattern I've followed many times for that kind of thing.

Any command you run with docker compose run or docker compose exec will write to the emphemeral disk and be discarded when you restart the container (unless it writes to one of the mounted volumes, like a rails generator would).

Adding it to the entrypoint will cause bundle to install gems at every boot up, which isn't really necessary and it'll slow down boot times considerably.

[keithschacht]

I like that pattern. Would you suggest we follow it just as it's written? I notice the repo is archived but I did a little googling and couldn't find an explanation for why. Maybe it's because rails has moved from a scripts/ folder to a bin/ folder? Should we follow the same advice but put it all in bin?

Actually, do you have time to take a crack at a PR to help with both this pattern and also a solution to the pid problem?

[keithschacht]

@anandvc touched on another possible improvement to our scripts. I think this one is less important but I’ll capture it:

he started up docker and got this error:

Error response from daemon: Ports are not available: listen tcp [0.0.0.0:6379](http://0.0.0.0:6379/): bind: address already in use

The solution was to run sudo brew services stop redis before trying docker compose up again. We could probably do a check if there any conflicting services running and fail more gracefully with a nice error message that suggests a resolution.