Theia Cloud, Minikube, using Docker, on Mac, NOT WORKING

[mhashemi]

Hi,

I have tried to deploy Theia Cloud using docker on my Mac, where things aren't working as documented. I am trying from /trraform/configurations/minikube_getting_started instruction.

First of all, as terraform works on Mac, and needs to communicate with internal services (i.e keycloak), I needed to run "minikube tunnel" after running "terraform apply", and rerun "terraform apply", to get it working. I wished the instruction of deploying Theia Cloud using Docker also would have been provided.

Then, I'd be able to browse /trynow and see the login page, where bar/foo users are also correctly authenticated, but then. I got an error after console log of "Calling to https://127.0.0.1.nip.io" with error code 500, and the log of the service-service pod, is that 127.0.0.1/127.0.0.1.nip.io port 443 refused.

The issue to me is that, the internal components landing-page, service-service, keycloak, etc. cannot communicate with each other through nip.io wild card, and I am not sure how to resolve this issue?
Please share your thoughts, and share instruction if there is any for deploying Theia Cloud using Docker.

On another note, I will try to deploy it to an AWS EKS Cluster, maybe the networking issue is resolved.

[jfaltermeier]

Hi,

our committers use ubuntu machines, so we rely on community contributions for the Windows and Mac setups. We can't debug the Minikube setups there. We are happy to accept contributions.

After authenticating at keycloak (which seems to work as far as I understood), the landing-page will make a rest call to the service in order to start the session.
You can check if this part worked by checking whether a sessions was created:
kubectl get sessions -n theiacloud

If this part worked, then the reverse proxy might be the issue or the operator can't determine if the app is running.

Checking whether the rest service is reachable from the browser may be done like this as well:
Have a look at the service ingress:
kubectl get ingress -n theiacloud
kubectl get ingress service-ingress -o yaml -n theiacloud

Then try to append the app id to the services URL, e.g. (depending on whether you are using paths or subdomains):
service.my-ip.nip.io/service/asdfghjkl
my-ip.nip.io/servicex/service/asdfghjkl
and see if you can reach this URL from te browser. It should either reply with true or {"code":470,"reason":"Invalid application id."} depending on whether you used the correct application id.

Based on this we should know how to debug further.

Please also have a look here:
#170
and here
https://github.com/eclipsesource/theia-cloud/blob/main/doc/docs/platforms/Minikube.md#troubleshooting
Maybe this helps you.

[mhashemi]

Hi @jfaltermeier

Thanks for the response.

I will definitely contribute as soon as I got it working on our side, and explore the functionalities, and extract the requirements that we may need from our side.

Please note that we are going to implement several IDE-like web apps using Theia, and deploy/run them on top of Theia Cloud.

After carefully exploring the Theia Cloud components, and architecture, I still haven't got luck to run the Theia Cloud solution.

I am using AWS EKS cluster,
I deployed all services via Helm, I customized the configurations to match AWS networking, and DNS(s) are created as service.DNS.com and theia.cloud.DNS.com, however when hitting the theia.cloud.DNS.com/, the ingress controller is trying to upstream to 127.0.0.1:8181 which I am not sure why!
Let's say the networking configuration is wrong.

Next was to port-forward to Landing-page-service and try from local machine, where initially the issue was that, the landing-page-service is trying to connect to service-service using the DNS URL. I managed to re-configure that via config map, and used POD IP and PORT, so now the landing-page is trying to make a connection with CORS issue, (it does make sense since I am hitting the landing-page from 127.0.0.1:3000), so I managed to use CORS plugin to bypass that issue, so finally the landing-page service supposes to have no issue to connect to service-service using POD-IP:8081 BUT, here is the next error:

Calling to http://10.IP.IP.122:8081
client.js:168 Network Error
startSession @ SessionLauncher.vue:58
POST http://10.IP.IP.122:8081/service net::ERR_CONNECTION_TIMED_OUT

As I said before, I would have no GCP to try it, and I tried Minikube and Docker with no luck, same errors,

I am using latest version of Theia Cloud using Helm, 0.8.1.OSWeek23-v1, I also tried 0.8.0.

I am stuck and would like to receive some supports, so as soon as I got it up and running on AWS EKS, I will start some projects on it.

I appreciate your response.

Regards.

[jfaltermeier]

We are using the Ingress-Nginx Controller for our ingresses: https://kubernetes.github.io/ingress-nginx/
So I think the first thing to check would be whether this controller is working in your cluster. Have you tried exposing something else than Theia Cloud using the controller yet?

There is a dedicated guide for AWS: https://kubernetes.github.io/ingress-nginx/deploy/#aws

You can check whether it is installed, running and has an external IP like this

:~$ kubectl get deployments --all-namespaces
NAMESPACE                  NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
nginx-ingress-controller   nginx-ingress-controller-ingress-nginx-controller   1/1     1            1           171d

:~$ kubectl get services --all-namespaces
NAMESPACE                  NAME                                                          TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                      AGE
nginx-ingress-controller   nginx-ingress-controller-ingress-nginx-controller             LoadBalancer   98.765.432.10    12.345.67.890    80:30200/TCP,443:32070/TCP   171d
nginx-ingress-controller   nginx-ingress-controller-ingress-nginx-controller-admission   ClusterIP      98.765.543.201   <none>           443/TCP                      171d

When it is installed you can look for a tutorial on how to set up a simple ingress using the controller, e.g. https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengsettingupingresscontroller.htm#ariaid-title4 might work

[mhashemi]

Hi,
Thanks for the response.

We have a dedicated Load balancer, which is linked with the Route53 DNS(es), for service.abc, the.cloud.abc, and ws.abc
The Ingress controller is in place, and all ingresses are registered with Nginx.

I have partially got The Cloud (0.8.1.OSWeek23-v1) installed on a Ubuntu, using Docker, and Minikube.
When hitting the landing-page, it takes some time, but then it fails with timeout error, however, I can see that the session and the pod for the App is created,
Looking at the logs of operator service, there is an error that says, "ws.127.0.0.1.nip.io/SOME-ID-FOR-THEIA-APP" is not available, however, if I open the url in a browser, I can access the Theia Blueprint app.
Also, If I abandon the session, the associated resources are being released properly.

I think, we would end up developing a new landing page app, that communicates with the-service to create the session, and all required resources for provisioning an app.

I'll keep you updated in here, also if you have any thoughts, please do share.

Regards.