Bosh release for Zipkin

One of the fastest ways to get Zipkin running on any infrastructure is to deploy this BOSH release.

Disclaimer

This is not presently a production ready Zipkin BOSH release. This is a work in progress. It is suitable for experimentation and may not become supported in the future.

Usage

Upload the BOSH release

To use this BOSH release, first upload it to your BOSH:

bosh target BOSH_HOST
git clone https://github.com/frodenas/zipkin-boshrelease.git
cd zipkin-boshrelease
bosh upload release releases/zipkin/zipkin-3.yml

Create a BOSH deployment manifest

Now create a deployment file (using the files at the examples directory as a starting point). You can use either a redis or cassandra store backend.

Note that the examples requires you to open some ports, so you will need to:

Create a security group (or the equivalent) named bosh with the following ports opened:

• TCP 22, 4222, 6868, 25250, 25555, 25777 from 0.0.0.0 to enable BOSH to communicate with the agents
• UDP 53 to enable using the BOSH DNS

Create a security group (or the equivalent) named zipkin (or the name of your deployment) with the following ports opened:

• All TCP/UDP ports from within the zipkin security group
• TCP 80 from 0.0.0.0 to enable access to the Zipkin Web
• TCP 9410 from 0.0.0.0 to enable sending traces to the Zipkin Collectors

Deploy using the BOSH deployment manifest

Using the previous created deployment manifest, now we can deploy it:

bosh deployment path/to/deployment.yml
bosh -n deploy

Feed data

Use any compatible Zipkin instrumented library (like Spring Cloud Sleuth) to feed data into the Zipkin collectors.

Contributing

In the spirit of free software, everyone is encouraged to help improve this project.

Here are some ways you can contribute:

• by using alpha, beta, and prerelease versions
• by reporting bugs
• by suggesting new features
• by writing or editing documentation
• by writing specifications
• by writing code (no patch is too small: fix typos, add comments, clean up inconsistent whitespace)
• by refactoring code
• by closing issues
• by reviewing patches

Submitting an Issue

We use the GitHub issue tracker to track bugs and features. Before submitting a bug report or feature request, check to make sure it hasn't already been submitted. You can indicate support for an existing issue by voting it up. When submitting a bug report, please include a Gist that includes a stack trace and any details that may be necessary to reproduce the bug, including your gem version, Ruby version, and operating system. Ideally, a bug report should include a pull request with failing specs.

Submitting a Pull Request

1. Fork the project.
2. Create a topic branch.
3. Implement your feature or bug fix.
4. Commit and push your changes.
5. Submit a pull request.

Create new release

Creating new final release

To create a new final release you need to get read/write API credentials to the @cloudfoundry-community s3 account.

Please email Dr Nic Williams and he will create unique API credentials for you.

Create a config/private.yml file with the following contents:

---
blobstore:
  s3:
    access_key_id:     ACCESS
    secret_access_key: PRIVATE

You can now create final releases for everyone to enjoy!

bosh create release
# test this dev release
git commit -m "updated mesos"
bosh create release --final
git commit -m "creating vXYZ release"
git tag vXYZ
git push origin master --tags

Copyright

Copyright (c) 2015 Ferran Rodenas. See LICENSE for details.