Feedback: ratel should be disabled by default and available on port 80 / 443

Issues
, ,
1

Moved from GitHub charts/6

Posted by christian-roggia:

Ratel currently is used as UI mostly for debugging and experimenting.
Normal operations run through alpha from (presumably) another service in the Cloud.

UI can be considered, within the Cloud / Kubernetes environment, an optional feature to be enabled.

Ratel is also completely unrelated to the deployment of zero and alpha, and it can be used from either localhost or play.dgraph.io without consuming any resource from k8s nodes (or load balancers, which are not cheap for small projects).

Ratel should also point to the port 80 in the service when enabled since kubernetes manages all the port allocation and there is no risk to encounter a busy port (as it might happen when ratel is deployed in docker/docker-compose in a local environment).

The expected behavior would also be to find the UI on the IP of the load balancer (or DNS record pointing to ratel) on the port 80 or 443, rather than 8080, which is instead common for local development.

2

danielmai commented :

Thanks for the feedback, @christian-roggia. Defaulting to port 80/443 makes sense.

I’m not convinced about turning off Ratel by default. It’s what a lot of folks use to interact with Dgraph. We can lock it down and not connect it to a load balancer.

3

christian-roggia commented :

Maybe a value called ratel.enabled could be provided, and when such a value is set to false ratel doesn’t get deployed at all.

(I am aware that ratel.replicaCount could be set to 0 to achieve a similar result, but it would be cleaner to provide a way to completely exclude ratel for deployments where it is not needed).

4

danielmai commented :

We can add an option like ratel.enabled.

5

christian-roggia commented :

That would be perfect :+1:

6

encryptblockr commented :

@danielmai
where is ingress? how do i expose ratel to loadbalancer? so i can view it via an endpoint outside the kubernetes cluster
i don’t see any option for this in values.yaml

7

orange-oranje commented :

I have raised a new issue for ingress, there is no template for ingress, as of now I am managing to create a local template and trying to replicate the values as much as possible

8

orange-oranje commented :

If ratel is exposed outside using an ingress, should the alpha be exposed as well through an ingress ?

I wrote a custom ingress for ratel by myself

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: dgraph-dgraph-ratel
  labels:
    app: dgraph
    chart: dgraph
    component: ratel
    release: dgraph
    heritage: Helm
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
    - host: "route53"
      http:
        paths:
          - path: /
            backend:
              serviceName: dgraph-dgraph-ratel
              servicePort: 8000

But unable to connect to alpha from the external dashboard, so alpha needs an ingress as well

9

orange-oranje commented :

@danielmai
where is ingress? how do i expose ratel to loadbalancer? so i can view it via an endpoint outside the kubernetes cluster
i don’t see any option for this in values.yaml

I don’t even see the point of ratel, if it is not exposed outside what is the use from inside the K8S cluster. Am I missing something ?

10

darkn3rd commented :

We have added functionality with last chart version 0.0.5 to support disabling ratel service for deployment, service, and recently added ingress support.

The default port is now 80 from 8000. There’s support for annotations as well, so you can add for example external load balancer annotations to customize LoadBalancer type.

Alternatively, you can use the new ingress feature. There are some example Helm chart values provided for popular ingress controllers.