Managing hot-pluggable AWS ENI / secondary IPv4, IPv6?
tomalok opened this issue · comments
The current Alpine EC2 AMIs currently has an awful hack to support hot pluggable ENI interfaces and secondary IPv4 and IPv6 addresses on them.
A /lib/mdev/eth-eni-hotplug script is triggered when eth interfaces are added/removed, and runs an assemble-interfaces script rewriting /etc/network/interfaces -- added eths are ifup'd; removed eths have their entries in /run/ifstate and related ip rules cleaned up. The assemble-interfaces script is run via init script when the instance boots up.
There's also a eth-eni-hook script that is called when udhcpc "post-bound" and "post-renew" events occur. This script queries the IMDS service at 169.254.169.254, finds the secondary IPv4 or IPv6 addresses attached to the ENI and adds/removes them (and any necessary route/rules).
It works, but there's got to be a better, less-hacky, way to do this.
I'm hoping that an ifupdown-ng executor-script could lend some sanity/standardization to things.
To that end, I'm looking for advice/framework for how to proceed -- how would a workable solution look?
Seems to me the best way to solve this would be to have some way to dynamically generate configuration stanzas, with some sort of pre-flight hook. What do you think @tomalok?
I've implemented this as an ifupdown-ng executor in Tiny Cloud (the successor to tiny-ec2-bootstrap) which also incorporates the ENI interface hotplugging from the old alpine-ec2-ami (now replaced by alpine-cloud-images).
Tiny Cloud adds /usr/libexec/ifupdown-ng/imds, which runs /sbin/imds-net-sync at "post-up" -- so far it's working pretty well. The only thing that it doesn't currently do is resync every so often, but at least it's not tied to a specific DHCP client hook any more.