Chapter 5. Migrate Fabric Profiles

This section covers the migration of Fabric8 1.x profiles manually in Fuse 7.1.

5.1. Overview

Fabric8 V1 monolithic application deployments may need to be migrated to micro-service applications or migrated to a monolith container in OpenShift that exposes several services (not optimal).
Re-factor network of Broker architectures to JBoss AMQ-7. The re-factoring affects how user applications connect to Broker and are deployed in OpenShift.
Containers can be mapped one to one from Fabric8 V1 deployments if the Fabric8 V1 architecture was a micro services style deployment. Container meta data such as host name, port, and so on need to be mapped to OpenShift resources and concepts such as Nodes, Pods and Services.
Features and bundles that were only available in Fabric8 V1 need to be mapped to either OpenShift resources/features or to an alternative solution.

Fabric8 V1 deployments may be monoliths that are connected using Fabric, or they may be a large number of small Fabric containers running ActiveMQ Brokers and, or Camel routes.
Monolith deployments will have to be refactored into several services under OpenShift.
Applications developed to run in Karaf could potentially be affected in the migration from version 2 to version 4. You have a choice between redeploying existing applications to a Karaf image on OpenShift or (optionally) refactoring applications to run in a Spring Boot container instead.
Use OpenShift’s EFK (ElasticSearch+Fluentd+Kibana) stack instead of Fabric8 V1 Insight for log monitoring.
Use OpenShift application services and routes instead of Fabric8 V1 Gateway.
Monitoring in OpenShift is supported using Fuse 7 HawtIO console and Prometheus monitoring service. Users have to configure and deploy their own Prometheus servers as the server requirements are unique to the applications being monitored.

Fabric8 V1 containers refactored to run small services will map to Fuse on OpenShift based projects packaged as OpenShift pod based services.
Fuse on OpenShift projects could be deployed using S2I templates to build the source in OpenShift builder pods, or built externally using Fabric8 maven plugin and deployed using S2I binary deployment. External builds may be more efficient and can be performed using external CI/CD infrastructure such as Jenkins.
Fabric8 V1 container versions can be migrated to ImageStream tags for versioning in OpenShift.
OpenShift Deployment Configuration supports liveness probes and scaling of services.
A new fabric8-karaf-cm feature bridges OpenShift ConfigMaps and Karaf ConfigAdmin service to provide dynamic configuration updates in OpenShift Karaf applications. See Fuse on OpenShift Guide for more details.