DEV Community

Discussion on: Running dev.to in a container

Collapse
 
chuck_ha profile image
Chuck Ha

Two points here

  1. I'm installing ruby with rbenv so that if the dev.to repo ever updates the .ruby-version file this image will use the correct version of ruby.
  2. The reason I have to add .rbenv/bin and .rbenv/shim to the $PATH is that the rbenv-install will fail with an exit code > 0 if those do not exist in the $PATH. It looks funny to me that I have to modify the $PATH then install rbenv-installer, but this seems to be a quirk of rbenv-doctor which is run after the installation.

I'm hoping to clean up the Dockerfile as I write out this series of posts.

Collapse
 
david_j_eddy profile image
David J Eddy

Interesting, I am conflicted.

I like the forward thinking of not needing to modify an upstream source provider content, esp. due to a minor increment.

But on the other hand I though if any of the app files change (ie .ruby-version)
shouldn't the image be rebuilt and the dependent containers restarted?

The phrase "There are no solutions, only trade-offs" comes to mind.

Thread Thread
 
chuck_ha profile image
Chuck Ha

To your point I think there is a better solution than what I've provided in this article. I should be using a multistage build. If I were building dev.to on a container for production I'd probably have a build pipeline for each commit that would do something like:

  1. build a ruby image based off .ruby-version file
  2. build a dependency image from the ruby image off the gemfile/yarnfile
  3. build an image with compiled assets
  4. add in the app code

The only time all the build steps get run is when the ruby-version is updated, otherwise the build uses the cache (assuming docker is able to cache i.e. the build is not running in ephemeral infrastructure). In the normal case where the app code is changing but the dependencies are not only the last step is executed which should be relatively quick.