# Example of using a Readiness probe in portable services

> [HTML Version](readiness.html)

This article shows an example of implementing a [Readiness probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) based on HTTP requests.

````
начало внимание

````
This article does not include recommendations on how to define whether you need a Readiness probe.

````
конец внимание

## ````
Basic information about the case

This is a module that includes two portable services. Service #1 can send information about its state via HTTP requests. Service #2 can interpret its responses or absence of responses.

We need to configure Service #2 so that it doesn’t accept incoming traffic when Service #1 is in a certain state.

We have decided to do it using a Readiness probe.

## Modification of Service #2

We need to define how Service #2 processes the HTTP request that retrieves the status of Service #1.

From the \[OBJECT\] environment variable, the address of Service #1 is retrieved. An HTTP request is sent to this service. If the response status code is 200, and the response body meets the conditions of the probe set up in Service #2, the method we added returns status 200. Otherwise, it returns 504.

````
func readnessFunc(w http.ResponseWriter, r \*http.Request) \{  
if serv1URL, exists := os.LookupEnv("SERV1URL"); exists \{  
       response, err := http.Get(serv1URL + "/getstatus")  
       if err == nil \&\&  
               response.StatusCode == 200 \&\&  
               isValidStatus(response.Body) \{  
               fmt.Fprintf(w, "Yeah, it works")  
               return  
       \}  
\}  
w.WriteHeader(http.StatusGatewayTimeout)  
\}

## ````
Configure Service #2

When the image of Service #2 is built and uploaded, we need to configure the Readiness probe in BRIX. To do that, we need to:

1. In the module’s settings, open the **Services** tab, then move on to editing Service #2. 

2. On the **Readiness** tab, select **HTTP**.

3. Set a delay after which the probe is performed.

````
начало внимание

````
Don’t make the delay too short. Service #2 must have enough time to be initialized in the cluster to accept requests from probes. If the value of the delay is not enough, Service #2 may become unavailable.

````
конец внимание

1. ````
In Service #2, specify the port and the path to the HTTP method used for the probe.

2. Pass information about the location of Service #1 to Service #2. To do that, go to the **Environment Variables** tab and create a string named **SERV1URL** with the URL of Service #1.

3. Specify the address of the service by clicking the **\{+\} **symbol on the right side of the string and select the service from the list. A value of the following format will be generated: \[OBJECT\].

## Additional information

When developing and implementing a Readiness probe, note that it is performed all the time while Service #2 exists. In the example provided in this article, Service #2 will constantly send HTTP requests to Service #1.