[Mono-list] libmono-2-0.a in libmono-dev CentOS package?

Sat Feb 20 04:03:33 UTC 2016

Dave,

That’s actually a pretty good way to handle it! Unfortunately that wouldn’t work for us because we lose the flexibility to use different versions of mono for our micro container services (on the same host). This can turn into a problem when running 100+ services (containers) on one host and your developers want to update mono version on a few of them without having to retest all the other services.

Eugene

From: Dave Curylo [mailto:dacurylo at gmail.com] On Behalf Of David Curylo
Sent: Friday, February 19, 2016 5:00 PM
To: Eugene Kobrinsky <cue at integrate.com>
Cc: Timotheus Pokorra <timotheus.pokorra at solidcharity.com>; mono-list at lists.ximian.com
Subject: Re: [Mono-list] libmono-2-0.a in libmono-dev CentOS package?

I’m not sure if this is an option for you, but if you control the host for your containers, then supplying mono to your container via data volume works for me to keep the images small:

https://docs.docker.com/v1.8/userguide/dockervolumes/#adding-a-data-volume

To describe my setup a little more, I run Mesos, and each slave has a mono distribution in a directory that mounts to the location of the shared mono distribution.  I also have a directory that contains nuget packages on each slave which I also mount as a docker volume.

With this configuration the Docker image really bootstraps itself by
1. Adding the docker volume containing mono to the PATH
2. Set LD_LIBRARY_PATH
3. Add nuget source
4. Install packages that contain .dll’s and .exe’s
5. Start the application itself.

The images are relatively small, at least they don’t contain copies of mono or my fairly large application, but they are entirely ephermal, and I can update packages without a need to rebuild and maintain many the images.

Some or all of course, is optional - you could put all your code on the image just as well.

On Feb 19, 2016, at 11:45 AM, Eugene Kobrinsky <cue at integrate.com<mailto:cue at integrate.com>> wrote:

In regards to Docker layers, I'm not an expert myself. At least from my understanding, Docker does use caching for each layer when you build a container but in effect it is still a separate instance when you run the resulting container.  It still seems to use all the space of each layer for that particular running container. So running the same container 10 times will still take up 10x of the space.

We might just have to build our own packages... I was really hoping to avoid that.

Going to try IRC and the package manager list next.

Thanks for your responses Timotheus!

Eugene

-----Original Message-----
From: mono-list-bounces at lists.ximian.com<mailto:mono-list-bounces at lists.ximian.com> [mailto:mono-list-bounces at lists.ximian.com] On Behalf Of Timotheus Pokorra
Sent: Thursday, February 18, 2016 11:58 PM
To: mono-list at lists.ximian.com<mailto:mono-list at lists.ximian.com>
Subject: Re: [Mono-list] libmono-2-0.a in libmono-dev CentOS package?

Hello Eugene,

Good question. We are using Docker to run a microservices architecture for our app. As such, we are dealing with a lot of docker containers, each running a very small mono app (service).
Sounds interesting!

Right now we have a full blown CentOS instance and mono runtime in each container, which bloats the container size to 160mb+. Our goal is to run a small container with minimal OS (options: BusyBox or Alpine https://github.com/gliderlabs/docker-alpine) which would bring down our container size to 20mb-40mb.
I am not a docker expert, but I thought the layered system with AUFS avoids duplication of similar parts of containers? Or are the containers all running on different hosts?

Here is an example of a guy doing it, except he makes the static bundle on Debian http://www.onegeek.com.au/articles/a-nancy-net-microservice-running-on-docker-in-under-20mb.
I suggest you build your own CentOS packages: comment the rm lines, and add the libmono-2.0.a files and others in the %files section.

Is the mono package mailing list more appropriate for this question? It seems like an oversite given there is a tool (mkbundle) that uses those static libraries.
I think not much is happening on the package mailing list:
http://lists.ximian.com/pipermail/mono-packagers-list/
But it might be good to get a discussion going there again :)

Otherwise try the IRC: #mono on freenode

all the best,
 Timotheus
_______________________________________________
Mono-list maillist  -  Mono-list at lists.ximian.com<mailto:Mono-list at lists.ximian.com> http://lists.ximian.com/mailman/listinfo/mono-list
_______________________________________________
Mono-list maillist  -  Mono-list at lists.ximian.com<mailto:Mono-list at lists.ximian.com>
http://lists.ximian.com/mailman/listinfo/mono-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20160220/998fc91a/attachment.html>