How to access Internal host from another project

[bayramovanar (Anar Bayramov)]

Hi there,

We have several projects within the same environment.
For instance, Project 1 with Environment=Production and Service=A_web, and Project 2 with Environment=Production and Service=A_web.

Our goal is to use QOVERY_APPLICATION_XXX_HOST_INTERNAL for communication between Service A’s REST APIs instead of relying on XXX_HOST_EXTERNAL or a defined domain.

I attempted to send curl requests, but encountered issues with host name resolution.

Do I need to use kubernetes service urls or am I missing something ?

[bchastanier (Benjamin Chastanier)]

Hello @bayramovanar,

From what I understand, you are trying to communicate between services spread into several projects.

From Qovery perspective, all services exposed variables (such as internal and public hosts) are scoped to the environment. E.q. project 1 having service 1 and 2 and project 2 having service 3 and 4, service 1 and 2 will see each other exposed variables but services 3 and 4 won’t see those.

Here’s a figure showing how your services can communicate between each other depending whether those are from the same env, project or cluster.

So Qovery exposes HOST_EXTERNAL and HOST_INTERNAL to services WITHIN the same env only.
It’s possible for you to declare by yourself HOST_EXTERNAL and HOST_INTERNAL across environments / projects.

For example, your service 1 has:

• HOST_EXTERNAL=service-a.z9d173239.cargo.rocks
• HOST_INTERNAL=service-a.z9d173239

Nothing prevent you from declaring in Env 2 those two variables manually (but you won’t be able to call it QOVERY_XX): dotted arrows on the figure above:

• SERVICE_A_HOST_EXTERNAL=service-a.z9d173239.cargo.rocks
• SERVICE_A_HOST_INTERNAL=service-a.z9d173239.svc.cluster.local ( <service-name>.<service-namespace>.svc.cluster.local)

You won’t be able to use HOST_INTERNAL between two services not running on the same cluster since this is an intra cluster resolution.

Doing this might be a bit cumbersome, so I would personally user custom domains to communicate IF services have to be in different environments as it’s the more flexible setup IMO.

Now comes my questions

1. Why don’t you want to use HOST_EXTERNAL?
2. Why don’t you want to use custom domains?
3. Why would 2 apps not from the same env should communicate between each others?
4. Why, if you require two services to communicate between each others via HOST_INTERNAL don’t you put those within the same env?

Let me know if it helps

[bayramovanar (Anar Bayramov)]

Hello,
Thank you for great explanation! They actually both run in same cluster just different projects and same environments.

1,2: We want to reduce latency by avoiding communication over internet

3: Each of them are microservice and they communicate to process certain requests

4* they are in same environment but in different projects

[bchastanier (Benjamin Chastanier)]

Hello,

At Qovery, the hierarchy is the following:

Organization > Project > Environment > Service.

Environments are linked to a cluster.

They actually both run in same cluster just different projects and same environments.
4* they are in same environment but in different projects

I don’t think it’s possible it cannot be same environments across projects. Do you mind sharing your service Qovery console URL so I can have a look?

It’s not because both your envs are called the same (example production) that those are the same. An environment is unique and has only one project.

Can you clarify?

Cheers !

[bayramovanar (Anar Bayramov)]

oh yes you are right. We simply didnt know about it. So yes they are in different environments but in same cluster.

[bchastanier (Benjamin Chastanier)]

So only if you really really really want to avoid using custom domains / external host, then you can declare your services internal routes ENV variables at env level (you can copy value from QOVERY_XXX_INTERNAL_HOST to your new env variable).

Given
Env 1:

• Service 1: QOVERY_XXX_INTERNAL_HOST: service_1_internal_host
• Service 2: QOVERY_YYY_INTERNAL_HOST: service_2_internal_host

Env 2:

• Service 3: QOVERY_ZZZ_INTERNAL_HOST: service_3_internal_host
• Service 4: QOVERY_AAA_INTERNAL_HOST: service_4_internal_host

Create the following variables
to Env 1:

• SERVICE_3_HOST_INTERNAL=service_3_internal_host
• SERVICE_4_HOST_INTERNAL=service_4_internal_host

to Env 2:

• SERVICE_1_HOST_INTERNAL=service_1_internal_host
• SERVICE_2_HOST_INTERNAL=service_2_internal_host

This way, you should be able to use in service 1 for example SERVICE_3_HOST_INTERNAL to reach service 3

Cheers