0

We are attempting to put an instance of rabbit mq into our Kubernetes environment. To do so, we have to implement it into our build and release process, which includes creating a docker container by Dockerfile.

During our original testing, we created the docker container manually with the following commands, and it worked correctly:

docker pull rabbitmq
docker run -p 5672:5672 -d --hostname my-rabbit --name some-rabbit rabbitmq:3
docker start some-rabbit

To create our docker file, we have tried various iterations, with the latest being: 

FROM rabbitmq:3 AS rabbitmq
RUN rabbitmq-server -p 5672:5672 -d --hostname my-rabbit --name some-rabbit 
EXPOSE 5672

We have also tried it with just the Run rabbitmq-server and not the additional parameters.

This does create a rabbit mq instance that we are able to ssh into and verify it is running, but when we try to connect to it, we receive an error: "ExtendedSocketException: An attempt was made to access a socket in a way forbidden by its access permission" (we are using rabbit's default of 5672).

I'm not sure what the differences could be between what we've done in the command line and what has been done in the Dockerfile.

Rico
  • 58,485
  • 12
  • 111
  • 141
Marshall Tigerus
  • 3,675
  • 10
  • 37
  • 67

2 Answers2

1

Looks like you need to expose quite a few other ports.

I was able to generate the Dockerfile commands for rabbitmq:latest (rabbitmq:3 looks the same) using this:

ENV PATH=/usr/lib/rabbitmq/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin    
ENV GOSU_VERSION=1.10    
ENV RABBITMQ_LOGS=-   
ENV RABBITMQ_SASL_LOGS=-   
ENV RABBITMQ_GPG_KEY=0A9AF2115F4687BD29803A206B73A36E6026DFCA 
ENV RABBITMQ_VERSION=3.7.8   
ENV RABBITMQ_GITHUB_TAG=v3.7.8
ENV RABBITMQ_DEBIAN_VERSION=3.7.8-1
ENV LANG=C.UTF-8   
ENV HOME=/var/lib/rabbitmq    
EXPOSE 25672/tcp  
EXPOSE 4369/tcp
EXPOSE 5671/tcp
EXPOSE 5672/tcp
VOLUME /var/lib/rabbitmq
ENTRYPOINT ["docker-entrypoint.sh"]
CMD ["rabbitmq-server"]
Rico
  • 58,485
  • 12
  • 111
  • 141
0

Dockerfile is used to build your own image, not to run a container. The question is - why do you need to build your own rabbitmq image? If you don't - then just use the official rabbitmq image (as you originally did). I'm sure it already has all the necessary EXPOSE directives built-in Also note command line arguments "-p 5672:5672 -d --hostname my-rabbit --name some-rabbit rabbitmq:3" are passed to docker daemon, not to the rabbitmq process. If you want to make sure you're forwarding all the necessary ports - just run it with -P.

antweiss
  • 2,789
  • 1
  • 13
  • 12
  • our build process currently requires a dockerfile. Are you saying we could literally just have a dockerfile that was just FROM rabbitmq:3 AS rabbitmq – Marshall Tigerus Nov 26 '18 at 20:01
  • yes, this would work but it makes no sense - why repackage an existing image? you don't actually need to build your own image - just create a deployment based on rabbitmq. Also I heartily recommend you not to use just 'rabbitmq', which implies the 'latest' tag, but work with a specific version. this way you you can be sure all your deployments are identical. – antweiss Nov 27 '18 at 10:57