Docker deployment in Ruby on Rails - Step-by-Step Execution

Concept Flow - Docker deployment

Write Dockerfile

↓

Build Docker Image

↓

Run Container from Image

↓

App Starts Inside Container

↓

Access App via Browser or API

↓

Stop or Restart Container

This flow shows how a Rails app is packaged into a Docker image, run as a container, and accessed.

Execution Sample

Ruby on Rails

FROM ruby:3.2
WORKDIR /app
COPY Gemfile* ./
RUN bundle install
COPY . .
CMD ["rails", "server", "-b", "0.0.0.0"]

This Dockerfile builds a Docker image for a Rails app and starts the Rails server.

Execution Table

Step	Action	Details	Result
1	Read Dockerfile	FROM ruby:3.2	Base image set to Ruby 3.2
2	Set working directory	WORKDIR /app	Working directory inside container is /app
3	Copy Gemfile	COPY Gemfile* ./	Gemfile and Gemfile.lock copied to /app
4	Install gems	RUN bundle install	Gems installed inside image
5	Copy app files	COPY . .	All app files copied to /app
6	Set start command	CMD ["rails", "server", "-b", "0.0.0.0"]	Rails server will start on container launch
7	Build image	docker build -t myrailsapp .	Docker image 'myrailsapp' created
8	Run container	docker run -p 3000:3000 myrailsapp	Container runs, Rails server listens on port 3000
9	Access app	Open http://localhost:3000	Rails app homepage loads in browser
10	Stop container	Ctrl+C or docker stop	Container stops, app no longer accessible

💡 Container stops when user stops it or system shuts down

Variable Tracker

Variable	Start	After Step 3	After Step 5	After Step 8	Final
Docker Image	None	Base Ruby image	Image with app files and gems	Image running as container	Stopped container
Container	None	None	None	Running Rails server	Stopped

Key Moments - 3 Insights

Why do we copy Gemfile separately before copying all files?

Copying Gemfile first allows Docker to cache the bundle install step if Gemfile hasn't changed, speeding up rebuilds (see execution_table steps 3 and 4).

Why do we bind Rails server to 0.0.0.0 instead of localhost?

Binding to 0.0.0.0 makes the server listen on all network interfaces inside the container, allowing access from outside (step 6).

What happens if we don't expose port 3000 when running the container?

Without port mapping (step 8), the app inside the container won't be reachable from the host machine's browser.

Visual Quiz - 3 Questions

Look at the execution table, what is the result after step 4?

A Gems installed inside image

B App files copied to /app

C Rails server started

D Docker image created

💡 Hint

Check the 'Result' column for step 4 in the execution_table

At which step does the Rails server start running inside the container?

A Step 6

B Step 8

C Step 7

D Step 9

💡 Hint

Look for when the container runs and the server listens on port 3000

If we change the CMD to bind Rails server to localhost (127.0.0.1), what happens?

A Container fails to start

B App is accessible from host machine

C App is not accessible from host machine

D Docker image build fails

💡 Hint

Refer to key_moments about binding address in step 6

Concept Snapshot

Docker deployment for Rails:
- Write Dockerfile with base Ruby image
- Copy Gemfile, run bundle install for caching
- Copy app files
- Set CMD to start Rails server binding 0.0.0.0
- Build image with docker build
- Run container with port mapping
- Access app via localhost:3000
- Stop container to end app

Full Transcript

Docker deployment for a Rails app involves writing a Dockerfile that starts from a Ruby base image. We set the working directory and copy the Gemfile first to install gems efficiently. Then we copy the rest of the app files. The CMD instruction starts the Rails server binding to 0.0.0.0 so it listens on all interfaces inside the container. We build the Docker image using 'docker build' and run it with 'docker run' mapping port 3000 to access the app from the host browser. Stopping the container stops the app. This process packages the Rails app in a container for easy deployment and consistent environment.