Files
docker-docs/content/guides/ruby/develop.md
Igor Aleksandrov c3431b0474 Rails guide upgrade (part 2) (#22114)
## Description

This PR has two goals. First of all it continues work that has been done
in #21559. Besides this, and this is more significant, I tried to
improve the structure of the documentation that is currently used for
different language-specific guides like
[PHP](https://docs.docker.com/guides/php/configure-ci-cd/),
[Go](https://docs.docker.com/guides/golang/),
[Python](https://docs.docker.com/guides/python/) and others, including,
of course, Ruby itself.

Each of these guides currently has a [Configure
CI/CD](https://docs.docker.com/guides/python/configure-ci-cd/) section.
Inside this section there is a GitHub Actions workflow example that has
nothing in common with a CI/CD pipeline. It's just an example of how to
build and push an image to a Docker Hub registry. We should be clear in
our documentation and not mislead our users. This was the main reason
why I renamed this section to "Automate your builds with GitHub
Actions". I also updated the content of this section to reflect the new
name and to make it more clear what the user can expect from this guide.
I suggest the same be done for all other language-specific guides.

Besides this, I changed the order of the sections in the Ruby guide. The
"Develop your app" section has been moved down to the bottom of the
guide. This makes more sense to me because of two reasons:

1. It is more important to start using Docker Hub right after you added
the Dockerfile to your project (section number one in all
language-specific guides).

2. I can hardly imagine anybody using Docker to run the app locally for
development purposes (at least for Ruby). What is really essential and
useful is to know how to run services, that are required by your app,
like a database, a cache server, or a local LLM. This is why the
"Develop your app" section should be rewritten to explain how to run the
infrastructure services that are required by the app and not the app
itself.

Below there are screenshots reflecting the changes that have been made
in this PR.

**Before**
<img width="1512" alt="Screenshot 2025-02-27 at 11 26 39"
src="https://github.com/user-attachments/assets/1ca06aea-ffeb-4efb-a14d-27254d2a2110"
/>

**After** 
<img width="1512" alt="Screenshot 2025-02-27 at 11 26 01"
src="https://github.com/user-attachments/assets/7abbe8b7-d1b3-480f-8105-49f967b51e47"
/>

## Related issues or tickets

#21559

## Reviews

- [x] Technical review
- [x] Editorial review
- [ ] Product review
2025-03-12 08:08:51 -07:00

204 lines
5.9 KiB
Markdown

---
title: Use containers for Ruby on Rails development
linkTitle: Develop your app
weight: 40
keywords: ruby, local, development
description: Learn how to develop your Ruby on Rails application locally.
aliases:
- /language/ruby/develop/
- /guides/language/ruby/develop/
---
## Prerequisites
Complete [Containerize a Ruby on Rails application](containerize.md).
## Overview
In this section, you'll learn how to set up a development environment for your containerized application. This includes:
- Adding a local database and persisting data
- Configuring Compose to automatically update your running Compose services as you edit and save your code
## Add a local database and persist data
You can use containers to set up local services, like a database. In this section, you'll update the `compose.yaml` file to define a database service and a volume to persist data.
In the cloned repository's directory, open the `compose.yaml` file in an IDE or text editor. You need to add the database password file as an environment variable to the server service and specify the secret file to use.
The following is the updated `compose.yaml` file.
```yaml {hl_lines="07-25"}
services:
web:
build: .
command: bundle exec rails s -b '0.0.0.0'
ports:
- "3000:3000"
depends_on:
- db
environment:
- RAILS_ENV=test
env_file: "webapp.env"
db:
image: postgres:latest
secrets:
- db-password
environment:
- POSTGRES_PASSWORD_FILE=/run/secrets/db-password
volumes:
- postgres_data:/var/lib/postgresql/data
volumes:
postgres_data:
secrets:
db-password:
file: db/password.txt
```
> [!NOTE]
>
> To learn more about the instructions in the Compose file, see [Compose file
> reference](/reference/compose-file/).
Before you run the application using Compose, notice that this Compose file specifies a `password.txt` file to hold the database's password. You must create this file as it's not included in the source repository.
In the cloned repository's directory, create a new directory named `db` and inside that directory create a file named `password.txt` that contains the password for the database. Using your favorite IDE or text editor, add the following contents to the `password.txt` file.
```text
mysecretpassword
```
Save and close the `password.txt` file. In addition, in the file `webapp.env` you can change the password to connect to the database.
You should now have the following contents in your `docker-ruby-on-rails`
directory.
```text
.
├── Dockerfile
├── Gemfile
├── Gemfile.lock
├── README.md
├── Rakefile
├── app/
├── bin/
├── compose.yaml
├── config/
├── config.ru
├── db/
│ ├── development.sqlite3
│ ├── migrate
│ ├── password.txt
│ ├── schema.rb
│ └── seeds.rb
├── lib/
├── log/
├── public/
├── storage/
├── test/
├── tmp/
└── vendor
```
Now, run the following `docker compose up` command to start your application.
```console
$ docker compose up --build
```
In Ruby on Rails, `db:migrate` is a Rake task that is used to run migrations on the database. Migrations are a way to alter the structure of your database schema over time in a consistent and easy way.
```console
$ docker exec -it docker-ruby-on-rails-web-1 rake db:migrate RAILS_ENV=test
```
You will see a similar message like this:
`console
== 20240710193146 CreateWhales: migrating =====================================
-- create_table(:whales)
-> 0.0126s
== 20240710193146 CreateWhales: migrated (0.0127s) ============================
`
Refresh <http://localhost:3000> in your browser and add the whales.
Press `ctrl+c` in the terminal to stop your application and run `docker compose up` again, the whales are being persisted.
## Automatically update services
Use Compose Watch to automatically update your running Compose services as you
edit and save your code. For more details about Compose Watch, see [Use Compose
Watch](/manuals/compose/how-tos/file-watch.md).
Open your `compose.yaml` file in an IDE or text editor and then add the Compose
Watch instructions. The following is the updated `compose.yaml` file.
```yaml {hl_lines="13-16"}
services:
web:
build: .
command: bundle exec rails s -b '0.0.0.0'
ports:
- "3000:3000"
depends_on:
- db
environment:
- RAILS_ENV=test
env_file: "webapp.env"
develop:
watch:
- action: rebuild
path: .
db:
image: postgres:latest
secrets:
- db-password
environment:
- POSTGRES_PASSWORD_FILE=/run/secrets/db-password
volumes:
- postgres_data:/var/lib/postgresql/data
volumes:
postgres_data:
secrets:
db-password:
file: db/password.txt
```
Run the following command to run your application with Compose Watch.
```console
$ docker compose watch
```
Any changes to the application's source files on your local machine will now be immediately reflected in the running container.
Open `docker-ruby-on-rails/app/views/whales/index.html.erb` in an IDE or text editor and update the `Whales` string by adding an exclamation mark.
```diff
- <h1>Whales</h1>
+ <h1>Whales!</h1>
```
Save the changes to `index.html.erb` and then wait a few seconds for the application to rebuild. Go to the application again and verify that the updated text appears.
Press `ctrl+c` in the terminal to stop your application.
## Summary
In this section, you took a look at setting up your Compose file to add a local
database and persist data. You also learned how to use Compose Watch to automatically rebuild and run your container when you update your code.
Related information:
- [Compose file reference](/reference/compose-file/)
- [Compose file watch](/manuals/compose/how-tos/file-watch.md)
- [Multi-stage builds](/manuals/build/building/multi-stage.md)
## Next steps
In the next section, you'll learn how you can locally test and debug your workloads on Kubernetes before deploying.