-
Notifications
You must be signed in to change notification settings - Fork 163
Update ece-architecture.md - Adding a container <-> ECE host role mapping table #1369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Proposing we document the actual service container names in a container-to-role mapping table
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ...
Re terminology mentioned above, @eedugon your name was the first to come to mind, but feel free to assign someone else. |
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 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). |
Sorry for the delay. Thanks @rseldner, LGTM from the content itself perspective. 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:
I am not against exposing things, and I think it will bring some great transparency to the customer. [2]Could we get buy-in / sign-off from dev for some tech details? 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) 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) Motivation of the ask: We have some docs & terms discrepancies, which we probably should unified our terms.
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. c) Motivation of the ask: Thanks! |
thanks! Co-authored-by: Jakob Reiter <[email protected]>
Thanks! Co-authored-by: Jakob Reiter <[email protected]>
thanks! Co-authored-by: Edu González de la Herrán <[email protected]>
Thanks for the feedback so far all 🙇 👋 @kunisen ... [1]The same containers are already publicly documented here since 3.7:
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
Maybe there is a better place for all of this? The page I picked seemed fitting to me based on the reason above. B C |
Thank you so much Roberto! All makes great sense! Przemek, I posted some details in an earlier comment - #1369 (comment), thanks! |
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. |
Full ack. For folks administering ECE environments this is very useful info and belongs in the public docs |
@przemek-grzedzielski 👋 when you have time, may I trouble you to take a look on this before we merge the PR please? thanks! |
reordered the list alphabetically, first based on role, second by container name.
@kunisen I reordered the list by role first, then the container name. |
Pinged internally (here) for follow up. |
🔍 Preview links for changed docs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments added, looks very good in general and I think it's a good addition.
|
||
## ECE service containers per host role(s) [ece-service-containers] | ||
|
||
Each Elastic Cloud Enterprise service runs as a dedicated Docker container. These containers are automatically deployed based on the roles assigned to each ECE host. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each Elastic Cloud Enterprise service runs as a dedicated Docker container. These containers are automatically deployed based on the roles assigned to each ECE host. | |
Each {{ece}} service runs as a dedicated container. These containers are automatically deployed based on the roles assigned to each ECE host. The following table lists the containers you’ll find on your ECE hosts: |
| `frc-client-forwarders-client-forwarder` | All roles | Manages communication between hosts and ZooKeeper. | | ||
| `frc-runners-runner` | All roles | Runs on every ECE host and provides a supervisor service to deploy and manage containers according to their defined roles, ensuring they are online and healthy. | | ||
| `frc-services-forwarders-services-forwarder` | All roles | Routes internal service data across the ECE platform. | | ||
| `frc-allocator-metricbeats-allocator-metricbeat` | Allocator | Collects allocator metrics via Beats. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| `frc-allocator-metricbeats-allocator-metricbeat` | Allocator | Collects allocator metrics via Beats. | | |
| `frc-allocator-metricbeats-allocator-metricbeat` | Allocator | Collects allocator metrics. | |
| `frc-runners-runner` | All roles | Runs on every ECE host and provides a supervisor service to deploy and manage containers according to their defined roles, ensuring they are online and healthy. | | ||
| `frc-services-forwarders-services-forwarder` | All roles | Routes internal service data across the ECE platform. | | ||
| `frc-allocator-metricbeats-allocator-metricbeat` | Allocator | Collects allocator metrics via Beats. | | ||
| `frc-allocators-allocator` | Allocator | Manages container lifecycle for Elasticsearch and Kibana; reports host capacity to ZooKeeper. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| `frc-allocators-allocator` | Allocator | Manages container lifecycle for Elasticsearch and Kibana; reports host capacity to ZooKeeper. | | |
| `frc-allocators-allocator` | Allocator | Manages container lifecycle for {{es}} and {{kib}} instances; reports host capacity to ZooKeeper. | |
| `frc-allocator-metricbeats-allocator-metricbeat` | Allocator | Collects allocator metrics via Beats. | | ||
| `frc-allocators-allocator` | Allocator | Manages container lifecycle for Elasticsearch and Kibana; reports host capacity to ZooKeeper. | | ||
| `frc-container-task-services-container-task-service` | Allocator | Supports autoscaling and tracks feature usage. | | ||
| `frc-admin-consoles-admin-console` | Controller | Backend service for the ECE UI; handles API requests and coordinates with ZooKeeper, Elasticsearch, logging, and security services. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| `frc-admin-consoles-admin-console` | Controller | Backend service for the ECE UI; handles API requests and coordinates with ZooKeeper, Elasticsearch, logging, and security services. | | |
| `frc-admin-consoles-admin-console` | Controller | Backend service for the ECE UI; handles API requests and coordinates with ZooKeeper, {{es}}, logging, and security services. | |
Thank you @eedugon will defer to Roberto on responding the changes. Also, friendly ping again @przemek-grzedzielski may we also have your review from ECE dev perspective please? 🙏 |
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