ECE URL Change

I'm looking at the ECE documentation, and "Change endpoint URLs" section is not clear to me.

https://www.elastic.co/guide/en/cloud-enterprise/current/ece-administering-endpoints.html

By default, cluster and Kibana endpoint URLs are constructed according to the following pattern, where CLUSTER_ID and LOCAL_HOST_IP are values that depend on your specific installation:

http://CLUSTER_ID.LOCAL_HOST_IP.ip.es.io:9200
https://CLUSTER_ID.LOCAL_HOST_IP.ip.es.io:9243

For example:

http://2882c82e54d4361.us-west-5.aws.found.io:9200
https://2882c82e54d4361.us-west-5.aws.found.io:9243

How "found.io" URL was produced in the above example? Is just an example of another URL? Why they didn't use the same example as above ("es.io")?

Do I need to keep es.io or found.io after I change the internal IP to a name of the hostname in AWS or GCP?

Hey @daniel_a,

Maybe the found.io is a bit confusion here but you don't need to keep it. For example in my ECE environment the default deployments URL is: <CLUSTER_UUID>.<IP>.ip.es.io:9243 and I can change this configuration to a more user friendly endpoint like: <CLUSTER_UUID>.ece.acme.com by replacing <IP>.ip.es.io with ece.acme.com in Platform >> Settings page. This means I also need to provide the relevant wild card certificate which I can upload in the same page.

Why the es.io part has been added to the URL?

I have an ECE deployment in GCP, and I use 10.x.x.x for the deployment. Let's say that my Kibana sits at 10.10.10.1, why can't I access Kibana by going directly to 10.10.10.1:9243, but I'll need to add that extra part to the URL (10.10.10.1.ip.es.io:9243) to be able to access it. Can you please elaborate on the es.io part a bit more? This seems to be a TLD here (similar to .com or .org), but I don't have a DNS record for it or never created one, and I'm not going outside (to the Internet).

--Thanks

All requests to Elasticsearch, Kibana, APM server, etc. are routed through our proxy service. You cannot ensure a specific Kiabana instance is available over a specific IP, and even if you find the container IP in various scenarios we will start a new Kibana container and kill the old one so the IP will change. That's why the routing is managed by the proxy and why the endpoint is constructed with the Kibana UUID which doesn't change.

We are planning to introduce a way for users to define deployment aliases which will support setting human friendly string to be used instead of the UUID. I think that will address your use case.

In this case, how do I request a CRQ certificate request if the domain for Kibana and proxies are hosted on es.io domain? What's the best way to sign the certs for the internal IPs sitting on this domain?

We recommend using a wildcard certificate as mentioned in the following page.

Excellent, thanks for your quick responses!

Where does this sit in the development road map? Do you know which release it's targeted for?

We don't have more information we can share about future roadmap items.

So here is the problem I noticed after adding a DNS record and updating the Deployment endpoints field under Platform/Settings:

  1. I created a DNS record (mycompany.com) for 10.x.x.x
  2. I was able to access the ECE URL via the new domain: https://mycompany.com:12443/ (it's a DNS lookup, so nothing complicated here)
  3. I then changed the 'Deployment endpoints' field under Platform/Settings from 10.x.x.x.ip.es.io to mycompany.com and now I can't access Kibana or anything else via a new domain record.
  4. I was able to access Kibana via https://mycompany.com:9243 but I got an error since there was no Cloud ID in the URL:

ERROR: {"ok":false,"message":"Unknown cluster."}

Question: How do I update "Deployment endpoints" and then be able to access it via Kibana link?

--Thanks

Easy fix, we added a wild card in GCP (Google Cloud) for the new domain: *.mycompany.com which points to 10.x.x.x address, and this solved the issue. It worked!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.