Using Weave Scope to explore Microservices Communication and Service Mesh (OpenShift and Istio)

If you are working with ESB, Message Brokers, BPMS, SOA or Microservices, you will notice that you are solving the same problems of Standalone Applications but in different way, because all of them are different kind of Distributed Application. Those problems are:

  • Users Management, Authentication and Authorisation
  • Logging, Debugging, Monitoring and Alerting
  • Clustering, High Availability, Load Balancing, etc…

What is a Service Mesh?

It’s other type of Distributed Application where the Services, or Microservices or APIs, are being interconnected. api-mesh-security-2-weave-scope

Service Mesh on Containerised and Orchestrated Platform

Generally a Service Mesh, based on the Microservices and/or APIs, is deployed by using multiple containers hosted and orchestrated for Kubernetes. In this scenario, we need to face new challenges such as ephemeral infrastructure, zero trust network, network segmentation or adopting new methodologies to test, to monitor, to deploy, to operate, etc. That’s we are calling DevOps.

Deployment Container Patterns

Like to EIP (Enterprise Integration Patterns) and Software Design Patterns, the Deployment of Service Mesh in a Containerised Platform also has Patterns. Google, Microsoft, Netflix, etc. recommend to use some patterns to implement solutions for the problems stated above. For example, Google explains very well 3 patterns:

  • Sidecar Pattern
  • Ambassador Pattern
  • Adapter Pattern

All of them support the building of the Service Mesh based on Containers. For further details read this paper: Design patterns for container-based distributed systems. By Brendan Burns and David Oppenheimer

What is Istio?

Extracted from

Istio is an open platform that provides a uniform way to connect, manage, and secure microservices. Istio supports managing traffic flows between microservices, enforcing access policies, and aggregating telemetry data, all without requiring changes to the microservice code. Istio gives you:

  • Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic
  • Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.
  • A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.
  • Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.
  • Secure service-to-service authentication with strong identity assertions between services in a cluster.


Why use Istio?

Extracted from

Istio addresses many of the challenges faced by developers and operators as monolithic applications transition towards a distributed microservice architecture. The term service mesh is often used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring, and often more complex operational requirements such as A/B testing, canary releases, rate limiting, access control, and end-to-end authentication. Istio provides a complete solution to satisfy the diverse requirements of microservice applications by providing behavioral insights and operational control over the service mesh as a whole. It provides a number of key capabilities uniformly across a network of services:

  • Traffic Management. Control the flow of traffic and API calls between services, make calls more reliable, and make the network more robust in the face of adverse conditions.
  • Observability. Gain understanding of the dependencies between services and the nature and flow of traffic between them, providing the ability to quickly identify issues.
  • Policy Enforcement. Apply organizational policy to the interaction between services, ensure access policies are enforced and resources are fairly distributed among consumers. Policy changes are made by configuring the mesh, not by changing application code.
  • Service Identity and Security. Provide services in the mesh with a verifiable identity and provide the ability to protect service traffic as it flows over networks of varying degrees of trustability.

Get a container-based Service Mesh with Istio

