You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Victor Romero <vi...@gmail.com> on 2015/10/01 07:23:54 UTC
Re: [DISCUSS IDEA] artemis create --docker
Llet me try to clarify how docker works and which are its expectations:
There are three outstanding moving pieces in docker:
- *Docker container*, an instance of a docker image.
- *Docker images* are *self contained images* of a piece of software,
its dependencies, end everything else down to the operating system.
- *DockerFiles*, the recipe to generate a docker image.
Two important best practices
<https://docs.docker.com/articles/dockerfile_best-practices/> regarding
creation of containers are:
- Containers should be ephemeral, it can be stopped and destroyed and a
new one built and put in place with an absolute minimum of set-up and
configuration.
- Run only one process per container.
Docker containers are customized tipically in two ways:
- Changing some simple value, like the number of threads of a listener:
with a passed environment property, i.e: -e HTTP_LISTENERS=64
- Changing actual files/directories both for input/output from/to the
image: with mounted volumes
<https://docs.docker.com/userguide/dockervolumes/>. An example of out
would be mounting a logs directory and an example for input, we could say,
mounting the apps directory of tomcat, i.e: -v /webapp training/webapp
There is a repository of docker images, similar to what maven central is
for maven, and this is dockerhub <https://hub.docker.com/>. The docker
command like has full support for it. Software providers can provide an
official docker image just like in maven central. On example could be the
official RabbitMQ <https://hub.docker.com/_/rabbitmq/> docker image that
has been there for a while. Of course users do prefer official images but
they tipically coexist with a bunch of other community images.
If we don't go creative, the tipical case for a docker image is just an
image that allows configuration to some extent using environment properties
and some volumes mounted. This is exactly what I tried to accomplish the
image <https://hub.docker.com/r/vromero/activemq-artemis/> I recently
uploaded to dockerhub.
*All this said, is there space for improvement?*
I'm afraid I kind of disagree with you in believeing there is value on
the artemis
create phase. There is very little customization at that point and very
little to no value at all would be added by generating a docker image at
this phase, i.e: Why not just have an official docker image published in
dockerhub that would have the very same effect with much less tooling and
non standard procedures involved?
*What about creating an image of an already customized instance?*
This would be having a base docker image all ready except for the artemis
intance, and then create an image with the instance on top of it.
I think there is some value on this but to be completely honest, this goes
against the common use of docker. The software and the very basic
configuration tipically reside on the image, and the hard core
configuration comes in the form of a mount point.
I'm on the fence around this one, perhaps there is some value, but at this
point I would rather say that it's better to not to go against the flow and
do something that is considered incorrect by the docker community.
*What would I personally do (docker related) with artemis:*
Personally I would create one or two images, the one I already created and
potentially another one customized for clustering.
I would pack this image, and tomcat and one of the artemis examples and
create a docker compose <https://docs.docker.com/compose/> image.
Then I would publish this as official image
<https://github.com/docker-library/official-images/tree/master/library> to
dockerhub (I imagine this is not easy bureocracy wise) just like rabbit,
ubuntu, wordpress, mariadb and others and I would create oficial
documentation along with the rest of the documentation.
If someone has a customized artemis instance that he wants to shift to
docker, he can just create a docker container from the official image and
mount there the etc directory.
This is just a personal oppinion, I but hope it helps.
2015-09-30 10:58 GMT-07:00 Clebert Suconic <cl...@gmail.com>:
> Sorry, it took me a while to digest this
>
> > What do you think? Would perhaps make more sense to have someting in a
> jar
> than can be invoked from bash/cmd?
>
>
> Maybe I'm getting confused because I would need more time with docker...
>
> We have the ./artemis create method, I would prefer to have things over
> there.. as it makes simpler and more accessible to users...
>
>
> If someone did anything around it, maybe we could then import it on the CLI
> to make it simpler...
>
> Maybe part of create wouldn't make sense.. but maybe a docker CLI... makes
> more sense maybe.
>
>
> ./artemis docker ... options...
>
>
> which is a simple thing to be implemented through OUR CLI package.
>
Re: [DISCUSS IDEA] artemis create --docker
Posted by "John D. Ament" <jo...@apache.org>.
That is awesome to hear. One thing to point out - the ASF already has a
docker hub account, so likely this image should reside under the ASF
https://hub.docker.com/r/apache/.
John
On Fri, Apr 8, 2016 at 12:17 AM Victor Romero <vi...@gmail.com>
wrote:
> Hi all,
> Apologies for resurrecting old thread.
>
> As result of our conversations here I published 6 months ago a docker image
> <https://hub.docker.com/r/vromero/activemq-artemis/> for Artemis 1.0, 1.1
> and 1.2 (as they were released).
>
> In this time there have been > 150 installations, 1 pull request, 1
> stackoverflow and no complains.
>
> I'd like to contribute it for an official artemis docker image, probably in
> the form of its own github repo (so I don't think a PR would be a fit) +
> bespoke documentation in the manual. I would be happy to maintain it just
> as I've been doing with the unofficial version.
>
> I'd love to hear if a separate repo is something acceptable, and any other
> opinions regarding this.
>
> Thanks
>
> El vie., 2 oct. 2015 a las 1:05, Claus Ibsen (<cl...@gmail.com>)
> escribió:
>
> > On Fri, Oct 2, 2015 at 10:01 AM, Andy Taylor <an...@gmail.com>
> > wrote:
> > > On 01/10/15 20:52, Victor Romero wrote:
> > >>>
> > >>> Actually you got that part wrong... There's a lot of customizations
> > being
> > >>> done as part of ./artemis create...
> > >>
> > >>
> > >>> For example, clustered, non clustered, HTTP PORT, ports, what users,
> > >>> security... and we can even add more options to it.
> > >>
> > >>
> > >> I see, the ones you mention are actually covered in my previous
> example:
> > >>
> > >> - clustered v non clustered would be two different images
> published
> > to
> > >> dockerhub.
> > >> - HTTP PORTS, ports. Ports configuration is irrelevant in docker,
> > >> given
> > >> that images are single process its unlikely there will be port
> > >> collision
> > >> and ports are then exported from the container to the docker host
> > with
> > >> -P
> > >> (that will use random ports) or -p that will use manually picked
> > >> ports.
> > >> - Users can be configured in place just as per my published
> example
> > >> <https://hub.docker.com/r/vromero/activemq-artemis/> (-e
> > >> ARTEMIS_USER=myuser -e ARTEMIS_PASSWORD=otherpassword).
> > >>
> > >> The rest you share in gist
> > >> <https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181> can be
> > >> definitely converted to parameters or considered complex configuration
> > to
> > >> be mounted (this is exactly what the nginx image
> > >> <https://hub.docker.com/_/nginx/> does for example).
> > >>
> > >> Summarizing:
> > >>
> > >>> What about this, we provide the official image with sensible
> > defaults...
> > >>
> > >>
> > >> Agree at 100% with this. It might be one or perhaps two depending
> how
> > >> clean is configure clustering with docker params.
> > >>
> > >>> and have a --docker option on artemis create to extend the image like
> > you
> > >>
> > >> said?
> > >>
> > >> Here I'm just in doubt, Artemis would be the first one doing
> > something
> > >> like this (and therefor users won't even expect it) plus it might fall
> > in
> > >> a
> > >> gray area between using the standard image with perhaps one or to
> > >> parameters and using the standard image mounting the etc directory
> with
> > >> complex configuration. Effectively it would be promoting the creation
> of
> > >> an
> > >> image per every possible configuration rather than a single
> configurable
> > >> image, and that would be against the docker philosophy itself.
> > >>
> > >> But again, I don't really know, I'd love to hear other opinions.
> > >
> > > I agree, I dont think we need a --docker option, I think we should
> > provide
> > > some official docker images that have a basic amount of configuration
> > > options and the option to mount external configuration. People can
> extend
> > > these images if they need to add anything further.
> > >
> >
> > +1 for official docker image and have it configurable using ENV
> > variables and/or other ways.
> >
> >
> >
> > >>
> > >>
> > >> 2015-10-01 6:48 GMT-07:00 Clebert Suconic <clebert.suconic@gmail.com
> >:
> > >>
> > >>> What about this, we provide the official image with sensible
> > defaults...
> > >>>
> > >>> and have a --docker option on artemis create to extend the image like
> > you
> > >>> said?
> > >>>
> > >>>
> > >>> the user would just download the image...
> > >>>
> > >>> /artemis create --docker <image-name> could then extend the image by
> > >>> externalizing the configuration? ... we could create scripts to start
> > the
> > >>> image with the external configurations..
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> Would that make sense?
> > >>>
> > >>> On Thu, Oct 1, 2015 at 9:23 AM, Andy Taylor <an...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> I don't see the point of having lots of different images and passing
> > in
> > >>>> variables to add to the configuration can also get a bit clunky.
> > >>>>
> > >>>> I would have 1 or 2 images maybe standalone and clustered and allow
> > the
> > >>>> configuration files location to be passed in when the image is run,
> > >>>> something like
> > >>>>
> > >>>> docker run --name my-artemis -e ARTEMIS_CONF=somewhere else
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 01/10/15 14:00, Clebert Suconic wrote:
> > >>>>
> > >>>>> These are the options that can be part of a create:
> > >>>>>
> > >>>>> https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181
> > >>>>>
> > >>>>> On Thu, Oct 1, 2015 at 8:58 AM, Clebert Suconic <
> > >>>>> clebert.suconic@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>> I'm afraid I kind of disagree with you in believeing there is value
> > on
> > >>>>>>
> > >>>>>>
> > >>>>>> the artemis
> > >>>>>>>
> > >>>>>>> create phase. There is very little customization at that point
> and
> > >>>
> > >>> very
> > >>>>>>>
> > >>>>>>> little to no value at all would be added by generating a docker
> > image
> > >>>
> > >>> at
> > >>>>>>>
> > >>>>>>> this phase, i.e: Why not just have an official docker image
> > published
> > >>>
> > >>> in
> > >>>>>>>
> > >>>>>>> dockerhub that would have the very same effect with much less
> > tooling
> > >>>>>>> and
> > >>>>>>> non standard procedures involved?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>> Actually you got that part wrong... There's a lot of
> customizations
> > >>>
> > >>> being
> > >>>>>>
> > >>>>>> done as part of ./artemis create...
> > >>>>>>
> > >>>>>> For example, clustered, non clustered, HTTP PORT, ports, what
> users,
> > >>>>>> security... and we can even add more options to it.
> > >>>>>>
> > >>>>>> So, adding a --docker would allow users to create a very
> customized
> > >>>>>> version of a docker instance. And the maven plugins we created as
> > part
> > >>>
> > >>> of
> > >>>>>>
> > >>>>>> the examples on 1.1.0 would get all the benefit of such a new
> > feature.
> > >>>>>>
> > >>>>>>
> > >>>>>> *What about creating an image of an already customized instance?*
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> you could have a lot of customizations..
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>> Personally I would create one or two images, the one I already
> > >>>>>>> created
> > >>>>>>> and
> > >>>>>>> potentially another one customized for clustering.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> I don't think it would be just one or two
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> Clebert Suconic
> > >>>
> > >>
> > >
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2nd edition:
> > https://www.manning.com/books/camel-in-action-second-edition
> >
>
Re: [DISCUSS IDEA] artemis create --docker
Posted by Victor Romero <vi...@gmail.com>.
Hi all,
Apologies for resurrecting old thread.
As result of our conversations here I published 6 months ago a docker image
<https://hub.docker.com/r/vromero/activemq-artemis/> for Artemis 1.0, 1.1
and 1.2 (as they were released).
In this time there have been > 150 installations, 1 pull request, 1
stackoverflow and no complains.
I'd like to contribute it for an official artemis docker image, probably in
the form of its own github repo (so I don't think a PR would be a fit) +
bespoke documentation in the manual. I would be happy to maintain it just
as I've been doing with the unofficial version.
I'd love to hear if a separate repo is something acceptable, and any other
opinions regarding this.
Thanks
El vie., 2 oct. 2015 a las 1:05, Claus Ibsen (<cl...@gmail.com>)
escribió:
> On Fri, Oct 2, 2015 at 10:01 AM, Andy Taylor <an...@gmail.com>
> wrote:
> > On 01/10/15 20:52, Victor Romero wrote:
> >>>
> >>> Actually you got that part wrong... There's a lot of customizations
> being
> >>> done as part of ./artemis create...
> >>
> >>
> >>> For example, clustered, non clustered, HTTP PORT, ports, what users,
> >>> security... and we can even add more options to it.
> >>
> >>
> >> I see, the ones you mention are actually covered in my previous example:
> >>
> >> - clustered v non clustered would be two different images published
> to
> >> dockerhub.
> >> - HTTP PORTS, ports. Ports configuration is irrelevant in docker,
> >> given
> >> that images are single process its unlikely there will be port
> >> collision
> >> and ports are then exported from the container to the docker host
> with
> >> -P
> >> (that will use random ports) or -p that will use manually picked
> >> ports.
> >> - Users can be configured in place just as per my published example
> >> <https://hub.docker.com/r/vromero/activemq-artemis/> (-e
> >> ARTEMIS_USER=myuser -e ARTEMIS_PASSWORD=otherpassword).
> >>
> >> The rest you share in gist
> >> <https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181> can be
> >> definitely converted to parameters or considered complex configuration
> to
> >> be mounted (this is exactly what the nginx image
> >> <https://hub.docker.com/_/nginx/> does for example).
> >>
> >> Summarizing:
> >>
> >>> What about this, we provide the official image with sensible
> defaults...
> >>
> >>
> >> Agree at 100% with this. It might be one or perhaps two depending how
> >> clean is configure clustering with docker params.
> >>
> >>> and have a --docker option on artemis create to extend the image like
> you
> >>
> >> said?
> >>
> >> Here I'm just in doubt, Artemis would be the first one doing
> something
> >> like this (and therefor users won't even expect it) plus it might fall
> in
> >> a
> >> gray area between using the standard image with perhaps one or to
> >> parameters and using the standard image mounting the etc directory with
> >> complex configuration. Effectively it would be promoting the creation of
> >> an
> >> image per every possible configuration rather than a single configurable
> >> image, and that would be against the docker philosophy itself.
> >>
> >> But again, I don't really know, I'd love to hear other opinions.
> >
> > I agree, I dont think we need a --docker option, I think we should
> provide
> > some official docker images that have a basic amount of configuration
> > options and the option to mount external configuration. People can extend
> > these images if they need to add anything further.
> >
>
> +1 for official docker image and have it configurable using ENV
> variables and/or other ways.
>
>
>
> >>
> >>
> >> 2015-10-01 6:48 GMT-07:00 Clebert Suconic <cl...@gmail.com>:
> >>
> >>> What about this, we provide the official image with sensible
> defaults...
> >>>
> >>> and have a --docker option on artemis create to extend the image like
> you
> >>> said?
> >>>
> >>>
> >>> the user would just download the image...
> >>>
> >>> /artemis create --docker <image-name> could then extend the image by
> >>> externalizing the configuration? ... we could create scripts to start
> the
> >>> image with the external configurations..
> >>>
> >>>
> >>>
> >>>
> >>> Would that make sense?
> >>>
> >>> On Thu, Oct 1, 2015 at 9:23 AM, Andy Taylor <an...@gmail.com>
> >>> wrote:
> >>>
> >>>> I don't see the point of having lots of different images and passing
> in
> >>>> variables to add to the configuration can also get a bit clunky.
> >>>>
> >>>> I would have 1 or 2 images maybe standalone and clustered and allow
> the
> >>>> configuration files location to be passed in when the image is run,
> >>>> something like
> >>>>
> >>>> docker run --name my-artemis -e ARTEMIS_CONF=somewhere else
> >>>>
> >>>>
> >>>>
> >>>> On 01/10/15 14:00, Clebert Suconic wrote:
> >>>>
> >>>>> These are the options that can be part of a create:
> >>>>>
> >>>>> https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181
> >>>>>
> >>>>> On Thu, Oct 1, 2015 at 8:58 AM, Clebert Suconic <
> >>>>> clebert.suconic@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> I'm afraid I kind of disagree with you in believeing there is value
> on
> >>>>>>
> >>>>>>
> >>>>>> the artemis
> >>>>>>>
> >>>>>>> create phase. There is very little customization at that point and
> >>>
> >>> very
> >>>>>>>
> >>>>>>> little to no value at all would be added by generating a docker
> image
> >>>
> >>> at
> >>>>>>>
> >>>>>>> this phase, i.e: Why not just have an official docker image
> published
> >>>
> >>> in
> >>>>>>>
> >>>>>>> dockerhub that would have the very same effect with much less
> tooling
> >>>>>>> and
> >>>>>>> non standard procedures involved?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> Actually you got that part wrong... There's a lot of customizations
> >>>
> >>> being
> >>>>>>
> >>>>>> done as part of ./artemis create...
> >>>>>>
> >>>>>> For example, clustered, non clustered, HTTP PORT, ports, what users,
> >>>>>> security... and we can even add more options to it.
> >>>>>>
> >>>>>> So, adding a --docker would allow users to create a very customized
> >>>>>> version of a docker instance. And the maven plugins we created as
> part
> >>>
> >>> of
> >>>>>>
> >>>>>> the examples on 1.1.0 would get all the benefit of such a new
> feature.
> >>>>>>
> >>>>>>
> >>>>>> *What about creating an image of an already customized instance?*
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> you could have a lot of customizations..
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Personally I would create one or two images, the one I already
> >>>>>>> created
> >>>>>>> and
> >>>>>>> potentially another one customized for clustering.
> >>>>>>>
> >>>>>>>
> >>>>>>> I don't think it would be just one or two
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Clebert Suconic
> >>>
> >>
> >
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2nd edition:
> https://www.manning.com/books/camel-in-action-second-edition
>
Re: [DISCUSS IDEA] artemis create --docker
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Oct 2, 2015 at 10:01 AM, Andy Taylor <an...@gmail.com> wrote:
> On 01/10/15 20:52, Victor Romero wrote:
>>>
>>> Actually you got that part wrong... There's a lot of customizations being
>>> done as part of ./artemis create...
>>
>>
>>> For example, clustered, non clustered, HTTP PORT, ports, what users,
>>> security... and we can even add more options to it.
>>
>>
>> I see, the ones you mention are actually covered in my previous example:
>>
>> - clustered v non clustered would be two different images published to
>> dockerhub.
>> - HTTP PORTS, ports. Ports configuration is irrelevant in docker,
>> given
>> that images are single process its unlikely there will be port
>> collision
>> and ports are then exported from the container to the docker host with
>> -P
>> (that will use random ports) or -p that will use manually picked
>> ports.
>> - Users can be configured in place just as per my published example
>> <https://hub.docker.com/r/vromero/activemq-artemis/> (-e
>> ARTEMIS_USER=myuser -e ARTEMIS_PASSWORD=otherpassword).
>>
>> The rest you share in gist
>> <https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181> can be
>> definitely converted to parameters or considered complex configuration to
>> be mounted (this is exactly what the nginx image
>> <https://hub.docker.com/_/nginx/> does for example).
>>
>> Summarizing:
>>
>>> What about this, we provide the official image with sensible defaults...
>>
>>
>> Agree at 100% with this. It might be one or perhaps two depending how
>> clean is configure clustering with docker params.
>>
>>> and have a --docker option on artemis create to extend the image like you
>>
>> said?
>>
>> Here I'm just in doubt, Artemis would be the first one doing something
>> like this (and therefor users won't even expect it) plus it might fall in
>> a
>> gray area between using the standard image with perhaps one or to
>> parameters and using the standard image mounting the etc directory with
>> complex configuration. Effectively it would be promoting the creation of
>> an
>> image per every possible configuration rather than a single configurable
>> image, and that would be against the docker philosophy itself.
>>
>> But again, I don't really know, I'd love to hear other opinions.
>
> I agree, I dont think we need a --docker option, I think we should provide
> some official docker images that have a basic amount of configuration
> options and the option to mount external configuration. People can extend
> these images if they need to add anything further.
>
+1 for official docker image and have it configurable using ENV
variables and/or other ways.
>>
>>
>> 2015-10-01 6:48 GMT-07:00 Clebert Suconic <cl...@gmail.com>:
>>
>>> What about this, we provide the official image with sensible defaults...
>>>
>>> and have a --docker option on artemis create to extend the image like you
>>> said?
>>>
>>>
>>> the user would just download the image...
>>>
>>> /artemis create --docker <image-name> could then extend the image by
>>> externalizing the configuration? ... we could create scripts to start the
>>> image with the external configurations..
>>>
>>>
>>>
>>>
>>> Would that make sense?
>>>
>>> On Thu, Oct 1, 2015 at 9:23 AM, Andy Taylor <an...@gmail.com>
>>> wrote:
>>>
>>>> I don't see the point of having lots of different images and passing in
>>>> variables to add to the configuration can also get a bit clunky.
>>>>
>>>> I would have 1 or 2 images maybe standalone and clustered and allow the
>>>> configuration files location to be passed in when the image is run,
>>>> something like
>>>>
>>>> docker run --name my-artemis -e ARTEMIS_CONF=somewhere else
>>>>
>>>>
>>>>
>>>> On 01/10/15 14:00, Clebert Suconic wrote:
>>>>
>>>>> These are the options that can be part of a create:
>>>>>
>>>>> https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181
>>>>>
>>>>> On Thu, Oct 1, 2015 at 8:58 AM, Clebert Suconic <
>>>>> clebert.suconic@gmail.com>
>>>>> wrote:
>>>>>
>>>>> I'm afraid I kind of disagree with you in believeing there is value on
>>>>>>
>>>>>>
>>>>>> the artemis
>>>>>>>
>>>>>>> create phase. There is very little customization at that point and
>>>
>>> very
>>>>>>>
>>>>>>> little to no value at all would be added by generating a docker image
>>>
>>> at
>>>>>>>
>>>>>>> this phase, i.e: Why not just have an official docker image published
>>>
>>> in
>>>>>>>
>>>>>>> dockerhub that would have the very same effect with much less tooling
>>>>>>> and
>>>>>>> non standard procedures involved?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Actually you got that part wrong... There's a lot of customizations
>>>
>>> being
>>>>>>
>>>>>> done as part of ./artemis create...
>>>>>>
>>>>>> For example, clustered, non clustered, HTTP PORT, ports, what users,
>>>>>> security... and we can even add more options to it.
>>>>>>
>>>>>> So, adding a --docker would allow users to create a very customized
>>>>>> version of a docker instance. And the maven plugins we created as part
>>>
>>> of
>>>>>>
>>>>>> the examples on 1.1.0 would get all the benefit of such a new feature.
>>>>>>
>>>>>>
>>>>>> *What about creating an image of an already customized instance?*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> you could have a lot of customizations..
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Personally I would create one or two images, the one I already
>>>>>>> created
>>>>>>> and
>>>>>>> potentially another one customized for clustering.
>>>>>>>
>>>>>>>
>>>>>>> I don't think it would be just one or two
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Clebert Suconic
>>>
>>
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2nd edition:
https://www.manning.com/books/camel-in-action-second-edition
Re: [DISCUSS IDEA] artemis create --docker
Posted by Andy Taylor <an...@gmail.com>.
On 01/10/15 20:52, Victor Romero wrote:
>> Actually you got that part wrong... There's a lot of customizations being
>> done as part of ./artemis create...
>
>> For example, clustered, non clustered, HTTP PORT, ports, what users,
>> security... and we can even add more options to it.
>
> I see, the ones you mention are actually covered in my previous example:
>
> - clustered v non clustered would be two different images published to
> dockerhub.
> - HTTP PORTS, ports. Ports configuration is irrelevant in docker, given
> that images are single process its unlikely there will be port collision
> and ports are then exported from the container to the docker host with -P
> (that will use random ports) or -p that will use manually picked ports.
> - Users can be configured in place just as per my published example
> <https://hub.docker.com/r/vromero/activemq-artemis/> (-e
> ARTEMIS_USER=myuser -e ARTEMIS_PASSWORD=otherpassword).
>
> The rest you share in gist
> <https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181> can be
> definitely converted to parameters or considered complex configuration to
> be mounted (this is exactly what the nginx image
> <https://hub.docker.com/_/nginx/> does for example).
>
> Summarizing:
>
>> What about this, we provide the official image with sensible defaults...
>
> Agree at 100% with this. It might be one or perhaps two depending how
> clean is configure clustering with docker params.
>
>> and have a --docker option on artemis create to extend the image like you
> said?
>
> Here I'm just in doubt, Artemis would be the first one doing something
> like this (and therefor users won't even expect it) plus it might fall in a
> gray area between using the standard image with perhaps one or to
> parameters and using the standard image mounting the etc directory with
> complex configuration. Effectively it would be promoting the creation of an
> image per every possible configuration rather than a single configurable
> image, and that would be against the docker philosophy itself.
>
> But again, I don't really know, I'd love to hear other opinions.
I agree, I dont think we need a --docker option, I think we should
provide some official docker images that have a basic amount of
configuration options and the option to mount external configuration.
People can extend these images if they need to add anything further.
>
>
> 2015-10-01 6:48 GMT-07:00 Clebert Suconic <cl...@gmail.com>:
>
>> What about this, we provide the official image with sensible defaults...
>>
>> and have a --docker option on artemis create to extend the image like you
>> said?
>>
>>
>> the user would just download the image...
>>
>> /artemis create --docker <image-name> could then extend the image by
>> externalizing the configuration? ... we could create scripts to start the
>> image with the external configurations..
>>
>>
>>
>>
>> Would that make sense?
>>
>> On Thu, Oct 1, 2015 at 9:23 AM, Andy Taylor <an...@gmail.com>
>> wrote:
>>
>>> I don't see the point of having lots of different images and passing in
>>> variables to add to the configuration can also get a bit clunky.
>>>
>>> I would have 1 or 2 images maybe standalone and clustered and allow the
>>> configuration files location to be passed in when the image is run,
>>> something like
>>>
>>> docker run --name my-artemis -e ARTEMIS_CONF=somewhere else
>>>
>>>
>>>
>>> On 01/10/15 14:00, Clebert Suconic wrote:
>>>
>>>> These are the options that can be part of a create:
>>>>
>>>> https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181
>>>>
>>>> On Thu, Oct 1, 2015 at 8:58 AM, Clebert Suconic <
>>>> clebert.suconic@gmail.com>
>>>> wrote:
>>>>
>>>> I'm afraid I kind of disagree with you in believeing there is value on
>>>>>
>>>>> the artemis
>>>>>> create phase. There is very little customization at that point and
>> very
>>>>>> little to no value at all would be added by generating a docker image
>> at
>>>>>> this phase, i.e: Why not just have an official docker image published
>> in
>>>>>> dockerhub that would have the very same effect with much less tooling
>>>>>> and
>>>>>> non standard procedures involved?
>>>>>>
>>>>>>
>>>>>>
>>>>> Actually you got that part wrong... There's a lot of customizations
>> being
>>>>> done as part of ./artemis create...
>>>>>
>>>>> For example, clustered, non clustered, HTTP PORT, ports, what users,
>>>>> security... and we can even add more options to it.
>>>>>
>>>>> So, adding a --docker would allow users to create a very customized
>>>>> version of a docker instance. And the maven plugins we created as part
>> of
>>>>> the examples on 1.1.0 would get all the benefit of such a new feature.
>>>>>
>>>>>
>>>>> *What about creating an image of an already customized instance?*
>>>>>>
>>>>>>
>>>>>> you could have a lot of customizations..
>>>>>
>>>>>
>>>>>> Personally I would create one or two images, the one I already created
>>>>>> and
>>>>>> potentially another one customized for clustering.
>>>>>>
>>>>>>
>>>>>> I don't think it would be just one or two
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Clebert Suconic
>>
>
Re: [DISCUSS IDEA] artemis create --docker
Posted by Victor Romero <vi...@gmail.com>.
> Actually you got that part wrong... There's a lot of customizations being
> done as part of ./artemis create...
>For example, clustered, non clustered, HTTP PORT, ports, what users,
>security... and we can even add more options to it.
I see, the ones you mention are actually covered in my previous example:
- clustered v non clustered would be two different images published to
dockerhub.
- HTTP PORTS, ports. Ports configuration is irrelevant in docker, given
that images are single process its unlikely there will be port collision
and ports are then exported from the container to the docker host with -P
(that will use random ports) or -p that will use manually picked ports.
- Users can be configured in place just as per my published example
<https://hub.docker.com/r/vromero/activemq-artemis/> (-e
ARTEMIS_USER=myuser -e ARTEMIS_PASSWORD=otherpassword).
The rest you share in gist
<https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181> can be
definitely converted to parameters or considered complex configuration to
be mounted (this is exactly what the nginx image
<https://hub.docker.com/_/nginx/> does for example).
Summarizing:
> What about this, we provide the official image with sensible defaults...
Agree at 100% with this. It might be one or perhaps two depending how
clean is configure clustering with docker params.
>and have a --docker option on artemis create to extend the image like you
said?
Here I'm just in doubt, Artemis would be the first one doing something
like this (and therefor users won't even expect it) plus it might fall in a
gray area between using the standard image with perhaps one or to
parameters and using the standard image mounting the etc directory with
complex configuration. Effectively it would be promoting the creation of an
image per every possible configuration rather than a single configurable
image, and that would be against the docker philosophy itself.
But again, I don't really know, I'd love to hear other opinions.
2015-10-01 6:48 GMT-07:00 Clebert Suconic <cl...@gmail.com>:
> What about this, we provide the official image with sensible defaults...
>
> and have a --docker option on artemis create to extend the image like you
> said?
>
>
> the user would just download the image...
>
> /artemis create --docker <image-name> could then extend the image by
> externalizing the configuration? ... we could create scripts to start the
> image with the external configurations..
>
>
>
>
> Would that make sense?
>
> On Thu, Oct 1, 2015 at 9:23 AM, Andy Taylor <an...@gmail.com>
> wrote:
>
> > I don't see the point of having lots of different images and passing in
> > variables to add to the configuration can also get a bit clunky.
> >
> > I would have 1 or 2 images maybe standalone and clustered and allow the
> > configuration files location to be passed in when the image is run,
> > something like
> >
> > docker run --name my-artemis -e ARTEMIS_CONF=somewhere else
> >
> >
> >
> > On 01/10/15 14:00, Clebert Suconic wrote:
> >
> >> These are the options that can be part of a create:
> >>
> >> https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181
> >>
> >> On Thu, Oct 1, 2015 at 8:58 AM, Clebert Suconic <
> >> clebert.suconic@gmail.com>
> >> wrote:
> >>
> >> I'm afraid I kind of disagree with you in believeing there is value on
> >>>
> >>> the artemis
> >>>> create phase. There is very little customization at that point and
> very
> >>>> little to no value at all would be added by generating a docker image
> at
> >>>> this phase, i.e: Why not just have an official docker image published
> in
> >>>> dockerhub that would have the very same effect with much less tooling
> >>>> and
> >>>> non standard procedures involved?
> >>>>
> >>>>
> >>>>
> >>> Actually you got that part wrong... There's a lot of customizations
> being
> >>> done as part of ./artemis create...
> >>>
> >>> For example, clustered, non clustered, HTTP PORT, ports, what users,
> >>> security... and we can even add more options to it.
> >>>
> >>> So, adding a --docker would allow users to create a very customized
> >>> version of a docker instance. And the maven plugins we created as part
> of
> >>> the examples on 1.1.0 would get all the benefit of such a new feature.
> >>>
> >>>
> >>> *What about creating an image of an already customized instance?*
> >>>>
> >>>>
> >>>> you could have a lot of customizations..
> >>>
> >>>
> >>>> Personally I would create one or two images, the one I already created
> >>>> and
> >>>> potentially another one customized for clustering.
> >>>>
> >>>>
> >>>> I don't think it would be just one or two
> >>>
> >>>
> >>
> >>
> >>
> >
>
>
> --
> Clebert Suconic
>
Re: [DISCUSS IDEA] artemis create --docker
Posted by Clebert Suconic <cl...@gmail.com>.
What about this, we provide the official image with sensible defaults...
and have a --docker option on artemis create to extend the image like you
said?
the user would just download the image...
/artemis create --docker <image-name> could then extend the image by
externalizing the configuration? ... we could create scripts to start the
image with the external configurations..
Would that make sense?
On Thu, Oct 1, 2015 at 9:23 AM, Andy Taylor <an...@gmail.com> wrote:
> I don't see the point of having lots of different images and passing in
> variables to add to the configuration can also get a bit clunky.
>
> I would have 1 or 2 images maybe standalone and clustered and allow the
> configuration files location to be passed in when the image is run,
> something like
>
> docker run --name my-artemis -e ARTEMIS_CONF=somewhere else
>
>
>
> On 01/10/15 14:00, Clebert Suconic wrote:
>
>> These are the options that can be part of a create:
>>
>> https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181
>>
>> On Thu, Oct 1, 2015 at 8:58 AM, Clebert Suconic <
>> clebert.suconic@gmail.com>
>> wrote:
>>
>> I'm afraid I kind of disagree with you in believeing there is value on
>>>
>>> the artemis
>>>> create phase. There is very little customization at that point and very
>>>> little to no value at all would be added by generating a docker image at
>>>> this phase, i.e: Why not just have an official docker image published in
>>>> dockerhub that would have the very same effect with much less tooling
>>>> and
>>>> non standard procedures involved?
>>>>
>>>>
>>>>
>>> Actually you got that part wrong... There's a lot of customizations being
>>> done as part of ./artemis create...
>>>
>>> For example, clustered, non clustered, HTTP PORT, ports, what users,
>>> security... and we can even add more options to it.
>>>
>>> So, adding a --docker would allow users to create a very customized
>>> version of a docker instance. And the maven plugins we created as part of
>>> the examples on 1.1.0 would get all the benefit of such a new feature.
>>>
>>>
>>> *What about creating an image of an already customized instance?*
>>>>
>>>>
>>>> you could have a lot of customizations..
>>>
>>>
>>>> Personally I would create one or two images, the one I already created
>>>> and
>>>> potentially another one customized for clustering.
>>>>
>>>>
>>>> I don't think it would be just one or two
>>>
>>>
>>
>>
>>
>
--
Clebert Suconic
Re: [DISCUSS IDEA] artemis create --docker
Posted by Andy Taylor <an...@gmail.com>.
I don't see the point of having lots of different images and passing in
variables to add to the configuration can also get a bit clunky.
I would have 1 or 2 images maybe standalone and clustered and allow the
configuration files location to be passed in when the image is run,
something like
docker run --name my-artemis -e ARTEMIS_CONF=somewhere else
On 01/10/15 14:00, Clebert Suconic wrote:
> These are the options that can be part of a create:
>
> https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181
>
> On Thu, Oct 1, 2015 at 8:58 AM, Clebert Suconic <cl...@gmail.com>
> wrote:
>
>> I'm afraid I kind of disagree with you in believeing there is value on
>>
>>> the artemis
>>> create phase. There is very little customization at that point and very
>>> little to no value at all would be added by generating a docker image at
>>> this phase, i.e: Why not just have an official docker image published in
>>> dockerhub that would have the very same effect with much less tooling and
>>> non standard procedures involved?
>>>
>>>
>>
>> Actually you got that part wrong... There's a lot of customizations being
>> done as part of ./artemis create...
>>
>> For example, clustered, non clustered, HTTP PORT, ports, what users,
>> security... and we can even add more options to it.
>>
>> So, adding a --docker would allow users to create a very customized
>> version of a docker instance. And the maven plugins we created as part of
>> the examples on 1.1.0 would get all the benefit of such a new feature.
>>
>>
>>> *What about creating an image of an already customized instance?*
>>>
>>>
>> you could have a lot of customizations..
>>
>>>
>>> Personally I would create one or two images, the one I already created and
>>> potentially another one customized for clustering.
>>>
>>>
>> I don't think it would be just one or two
>>
>
>
>
Re: [DISCUSS IDEA] artemis create --docker
Posted by Clebert Suconic <cl...@gmail.com>.
These are the options that can be part of a create:
https://gist.github.com/clebertsuconic/a4a7c02e3b71961ca181
On Thu, Oct 1, 2015 at 8:58 AM, Clebert Suconic <cl...@gmail.com>
wrote:
> I'm afraid I kind of disagree with you in believeing there is value on
>
>> the artemis
>> create phase. There is very little customization at that point and very
>> little to no value at all would be added by generating a docker image at
>> this phase, i.e: Why not just have an official docker image published in
>> dockerhub that would have the very same effect with much less tooling and
>> non standard procedures involved?
>>
>>
>
> Actually you got that part wrong... There's a lot of customizations being
> done as part of ./artemis create...
>
> For example, clustered, non clustered, HTTP PORT, ports, what users,
> security... and we can even add more options to it.
>
> So, adding a --docker would allow users to create a very customized
> version of a docker instance. And the maven plugins we created as part of
> the examples on 1.1.0 would get all the benefit of such a new feature.
>
>
>> *What about creating an image of an already customized instance?*
>>
>>
> you could have a lot of customizations..
>
>>
>> Personally I would create one or two images, the one I already created and
>> potentially another one customized for clustering.
>>
>>
> I don't think it would be just one or two
>
--
Clebert Suconic
Re: [DISCUSS IDEA] artemis create --docker
Posted by Clebert Suconic <cl...@gmail.com>.
I'm afraid I kind of disagree with you in believeing there is value on
> the artemis
> create phase. There is very little customization at that point and very
> little to no value at all would be added by generating a docker image at
> this phase, i.e: Why not just have an official docker image published in
> dockerhub that would have the very same effect with much less tooling and
> non standard procedures involved?
>
>
Actually you got that part wrong... There's a lot of customizations being
done as part of ./artemis create...
For example, clustered, non clustered, HTTP PORT, ports, what users,
security... and we can even add more options to it.
So, adding a --docker would allow users to create a very customized version
of a docker instance. And the maven plugins we created as part of the
examples on 1.1.0 would get all the benefit of such a new feature.
> *What about creating an image of an already customized instance?*
>
>
you could have a lot of customizations..
>
> Personally I would create one or two images, the one I already created and
> potentially another one customized for clustering.
>
>
I don't think it would be just one or two
Re: [DISCUSS IDEA] artemis create --docker
Posted by Hiram Chirino <hi...@hiramchirino.com>.
At best having a 'create --docker' command which customizes the
instance configuration to be more docker friendly might be as good as
it gets. For example 'create --docker' might create a config which
tries to read more settings from the env vars. It could also setup
logging so it all goes to std out instead of to files.
On Thu, Oct 1, 2015 at 1:23 AM, Victor Romero <vi...@gmail.com> wrote:
> Llet me try to clarify how docker works and which are its expectations:
>
> There are three outstanding moving pieces in docker:
>
> - *Docker container*, an instance of a docker image.
> - *Docker images* are *self contained images* of a piece of software,
> its dependencies, end everything else down to the operating system.
> - *DockerFiles*, the recipe to generate a docker image.
>
> Two important best practices
> <https://docs.docker.com/articles/dockerfile_best-practices/> regarding
> creation of containers are:
>
> - Containers should be ephemeral, it can be stopped and destroyed and a
> new one built and put in place with an absolute minimum of set-up and
> configuration.
> - Run only one process per container.
>
> Docker containers are customized tipically in two ways:
>
> - Changing some simple value, like the number of threads of a listener:
> with a passed environment property, i.e: -e HTTP_LISTENERS=64
> - Changing actual files/directories both for input/output from/to the
> image: with mounted volumes
> <https://docs.docker.com/userguide/dockervolumes/>. An example of out
> would be mounting a logs directory and an example for input, we could say,
> mounting the apps directory of tomcat, i.e: -v /webapp training/webapp
>
> There is a repository of docker images, similar to what maven central is
> for maven, and this is dockerhub <https://hub.docker.com/>. The docker
> command like has full support for it. Software providers can provide an
> official docker image just like in maven central. On example could be the
> official RabbitMQ <https://hub.docker.com/_/rabbitmq/> docker image that
> has been there for a while. Of course users do prefer official images but
> they tipically coexist with a bunch of other community images.
>
> If we don't go creative, the tipical case for a docker image is just an
> image that allows configuration to some extent using environment properties
> and some volumes mounted. This is exactly what I tried to accomplish the
> image <https://hub.docker.com/r/vromero/activemq-artemis/> I recently
> uploaded to dockerhub.
>
> *All this said, is there space for improvement?*
>
> I'm afraid I kind of disagree with you in believeing there is value on
> the artemis
> create phase. There is very little customization at that point and very
> little to no value at all would be added by generating a docker image at
> this phase, i.e: Why not just have an official docker image published in
> dockerhub that would have the very same effect with much less tooling and
> non standard procedures involved?
>
> *What about creating an image of an already customized instance?*
>
> This would be having a base docker image all ready except for the artemis
> intance, and then create an image with the instance on top of it.
>
> I think there is some value on this but to be completely honest, this goes
> against the common use of docker. The software and the very basic
> configuration tipically reside on the image, and the hard core
> configuration comes in the form of a mount point.
>
> I'm on the fence around this one, perhaps there is some value, but at this
> point I would rather say that it's better to not to go against the flow and
> do something that is considered incorrect by the docker community.
>
> *What would I personally do (docker related) with artemis:*
>
> Personally I would create one or two images, the one I already created and
> potentially another one customized for clustering.
>
> I would pack this image, and tomcat and one of the artemis examples and
> create a docker compose <https://docs.docker.com/compose/> image.
>
> Then I would publish this as official image
> <https://github.com/docker-library/official-images/tree/master/library> to
> dockerhub (I imagine this is not easy bureocracy wise) just like rabbit,
> ubuntu, wordpress, mariadb and others and I would create oficial
> documentation along with the rest of the documentation.
>
> If someone has a customized artemis instance that he wants to shift to
> docker, he can just create a docker container from the official image and
> mount there the etc directory.
>
> This is just a personal oppinion, I but hope it helps.
>
>
>
>
>
>
>
>
> 2015-09-30 10:58 GMT-07:00 Clebert Suconic <cl...@gmail.com>:
>
>> Sorry, it took me a while to digest this
>>
>> > What do you think? Would perhaps make more sense to have someting in a
>> jar
>> than can be invoked from bash/cmd?
>>
>>
>> Maybe I'm getting confused because I would need more time with docker...
>>
>> We have the ./artemis create method, I would prefer to have things over
>> there.. as it makes simpler and more accessible to users...
>>
>>
>> If someone did anything around it, maybe we could then import it on the CLI
>> to make it simpler...
>>
>> Maybe part of create wouldn't make sense.. but maybe a docker CLI... makes
>> more sense maybe.
>>
>>
>> ./artemis docker ... options...
>>
>>
>> which is a simple thing to be implemented through OUR CLI package.
>>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino