Friday, October 17, 2014

Six major changes in the Fabric8 V2


As some of you may know from my tweets, the Fabric8 team started to work on the v2 branch of the project. You may also already know that this version of Fabric8 will bring some major architectural changes. All of those are for better in my humble opinion, even if you may find them a bit aggressive ;) .

Change #1: Docker and Kubernetes will be required to run Fabric8

Yes. Containers are the big thing. They will change the way we deploy and manage our software. The new version of Fabric8 fully embraces the containerization trend. It means that Fabric8 is designed to work on top of Kubernetes and Docker. Fabric8 will work in any environment providing the Kubernetes platform such as RHEL Atomic, OpenShift, Google Compute Engine, Azure and so forth.

For platforms not supporting Docker, there will be a Kubernetes emulator layer. But come on, don't resist the changes in the industry - just invest into the Docker and Kubernetes. If Microsoft did it, you can do it as well :) .

Change #2: No ZooKeeper runtime registry

There will be no ZooKeeper ensemble in the Fabric8 anymore. Fabric8 1.x used ZooKeeper to share the runtime information between applications and to discover services. Kubernetes comes with the etcd internally which serves much of the same purpose and has support for the services binding, so Fabric8 v2 doesn't need ZooKeeper registry anymore for general purpose provisioning of containers and services.

However certain services will still require master slave election and partitioning functionality (such as running clusters of ActiveMQ); where either etcd or Apache ZooKeeper is required. If a Kubernetes environment allows it, then Fabric8 could reuse the underlying etcd cluster; otherwise an etcd or ZooKeeper clusters is required for things like ActiveMQ clustering.

Change #3: No profiles to configure application deployment

There will be no profiles in Fabric8 anymore. Starting from v2 Fabric8 uses app JSON files (i.e. Kubernetes extension proposed by OpenShift 3) to configure deployment of the managed application. More detailed configuration (like properties or YAML files) can be added to the file system of the deployed application's Docker image.

Change #4: Git repository isn't mandatory

Applications' configuration isn't stored in Git repository as it used to be in Fabric8 v1. As Fabric8 v2 doesn't use profiles (but app templates instead), the Git repository is not needed anymore. You can just store application's configuration (app file) in the Maven project and use the Fabric8 Maven plugin to start the application in the Kubernetes without keeping the configuration in any central repository (like Git).

However keeping app files in Git for easier configuration management can be useful. That's why Hawt.io provides this functionality for you. You can push your configuration to the Hawt.io Git repository via fabric8:deploy Maven goal. Fabric8 uses App Zip packaging format to distribute the configuration between the various environments.

Change #5: There is not Fabric8 "server" anymore

Starting from Fabric8 v2 Kubernetes is responsible for providing the runtime registry for the managed applications. It means that you don't have to start any dedicated Fabric8 deamon. Tools like Fabric8 Maven plugin or Hawt.io can connect directly to the Kubernetes and deploy into it or manage the applications.

Change #6: No Fabric8 server == no (Karaf) Fabric8 shell

If you are the shell kind of person (like me!), you probably enjoy Karaf-based Fabric8 shell very much. As there is no "Fabric8 server" anymore, Karaf won't provide the default shell any longer. For the Fabric8 v2 development activities, the recommended tool is JBoss Forge with the Fabric8 add-on. For provisioning purposes (like creating containers/services or changing the replica sizes) the default shell is OpenShift/Kube. Kube will be included in Red Hat Enterprise Linux and OpenShift V3 and is the standard shell for provisioning any kind of the container.

Technically, you can install Karaf server into the Kubernetes and enjoy the part of the old Fabric8 shell commands, but keep in mind that main development efforts will be focused on Kube and Forge commands.

Give it a shot

Wanna try new Fabric8 V2? Here is the detailed guide how to install it locally and deploy a sample application into it. Got problems with installation? Ping us on Fabric8 forum - we'd love to help you.

7 comments:

  1. Hi Henryk,

    It says on the FAQ page that FABs are now deprecated. Are the team killing the idea? or are they moving over to Fuse/Karaf?

    Cheers.

    ReplyDelete
  2. Hi Gareth,

    Killing, I'm afraid. We recommend to use plain Karaf features instead. FABs had too many corner cases...

    Cheers.

    ReplyDelete
  3. Hi Henryk,

    With coreos creating their own container runtime, Rocket (https://coreos.com/blog/rocket/). Is that something that Fabric8 will support in the future?

    Cheers,
    Phil.

    ReplyDelete
  4. Hi Phil,

    As soon as Kubernetes starts to support Rocket :) .

    Cheers.

    ReplyDelete
  5. Hi Vincent,

    The granularity of your service is up to up. I personally prefer to spawn more smaller microservices in many containers. But having single Karaf in a single container would be possible as well.

    Regarding the supported content of the containers - we should support all the technologies provided via the quickstarts [1]. So Tomcat, Spring Boot, Wildfly and all the others will be supported :) .

    Cheers.

    [1] https://github.com/fabric8io/fabric8/blob/master/docs/quickstarts.md

    ReplyDelete
  6. Hi Vincent,

    Yes. The maven-docker-plugin is responsible for putting the developed artifact into the Docker image. Then it is up to the Fabric8/Kubernetes to deploy/manage the final image.

    Cheers.

    ReplyDelete
  7. All the contents you mentioned in post is too good and can be very useful. I will keep it in mind, thanks for sharing the information keep updating, looking forward for more posts.Thanks
    android app templates

    ReplyDelete