Introduction to Fabric8

by Ioannis Canellos / @iocanel
and James Strachan / @jstrachan


What is Fabric8?


Fabric8 Concepts


So, What is Fabric8?

Integration Platform...

Fabric Diagram

A integration what?

- A platform that allows you...

  • Integrate all kind of applications.
  • Collaborate between different application across the network.
  • A common facade.

What does it do?

  • Allocate Resources, Install & Connect containers in your environment.
  • Publish Services, Discover & Coordinate.
  • Manage.
  • Provision.
  • Visualize.
  • Scale Up / Down
  • ...more

What kind of Containers?

  • Apache Karaf
  • Apache Tomcat (work in progress)
  • Wildfly (work in progress)

Where are the containers running?

  • In any public / private IAAS
  • Openshift
  • Docker
  • Your local network (bare metal)
  • Mix and match (hybrid)...

A little bit of History ...

  • Introduced in Fuse ESB as "Fuse Fabric".
  • Too "cool" to be just Fuse ESB / JBoss Fuse.
  • Wider focus on Runtimes.
  • Indepedant OSS project. ASL 2.0 Licensed.


Sounds cool, but I need that why?

"With great Power comes great Responsibility"

Voltaire Spiderman

"With great 'Buzz Words' comes great Responsibility"

-- Me


  • There is nothing wrong with "buzz words".
  • There buzz is generated by value.

Following the current trends

Chances are that you are already using...

  • Cloud
  • NOSQL Databases
  • Message Brokers
  • Rest APIs
  • Anything that qualifies as a "Service"...

Which of course you will eventually have to "configure"!

Are your services "Set to Stone"?

Peter Griffin as Moses

You could always hardcode everything...

... as long as you tell no one!

But when you build for ...

  • Cloud
  • Elasticity
  • Scalability
  • IP Address & Ports are rarely known in advance!

    So hardcoding is not just "smelly", its also not workable.

    What you need is Location Transparency.

Continous Delivery

The more VMs your application is using, the more challenging to...

  • Install your application
  • Push Bug Fixes, Improvements
  • Do all shorts of maintainance
  • Especially if you want to limit the "down time" as much as possible.

Speaking of "Down Time" ...

  • Failover Strategy
  • Load Balancing
  • Access shared resources

Bottome line: You need Coordination.

Summary: To stay "relevant"

you need...

  • Tools for allocating resources (e.g. VMs or LXC containers)
  • Tools for installing your apps to those resources.
  • Tools for discovering services.
  • Tools for coordinating services.
  • Tools to managing/monitoring those services.
  • Tools for glueing all these together.

Good news !!!

Plenty of tools

There are indeed lots of tools.

Infact, there are too many!

What's missing?

Plenty of tools

A unified tool...

Be awesome

You can use Fabric8.

Fabric8 Concepts

  • ZooKeeper for Registry and Coordination
  • Git for Configuration
  • Profiles for modeling configuration
  • Hawtio for managing

Runtime Registry

Apache ZooKeeper

Apache ZooKeeper

  • Sequential Consistency
  • Atomicity
  • Single System Image

Ideal for distributed system coordination...

Runtime Registry

How is it used?

  • As a registry of non configuration data.
  • Distributed Locks
  • Leader Election
  • Service Discovery

Runtime Registry

What does it contain?

  • Container Status
  • Container connection addresses
  • Container allocated resources
  • Container services (URLs, Endpoints)

So where do the "configuration data" live?


Git Logo


Why Git?

  • Versioning
  • Full audit history (who changed what and when)
  • Multiple Repositories Concept
  • Easy access through external clients
  • Works pretty well on unreliable networks
  • It's becoming a standard


Isn't the git repo becoming a single point of failure?

Git Failure

NO! Fabric8 provides you with an HA Git Repository!


Highly available Git

Fabric8 treats Git as any other HA service:

  • Uses Runtime Registry for Master election.
  • If the "current" master fails...
    • host goes down
    • jvm crashes
    • unable to serve http content
  • A new master will get elected.
  • All containers will switch to the "new" master.

How is configuration modled?

  • What layout I should use?
  • How is the configuration applied?


Configuration is not meant to be applied to all containers

Instead of configuring each container individually...

Identify logical groups of containers and create profiles for them.


What exactly is a profile?

"A collection of configuration resources that can be applied to the container"

  • Hierarchical
  • Reusable
  • Combinable
  • Versioned

Some examples of such resources:

  • property files
  • json files
  • XML files
    • ActiveMQ broker.xml configuration files
    • A camel routes
    • Anything !!!


What can I define in profiles?

  • What should be deployed to the container.
  • The configuration of your container.
    • Configuration Admin Support
    • Raw files that can be easily looked up (e.g. profile://config.xml).

Profiles, Containers & Git

How do I use all these?

  • A git branch corresponds to a version.
  • A version contains multiple profiles.
  • A container can be assinged a version and multiple profiles.
  • Each container:
    • Checkouts the assigned version
    • Reads the associated profiles
    • Applies configuration to itself
    • Provisions itself
    • Acts as a configuration repository
  • Easy way of performing rolling upgrades / downgrades.

Containers, Versions, Profiles, Applications

How do I manage all this?

Don't you wish you had a console, hawt like this?


Remember when we talked about a "common" facade?

Hawtio is a unified console for visualizing & managing everything.

Written on AngularJS!


Rich collection of plugins

  • Camel
  • ActiveMQ
  • OSGi / Karaf
  • Docker
  • ... lot more