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:dacur...@gmail.com] On Behalf Of David Curylo Sent: Friday, February 19, 2016 5:00 PM To: Eugene Kobrinsky <c...@integrate.com> Cc: Timotheus Pokorra <timotheus.poko...@solidcharity.com>; mono-list@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 <c...@integrate.com<mailto:c...@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-boun...@lists.ximian.com<mailto:mono-list-boun...@lists.ximian.com> [mailto:mono-list-boun...@lists.ximian.com] On Behalf Of Timotheus Pokorra Sent: Thursday, February 18, 2016 11:58 PM To: mono-list@lists.ximian.com<mailto:mono-list@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@lists.ximian.com<mailto:Mono-list@lists.ximian.com> http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com<mailto:Mono-list@lists.ximian.com> http://lists.ximian.com/mailman/listinfo/mono-list
_______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
