On Tue, 24.02.15 11:00, Peter Paule ([email protected]) wrote: > Hi, > > while playing around with "systemd-nspawn" a lot in the last few days two > things > I'm really missing are links between containers like dkr supports > https://docs.docker.com/userguide/dockerlinks/ and getting an ip within the > container when running a single application like /usr/sbin/nginx and no > container-internal dhcp-server.
dhcp client you mean? In general, I am not really keen on doing IP configuration in nspawn. We have one solution for doing IP configuration already in systemd, and that's networkd, and it's a ton more powerful than anything we could add to nspawn. The general philosophy with nspawn I try to follow is that we invent as little new concepts and configuration as possible. Specifically, for network setup this means we use DHCP and all the other standard technologies but avoid inventing any addition IP configuration propagation protocol beyond that. networkd is by default shipped in a way now that it will do dhcp server stuff on the host for the network interfaces exposed by nspawn, and dhcp client stuff in the container for the interface it sees there. This stuff works now, and is really how I recommend what people use on the host and in the container if they use nspawn. (Note that networkd on the host only takes possession of these nspawn network interaces by default, hence it's completely safe to run this in parallel with NM or some other network configuration scheme, which is used for the other interfaces). I am quite interested to find ways to make all these things work without using too many container-specific technologies. More specifically this means I will always prefer a solution that could be made work for kvm containers the same way as for containers. Solutions involving env vars (like docker does it) are hence less than ideal since they do not translate nicely to VMs... > Are there plans to support something like that in future versions? Or are > there better options to do the same things? > > Example: > > systemd-nspawn -x -M db1 -D /var/lib/machines/centos-postgresql > /usr/bin/postgresql > systemd-nspawn -x -M web_app2 -D /var/lib/machines/centos-nginx > --link-with db1 /usr/sbin/nginx > > I know that that there are some new options introduced with systemd 219, but I > was not able to make it work for my use case. > > * --port > * --private-network > * --network-veth > > Did I understand it correctly, that I need to install systemd-networkd or some > other dhcp-daemon to get an ip address for now? Correct. You don#t really have to configure it as mentioned though. It will just work out of the box. > # The use case # > > Here's my use case. I would like to run everything in containers to better > separate web applications which use different software stacks - ruby, python, > native code etc. - security is important for me but not my main concern using > containers. > > [ Client ] --> [ Web Server 1 ] -+-> [ Web App 1 ] -+-> [ Database 1 ] > | | > +-> [ Web App 2 ] -+ > | > +-> [ Web Server 2 ] > > My idea is to run an nginx-webserver as reverse proxy in front of some web > application and other web servers. It should be responsible to route requests > to the web applications/server. So, my proposal to solve this would be like this: we could extend nspawn's --network-bridge= setting so that it would allow creating a bridge interface when the first container referencing it is created, and ref-counting it by the containers using it. Maybe via a new switch --network-bridge-make=foobar or so, where "foobar" is the name of this bridge to create. Then, for all containers that shall be linked one would specify the same --network-bridge-make= parameter, so that they are all added to the same bridge, and can thus communicate with each other. networkd would be configured out-of-the-box to do dhcp server magic on the host side for these kind of bridges, so that IP configuration works out of the box again, fully automatically, as long as the containers run networkd or some other DHCP client. With that in place you could easily create arbitrary groups of containers that can communicate with each other via IP. Now, the question is how they would find each other. For that I'd simply use LLMNR, and each container should just pick a descriptive host name, and that's it. LLMNR support is built into systemd-resolved. As long as each container runs resolved (or any other LLMNR implementation) it will be found by the other containers on the network, and it can find the other containers. The containers would simply reference each other by host names, the way the unix gods intended it. There would not be any further concept of passing configuration data about who talks to who in this. With this solution we have something that would work with containers the same way as KVM: the peers that shall operate together would join the bridge, and everything else is figured out via the dhcp and llmnr implementations. In fact, you could even put together crazy combinations here, where you run a Windows KVM together with a Linux container, and since both Windows and Linux (via resolved) speak DHCP and LLMNR they would be able to talk together. I hope this makes some sense... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
