Are you trying to deploy PHP Guestbook application with Redis?

This guide is for you.

Redis (REmote DIctionary Server) is an open source, in-memory datastore, often used as a database, cache or message broker. It can store and manipulate high-level data types like lists, maps, sets, and sorted sets.

Deploying Redis Cluster within Kubernetes has its challenges, as each Redis instance relies on a configuration file that keeps track of other cluster instances and their roles. 

Here at Ibmi Media, as part of our Server Management Services, we regularly help our Customers to resolve Redis related issues.

In this context, we shall look into how to build and deploy a simple, multi-tier web application using Kubernetes and Docker.

Deploying PHP Guestbook application with Redis

In order to begin our Support Experts suggest having a Kubernetes cluster.

Similarly, we need to configure the kubectl command-line tool to communicate with the cluster. 

If we do not already have a cluster, we can create one by using Minikube, or we can use one of these Kubernetes playgrounds:

i. Katacoda

ii. Play with Kubernetes

To check the version, we run:

kubectl version

1. Startup the Redis Master

The guestbook application uses Redis to store its data. It writes its data to a Redis master instance and reads data from multiple Redis slave instances.

i. Create the Redis Master Deployment:

The manifest file specifies a Deployment controller that runs a single replica Redis master Pod.

a. Open the file application/guestbook/redis-master-deployment.yaml and enter the code given below:

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: redis-master
labels:
app: redis
spec:
selector:
matchLabels:
app: redis
role: master
tier: backend
replicas: 1
template:
metadata:
labels:
app: redis
role: master
tier: backend
spec:
containers:
– name: master
image: k8s.gcr.io/redis:e2e # or just image: redis
resources:
requests:
cpu: 100m
memory: 100Mi
ports:
– containerPort: 6379

b. Then, launch a terminal window in the directory we downloaded the manifest files.

c. Later apply the Redis Master Deployment from the redis-master-deployment.yaml file:

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml

d. We query the list of Pods to verify that the Redis Master Pod is running:

kubectl get pods

e. The response should be similar to:

NAME READY STATUS RESTARTS AGE
redis-master-1068406935-3lswp 1/1 Running 0 28s

f. Then we run the below command to view the logs from the Redis Master Pod:

kubectl logs -f POD-NAME

g. Finally, replace POD-NAME with the name of your Pod.

ii. Create the Redis Master Service:

The guestbook application needs to communicate with the Redis master to write its data. We need to apply a Service to proxy the traffic to the Redis master Pod. A Service defines a policy to access the Pods.

a. We open the file application/guestbook/redis-master-service.yaml and enter the code given below:

apiVersion: v1
kind: Service
metadata:
name: redis-master
labels:
app: redis
role: master
tier: backend
spec:
ports:
– name: redis
port: 6379
targetPort: 6379
selector:
app: redis
role: master
tier: backend

b. Then we apply the Redis Master Service from the following redis-master-service.yaml file:

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml

c. Later, we query the list of Services to verify that the Redis Master Service is running:

kubectl get service

d. The response should be similar to this:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 1m
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 8s

This manifest file creates a Service named redis-master with a set of labels, so the Service routes network traffic to the Redis master Pod.

2. Startup the Redis Slaves

Although the Redis master is a single pod, we can make it highly available to meet traffic demands by adding replica Redis slaves.

i. Create the Redis Slave Deployment:

Deployments scale based on the configurations set in the manifest file. 

In this case, the Deployment object specifies two replicas.

If there are not any replicas running, this Deployment would start the two replicas on the container cluster.

Conversely, if there are more than two replicas running, it would scale down until two replicas are running.

