ObjectStore Behavior in Runtime Fabric
Runtime Fabric is a containerized deployment type, where every application deployed is contained within its Mule Runtime; it is its own private Kubernetes Pod.
Join the DZone community and get the full member experience.
Join For FreeAgenda
- ObjectStore feature for Runtime Fabric
- Demo
ObjectStore Feature for Runtime Fabric
Limitations
- Runtime Fabric is a containerized deployment type, where every application deployed is contained within its Mule Runtime; it is its own private Kubernetes Pod.
- To facilitate containerization, the model is designed such that when an application is deployed, updated, or restarted, the image of the Mule Runtime and Application is rebuilt and redeployed.
- Furthermore, this feature indicates that ObjectStore, when applied in Runtime Fabric, does not approve file-based persistence. This does not mean that file-based object store cannot be used but it will be deleted or removed from pod/platform if any restart happens on the application pod.
- The promoted usage of MuleSoft ObjectStore in Runtime Fabric is "in-memory" and applications should be designed to not have a dependency on persistent object store data.
- Kubernetes performs workload by setting containers into Pods to run on Nodes. The state of nodes behaves depending on the cluster's configurations. Each node is managed by the control plan and contains the services necessary to run Pods.
- The containers in a Pod can also communicate with each other using standard inter-process communications like SystemV semaphores or shared memory.
Demo
Live Demo
ObjectStore
Kubernetes
application
pods
Object (computer science)
cluster
Memory (storage engine)
Data (computing)
Dependency
Published at DZone with permission of Sadik Ali. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments