Live data from Hacker News

Getting Started with Docker

serversforhackers.com

41–50 of 78 posts

Re: Getting Started with Docker

#41
post #31

Earlier quoted context omitted.

I've been thinking along these lines recently, specifically service discovery for front-end load-balancers. Most (all?) of the available reverse proxies will stop sending traffic to a server that is offline, but not discover them. There are solutions such as etcd which you can hook into, or you can write a toy application to use UDP-broadcasts to advertise "Hey I'm http://dev.local.com/ on port 4444", but there isn't…

> ObRelated: Varnish is a beast that few people can configure easily. I'd love to work on a caching reverse proxy that was simple, extensible, and fast. It doesn't have as many caching-specific bells and whistles as Varnish, but nginx is an excellent reverse proxy with some caching abilities (and simple configuration).

The biggest problem is you cannot use `proxy_cache_purge` unless you pay for the commercial version/fork of nginx.

That means you can't expire the cached content by URL.

Re: Getting Started with Docker

#42
post #3

This skips over the hard part: managing docker containers. Poking a hole directly to the container is a leaky abstraction. A reverse proxy like HAProxy or Varnish should be sitting in front of the container. Once you have the reverse proxy setup the next problem that arises is routing to containers based on the domain. Now your HAProxy or Varnish config is going to get bloated and every time you deploy a container th…

What are you finding unreliable in terms of tooling for Puppet on Windows?

Re: Getting Started with Docker

#43
post #12

This is a copy and improvement of the article I wrote last month, even down to the breakdown of "What's that command doing?" with `docker run -t -i ubuntu /bin/bash`. Glad it was useful enough to spur an improved article, at least. http://tonyhb.com/unsuck-your-vagrant-developing-in-one-vm-w...

I've been sitting on my original since December. https://www.dropbox.com/s/lf0qi70vlglasgv/Screenshot%202014-...

Hey, no problem at all! Just surprised to see how similar we were in our styles. Happy that there are more resources popping up now!

Re: Getting Started with Docker

#44
post #3

This skips over the hard part: managing docker containers. Poking a hole directly to the container is a leaky abstraction. A reverse proxy like HAProxy or Varnish should be sitting in front of the container. Once you have the reverse proxy setup the next problem that arises is routing to containers based on the domain. Now your HAProxy or Varnish config is going to get bloated and every time you deploy a container th…

Synapse has the ability automatically discover docker containers and configure HAProxy: https://github.com/airbnb/synapse#docker.

Re: Getting Started with Docker

#46
CoreOS experience designer here. I'm looking for testers to check out the general platform and test some of our new features. All skill levels are fine – new to docker & CoreOS, new to CoreOS only, etc. I'm happy to work with your schedule and make it as quick or involved as you're comfortable with. Anything from emailing a few thoughts to Skype to hanging out in our office in SF for the day.

Email: rob.szumski@coreos.com

Re: Getting Started with Docker

#47
post #13
post #5

Earlier quoted context omitted.

> Poking a hole directly to the container is a leaky abstraction. A reverse proxy like HAProxy or Varnish should be sitting in front of the container. It might be a stupid question but I wonder what's considered a leaky abstraction in this case. By the way, I'm not sure I fully understand your concerns over reverse proxy routing, but I recall that Ambassador pattern linking[0] is a suggested way of tying Docker conta…

>It might be a stupid question but I wonder what's considered a leaky abstraction in this case. I consider poking a hole a leaky abstraction because you are exposing the internals of your stack. The consumer should not know or care that you are using docker containers to serve the application. From a security perspective directly exposing a container may lead to potential exploits of docker itself.

Exposing a container would not to exposing potential exploits of Docker. Docker is not running in the container (and doesn't know anything about Docker).

Exposing a container is a hell of a lot safer than exposing a service on the host OS.

Also not sure I follow you how a consumer would know you are using docker or not.

Re: Getting Started with Docker

#48
post #9

For non-Paas use cases (for example, a development server with a bunch of projects) I find schroot (1) simpler and more productive. For example, you can use the normal `service stop / service start` instead of writing manually init scripts, and you don't get stuck with sharing directories, which I found extremely tricky with Docker (for example, I couldn't start correctly mysql with supervisor sharing the mysql db di…

I've had the same issue with MySQL. It's an issue of timing - You install MySQL, and the MySQL data directory has its data/default databases. Then you share the directory with Docker, and the data lib directory is wiped out (the files don't exist on the host machine, after all). Getting it right in an automated way is a Hard Problem™. As of now, I'm keeping data persisted within the Container, which I don't necessari…

That's actually not true at this time. When you turn a directory into a volume, Docker will copy whatever the contents of that directory into the volume directory... But you need to make the volume after the directory is populated.

Re: Getting Started with Docker

#49

Shouldn't "setting up a correct init process" be part of every "getting started with docker?" http://phusion.github.io/baseimage-docker/

No. That guide assumes you're running a bunch of processes in the container (or even a full system). That's not the case at all when you're doing an "application container" that doesn't need its own cron daemon, ssh daemon, etc.

Containers can be much leaner than the kind discussed there.

Re: Getting Started with Docker

#50
post #19
post #3

This skips over the hard part: managing docker containers. Poking a hole directly to the container is a leaky abstraction. A reverse proxy like HAProxy or Varnish should be sitting in front of the container. Once you have the reverse proxy setup the next problem that arises is routing to containers based on the domain. Now your HAProxy or Varnish config is going to get bloated and every time you deploy a container th…

Update etcd with connection details on container start/stop. Then use a script to watch the appropriate directory in etcd for changes and regenerate the config. Look at "fleet" from CoreOS, and especially their "sidekick" example that uses systemd dependencies to trigger etcd updates: https://coreos.com/docs/launching-containers/launching/launc... though you can certainly do this without fleet too. Then on the haprox…

This is what DNS is for. If you specify your backends by hostname instead of IP, then each time the load-balancer tries to connect to the backend, it'll get a list of A records from its DNS resolver and pick one in a round-robin fashion. Thus, if you have a dynamic DNS server that queries your presence service, it can return exactly the hosts that are up right now as the round-robin set.

Right now, if you use SkyDNS[1] as your DNS server, and attach Skydock to the Docker host, this all Just Works. Most people want to use etcd instead of Skydock, though, so support for that is coming soon[1] too.

[1] https://github.com/skynetservices/skydns

[2] https://groups.google.com/forum/#!topic/coreos-dev/iklEYHh5J...

Post reply on HN