[ https://issues.apache.org/jira/browse/AMQ-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288265#comment-17288265 ]
John Behm edited comment on AMQ-8149 at 2/22/21, 2:26 PM: ---------------------------------------------------------- Thanks for the comments. I did not have much time on friday, so I took all of my previous input and combined it in that one comment, as this issue did get some traction, so I felt like I had to be fast here. My comment is directed at the ActiveMQ Artemis product, I did not touch on the ActiveMQ topic at all. (the part of me being somewhat diappointed is not really necessary for this discussion at all, as we did really expect to use Artemis and we think that it has great potential and hopefully a great future, but currently not for us, thus not production ready for us. In the end it does not matter, whether I or some expert company get paid for taking their time to investigate an open source product, I might take longer, but I might also learn some new technologies along the way that might help the company on the long run). I did try to summarize my problems I faced when trying to run Artemis in a Kubernetes environment, but might go further into detail about what exactly hinders Artemis from being ready to be officially put into a Docker container. The efforts to actually take this step and go into the real cloud native direction is great. The configuration of Artemi, on the other hand, does not really seem to be made to be put into a container as one does not have an immutable image but a two stage process (referring to the current Dockerfile that is somewhere in the Github repository). The configuration of an application that runs inside of a Docker container is usually passed through either environment variables or mounted at a specific location or a combination of both. For that to work Artemis needs to have a static configuration which is not the case. In the first startup step (referring to the Dockerfile example in the github repo mirror) Artemis generates a somewhat generic broker.xml with some specific (performance) values that are inherent to the underlying container, hostmachine, etc. I think those performance values of the storage should be handled outside of the broker.xml (or calculated on every startup, whatever ideas you may have) as they usually cannot be known by the person configuring Artemis. Also the redundant passing of environment variables to the container and the JVM should preferrably also be done directly. So that Artemis does directly fetch all environment variables (I don't know if that's feasible without passing them to the JVM, I hope yes, as it's possible in other languages). These two key points would make Artemis way better configurable inside of a Docker container. I know that this issue is about the Docker image and I do not expect anyone to create anything else, yet. BUT one has to look ahead of the current stage and look at what might come after the Docker image is ready. What do people want and what the image is goind to be used for. The Docker image will be the foundation that every other technology like Kubernetes and should work properly for it to be successful now and in the future. The roadmap ahead for the Artemis product seems to be something along the lines of # Make Artemis container ready <-- this should be done first # Put Artemis in a Docker container # Run Artemis in Kubernetes <-- I don't expect anyone to take on any of these tasks in the near future at all. # Create a Kubernetes Operator was (Author: behm015): Thanks for the comments. I did not have much time on friday, so I took all of my previous input and combined it in that one comment, as this issue did get some traction, so I felt like I had to be fast here. My comment is directed at the ActiveMQ Artemis product, I did not touch on the ActiveMQ topic at all. (the part of me being somewhat diappointed is not really necessary for this discussion at all, as we did really expect to use Artemis and we think that it has great potential and hopefully a great future, but currently not for us, thus not production ready for us. In the end it does not matter, whether I or some expert company get paid for taking their time to investigate an open source product, I might take longer, but I might also learn some new technologies along the way that might help the company on the long run). I did try to summarize my problems I faced when trying to run Artemis in a Kubernetes environment, but might go further into detail about what exactly hinders Artemis from being ready to be officially put into a Docker container. The efforts to actually take this step and go into the real cloud native direction is great. The configuration of Artemi, on the other hand, does not really seem to be made to be put into a container as one does not have an immutable image but a two stage process (referring to the current Dockerfile that is somewhere in the Github repository). The configuration of an application that runs inside of a Docker container is usually passed through either environment variables or mounted at a specific location or a combination of both. For that to work Artemis needs to have a static configuration which is not the case. In the first startup step (referring to the Dockerfile example in the github repo mirror) Artemis generates a somewhat generic broker.xml with some specific values that are inherent to the underlying container, hostmachine, etc. I think those performance values of the storage should be handled outside of the broker.xml (or calculated on every startup, whatever ideas you may have) as they usually cannot be known by the person configuring Artemis. Also the redundant passing of environment variables to the container and the JVM should preferrably also be done directly. So that Artemis does directly fetch all environment variables (I don't know if that's feasible without passing them to the JVM, I hope yes, as it's possible in other languages). These two key points would make Artemis way better configurable inside of a Docker container. I know that this issue is about the Docker image and I do not expect anyone to create anything else, yet. BUT one has to look ahead of the current stage and look at what might come after the Docker image is ready. What do people want and what the image is goind to be used for. The Docker image will be the foundation that every other technology like Kubernetes and should work properly for it to be successful now and in the future. The roadmap ahead for the Artemis product seems to be something along the lines of # Make Artemis container ready <-- this should be done first # Put Artemis in a Docker container # Run Artemis in Kubernetes <-- I don't expect anyone to take on any of these tasks in the near future at all. # Create a Kubernetes Operator > Create Docker Image > ------------------- > > Key: AMQ-8149 > URL: https://issues.apache.org/jira/browse/AMQ-8149 > Project: ActiveMQ > Issue Type: New Feature > Affects Versions: 5.17.0 > Reporter: Matt Pavlovich > Assignee: Matt Pavlovich > Priority: Major > > Create an Apache ActiveMQ docker image > Ideas: > [ ] jib or jkube mvn plugin > [ ] Create a general container that supports most use cases (enable all > protocols on default ports, etc) > [ ] Provide artifacts for users to build customized containers > Tasks: > [Pending] Creation of Docker repository for ActiveMQ INFRA-21430 > [ ] Add activemq-docker module to 5.17.x > [ ] Add dockerhub deployment to release process -- This message was sent by Atlassian Jira (v8.3.4#803005)