On 02/04/2019 11:55 AM, Rich Freeman wrote:
IMO I would separate your container logic from your service manager logic.
I'm not exactly sure what you mean by "container logic" vs "service
manager logic" and how they differ. I'm assuming that the former
creates / destroys the container and that the latter manages
(re)starting/stopping services where ever they are at.
If you have a script that launches a container, then all you need is a
generic init.d script that runs it.
I guess that's one way to do it. But that doesn't seem very Gentoo<ish>
to me.
I'd like to see a way that I can have standard service init scripts and
use them where ever I want them, either inside a container or outside on
the host.
As long as I don't want to run the same service in multiple places, I
don't see a problem with doing that. Multiple instances starts to get
more tricky, but is still possible, and should be location agnostic.
I launch nspawn containers from systemd units all the time. The only
logic in the units is running the command line to start nspawn.
IMO if you start mixing the two it will just make it harder to maintain.
Sure, an init.d script CAN do anything, but that doesn't mean that you
should do it this way.
I'm wanting to avoid having an init script that creates the container
and starts services therein. I'd rather start the container and then
start the services therein using the same type of init scripts, just
called within different contexts.
Without creating a separate reply I wanted to react to your other email
detailing your config. It strikes me that you might not even need
containers to set up all those interfaces and the routing between them.
However, the container probably still makes sense so that random processes
trying to listen on 0.0.0.0 on the host don't end up attaching to all
those virtual interfaces.
Yes, I could have all the interfaces on the host. But I'm doing a
number of different things and don't want to spoil the host.
The nice containers that I mentioned are long standing containers. I
routinely stand up 10 ~ 100 more for various tests.
I'm also using network namespaces as an isolation so that I can easily
do various things with networking without the added complexity of
isolating things from each other via command line or policy based
routing. Each network namespace can easily have it's view of 0.0.0.0
(as a good example) and it's own routing table. I don't need to bother
with PBR / ip rules / iptables complexities. Each NetNS just knows
about it's local interfaces.
Really all you need is some initialization inside each container and
then the kernel is doing all the work. You don't really need any
userspace process running in the container except for the fact that
kernel namespaces are attached to processes.
I mostly agree. I am running BIRD inside the container, but that's more
of a would be nice to have and I can work around not having it. There
are also the occasional commands that I want to run to do
troubleshooting (ping, traceroute, etc) as well as dynamically modifying
the containers which is usually done via "nsenter …" or "ip netns exec
$NetNSname …" commands.
As a result, I'd suggest considering using sysvinit inside your
containers to do the work.
That is a possibility. But I feel like that's tantamount to saying
"Gentoo doesn't have an answer for what you're wanting to do, so just
use Sys V init scripts." I don't like it.
I like the idea of re-using standard OpenRC / NetifRC scripts inside the
containers too. Especially if the services don't conflict anywhere. To
me, this re-uses the existing Gentoo methodology in different contexts.
You might run openrc/netifrc to do the network setup inside each
container, or just have sysvinit run a shell script that initializes
and then terminates, leaving init running childless indefinitely (I
assume it supports this). If you want a process to noop indefinitely
at minimal cost that is basically the definition of what sysvinit does...
The more that I think about it, largely in response to emails in this
thread, I believe that I want the same overall thing to create the
network between the default / main / unnamed NetNS and the container, as
well as likely re-using the OpenRC / NetifRC scripts to configure things
inside the container.
I think, and would be curious to have someone confirm or refute, that I
could add configuration information to /etc/conf.d/net for the xyz123
interface inside the container and use an /etc/init.d/net.xyz123 init
script sym-linked to /etc/init.d/net.lo script.
My host would not have net.xyz123 in any runlevel. Certainly not boot
or default.
I think that would mean that I could run rc-service net.xyz123 start
inside the container and re-use existing Gentoo methodology.
Now I wonder if I could use custom runlevels for each container and rely
on standard init system. }:-) But that's a different question.
--
Grant. . . .
unix || die
