Quick noob question or two about Heroku.
I have a rails app I would like to deploy on Heroku.
If I want the address to be www.whatevername.ie do I need to purchase this domain name or does the custom domain name feature with Heroku allow me to do this?
Secondly, what is the difference between development and production with regards to deploying an app on Heroku? Once it's deployed and on the net, does this mean it is in fact "in production" so to speak?
Thanks!
Heroku
To answer your questions more fully, you need to appreciate that Heroku is a Platform As A Service - meaning that it will provide the back-end infrastructure for your application, but that's it:
In terms of a domain name, it's not for Heroku to buy you a domain. A domain is literally just a "mask" for an IP address (a shop window), which means you have to buy it (as the DNS system takes a lot to manage & maintain)
Heroku's custom domain feature is simply a means for you to accommodate external domain name traffic to your application. You'll have to buy a domain (we use Namecheap, but there are 1,000's of domain registrars you can use)
--
Rails
If you want to run a Rails application, the development and production environments are very important, although not much different than each other.
As mentioned in the referenced question, the underlying differences between "production" and "development" modes / environments for Rails is efficiency. You're running the SAME source code in both environments - the difference is how that source is handled, compiled & served
--
Development
Rails logger is running all the time
Exceptions are captured & displayed on screen
Classes are not cached
Assets are compiled "on the fly" (dynamically handled)
Typically operated with low-efficiency services (DB / Web Server)
Loads everything individually for development purposes
Production
"Assets" precompiled & served statically (for performance)
Classes can be cached
Production-grade web & DB servers recommended
Focus on efficiency & speed
--
By default, Heroku will run your Rails application in production mode
If I want the address to be www.whatevername.ie do I need to purchase this domain name or does the custom domain name feature with Heroku allow me to do this?
You need to purchase the domain name.
-
Secondly, what is the difference between development and production with regards to deploying an app on Heroku? Once it's deployed and on the net, does this mean it is in fact "in production" so to speak?
Development is what's on your computer locally; production is what's on the internet for all to see (in this case, on Heroku).
Related
I have a live, functioning Rails app that is currently running on Heroku. In order to scale back on costs, I'm in the process of migrating the whole app to Digital Ocean. Much of what I've done so far has only involved adding extra gems and files to support Capistrano deployment, but I just ran into the first (presumably of many) instance where I need a different configuration for my app on Digital Ocean vs. what I use for Heroku. Specifically it's Redis. On Heroku you need to use an add-on ("Redis To Go") since you can't install Redis directly. Thus my reds_init.rb looks like this:
if Rails.env.development? || Rails.env.test?
redis_conf_path = Rails.root.join("config/redis", "#{Rails.env}.conf")
redis_conf = File.read(redis_conf_path)
port = /port.(\d+)/.match(redis_conf)[1]
`redis-server #{redis_conf_path}`
REDIS = Redis.new(:port => port)
end
if Rails.env.production?
uri = URI.parse(ENV["REDISTOGO_URL"])
REDIS = Redis.new(:url => ENV['REDISTOGO_URL'])
end
That production configuration is Heroku-specific and for Digital Ocean I'll be needing something a lot more like (perhaps exactly like) the test/development configuration. However, during the migration I need to have both working as I may need to deploy code (bug fixes etc) to the live production environment while slowly setting up the Digital Ocean environment.
Since there will likely be many other instances of this sort of thing as I work through this migration, I'm thinking that the best way to handle this would be a separate Git branch for the Digital Ocean environment. But I'm not entirely sure the best way to set this up. I'd really appreciate any pointers from someone who's had to do a migration like this on a live site.
Here are my thoughts with a general outline of the approach I've taken in the past:
For good measure, make sure your production environment is stable (tests passing) and preferably deployed off of the master branch on git. You'll want to be able to reliably deploy hotfixes on master as well as cross-reference any future changes during your migration with your development environment. Backup your DB as well.
Create and checkout a new git branch for digital ocean.
Create a new Rails configuration environment or digital ocean preferably with a name consistent with your branch name in (2). Make sure your new environment is isolated from what you're using in production. In other words, you shouldn't be able to "contaminate" your production environment from your new environment. This means all db & api connections use separate credentials. Also try to keep version control in mind with commits tracking specific changes. This will make debugging easier through git bisect if necessary.
Configure and test deployment of your application server on digital ocean using data in a seed database. Make sure you can perform all aspects of deployment, including running migrations, asset precompiling, bundler, stability of nginx/unicorn without affecting the stability of the site.
Take snapshots of your production database(s) on Heroku and import them into the database you're using on Digital Ocean. Again test your site and make sure it's working properly with production data.
Schedule a time when you can take your site offline for enough time to do the migration. You'll need to move DNS, DB data, environment configurations, and whatever other environment specific data.
Since your master branch should be stable, you can always go back to it to deploy bugfixes as necessary. However, make sure you incorporate (git cherry-pick) these commits into whatever branches are ahead of master for consistency. I'd recommend checkout out git-flow if you haven't already: http://nvie.com/posts/a-successful-git-branching-model/.
This is mostly just food for thought as there's a lot to be said about the subject of migrating an application between data center. Specific approaches and strategies are going to depend on your dev ops setup and application environment.
I was wondering if there was around a hosting as those that have existed for years for PHP that would give the opportunity to publish many Ruby and Rails applications and not as Heroku that forces a single application for dyno.
In classical hosting PHP I can create a folder, upload some files in php and navigate them through links.
You can something like that on some Web hosting?
For small projects, Heroku is really the best deal. Their free tier does everything you'd need for something that's occasionally used and doesn't have a lot of scaling issues. You are restricted to one application per "dyno", per account.
For anything more demanding it's not hard to set up a hosting environment on a VPS provider. Although it takes some additional knowledge, you'll be able to set up and configure a web server using a tool like Passenger and manage your own instances. For $10/mo. you can have a very capable server instance that will handle way more than a $7/mo. dyno can manage. Even the $5/mo. server from a provider like Digital Ocean is a fantastic deal.
PHP's fire and forget method of hosting is convenient, but it's actually a lot more work in the long haul compared to an efficient workflow based around Rails and Passenger.
For example, using Capistrano and a version control system like Git you can make changes, test locally, package up into a commit and deploy on your server within minutes. It's basically effortless once you get it working.
For small production projects, I use webfaction, it's easier to push to production than to configure a complete VPS as it's more like a managed hosting (with all the tools and documentation you need for rails) .
I use mina for deployment and Git for version control.
To complete #Tadman answer you can check OpenShift if you want a more Heroku like alternative.
When I started using Rails I was also tempted to compare and seek for a 'php-hosting' like solution. But it's just a different approach.
To answer your question more precisely, you don't drop files in a folder and navigate with links in a classic rails project. You have to understand the concept of MVC, routing ...
I suggest that you give the rails-tutorial a try, it is a good starting point for understanding the whole rails ecosystem.
You can try Ruby hosting on Jelastic PaaS with automated deployment to containers and scaling, as well as pay-per-use pricing model that makes it not so pricy.
There are pre-configured Apache and NGINX containers for running Ruby application, supported different Ruby versions, built-in Ruby on Rails framework, Passenger, Puma, Unicorn, Bundler dependency manager etc.
When deploying a Ruby application, only a single context (ROOT) can be used. However, you can switch between three deployment types: deployment, production and test.
More details are described here https://jelastic.com/blog/ruby-paas-hosting/
You can start with a free trial and test how it suits your project before investing any budget. This Ruby PaaS is available on different local service providers https://jelastic.cloud/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
My team and I are currently building a Ruby on Rails web application (SaaS model) that will be used by at least 5k users, and there will be probably more after.
While we reach the end of the development process I was wondering what kind of hosting we were going to use.
I first thought about using a standard web server with Nginx and Puma, and a second server dedicated to the database, but the scalability is a thing that we really want. So I started to check for an alternative solution (knowing the fact that no one of our team is an admin), and I end up on Heroku.
So, my question is why should I use something like Heroku ? After watching the prices I've the feeling it's going to cost more than a standard server for less performances, but i'm still intrigued by it : if people use it, there must be a reason.
Heroku & DigitalOcean etc, are just services which make deploying to "cloud" hosting easier. Heroku uses AWS's computing infrastructure to host your apps, but provides an environment to help deploy them easier:
Why do people use Heroku when AWS is present? What distinguishes Heroku from AWS?
Heroku vs...
Some of the important points to note about Heroku is you don't have direct access to your database, as well as relying on their infrastructure to hold up (E.G if something happens to their datacenters -- which has happened before -- you're at the mercy of Heroku & AWS's engineers).
There are two issues we have with them:
You're obliged to use their AWS Postgres DB
You've got to route through Heroku's domain
--
Choice
The choice you really have is whether to use something like RackSpace (like us), or use a service such as Heroku or DigitalOcean. To me, there is not much difference, as Heroku / DO just provide an environment to push to VPS's running on their respective partner hosting providers.
With the ease of deployment (git push), you get the downside, which is your database, environment etc will not be directly configurable. I.E if you use Heroku, it's very difficult to get off it (transferring data etc).
By using a direct solution, such as RackSpace or AWS, you are in control of the environment, which means you get direct access to your database, dependent services & other aspects of the system. Of course, it comes with more maintenance, but you aren't locked into one system, as you are with Heroku
--
System
In terms of the system, Heroku locks you into using their domain infrastructure:
The domain example.herokuapp.com will always remain active, even if
you’ve set up a custom domain. If you want users to use the custom
domain exclusively, your app should send HTTP status 301 Moved
Permanently to tell web browsers to use the custom domain. The Host
HTTP request header field will show which domain the user is trying to
access; send a redirect if that field is example.herokuapp.com.
This is coupled with the lock-in of using the likes of different dependencies & other aspects of the Heroku system. It's basically a store-front for Amazon's AWS infrastructure
--
Recommendation
If you expect to have 5k users, I would highly recommend looking at
setting up your own environment, probably with RackSpace (as we
use them).
It's my opinion that Heroku is great for developers who just want to get an app up-and-running, but it's not very good with providing an environment you can control.
Some examples of this include your database - setting up on Rackspace etc means you get to define your database yourself. On Heroku, the db is kept in a third party datacenter, which you never see (try setting up PHPMyAdmin on Heroku)
Another example would be how you're going to scale the application. If you have memory leaks etc, you'll be far better positioned to have your own stack in place, rather than relying on someone else's. It allows you to define the specific details of how the app should operate - giving the ability to scale much easier
So I host with company X and have my domain on there. I deployed my app to heroku and pointed my domain at it. I can't wrap my head around if I am hosting my site on heroku now or if I am hosting it on company X's servers.
I would assume I'm hosting on herokus server because that is the most logical, but just keep having this brainfart.
Could someone please explain this to me?
Your application is on Heroku's server. All company X has done is perform the DNS magic necessary to map the friendly URL (www.yoursite.com) to your Heroku deployment.
Amazon
You should also be aware that Heroku doesn't actually "store" the app on its own servers - it uses Amazon's ec2 cloud to create instances of your app
So although you have your domain with company X, your app handled through heroku, it will actually be running in one of Amazon's data centers
Keep that in mind when you start to grow (you may find benefits of using Amazon directly)
I am running a Rails app on the AWS infrastructure using several EC2 instances, a RDS DB, a round robin session-sticky load balancer and Route 53.
The application is serving pages for several domain names (same app looks and functions different depending on domain name).
The Rails code is hosted on a NFS share on a staging instance where the web server is running in development mode, while the other boxes load the apache config and application code via NFS and run in production mode.
What I'd like to do is to SSL-enable the whole thing as we're starting to process payments and whatnot. Due to the nature of the application and the heavy apache/Passenger optimization in place, I can't set up a vhost for each domain, but rather use a wildcard for www.* to load pretty much the same code, and the app does the rest internally.
Haven't really been able to figure out an ideal way to resolve this. Would anyone have an idea?
Thanks!
After a bit of discussion in the comments we came to this conclusion:
The application is currently hosted in one single <vhost> on Apache where the Application does the differentiation between hostnames for the different layouts.
The problem here is to support SSL without having to setup each domain with it's own certificate and a different vhost as that would require running the Rails app multiple times where it's unnecessary.
By using a Multiple Domain Certificate (MDC) this problem can be solved with only one vhost and one certificate, but MDCs are more expensive than normal certificates. So depending on the number of domains you need to support it may be cheaper/easier to just do it manually with multiple certs, or opt to pay the more expensive MDC but save time and maintenance cost.
While at it I found this nice wikipedia comparison of Certificate Authorities and their trust level in different browsers:
http://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers