Bobcares

Deploying PHP Guestbook application with Redis – Do it in ease

by | Mar 2, 2021

Need help with deploying PHP Guestbook application with Redis? We can help you.

As part of our Server Management Services, we assist our customers with several Redis queries.

Today, let us see 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 Engineers 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:

  1. Katacoda
  2. Play with Kubernetes

To check the version, we run:

kubectl version

Deploying PHP Guestbook application with Redis

 

  • 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.

Create the Redis Master Deployment:

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

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

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

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

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

kubectl get pods

The response should be similar to:

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

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

kubectl logs -f POD-NAME

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

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.

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

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

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

kubectl get service

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.

 

  • 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.

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.

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

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

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
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.

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

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

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

 

  • 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.

Create the Guestbook Frontend Deployment:

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

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

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

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
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.

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

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

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

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
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.

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

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

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.

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

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

Scale the Web Frontend:

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

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

kubectl scale deployment frontend –replicas=5

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

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

kubectl scale deployment frontend –replicas=2

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

 

  • Clean up

Deleting the Deployments and Services also deletes any running Pods. We use labels to delete multiple resources with one command.

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

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? We’d be happy to help you]

 

Conclusion

To conclude, an effective way of Deploying PHP Guestbook application with Redis is with the use of the Kubernetes cluster. Today, we saw how our Support Engineers go about this deployment.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

var google_conversion_label = "owonCMyG5nEQ0aD71QM";

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Never again lose customers to poor
server speed! Let us help you.

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

_reb2bgeo - The visitor's geographical location

_reb2bloaded - Whether or not the script loaded for the visitor

_reb2bref - The referring URL for the visit

_reb2bsessionID - The visitor's RB2B session ID

_reb2buid - The visitor's RB2B user ID

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid
_reb2bgeo, _reb2bloaded, _reb2bref, _reb2bsessionID, _reb2buid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF