Update ece-architecture.md - Adding a container <-> ECE host role mapping table

[rseldner]

DRAFT Proposing we document the actual service container names with a brief description in a container<->ece host role mapping table. ece-architecture.md seems like an appropriate place for this. Kept it brief to limit redundancies from the sections above.

Preview: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/1369/deploy-manage/deploy/cloud-enterprise/ece-architecture

[jakommo]

LGTM, thanks for creating this @rseldner !

In general, I'd appreciate if someone from the docs team could go over this re terms used. I.e. cluster is used a few times, where I think deployment could be a better term to stay within ECE terminology ...

[jakommo]

Re terminology mentioned above, @eedugon your name was the first to come to mind, but feel free to assign someone else.

[eedugon]

great initiative! I'm totally ok with the change and giving a brief description of each container set.

Would it be ok if I double check with someone from development team or PM about the accuracy of the descriptions in the table? Just to ensure all looks good.

In the meantime @rseldner , it would be great if you review and commit the suggestions made by @jakommo and myself (of course if you agree with them).

[kunisen]

Sorry for the delay. Thanks @rseldner, LGTM from the content itself perspective.
I have some questions would like to have your opinion before we merge this.

Disclaimer: This is a public repo so I will redact internal info as much as possible.

[1]

What do we expect users to get from this content?

Motivation of the ask:

• This is super ECE internals, and most containers we don't have the way to tweak them via UI or APIs, and don't need to tweak them.
• If we expose this to public, then we may get questions around this part. I am unsure if it will cause more asks from customers than it can explain or solve.

I am not against exposing things, and I think it will bring some great transparency to the customer.
However, we are support engineers in front line, and I am a bit unsure how many of us (the team) understand this part and can answer questions if being asked by users.

[2]

Could we get buy-in / sign-off from dev for some tech details?
@przemek-grzedzielski could you kindly help check?

Since this is ECE internals, and we collect most of the info from our internal wiki, slack, GH tickets, it would be the best to have a dev friend to double check this.

[3]

We should also keep our terms and logic aligned.

a)
There's no role mentioned in this page earlier.
=> Should we add what's host role?

Motivation of the ask is: We also have RBAC via security cluster and can create different roles to manage platform and deployment. We should make it clear the difference between host roles and user roles.

b)
Term Controller, it's the correct term but other relevant terms are outdated, which makes it seems a bit isolated.
=> Could we update other part of the this doc page to make them up to date?

Motivation of the ask: We have some docs & terms discrepancies, which we probably should unified our terms.

• Previously Coordinator is a role for director and constructor (cf: doc link). Now it's renamed to Controller and only represent constructor, but not director. (I copied it from Omer's blog I linked. I might be wrong but actually I thought director was there forever, while coordinator contains constructor + admin console. Sorry I couldn't find the evidence quickly now)
• We still use Constructor term in doc. Should we replace it to Controller?
• We still use coordinator term in installer script. Should we replace it? (Probably no?)
• We specially mention The role Controller in the admin console is called coordinator in this doc (link)

I had that in my mind, but due to it's a bit tricky as it's both in docs and installer script, I never got the chance to tackle this in reality.
@przemek-grzedzielski could you kindly guide us that, how could we update the doc page please?
I feel we probably could add the host role section to make it clear. Also mention that control plane services ≠ host roles.

c)
Personal preference @rseldner
=> do you think it makes more sense to group by Roles instead of alphabet order?

Motivation of the ask:
All service containers start with frc- which makes me feel alphabet order is not very evident, while I see host roles is in a random order (but actually it's because containers name is in alphabet order).

---

Thanks!

[rseldner]

Thanks for the feedback so far all 🙇

👋 @kunisen ...

[1]

The same containers are already publicly documented here since 3.7:

• Current: https://www.elastic.co/docs/troubleshoot/deployments/cloud-enterprise/troubleshooting-container-engines#ece-troubleshooting-containers-unhealthy-restart
• 3.7: https://www.elastic.co/guide/en/cloud-enterprise/3.7/ece-troubleshooting-containers.html

And I think ECE admins should be aware of the containers that exist in their environment and that ECE relies on even if at a basic level. It would be particularly useful to know which containers are expected to run on each host type for admins to know if something might be amiss when looking at list of running containers.

[2]

Agreed on getting cloud devs' blessing. Thank you!

[3]

A
Regarding the roles, that page jumps from the "Service-oriented architecture" to basically discussion of the roles. Though it does not explicitly mention the term "role" it pretty much checks all the boxes.

• ✔️ Control Plane
  • ✔️ Director
  • ✔️ Constructor (perhaps rename)
• ✔️ Proxies
• ✔️ Allocator

Maybe there is a better place for all of this? The page I picked seemed fitting to me based on the reason above.

B
Wouldn't hurt to align the rest of the documentation but the terms are a bit all over the place as you mention 😅

C
Agreed on the suggestion. Grouping first by roles instead makes sense to me.

[kunisen]

Thank you so much Roberto! All makes great sense!
Hope @przemek-grzedzielski could help us review as this is really an important update and please let us know if anything it not clear.

Przemek, I posted some details in an earlier comment - #1369 (comment), thanks!

[eedugon]

I don't think the list of container sets should be considered too low level or ECE internals when we have public docs that already mention some of them when providing commands.

We could have this info in a KB and not make it visible in the public docs, but having a good reference between the ECE host roles and the expected containers is great in my opinion, except if we plan to change that very often and we don't want users to have clear expectations in terms of what to expect when they run docker / podman ps.

[jakommo]

I don't think the list of container sets should be considered too low level or ECE internals

Full ack. For folks administering ECE environments this is very useful info and belongs in the public docs