Being devOps doesn’t suck anymore!

Brought to you by...

Why do devOps cry?

Because the gap between dev and ops is thaaaaaaaat huge.

What can make devOps happy?

Ansible/Chef/Puppet/Salt doesn’t solve all the issues.

What can make devOps happy?

Reducing the gap between dev and ops.

What is Fabric8 then?

The tool to make (JVM) devOps happy ;) .

But how?

● integrate early● fail fast● automate● monitor

Integration platform FTW!

Let your devs be the ops (in their sandbox).

Little background

Fabric origins

● Apache Camel● Apache ActiveMQ● Apache ServiceMix● Apache CXF

To put the s**t together.

Fabric-eight

● FuseSource acquired by Red Hat ● project renamed from fabric to fabric8● wider scope of the project

Fabric8 crash course #1

Start Fabric8 platform.

Fabric8 crash course #2

Log into shell or GUI.

Fabric8 crash course #3

Tell Fabric8 to deploy your app.

Fabric8 crash course #4

Repeat for the test/QA/production.

Do less. Be dev focused.

In the devOps world...

...failures happen.

Be ready for failures

Have monitoring. Stay cool.

Sharing is good

DevOps need to share.

Sharing is good

?...for service discovery.

Sharing is good

...for load-balancing.

Sharing is good

…for the microservices coordination.

Describing deployables

Fabric8 uses “profiles” for that.

Profile describes what to deploy

For example my-spring-boot-app profile has mvn:com.example/my-spring-boot-app/1.0 jar assigned to it.

Profiles can have parents

For example my-spring-boot-app profile has containers-java.spring.boot parent.

Deploy, but where?

Fabric8 deploys applications to the container.

Containers

● Tomcat● WildFly● plain JVM process● Karaf● OpenShift● Docker● ...

Fabric8 <3 Docker

Docker will be a recommended container for the Fabric8.

Unified provisioning

Use (almost) the same profiles for test/QA/production.

How can I distribute profiles?

Via Maven repos. Using Fabric8 Maven plugins.

Managing environment configuration

Fabric8 uses Git for that.

Version your system

● you can version your system in Git● rollback if necessary

Fabric8-awarness

Applications deployed by the Fabric8 can use API to become Fabric8-aware.

Fabric8-aware Camel routing

from("master:http://0.0.0.0:10000").

to("jms:prices");

from("http://0.0.0.0:10000").

to("fabric:brokers:jms:queue");

Fabric8-aware Spring apps

@Value("${service.url}")

String serviceUrl;

...

new RestTemplate().getForObject(serviceUrl);

Monitoring

Hawt.io and shell.

Choose your weapon - shell

something for | scripting > fans

Choose your weapon - hawt.io

Sexy!

Choose your weapon - hawt.io

Sexy!

Choose your weapon - hawt.io

Sexy!

Hawt.io is JMX friendly

Hawt.io plugins know how to handle JMX beans of popular libraries and servers.

Monitor by default

Hawt.io monitors all apps managed by Fabric8.

Monitoring with shell

host = (process:environment <PID> | grep SSH_ADDRESS | word 1 | tac)

ssh $host "grep -C 10 FindMe app/log.txt"

Sriptable diagnostic!

Monitor legacy

You can use Hawt.io to monitor your existing apps (JMX + Jolokia).

What’s next?

Better devOps (monitoring, Ansible?, etc).

What’s next?

More apps supported (vert.x!).

What’s next?

Deploy all the JBoss middleware (and more).

Many thanks!