27
Jesus Jackson Developing Rails Apps in Technical Isolation

Developing Rails Apps in Technical Isolation

  • View
    678

  • Download
    0

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Developing Rails Apps in Technical Isolation

Jesus Jackson

Developing Rails Apps in Technical Isolation

Page 2: Developing Rails Apps in Technical Isolation

Background

● Live in Washington, D.C.● Software developer who has been leading a

Ruby on Rails project for over 2 years.● Developer advocate in a Java-based world

Team Background● 15 developers● DoD clients in secure spaces● Development occurs on a restricted intranet

- no way for our application to connect to the Internet.

Page 3: Developing Rails Apps in Technical Isolation

Technical Isolation?

No● Developing on an island :o)

Yes● Developing apps on an intranet● No sudo privileges on servers● Don't have control over firewall rules

Page 4: Developing Rails Apps in Technical Isolation

What do we do?

Page 5: Developing Rails Apps in Technical Isolation
Page 6: Developing Rails Apps in Technical Isolation

How do we manage our Rubies and gemsets behind a firewalled/restricted environment?

Problem 1: Using RVM

Page 7: Developing Rails Apps in Technical Isolation

Solution: RVM::FW

● Created by Steven Haddox - a developer who worked on my team and was instrumental in our success

● https://github.com/stevenhaddox/rvm_fw● Sinatra app that runs on a Phusion enabled

web server● Works by modifying RVM's ~/.rvm/user/db

to point to an internal file which reference your Rubies.

Page 8: Developing Rails Apps in Technical Isolation

Set up RVM::FW

1) "rake boot:strap" to download Rubies and packages2) Copy contents and deploy to your internal server3) Install RVM: "bash < <( curl http://<your-server>:<port>/releases/rvm-install-latest )"

4) Configure RVM: "wget http://<your-server>:<port>/db -O ~/.rvm/user/db"

5) "rvm reload"...and viola!

Page 9: Developing Rails Apps in Technical Isolation

Using RVM::FW

● Other projects on your network can now use your server to install RVM::FW and maintain their Rubies.

● http(s)://[your_host]:[port]/db to get a list of rubies. Your users can copy and paste the contents into their ~/.rvm/user/db to point to your RVM::FW instance to download its Rubies.

● http(s)://[your_host]:[port]/known - will provide a list of available Rubies when user does "rvm list known"

Page 10: Developing Rails Apps in Technical Isolation

Problem #2: CapistranoDeployment Gotchas

Page 11: Developing Rails Apps in Technical Isolation

Using Capistrano

● Not very difficult to set up, even in a restricted environment.

● You need to set up key-based authentication, which was my team's primary challenge. Telnet and FTP are not supported.

● By default, Capistrano attempts to use sudo. "set :user_sudo, false" within deploy.rb to bypass this.

Page 12: Developing Rails Apps in Technical Isolation

Capistrano

● Place chmod task in deploy.rb to chmod 775 so releases/### and releases/###/public are accessible to Apache.

namespace :permissions do desc "chmod the release and public folder for Apache" task :make_public do run "chmod 775 #{release_path}" run "chmod 775 -R #{release_path}/public" endend

Page 13: Developing Rails Apps in Technical Isolation

Capistrano

● Important to stop and restart Resque workers

namespace :resque do desc "Stop resque workers" task :stop do begin run "cd #{shared_path}/path; RAILS_ENV=production bundle exec rake resque:stop" rescue Exception => e puts "!" * 80 "ERROR: Unable to stop Resque workers: #{e}" puts "!" * 80 end endend

Page 14: Developing Rails Apps in Technical Isolation

How do we test email notifications when the SMTP server is locked down?

Problem 3: Testing Email

Page 15: Developing Rails Apps in Technical Isolation

Testing Email Notifications

● Emails blocked when being sent from ActionMailer

● By default, ActionMailer delivery is sent to an SMTP server running on your localhost on port 25.

● SMTP server won't receive emails and don't have ability to set up another full-fledged SMTP server and configure ActionMailer to reference it

Page 16: Developing Rails Apps in Technical Isolation

Solution: MailCatcher

● Runs a lightweight SMTP server on your localhost

● Catches any emails sent to it and displays emails in a nifty interface.

● Configure your app to send mail to smtp://127.0.0.1:1025

● View emails at http://127.0.0.1:1080

Page 17: Developing Rails Apps in Technical Isolation

MailCatcher UI

Page 18: Developing Rails Apps in Technical Isolation

Problem 4: Using GitHow to use Git in an SVN world

Page 19: Developing Rails Apps in Technical Isolation

SVN is still prevalent

● Every project on the contract used SVN● No official server or host for Git on the

intranet.● Git was misunderstood and misinformation

flew rapidly.● It was difficult for people to see the benefits

of a distributed versioning control system because of the small learning curve.

Page 20: Developing Rails Apps in Technical Isolation

Solution: git svn

● Tool allows you to use Git as a valid client, but push all of your changes to an SVN server.

● You can use the nifty features of Git locally (branching/merging, rebasing, etc.)

● You can use Git locally while the rest of your team or organization uses SVN.

● It's a great tool to get your team's feet wet with Git without having to make a complete commitment.

Page 21: Developing Rails Apps in Technical Isolation

Using git svn

● "git svn clone [SVN URL] -s" - import your SVN repo into your local Git repo

● "git commit -am 'My awesome commit message'" - commit locally without pushing to the SVN server. You can do this many times without modifying the SVN repo.

● "git svn dcommit" - Push all of your changes to the SVN repo. Performs an SVN commit for each one of your local commits.

● "git svn rebase" - Pull all changes from the SVN repo and updates your local repo.

Page 22: Developing Rails Apps in Technical Isolation

git svn caveat

● Remember, you're still using SVN under the hood.○ Rebase your work as much as possible.○ Don't simultaneously interact with a Git repo.

● SVN history is linear

● A "git svn dcommit" rewrites your local Git to include a unique ID. Working simultaneously with a remote Git repo can screw things up. Keep it simple :o)

Page 23: Developing Rails Apps in Technical Isolation

Solution 2: Gitlab

● If you can host Git on a server, try Gitlab.● Allows you to manage multiple repos. It's

pretty much your very own Github.● You can handle user access permissions,

merge requests, issues, wikis, and code reviews.

Page 24: Developing Rails Apps in Technical Isolation

Problem 5: Managing GemsHow do we host gems in restricted environments?

Page 25: Developing Rails Apps in Technical Isolation

Solution: "gem server"

● Rubygems comes with the command "gem server"

● Running this command will serve all of your gems from http://localhost:8808

● Visiting the address in your browser will provide gem details.

● When you install new gems, they'll automatically be available through your gem server.

Page 26: Developing Rails Apps in Technical Isolation

Solution 2: Gem In A Box

● Provides more features, like the ability to push gems to the server.

● Easy to set up:○ Create the directory for storing gems○ Modify the config.ru file to point to the gems

directory.○ Run the server

● Push gems via the "inabox" command:○ "gem inabox ./my-awesome-gem-1.0.0.gem"

Page 27: Developing Rails Apps in Technical Isolation

The endQuestions?