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

Docker Jumpstart

github.com

Post reply on HN
Print view View original

41–45 of 45 posts

Re: Docker Jumpstart

#41

Post by laex »

brunoqc wrote: post #40
laex wrote: post #25

Anybody wanting to try out Docker + GoLang + AWS Beanstalk, I've made a sample app / guide here - https://github.com/OrganicCoffeeNepal/DockerBeanstalkSample

Thanks for the link. Is Beanstalk worth it? Is it cheaper than an ec2 instance?

I haven't done any systematic comparison to tell which one's cheaper. AWS allows 1 year of free tier service, so I'm using that. What I like about Beanstalk is that it's extremely easy to deploy updates. Just commit the changes and execute eb deploy. Setting up a new environment via. CLI is also a breeze.

Re: Docker Jumpstart

#42

Post by tvmalsv »

icebraining wrote: post #37
xchaotic wrote: post #35

Earlier quoted context omitted.

That's why you want to use volumes for mutable data such as your source code repo - you isolate the changing parts and keep the containers static.

But if the source is mutable data, what isn't? Everything eventually mutates - dependencies have updates, configurations change, etc. Isn't the point of images that you "freeze" a static release that can be deployed everywhere? It seems that by that point you've lost the advantage of using images; if parts of the system must be loaded outside of the container, it seems you might as well simply use a configuration man…

I know, I'm a little late to this party, but just in case anyone is still around... :)

For me, mounting my local app files as a volume is useful during development since it keeps the workflow fast. I don't have to rebuild the image every time I want to try the app out, I get to use the new code without delay.

If I were deploying as a container, I presume my build process would check the app out of git and build the image based on that fresh checkout. I'm just using Docker as a convenient way of simulating my production environment (dev'ing on Ubuntu 15.04, but deploying to Debian 7), and still be able to iterate rapidly.

Re: Docker Jumpstart

#43

Post by icebraining »

tvmalsv wrote: post #42
icebraining wrote: post #37

Earlier quoted context omitted.

But if the source is mutable data, what isn't? Everything eventually mutates - dependencies have updates, configurations change, etc. Isn't the point of images that you "freeze" a static release that can be deployed everywhere? It seems that by that point you've lost the advantage of using images; if parts of the system must be loaded outside of the container, it seems you might as well simply use a configuration man…

I know, I'm a little late to this party, but just in case anyone is still around... :) For me, mounting my local app files as a volume is useful during development since it keeps the workflow fast. I don't have to rebuild the image every time I want to try the app out, I get to use the new code without delay. If I were deploying as a container, I presume my build process would check the app out of git and build the i…

Ah, fair enough, I was really thinking about shared, deployable images. I suppose this use case makes sense.

Re: Docker Jumpstart

#44

Post by rikrassen »

zwischenzug wrote: post #29
rikrassen wrote: post #8

Earlier quoted context omitted.

For some reason I found docker very unintuitive, even writing a simple build script was confusing. I agree, this book would have done a much better job of introduction than the docker site.

Out of interest, what did you find confusing/unintuitive? I'm writing a book on Docker so am interested in where the pain points are.

It was mostly how we wanted to use it at my company. It didn't seem clear whether docker should just set up the system (apt-get, pip install) or also checkout the code. To add to the complexity, we have a puppet script we run on the machine to install dependencies. I had no idea how Docker who supposed to fit into this pipeline. So basically, I didn't know what docker was supposed to be good at, i.e. do better than other tools.

Re: Docker Jumpstart

#45

Post by zwischenzug »

rikrassen wrote: post #44
zwischenzug wrote: post #29

Earlier quoted context omitted.

Out of interest, what did you find confusing/unintuitive? I'm writing a book on Docker so am interested in where the pain points are.

It was mostly how we wanted to use it at my company. It didn't seem clear whether docker should just set up the system (apt-get, pip install) or also checkout the code. To add to the complexity, we have a puppet script we run on the machine to install dependencies. I had no idea how Docker who supposed to fit into this pipeline. So basically, I didn't know what docker was supposed to be good at, i.e. do better than o…

Interesting.

You might be interested in my blog and book:

http://zwischenzugs.wordpress.com/

There are links through there to my book, where the first chapter is free to download, and may help. Let me know if you have any feedback.

Post reply on HN