I am excited to announce that I published a Laravel course on Pluralsight! This course is titled “Laravel 9: The Big Picture“. This is my 16th course with Pluralsight. I have been working with PHP based websites, Content Management Systems, Frameworks, and the language off and on for many years. When the opportunity came to author a course on Laravel I jumped on it.
Laravel is a full-stack web framework for modern PHP based web applications. PHP is a language that has been around for a long time used to power most of the web site and web apps on the internet today. And some of the best web development teams in the world build their products with Laravel.
Many don’t know this but Laravel can be used for front-end and back-end development, as well as developing a REST API. Some of the largest companies and most popular websites have been built using Laravel such as Disney, Apple, Pfizer, BBC, Twitch, Mastercard, and more.
In this course, Laravel 9: The Big Picture, you’ll learn about the Laravel full-stack framework. First, you’ll explore Laravel’s core components such as: routing, middleware, controllers, requests, responses, views, blade templates, and more. Next, you’ll discover how to install Laravel, configure it, how it handles security, works with databases, about its APIs and more. Finally, you’ll learn what it is like to develop, build, and deploy an app with Laravel.
When you’re finished with this course, you’ll have the skills and knowledge of Laravel needed to decide if it is the right PHP web framework for you and where to go next on your journey with Laravel.
I hope you find value in this new Laravel 9: The Big Picture course. Be sure to follow my profile on Pluralsight so you will be notified as I release new courses!
I am giving a talk for the Data on Kubernetes Community (DoKC) Community next week. They are a user group like community that focuses on how to build and operate data-centric applications on Kubernetes. Be sure to check them out! The DoK website is: https://dok.community.
My talk is titled: “Running Stateful Apps in Kubernetes Made Simple“
ABSTRACT OF THE TALK
Eventually, the time will come to run a stateful app in Kubernetes. This can be a scary thing adding more moving parts to a Kubernetes cluster and deploying as well as managing your app on Kubernetes when it requires state.
In this talk, Steve Buchanan will take you through a journey of understanding how storage works in Kubernetes, how to Persistent state with pods, what storage options are available with Azure Kubernetes Service, best practices, and a demo of deploying a stateful app to AKS.
In the demo, I will show how to deploy stateful Worpress & Jenkins workloads on Azure Kubernetes Service using the GitOps model with Argo CD.
KEY TAKE-AWAYS FROM THE TALK
Overview of Storage in Kubernetes covering Storage Classes, Persistent Volumes, & Persistent Volume Claims. Overview of Azure Storage, Best Practices to running stateful apps in Kubernetes.
I recently published a blog post on 4sysops.com about Web App for Containers on Azure here: https://4sysops.com/archives/web-app-for-containers-on-azure. That blog post is about the often-overlooked service in Azure that can be used to host a container/s on a web app in Azure App service.
This is a great service if you just need to run a single container or even a couple of containers that you have in Docker Compose. This service is PaaS and abstracts away an orchestration system like Kubernetes. If you need insight into the Azure App Service Web App for Containers service check out the blog post on 4sysops.
In this long blog post I am going to take things a step further and walk-through the build & release of a Container from Azure DevOps to Azure Web App for Containers. The overall goal of this post is to help someone else out if they want to setup a build and release pipeline for building and deploying a container to Azure App Service. We will use a very simple PHP web app I built that will run in the container.
Here are the components that are involved in this scenario:
Azure Container Registry (ACR): We will use this to store our container image. We will be pushing up the container image and pull it back down from the registry as a part of the build and release process.
Azure DevOps (ADO): This is the DevOps tooling we will use to build our container, push it up to ACR, pull it down into our release pipeline and then deploy to our Azure App Service.
App Service Web App for Containers: This is the web server service on Azure that will be used to host our container. Under the hood this will be a container that is running Linux and Apache to host the PHP web app.
Here is the data Flow for our containerized web app:
Deploy the Azure App Service Web App for Containers instance
Deploy the Azure Container Registry
Deploy the Azure DevOps organization and project, create repository to host the code, clone repository in VS Code (Not shown in this blog post. Assume you know how to this up.)
Update the application code (PHP code and Docker image) in Visual Studio code
Commit application code from Visual Studio code to the Azure DevOps repo (Not shown in this blog post. Assume you know how to this up.)
Setup build and then run container build and push the container image to ACR
Setup release pipeline and then kick off the release pipeline pulling down the container image from ACR and deploys the container to the App Service Web App for Containers instance.
Here is a diagram detailing out the build and release process we will be using:
Ok. Let’s get into the setup of core components of the solution and the various parts of the build and release pipeline.
For starters this solution will need a project in Azure DevOps with a repo. Create a project in Azure DevOps and a repo based on Git. Name the repo exerciseoftheday. Next up let’s create the core framework we need in Azure.
Deploy Azure App Service Web App for Containers
Let’s create the Azure App Service Web App for Containers that will be needed. We will need a resource group, an app service plan and then we can setup the app service. The PHP app we will be running is named Exercise Of The Day (EOTD) for short so our resources will use EOTD. Use the following steps to set all of this up.
We will do everything via Azure Cloud Shell. Go to https://shell.azure.com/ or launch Cloud Shell within VS Code.
Run the following Syntax:
# Create a resource group
az group create –name EOTDWebAppRG –location centralus
# Create an Azure App Service plan
az appservice plan create –name EOTDAppServicePlan –resource-group EOTDWebAppRG –sku S1 –is-linux
# Create an Azure App Service Web App for Containers
Note the loginServer from the output. This is the FQDN of the registry. Normally we would need this, admin enabled, and the password to log into the registry. In this scenario we won’t need admin enabled or the password because we will be adding a connection to Azure DevOps and the pipelines will handle pushing to and pulling the image from the registry.
When it’s all done you should see the following resources in the new resource group:
Next, we will need to build an application and a container image.
This will be a short
post and this one is mostly for me so I can easily find this information in the
future when I need it again. 🙂
Recently I was
containerizing some PHP websites that use Composer. If you are not familiar
with Composer but you are working with PHP, you will run across it at some
point. Composer is a dependency package manager for PHP. Composer manages
(install/update) any required libraries and dependencies needed for your PHP
site.
To use Composer you must first declare the libraries and dependencies in a composer.json file in your site directory and then you would run Composer and it will do its magic. For more information on Composer visit: https://getcomposer.org/doc/00-intro.md
Back to my task, I
needed to install Composer in the containers I was building and run it to
install all the dependencies. I needed these actions in the Dockerfile so it
would all happen during the container build. After some research on Composer I
was able to pull something together. Here is the syntax that I ended up putting
in the Dockerfile:
# Install Composer
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
# Set working directory for composer (Contains the composer.json file)
WORKDIR /var/www/html/sitename
# Run Composer
RUN composer install
Note: I placed the above code at the end of the
Dockerfile ensuring Apache, PHP etc was all in place first.
