Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from Heroku to AWS using Docker

blog.doordash.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Migrating from Heroku to AWS using Docker

#41

Post by eshamow »

alvinchow86 wrote: post #38
eshamow wrote: post #36

Suggesting that moving to Docker obviates the need for configuration management is frankly naive. The whole point of CM tools is to make the layout/configuration of systems predictable. That doesn't make Docker or CM redundant. It means that when you build Docker containers, it makes good sense to install a CM tool and use it to do the systems configuration. Saying that the Dockerfile works like BASH and thus makes l…

Appreciate the comment. The point I was hoping to get across wasn't that Docker would completely replace CM (or that CM is a bad thing), but that it could help reduce the amount of work in the CM world. As mentioned, we still needed to use Chef anyway (and using Opsworks to get a head start), so at least in this kind of environment CM is still necessary. That said I can see how the article could be slightly misleadin…

I appreciate your response, but -

When you discuss CM being necessary, you are talking about using it on the host and not within the container.

Ultimately, operability and proper configuration inside the container is critical. Using a Dockerfile with no CM inside it is not much of an improvement on not using CM anywhere.

You don't need stateful CM inside the container. It's fine to fire and forget - use Puppet in apply mode or Chef solo. But there's a reason these tools are used in building AMIs and containers over scripting languages - we've come a long way over the past 10 years, and I still feel that switching to the Dockerfile as a configuration mechanism is like moving back to configure/make/make install.

Re: Migrating from Heroku to AWS using Docker

#42

Post by calineczka »

This post is mostly focused on migrating application instances. I wonder what's the best step-by-step way to move database from Heroku/EY/etc provider to Amazon .

And is it possible to first migrate app instances that would for some time use Heroku DB and then migrate the DB itself? Instead of doing everything in one big step?

Re: Migrating from Heroku to AWS using Docker

#43

Post by Gigablah »

eshamow wrote: post #41
alvinchow86 wrote: post #38

Earlier quoted context omitted.

Appreciate the comment. The point I was hoping to get across wasn't that Docker would completely replace CM (or that CM is a bad thing), but that it could help reduce the amount of work in the CM world. As mentioned, we still needed to use Chef anyway (and using Opsworks to get a head start), so at least in this kind of environment CM is still necessary. That said I can see how the article could be slightly misleadin…

I appreciate your response, but - When you discuss CM being necessary, you are talking about using it on the host and not within the container. Ultimately, operability and proper configuration inside the container is critical. Using a Dockerfile with no CM inside it is not much of an improvement on not using CM anywhere. You don't need stateful CM inside the container. It's fine to fire and forget - use Puppet in app…

What else do you think is happening under the hood when you use a CM tool like, say, Ansible? Ansible translates your configuration to small Python scripts, uploads them to the remote host and runs them.

What I'd like to see is a "script dump" output that still lets you create your yml configuration but converts it into shell scripts that you can call from your Dockerfile without any dependencies.

Of course, now you have an additional build step... and what could you use to tie everything together? make/make build :)

Re: Migrating from Heroku to AWS using Docker

#44

Post by Gigablah »

alvinchow86 wrote: post #35
toomuchtodo wrote: post #6

Earlier quoted context omitted.

Store your Dockerfile in version control, either in its own repo with other Docker files or in the same repo as the app. Use Jenkins (or preferred build system) to fetch the Dockerfile, your app, build the Docker container, and then docker push to your own private docker registry. Bake your AMIs with your Docker image (tags are your friend). You don't want to have to scale and find out you're having problems fetching…

Yup, pretty much. We actually were using Docker Hub but they went down a few times so we are going to try setting up a private registry. We also tried Docker Hub's "Automated Build" service but it doesn't do any layer caching between builds so we found it way too slow. One thing I'd recommend is at least installing the Docker service itself on the AMI (spinning up EC2 instances, especially on Opsworks, is slow enough…

I actually trust Docker Hub more compared to a private registry setup... had so many hard to debug EOF errors, registry container crashes, etc.

But the Docker Hub is also a single point of failure, so now I'm considering just having our CI service dump (docker save) the container build to a tarfile and send it to S3, then having the destination host download it and run docker load.

Docker's handling of layers is excruciatingly slow, anyway.

Re: Migrating from Heroku to AWS using Docker

#45

Post by jordanthoms »

calineczka wrote: post #42

