[ixpmanager] Docker and IXP Manager

[Barry O'Donovan]

Marco d'Itri wrote:
>> Especially for emulating switches, route servers, graphing and tools
>> such as Bird's Eye. Docker is ideally suited to solving these issues as
>> well as providing the perfect environment for IXP Manager workshops.

> I started moving the not tightly coupled pieces to containers, so maybe 
> somebody will find design this useful.

That's pretty much the design of the Docker containers we have created.

Also, IXP Manager has been designed to be as not-tightly-coupled as is
reasonably possible (for an extremely limited amount of resources).

A real example I often give is how INEX runs it. We have four bare-metal
servers (BM1-4) on which we run virtual machines (VM). Also two other
bare metal servers for INEX Cork in another city (BM5,BM6).

These are all listed below with references to IXP Manager configured parts.

BM1-VM1: IXP Manager (Ubuntu 16.04 LTS)
BM1-VM2: MySQL on FreeBSD
BM1-VM3: mrtg collection and storage, Nagios, Smokeping (FreeBSD, LAN1,
LAN2) [1], [8], [9]
BM1-VM4: route collector (Ubuntu/Bird, LAN1, LAN2) [2]
BM2-VM5: sflow collector and peer to peer graph rrd storage (FreeBSD) [3]
BM2-VM6: AS112 service (LAN1, LAN2) (Ubuntu/Bird, LAN1, LAN2) [4]
BM2-VM7: SaltStack / Napalm switch config automation (FreeBSD) [5]
BM2-VM8: mail server with mailman (FreeBSD) [6]
BM1-VM9: DNS [7]
BM2-VM10: Quarantine route collector (Ubuntu/Bird, LAN1, LAN2) [2]

BM3-VM11: route server #1 (Ubuntu/Bird, LAN1, LAN2) [10]
BM4-VM12: route server #2 (Ubuntu/Bird, LAN1, LAN2) [10]

BM5-VM13: mrtg collection and storage, Nagios, Smokeping (FreeBSD, Cork)
[1], [8], [9]
BM5-VM14: route collector (Ubuntu/Bird, Cork) [2]
BM5-VM15: AS112 service (Cork) (Ubuntu/Bird, LAN1, LAN2) [4]
BM6-VM16: Quarantine route collector (Ubuntu/Bird, Cork) [2]

BM5-VM17: route server #1 (Ubuntu/Bird, Cork) [10]
BM6-VM18: route server #2 (Ubuntu/Bird, Cork) [10]

All config via HTTPS APIs.

We're at a point that our SaltStack server management can pretty much
treat VMs like containers. We've just been hesitant to move to
containers to date. This hesitancy is a mix of reasons included: in
house skills, stability, proven track record, "don't fix what's not
broken", time, etc.

See references below.

> mrtg.service is just a plain MRTG service unit, running in a dedicated 
> container:

<snip>

> The trick is that /var/lib/mrtg/ is shared between the two containers:

This is the same as the Docker system we built:

https://github.com/inex/ixp-manager-docker/blob/master/docker-compose.yml#L37


> I will apply the same principle to RS.

See: https://github.com/inex/ixp-manager-docker/tree/master/containers/rs1


 - Barry

[1] http://docs.ixpmanager.org/features/grapher/#backend-mrtg
[2] http://docs.ixpmanager.org/features/route-collectors/
[3] http://docs.ixpmanager.org/features/grapher/#backend-sflow
[4] http://docs.ixpmanager.org/features/as112/
[5] https://www.ixpmanager.org/presentations.php
[6] http://docs.ixpmanager.org/features/mailing-lists/
[7] http://docs.ixpmanager.org/features/dns-arpa/
[8] http://docs.ixpmanager.org/features/nagios/
[9] http://docs.ixpmanager.org/features/smokeping/
[10] http://docs.ixpmanager.org/features/route-servers/