---
title: 'Deploying Laravel on Kubernetes with Docker | Part 5'
source: 'https://youtube.com/watch?v=MUXVbEeCYxw'
video_id: 'MUXVbEeCYxw'
date: 2026-06-30
duration_sec: 4424
---

# Deploying Laravel on Kubernetes with Docker | Part 5

> Source: [Deploying Laravel on Kubernetes with Docker | Part 5](https://youtube.com/watch?v=MUXVbEeCYxw)

## Summary

This video provides a comprehensive guide to deploying a Laravel application on Docker and Kubernetes, covering everything from setting up a backend repository and Dockerfile to configuring Nginx, PHP-FPM, and Supervisor. It also demonstrates how to set up CI/CD pipelines with Google Cloud Build, create Kubernetes workloads and services, implement liveness probes, and securely manage credentials using Kubernetes secrets.

### Key Points

- **Overview of Deployment Steps** [00:10] — The video will cover deploying Laravel on Docker and Kubernetes, including differences between Nginx and Apache, and supporting various Laravel setups like queues, Horizon, and high-load applications.
- **Creating Backend Repository** [01:01] — Create a private GitHub repository for the backend, enable Google Cloud Build, and clone sample configuration files for Laravel.
- **Setting Up Project Structure** [02:04] — Create a 'backend' folder, copy configuration files (config production, config staging, gitignore, Dockerfile) from a front-end template, and create the 'src/www/html' directory for Laravel.
- **Installing Laravel via Composer** [04:43] — Use Composer to create a new Laravel project inside 'src/www/html', then move files out of the 'example' subdirectory and verify installation with 'php artisan serve'.
- **Dockerfile and Configuration Files** [07:09] — Create a Dockerfile and copy Laravel-specific config files (entrypoint, Nginx config, PHP-FPM config, supervisor config) from example files. Explain each config file's purpose.
- **Adjusting Dockerfile for Laravel** [11:07] — Modify the Dockerfile: remove Node.js/npm, copy Laravel files, install Composer using multi-stage build, run 'composer install --optimize-autoloader --no-dev --no-interaction --no-progress', and expose port 8080.
- **Creating Kubernetes Workloads** [15:32] — In Google Kubernetes Engine, create two workloads (backend and backend-staging) using a basic Nginx image, then set up Cloud Build triggers for production and staging branches.
- **Pushing Code and First Build** [19:26] — Push code to GitHub master branch, triggering Cloud Build. Encounter an error due to leftover Node.js installation; fix by removing that line and recommit.
- **Deploying and Debugging** [24:42] — After successful build, update workload image. Use 'kubectl logs' and 'kubectl exec' to debug a missing .env file. Add environment files in config/staging and config/production.
- **Verifying Staging and Production** [34:48] — Both workloads become healthy. Create a staging branch, merge master, and push to trigger staging build. Verify both environments show different app names.
- **Adding Liveness Probe** [42:37] — Explain liveness probe: if a pod becomes unresponsive, Kubernetes restarts it. Add liveness and readiness probes to both workloads using HTTP GET on port 8080.
- **Why Nginx Over Apache** [48:46] — Nginx offers better performance under high concurrency. Benchmark shows response times around 36-40 ms. Apache slows down with thousands of concurrent requests.
- **Securing Credentials with Kubernetes Secrets** [52:31] — Create JSON credential files for production and staging, upload them as Kubernetes secrets, mount them as volumes in workloads, and use an init.php script to inject values into Laravel's .env file.
- **Final Verification** [67:02] — After fixing init.php not being executed (added call in entrypoint), both workloads deploy successfully with credentials injected. App names and keys are correctly set.

## Transcript

foreign
I'm going to show you how to deploy PHP
laravel on a Docker and kubernetes
you'll know exactly how it's done we
will tackle all use cases we will
discuss the difference between engines
and Apache server we will make sure that
your Docker container environment is
able to support any setup of level
whether you're using Quran jobs Horizon
whether your application is a really
high load and high CPU application or
the just API service or a web server you
after completing this chapter you will
know exactly how to deploy your
layerable onto Docker and kubernetes
okay let's work on setting up back-end
workload for lateral
so these are going to be our steps first
of all let's go to your GitHub
repository right here and let's create a
backend Repository
so I'm going to select that it's private
and enable Google Cloud build right here
so let's hit create Repository
here you go so the repository is created
now let's open the finder or the browser
and uh
let's go to our folder our learning
folder and prerequisite is that you have
to download the sample files for a
backend because we will be using some
level specific some PHP specific
configuration files for engines this is
why I want to make sure that you have
the right files files with you so please
download the files before starting this
video and you can paste it in here such
as backend example files so let's let's
begin so let's create a new folder will
called Beckett
here you go now let's open your PHP
store
and let's open the repository the the
folder
here you go
this is open so first of all
um let's just copy the files that we can
from the front-end repository and let's
just go
back
to our front end project
let's open it up
so I'm gonna open it a new window
so remember now we have couple of
folders and a couple of files that we
have to have so this is config config
production config staging and the
dashboard really what differs here is
that we will be deploying layerable
everything else the same however we will
deploy a layerable so it's a little bit
different
so let's let's continue let's drag and
drop couple of files so here let's copy
config production config staging some
some basic
let's take a look
here you go config production
now let's go
let's copy config staging
now let's
let's take these files
will they create me a global staging
production git ignore
and it'll leave Docker file and config
for now there
let's see okay so in readme let me just
change the name just so we have it I'm
gonna call it back end
and really you can call it any name you
want you can call back end you can call
it any any way you want
so we have copied that
let's let's now create the most
important directory here where we're
going to store level so let's hit here
let's create new folder SRC
www
in HTML so in this folder we will hold
variable and let's install the level
let's open Terminal
and let me go to level's original
website and let's
take a look installable
installation
here you go
shouldn't be fairly simple
okay
okay let's do this
let me just change them into ninth
version to the latest one
I'm going to call it example
and again as a prerequisite you should
have composer installed
so now let's go to CD SRC
www.html and let's hit composer create
project
here you go it's installing all the
packages right now
and most likely we will need to move it
back in HTML folder let's take a look
here you go so now let's move all files
out of example into the HTML
okay so as you see it's indexing in the
bottom so let's give it one more minute
to finish indexing
it has finished indexing so now let's
just copy these files into HTML
let's give it one second to refactor it
great so we have moved all the files so
now let's delete example
and let's put PHP Artisan server to
ensure that everything is installed
properly
I just go here here you go level was
installed successfully so V Should Be
Alright to continue
okay so now a couple of things first of
all we will have to begin with the
docker file so let's create a new Docker
file
and we will need to use a config
this config will be specific to level
application so let's create a folder and
now it's the time to open our folder our
example files and just go in here go to
config directory and just copy all the
files and again we're going to go
through them so no no worries so let's
just copy them here
here you go we have copy the files so
the entry point this is the
so now let me walk you through each file
so you have a full understanding there
are no files that are not making any
sense for you so entry point this is the
file that we will use whenever we deploy
the docker container and here we are
essentially telling level hey
create the cache for a config and create
the cache for routes because this is
what's going to optimize lateral
application
and now we're passing the command to
exits to to be executed now let's take a
look on fbm pull not configuration
so this is spec this is engine specific
configuration that we use for PHP
so we we could go in depth here but this
is not going to be covered in this
lesson so for now just copy them in and
in short these are just the
configuration files for our engines PHP
server really the fpm extension of PHP
so now we have engines configuration
file
and uh right here we have a couple of
things here
let's let's go to the server this is the
30 second line and here we are listening
to the port 8080 and we are exposing the
server name as the local server which is
fine in production you can put your
domain name here so keep a live time of
this set for 70 seconds and here we are
saying that the raw directory of our
application will be located in this spot
so VAR www HTML in public because the
way light level works as you see here
index PHP is located in the public
folder
and usually if you would deploy it on
Apache you would put htxs in this folder
right here however in this case and Jinx
does not need HD access because it's
really slowing down the requests so in
this case we can even delete it if you
don't need it and here we're just
telling the engines that this is the
directory and it should be pointing to
index PHP right here
and here we are saying drive files in
index PHP right away
and this is the configuration where we
are passing down requests to PHP fpm
that's listening on 9000 port
and let's go right here and this is G
sub configuration so this is really very
optimized in Jinx configuration
and let's go to the PHP e this is
another PHP configuration which you can
adjust as you need however I'm finding
it to be very optimized where it's
working very well however you can change
it as you need and now let's go to
supervisor configuration very important
file because this is what's really
running our server
here we are running supervisor and let's
examine this one so we are running PHP
fpm this is what we need in order in
order to host our PHP application and
here we're running engines and this is
really the case where you really need to
use supervisor configuration because
otherwise running both ground jobs on a
very optimized Alpine Linux is going to
be challenging this and here supervisor
is really helping us
all right so so we have went through the
configuration file let's just close this
directory and now let's work on our
Docker file
so first of all let's open your previous
project and we will start with
correcting it so so let's go to Docker
file in our previous project
let's copy paste it
and let's set it up here
so
so now this is the docker file that we
were using to run our react.js
application however now it will be a
little bit different because now we
don't need to to have npm we don't need
to have node.js we just need to run our
lateral application
so now let's adjust our Docker file so
it would be working fine with lateral so
let's just scroll down right here we can
actually remove node.js
npm
so let's just remove that and let's
scroll down to line number 17. so here
we are entering
as a you as a user engines and now let's
just change up this part and let's build
our lateral application so let me just
make a comment so build up
and now we're going to copy all our
folder SRC www to to the correct
location so let's let's do that now
so copy
Sean
equals engines and now we are saying
copy the files from WWW folder
to this directory okay and now let's
just copy our environment file because
it will be located in a different
directory it can be either in config
production or config staging so let's do
that right now
and you can actually copy this part
right here from the bottom
in order to be consistent uh consistent
I'm just gonna type it
so the same rule in jinx let's say now
config path
environment file and we will place it in
the root directory of flyable and now as
you see
it's even easier to install lateral we
can just go ahead and remove this part
right here
however we need to install the packages
for lab for the level so let's install
packages right here
and first of all
we need to install composer because this
composer I mean this Docker image does
not know what it what composer is it
doesn't have it installed so in this
case Docker makes it very simple to
install it and really if you would be
doing it manually you would be launching
some scripts and installing it however
Docker makes it very simple for it
Docker makes it very simple for us so
let's say copy from composer latest so
we are referencing the composer's
directory
user
bin
composer
we are just defining a path right now
and now let's run the installation
because very important part so let's CD
to our HTML folder
and let's say user bin composer install
and now we will use a couple of flags
that really we should be using in a
production environment so we will say
optimize autoloader
and it will say no development
we don't need no interaction
what is interaction it can start asking
you are you sure you want to install
that package yes or no and that's
something we cannot have on when we when
we're running Cloud build so here we
have it no Dev optimize Auto loader no
progress here you go so this is
installed and now let's expose the ports
so in this case really we will be using
just 8080 port
however whenever you're running
production case scenario you would want
to remove 8080 you'd want to keep only
8443 Port so now let's quickly glance
through this file to make sure to make
sure that everything looks correct
because you know whenever you're typing
you can make mistakes and that's fine
this is why it's always good to go
through the code
okay though everything looks fine for
myself
so now before we commit everything to
GitHub and set up CI pipeline let's go
to our kubernetes and let's create
the workload so we can close the lateral
documentation you can go to workload and
let's press deploy right here
okay so but whenever we are deployed we
can just deployed the regular regular
engines image I'm gonna press continue
and I'm gonna say backend
and we will keep the fold namespace
right here
I'm going to say deploy
and now I'm going to make another
backend instance and then this one will
be for the staging environment so let's
keep the same engines image which is
very basic and here we will say the same
thing back end and I'm going to put
staging as a namespace okay so
everything checks out everything is fine
and now we have deployed to work
workloads really that was fast
so now
let's make sure that the repository is
connected so first of all let's go to
Cloud build let's go to triggers
and let's set up two triggers let's
press create trigger
and I'm gonna say backend
and now let's add the repository right
here
so now you need to connect a new
repository in my case I'm going to press
continue I'm gonna authenticate
and now it will allow me to select
repositories
here you go I have selected my GitHub
account I have created a repository
and now let's press connect
here you go it was connected so let's
just select it right here
and let's choose master Branch okay
all right and now everything looks fine
here
okay and now let's just take a look how
we called our file so we called it Cloud
build production
so let's just call it the same way here
Cloud build production
and let's hit create
and now let's create one more back-end
trigger for staging environment okay
so backend staging
right here
so let's select our repository once
again I'm going to say staging as a
branch
and here I'm just going to change it to
Cloud build staging
all right
so now let's go back to our workloads
right here and now we have two workloads
backend and back end uh one is under
staging environment another one is under
default environment so now let's go to
our PHP storm right here
and let's go back let's go to Cloud
build production
so now make make sure that you have
proper project ID set up the zone is set
up and here we will change
front-end deployment to back-end
deployment and really this is
all we're doing right here
so let's go down Cloud build staging
and as you as you're really seeing we're
using the same thing we use for
front-end however changing couple of
things
and now let's
emitted with the GitHub so please go
back to your GitHub page right here and
now let's
let's push our code to production to
GitHub
so let me just open my terminal
I'm gonna go to main directory of the
folder
of the project okay getting it
so I'm gonna add all the files
however you want to make sure that you
have proper configuration on the git
ignore and something you don't you want
to ignore
is the vendor folder and as you see it's
already being ignored so so it's fine
all right so now
let's add all files
let's make sure that there is no GitHub
repository initialized under the level
so as you see here I just checked the
files it's fine
so now
let's add all the files it's fine
so now let's make our first commit
and and in this case I'm not copying the
whole thing I'm gonna make a master
Branch as you see master
let's add an origin
and let's push everything to the master
Branch all right
here you go we have submitted our code
to this Repository
let's take a look
here you go and as you see our Cloud
build is spending right now so let's
take a look what's happening here let's
go to Cloud build history
and as you see it's Panic right now so
really what's happening behind the
scenes right now Google is spinning up
the worker pull the one that we are uh
we created so it's right now bringing it
up alive
and it will start processing our image
on that worker pool
and while and while we are waiting for
it to spin up let's just go to workloads
and let's make sure we have nice
configurations there so let's go to the
staging one let's press enrolling update
let's change it to 75 percent here
five percent
this is fine so as far as the auto scale
we can keep it at one really we don't
need Auto scale at this time however
however when you're running production
environment you could have it
I mean you should have that enabled so
now I went to backend which is under
default namespace and I'm going to do
the same thing I pressed as a maximum
paths as a maximum replicas one and now
here you would want to when you never
you're running production environment to
set it up for like 60 70 percent
so let's just do that as an example
so so here we have two metrics CPU 70
percent and memory seventy percent as
soon as it sees that the CPU is coming
high it's going to make new replicas new
instances new pods and this is what you
want to have
all right and let's just quickly do the
same thing for our staging
workload
we are okay here
and let's just add it in
and really if we are using this we want
let's just put it in four three let's
keep maximum three three replicas
let's just do the same thing here as
well
okay and now let's go to our Cloud build
and let's see what is the progress
so here you go we did encounter an issue
so let's take a look what was the
problem right here so as you see here we
were installing node and we don't
need this package and really the problem
problem is that we removed
then pm and node.js however we are
installing it here so let's just remove
this line right here
let's make sure we don't use it no
nowhere else
and now let's make another commit
and I'm gonna say remove
note
here you go
now let's take it look on history and
now it should be able to deploy and
create this build process much more
faster than it did before so let's take
a look
so now our build is running
let's open it
and now we can see that it's pulling the
latest image now it's running
so now let's give it like 30 seconds it
should be it should be done by then
so here everything went pretty well as
you see no errors here it copied the
files copy the application really fast
and now you can see here that we are
running composer install and now it's
installing our packages so everything is
working as expected it exposed the ports
it created the image and now it's
pushing it to container registry and
when done it's gonna update our workload
so let's give it a few more seconds
here you go so now it's
snug has updated the image of our
workload so we can go to kubernetes
engine workloads and now we will see
this error right here it's really
because it's updating
the the image
as you see it's unschedulable right here
so now let's just
put it for minimum two instances
because this way you really won't
experience the downtime because when
another instance is built it becomes
green it's running it's really healthy
only then Google is going to kill the
other old instance
so now let's hit refresh
and as you see currently it's on
scheduleable so what's happening is that
autopilot cluster is so optimized it's
not using resources you don't want to
pay for and this is why it's allocating
the resources right now and when the
resources are allocated it's gonna push
these images and they will be healthy
and let's press refresh one more time
and as you see here it's already
creating our cluster so we have two more
things we have to do in order to access
our backend workload so first of all
let's fix up our yaml file so let's just
press edit right here and this is so
crucial that you know how to use yaml
file so here
really we don't care about this part we
don't care about this part we care only
about the part uh after specs so in this
case as you see here we have two images
one is our image and another one is in
Jinx the one we used to make this
workload so let's just select it and
let's hit delete
let's delete this part as well
and these resource requests are fine
this is okay
and let's press save right here
as you see it's saying that it's
deploying right now another update and
let's just force update it it's fine
okay
so this is okay now let's make the
server so in my case uh there is a
service already created from before
however what you would do in this case
you would press expose you would you're
gonna say 80 here so this is the outside
port and here we will select we will put
8080 because this is the port you're
exposing in a Docker image when you go
to Docker file and as you see here 8080
this is what you're exposing
so now let's select it here let's press
load balancer right here
and just press expose
and now it's going to create a new load
balancer
and usually takes few minutes
maybe one minute to spin up so let's
just wait it
so now after a couple of free verses you
can see that you were assigned a load
balancer ID so let's make sure that we
reserve it as a static IP let's go to
our Network Services let's let's go to
VPC Network external IP addresses
and now let's do Ctrl F and let's search
for AP address so here we go it's a
thermal so we want to make it static I'm
going to call it backend
service AP
here you go we have reserved it so now
let's go back to kubernetes and let's
test it out everything should be working
now
so let's go to back end we're going to
go to default right here
and let's really open any so this was my
old balance this is a new one and as you
see here we are getting an error and
this is fine the very most important
skill is for you to know how to debug it
how to access it and this is what we're
gonna do right now so let's go back here
first of all let's ensure you have only
one pad running because this is
easier to debug it this way let's press
update and now let's open your terminal
and now we will try to access it
so let's open your terminal right here
so first of all you want to authenticate
so let's do that let's just copy your
email so in my case this is a demon CTO
mentorship.com so let's do that gcloud
authenticate
all right it's not allowing me let's
take a look
so the problem is that we have to say of
login
okay this is fine now we want to set the
project ID let's copy the ID here
and now let's say gcloud
config set project
for some reason it basted it two times
it's okay
okay so this this was updated and now
let's get access to this cluster so we
have autopilot cluster one running on a
Zone us yeast
for
so let's do that let's just say the
following in gcloud
container
clusters
get credentials
and we will say
you can copy the name so it is autopilot
cluster one
and it's very important to specify the
zone so in this case it's Us East 4. all
right
so now that was successful so now let's
just go here
so let's open up
and first of all let's just examine
regular logs
Cube CTL logs now you paste in the
workloaded workload ID
and that's it so now when we look at
these logs it's really not helping us
much so that's fine so now let's go to
actual container so we will say Cube CTL
execute the paste in the
pod ID
and let's say sh
so that's the command
you're using
now let's go to HTML folder and let's
take a look what's going on
in the configuration file so here see
it's very simple you're getting some
error here level doesn't like it
so now as you see here it was so simple
we just messed up both environment file
for the lateral because it cannot work
with the environment without an
environment file
so now let's
and really you might ask but hey why
doesn't use this environment file why
the answer is simple it's ignored and we
don't push it to GitHub this is the only
reason okay so now just going here don't
environment file
go to config staging and let's just
paste it in and you can call you can
change the application name from laravel
to level staging and you can keep local
environment
and now let's go to config production
and in this case we'll call our
application Level production
and here you will say
the environment is production
and the debug is false
now let's make this change
now added environment files
and really in production case you would
not be exposing all your environment
files just like that and and I'm going
to show you a couple of Tricks how you
can hide it
by using um secrets from the Google
Cloud kubernetes engine
but now let's take a look on our Cloud
build
as you see it was cute and now whenever
we are done with our Master Branch we
will set up our staging Branch so while
it's loading let's just go to the
staging workload
and let's fix up the yaml file as well
let's go here
and in this case we didn't push anything
yet
it's fine
so in this case let's create a service
in my case the service is already
created
but
let's just press expose
and let's target the 8084 the same way
we did it before it's all right
and again for production scenario you
would put 443 here eight four four three
here and you would not even expose port
80. so let's press expose
and now let's give it one more minute in
order to
in order for it to create
here you go it was created
so now we have our right B right here
let's just make a copy of that let's go
to VPC Network external IP addresses
and let's make a static IP as well
what's reserved
and I'm gonna call it back-end staging
service IP all right
and while we were doing it I'm sure the
back end
part is already ready
take a look if it's still building
yep it's done so now let's go here
here you go the lateral is working
everything is working fine
and now
you can make sure that this is lay this
the image by going to your workload and
taking a look when was the bot created
it was created at 9 10 pm so this was
just now and this is the latest path and
it's working so now let's create a
staging environment
okay so in here we will
say that we want to create a new
environment okay so create Branch
staging from Master okay
so now we just created our staging
branch and it just copied the master
into the stage
so now let's go to our Cloud build
let's take a look and now as you see
it's building our image and the name of
the trigger is back and staging
so here you go on the back end staging
is building so now let's open it and
let's say jump to top
and as you see here it's installing the
packages like the regular stuff
and now it installed all our
configuration files very quickly and now
it's installing the packages
see it was very quick it created its
creating image right now and then it
will push it to the workloads
so now let's go to the workload let's
open the staging one
and now let's give it a few more seconds
it shouldn't be able to it should it
should update it right now
just give it a little bit of time and
press refresh
here you go it updated it
so now we really don't have time and
there's no need for us to wait for it to
work so now let's just press edit
because we have to configure the yaml
file and in this case just find all this
configuration for engine server
starting from termination message policy
and now let's remove it
and now we have our application right
here as you see it's staging
I updated everything is fine
I'm gonna say that that we have minimum
two parts
all right so we need to wait for it to
finish up
now let's hit refresh
so here you go everything is working so
now let's take a look
and whenever we're going to this IP
address it is working so we are getting
Level and now you might be thinking hey
but how do I know it's staging
environment really there are many ways
but let's just
let's make sure that we can change here
level and we will call it lateral State
staging
so now
let's say git pull
and now
and now we got our staging Branch right
here
and now this is what we want to do we
want to put this app name in our
um title so now let's open resources
views welcome to the blade and now we
will change this lateral and we will say
config
app
name
let's just test it out quickly
to make sure it's working all right
see I'm launching the server
here you go so in this case it didn't
change the title title here for some
reason I'm supposing this is really
because of the cash
so let's try to add some character right
here oh no no it's fine because you see
it's exposing the name from the local
environment and it is
layerable as you see here so everything
is working properly
so now let's just close it out
let's make it let's make a comment and
update app name
and really this is really and really you
would not be doing it you will not be
changing title you would be using
lateral for some other things however
this is a really good way for you to see
that this is working that the staging
name and production name are different
so let's get let's say git switch
staging
okay and now we will say git merge
origin master
so now we have chain we can push the
code from Master Branch to staging
branch and now let's say git commit
merge
in this case we don't need that and we
just say git push
so now let's go to the Google ROM let's
go to our Cloud build
and we should be seeing two builds
running one for master one for staging
here you go both are cute so let's give
a couple of minutes for them to build
so as you heat as you see here both
builds are running right now so let's
give it one more minute and we will be
refreshing both of our
workloads
so usually if it doesn't show the
duration of the build here you can just
go to another page come back and as you
see here the duration for this one
is one minute 10 seconds for another one
34 seconds and you can take a look what
is the usual time for it to build
you can see here that this one took
three minutes and then it took 50
seconds so I'm supposing what happened
it just cached
and the second build was faster
all right so let's take a look if this
one is done yet
as you see here it's updating so let's
go to our workloads
and we see that both are currently
updating it's fine so you can just hit
refer refresh give it a little bit of
time
let's
let's wait for staging one to become
available as well
as you see it's almost done
so here you go the third one is already
terminating so no traffic will will be
sent to the spot so we can go ahead
and refresh it
and here you go so you have one level
staging and application name is level
staging and for the second one it's
lateral production
so now you have successfully deployed
both lateral applications and you have
created the CI continuous integration
environment for the laravel
on the GitHub so now the things that you
would want to add
let's go back here to front end
you would really want that
the Readiness probe because this is
always a good practice to add Readiness
probe
for your application however in next
video I'm gonna talk about liveness
probe and we will add both probes to our
lateral application
in this video we're gonna talk about
liveness probe so first of all what is
it what do we need and what is the use
case so imagine that your application is
running everything is fine and then at
some moment it it gets some Deadlocks or
something happens and it it just doesn't
work and
that those things can happen
unfortunately ideally you would fix up
your application for it to not happen
however if that happens there's a way
for vocal to be restarted so imagine
it's deploying your pods and you have 10
parts and one of the Pod really becomes
unresponsive it just does not want to
work and and we can tell kubernetes hey
if this spot doesn't work for x amount
of time go ahead and restart it and what
it's going to do we're just gonna kill
it and it's gonna recreate it and this
way it's very good because this way you
can ensure that all your workloads all
your pods are healthy at all times so
now let's install it for a back-end
instance so let's press on backhand
let's hit edit button
and
and let's scroll down
to this path so resources so first of
all you don't want to invent the wheel
we are not here to invent the wheel so
now let's go to front end
so this is your old workload
this is where we install the Readiness
probe so now let's just copy this part
right here
and let's paste it here as well
and and paste it one more time so
imagine that
Readiness probe and liveness probe are
very similar
so in this case we're just going to
change the second one and we will call
it
to see aliveness
probe
and the configuration file is the same
so here we can say if it's failing let's
say four times uh initial delay 30
seconds and it should be attempting to
query our application every second
so let's hit save
and just in case if in case you're
wondering you want to get some
documentation on how does it work or or
something else you could just go ahead
copy it go to Google and here you go
Google is going to give you the
documentation for kubernetes where they
will show you how the liveness probe
works and they will show you a couple of
more configurations however I find it
very useful
so by the way let's just copy this one
here so we can put it for the staging
workload as well let's hit save here
so this was ours actually this was our
staging workload so now let's go to the
master
one
let's hit edit
let's scroll down
and after resources we're just gonna
paste it in right here okay so just hit
save
as you see here it's unschedulable
that's all right
staging one is currently updating it
it's okay as you see the the same way we
were experiencing the redness probe when
we are working on the front end it's
very similar here as you see that the
Pod is under status running
It's really because we added initial
delay for 30 seconds so we want to give
your application 30 seconds before we
start sending requests to your
application so let's hit refresh
as you see here so this was deployed
first pod was deployed and another one
is awaiting
so now let's go to another instance
right here the default one
and in this case what I would do I would
increase it to two parts two replicas
because this way it's going to be able
to deploy a little bit faster
so just refresh it and you can see that
we have two parts that are currently
running they're awaiting
the delay
so let's give them 10 more seconds and
they should turn green and this one this
old part should be terminated
not yet let's wait
here you go yep so they are fine so see
this old part is being terminated and
two new parts are healthy so now let's
go back to our instances and we can
ensure that everything is working fine
here
okay so this is how we deploy and use
liveness probe
you might ask
and how does our application is going to
use it it's very simple as soon as your
application crashes and something
happens there it's just gonna restart
and how you would see it you can just go
to your workload right here and where it
says restarts right here zero currently
it's zero but if your application
decides to restart and Google kubernetes
engine restarts it you will see that
this number zero is going to increase
and look out for those numbers because
if your application is constantly
restarting most likely it needs more
memory or CPU or something is wrong this
is why it's so important to look out and
monitor your CPU memory in disk risk
requests
something I wanted to talk about with
you is why did we choose engines
and this is a very important topic
because whenever you're deploying any
application whether it's layerable or
something else
it's always about choosing web server
and it's very important question
because
imagine you build your application and
all your response times are quick
your queries are quick
everything is cached everything is
optimized however it's still slow all
your users users complaining that your
backend is slow the response times is
one second and so on and then you start
thinking why is it the case I'm using
PHP I'm using glarevel everything's fine
and as you see it's not always about
your applications not always about your
code it's also the web server this is
why choosing the right web server is so
important for you and you might have
heard about of Apache I think everyone
has heard about Apache and this is
really the web server that everybody was
using and and
think about it it's really great however
when you start thinking about
performance you want to get the lowest
times the lowest response times and get
the most performance all out of it you
want to use engines
because in Jinx is is built with the
idea that it's really it's very similar
to Apache however it brings the ultimate
performance and this is a very simple
way how we can test it so let's let's
just go to level production or staging
doesn't matter and you can take a look
how much time does it take in Jinx to
return this web page and you see it's
40 milliseconds and the smallest I've
seen was 36 milliseconds just now and
it's very quick
and if you would want to Benchmark you
can either go online and take a look on
the benchmarks between Apache and
engines or you can just deploy Apache on
this Docker container and take a look
what are going to be response times
but even if the response time is fine
for this empty project whenever you are
running your big application and getting
thousands upon thousands of requests at
the same time Apache starts slowing down
however engines remains very fast and
this is the only reason why we used
engines in this tutorial
something I wanted to mention is you
might be thinking why does it take us so
much time to deploy a level on a
production and staging environment it
really took us so much time because we
were doing everything from scratch
however whenever you're creating
multiple lateral applications such as
some API some back-end service some
robot service some calculation server
and so many more apis and servers you
would be having some template and really
the template I'm talking about is this
one so please go to your backend
project
and take a look right here so you would
you would have this configuration file
so this is that you are using for your
level application you just change your
environment files and here you would be
having different level application
however this wrapper all the production
yaml files and so on they would remain
the same this is why whenever you will
deploy your next level application it
will take you maybe five to ten minutes
it will be much quicker than that
whenever you're deploying your lateral
application to production you want to
make sure it's as secure as possible and
currently the way we have it set up is
that all your environment is exposed
publicly and that's not the way you
should have it so let's work on it so
first of all let's make your environment
configuration file so in this case I'm
going to make a new folder I'm going to
call it security or I'm going to say
credentials all right
and I'm gonna say
um I'm gonna create a new file so let me
just use
a terminal as you see it doesn't allow
me to create a new file it's fine let me
use a terminal I'm gonna go to security
actual credentials and I'm gonna say
touch
and I'm gonna call them
credentials dot Json okay and we will
make another credentials which are going
to be staging credentials
dot Json all right and now we have two
files that we have created
so now let's open each of the files okay
let's open credentials
we can use the text edit app it's fine
now let's create a Json format and now
let's say
and now in this file what we're going to
use it for we will expose our
environment configurations in this file
so in this case whatever we want to
expose it's really the app app key
let me just make a copy of this
let me expose that name as well
so you have it as an example
in this case we will call it I mean it's
called level production
and really in production case scenario
you would put all your database config
any other passwords any other
credentials you would keep in this file
so now we will use only two things one
is app name and second one is app key
all right so this Json file is fine
let's save it
and let's open another file the staging
credentials file all right
so now let's just copy paste it
and let's go
right here
let's just change this name right here
and now you see we have a problem that
the key is the same so we can go back to
our backend instance
okay and let's go to level and I'm gonna
say PHP artisan
key generate
it has created the new key for myself
I'm gonna go to environment file right
here and I'm going to grab this key I'm
going to go to config staging
as you see we can change it up here
it's really what we want to do
we want to go here and change it up
so now we have created two credential
files and obviously we don't want to
store these files locally so let's go
back to these files and we will upload
them as secret credentials on Google
Cloud okay
let's open the credentials folder and
now let's execute the following command
and before we can execute the right
command in order in order to boost these
credentials to your cluster you have to
ensure that you have logged in that you
did run Google Cloud
authentication login your email and you
got credentials of your cluster and just
in case if yeah
forgot the way the way you do it you
would set up Google Cloud project set
send to your ID and then you would get
credentials in the following way you
would say Google Cloud container
clusters
and then you would say your autopilot
cluster and you would specify the zone
you assist for okay so let's assume
you've done that and now we will push
these credentials all right
it's now we will do the following we
will say Cube
CTL okay since the command is working
create Secret
and this is going to be generic type of
the secret I mean there are more you
could push your DLS SSL certificate to a
cluster and more in this case it's
really generic credentials that you're
pushing and they will be called
credentials
the way it works you have to save from
file
you specify credentials the Json
and credentials.json all right
here you go this was created and now we
need to create the same thing however
for the staging environment so now
what's going to change
so here I'm going to change this one to
staging credentials and I'm going to
specify namespace so the way we do it we
just say n
and we say staging
so now both secrets were created so now
let's go to our cluster right here
and let's open Secrets and config Maps
and as you see here the credentials
under default and staging they were
created
so we did the first part the most
important part and now you might be
thinking so how do I get these
credentials attached to our laravel
application so first of all we want to
attach them to the workload so let's go
here let's open our backend staging
workload and at the same time let's open
our front-end yam file so you would just
open your front-end workload press edit
and let's take a look the way these
credentials were attached so you're
really doing it on the volume level so
here let's attach the volume to this
workload
so you would do it this way volume
credentials secret name is credentials
and now you want to mount it for your
container so now we're doing the same
thing so volume outs mounts we are
mounting your credentials under this
directory and the name of it is
credentials all right now I'm gonna hit
save right here
and let's just do the same thing for the
master
now let's open it let's press edit
all right so now let's do the same thing
let's just copy the bottom part the
volumes
let's rename it to credentials
and again you can keep it under any name
you want it to be
so the same thing copy paste
and we changed it up
so now before we Implement anything on a
level let's make sure that you're able
to access them
in your image
in your container so let's open the
terminal
let's clear it and I'm going to say Cube
CTL execute
e
and Sh so before I do it I want to make
sure that the instance is at least
running
so now I mean hit refresh
and you see so it's already running so I
can go ahead and execute it
here you go I have accessed
so now
I just went to the main folder and now
I'm going to go to this folder Secrets
environment okay we are here and let's
take a look on our credentials so here
we go here is our Json file
so now we got that part established that
we have created the credentials we have
uploaded them to the cluster and we have
linked them with the workload and now
they are accessible from your lateral
application and you might ask so how do
I actually exchange the environment file
so take a look this is what we're gonna
do
go back to this part right here let's
examine config production file right
here
okay
and now let's change this part app name
let's change it up to app name this way
and we will do the same thing with the
app key
and a lot now let's go to the config
staging
let's do the same thing
and as you see now we're not exposing
any credentials on GitHub
now it will be safe no problems however
now we need to insert the information
from your Json file into this
environment file how do we do it
we can do it the following way
so we'll go back here's SRC www
and let's create a new file I'm going to
call it init .php
and you want to add it to the GitHub
location
okay and now we want to define a couple
of things right here okay so first of
all is location of your environment file
so
we know it's in this location secrets
environment and credentials that Json
and the environment file is is located
in this location
and now you want to take these
credentials and insert them right here
and we can do it the following way so
first of all let's let's get the
credentials
so we can do it the following way okay
array
Json code
and we are getting the contents of the
file
so now we have your connection files in
Array and
we make a comment and we will say here
so first of all we want to open your
file
get contents
environment file
and so usually it's better to specify
that it's file so environment file
and let's open it up right here
open
in a right mode
now take take a look on this so now we
are iterating our credentials as Keen
value
and now we are replacing
let's take a look
we are replacing
this part
but this part that you have defined in
your Json file
so whenever you understand it it becomes
very simple so in this case we are
searching
for key
and we are replacing it with the Valor
so in this case you can see that I'm
adding extra apostrops this is to make
sure if credentials are long or they
have special characters they're not
gonna break the environment file this is
a good practice
okay so this is done now let's
write
B
here and now let's close the file
okay and this file again it's going to
take all your credentials and they're
gonna insert them in the environment
file okay so as you see we are receiving
some errands something is off here so
let's take a look
what is the problem okay
so as you may know PHP might be acting
sometimes so in this case I just remove
this line I put it back and there are no
errors right here all right so now let's
go back to our backend instance right
here
let's
make a comment
so I'm gonna say initialize
credentials the right way
and now we're pushing it to the staging
okay
so everything should turn the blue color
disappeared so now let's do the same for
the master let's go to master get switch
Master get the merge origin staging
and
let's just say git push
all right
and now let's just go to your GitHub
real quick
and let's take a look on something
so now here as you see the way the
credentials are stored config production
config staging whenever you go to your
environment file you will see that the
name of the application app name and app
key they are not exposed and now you're
really safe because the only place where
your credentials are stored at is on the
cluster level and they are not stored on
a cold level not in GitHub therefore
you're safe now and this is really the
way you should be deploying lateral
always have to keep credentials safe
so now let's wait for the build to
create and then we will test it and make
sure that the proper keys and proper
application names are on each side
so you see the mess the staging branch
is already building and the master
branch is currently waiting for the
build
so now let's go to the workloads
so as you see here the master is already
working
it was deployed just now
and now let's go back to the staging
workloads
and let's take a look right here
all right
so as you see here it's getting
restarted and what this means that there
is some error and there is the following
now I wanted to show you the way restart
Works actually because whenever larval
starts running it gets some fatal error
and
it gets restarted okay so in this case
as you see the radio started four times
and really the problem is yes we created
in that PHP however if you are not
running this file nowhere in our code
and that's a problem
because now if it doesn't know that it
has to run
Laro will see this
in environment configuration and it's
just not gonna known it's gonna throw
never so now let's do the following
let's go to our entry point and entry
point this is a very good place to
initialize some scripts that you want to
run before your laravel application
starts so let's
call the script PHP
and location of your init PHP file
and let's ensure
and actually in the PHP will be copied
because the way we are doing it here
whenever we are copying the files we are
copying the whole WWE directory this is
why this file will be copied right there
all right so now let's make a comment
right here
call in PHP
all right now let's switch to staging
and let's merge
Master into the staging
now let's go back to master
okay
so now we should have two Cloud builds
running so let's give them two more
minutes and then we'll try again and see
if it works then
and by the way uh you see because they
are crashing this Cloud build is not
going to stop because it's waiting for
for them to deploy and become
like become green become healthy and
it's not going to happen so in this case
we can just press cancel usually takes
30 seconds to be canceled so give it a
little bit of time
don't
exit this page yet
so here you go it's canceled
let's just cancel this one as well
all right and now let's wait for these
two
images to be deployed
it's not their building let's take a
look if they are done yet
he doesn't want to load it's all right
okay so it's pushing the image it's
almost done
see one minute usually at one minute 40
seconds and deploys so give or take 30
more seconds
so let's go to our workloads
and as you see here it's currently
deploying the new image okay
it does the same for the staging okay so
it seems like it's working there are no
restarts right here and let me do the
following let's just go to
this instance default one
and now let's go ahead and connect to
this instance and let's take a look if
the credentials were initialized
properly
such as connected I'm going to the root
directory
and I'm getting information of the
environment file and right here as you
see everything worked fine the
application names level production and
level has app key right here so let's
take a look if our pod became healthy
yet
as you see hasn't killed the seventh one
so so let's not refresh it yet because
the result might be 4C
okay so the most important thing that
this one is working it's replacing your
your labels your placeholders
so now let's
just wait few more seconds
okay so the staging is already working
as you see as you see here it's
refreshed everything is going through
and let's wait for the production to
remove the old instance as you see here
it has removed
and whenever you hit refresh it's
working fine so so this is how you can
ensure that your level application is
very safe it's really by putting these
special names and and hiding your data
and exposing it and saving it on a
cluster level level I hope you found
this lesson very productive because
security is one of the most important
things and kubernetes engine cluster
allows us to be extremely secure because
you can manage all your credentials and
you can save them on this cluster