The official RabbitMQ BOSH release is cf-rabbitmq-release
This BOSH release is used by the RabbitMQ team to debug all things RabbitMQ & Erlang on GCP, AWS & vSphere. This release is only meant to be used for debugging purposes. It comes with no guarantees or promises, it just helps us ensure RabbitMQ is stable across different IaaS platforms, and is BOSH-friendly.
For the RabbitMQ Core team, ensure rabbitmq/rabbitmq-credentials is cloned alongside this repo, then cd rabbitmq-server-boshrelease & configure either env.example or envrc.example as a dotfile, then run . .env or direnv allow.
For the RabbitMQ SME team, ensure rabbitmq/sme-credentials is cloned alongside this repo, then cd rabbitmq-server-boshrelease & configure either envrc.sme.example as a dotfile, then direnv allow.
Don't forget to initialize this repository's submodules:
To create a new deployment, run deploy . A successful deploy will store a deployment
configuration file in deployment_configurations.
To update an existing deployment, run deploy-configuration
You're a champ for just thinking it! Making things better is deeply rewarding, we already like you very much : )
When you're making local changes and want to test the release, you can use create-dev-release and then deploy - remember to select the LATEST BOSH release version
To create a new BOSH dev release, run create-dev-release and then deploy. You will need to set the release version to latest (we default to final release version) when creating the manifest.
When the time comes to cut a new final release, create-final-release will do most of the heavy lifting. You will still need to create a git tag and update the CHANGELOG.md. It's a small price to pay for the excitement that shipping a final release brings.
github.com/erlang/otp is the official place for downloading Erlang patch releases, such as 19.3.4
Patch releases are not available from erlang.org
This release ships with multiple Erlang versions, all used in various production environments that we've come across, mostly via escalations or support cases. Take a look in packages/erlang-*
The Erlang version that will be used to run RabbitMQ can be selected when running deploy
We need to be able to deploy any RabbitMQ version, even dev releases produced by our CI. To obtain a GA version of RabbitMQ, see RabbitMQ releases on GitHub. Snapshot builds are available from Bintray.
When deploy asks you which RabbitMQ Server release you want to deploy. Select OTHER if you need to provide
an arbitrary rabbitmq-server-generic-unix-* package URL, e.g. a snapshot build from the Bintray repo mentioned above.
RabbitMQ v3.5 generic-unix packages are not fully supported. Even though cluster formation will succeed,without the rabbitmq_clusterer plugin, arbitrary node restarts will fail. Since RabbitMQ 3.5.x is no longer under development, we do not plan to address this shortcoming.
The correct way of setting system user limits in Linux is through /etc/security/limits.d. It might also be necessary to modify /etc/pam.d/common_session, depending on the Linux distribution.
Since we are running rabbitmq-server via start-stop-daemon, configuring system user limits through /etc/security/limits.d is not going to work. Executing ulimits -n just before running start-stop-daemon works just fine.
Template a single env file, never template scripts.
Most BOSH releases end up templating files left, right & center. It's most unfortunate when shell scripts get templated since this breaks shellcheck.
I cannot emphasise enough how important it is to run shellcheck against your shell scripts, preferably on every file save.
It works really well to have a single env file templated by BOSH, that contains all environment variables required by your release scripts. This has the added benefit of making it really easy to integrate your release executables with bosh ssh.
All BOSH jobs will only contain scripts that correspond to BOSH lifecycles:
- drain
- post-start
- pre-start
- start
- stop
Using a single script to both stop and start a BOSH job is guaranteed to cause more trouble than it's worth. Also, we would be violating the Single Responsibility Principle at great cost.
Respect the idempotency of all BOSH lifecycle events, be aware of their limitations and you are guaranteed the best BOSH experience. As all products, BOSH has its sharp edges, so don't make your life harder by ignoring this hard-earned advice.
RabbitMQ recognises many environment natively. We tried using RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS & RABBITMQ_CTL_ERL_ARGS to configure the Erlang cookie, but we have come across some limitations.
The first time you use an environment variable in a script, ensure that it has been defined. It's as simple as ${FOO:?must be defined}. Don't worry about the repetition, it will save you many frustrating debugging sessions.
This is most likely to stay consistent across versions. For example, RabbitMQ v3.7 will have a new configuration file format. The old one will still work, but we want to promote the new one as much as possible.
Be aware of commands that take multiple arguments, such as rabbitmq-plugins enable PLUGIN-A [PLUGIN-B...]. They can speed things up considerably.
If a command fails, it will be more obvious what failed and should even hint how to fix the failure. The new configuration format in RabbitMQ v3.7 will help things, for sure.