This post is mostly focused on migrating application instances. I wonder what's the best step-by-step way to move database from Heroku/EY/etc provider to Amazon . And is it possible to first migrate app instances that would for some time use Heroku DB and then migrate the DB itself? Instead of doing everything in one big step?

Yes, it's possible to point a heroku app at a EC2 DB, and it's also possible to point an app running on EC2 at a Heroku DB.

Re: Migrating from Heroku to AWS using Docker

#46

Post by leg100 »

eshamow wrote: post #36

Suggesting that moving to Docker obviates the need for configuration management is frankly naive. The whole point of CM tools is to make the layout/configuration of systems predictable. That doesn't make Docker or CM redundant. It means that when you build Docker containers, it makes good sense to install a CM tool and use it to do the systems configuration. Saying that the Dockerfile works like BASH and thus makes l…

> It means that when you build Docker containers, it makes good sense to install a CM tool and use it to do the systems configuration.

If you belong to the "one container, one process" camp, I'd say CM has little utility.

Let's say we have a redis image. Using a CM I'd have to:

  * install ruby and various ruby lib pkgs
  * install chef or puppet, and a multitude of rubygems 
  * add recipes/manifests
My image is now several times bigger than it need be, and the configuration is now more opaque, in several files. It's a pain to debug and troubleshoot when something deep inside the recesses of chef-solo fails. And why would I?

I'd rather have a dockerfile with `apt-get update && apt-get install -y redis-server` and perhaps a line adding a custom config file. Very readable.

Re: Migrating from Heroku to AWS using Docker

#47

Post by ksajadi »

This is a great article and breaks down the components needed to run Docker in production on your own servers. We have been doing that in Cloud 66 - http://www.cloud66.com/ (on 8 cloud providers including AWS) for a while and it's been a great experience: http://blog.cloud66.com/docker-in-production-from-a-to-z/

Re: Migrating from Heroku to AWS using Docker

#48

Post by mark_l_watson »

jordanthoms wrote: post #34

I'm in a situation like this as well, using Heroku but not happy with the performance on the Dynos and looking to move to EC2 (we already use our own databases etc hosted on EC2). The biggest issue is finding a solution which can give similar ease of use and functionality as Heroku. Doing a opsworks/chef setup like this isn't appealing - over time we want to have many microservices which can be scaled independently,…

My first thought when I read the news about Heroku's beta pricing changes was that if a huge number of non-paying customers leave then Heroku might provide more resources for less money to paying customers.

As another commenter said, I would also like to see an honest writeup by the author of cost and engineering time trade offs - written a year from now.

Re: Migrating from Heroku to AWS using Docker

#49

Post by mhale »

alvinchow86 wrote: post #15
seanwilson wrote: post #2

> With Heroku, you lose fine-grained control and visibility over your servers. Installing custom software in your server stack is far from straightforward, and it’s not possible to SSH into a server to debug a CPU or memory issue. I found this annoying at first along with not being able to save files to the server. However, Heroku is forcing you to automate server setup so servers can be restarted, destroyed and crea…

As skwirl pointed out, yes SSHing is more for debugging production server issues than for setting up the servers. The transition itself took one month. So far it's been several months and it's been very stable with pretty minimal maintenance. We did end up writing a number of Python scripts to help make the deploy process easy for developers (i.e. replicating most of the common Heroku features we used to use)

While you cannot ssh directly, you can get a bash shell on a heroku dyno quite easily by running:

heroku run bash

This can be very handy for debugging.

That said, heroku will spin up a new dyno instance to run the bash shell. You cannot (as far as I know) get a shell on a specific dyno of your choice.

Re: Migrating from Heroku to AWS using Docker

#50

Post by bike_index »

ksajadi wrote: post #47

This is a great article and breaks down the components needed to run Docker in production on your own servers. We have been doing that in Cloud 66 - http://www.cloud66.com/ (on 8 cloud providers including AWS) for a while and it's been a great experience: http://blog.cloud66.com/docker-in-production-from-a-to-z/

I'd like to chime in here in support of Cloud66. I've been running normal (non-dockerized) Cloud66 for about a year on a wide variety of projects, including the main Bike Index site (https://bikeindex.org), and it's fantastic.

It's all the ease of Heroku and all the flexibility of actual servers, and way cheaper than Heroku. The only reason I've touched Docker on Cloud66 is JRuby - since this article is about a python app, it would be also require Docker. But for Ruby MRI applications, the logical first step as soon as Heroku stops being cost effective is immediate (and painless) migration to Cloud66.

Post reply on HN