| 1 |
On Tuesday 14 June 2016 06:46:32 J. Roeleveld wrote: |
| 2 |
>On Monday, June 13, 2016 02:10:27 PM James wrote: |
| 3 |
>> wabe <wabenbau <at> gmail.com> writes: |
| 4 |
>> Still, if you manage 1000 linux workstations, then systemd does have |
| 5 |
>> it's merits. |
| 6 |
> |
| 7 |
>Serious question: What makes systemd more suitable to manage 1000 linux |
| 8 |
>workstations when compared to, for instance, OpenRC? |
| 9 |
> |
| 10 |
>-- |
| 11 |
>Joost |
| 12 |
|
| 13 |
Well, since nobody else gave a proper response yet... |
| 14 |
|
| 15 |
Not being somebody who manages lots of containers like that, I'm not aware of *all* |
| 16 |
of the relevant features and how they interact, but one that I can think of is that |
| 17 |
systemd can communicate with systemd instances running in containers started with |
| 18 |
systemd-nspawn (e.g., "machinectl status <name>" gives you the status of systemd |
| 19 |
+ services in a container). In fact, systemd-nspawn could probably be seen as such a |
| 20 |
feature in itself (though personally, when I do use it, it's mainly as chroot on steroids). |
| 21 |
Oh, and its cgroups management probably helps, that is, I *think* that you can limit |
| 22 |
resource consumption of containers that way, just like with service units (though I'm |
| 23 |
not 100% sure of that). |
| 24 |
|
| 25 |
In general, my understanding is that systemd provides base features that container |
| 26 |
management software utilises, and not so much that systemd by itself does container |
| 27 |
management. |
| 28 |
|
| 29 |
Perhaps somebody with more systemd expertise will now feel compelled to respond ;-) |
| 30 |
. |
| 31 |
|
| 32 |
HTH |
| 33 |
-- |
| 34 |
Marc Joliet |
| 35 |
-- |
| 36 |
"People who think they know everything really annoy those of us who know we |
| 37 |
don't" - Bjarne Stroustrup |
Archives