For a local Tunnelbroker development environment, we need to use a local instance of the RabbitMQ server.
Add the RabbitMQ docker image after the localstack image to the docker-compose.
AMQP(s) ports 5672 and 5671 are forwarded to use in local or docker builds.
The rabbitMQ management console is listening on localhost:15672.
The local image user and password are set to comm:comm.
Details
Details
Successfully connected to the rabbitMQ by AMQP client and logged into the local management web-gui.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- docker-rabbitmq-image
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| services/docker-compose.yml | ||
|---|---|---|
| 84 | ||
Comment Actions
Adding @jimpo as a blocking reviewer so that we can clarify if specifying default user and pass is a good practice.
| services/docker-compose.yml | ||
|---|---|---|
| 94–95 ↗ | (On Diff #12577) | Is it a good practice to specify the credentials here? |
| 84 | Thanks for creating that diff! This diff still specifies the container_name so please delete it before landing | |
| services/docker-compose.yml | ||
|---|---|---|
| 94–95 ↗ | (On Diff #12577) |
This image is for the local dev environment only, it's safe to use it here. Also, we can omit this and use the default rabbitMQ user and password which are guest. |
| 84 |
Fixed, thanks for catching this! | |
Comment Actions
I think it's not crazy to specify the credentials like this for now, especially because this Docker Compose is probably only used for the dev environment. Docker Compose is not really set up for orchestration... for that, you'd need K8s or Docker Swarm, or maybe Terraform can help with some of it.
In the production environment, we should avoid specify username / password like this. @geekbrother, can you create a task to track this? Then we can give @jimpo a couple days to give his thoughts before removing him from the review.
Comment Actions
In the production environment, we should avoid specify username / password like this.
Of course, we should not use such an approach in the production. That would be crazy.
@geekbrother, can you create a task to track this? Then we can give @jimpo a couple days to give his thoughts before removing him from the review.
Sure, I've created ENG-1153 task to track this.