Hello, great work! I too prefer to deploy via Docker.
One minor pet peeve was having to stop, rebuild and run the Docker image after any change in code (or git pull).
Here is my new way to launching, after the initial docker build:
$ cd ~/www/robinhood-on-rails
$ docker run --name=RobinhoodOnRails -v $HOME/www/robinhood-on-rails:$HOME/robinhood-on-rails -dt -p 3222:3000 robinhood-on-rails
Wherein:
--name since I don't expect to run multiple instances on the same server. This prevents Docker from assigning random aliases, and simplifies instance management.
-p 3222 externalizes to a port other than 3000, which on my server was already taken.
-v The main point of this issue. Binds a dir from host to guest, and since Rails is already launched in dev mode, reloads new code on the fly.
I am unsure how to best adapt into the Dockerfile, etc.
Hello, great work! I too prefer to deploy via Docker.
One minor pet peeve was having to stop, rebuild and run the Docker image after any change in code (or
git pull
).Here is my new way to launching, after the initial
docker build
:Wherein:
--name since I don't expect to run multiple instances on the same server. This prevents Docker from assigning random aliases, and simplifies instance management.
-p 3222 externalizes to a port other than 3000, which on my server was already taken.
-v The main point of this issue. Binds a dir from host to guest, and since Rails is already launched in dev mode, reloads new code on the fly.
I am unsure how to best adapt into the Dockerfile, etc.