Isn’t an image per component really heavyweight?
From: Tom Barber <t...@spicule.co.uk> Date: Monday, October 15, 2018 at 8:26 AM To: Imesha Sudasingha <imesha...@cse.mrt.ac.lk> Cc: dev <dev@oodt.apache.org>, Chris Mattmann <mattm...@apache.org> Subject: Re: OODT docker builds Why aren’t we doing so?! :) Lack of cycles and young kids ;) I’ll take a stab at it and see where we get to outside of RADIX to get the stack in distinct containers and then we’ll look at integrating it into the main build then. Tom On 15 October 2018 at 13:07:56, Imesha Sudasingha (imesha...@cse.mrt.ac.lk) wrote: Yes. Agree with you. That is something I have been planning to ask you for long; why aren't we doing so. I like the idea of having a docker image per component and as you suggested we can create docker-compose or kubernetes setup for deployments. I like that direction ;-) As an starting point, we can add an all-in-one docker image to be built in the RADIX build, right? If you start off, I will be able to join you along the way. Thanks, Imesha On Mon, 15 Oct 2018 at 16:33, Tom Barber <t...@spicule.co.uk> wrote: I was thinking about the outputs. Currently everything is 1 docker file which is fine for some deployments and not for others. In the RADIX build we should also build individual containers for each component. For the deployment we could also have a docker-compose file and a K8S Helm setup so that you could deploy a distributed OODT setup from your RADIX output, this could also have the ZK stuff in it so we can properly utilise the distributed nature we started constructing with the FM ZK changes. On 15 October 2018 at 05:08:41, Imesha Sudasingha (imesha...@cse.mrt.ac.lk) wrote: Hi Tom, I think this will be great since people are adopting docker more and more and even for a user once they have built a customized docker image, they can share it among the peers reducing the time spent for configuration by each individual. Also we have another option ;-) With distributed configuration management which I implemented, users can ask OODT components to download configuration published in zookeeper. But this will require zookeeper to be running (either as a container or standalone). As per my understanding, configuration is the problem we need to solve when using a pre-built docker image? In future, if we are able to implement https://issues.apache.org/jira/browse/OODT-977 we will be able to run multiple file managers in multiple containers which will allow the load to be distributed and query all at once. So, docker will be the way to go as I see it. What do you think? Thanks, Imesha On Sun, 14 Oct 2018 at 15:40, Tom Barber <t...@spicule.co.uk> wrote: > I’m interested in the Dockerization of OODT but also conscious that most > people use RADIX to build their stuff, which make’s overriding bits of a > prebuilt image tricky. > > I’m wondering if its worth adding an optional Docker profile to RADIX to > add a Docker build step to the backend of people’s RADIX builds if they so > wanted. > > Thoughts? > > -- > > > Spicule Limited is registered in England & Wales. Company Number: > 09954122. Registered office: First Floor, Telecom House, 125-135 Preston > Road, Brighton, England, BN1 6AF. VAT No. 251478891. > > > > > All engagements > are subject to Spicule Terms and Conditions of Business. This email and > its > contents are intended solely for the individual to whom it is addressed > and > may contain information that is confidential, privileged or otherwise > protected from disclosure, distributing or copying. Any views or opinions > presented in this email are solely those of the author and do not > necessarily represent those of Spicule Limited. The company accepts no > liability for any damage caused by any virus transmitted by this email. If > you have received this message in error, please notify us immediately by > reply email before deleting it from your system. Service of legal notice > cannot be effected on Spicule Limited by email. > Spicule Limited is registered in England & Wales. Company Number: 09954122. Registered office: First Floor, Telecom House, 125-135 Preston Road, Brighton, England, BN1 6AF. VAT No. 251478891. All engagements are subject to Spicule Terms and Conditions of Business. This email and its contents are intended solely for the individual to whom it is addressed and may contain information that is confidential, privileged or otherwise protected from disclosure, distributing or copying. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Spicule Limited. The company accepts no liability for any damage caused by any virus transmitted by this email. If you have received this message in error, please notify us immediately by reply email before deleting it from your system. Service of legal notice cannot be effected on Spicule Limited by email. Spicule Limited is registered in England & Wales. Company Number: 09954122. Registered office: First Floor, Telecom House, 125-135 Preston Road, Brighton, England, BN1 6AF. VAT No. 251478891. All engagements are subject to Spicule Terms and Conditions of Business. This email and its contents are intended solely for the individual to whom it is addressed and may contain information that is confidential, privileged or otherwise protected from disclosure, distributing or copying. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Spicule Limited. The company accepts no liability for any damage caused by any virus transmitted by this email. If you have received this message in error, please notify us immediately by reply email before deleting it from your system. Service of legal notice cannot be effected on Spicule Limited by email.
