Currently (prior to this PR), the calico/bird container image is used only as an intermediate step towards the production of a deliverable calico/node container image. Specifically, we use the calico/bird container image just as a way to wrap and publish the various BIRD binaries (on multiple architectures):
bird
bird6
birdcl
birdcl6
Then the calico/node build process pulls that image and copies the BIRD binaries out of it to the right place in the calico/node image.
Now - especially with the recent dual ToR work - we need something to model a router that is not a Calico node, and it's convenient to use BIRD for that too, as we're familiar with its config and operation. I have built a container image for that purpose from a different Dockerfile than calico/bird, and published it as "neiljerram/birdy", but:
I haven't yet finalised the coding and process for that image
I think it's confusing for our BIRD repo to generate two container images for different purposes
I think we can add the "birdy" testing role into the existing calico/bird image without jeopardising the current uses of the calico/bird image.
So, the last bullet is what this PR does. For simplicity, for amd64 only, because we only need to test on amd64.
BIRD binaries are copied into the image at the same location (/) as before.
Then, to make the image runnable and useful for testing:
Base is changed from scratch to alpine.
BIRD binaries are linked to standard locations in PATH.
Required runtime and config directories are created.
Basic config is added in.
Added a wrapper script that discovers the container's IPv4 and runs BIRD and BIRD6 with that IPv4 as router ID.
Currently (prior to this PR), the calico/bird container image is used only as an intermediate step towards the production of a deliverable calico/node container image. Specifically, we use the calico/bird container image just as a way to wrap and publish the various BIRD binaries (on multiple architectures):
Then the calico/node build process pulls that image and copies the BIRD binaries out of it to the right place in the calico/node image.
Now - especially with the recent dual ToR work - we need something to model a router that is not a Calico node, and it's convenient to use BIRD for that too, as we're familiar with its config and operation. I have built a container image for that purpose from a different Dockerfile than calico/bird, and published it as "neiljerram/birdy", but:
So, the last bullet is what this PR does. For simplicity, for amd64 only, because we only need to test on amd64.
/
) as before.I have tested successfully that: