libmesos on alpine linux?

[Dick Davies <di...@hellooperator.net>]

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).

Re: libmesos on alpine linux?

[Dick Davies <di...@hellooperator.net>]

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 <sa...@sargun.me> 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 <li...@gmail.com> 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 <di...@hellooperator.net> 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).
>>
>>

Re: libmesos on alpine linux?

[Sargun Dhillon <sa...@sargun.me>]

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 <li...@gmail.com> 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 <di...@hellooperator.net> 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).
>
>

Re: libmesos on alpine linux?

[Shuai Lin <li...@gmail.com>]

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 <di...@hellooperator.net> 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).
>