Declarative containers: more veth interfaces#15496
Merged
fpletz merged 2 commits intoNixOS:masterfrom Jul 31, 2016
Merged
Conversation
kampfschlaefer
referenced
this pull request
May 26, 2016
Without the templating (which is still present for imperative containers), it will be possible to set individual dependencies. Like depending on the network only if the hostbridge or hardware interfaces are used. Ported from #3021
Contributor
Author
|
I would rebase this PR to the current master (and have done so locally) with its updated systemd, but current master has broken containers… |
c980022 to
a0102ef
Compare
Contributor
There was a problem hiding this comment.
if condition then "foo" else "" is more neatly expressed as optionalString condition "foo".
Contributor
|
@fpletz anything we can do to help move this along? |
de225fa to
723eb97
Compare
With these changes, a container can have more then one veth-pair. This allows for example to have LAN and DMZ as bridges on the host and add dedicated containers for proxies, ipv4-firewall and ipv6-firewall. Or to have a bridge for normal WAN, one bridge for administration and one bridge for customer-internal communication. So that web-server containers can be reached from outside per http, from the management via ssh and can talk to their database via the customer network. The scripts to set up the containers are now rendered several times instead of just one template. The scripts now contain per-container code to configure the extra veth interfaces. The default template without support for extra-veths is still rendered for the imperative containers. Also a test is there to see if extra veths can be placed into host-bridges or can be reached via routing.
Seems like the right thing to do.
723eb97 to
07de11f
Compare
Contributor
Author
|
@fpletz ping? Would be nice to get that into master before 16.09 is branched off… |
Member
|
Sorry for the long wait. I just had another look, let's merge this! 👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With these changes, a container can have more then one veth-pair. This allows for example to have LAN and DMZ as bridges on the host and add dedicated containers for proxies, ipv4-firewall and ipv6-firewall. Or to have a bridge for normal WAN, one bridge for administration and one bridge for customer-internal communication. So that web-server containers can be reached from outside per http, from the management via ssh and can talk to their database via the customer network.
The scripts to set up the containers are now rendered several times instead of just one template. The scripts now contain per-container code to configure the extra veth interfaces. The default template without support for extra-veths is still rendered for the imperative containers.
Also a test is there to see if extra veths can be placed into host-bridges or can be reached via routing.
cc @edolstra @fpletz
Things done