Azure – Azure kitchen

April 13, 2022April 18, 2022

Create and host a WordPress blog on Azure for FREE

Many people are looking for building their own online blog.

One of the very popular online blog engines or websites, that had gained a lot of traction in the past, I would say 10 to 15 years, is WordPress.

People like WordPress because there is a huge community of developers, content creators around WordPress and because it’s open source. There are also a lot of plugins, a lot of themes and a lot of integrations with other services (payment gateway, cart, SEO …etc.)

You can even have an online store (e-commerce website) built on top of WordPress with free plugins. I think WordPress is pretty cool.

We at FaceGraph, have used WordPress to build our online store [https://shop.facegraph.com] that sold thousands of dollars of our products online and pretty much costs us 2 hours to setup!

The problem now is not the cost of WordPress itself since its open source, it is the cost of hosting WordPress. One of the things I liked in the past is the ability to host a WordPress website in the cloud for free. And to be clear, I am talking about the Microsoft Azure cloud.

WordPress consists today of two main components, the web server and a database which runs on MySQL.

In the past, if you have used Microsoft Azure. You were able to create an A WordPress blog using the Microsoft ‘WordPress’ listing in the Azure marketplace. That allowed you to create an app service plan to host the web component and more importantly also host the MySQL database in the same app service.

Unfortunately, that option is no longer available. If you go check the Azure Portal marketplace today, you will find there is only one title by WordPress “WordPress”. And there are many other word press titles by other companies.

The WordPress listing allows you to create a WordPress blog for free, which is very convenient. However, it will basically create a new app service plan and it will also create a standalone Azure MySQL instance.

This setup might be good for production, heavy load, performant website. The cost of the hosting this setup will be about $146 a month.

Estimated hosting cost for the current WordPress deployment on Azure

That might be hefty for someone who’s looking for an economical option.

If you want to have an economic option, an option to host a lightly accessed blog {like this one for instance 😊}, you may not want to consider a different option.

The solution

The solution to that is to use this ARM template WordPress on App Service with MySQL In App (microsoft.com) by Gerardo Saca.

This arm template will allow you to deploy the old WordPress title where you can have an Azure app service created uses the free tier by default and also have the MySQL database instance created in app.

The two Azure resources that get created after deploying WordPress using the ARM-Template

MYSQL instance that is hosting the WordPress blog content hosted in App inside the App Service

At the end of the day, you basically can pay nothing for hosting your WordPress website as you used to be in the past.

Obviously, needless to say this is not really an ideal setup for production. You bear the risk of losing your database without redundancy, the performance will also be impacted since you share the App service plan resource between the website and the database. However, it’s a good cheap option, it works and takes 5 minutes to setup!

To be a good citizen of Azure, and follow your whatever governance and naming convention you may have, I would strongly recommend you to edit the template before your deploy it, locate the following two variables and updated them with your own desired name for the app service plan as well as the web app service name:

For instance you can change them from this:

To this:

Lastly, one of the things you will want to do in your WordPress blog is to change the look the appearance. You probably will look for existing themes or maybe try to import a new theme.

Check this website. https://elements.envato.com which has a huge library of electronic marketing assets and great themes for WordPress.

One of the things you’re going to face when you try to import a theme that has a lot of graphics especially if it’s big say around 10-15 MB is a problem importing the theme zip package.

You will get an error message like this:

“the page was not displayed because the request entity is too large.”

To fix this issue you have to change the settings of your web server to allow larger requests. If you have hosted your application on a Windows based app service. This is how you fix it. You add this configuration in the web.config:

New configuration added to the web application configuration to allow larger content requests

  <security>
  <requestFiltering>
     <requestLimits maxAllowedContentLength="99500000" />  <!-- 99.5 MB -->
  </requestFiltering>
  </security>

I hope that in-app hosting of MySQL continues to be available as it saves a lot of money (in this case 100% of cost) for hosting a WordPress blog.

The question now is, can you do this in AWS?

May 14, 2020May 15, 2020

Authenticate to TF.exe CMD in Azure DevOps with OAuth

If you are using TFS or now called Azure DevOps and still maintain a TFVC project (source code) you may not have many options for automating certain tasks.

In this article I will touch on the use of TF.exe which does some unique commands that can only be done with that command line utility none-interactively (in a script or command shell for the purpose of automation). I will focus more on the bigger problem that you will encounter, which is how can you authenticate the TF.exe utility none-interactively in a script being run in Azure DevOps for example.

Background

Building workflows (CICD) for your projects require executing certain tasks to get the job done. Now that DevOps is so popular you will find lots of good tools and resources that covers common scenarios for CICD and test automation. Most of which revolve around using GIT repos. For those older projects that still use a centralized code repository system like TFVC, you may not find tons of documentation.

In modern DevOps tools and code storage systems you can either use the GIT protocol or REST APIs to accomplish most of the build or deployment tasks through an automated task scheduler. That allows you to run specific tasks through scripts or web requests. TFS or Azure DevOps supports GIT as well as REST APIs. However, if you are using TFVC (Team foundation version control) you have a smaller set of options beside the precanned and marketplace CICD tasks.

One option would be to use REST APIs: TFVC REST API the problem with this endpoint is that it mostly offers APIs for reading data. You cannot do things like branch merges, check-ins …etc.

TFVC REST API covers read operations for the following:

Branches
Changesets
Items
Labels
Shelvesets

The alternative is to use the Team foundation command line TF.exe. This tool comes in handy, if you want to get things done with your TFVC source code that require changes or updates. Things like delete, rename, shelve, merges and check-in\check-out.

For more information about TF.EXE check out Team Foundation commands

The problem

Using TF.exe is fun and can get things done easily with the available rich set of commands. It also works with the most recent version of Azure DevOps (cloud & server).

For example, if you want to create a new workspace you run the following command:

>tf.exe workspace /new /collection:https://afaragtfvc.visualstudio.com/

As you see above, because we are accessing a private project on Azure DevOps we are required to login. This will show an interactive screen that will let you login with your credentials. After successful login I can continue the execution of the script and get the workspace created.

What if this will run on an agent in build task unattended? well, you will need to make sure you don’t get prompt for credentials but rather enter them part of the command line.

The good news is, there is a switch for that. You can use the ‘/noprompt’ switch to prevent interactive prompts. However, if your current user running the command line doesn’t have an active auth session with Azure DevOps you will be access denied:

We also have a switch to login without a prompt using the command line:

/login:username,password: If you want to run the command as another user, you must specify the /login option verbatim, replace username with the name of the user, and if necessary, you can supply the password.

The problem with this switch is that Azure DevOps no longer supports basic login with a user name and password.

Azure DevOps no longer supports Alternate Credentials authentication since the beginning of March 2, 2020. If you’re still using Alternate Credentials, then they won’t work anymore. You have to switch to a more secure authentication method, to mitigate this breaking change impacting your DevOps workflows.
Tell me more …

The solution

There must be a way to authenticate that command line with the modern OAuth (JWT) tokens. With some close inspection to the built-in Azure DevOps tasks for TFVC pipelines I can see clearly that Azure DevOps uses TF.exe to get the latest code …etc.

TF.exe commands executed in Azure DevOps

You will notice that there is an undocumented switch being used called ‘/loginType:OAuth’ !! That’s exactly what we need.

Now, the last hurdle, how do we get an OAuth token? And make sure it hasn’t expired before we use it? How do we renew it?

Luckily that is something handled very well in Azure DevOps. ADO itself uses your credentials\PAT to issue an OAuth token when needed and stores it as an environment variable that you can consume in your script.

The variable is called $(System.AccessToken). To be able to use it you have to do an extra step to enable it in your pipeline. Edit your pipeline and click on the agent job node where the command line task will be running under then select ”Allow scripts to access the OAuth token”

Now you are ready to use that env variable in your script as follows:

>tf.exe workspaces /format:xml /collection:https://afaragtfvc.visualstudio.com/ /loginType:OAuth /login:.,$(System.AccessToken) /noprompt

That should work flawlessly in Azure DevOps

ADO Pipeline with TF.exe command auth. w/ OAuth

You can also get the raw JWT and insert it in the command if you like to test locally on your machine, but I wouldn’t recommend using that static token on Azure DevOps pipeline as it will expire and break your pipeline at some point.

tf.exe workspaces /format:xml /noprompt /collection:https://collectionName.visualstudio.com/ /loginType:OAuth /login:.,eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Im9PdmN6NU1fN3AtSGpJS2xGWHo5M3VfVjBabyJ9.eyJuYW1laWQiOiI1NmE5ZDJhYi1iMjk1LTQwNjgtYjA2Yy1jNGRiMGIxNmE1YjQiLCJzY3AiOiJhcHBfdG9rZW4iLCJhdWkiOiIyZjgyYTNiZS04MmE4LTQxMzgtYTA5eS1iNDU2MDBiZjY2ZGMiLCJzaWQiOiI2MDtmNTRhNS1hNjlmLTRhYjUtYWE2Zi1mZTZiNjJhMGJiZDYiLCJCdWlsZElkIjoiMTllNrdkMDctZDIwYS00ZWJiLTk5NzYtMjMyYhIwMTkxNTc1OzciLCJvcmNoaWQiOiJmMjA3MTQxNC04MDQwLTRlZTItOGMxMy01MTg4Yjc4MmZiZTMuam9iXzEuX19kZWZhdWx0IiwicmVwb0lkcyI6IiIsImlzcyI6ImFwcC52c3Rva2VuLnZpc3VhbHN0dWRpby5jb20iLCJhdWQiOiJhcHAudnN0b2tlbi52aXN1YWxzdHVkaW8uY29tfHZzbzphZTEyNDFiYi0xMzQ3LTRiNzUtODg1YS05ZmNiMzczMwYxMjYiLCJuYmYiOjE1ODk1MDYyMzcsImV4cCI6MTU4OTUxMTAzN30.GcoNwj1Kco69N8r78EN2CMBnzhrZRX5Ye2ihTAw0mVIQtyRl20y1vxgb-kzgkEeVGXaYO3Waz7meBxJftlKLtE8hZX6KyNlbgrEh0y8iJmbg1Ry2xlLV-LSSu9Ij_LW3vnJtWbDKeGeca_Vx_78kR2t0VWABiq-ldaDfauOWp2hGEmJ7wVxkh6IxDp0GbxRMNdExeqeLlFrU5Mr1aK1dJWCSWulLba8zDCUr0_gZlXVpcWmeO-KkWWUUHGWtd2gI2RFIe7Nl47aWf6pv9M3mUyP_aAloCaA7t0DV34KjqlGxPsxn6uGxrDtOXFE7XQZQp9Y7vkbgC-uTcgv99I7H1Q

March 16, 2019March 16, 2019

Azure App Service Storage

Each app service storage tier provides a specific storage quota to use for hosting your app artifacts (code, media assets … etc.).

If you are using the smaller tiers (Dev\Test) you will be sensitive to storage limits more than higher tiers (production and isolated) but this also depends on your application.

At the time of writing this article, this is how much storage you can get per tier:

Azure App Service tiers – Storage options

For more information and the latest quotas and prices go to:

https://azure.microsoft.com/en-us/pricing/details/app-service/windows/

Some applications use the web server storage to store temp files that gets generated in the lifecycle of the web application. In a lot of scenarios, it would be better to use a different type of storage away from the web server but in certain cases it makes sense. Either way, I’m not going to touch on this topic in this article but I wanted to highlight that if your application is writing files to the webserver – in this case the app service in Azure – make sure you clean them up periodically.

You don’t want to run out of storage in your app service, you also don’t want to pay for a higher tier just because you cannot keep your storage under control.

Other than your code being the main reason to periodically increase the size of your app service there are other things that can cause this to happen too, some are obvious, and some aren’t.

In this article I will highlight some of the potential contributors to storage increases in Azure app service and how to get that under control.

Before we go there, its good to know few important basics.

Each app service is hosted in an app service plan. Think of the app service plan as a virtual web farm that hosts your code. The app service is your application virtual folder (e.g. wwwroot folder).

That means if you have multiple app services hosted on a single app service plan, all the app services will share the allowed storage for that app service plan.

How much storage is my app consuming?

First thing you usually need to know to be able to address a storage problem, is where you stand in terms of storage. How much storage your apps are consuming from your app service plan allocated storage.

I find the best place to see that information is to browse to the app service plan itself from the Azure portal. Here is how:

Go to https://Portal.Azure.com

Type “app service plan” in the top center search box then select App Service plans under Services:

Search for App Service plans in the Azure Portal

Then select the app service plan in question. From the menu of the app service plan select File system storage under Settings

This will give you a nice graph that shows everything you need to know:

Now you know exactly which app is consuming what under your app service plan.

What to watch out for

What are the things that you need to watch out for that might be silently increasing your storage?

Here is a list:

Your code! We talked about this above.
Old packages from prior deployments (especially if you are building a single page web app SPA)
Old binaries that are no longer needed
Localized binaries for languages your app doesn’t support

First thing is to get the items listed above under control.

Secondly, make sure you don’t have anything in your build or deployment process that might be inflating your storage for no reason. For that, I will provide two common tips to make sure your continuous deployment (whether its automated CD or manual) doesn’t contribute to the storage problem.

If you are using Visual Studio to publish your code, edit the publish profile settings and make sure to select Remove additional files at destination under File Publish Options under Settings

Publishing Web App from Visual Studio – Remove additional files option

This will ensure to delete any unwanted files in the app service storage that is not a product of your new build. Obviously, if you are not the developer of the app, you may want to check with the developers responsible of the application to make sure they’re not creating some content on the app service needed by the app outside the build process since this option will remove that content and potentially break the app logic. The odds are the person deploying the app using VS will be the developer 😊

If you are working on a more mature project and use a CD tool like Azure DevOps to do continuous delivery for example, make sure to implement a task to clean up the app service storage before deployment. That can be done in Azure DevOps native App service deployment task with a setting (if you use Web deploy):

Under Additional Deployment Options | Select Publish using Web Deploy | then select Remove additional files at destination

Azure DevOps pipelines – Remove additional files option

Cleanup

What if your app service is already taking too much space and you want to clean it up manually. There are multiple places where you can do that at:

Browser: Navigate to the Azure portal and go to the app service in question, under Development Tools

Navigate to App Service Editor (Preview) which will take you to the following URL https://[App_Service _Name].scm.azurewebsites.net/dev/

Or navigate to the Kudo portal (Advanced Tools) which will take you to the following URL

https://[App_Service _Name].scm.azurewebsites.net/

From there you have few options:

UI, go to Tools | Zip Push Deploy

This gives you a nice UI to navigate through your app content, delete and add files …etc.

Console Debug console | PowerShell

If you are an old DOS dude like me you can go to Debug console | CMD

In all the above web methods you will be able to browse your web app content and delete any files as needed.

2. Thick client or IDE, you can do the following in Visual Studio:

Open the Server Explorer, connect to your Azure subscriptions then browse your App Service plan | app service files:

3. Use your favorite FTP client with the app service SFTP credentials

App service is still too big after deleting my code

One thing that some developers may run into, is that the app service size doesn’t go down as they delete all their deployment code. There are other things that may contribute to the size of your app service but not necessary part of your app code. This is what I call none-obvious stuff, one of the most common would be site extensions.

You may have a few site extensions installed in your app service that are not being utilized and that is what is consuming a lot of your app service storage. For example, the .NET Core 2.2 libs are big, they can be about 300 MB per version.

To find out which extensions are installed, navigate to the Azure portal and select the app service in question then go to Extensions | under Development Tools:

Make sure you don’t have any unwanted extension

Hope that helps