a. Initially, we open the file application/guestbook/redis-slave-deployment.yaml and enter the code given below:

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: redis-slave
labels:
app: redis
spec:
selector:
matchLabels:
app: redis
role: slave
tier: backend
replicas: 2
template:
metadata:
labels:
app: redis
role: slave
tier: backend
spec:
containers:
– name: slave
image: gcr.io/google_samples/gb-redisslave:v3
resources:
requests:
cpu: 100m
memory: 100Mi
env:
– name: GET_HOSTS_FROM
value: dns
# Using `GET_HOSTS_FROM=dns` requires your cluster to
# provide a dns service. As of Kubernetes 1.3, DNS is a built-in
# service launched automatically. However, if the cluster you are using
# does not have a built-in DNS service, you can instead
# access an environment variable to find the master
# service’s host. To do so, comment out the ‘value: dns’ line above, and
# uncomment the line below:
# value: env
ports:
– containerPort: 6379

b. Then we apply the Redis Slave Deployment from the redis-slave-deployment.yaml file:

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml

c. Subsequently, we query the list of Pods to verify that the Redis Slave Pods are running:

kubectl get pods

The response should be similar to this:

NAME READY STATUS RESTARTS AGE
redis-master-1068406935-3lswp 1/1 Running 0 1m
redis-slave-2005841000-fpvqc 0/1 ContainerCreating 0 6s
redis-slave-2005841000-phfv9 0/1 ContainerCreating 0 6s

ii. Create the Redis Slave Service:

The guestbook application needs to communicate to Redis slaves to read data. 

To make the Redis slaves discoverable, we need to set up a Service.

A Service provides transparent load balancing to a set of Pods.

a. To begin, we open the file application/guestbook/redis-slave-service.yaml and enter the code given below:

apiVersion: v1
kind: Service
metadata:
name: redis-slave
labels:
app: redis
role: slave
tier: backend
spec:
ports:
– port: 6379
selector:
app: redis
role: slave
tier: backend

b. Initially, we apply the Redis Slave Service from the following redis-slave-service.yaml file:

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml

c. Then we query the list of Services to verify that the Redis slave service is running:

kubectl get services

The response should be similar to this:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 2m
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 1m
redis-slave ClusterIP 10.0.0.223 <none> 6379/TCP 6s

3. Set up and Expose the Guestbook Frontend

The guestbook application has a web frontend serving the HTTP requests written in PHP. 

It is configured to connect to the redis-master Service for write requests and the redis-slave service for Read requests.

i. Create the Guestbook Frontend Deployment:

a. Open the file application/guestbook/frontend-deployment.yaml and enter the code given below:

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: frontend
labels:
app: guestbook
spec:
selector:
matchLabels:
app: guestbook
tier: frontend
replicas: 3
template:
metadata:
labels:
app: guestbook
tier: frontend
spec:
containers:
– name: php-redis
image: gcr.io/google-samples/gb-frontend:v4
resources:
requests:
cpu: 100m
memory: 100Mi
env:
– name: GET_HOSTS_FROM
value: dns
# Using `GET_HOSTS_FROM=dns` requires your cluster to
# provide a dns service. As of Kubernetes 1.3, DNS is a built-in
# service launched automatically. However, if the cluster you are using
# does not have a built-in DNS service, you can instead
# access an environment variable to find the master
# service’s host. To do so, comment out the ‘value: dns’ line above, and
# uncomment the line below:
# value: env
ports:
– containerPort: 80

b. Then we apply the frontend Deployment from the frontend-deployment.yaml file:

kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml

c. Later, we query the list of Pods to verify that the three frontend replicas are running:

kubectl get pods -l app=guestbook -l tier=frontend

The response should be similar to this:

NAME READY STATUS RESTARTS AGE
frontend-3823415956-dsvc5 1/1 Running 0 54s
frontend-3823415956-k22zn 1/1 Running 0 54s
frontend-3823415956-w9gbt 1/1 Running 0 54s

ii. Create the Frontend Service:

The redis-slave and redis-master Services we apply are only accessible within the container cluster because the default type for a Service is ClusterIP.

If we want guests to be able to access the guestbook, we must configure the frontend Service to be externally visible, so a client can request the Service from outside the container cluster.

If the cloud provider supports load balancers and we want to use it, simply delete or comment out type: NodePort, and uncomment type: LoadBalancer.

