56 lines
3.6 KiB
Markdown
56 lines
3.6 KiB
Markdown
# What is Ruby on Rails
|
|
|
|
Ruby on Rails, often simply referred to as Rails, is an open source web application framework which runs via the Ruby programming language. It is a full-stack framework: it allows creating pages and applications that gather information from the web server, talk to or query the database, and render templates out of the box. As a result, Rails features a routing system that is independent of the web server.
|
|
|
|
> [wikipedia.org/wiki/Ruby_on_Rails](https://en.wikipedia.org/wiki/Ruby_on_Rails)
|
|
|
|
# How to use this image
|
|
|
|
## 1. create a `Dockerfile` in your rails app project
|
|
|
|
FROM rails:onbuild
|
|
|
|
Put this file in the root of your app, next to the `Gemfile`.
|
|
|
|
This image includes multiple `ONBUILD` triggers so that should be all that you need for most applications. The build will `ADD . /usr/src/app`, `RUN bundle install`, `EXPOSE 3000`, and set the default command to `rails server`.
|
|
|
|
## 2. build the rails app image
|
|
|
|
docker build -t my-rails-app .
|
|
|
|
## 3. start the rails app container
|
|
|
|
docker run --name some-rails-app -d my-rails-app
|
|
|
|
Then hit `http://container-ip:3000` in a browser. On the other hand, if you need access outside the host on port 8080:
|
|
|
|
docker run --name some-rails-app -p 8080:3000 -d my-rails-app
|
|
|
|
Then hit `http://localhost:8080` or `http://host-ip:8080` in a browser.
|
|
|
|
# Issues and Contributing
|
|
|
|
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
|
|
|
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
|
|
|
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/rails/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
|
|
|
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
|
|
|
## Conventions
|
|
|
|
Fork the repository and make changes on your fork in a feature branch.
|
|
|
|
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
|
|
|
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
|
|
|
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
|
|
|
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
|
|
|
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
|
|
|
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|