Re: [Hawkular-dev] OpenShift Deployment

+1 On Thu, Nov 30, 2017 at 2:56 PM, Matthew Wringe <mwringe(a)redhat.com&gt; wrote: > Yeah, I think we should go with the all-in-one pod approach for now. If > we discover certain use cases that wont work properly we can re-evaluate. > > On Thu, Nov 30, 2017 at 5:15 AM, Lucas Ponce <lponce(a)redhat.com&gt; wrote: > >> >> >> On Thu, Nov 30, 2017 at 10:55 AM, Lucas Ponce <lponce(a)redhat.com&gt; wrote: >> >>> >>> >>> On Mon, Nov 27, 2017 at 4:38 PM, Matthew Wringe <mwringe(a)redhat.com&gt; >>> wrote: >>> >>>> With the changes that are now going to include Prometheus, how do we >>>> want to deploy this in OpenShift? >>>> >>>> We can have a few options: >>>> >>>> ALL-IN-ONE CONTAINER >>>> We put both Hawkular Services and Prometheus in the same container. >>>> >>>> Pros: >>>> - easy to deploy in plain docker (but this doesn't appear to be a >>>> usecase we are targetting anyways) >>>> - shares the same network connection (even localhost) and ip address >>>> (eg but both services are on the different ports). >>>> - Does't require any special wiring of components. >>>> - Can share the same volume mount >>>> - version of components can't get out of sync. >>>> >>>> Cons: >>>> - workflow doesn't work nicely. Docker containers are meant to only >>>> run a single application and running two can cause problems. Eg lifecycle >>>> events would become tricky and require some hacks to get around things. >>>> - can't independently deploy things >>>> - can't reuse or share any existing Prometheus docker containers. >>>> >>>> ALL-IN-ONE POD >>>> Hawkular Services and Prometheus are in their own containers, but they >>>> are both deployed within the same pod. >>>> >>>> Pros: >>>> - shares the same network connection. >>>> - bound to the same machine (useful if sharing the same hostpath pv) >>>> and don' need to worry about external network configurations (eg firewalls >>>> between OpenShift nodes) >>>> - pvs can be shared or separate. >>>> - lifecycle events will work properly. >>>> >>>> Cons: >>>> - lifecycle hooks will mean that both containers will have to pass >>>> before either one will enter the ready state. So if Prometheus is failing >>>> for some reason, Hawkular Services will not be available under the service. >>>> - cannot independently update one container. If we need to deploy a >>>> new container we will need to bring down the whole pod. >>>> - are stuck with a 1:1 ratio between Hawkular Services and Prometheus >>>> >>>> >>> One technical requeriment is that Hawkular Services needs to now where >>> is Prometheus server at initialization. >>> >> >> One technical requeriment is that Hawkular Services needs to *know* >> where is Prometheus server at initialization. >> >> [Sorry, typing fast] >> >> So, I guess that all-in-one pod will simplify things on this case. >>> >>> I would start with this architecture first and harden the basic >>> scenarios. >>> >>> >>>> >>>> SEPARATE PODS >>>> Hawkular Services and Prometheus have their own separate pods. >>>> >>>> Pros: >>>> - can independently run components and each component has its own >>>> separate lifecycle >>>> - if in the future we want to cluster Hawkular Services. this will >>>> make it a lot easier and will also allow for running an n:m ratio between >>>> Hawkular Services and Prometheus >>>> - probably the more 'correct' way to deploy things as we don't have a >>>> strong requirement for Hawkular Services and Prometheus to run together. >>>> >>>> Cons: >>>> - more complex wiring. We will need to have extra services and routes >>>> created to handle this. This mean more things running and more chances for >>>> things to go wrong. Also more things to configure >>>> - reusing a PV between Hawkular Services and Prometheus could be more >>>> challenging (especially if we are using hostpath pvs). Updating the >>>> Prometheus scrape endpoint may require a new component and container. >>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>>> >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev