[
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/23/21, 8:26 AM:
----------------------------------------------------------
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) Artemis generates a somewhat generic broker.xml with some specific (hard
drive 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 thus it should work properly for it to be successful now and in
the future.
If plugins are not to be baked into the image, there should be a means of
providing parameters to download e.g. maven artifacts (usually not recommended,
as baking it into the image adheres to the immutable image "principle")
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) Artemis generates a somewhat generic broker.xml with some specific (hard
drive 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 thus it 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)
