{"id":26059828,"url":"https://github.com/orange-cloudfoundry/cassandra-deployment","last_synced_at":"2026-02-10T23:32:38.510Z","repository":{"id":146522447,"uuid":"136958310","full_name":"orange-cloudfoundry/cassandra-deployment","owner":"orange-cloudfoundry","description":"Standard deployment manifests for the Cassandra BOSH Release","archived":false,"fork":false,"pushed_at":"2019-05-08T21:03:56.000Z","size":45,"stargazers_count":1,"open_issues_count":2,"forks_count":1,"subscribers_count":8,"default_branch":"master","last_synced_at":"2025-08-25T22:31:35.732Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/orange-cloudfoundry.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2018-06-11T17:21:10.000Z","updated_at":"2023-03-22T03:42:49.000Z","dependencies_parsed_at":null,"dependency_job_id":"cf90fe73-83c6-40e2-9b5e-ec1abb2c3695","html_url":"https://github.com/orange-cloudfoundry/cassandra-deployment","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"purl":"pkg:github/orange-cloudfoundry/cassandra-deployment","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/orange-cloudfoundry%2Fcassandra-deployment","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/orange-cloudfoundry%2Fcassandra-deployment/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/orange-cloudfoundry%2Fcassandra-deployment/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/orange-cloudfoundry%2Fcassandra-deployment/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/orange-cloudfoundry","download_url":"https://codeload.github.com/orange-cloudfoundry/cassandra-deployment/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/orange-cloudfoundry%2Fcassandra-deployment/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29321371,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-10T20:44:44.282Z","status":"ssl_error","status_checked_at":"2026-02-10T20:44:43.393Z","response_time":65,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-03-08T13:28:37.190Z","updated_at":"2026-02-10T23:32:38.501Z","avatar_url":"https://github.com/orange-cloudfoundry.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Base deployment\n\nThe base deployment suggested here is made of the `cassandra.yml` base\nmanifest and the `default-vars.yml` default variables.\n\nThis is a classical deployment with 3 seeds and optionally more servers. It\nprovides two separate instance groups for this, named `cassandra-seeds` and\n`cassandra-servers`.\n\nCassandra “seeds” are plain Cassandra nodes with a special role in the\ncluster: They are meant to “explain” the cluster topology (how data is spread\naccross nodes) to any new node that enters the cluster. From the perspective\nof a BOSH Release maintainer, the only particularity they have is to be listed\nin the `seed_provider:` section of the `cassandra.yaml` configuration file.\n\nWhen scaling out the cluster, you should add more instances (default is 0) of\nthe `cassandra-servers` instance group.\n\nThe default of 3 seeds is reasonable because less becomes risky to handle\nsituations when performing rolling upgrades or in case of failure.\n\nBy default, the `system_auth` keyspace (holding users and keyspaces) is\nreplicated as many times as there are cassandra seeds. So when you deploy\nseeds only, you get one replication of it on all nodes.\n\n\n# Deployment topologies\n\nYou should span your Cassandra nodes accross different hypervisors and\ndifferent availability zones, in order to minimize risk of data loss in case\nof failure.\n\nThe default deployment uses the standardrd 3 zones named `z1`, `z2` and `z3`.\nYou should refer to the documentation of your CPI in order to properly setup\nthese availability zones in your Cloud Config. See [Defining\nAZs][defining_azs] and [CPI Specific `cloud_properties`][cpi_Specific_cloud_properties]\nfor more information.\n\n[defining_azs]: https://bosh.io/docs/azs/#config\n[cpi_Specific_cloud_properties]: https://bosh.io/docs/azs/#azs-cloud-properties\n\n\nRandomizing AZ placement with the [`randomize_az_placement`][features_block]\nproperty should be considered, and you can use the `randomize-az-placement.yml`\nops file for this. For complex topologies with different availability zones\nand different data centers, the\n[`bosh_to_cassandra_topology_mapping`][bosh_to_cassandra_topology_mapping]\nproperty should help you mapping those to Cassandra “Racks” and “DCs”. Refer\nto the comprehensive documentation of the [`cassandra` job spec][bosh_to_cassandra_topology_mapping].\n\n[features_block]: https://bosh.io/docs/manifest-v2/#features\n[bosh_to_cassandra_topology_mapping]: https://github.com/orange-cloudfoundry/cassandra-boshrelease/blob/master/jobs/cassandra/spec#L577-L609\n\n\n# Operations files\n\n## `use-bpm.yml`\n\nThis is a recommended way to strengthen the security of you Cassandra nodes in\nproduction, implementing namespaces and cgroups to sandbox the execution of\nCassandra daemons. Using BPM (BOSH Process Manager) is meant to become the\ndefault in future versions of this BOSH release.\n\n\n## `cf-service-broker.yml`\n\nThis operations file add a `cassandra-brokers` instance group, a\n`broker-smoke-tests` errand job, and both `broker-registrar` and\n`broker-deregistrar` errand jobs.\n\nThe Cassandra Service Broker implements the `cf create-service` verb as a\nkeyspace creation and the `cf bind-service` verb as a user creation.\n\nThe Cassandra Service Broker is purely stateless, so there is no need to setup\nany database for it to work. This is possible thanks to a convention on naming\nthe created keyspaces and users. Keyspaces typically start with the `ks`\nprefix. The Service Brokers only relies to the keyspaces and users in\nCassandra that follow its naming pattern.\n\n### Broker smoke tests\n\nThe Service Broker comes with a `broker-smoke-tests` errand job that\nimplements a full round-trip around pushing an app in Cloud Foundry, binding a\nCassandra service to it, writing some data, and checking it can be read back.\n\n### Broker registration and purge\n\nThe `broker-registrar` and `broker-deregistrar` errand jobs are provided by\nthe standard\n[`broker-registrar` BOSH release](https://github.com/cloudfoundry-community/broker-registrar-boshrelease),\nas provided by the Cloud Foundry community. Then you can register your broker\n\nin CF with `bosh run-errand broker-registrar`. The deployment option retained\nhere is to have those two errand jobs be deployed each one on its own VM. This\nis recommended as a security perspective because the confguration files that\nare rendered for running those errands typically contain admin passwords, so\nit's best deleting them after their errand has run. From a performance\nperspective though, you might be interedted in collocating those jobs on a\nsingle service broker instance (this implies you have only one), so that you\ndon't pay the cost of creating a new VM when running them.\n\nIf you are not familiar with the semantics of this `broker-registrar` BOSH\nrelease, there's one important thing to know. Be aware that the\n`broker-deregistrar` job actually purges all services offerings from Cloud\nFoundry, which can be pretty destructive for your Clooud Foundry users. This\nis supposed to be used with great caution.\n\n### Requirements on your Cloud Foundry deployment\n\nWith the `cf-service-broker.yml` operations file, we assumes that you are\nusing the *de facto* standard `cf-admin-user` job from the\n[`collection-of-pullrequests` BOSH Release](https://github.com/cloudfoundry-community/collection-of-pullrequests-boshrelease),\n(as provided by the Cloud Foundry community), which is pretty useful at\nproviding a BOSH 2.0 Link that lets the Broker (De-)Registrar errand jobs know\nthe exact Cloud Foundry settings. If you don't use it, then you can provide\nvalues for this Bosh Link manually. See the [Manual Linking](https://bosh.io/docs/links-manual/)\nsection of the Bosh documentation for details about how to do this.\n\n\n## `shield-v7-agent.yml`\n\nThis operations file installs a SHIELD v7 agent for backuping you Cassandra\ncluster. By default, system keyspaces are excluded. Only user keyspaces are\nbackuped. As a requisite, please note that the `cassandra` SHIELD plugin only\nexists as of version `v7.0.4` of the SHIELD Bosh Release. Version `v7.0.8` of\nthe [gk-shield-boshrelease](https://github.com/gstackio/gk-shield-boshrelease)\nis highly recommended.\n\nWith Cassandra, keyspaces usually have a replication factor that is strictly\nless than the number of nodes in the cluster. This implies that keyspaces have\nto be backuped on *all* cluster nodes at the same time if you want to capture\nall their data.\n\nAs SHIELD has no “cluster” abstraction, operators are required to create\nseparate one target and one job for each Cassandra node. To help in this\nsetup, the SHIELD auto-config that is provided here uses a mini-templated\nsyntax with idioms like `(ip)` and `(deployment)`.\n\nThe provisioned SHIELD jobs all use the same SHIELD schedule, so they are\nstarted nearly at the same time. You don't get strict ACID consistency with\nsuch a design but this is still a working backup solution.\n\nThe `shield-v7-agent.yml` ops file demonstrates an example SHIELD store that\nuses the `fs` plugin. Because there is a bug with purging archives stored with\nthis `fs` plugin the complementary `shield-v7-purge-archives.yml` ops file is\nprovided as a workaround.\n\n\n## `shield-v8-agent.yml`\n\nThis operations file provides pretty much the same as its v7 counterpart, but\nhere for SHIELD v8. Please read the related documentation first. As a\nrequisite, please note that the `cassandra` SHIELD plugin was merged into v8\nbranch as of version `v8.0.5` of the SHIELD Bosh Release.\n\nA few variables need to be specified, like the `((shield_domain))`which is an\nIP address or a DNS name that Cassandra nodes can use to reach the SHIELD\n“core” server. The `((shield-ca))` certificate should be the one from your\nSHIELD deployment. We recommend you upload it in your CredHub config server\nfirst, or use an absolute-path syntax that will target it in CredHub:\n\n```\n((/\u003cbosh-director-name\u003e/\u003cshield-deployment-name\u003e/shield-ca.certificate))\n```\n\n\n## `scale-vms-and-disks.yml`\n\nThis helps defining different VM type and persistent disk type for all VMs of\nthe Cassandra cluster.\n\n\n## `scale-memory.yml`\n\nThis helps defining custom heap size for Cassandra JVM instances. Setting both\n`((max_heap_size))` and `((heap_newsize))` variables in necessary for this.\n\n\n# Development operations files\n\n## `admin-tool.yml`\n\nThis operations file adds a job that provides convenient wrappers around usual\ncassandra administrative tools. These are provided by this BOSH Release for\nhuman convenience only, so they are definitely not required for a Cassandra\ncluster to properly work. They are even not recommended in production, as they\ncan provide a larger attack surface to intruders.\n\n\n## `latest-versions.yml`\n\nThis helps release authors to deploy their latest development release that is\nuploaded to the BOSH director.\n\n\n## `bosh-lite.yml`\n\nThis operations file implements the necessary settings for deploying in Bosh-Lite.\n\n\n## `custom-release-name.yml`\n\nThis helps release authors to deploy Cassandra releases with custom names, as\nproduced by the `bosh create-release --name` command. This is especially\nuseful when release authors are developing new features for the BOSH release\nat the same time using a single shared BOSH director.\n\n\n# Experimental operations files\n\n## `experimental/use-tls.yml`\n\nThis ops file enable TLS for client-to-node connection and enforces mutual TLS\n(mTLS) for internode connections.\n\nAlone, this ops file in not enough alone for enabling these features. First,\nit requires the `rename-deployment-and-network.yml` ops file. Then, a\ncertificate chain must be specified adding one of `tls-certs-green.yml` or\n`tls-certs-blue.yml`.\n\nIn a running cluster, the impact of re-deploying with TLS enabled is that\nCassandra nodes implementing TLS won't be able to connect to Cassandra nodes\nimplementing non-encrypted connections. Thus, the operation introduces a\nsplit-brain in the cluster, where the smaller part progressively become the\nlarger one while BOSH re-restarts cluster nodes with TLS enabled.\n\n\n## `experimental/tls-certs-green.yml`\n\nThis uses the “green” certificate chain for client-to-node TLS encryption and\ninternode mTLS. By “certificate chain”, we mean a server certificate and a\nCertificate Authority. Transitioning from green to blue (forth or back)\ncertificates is only required when rotating certificates.\n\nWhen rotating certificates from “green” to “blue”, the process is to use\n`tls-certs-blue.yml` instead of `tls-certs-green.yml` and re-deploy.\n\nIf “blue” certificates have never been created, they will be generated by the\n`bosh` CLI (when using a local file as `--vars-store`), or by the CredHub\nserver (if enabled). As a safety measure, you should always first ensure that\nthe “blue” certificates don't exist in your local variables store, or in your\nCredHub server. If you need to use a custom Certificate Authority, then its\npublic certificate and private key will have to be specified as\n`cassandra_ca_blue` variable in the local variables store, or uploaded for\nthis deployment variable in CredHub.\n\nThe impact of the certificate rotation operation is that Cassandra nodes\nimplementing “blue” certificate won't be able to connect to Cassandra nodes\nimplementing the “green” certificate. Thus, the certificate rotation introduce\na split-brain in the cluster, where the smaller part progressively become the\nlarger one while BOSH re-restarts cluster nodes with the new certificates.\n\n\n## `experimental/tls-certs-blue.yml`\n\nSame as the “green” certificate chain above, but this is the “blue” one. Which\nonly means that it's a different set of certificates. Transitioning from green\nto blue certificates (forth or back) is only required when rotating\ncertificates.\n\n\n## `experimental/rotate-certs-transitional-step.yml`\n\nThis experimental ops file is meant to be used as an intermediate step for a\nsmooth transition from green to blue certificates, or the reverse from from\nblue to green.\n\nThis idea here is to run an intermediate deployment trusting both “green” and\n“blue” certificates, before actually switching server certificates. This\nintermediate step would be required temporarily, just for the sake of rotating\ncertificates.\n\nBut as it turns out, Cassandra doesn't support specifying many trusted\nCertificate Authorities for mutual TLS. Even when those CAs are properly put\nin the Java Truststore, connection issues appeared in the cluster between\nnodes using different server certificates.\n\nThis experimental ops file is still kept here in case it turns out being\nuseful in the future.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Forange-cloudfoundry%2Fcassandra-deployment","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Forange-cloudfoundry%2Fcassandra-deployment","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Forange-cloudfoundry%2Fcassandra-deployment/lists"}