Host Tracks v2.2.2 for free with OpenShift

Update: Fixed the command to create the application.

A few days ago I discovered Red Hat’s OpenShift service for hosting web applications in the cloud. Currently, you can host up to three applications for free which is nice, and performance is quite acceptable as well.

In order to host tracks on OpenShift, you can use the repository I created at https://bitbucket.org/matt/tracks-openshift-quickdeploy/src which includes Tracks v2.2.2.

Here’s instructions on how to deploy Tracks on OpenShift. In the future, when Red Hat resolves some issues with deploying from a git repository, it will be much simpler.

Assumptions

I’m going to assume that you have created an account at openshift.com and that you have installed the OpenShift client tools, including git.

Installation

First, we’ll create the application:

$ rhc app create tracks ruby-1.9 mysql-5.1

After creating the application, rhc will create a git repository in the current directory with the name of the app. We need to replace all the code with the code from https://bitbucket.org/matt/tracks-openshift-quickdeploy/src.

$ cd tracks
$ rm -rf *
$ git rm --cached *
$ git commit -m "Removing initial files"
$ git remote add upstream -m master https://bitbucket.org/matt/tracks-openshift-quickdeploy.git
$ git pull -s recursive -X theirs upstream master

Note, if you’re on Windows, you might want to double check to make sure that the hook scripts are still executable. You can do this on Windows with the following:

$ git update-index --chmod=+x .openshiftaction_hooksbuild
$ git update-index --chmod=+x .openshiftaction_hooksdeploy
$ git update-index --chmod=+x .openshiftaction_hookspost_deploy
$ git update-index --chmod=+x .openshiftaction_hookspost_start_ruby-1.9
$ git update-index --chmod=+x .openshiftaction_hookspost_stop_ruby-1.9
$ git update-index --chmod=+x .openshiftaction_hookspre_build
$ git update-index --chmod=+x .openshiftaction_hookspre_start_ruby-1.9
$ git update-index --chmod=+x .openshiftaction_hookspre_stop_ruby-1.9
$ git commit

Now, you will want to edit the config/site.yml file and replace the salt: and secret_token: values with your own values. I used GRC’s password generator to generate some random values. Also, while you’re at it, modify any other options in site.yml that you want. Be sure to commit the changes when you’re done.

Finally, we can do a push and after a while, you should be able to access your application at https://APPLICATION-NAMESPACE.rhcloud.com where you’ll be prompted to create the admin account and etc.

Once Red Hat resolves issues with the --from-code, this will become much simpler.

Credit

Thanks to @disconn3ct for boiling down the necessary instructions to avoid Red Hat’s issues.