a. First, open the file application/guestbook/frontend-service.yaml and enter the code given below:

apiVersion: v1
kind: Service
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# comment or delete the following line if you want to use a LoadBalancer
type: NodePort
# if your cluster supports it, uncomment the following to automatically create
# an external load-balanced IP for the frontend service.
# type: LoadBalancer
ports:
– port: 80
selector:
app: guestbook
tier: frontend

b. Then apply the frontend Service from the frontend-service.yaml file:

kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml

c. Subsequently, query the list of Services to verify that the frontend Service is running:

kubectl get services

The response should be similar to this:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend NodePort 10.0.0.112 <none> 80:31323/TCP 6s
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 4m
redis-master ClusterIP 10.0.0.151 <none> 6379/TCP 2m
redis-slave ClusterIP 10.0.0.223 <none> 6379/TCP 1m

iii. View the Frontend Service via NodePort:

If we deploy this application to Minikube or a local cluster, we need to find the IP address to view the Guestbook.

a. Initially, we run the following command to get the IP address for the frontend Service:

minikube service frontend –url

The response should be similar to this:

http://192.168.99.100:31323

b. Then we copy the IP address and load the page in the browser to view your guestbook.

iv. View the Frontend Service via LoadBalancer:

If we deploy the frontend-service.yaml manifest with type: LoadBalancer we need to find the IP address to view the Guestbook.

a. Initially, we run the following command to get the IP address for the frontend Service:

kubectl get service frontend

The response should be similar to this:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend ClusterIP 10.51.242.136 109.197.92.229 80:32372/TCP 1m

b. Then we copy the external IP address and load the page in your browser to view your guestbook.

v. Scale the Web Frontend:

Scaling up or down is easy because the servers are Service that uses a Deployment controller.

a. We run the following command to scale up the number of frontend Pods:

kubectl scale deployment frontend –replicas=5

b. Then we query the list of Pods to verify the number of frontend Pods running:

kubectl get pods

The response should look similar to this:

NAME READY STATUS RESTARTS AGE
frontend-3823415956-70qj5 1/1 Running 0 5s
frontend-3823415956-dsvc5 1/1 Running 0 54m
frontend-3823415956-k22zn 1/1 Running 0 54m
frontend-3823415956-w9gbt 1/1 Running 0 54m
frontend-3823415956-x2pld 1/1 Running 0 5s
redis-master-1068406935-3lswp 1/1 Running 0 56m
redis-slave-2005841000-fpvqc 1/1 Running 0 55m
redis-slave-2005841000-phfv9 1/1 Running 0 55m

c. Subsequently, we run the following command to scale down the number of frontend Pods:

kubectl scale deployment frontend –replicas=2

d. Finally, we query the list of Pods to verify the number of frontend Pods running:

kubectl get pods

The response should look similar to this:

NAME READY STATUS RESTARTS AGE
frontend-3823415956-k22zn 1/1 Running 0 1h
frontend-3823415956-w9gbt 1/1 Running 0 1h
redis-master-1068406935-3lswp 1/1 Running 0 1h
redis-slave-2005841000-fpvqc 1/1 Running 0 1h
redis-slave-2005841000-phfv9 1/1 Running 0 1h

4. Clean up

Deleting the Deployments and Services also deletes any running Pods. 

We use labels to delete multiple resources with one command.

a. Initially, to delete all Pods, Deployments, and Services we run:

kubectl delete deployment -l app=redis
kubectl delete service -l app=redis
kubectl delete deployment -l app=guestbook
kubectl delete service -l app=guestbook

The responses should be:

deployment.apps “redis-master” deleted
deployment.apps “redis-slave” deleted
service “redis-master” deleted
service “redis-slave” deleted
deployment.apps “frontend” deleted
service “frontend” deleted

b. Then we query the list of Pods to verify that no Pods are running:

kubectl get pods

The response should be this:

No resources found.

[Stuck in between Deploying PHP Guestbook application with Redis?  We'd be happy to help you. ]