| 1 |
* Ed W <lists@××××××××××.com> schrieb: |
| 2 |
|
| 3 |
> I maintain a, likely much smaller, number of VMs using linux vservers. |
| 4 |
> The approach here is to almost cut each machine down to a chroot that |
| 5 |
> runs only one (or thereabouts) interesting service. |
| 6 |
|
| 7 |
I'm working in a similar way: my dedicated boxes are VM hosts |
| 8 |
(currently ovz, but later lguest or lxc), each of them running |
| 9 |
only specific services (eg. one for nginx-based front proxy, |
| 10 |
several other for backend webservers, RDBMs'es, mailservers, etc). |
| 11 |
|
| 12 |
But, for me, even a trimmed-down Gentoo is still too large |
| 13 |
(has to contain the whole base packages, from portage to |
| 14 |
toolchain, includes, etc). I'd prefer having only the essential |
| 15 |
runtime stuff within the containers. |
| 16 |
|
| 17 |
For this we need a different approach (strictly separating build |
| 18 |
and production environments). Binary distros (eg. Debian) might |
| 19 |
be one option, but they're lacking the configurability and mostly |
| 20 |
are still too large. So I'm going a different route using my own |
| 21 |
buildsystem - called Briegel - which originally was designed for |
| 22 |
embedded/small-device targets. |
| 23 |
|
| 24 |
For now I didn't have the spare time to port all the packages |
| 25 |
required for complete server systems (most of it is making |
| 26 |
them all cleanly crosscompile'able, as this is a fundamental |
| 27 |
concept of Briegel). But maybe you'd like to join in and try it :) |
| 28 |
|
| 29 |
> Using something like git would probably be perfect |
| 30 |
|
| 31 |
I'm using git'ed portage trees in production for several month now |
| 32 |
(I sometimes had to touch some eclasses, which _IMHO_ doesn't via |
| 33 |
overlays). The repos are configured to rebase on pull and everything |
| 34 |
runs automatically :) |
| 35 |
|
| 36 |
> The still missing step is configuration management across the machine |
| 37 |
> types, eg I want to upgrade all my "Apache-WWW" class machines and merge |
| 38 |
> in all changes in /etc in a certain way... At the moment I just run |
| 39 |
> dispatch-conf across all machines, but it can be quite boring merging 20 |
| 40 |
> instances of sshd.conf... Seems like Puppet/Chef could be a solution |
| 41 |
> here, but the step up and investment to make it work seems pretty large? |
| 42 |
|
| 43 |
I haven't used puppet yet, but several collegues have made good |
| 44 |
experiences with it. If you're maintaining dozens of very similar |
| 45 |
systems (mine tend to be very different from each other), it likely |
| 46 |
worth investigating. |
| 47 |
|
| 48 |
> It does appear like managing large numbers of virtual machines is one |
| 49 |
> are that gentoo could score very well? Interested to see any chatter on |
| 50 |
> how others solve this problem, or any general advocacy? Probably we |
| 51 |
> should start a new thread though... |
| 52 |
|
| 53 |
I'm not sure if Gentoo really is the right distro for that purpose, |
| 54 |
as it's targeted to very different systems (i.g. Gentoo boxes are |
| 55 |
expected to be quite unique, beginning with different per-package |
| 56 |
useflags, even down to cflags, etc). But it might still be a good |
| 57 |
basis for building specific system images (let's call them stage5 ;-)) |
| 58 |
|
| 59 |
An setup for 100 equal webserver vm's could look like this: |
| 60 |
|
| 61 |
* run a normal Gentoo vm (tailored for the webserver appliance), |
| 62 |
where do you do regular updates (emerge, revdep-rebuild, etc, etc) |
| 63 |
* from time to time take a snapshot, strip off the buildtime-only |
| 64 |
stuff (hmm, could turn out to be a bit tricky ;-o) |
| 65 |
* this stripped snapshot now goes into testing vm's |
| 66 |
* when approved, the individual production vm's are switched over |
| 67 |
to the new image (maybe using some mount magic, unionfs, etc) |
| 68 |
|
| 69 |
|
| 70 |
At this point I've got a question for to the other folks here: |
| 71 |
|
| 72 |
emerge has an --root option which allows to (un)merge in a separate |
| 73 |
system image. So it should be possible to unmerge a lot of system |
| 74 |
packages which are just required for updating/building (even |
| 75 |
portage itself), but this still will be manual - what about |
| 76 |
dependency handling ? |
| 77 |
|
| 78 |
Is there some way to drop at least parts of the standard system set, |
| 79 |
so eg. portage, python, gcc, etc, etc get unmerged by --depclean |
| 80 |
if nobody else (in world set) doesn't explicitly require them ? |
| 81 |
|
| 82 |
|
| 83 |
cu |
| 84 |
-- |
| 85 |
---------------------------------------------------------------------- |
| 86 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
| 87 |
|
| 88 |
phone: +49 36207 519931 email: weigelt@×××××.de |
| 89 |
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 |
| 90 |
---------------------------------------------------------------------- |
| 91 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
| 92 |
---------------------------------------------------------------------- |
Archives