This article is the second in a series on implementing an Erlang distributed service with BOSH & Cloud Foundry. In the first article, I created a simple BOSH release which compiled a couple of packages and ran a single Erlang job (a monitored daemon) on three virtual-machines. My eventual goal here is to have a running service broker, and conduct some experiments with distributed Erlang and Cloud Foundry, but before we get there, we have some more work to do.
While developing the broker, it became clear that I need a few more build-tool dependencies. I want to keep these articles as short and focused as possible, so in this article, we’ll do just that.
To begin with, let’s take a look at the state of our deployments:
We’re running 2 deployments: Cloud Foundry and our own Erlang deployment. You can also see that the Erlang deployment has 3 VMs running (just like before) and our release is running at our initial level: “0+dev.1″. You see, BOSH is nice enough to allow us to iterate without having to get all the way to a 0.0.1 release — we’re not quite there yet…
In order to really run the components of the Erlang service-broker, we’ll need the Rebar packaging tool, Git to pull in dependencies, and Python to compile Git. Rebar uses Git when it runs to pull down Erlang dependent libraries (like Gem in Ruby, NPM in Javascript or Maven in Java). The BOSH docs talk about this as a dependency graph, and the way we create that graph, is just by adding entries each package’s spec file. You might notice in our depiction that Rebar doesn’t depend upon Git (even though I just explained that it does). Instead, the Erlang job (recall, that’s a monitored daemon in BOSH) depends upon it directly. That’s because BOSH makes a distinction between compile time dependencies and run time dependencies. In our case, Git has a compile time dependency on Python, while Rebar has a run time dependency on Git. It took me a bit to figure out what was going on, but in practical terms, if you want the package to be around when the daemon is running, make it a job dependency; otherwise, it won’t be there.
Here we’ll generate new packages for each using Stark & Wayne’s bosh-gen gem (like in the last article):
Make the package specs to reflect this graph, and fix the packaging scripts:
For Python:
For Git:
More.. http://spiegela.com/2015/01/22/adding-packages-to-a-bosh-deployment/
Powered by: BKGjewelry
