World download URL makes assumptions on DNS and network connectivity

[sshipway]

When spawning the new minecraft container and passing the URL to download a previously uploaded world, the mccy assumes that the container can access the same URL as the user has for the web UI.

If the user is accessing http://localhost:8080 for example, or if the minecraft container cannot route or resolve the hostname in that URL (such as when your home network uses netbios broadcasts, or if the client access is proxied), the download fails.

Instead, the mccy should spawn the minecraft container using --link=$mccyid:mccy to link to itself, and generate a URL of the form http://linkname:8080/ instead; this would be guaranteed to work.

[itzg]

You can override that derivation by setting --mccy.external-uri; however, I'll follow through on your suggestion since it does seem more Docker'ish.

[sshipway]

I've tried using --mccy.external-uri=dockertest.auckland.ac.nz but it does not seem to work... will investigate.

[itzg]

Is there a way to get the current container's ID from within the container? With that it would be zero config to setup the link from mc server to mccy.

[sshipway]

http://stackoverflow.com/questions/20995351/docker-how-to-get-container-information-from-within-the-container

[itzg]

Thanks.

Notes

On a busybox container (container id is f93c2312944ac55be5fe104abd83a36c60281ec6b3d34e4e49ca3de7390bf157)

/ # cat /proc/self/cgroup 
11:hugetlb:/docker/f93c2312944ac55be5fe104abd83a36c60281ec6b3d34e4e49ca3de7390bf157
9:memory:/machine/instance-08354a7f-36b2-4d41-974a-08249f1aaabd.libvirt-lxc/docker/f93c2312944ac55be5fe104abd83a36c60281ec6b3d34e4e49ca3de7390bf157
8:perf_event:/machine/instance-08354a7f-36b2-4d41-974a-08249f1aaabd.libvirt-lxc/docker/f93c2312944ac55be5fe104abd83a36c60281ec6b3d34e4e49ca3de7390bf157
7:blkio:/machine/instance-08354a7f-36b2-4d41-974a-08249f1aaabd.libvirt-lxc/docker/f93c2312944ac55be5fe104abd83a36c60281ec6b3d34e4e49ca3de7390bf157
6:net_cls:/machine/instance-08354a7f-36b2-4d41-974a-08249f1aaabd.libvirt-lxc/docker/f93c2312944ac55be5fe104abd83a36c60281ec6b3d34e4e49ca3de7390bf157
5:freezer:/machine/instance-08354a7f-36b2-4d41-974a-08249f1aaabd.libvirt-lxc/docker/f93c2312944ac55be5fe104abd83a36c60281ec6b3d34e4e49ca3de7390bf157
4:devices:/machine/instance-08354a7f-36b2-4d41-974a-08249f1aaabd.libvirt-lxc/docker/f93c2312944ac55be5fe104abd83a36c60281ec6b3d34e4e49ca3de7390bf157
3:cpuacct:/machine/instance-08354a7f-36b2-4d41-974a-08249f1aaabd.libvirt-lxc/docker/f93c2312944ac55be5fe104abd83a36c60281ec6b3d34e4e49ca3de7390bf157
2:cpu:/machine/instance-08354a7f-36b2-4d41-974a-08249f1aaabd.libvirt-lxc/docker/f93c2312944ac55be5fe104abd83a36c60281ec6b3d34e4e49ca3de7390bf157
1:cpuset:/machine/instance-08354a7f-36b2-4d41-974a-08249f1aaabd.libvirt-lxc/docker/f93c2312944ac55be5fe104abd83a36c60281ec6b3d34e4e49ca3de7390bf157

[sshipway]

The content depends on the underlying OS of the docker host, not the container base, I think.

On a CoreOS-based docker host it is different. Also, the hostname is set to be the first few bytes of the container ID (2ecbc3381bcb74c3f32f3c04262c642f7ed62f82e6911877026aa8c5e91f34fc)

root@2ecbc3381bcb:/portus# cat /proc/self/cgroup
9:perf_event:/
8:devices:/system.slice/docker-2ecbc3381bcb74c3f32f3c04262c642f7ed62f82e6911877026aa8c5e91f34fc.scope
7:memory:/system.slice/docker-2ecbc3381bcb74c3f32f3c04262c642f7ed62f82e6911877026aa8c5e91f34fc.scope
6:cpuset:/system.slice/docker-2ecbc3381bcb74c3f32f3c04262c642f7ed62f82e6911877026aa8c5e91f34fc.scope
5:cpu,cpuacct:/system.slice/docker-2ecbc3381bcb74c3f32f3c04262c642f7ed62f82e6911877026aa8c5e91f34fc.scope
4:freezer:/system.slice/docker-2ecbc3381bcb74c3f32f3c04262c642f7ed62f82e6911877026aa8c5e91f34fc.scope
3:blkio:/system.slice/docker-2ecbc3381bcb74c3f32f3c04262c642f7ed62f82e6911877026aa8c5e91f34fc.scope
2:net_cls,net_prio:/system.slice/docker-2ecbc3381bcb74c3f32f3c04262c642f7ed62f82e6911877026aa8c5e91f34fc.scope
1:name=systemd:/system.slice/docker.service

[itzg]

Ah that's why people had a few different grep/sed approaches in the answers and comments.

This whole time I didn't know the hostname matched the same 12-digit prefix shown in the docker ps listing.

[sshipway]

I think that this is a good regexp to match --

egrep -e cpuset /proc/self/cgroup | sed -r 's/^.*([a-f0-9]{64}).*$/\1/'

[itzg]

Cool, I'll go with that. The hostname is easy, but there's a slight risk of ambiguous value with only 12 digits.

[sshipway]

TBH, I would say that the hostname is unique enough -- 12 hex digits gives so many possibilities that you'd be waiting until the end of the universe to get a duplicate...

[itzg]

@sshipway , can you test this out on the issue-41 branch?

[sshipway]

Will try it out, and let you know...

[sshipway]

Problems -- the container (again) refuses to build under docker 1.7.1. To get a later docker I need to upgrade Linux to RHEL7...

[itzg]

Turns out I went ahead and merged to master so that I observe the behavior on a two node cluster. So the hub image should now contain this resolution. On Thu, Jan 14, 2016 at 7:48 PM Steve Shipway notifications@github.com wrote:

Problems -- the container (again) refuses to build under docker 1.7.1. To get a later docker I need to upgrade Linux to RHEL7...

— Reply to this email directly or view it on GitHub https://github.com/itzg/minecraft-container-yard/issues/41#issuecomment-171842947 .

[itzg]

FYI @sshipway , I ended up leaving this setting, mccy.using-link-for-content, defaulted to false since I end up with two different scenarios on inter and intra Swarm cluster deployments where a container link cannot be used.

[danpolanco]

Can we remove the branch from github?

[itzg]

It's removed. I also removed develop while I was at it.

[danpolanco]

Yay! K.