27 replies on “Host Tracks v2.2.2 for free with OpenShift”

  1. Hi.

    Thanks for your effort. This seems to be broken. I followed the recipe, but when starting the application php complains about the DocumentRoot not being found. This can be fixed by not deleting the php folder, but this only gives me the default page. Any ideas how to fix this ?

    1. You’re absolutely right, I was working on two different applications and the time and confused the setup instructions. You need to create a rails gear, not a php gear.

      During the create application step, use:

      $ rhc app create tracks ruby-1.9 mysql-5.1

  2. Thanks for the instructions. I want to use and contribute to the project and i also want to use openshift for my production server. Since i plan on contributing. I dont want to add the database.yml and site.yml files to the repo.

    Do you know of an easy way to do this with openshift? perhaps build hook? or maybe it can be ignored in one repot and not the other?

    1. For a php app I use the following to deploy the config file, it’s stored in the misc directory:

      # Copy our config.php over
      if [ -f $OPENSHIFT_REPO_DIR/misc/config.php ]; then
      cp $OPENSHIFT_REPO_DIR/misc/config.php $OPENSHIFT_REPO_DIR/php/config.php
      fi

  3. This is great, and I think for Windows users it’s very nearly there. The wheels sort of come off at rm -rf *, which is not a windows command of course, unless you’re saying that during the client install process we should have installed all the unix commands?

    Whatever. If we do del /s * at this point the folder ceases to be a git repository, and if we plough ahead without it (I’ve run this lot at least 4 times) we get:
    From https://bitbucket.org/matt/tracks-openshift-quickdeploy
    * branch master -> FETCH_HEAD
    error: The following untracked working tree files would be overwritten by merge:

    .openshift/cron/README.cron
    .openshift/cron/daily/.gitignore
    .openshift/cron/hourly/.gitignore
    .openshift/cron/minutely/.gitignore
    .openshift/cron/monthly/.gitignore
    .openshift/cron/weekly/README
    .openshift/cron/weekly/chrono.dat
    .openshift/cron/weekly/chronograph
    .openshift/cron/weekly/jobs.allow
    .openshift/cron/weekly/jobs.deny
    README.md
    config.ru
    Please move or remove them before you can merge.
    Aborting

    I’m kind of stuck at this point. But great stuff so far!

    1. I did get further – instead of rm -rf *, I deleted the .openshift/cron folder and README.md and
      config.ru, and that got all the source loaded. More fiddling later, I seem to have something booting up – remote: Starting Ruby cart – but when I go to the url I’m redirected to a non-existent app folder: The requested URL /app was not found on this server.

      But that was exciting!

      1. Okay, so even though I have done the deploy before from Windows, I decided to go ahead and verify that it still works. After all, maybe something has changed on OpenShift. I ran the following on Windows 7 this morning:

        rhc app create trackstest ruby-1.9 mysql-5.1
        cd trackstest
        rmdir /s .openshift public tmp
        del config.ru README.md
        git rm --cached *
        git commit -m "Removing initial files"
        git remote add upstream -m master https://bitbucket.org/matt/tracks-openshift-quickdeploy.git
        git pull -s recursive -X theirs upstream master
        git update-index --chmod=+x .openshiftaction_hooksbuild
        git update-index --chmod=+x .openshiftaction_hooksdeploy
        git update-index --chmod=+x .openshiftaction_hookspost_deploy
        git update-index --chmod=+x .openshiftaction_hookspost_start_ruby-1.9
        git update-index --chmod=+x .openshiftaction_hookspost_stop_ruby-1.9
        git update-index --chmod=+x .openshiftaction_hookspre_build
        git update-index --chmod=+x .openshiftaction_hookspre_start_ruby-1.9
        git update-index --chmod=+x .openshiftaction_hookspre_stop_ruby-1.9
        git commit -m "Make scripts executable"
        REM edit configsite.yml and replace the secret values
        git add configsite.yml
        git commit -m "Change secrets"
        git push

        When the push finished, the app was working and I was able to login as admin. If it’s not working for you, at least post what errors you get from the final push command.

        Edit: The first push takes a very long time to finish (~15 minutes here), make sure you’re letting it finish completely before trying to access the app.

        1. Matt, that is so close it’s brilliant. My stupid mistake was not setting subdir in site.yml; once I did that I got the site up . . . except it doesn’t serve assets, e.g it has links like /tracks/assets/application-571cd799e335caec3ef60b9e431b1c8a.css that don’t work. I’m hoping this is easy peasy to you, I’ve come unstuck trying to see what’s on OpenShift with Putty.

        2. Ah. Further investigation shows that /assets/application-571cd799e335caec3ef60b9e431b1c8a.css is a valid link whereas /tracks/assets/application-571cd799e335caec3ef60b9e431b1c8a.css is not. Looks like there’s something iffy in the production environment configuration?

        3. Mmm . . . if I don’t set subdir, the site doesn’t come up at all (it looks for an “apps” subdir). If I set subdir, I can’t see static data. Maybe something in config/production.rb?

  4. The point is to delete all non-git files in the initial repository that is created on OpenShift. Adjust accordingly based on what operating system you’re running as. Do not, however, delete the .git directory.

    I only mentioned Windows, because if you don’t ensure the scripts are executable, then they won’t run on OpenShift and nothing will work.

    I do assume if you’re messing with OpenShift, you have some familiarity with git and the linux console.

    1. Matt – many thanks for your work on this, it has whetted my appetite for throwing a PHP app up on OpenShift. I barely pass go with git, but I try. My linux is somewhat rusty too, but I think I’m doing OK getting this far!

      I’ve also just revived my Tracks account on your own server, which seems to have some of my to-dos from a year ago!
      Cheers
      Jim

  5. You’ll see the 500 error code at the, I followed everything religiously I think.

    The production log shows the following


    ActionController::RoutingError (No route matches [GET] "/favicon.ico"):
    vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
    vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
    vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/rack/logger.rb:32:in `call_app'
    vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/rack/logger.rb:16:in `block in call'
    vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/tagged_logging.rb:22:in `tagged'
    vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/rack/logger.rb:16:in `call'
    vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/request_id.rb:22:in `call'
    vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/methodoverride.rb:21:in `call'
    vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/runtime.rb:17:in `call'
    vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/cache/strategy/local_cache.rb:72:in `call'
    vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/lock.rb:15:in `call'
    vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:136:in `forward'
    vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:245:in `fetch'
    vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:185:in `lookup'
    vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:66:in `call!'
    vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:51:in `call'
    vendor/bundle/ruby/1.9.1/gems/rack-mini-profiler-0.1.23/Ruby/lib/mini_profiler/profiler.rb:209:in `call'
    vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/engine.rb:479:in `call'
    vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/application.rb:223:in `call'
    vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/railtie/configurable.rb:30:in `method_missing'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/rack/request_handler.rb:97:in `process_request'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/abstract_request_handler.rb:521:in `accept_and_process_next_request'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/abstract_request_handler.rb:274:in `main_loop'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/rack/application_spawner.rb:206:in `start_request_handler'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/rack/application_spawner.rb:79:in `block in spawn_application'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/utils.rb:470:in `safe_fork'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/rack/application_spawner.rb:64:in `spawn_application'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/spawn_manager.rb:264:in `spawn_rack_application'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/spawn_manager.rb:137:in `spawn_application'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/spawn_manager.rb:275:in `handle_spawn_application'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/abstract_server.rb:357:in `server_main_loop'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/lib/phusion_passenger/abstract_server.rb:206:in `start_synchronously'
    /opt/rh/ruby193/root/usr/share/gems/gems/passenger-3.0.21/helper-scripts/passenger-spawn-server:102:in `'

  6. I’m still installing this about 5 times a day, buthave no idea where I’m going wrong

    There doesn’t appaer to be any tables in the database though

    mysql> show DATABASES;
    +——————–+
    | Database |
    +——————–+
    | information_schema |
    | mysql |
    | tracks |
    +——————–+
    3 rows in set (0.03 sec)

    mysql> use tracks;
    Database changed
    mysql> show TABLES;
    Empty set (0.01 sec)

    mysql>

    At what point are these filled in

  7. I haven’t attempted to deploy tracks to OpenShift since May when I wrote this post. Without any spare gears, I can’t verify whether or not these instructions still work without modification.

    You haven’t, however, listed anything about what (if any) steps aren’t working properly.

    No mention of what operating system you’re deploying from (it matters, see the remarks about Windows above).

    At the least you could post the output of the git push command (NOT HERE, but to a site like pastebin.com).

  8. Thanks for replying, getting tracks running again is my holy grail, I never seem to be able to set the server stack up properly, so this looked like a great method.

    You’re right there are no errors reported at any point in the process – I’m using Ubuntu 13.04

    The pastebin for the push is at http://pastebin.com/j0sFp0uP

    1. Okay, this is useful.

      ActiveRecord::StatementInvalid (Mysql2::Error: Table 'tracks.sessions' doesn't exist: SHOW FULL FIELDS FROM `sessions`):
      lib/login_system.rb:173:in `store_location'
      lib/login_system.rb:113:in `login_required'
      lib/login_system.rb:80:in `login_or_feed_token_required'

      It looks like the database creation is failing… and I see now above that you had already mentioned the tables weren’t being created. My apologies for not recognizing that earlier.

      Verify the deploy scripts are executable by running:

      $ git update-index --chmod=+x .openshift/action_hooks/build
      $ git update-index --chmod=+x .openshift/action_hooks/deploy
      $ git update-index --chmod=+x .openshift/action_hooks/post_deploy
      $ git update-index --chmod=+x .openshift/action_hooks/post_start_ruby-1.9
      $ git update-index --chmod=+x .openshift/action_hooks/post_stop_ruby-1.9
      $ git update-index --chmod=+x .openshift/action_hooks/pre_build
      $ git update-index --chmod=+x .openshift/action_hooks/pre_start_ruby-1.9
      $ git update-index --chmod=+x .openshift/action_hooks/pre_stop_ruby-1.9
      $ git commit

      The do another commit and push. If that still doesn’t create the database, you could try running a bundle exec rake db:migrate RAILS_ENV=”production” by hand after logging into the server via SSH.

      If that still doesn’t work, then perhaps they have changed something at openshift. I haven’t deployed a rails app since I wrote this original post, so I’m kind of at a loss at this point otherwise.

  9. The first commit actually does get the tables created, but it’s still not working. I’m not sure where to run the bundle exec command within the directory structure (or if I need to if I’ve got the tables), when it does run I just get errors – http://pastebin.com/fv1fcU08

    I’m not sure I’ll get any further, but thanks for your help

Comments are closed.