Re: [Hawkular-dev] OpenShift Deployment

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