Stops resolving running containers after skydock: EOF under heavy system loads about skydock HOT 8 CLOSED

I attempted to address this in #58

from skydock.

Just noticed the 'no-expire' branch and notes at skynetservices/skydns#84 which should just get rid of the whole issue of tweaking timers and error counters. As long as skydock is always running and catches all the notifications from the docker API then skydns should stay in sync.

from skydock.

Yes, skydns is also in the middle of a rewrite to use etcd as the backend so it should be more robust and I will not add any TTL with skydock so that should solve your issue. I just don't know if I should ship skydns, skydock, and etcd in 1 or 3 containers.

from skydock.

Thanks for the update. Multi-host will be exciting!

One idea would be to use a single image with all three binaries in it. Then you would instantiate three containers using different names and command line arguments for each entry point.

Pros for this would be:

1. Logs kept separate and not interwoven
2. No need for an inside container process manager watching and restarting on failures.
3. The three binaries' versions could be tested together before vendored out in one package.
4. Possible to use an existing general purpose etcd server possibly already running on the host.

Cons:

1. You still have to start up and monitor 3 separate containers
2. Potential difficulty linking up the first three containers before discovery services exist.

Kind of like how one jar/tar.gz vendors logstash, elasticsearch, and kibana functionality?

Just some thoughts.

from skydock.

I was tinkering around with how to do deployment like these, one idea
(based on shipyard) is to how a setup container that he install all the
seperate containers you need. - this would also remove any difficulty in
linking the initial containers.

You could take that idea one step further by generalizing with a webbased
ui for the configuration (eg an MSI for docker).

For the logs would it be possible to extend the concept to use a fourth
container mounted drive to hold all the logs of all the containers so that
one might use something like logstash-forwarder to go through the logs
https://denibertovic.com/post/docker-and-logstash-smarter-log-management-for-your-containers/
?

For the starting up/monitoring between shipyard, project atomic and perhaps
Flynn there are more and more options out there.

On Tuesday, May 6, 2014, ubergarm [email protected] wrote:

Thanks for the update. Multi-host will be exciting!

One idea would be to use a single image with all three binaries in it.
Then you would instantiate three containers using different names and
command line arguments for each entry point.

Pros for this would be:

1. Logs kept separate and not interwoven
2. No need for an inside container process manager watching and restarting
   on failures.
3. The three binaries' versions could be tested together before vendored
   out in one package.
4. Possible to use an existing general purpose etcd server possibly
   already running on the host.

Cons:

1. You still have to start up and monitor 3 separate containers
2. Potential difficulty linking up the first three containers before
   discovery services exist.

Just some thoughts.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-42333387
.

from skydock.

I would prefer separate images, so you can use the images of skydns(2) and skydock in combination with CoreOS.

from skydock.

+1 for separate images.

from skydock.

Regardless of the images consideration, the solution to this original issue was taken care of in the skydock no-expire branch. I built a single image to vendor a solution which takes the form of two running containers (using whatever method you want to start them) here:

https://index.docker.io/u/ubergarm/skyservices/

Hopefully this is agnostic enough to be useful in general, but it works for me and my runit based production system.

I look forward to seeing the new skydns2 and skydock stuff when it is ready!
Thanks!

from skydock.