The migration from monolithic applications to container-based microservice architectures does require fundamental changes in the basic concepts upon which applications used to be developed. No more massive, resource intensive web applications with long release cycles and terrible flexibility! No more ugly all-in one applications, all features locked in from the same vendor!

Microservice frameworks based on containers allow instead a more flexible way of dealing with:

• Many different lightweight microservices, each one doing only one thing.
• Easy adoption of the CI/CD mantra to speed up release cycle and bug fixes.
• Per-service load balancing and scalability of the single microservices (especially in a cloud context).
• Vendor and platform/language flexibility at a container level.
• The cultural shift in development teams and operations, namely DevOps

With the adoption of microservices come downsides as well, however. One of them is the increased necessity of having properly secured connections between the APIs: without careful consideration, some APIs might end up exposed to any other networks and containers, which might have been already compromised.

Often aided by orchestration frameworks, the lightweight approach to solving this problem lies with defining disjointed virtual networks and establishing security rules between them. Other approaches such as Istio's are more heavyweight and also require provisioning sidecars to Kubernetes pods in order to monitor and control the services they manage. The target of the Ansible playbooks, however, is for a small installation with low available resources.

Cilium, instead, uses a fairly different approach: it puts every container in the same network, only allowing specific containers (or container classes) to other containers (or classes). It can perform monitoring and policy enforcement because it build the networking driver that the containers must use.

Based on BPF and its capabilities, the cilium network plugin for Docker can perform L3 and L7 filtering (by using reverse proxies to filter specific calls). This way, not only the IP-level source of an API call must be correct: even the API calls performed must match the expected behaviour, and as an example contain the right headers.

The ansible playbook

This project contains the Ansible playbooks required to (re)install Cilium on top a Docker CE installation on a remote host with Ubuntu Server. As an addition, the playbooks also show how to create the required docker networks for cilium to work, and pulls the correct docker images to recreate the Cilium's own getting started guide for docker container networking.

• 10_ansible_setup.yml: sets up the remote side with the required python packages, without which the next playbooks wouldn't work - required as a separate playbook for this reason.
• 20_container_setup.yml: sets up Docker and Cilium, waiting for them to come up and be ready.
• 30_applications.yml: shows the creation of a Cilium network through ansible, and how to provision containers in that network. It then goes on to apply cilium policies and tests the communication between microservices.

Download

This library is released under the terms of the GPLv3 or any later version. See the details.