I’ve created 3 Ansible Roles to get easily a minimalist OpenShift Cluster (by using Minishift), Weave Scope (, Istio and BookInfo Application (API and Microservices on containers) to understand what challenges we have to face. The 3 Ansible Role are:

  1. Minishift Ansible Role To get OpenShift Cluster in a VM by using Minishift
  2. Weave Scope Ansible Role To deploy Weave Scope Application in an OpenShift running locally
  3. Istio Ansible Role To deploy and configure Istio in OpenShift running locally, to deploy BookInfo Application and inject sidecar proxies(Envoy Proxy)

I have also created some examples so that you can have an environment where you can test and try quickly with all this. Weave Scope Application will play a important role here, because It will allow us to monitor, visualise, troubleshot and manage easily whole the container-based Service Mesh. Once completed the step-by-step guide, you will get next: ..and

Hope this helps!.

Tagged with: , , ,
Posted in DevOps, PaaS, Service Mesh

Apache NiFi and TLS Toolkit Ansible Roles to create a multi-node secure NiFi cluster

I’ve created 2 Ansible Roles (chilcano.apache-nifi and chilcano.apache-nifi-toolkit) to automate the creation of a multi-node and secure NiFi cluster. At the moment, the chilcano.apache-nifi Ansible Role doesn’t implement Cluster State coordination through Apache ZooKeeper. It will be implemented in the next version of this Ansible Role. Also I’ve implemented only TLS Toolkit Standalone mode in the chilcano.apache-nifi-toolkit Ansible Role.

Further details and samples about both Ansible Roles can be found at Ansible Galaxy:

Once presented both Ansible Roles, I’m going to explain how to automate the creation of several instances of Apache NiFi, secure and not secure.

See image below:
Automated provisioning Apache NiFi multi-node cluster with Ansible and Vagrant

We are going to create 5 NiFi instances, the first NiFi instance nf1 will be a standalone instance running over HTTP. The second instance will will be a customized instance running over HTTPS with Client Certificate authentication. The third, fourth and fifth instances will run over HTTPS with Client Certificate authentication with configuration provided for NiFi TLS Toolkit. This configuration, key-pair, Java key stores and certificates will be generated in other VM instance provided for chilcano.apache-nifi-toolkit Ansible Role. See the image below:

Apache NiFi Toolkit - folder structure and files generated

I’ve created an Ansible Playbook for you, you can download from this Git repository:

How to use it – steps

1. Clone the Ansible playbooks

$ git clone

2. Install chilcano.apache-nifiand chilcano.apache-nifi-toolkit Ansible Roles

$ cd ansible-apache-nifi-multi-nodes
$ ansible-galaxy install -r playbooks/requirements.yml

3. Create all VMs with Vagrant

Create all 6 VMs by using Vagrant.

$ cd infra/Vagrant
$ vagrant up

4. Ansible provisioning with Vagrant

Now, I’m going to provision (run Ansible Playbooks) through Vagrant. This step will install Apache NiFi TLS Toolkit in the nftk1 VM, once provisioned, Vagrant will provision 5 VMs following the Ansible Playbook playbooks/main.yml. It is very important to start the provision of all NiFi instances after provisioning nftk1. In the playbooks/main.yml you will see the nftk1 is declared on top and after nf1, nf2, nf3, nf4 and nf5.

$ vagrant provision

$ vagrant status
Current machine states:

nftk1                     running (virtualbox)
nf5                       running (virtualbox)
nf4                       running (virtualbox)
nf3                       running (virtualbox)
nf2                       running (virtualbox)
nf1                       running (virtualbox)

This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.

Now we can verify if all instances are running as expected, before we have to install the Client Certificate (CN=chilcano_OU=INTIX.p12) generated in our browser.
Install the Client Certificate

The Client Certificate only is required when connecting to nf2, nf3, nf4 and nf5 because these instances are running over HTTPS with Mutual SSL/TLS Authentication (based on Client Certificate).
Select the Client Certificate

Open the URL (http://nf1:8080/nifi, http://nf2:9443/nifi, http://nf3:9443/nifi, http://nf4:9443/nifi and http://nf5:9443/nifi) from Firefox. Instead of hostname you can use the IP address (see inventory file).
Open NiFi from Firefox


  1. Improve the Ansible Role chilcano.apache-nifi to implement Cluster Status coordination through Apache ZooKeeper.
  2. Improve the Ansible Role chilcano.apache-nifi-toolkit to implement Client/Server mode.
  3. Deploy a sample DataFlow in NiFi.


Tagged with: , , ,
Posted in Big Data, DevOps, Security

My 3 Ansible Roles to mass provision Kismet and Apache MiNiFi for wardriving at scale

This blog post is implementing the same scenario used in the previous post Mass provisioning of Kismet and Apache MiNiFi in Raspberry Pi using Ansible. The unique difference is this new blog post I’m using Ansible Roles instead of Ansible Playbooks where all automated operations as install, configure, run, etc. were implemented in Ansible Tasks.

Then, I’ve refactored all Ansible Tasks and I’ve created 3 Ansible Roles. They are in Ansible Galaxy and are:

Ansible Role Kismet RPi Build

An Ansible Role that builds / compiles from scratch and packs (Debian/Raspbian binary) Kismet on a Raspberry Pi. This Role provides the following features:

  • Download the Kismet source code.
  • Compile the source code in a Raspberry Pi.
  • Generate a Kismet Debian/Raspbian package suitable for Raspberry Pi (ARMv7).

Ansible Role Kismet RPi Wardriving

An Ansible Role that installs, configures and runs Kismet on a Raspberry Pi. This Role provides the following features:

  • Install Kismet and dependencies.
  • Configure Kismet by deploying an customized kismet.conf.
  • Download MAC Addresses Manufacturer List.
  • Enable monitor mode in the Raspberry Pi before starting Kismet.
  • Run Kismet as a systemd service.

Ansible Role Apache MiNiFi

An Ansible Role that installs, configures and runs Apache MiNiFi in tiny devices like a Raspberry Pi, although you can use it on any distro. This Role provides the following features:

  • Install Apache MiNiFi and Java SDK.
  • Configure Apache MiNiFi.
  • Run Apache MiNiFi as a systemd service.

How to use everything

Well, I’ve updated and deleted Ansible Tasks not used in the existing Ansible Raspberry Pi Wardriving Github repo because now I’m using 3 Ansible Roles. Just download the same Github repo with Tag 2.0.0 and execute the new Ansible Playbook with the same inventory file.

Install all Ansible Roles needed as below or using requirements.yml file:

$ sudo ansible-galaxy install geerlingguy.apache
$ sudo ansible-galaxy install chilcano.kismet-rpi-build
$ sudo ansible-galaxy install chilcano.kismet-rpi-wardriving
$ sudo ansible-galaxy install chilcano.apache-minifi

$ ansible-galaxy list

– chilcano.apache-minifi, 1.0.1
– chilcano.kismet-rpi-build, 1.0.4
– chilcano.kismet-rpi-wardriving, 1.1.1
– geerlingguy.apache, 2.0.1
– knopki.locale, a1232f836b5514c58da381d9479640e40d874906
– Stouts.hostname, 1.1.0
– Stouts.timezone, 2.2.0

…and continue with this:

$ git clone --branch 2.0.0 --single-branch

$ cd ansible-raspberrypi-wardriving

$ git tag -l

$ git checkout tags/2.0.0 -b 2.0.0

$ ansible-playbook -i inventory main_all.yml -k

And that’s it !.
I hope It helps.

Tagged with: , , ,
Posted in Big Data, DevOps, IoT, Security