[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

BGP in a containers

Years back I ran ExaBGP inside a Docker container (when it wasn't
"production ready") to anycast a contained service both within a datacenter
and across them. To make routing work correctly I had to also run another
BGP daemon on the Docker host machine; I can't remember if I used bird for
this, but it seems like what I'd use since I didn't need programmatic
control of prefixes.

Would I do it that way today? Not a chance. How would I do it? That would
really depend on two things: what I'm trying to accomplish with BGP and
what the service is. If you just want portability of a service (not
redundancy/balancing via anycast) is BGP really the best option? I'd make a
strong case for OSPF due to it needing far less config. The same need for a
routing instance on the Docker host would apply, but you wouldn't need to
manage configuration for neighbors as containers come up and go down (since
the IP will likely change). Sure, you could just add neighbor config for
every IP Docker might use, however-- ouch.

Jeff Walter

On Mon, Jun 18, 2018 at 8:45 AM, Hugo Slabbert <hugo at slabnet.com> wrote:

> On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess <mysidia at gmail.com> wrote:
>> Running the BGP application in a container on a shared storage system
>> managed by
>> a host cluster would also make it easier to start the service up on a
>> different host when
>> the first host fails or requires maintenance.
>> On the other hand, running directly on a host,  suggests that
>> individual hosts need
>> to be backed up again,   and  some sort of manual restore of  local
>> files from the lost host
>> will be required to copy the non-containerized application to a new host.
> Even if the BGP speaker is running right on the host, the shared storage
> or backups thing doesn't click for me.  What about your BGP speaker will
> need persistent storage?  At least in our environment, everything unique
> about the BGP speaker is config injected at startup or can be derived at
> startup.  This might be based on differences in how we're using them (BGP
> daemon per container host in our case, rather than "I need X number of BGP
> speakers; schedule them somewhere"), I guess.
> --
> Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
> pgp key: B178313E   | also on Signal