heroku

Why do people use Heroku when AWS is present?


Frst things first, AWS and Heroku are different things. AWS offer Infrastructure as a Service (IaaS) whereas Heroku offer a Platform as a Service (PaaS).

 

What’s the difference? Very approximately, IaaS gives you components you need in order to build things on top of it; PaaS gives you an environment where you just push code and some basic configuration and get a running application. IaaS can give you more power and flexibility, at the cost of having to build and maintain more yourself.

To get your code running on AWS and looking a bit like a Heroku deployment, you’ll want some EC2 instances – you’ll want a load balancer / caching layer installed on them (e.g. Varnish), you’ll want instances running something like Passenger and nginx to serve your code, you’ll want to deploy and configure a clustered database instance of something like PostgreSQL. You’ll want a deployment system with something like Capistrano, and something doing log aggregation.

That’s not an insignificant amount of work to set up and maintain. With Heroku, the effort required to get to that sort of stage is maybe a few lines of application code and a git push.

So you’re this far, and you want to scale up. Great. You’re using Puppet for your EC2 deployment, right? So now you configure your Capistrano files to spin up/down instances as needed; you re-jig your Puppet config so Varnish is aware of web-worker instances and will automatically pool between them. Or you heroku scale web:+5.

Hopefully that gives you an idea of the comparison between the two. Now to address your specific points:

Speed

Currently Heroku only runs on AWS instances in us-east and eu-west. For you, this sounds like what you want anyway. For others, it’s potentially more of a consideration.

Security

I’ve seen a lot of internally-maintained production servers that are way behind on security updates, or just generally poorly put together. With Heroku, you have someone else managing that sort of thing, which is either a blessing or a curse depending on how you look at it!

When you deploy, you’re effectively handing your code straight over to Heroku. This may be an issue for you. Their article on Dyno Isolation details their isolation technologies (it seems as though multiple dynos are run on individual EC2 instances). Several colleagues have expressed issues with these technologies and the strength of their isolation; I am alas not in a position of enough knowledge / experience to really comment, but my current Heroku deployments consider that “good enough”. It may be an issue for you, I don’t know.

Scaling

