Today marks the end of the Azure Academy pilot. I had fun talking with students about Azure, Automation, PowerShell and DevOPS.
For those that do not know what Azure Academy is. It’s the school for training students and people that want a chance to start a new chapter in their professional career using Azure as there starting point.
My involvement in Azure Academy is to teach IaaS, Networking, best practices in Azure, infrastructure design patterns, automation with ARM and PowerShell and doing infrastructure as code with CI/CD pipelines.
This was an amazing experience for me because I got to see first-hand what passionate people look like and see what determination and the will to change and evolve looks like.
It was also a pleasure to see how people are able to change their mindsets in order to understand what it means to be in the Azure world and work hard to get to the point of actually changing there lives.
If we look at the statistics of Azure, we will see that most of the Virtual Machines that are deployed are running Linux. There’s a good reason as to why to run Linux applications, and I’m not going to cover that in this blog article. Today I will be talking about running Linux Web Applications in Azure’s App Services offering.
You may or may not know that Azure App Services run on IIS so in a nutshell, when you spin up an App Service and deploy a Web Application, you’re deploying that code using the same worker process with one application pool per website. So you’re not provisioning a single virtual machine to host your Web App instead you’re receiving space on an existing VM to host your application.
The main problem with App Services was that you could only host applications on IIS thus limiting your options. You have the possibility of running PHP or Java applications on IIS, but they wouldn’t be as performant as you would expect. Microsoft solved the problem by introducing Containers for Web Apps. You spin up a Linux App Service, and from there you deploy your application on an Apache solution (prebuilt) or a container built by you.
Why containers you might say?
Containers have been around for a long time, and they allow you to consistently run your application in any environment you want without having to say “It works on my machine”. API that was chosen to create, deploy, run containers is Docker. Most people call those containers as Docker Containers, but in reality, Docker is just the API that allows you to create/manage those containers. The main idea is that if you create a container that runs your web application without problems, then you can just take that container and deploy it anywhere because the code and all your dependencies are held in that image.
So how publish/pushh / push my container in a Linux App Service?
Taking your image and pushing it in a Linux App Service is very simple. You first have to have your container image pushed in a public/private repository like Azure Container Registry or Docker Hub then you just create a Web App for Containers and reference your image.
How do I deploy my code in a consistent manner?
Creating images in a centralized consistent manner is quite different than working alone on your laptop. Web App for Container has integration with most of the thing that you would use to deploy your code in a regular Windows App Service.
There are a couple of ways of pushing your code to the Linux App Service:
1. You can create your container image and push it to a repository like Azure Container Registry or Docker Hub.
2. You can use a CI/CD engine like VSTS to create your image and push it to the registry.
3. You just upload your files via FTP and be done with it 🙂
Down below is a demo flow of how you would push an image to the Web App for Containers service
Now if you’re used to App Services running IIS, there are some limitations that you should be aware of.
1. Containers are stateless by nature – If you need persistence you need to leverage blob storage or use another service like Redis Cache or you can leverage a feature to mount the /home directory to an Azure Files share. The latter will downgrade your performance a lot so tread carefully.
2. You only get ports 80/443 so if you need a custom port for your web application then App Services will not allow it.
3. You don’t have Web Jobs
4. You cannot do VNET integration
5. You cannot do Authorization with Azure AD
This is just a number of limitations that you should be aware of. Some features that you get from a regular App Service will eventually pop up in the Linux ones but until then, you need to work with what you have 🙂
That being said, take a look at Web Apps in Containers, play around with them and see what you can come up with.