I am deploying a web app onto multiple servers. I would like to push code to one of these servers so that it can be updated but not affect the other deployed servers. The web app and server is unique to each client so if I add a feature for one client I would not like to add it to all the other servers that are deployed. There will be occasions where an update might be required for all the active servers.
I am hoping to automate this functionality so that I can push code for one server without it affecting the other servers. I have been looking into using Docker, Ansible, and Kubernetes for this job but am fairly new to deployment in general and would like to get an idea of the best practices for something like this.
Thank you.
It is now deployed as a stand alone web server where a push to the master branch causes an automatic deployment for that one server. The only solution I've come up with is deploying multiple servers individually.
Your question is not strictly related to Docker/Kubernetes but I will try to answer anyway. There are two ways this could be done
1) Maintain a repo for each customer - which has the customer's customization and pulls the common code from somewhere else. Maybe a Git submodule or some other way. This way each customer can have their own lifecycle. I don't like this approach because the drift between customer tends to get bigger. Also, it is like maintaining as many codebases as there are customers - which is not scalable
2) The only way I can think of this can be done in a way which is uniform for all customers is to do feature flags. This has to be during development and is not a purely operational exercise. This is difficult to get started but in longer-term is the only way I think this can be scaled. Specific features for the one customer then can be turned off by configuration. There are also some companies like LaunchDarkly which enable this
From what i've gathered, there are many solutions to my problem but i'd appreciate some suggestions on where to start. here's the stack we're running on heroku currently:
Rails on puma
mongoDB
elasticsearch
redis
mini_magick
What goes into the decision of using Elastic Beanstalk vs OpsWorks vs CloudFormation vs just setting up everything manually myself? Also, I'd really prefer, for financial reasons, not to use some third party service like Docker if possible. The plethora of options leaves me a little confused as to where to begin or how to even choose. Background: right now I really like Heroku b/c i don't have to think too much about sysadmin (on my team i'm the only developer), but we were recently given a lot of annual AWS credits so it seems to make financial sense for us to shift over to AWS.
I want to expand on Mark’s great answer.
Available alternatives
Since you’re the sole developer, Cloud Formation and OpsWorks aren’t good options for you.
With OpsWorks you’ll need to write, or at least be aware of, the Chef automation code that configures your instances. On the other hand, Cloud Formation by itself isn’t enough. It will help you with AWS cloud resources creations, but you will still need to figure out how to orchestrate your applications deployment, just for starters.
Neither of these options can give you everything you need to run and deploy your code like Heroku does right out of the box. You’ll need to implement parts of it by yourself.
Since rolling your own automation on top of EC2 takes even more effort than the options above, I think you have two alternatives within AWS that will fit your needs:
1) Elastic Beanstalk
It’s the closest you can get to Heroku within AWS. You might have to spend some time getting to know the platform at first since it’s not as intuitive as Heroku, but eventually Elastic Beanstalk will provide you with all the tools you need to continue running your applications without spending time on sysadmin tasks.
2) ECS + Empire
Although you mentioned that using Docker is out of question for you, I still would like to highlight the option of using ECS, Amazon’s Docker orchestration service, as an alternative to Heroku.
By itself, ECS doesn’t provide enough automation to do everything you would expect from a PaaS. The service was intended to be used as a building block which you should extend to fit your needs.
Luckily, the guys from Remind have already done this for you. They have released an open source project called Empire, which according to its own description is “a control layer on top of ECS that provides a Heroku-like workflow”.
Empire is compatible with Heroku’s API, and its command line implements the most important features of Heroku.
Empire is an open source project, so if you choose to use it, you should be prepared to dig into its code from time to time. The documentation isn’t perfect, and although there is some traction around the project, the community isn’t very big.
Overall, it’s a good alternative to Heroku if you’re willing to run your applications using Docker -- and why shouldn’t you?
Addons
The main benefit I see to switching from Redis Labs to Amazon’s Redis service (ElastiCache), other than the fact that you have free AWS credit, is that it’s going to be easier (and cheaper) to secure access to your Redis instances when you also run your applications on AWS.
Overall, it’s relatively easy to replicate the addons you’re using with Heroku when you migrate to AWS. For the third-party addons like Elasticsearch you just continue pointing your application to the relevant endpoint. It’s a bit more complicated to replicate Heroku’s native addons like deploy hooks since you can’t continue to use them when you migrate to AWS. In these cases it’s usually possible to find alternative ways of replicating their functionality within AWS.
If you want to learn about how to migrate the most common addons, I’ve written an article that details how to do that, you can find it here: how to replicate Heroku’s addons on AWS.
Hope this helps.
For your Rails app, Elastic Beanstalk is going to be very similar to Heroku. I would suggest using Elastic Beanstalk if you are already familiar with a PaaS like Heroku. It's probably going to be a bit more difficult to configure at first (there are just a lot more options you can configure), but then it will be a very similar deployment process to what you are used to.
Of course Heroku and most (probably all) of those other services you are using run on top of AWS already, so you would really just be switching from one set of services built on AWS to Amazon's own version of those services. You could possibly continue using some of the same services you are using on Heroku. For example I believe MongoLab is the recommended service for MongoDB on Heroku, and it is my preferred MongoDB-as-a-Service on AWS as well. If you want to use those AWS credits for MongoDB you will have to setup the EC2 servers and install and manage MongoDB yourself.
For Redis you could use Amazon's ElastiCache service or RedisLabs. I've found the features and price to be better with RedisLabs than ElastiCache, but you can use your AWS credits with ElastiCache.
For Elasticsearch you would probably want to use Amazon's new managed Elasticsearch service.
I have been chipping away at this for the last couple of days but it has become quite frustrating. My web host is "JustHost" and I have a shared hosting service. I have found this translates directly to "strips you of all privileges," when it comes to trying to set up the deployment on the server.
I thought I had found some really good tutorials that might help me to get my environment set up (I tried to Follow Rob McLarty's blogs on How to setup a Production Server and How to Deploy a Rails App as best as I could). The problem that I found is that I couldn't/didn't need to install any of the things recommended, and when it came time to try to set things up I didn't have permission over the files that were recommended to modify or I didn't have permission to use the commands that were needed.
Naturally I can see why this would be important on a shared host. It would be silly if each individual on the host could restart an apache server willy nilly.
Regardless, I have found this to be the problem with most of the research into getting this deployment up and running. Simply put, most of the things that are recommended I don't have permission to access.
Does anyone know how to setup a deployment on an environment that is so restrictive? Even some resources, or a simple "you are thinking about this way too hard" to point me in the right direction would be really really helpful.
I highly recommend OpenShift as a platform for deploying your rails app on a shared environment. It gives you the option to start for free with a small amount of resources in the server and gives you the ability of starting up everything you need at first like relational or NoSQL databases, loadbalancers, cache, etc.
Heroku is a simple setup formula, For a shared host ROR Deployment Found a good reference : REFERENCE LINK this will help to deploy ROR App on a shared host.(some modules may not be allowed on a shared server environment. You may have to go for a VPS to meet all the requirements).
I'd like to create a development integration server that's on the open internet, running a Ruby on Rails app. But I need FTP or SFTP access to this server, so I can upload files to the codebase via FTP.
Is there a good Rails host that allows FTP connections? The cloud providers like Heroku and Dotcloud just support pushing from source code or build files, it appears.
Thanks!
If you have experience setting up a Linux box I'd suggest using a VPS service, like Linode (www.linode.com) for instance, that way you can pretty much have any service running that you want. And if you don't have experience, that's a great way to learn ;)
If it's just for development, Dreamhost's shared hosting works well enough and is affordable. $8.95/month for unlimited domains and storage and bandwidth and it supports Rails via passenger/modruby. You get ssh and sftp access and you can schedule cron jobs too. Especially great for development since you can easily create and destroy apps and subdomains. Main downside is that you'll face a tough time if you need any custom gems or if you need a different version of ruby from what your host's passenger is using. Customer service is good though, and they can install custom gems or move you around between shared hosts if need be. I probably wouldn't dare to deploy a live Rails site on their (or anybody else's) shared plan though.
All that said, lately I've moved to Heroku for dev/staging instances. Not worrying about custom gems is a big plus, and since we deploy live on Heroku it's nice to have almost the exact same environment in staging as well as live. Heroku is free for single-dyno apps as long as you don't spend too much time in the heroku console. Pushing code from different branches to different instances becomes a piece of cake when you use heroku-san.
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 9 years ago.
Improve this question
I'm close to picking a Rails host. I think I need a VPS solution, because (1) my Rails app has gems and plugins that I need to install to get it working, and (2) I need an SMTP server to send emails from my rails app out to users.
But then it occured to today...
1) Do I actually need VPS and root access to get my app up and running, just because I need to install gems, or can I just copy my Rails app folder up to a Rails-supporting hosting server and start it?
2) If I get a Google Apps account, which would include a business-class GMail solution, would that give me an SMTP server which I could use to send emails to users?
I'm looking for least-support-needed-solution. I can afford to pay for VPS hosting, and a Google Apps account, but I just wonder if this is really my best option.
UPDATE: It's now been just over three years since I first posted this question and answer. I still prefer AWS for all new deployments of a professional or serious horsepower nature (that is, if I don't self-host), but I also regularly deploy demo and tutorial apps to Heroku. I haven't tried any of the many VPS providers that have popped up such as Linode or DigitalOcean, but generally hear good things about them.
The key thing that keeps me from choosing Heroku for all my apps is cost. Since most of my indie projects outside of work are things where I'd prefer to absolutely minimize costs, AWS remains the better deal between AWS vs. Heroku. AWS (or any VPS provider for that matter) has the nice side effect of teaching you the OS along the way, which turns out to be hugely valuable in the long term.
=======================
So, two years later, here's my update. I've used three services for hosting, and here's my take on each of them (I actually love them all, but for various reasons).
Slicehost (now part of Rackspace Cloud Hosting)
This was the first VPS host I tried, and I loved them. The people there were amazing, support was awesome, and it had a really cool grassroots kind of feel. Now that VPS as a solution is more mainstream, and Rackspace has long since purchased Slicehost, I feel that the service offering is still awesome. If you want a simple way to setup a server, plenty of Linux distro choices, and control over your server, this is an awesome option.
Heroku
Love these guys too. I built a hobby app that is hosted there, rpglogger.com (which as of Nov. 2012 has actually migrated to Amazon Web Services), and developing and deploying to Heroku is a no-brainer. I really like working on Heroku for two reasons:
It's dead simple to setup. It really is as easy as they say, in my experience, to get an app running on their platform.
A single dyno (web server instance) is free. So hobby apps, and smaller apps basically get free hosting. It's not just for hobbies though - their plugin architecture is second-to-none, making the addition of 3rd party plugins such as NewRelic, Exceptional, and anything else on their platform a matter of just a few clicks.
You absolutely cannot beat Heroku for ease of use. Deploying an updated version of your app is literally as simple as pushing to your git repo. Heroku isn't necessarily cheap (for anything other than the small app), but if you're in a situation where you believe developer time is more valuable than having control over the server, then this is an amazing option. You can always migrate your app to any other platform anyhow, if it gets big, or the needs of the app vs. the cost of Heroku no longer make sense for you.
Amazon Web Services
I do quite a few small apps, and AWS reserved instances are awesome. For $60 I can basically get a reserved instance for an entire year. That one server is enough to run 3-4 small apps on the same machine, with more optimized memory usage, and the ability to run multiple web server instances (vs. Heroku's one free dyno, though I hear you can custom config your Heroku dyno using unicorn to get more scalability). Basically, AWS scales really well, and lets you share a server among multiple small apps, or spread a larger app across multiple servers.
On top of that initial cost for the reserved instance, I only have to pay for bandwidth and other AWS usage (S3, for example). I think AWS is an amazing mix of ultimate scalability, great costs, ultimate control, and for enterprise customers who want to build their entire infrastructure in the sky, it can't be beat. Rackspace Cloud Hosting provides similar services, and they're probably comparable for most things. But if what you want is the Swiss army knife of cloud services, I think AWS is still way ahead of everyone else.
===============
So, that being said, I started on Slicehost, then went to AWS, then tried Heroku, and today I spend most of my time back on AWS.
AWS is the kind of platform that, after you invest a little time in setting up your collection of VPS machines, it often makes sense to stay on this platform and leverage their ever increasing set of tools.
Granted, it took me two years of trying several options, and trying every level of management from fully managed servers (i.e. Heroku, where you don't even think of the server, just the app) to fully controlled servers (Slicehost and AWS). After all that I've come to this point where I'm ready to manage my own machines in order to get the flexibility and low costs that I want.
Through automation, the actual management of the servers on AWS becomes a non-event, so I don't spend my time constantly patching my machines, or doing other sysadmin tasks. I just check periodically to see if my servers need reboots, I set them to automatically install all security updates (I happen to deploy to Ubuntu servers), which means I spend 99% of my time (at least day-to-day) writing the application - not managing the servers (managing services is instead an occasional task of a few day's work, and then nothing else for months) - which is where I want to spend my time as a developer.
Neither of your requirements are VPS-specific. I use shared hosting from Site5 and currently run two rails apps through the account, both with gems that are not installed on the server by default and sending email. Installing gems does not require root access.
If you want to use a VPS anyway, both Slicehost and Linode are often recommended for Rails apps. A few more are listed under Deploy on the Rails site. I would encourage you to do some research on your choice in either case. Good luck!
You could check out Ruby on Rails Hosting, What is a good Ruby on Rails hosting service?, Good Ruby on Rails free hosting, and What is a good Ruby on Rails and PHP hosting?.
I personally prefer Heroku which has offers free low-scale hosting and is very easily upgraded. Also, they allow you to install gems (similarly to the gem dependencies and rake gems:install, but with different syntax/files), and send a few free emails (200, but it is easily upgraded).
I hate Heroku, it gives you no control over services you want to use and it's massively over priced. Just try to make use of a gem or service they don't specifically support and you will quickly find the limitations and the horrendous pricing.
Heroku is my host of choice.
You can send messages using GMail SMTP as well as the commercial SMTP plugin.
I have also used Slicehost, Linode, Dreamhost and RailsMachine.
Slicehost/Linode are awesome if you can set up the box yourself.
Dreamhost is cheap-as and great for staging. Sites are ponderously slow at times though.
RailsMachine is second to none as a managed service. Highly recommended for the support and the well-tuned stack.
I prefer linode, aws or so.
linode : is a standard linux server. you can login, install 3rd party dependencies and play around just like in your own server. Installing nginx/rails/ruby is the same way as what you did on your own pc/laptop/server.
heroku : is a service. I have to learn lots of stuffs that are not valuable at all if one day you switch to another platform(e.g. linode) or you have your own real server, for example, check the logs, install databases, or install gems. I have printed out most of its documents and read them in 1/2 days, and then I realize that I can't use these knowledges in my working server( that my company offered to me)
linode is cheap enough, $20 per month.
heroku is not always free. and I don't think it's stable enough for demonstration purpose.(e.g. your free heroku app will fall in sleep in spare time, and will cost you several seconds to wake up. this SEVERAL seconds is long enough to make you lost your customers if they want FAST web app )
so, forget heroku, buy or setup your own VPS, use it for years, then you will be an linux expert.
I use HawkHost for all my hosting needs, and I'm 90% sure they meet all your criteria. They provide web hosting and VPS services for very good prices, and their basic web host plan lets you have Rails applications running as well.
I'm used Joyent host- http://www.joyent.com. It's good Rails host.