How to Use Cloudify’s Deployment Proxy to Pass Parameters Between Deployments and More

This post originally appeared in Sebastian’s personal blog at this link.

What happens if you need to service chain VNF’s and you need to pass parameters between VNF deployments?
This question looks a bit trivial, but sometimes it may cause users a bit of a headache. Why? Because if you’re, for example, service chaining a vRouter with a vFirewall and for some reason you need to create them as separate deployments in Cloudify (creating single blueprint is a no brainer, so we won’t discuss it here), how do you then query the system for the private LAN network name and details on which you want to plug in the vFirewall? This is where the Deployment Proxy plugin is coming handy.

Orchestrate VNFs at no cost in the Cloudify NFV Lab!   TRY FREE

The purpose of the Deployment Proxy is twofold:

• Deployment chaining – helping to pass parameters between deployments
• Deployment triggering – when one deployment triggers others

I’m going to discuss both use cases in the context of a Virtual Branch as I utilize the deployment proxy quite extensively in that use case. Initially, I was only using the deployment proxy for deployment chaining as I needed to pass the parameters between deployments. All three VNFs were created one by one manually, which was a bit of overhead. One of our customers asked me to streamline the process and launch them in one shot. I could always create one monster blueprint and create a single deployment – but I wanted to leverage existing work and use existing blueprints. This is where the deployment proxy came in handy and I used it to trigger deployments – but I’ll get there in a second. Let’s start with deployment chaining.

Deployment chaining

In Cloudify, a deployment represents a namespace. We can query parameters, properties, and runtime properties, but only within the boundaries of a deployment. We cannot query runtime properties of nodes from another deployment. This is the way the system was built. Sometimes this can be a limitation which is why Cloudify decided to introduce the Deployment Proxy plugin.

Deployment proxy brings a proxy type into a blueprint which can query other deployments for output parameters. As we can see in the diagram above, the vFirewall Deployment queries the vRouter Deployment in order to “get parameters”.
In order to better illustrate, here’s a more detailed diagram:

In this diagram we have 3 deployments:

• vRouter Deployment
• vFirewall Deployment
• Application Deployment

Two deployments are using deployment proxy which are represented through “green” nodes. The vFirewall Deployment has a node which I called “router_node,” and which represents the deployment proxy. This node is “fetching outputs” from the vRouter Deployment. Sample code can be found here.

The above is part of a vFirewall blueprint where I’ve created a node “branch_vnf_deployment” of the type: cloudify.nodes.DeploymentProxy  and  represents vRouter. The parameters of it are blueprint and deployment name of vRouter. When this node is instantiated, it polls the relevant deployment for output parameters (e.g. baseline_branch_mgmt_lan_net) and stores them under runtime properties (e.g. branch_lan_net)
Once stored, we can use them in the current deployment:

I used also deployment proxy to service chain vRouter with HQ router. I’ll leave it to you to analyze the code and why I did that 🙂.

Deployment triggering

Being able to trigger a deployment from another deployment is another function of Deployment Proxy. Sometimes we may have a need, to not create one giant deployment with 100’s of nodes – but we want to split them into individual deployments for the sake of manageability.

In the above diagram we can see the vBranch Deployment which contains three nodes of the type of deployment proxy: router_node, firewall_node, and application_node. Once we create this deployment and run the install workflow, it will instantiate three nodes and these three nodes will trigger instantiation of three deployments. As a result, in Cloudify Manger we will see four deployments:

• vBranch
• vRouter
• vFirewall
• vApplication

The real case is presented in here.

The Benefit

What’s the benefit of using the deployment proxy? In my case it was flexibility and reusability. Instead of building one giant blueprint representing all three VNFs – I leveraged three individual blueprints. Thanks to that I had the flexibility to install and uninstall VNFs selectively. Having one giant blueprint which spins up all three VNFs means I need to uninstall all three in case the need to uninstall is required. It was my design decision. Yours may be different. What’s important is that Cloudify gives you the option to choose.
As you can see, the deployment proxy is very powerful. We can chain deployments in order to build service chains or trigger deployments from one deployment. Read more about the deployment proxy and other Cloudify Utilities.