fabric8 uses the Apache 2.0 License.
Fabric8 is an integrated open source DevOps and Integration Platform which works out of the box on any Kubernetes or OpenShift environment and provides Continuous Delivery, Management, ChatOps and a Chaos Monkey.
Fabric8 (pronounced fabricate) gives you out of the box services that assist you when building Microservices, monoliths or any application in a linux container (Docker/Rocket) environment and is built on top of Kubernetes.
openshift.io is a free hosted development platform which uses that lets developers plan, create, edit, run, debug and CI / CD applications that are hosted on OpenShift Online with a fully integrated console, IDE and deep analytics.
At the time of writing there are quite a few differences between the upstream fabric8 distribution and openshift.io which we are hoping to reduce ASAP. The differences today are:
So its going to take a little while for us to get a fabric8 distrition thats easy to install and run on any kubernetes or openshift cluster that mimicks the functionality of openshift.io but we will get there in the end.
At the same time in parallel we hope to make openshift.io work with different openshift clusters for building applications and using different environments; so that might be the fastest way to get an openshift.io experience either on premise or on your own kubernetes or openshift cluster in the cloud.
Fabric8 provides upstream innovation on concepts and features, once validated, make their way into other open source projects such as OpenShift Origin, Kubernetes and Jenkins (as examples). Fabric8 contributors work in the various other open source communities to align a unified developer experience.
webconsole are all great tools that end up operating on the same resources through the Kubernetes/OpenShift API. They can be used at any point to help manage your applications. The fabric8-maven-plugin is intended for Java developers developing applications "pre git-commit" on their laptops. It gives Java developers a familiar way of building/deploying their applications as well as logging, debugging, and live-reloading their applications using Kubernetes as an application cloud. Developers can use their favorite IDE which typically has great Maven integration. The sweet spot of Kubernetes/OpenShift is dealing with the build, deploy, and management of applications after a git commit/push. The CLI/webconsole is great at working with API resources, import projects from git, or spin up new projects from a template.
The fabric8-maven-plugin helps Java developers migrate existing Maven projects to Kubernetes/OpenShift as well. We're all busy Java developers and although it would be great to learn the ins/outs of kubectl, oc, Docker, Rkt, CNCF, OCI, Kubernetes, etc, the fabric8-maven-plugin helps abstract some of that away so we can be productive using tooling similar to others (any application-server maven plugin, spring-boot plugin, etc. fabric8-maven-plugin feels just like those others)
However you'd like. The fabric8-maven-plugin does help automatically generate this for you as part of your builds and even attach these resource files as build artifacts so they can be versioned and pushed to a central artifact repository.
The fabric8-maven-plugin generates the JSON/YAML resource files and can be customized using Maven configurations. See the documentation for fabric8-maven-plugin for more details. It can also introspect your projects and be a lot smarter about what resources to include (eg, health/liveness checks can automatically be enabled in the Kubernetes resource files if you've got, for example, spring-boot actuator or some other http endpoint that can expose liveness information).
The short answer is no ;).
Having said all that; with the Fabric8 iPaaS) focus, we have optimised Fabric8 so that folks who do use Java have an optimised experience of working with Docker, Kubernetes, OpenShift and Fabric8. Though we hope to continue to improve tooling, management and visualisation for other languages and runtimes too.
Jenkins Pipeline provides a domain specific language for orchestrating long running build tasks such as building, testing, approving, promoting and deploying steps using the Groovy programming language.
The preferred approach to using Jenkins Pipeline is to reuse docker images for all your build and testing tools; so that most of the details in your Jenkinsfile tends to be running commands inside docker images. So your CD pipeline definition is usually a list of commands using whatever tools you use (Maven, Grunt, Gulp, Make, bash, python, ruby, whatever) which is completely language, tool and framework agnostic.
However this is for orchestrating delivery pipelines which typically involves many tasks such as building, testing, approving, promoting and deploying. How each of those parts work is completely up to you.
For example you can reuse your existing CI server (Jenkins, Bamboo, TeamCity or whatever) to build your code then use a Jenkins Pipeline pipeline to move the build through environments, orchestrate system tests, soak tests, acceptance tests, approvals, promotions and so forth.
Our preferred approach is to use Jenkins Pipeline pipelines as the core orchestration layer when trying to implement Continuous Delivery, Continous Deployment or Continous Improvement then for that pipeline to trigger whatever is required to complete the pipeline; whether its one or more builds in an existing CI server, triggering OpenShift Source to Image builds or other existing build or test services then orchestrating those along with approval and promotion through Jenkins workflow. It also then means its easier to get a holistic view of your CD pipelines across all projects; irrespective of how each build or test works or what tools are used to build or test projects etc.
Fabric8 is comprised of a collection of projects written in Java and Golang and packaged up as Docker containers. The git repos for each of these projects/containers can be found in detail in the project documentation pages
Fabric8 is designed to work best on top of Kubernetes and Docker; it means fabric8 will work very well in any environment providing the Kubernetes platform such as OpenShift, Google Compute Engine, Azure etc.
Windows is currently only partially supported. Windows users may consider using Docker so that all the fabric8 technologies run inside a linux VM in lightweight containers.
If you are behind a corporate firewall then maven builds may fail to download jars from maven central.
To configure a HTTP Proxy in fabric8 open the [fabric8 console(console.html) then:
Runtimepage on the left tab
~/.m2/settings.xmlused by default on all maven builds in Jenkins - based on the this document
See the list of maven plugin goals
fabric8's Java code uses Java 8 but any docker image can use any version of any language, runtime or framework it wishes
No, not 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 ZK clusters is required for things like ActiveMQ clustering.
No, not 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 application's Docker image.
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 Kubernetes without keeping the configuration in any central repository (like Git).
However keeping app files in Git for easier configuration management is recommended. That's why fabric8 has integrated with Gogs for on premise git repository hosting. This comes from the fabric8 DevOps features.
No. Kubernetes is responsible for providing the runtime registry for the managed applications. It means that you don't have to start any dedicated Fabric8 software in production.
For provisioning purposes (like creating containers/services or changing the replica sizes) you can use the Fabric8 add-on or use the shell from OpenShift/Kubernetes.
Kubernetes will be included in Red Hat Enterprise Linux and OpenShift V3 and is the standard shell for provisioning any kind of the container.
FAB (Fuse Application Bundles) has been deprecated for the 1.2 release and removed from 2.x.