David Kimura
PRO
said almost 2 years ago
on
Rails Docker development environment
:
Tests - An alias that I use from that episode is dcr. I will run this command to pull up a shell in the Rails app container. From there, I can run my tests as I normally would. Though, I do run system tests as headless.
Conflicting ports - You need to decide which services you want to use and where they are. If you have a postgresql instance that you keep installed locally for various reasons, but want to spin up a docker instance of postgresql for your development, you're going to have to change the ports on one of the running instances. That really is up for you to decide, but I would recommend changing the port for the one that you interact with the least.
Working through a feature in a docker dev environment - I'll use the dcr alias for anything that I need to do when interacting with a running container. However, for pushing to git, I keep my code on my host machine. It is linked through a container through the volume mounts. So, in that case, I would use my host machine's git to push to the repository.
Caching & Multiple versions - I'm a believer that docker containers should be treated like cattle (verses pets). We should be able to destroy and recreate them without issues. If I have a situation where I'm installing a bunch of gems, I may specify a directory and use volume mounts.
custom Rails application template - I have an episode for that! https://www.driftingruby.com/episodes/easy-deployments I use this methodology for any application that I'm creating. Combined with the next episode after that one, I can create a new dockerized Rails application that I use for development AND I can deploy it to a FQDN within minutes of creating the application.
Hope this addresses some of your concerns.
Have a look at this episode https://www.driftingruby.com/episodes/docker-on-rails-7 as I think it covers a lot of the issues that you may have. I'll try to fill in some of the gaps as well.
database.yml - This is getting covered by having the environment variable in our docker-compose file. DATABASE_URL=postgres://postgres:postgres@postgres:5432 is getting set and available to the Rails container. in the database.yml file, you'd just need to add
database.yml - This is getting covered by having the environment variable in our docker-compose file. DATABASE_URL=postgres://postgres:postgres@postgres:5432 is getting set and available to the Rails container. in the database.yml file, you'd just need to add
development: url: <%= ENV['DATABASE_URL'] %>
Tests - An alias that I use from that episode is dcr. I will run this command to pull up a shell in the Rails app container. From there, I can run my tests as I normally would. Though, I do run system tests as headless.
dcr bash
Conflicting ports - You need to decide which services you want to use and where they are. If you have a postgresql instance that you keep installed locally for various reasons, but want to spin up a docker instance of postgresql for your development, you're going to have to change the ports on one of the running instances. That really is up for you to decide, but I would recommend changing the port for the one that you interact with the least.
Working through a feature in a docker dev environment - I'll use the dcr alias for anything that I need to do when interacting with a running container. However, for pushing to git, I keep my code on my host machine. It is linked through a container through the volume mounts. So, in that case, I would use my host machine's git to push to the repository.
Caching & Multiple versions - I'm a believer that docker containers should be treated like cattle (verses pets). We should be able to destroy and recreate them without issues. If I have a situation where I'm installing a bunch of gems, I may specify a directory and use volume mounts.
custom Rails application template - I have an episode for that! https://www.driftingruby.com/episodes/easy-deployments I use this methodology for any application that I'm creating. Combined with the next episode after that one, I can create a new dockerized Rails application that I use for development AND I can deploy it to a FQDN within minutes of creating the application.
Hope this addresses some of your concerns.