I touched on how one might implement this in my IaaS vs PaaS comparison above. Approximately, your application has a Procfile, which has lines of the form dyno_type: command_to_run, so for example (cribbed from http://devcenter.heroku.com/articles/process-model):

web:    bundle exec rails server
worker: bundle exec rake jobs:work

This, with a:

heroku scale web:2 worker:10

will result in you having 2 web dynos and 10 worker dynos running. Nice, simple, easy. Note that web is a special dyno type, which has access to the outside world, and is behind their nice web traffic multiplexer (probably some sort of Varnish / nginx combination) that will route traffic accordingly. Your workers probably interact with a message queue for similar routing, from which they’ll get the location via a URL in the environment.

Cost Efficiency

Lots of people have lots of different opinions about this. Currently it’s $0.05/hr for a dyno hour, compared to $0.025/hr for an AWS micro instance or $0.09/hr for an AWS small instance.

Heroku’s dyno documentation says you have about 512MB of RAM, so it’s probably not too unreasonable to consider a dyno as a bit like an EC2 micro instance. Is it worth double the price? How much do you value your time? The amount of time and effort required to build on top of an IaaS offering to get it to this standard is definitely not cheap. I can’t really answer this question for you, but don’t underestimate the ‘hidden costs’ of setup and maintenance.

(A bit of an aside, but if I connect to a dyno from here (heroku run bash), a cursory look shows 4 cores in /proc/cpuinfo and 36GB of RAM – this leads me to believe that I’m on a “High-Memory Double Extra Large Instance”. The Heroku dyno documentation says each dyno receives 512MB of RAM, so I’m potentially sharing with up to 71 other dynos. (I don’t have enough data about the homogeny of Heroku’s AWS instances, so your milage may vary))

How do they fare against their competitors?

This, I’m afraid I can’t really help you with. The only competitor I’ve ever really looked at was Google App Engine – at the time I was looking to deploy Java applications, and the amount of restrictions on usable frameworks and technologies was incredibly off-putting. This is more than “just a Java thing” – the amount of general restrictions and necessary considerations (the FAQ hints at several) seemed less than convenient. In contrast, deploying to Heroku has been a dream.

Conclusion

I hope this answers your questions (please comment if there are gaps / other areas you’d like addressed). I feel I should offer my personal position. I love Heroku for “quick deployments”. When I’m starting an application, and I want some cheap hosting (the Heroku free tier is awesome – essentially if you only need one web dyno and 5MB of PostgreSQL, it’s free to host an application), Heroku is my go-to position. For “Serious Production Deployment” with several paying customers, with a service-level-agreement, with dedicated time to spend on ops, et cetera, I can’t quite bring myself to offload that much control to Heroku, and then either AWS or our own servers have been the hosting platform of choice.

Ultimately, it’s about what works best for you. You say you’re “a beginner programmer” – it might just be that using Heroku will let you focus on writing Ruby, and not have to spend time getting all the other infrastructure around your code built up. I’d definitely give it a try.

Note, AWS does actually have a PaaS offering, Elastic Beanstalk, that supports Ruby, Node.js, PHP, Python, .NET and Java. I think generally most people, when they see “AWS”, jump to things like EC2 and S3 and EBS, which are definitely IaaS offerings

Managing Multiple Environments for an App


Create your servers and fix your remotes

We’ll need to create both remote environments, staging and production.Since we’ll be pushing to two applications we are using the –remote argument to make two sensibly named remotes.

First create staging:
$ heroku create --remote staging

Push code to heroku:
$ git push staging master
Migrate database:
$ heroku run rake db:migrate --remote staging
Get remote inof:
$ heroku ps --remote staging
Then production:
First create production:
$ heroku create --remote production

Push code to heroku:
$ git push production master
Migrate database:
$ heroku run rake db:migrate --remote production
Get remote inof:
$ heroku ps --remote production

Linking local branches to remote apps

This pushes my local topic branch named red-bg into remote branch master on the remote repository named production.

git config remote.[remoteName].push [localBranchName]:[remoteBranchName]

$ git config remote.production.push red-bg:master

$ git push production red-bg:master -f

Also, you can do this directly with git push:

$ git push heroku +HEAD:master
$ git push -f heroku HEAD:master

That’s it 🙂


			

	
	



			
				


			
				


			
				


			
				


		

		
heroku db:push
	


		

		

Make sure all gems are install on your system.

sudo apt-get install sqlite3 libsqlite3-dev

sudo gem install sqlite3-ruby


gem install heroku taps sequel


sudo gem install tabs


sudo heroku db:push


OR


sudo heroku db:push –config herokuServerName


If still problem. Use below command


heroku db:pull postgres://root:@localhost/db_name

Else

sudo heroku db:pull --confirm herokuDomanName postgres://userName:@localhost/Locadatabase
 root will be database user name and db_name is database name
Good Luck.........!!

			

	
	



			
				


		

		
Heroku: Getting Started as a Collaborator
	


		

		

One of my recent client project, Client had added me as a collaborator on this working heroku. I was bit confused how will i access/pull/push my code to server. After long research and some mistakes, Finally i am able to perform all relevant operation as developer. Below are few steps we should to follow.


1. Move to your working directory.


$cd appDir


2.Check, Are you already sign-in to heroku server?


$ heroku keys


Will display all keys if you added to heroku for other account. Else you see prompt


$ heroku keys

Enter your Heroku credentials.

Email:


Here you need to Login using your collaborator email id and password. Once you get login, Heroku will add your ssh key. if not then you should to run manually


$ heroku keys:add


That’s it…..


Now you able to pull/push your code to server(Be sure you pushing your code as master OR collaborator).


Few more heroku command, May it helps some times.


1. Login to heroku.


$ heroku login


2. Logout from current session.


$ heroku logout


3.Remove unnecessary ssh key


$ heroku keys:remove KEYNAME


4. Wanted to add other collaborator(developer)


$ herku sharing:add test@gmail.com


“test@gmail.com” is email id of collaborator


5. List app info


$ heroku info


6. Remove collaborator


$ herku sharing:remove test@gmail.com


7. Push code


$ git push heroku 


 

			

	
	



			
				


		

		
fatal: ‘heroku’ does not appear to be a git repository
	


		

		

I was facing same issues, When i cloned a client project and he had already created heroku server. Even he collaborated me to his account.




Below googled solution worked for me.


git remote add heroku git@heroku.com:appname.git


Where appname is the name of your app.


After that


git push heroku master


(assuming you want to push the master branch)


 

			

	
	



			
				


		

		
You have modified your Gemfile in development but did not check the resulting snapshot (Gemfile.lock) into version control
	


		

		

******* this is error **************


You have modified your Gemfile in development but did not check

the resulting snapshot (Gemfile.lock) into version control

You have added to the Gemfile:

* source: rubygems repository http://rubygems.org/

* rails (>= 3.0.0.rc)

* ruby-mysql

* devise (>= 1.1.rc2)

* formtastic

* ruby-debug


$  vi +/PLATFORMS Gemfile.lock


delete —>

PLATFORMS

x86-mingw32


save gemfile.lock


$ git status


$ git commit -m Gemfile.lock -m “windows issues”


$ git status


$ git push heroku master


$ heroku logs


$ git status


$ git diff

diff –git a/Gemfile.lock b/Gemfile.lock

index 371b2f9..d8c867f 100644

— a/Gemfile.lock

+++ b/Gemfile.lock

@@ -54,6 +54,7 @@ GEM

treetop (~> 1.4.8)

mime-types (1.18)

multi_json (1.2.0)

+    mysql (2.8.1)

mysql (2.8.1-x86-mingw32)

polyglot (0.3.3)

rack (1.4.1)

@@ -100,6 +101,8 @@ GEM

execjs (>= 0.3.0)

multi_json (>= 1.0.2)


+PLATFORMS

+  x86-mingw32


DEPENDENCIES

coffee-rails (~> 3.2.1)