Thanks - I'll give that a whirl. MESOS-4507 sounds like mesos are starting to use Alpine in their test suites, so hopefully the glibc/musl incompatibilities will start to get ironed out.
My (very basic) Spark testing has hit issues with big images (Spark load images on demand, but anything too large triggers timeouts, so Alpines sizes are pretty appealing). In my experience, dockers caching isn't as effective as it's made out to be so I'm all for a smaller image. Spark is the first framework I've used that needs a libmesos in the container image, I'm still not clear why. On 17 April 2016 at 03:17, Sargun Dhillon <[email protected]> wrote: > A word of warning about musl. Alpine ships with musl as its default > libc implementation. Its DNS resolver tends to act very differently > than glibc. This can prove problematic in certain types of > applications where you may be interacting with slow DNS resolvers, or > relying on glibc's behaviour. > > Fortunately, Alpine actually supports glibc, and there are examples of > using it in a Docker container: > https://hub.docker.com/r/frolvlad/alpine-glibc/~/dockerfile/ -- the > image clocks in at about 12MB. > > On Sat, Apr 16, 2016 at 6:52 PM, Shuai Lin <[email protected]> wrote: >> Take a look at >> http://stackoverflow.com/questions/35614923/errors-compiling-mesos-on-alpine-linux >> , this guy has successfully patched an older version of the mesos to build >> on alpine linux. >> >> On Sun, Apr 17, 2016 at 3:19 AM, Dick Davies <[email protected]> wrote: >>> >>> Has anyone been able to build libmesos (0.28.x ideally) on Alpine Linux >>> yet? >>> >>> I'm trying to get a smaller spark docker image and though that was >>> straightforward, the docs say I need libmesos in the image to be able >>> to use it (which I find a bit suprising, but it seems to be correct). >> >>
