Future Elasticsearch Image plans

[mleklund]

Wondered if there was a plan to handle the fact that the pires/docker-elasticsearch-kubernetes repo is abandoware at this point.

[while1eq1]

I built my own here that I shared that supports ES 6.3+

https://github.com/while1eq1/elasticsearch-kubernetes-searchguard

[pieterlange]

What makes you say pires/docker-elasticsearch-kubernetes is deprecated? Seems supported to me.

Nevermind, just read the deprecation notice. Packaging maintenance has been fairly light, i'm sure the community (we?) can pick this up.

[karlskewes]

I forked @while1eq1 repo above for my use and haven't made any major changes yet. Thanks very much for your work there.

I think we should adopt it for this repo as it works well and reduces the number of FROM statements.

[while1eq1]

Also the pires one wouldnt work with this operator if the ES version was 6.3+ as the SearchGuard SSL standalone plugin was rolled into mainline SearchGuard and doesnt support anything after ES 6.2.

This required changes such as initializing searchguard at runtime and adding all the sgconfigs.

Also, to use my ES repo with this you need to build the elasticsearch-operator from master branch

[mleklund]

Also, with the open sourcing of xpack, should consideration be given to basing the image on the upstream projects docker image? Docker hub's "official" image is based on elastic.co's image now. There are size considerations of an alpine based image vs another platform, but it could pay off in stability as elastic's image likely gets a large amount of testing.

[pieterlange]

xpack isn't "true" open source though (elastic license), as we've discussed in another issue here or in pires' repo so i'm not sure about packaging that.

I tried building my own ES 6.1.3 image with a recent searchguard a couple of months ago but also ran into some upgrading issues due to the searchguard support model changing. Ran out of my timebox and didn't have time yet to look back.
This is a really useful project and i've used it a lot personally, it would make sense for us to all ask for some company time to contribute to maintaining it. Getting us over this searchguard/xpack hurdle being one of the first bigger things to cover since its a blocker for a normal upgrade path at the moment.

If anyone is up for spending some time on this, specifically on maintaining the discovery plugin and related docker image, ping me on slack @gianrubio @while1eq1 @komljen @mumoshu @skokovic

[stevesloka]

I think we should rally around @while1eq1's image. Do you want to make that a thing @while1eq1?

I also might see about moving this to a generic org/repo. Would be nice to have all the code in one place (e.g. operator, cron, image, etc)

[while1eq1]

@stevesloka Yes, Id be 100% down for that, lets make it happen.

[skokovic]

@pieterlange I'm up for it, don't know what slack you're referring to though.

[dimm0]

Is it gonna happen?
(he's referring to https://slack.com messenger)

[while1eq1]

Yes but which slack team/server/channel do we wanna meet up on?

[dimm0]

Ah.. I see :) no idea.

[mleklund]

https://www.elastic.co/blog/security-for-elasticsearch-is-now-free

[stevesloka]

Yeah I saw that @mleklund, the question now is should this operator exist now that elastic has an official one?

[while1eq1]

Once the official one is tested and known to provide all the needed features id imagine the answer would be no. What is your thoughts?

…

On Tue, May 21, 2019 at 10:00 AM Steve Sloka ***@***.***> wrote: Yeah I saw that @mleklund <https://github.com/mleklund>, the question now is should this operator exist now that elastic has an official one? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#276?email_source=notifications&email_token=AATPVQVAUTW63SML5ZKKZ7DPWP6AJA5CNFSM4GOZUIO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV4ACUY#issuecomment-494403923>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AATPVQUXVRH3DHHMSPWTPP3PWP6AJANCNFSM4GOZUIOQ> .

[stevesloka]

That's my thinking, but need to investigate the current solution to verify features. I don't think it makes sense to invest in multiple solutions that accomplish the same thing and given there's a vendor solution, I think it makes sense to move to that.

[komljen]

Zalando team have their own ES operator, but it seems the main focus is on scaling https://github.com/zalando-incubator/es-operator. Of course, it would be great if we have only one operator to rule them all, but I don't see that happen anytime soon.

[komljen]

I also might see about moving this to a generic org/repo. Would be nice to have all the code in one place (e.g. operator, cron, image, etc)

@stevesloka any updates on this?

[kfox1111]

https://www.elastic.co/blog/security-for-elasticsearch-is-now-free

Free but not open. Its in the basic tier, not the open source tier.

The open distro folks seem to be maintaining images too. maybe those would work?
https://hub.docker.com/r/amazon/opendistro-for-elasticsearch

[dimm0]

I tried installing the official one, never worked for me... Still using yours

[komljen]

The open distro folks seem to be maintaining images too. maybe those would work?

It works with the operator with minor modifications, https://github.com/komljen/opendistro-for-elasticsearch-k8s

I removed the security plugin here.