Saturday 7 January 2023

Blob Storage Info

Azure Blob storage is Microsoft's object storage solution for the cloud. Blob storage is optimized for storing massive amounts of unstructured data. Unstructured data is data that does not adhere to a particular data model or definition, such as text or binary data. It is ideal for flat-files, images, videos and sound files.

Though there are four types of Blob storage types: Standard general, Premium block blobs, Premium page blobs, and Premium file shares; odds are you are going to need the standard general.

Storage account type Supported storage services Usage
Standard general-purpose v2 Blob, Queue, and Table storage, Azure Files Standard storage account type for blobs, file shares, queues, and tables. Recommended for most scenarios using Azure Storage. If you want support for NFS file shares in Azure Files, use the premium file shares account type.
Premium block blobs Blob storage Premium storage account type for block blobs and append blobs. Recommended for scenarios with high transactions rates, or scenarios that use smaller objects or require consistently low storage latency.
Premium page blobs Page blobs only Premium storage account type for page blobs only.
Premium file shares Azure Files Premium storage account type for file shares only.

Each of the types has 3 tiers of access:

  • The Hot access tier, which is optimized for frequent access of objects in the storage account. The Hot tier has the highest storage costs, but the lowest access costs. New storage accounts are created in the hot tier by default.
  • The Cool access tier, which is optimized for storing large amounts of data that is infrequently accessed and stored for at least 30 days. The Cool tier has lower storage costs and higher access costs compared to the Hot tier.
  • The Archive tier, which is available only for individual block blobs. The archive tier is optimized for data that can tolerate several hours of retrieval latency and will remain in the Archive tier for at least 180 days. The archive tier is the most cost-effective option for storing data, but accessing that data is more expensive than accessing data in the hot or cool tiers.
In all likelihood, the Hot access tier will be the most appropriate.

When accessing your blobs, there are basically levels of organisation:
  • Storage account: this is the url level, each storage account has their own unique URL, and it will look like "http://foobar.blob.core.windows.net", this is the top level url your blobs will sit at.
  • Container within the storage account, it can be thought of as a folder, you can have any number of them, but should probably ensure that they make some sort of sense, they can also be used to restrict access using permissions, so you may have one for flat files that's secured, but one for media that's public
    • http://foobar.blob.core.windows.net/data
    • http://foobar.blob.core.windows.net/images 
  • Blobs: the actual files you are storing inside your containers.

sdf

Friday 6 January 2023

Web App Service

Now that we have our Resource group and App service plans set up, let's create a Web App service. A web app service can contain either a traditional web application such as on made using html or an API.

It's pretty straight forward, this time go to your resource group and create the 'Web App service' from there.



Then, as before select the create drop down at the bottom of the web app card and choose new 'web app'


Now this configuration is a bit more complicated


to select the previous plan that we created, our OS and region have to match, in our previous post we configured it to be west Europe and Windows at least in the PowerShell, these two properties filter which App service plans we can connect our web app service two, meaning that an App service and it's plan must be of the same OS type as well as in the same geographic region, however they do not have to be in the same resource group.

Before we create our application, go to the monitoring tab, this is because, by default app-insights is enabled, though this can be a useful service, it can also be a pricy one depending on your app usage, so I generally disable it.


Next, click the 'Review + create' button where you do one last final sanity check, make sure your spelling and naming conventions are correct and that you have the right plan connected to your web app, double check that cause it can prove to be an expensive mistake.


Now if we create our 'Web app service' we should see it in our resource group along with our app service plan (Assuming the app service plan is in the same resource, generally I like to distinguish between my environments by resource groups). 

With that done, as aways it's PowerShell time.


# create app service
function CreateAppService {
Param(
[Parameter(Mandatory = $true)] [String] $name,
[Parameter(Mandatory = $true)] [String] $prefix,
[Parameter(Mandatory = $true)] [String] $location,
[Parameter(Mandatory = $true)] [String] $environment,
[Parameter(Mandatory = $false)] [Microsoft.Azure.Management.WebSites.Models.AppServicePlan] $servicePlan,
[Parameter(Mandatory = $false)] [String] $servicePlanName)
$rgName = "rg-$name-$environment"
$appName = "app-$prefix-$name-$environment"
Write-Host "Createing $appName web app in $rgName resource group" -ForegroundColor Magenta
#check if web app already exists
$webApp = Get-AzWebApp -ResourceGroupName $rgName -Name $appName -ErrorAction SilentlyContinue
if ($webApp) {
Write-host "Web app ""$appName"" already exists" -foregroundcolor yellow
return $webApp
}
#create web app
try {
if ($servicePlan) {
$servicePlanName = $servicePlan.Name
}
$webApp = New-AzWebApp -ResourceGroupName $rgName -Name $appName -Location $location -AppServicePlan $servicePlanName
Write-host "App service ""$appName"" Created" -foregroundcolor Green
return $webApp
}
catch {
Write-error "App service NOT created" -ErrorAction Stop
}
}

# these guids will be unique to your Azure tenant and subscription
# fyi these are randomly generated and not my actual guids
$tenantId = "ba9ff786-e26a-4a09-ac62-412a0d1f1d76"
$subId = "d8cddcf7-1050-4524-89e3-28cea221fd80"

$azContext = Get-AzContext

if (!$azContext) {
Connect-AzAccount -Tenant $tenantId -SubscriptionId $subId -UseDeviceAuthentication
}

# create resource group
CreateAppService -name pav-example -prefix api -location westeurope -environment dev -servicePlanName plan-pav-example-dev

# Disconnect active account
Disconnect-AzAccount


Thursday 5 January 2023

App Service Plan

An app service can be thought of as the runtime environment in azure for your application, it could be an API, or a web app or a SPA (Single page application, Angular, React, Vue.js, etc). However before we can create an App Service we need an App service Plan. 

An App service plan, can be thought of as the infrastructure for your application, as in all things in life, you get what you pay for, the more expensive the app service plan the more 'Horsepower' you have, the question you must ask yourself do I need a Porche to get my groceries... the answer is generally yes if you are a god damn douche-bag... otherwise just get a ford escort.

To set add a service plan to your Resource group click the 'Create a resource' button on the home screen of your azure portal.


this will bring up your 'Create a resource page, in the top search bar just search for 'Service plan'.


It should be the first search result look for 'App Service plan'


The fastest way to get started is to select the 'Create' drop down and choose 'App Service Plan', this will navigate you to the 'Create App Service Plan' page, here you'll have to specify some basic configuration.


Two things to point out, are one, to get the free tier for linux based OS you have to click the 'Explore pricing plan' link button and manually select it, and try to use a reasonable naming convention to make it easier on yourself later.

Next optionally if you like you can hit 'Next: Tags >' to add tags to your 'App Service Plan' unless you have 100 of resources, this may be a bit overkill. Just keep in mind like all things, before adding tags you should come up with a tagging strategy something that is repeatable and beneficial.

Whether you choose to add tags or not the final step is to click the 'Review + create' button.


Here you just do a final sanity check of what you are about to deploy, make sure your spelling is right, the pricing tier is correct, and create your application.

Once your plan is deployed, you can navigate to your resource group that you created earlier and do one last double check to make sure it is where you expect it to be.


And that's it, our App service plan is ready to go.

So that is all fine and dandy, however I generally prefer to use powershell to deploy all my infrastructure, hence the following 


# Create app service plan
function CreateAppServicePlan {
Param(
[Parameter(Mandatory=$true)] [String] $name,
[Parameter(Mandatory=$true)] [String] $location,
[Parameter(Mandatory=$true)] [String] $environment)
$rgName = "rg-$name-$environment"
$planName = "plan-$name-$environment"
Write-Host "Createing $planName ($location) app service plan in $rgName resource group" -ForegroundColor Magenta
#check if service plan already exists
$servicePlan = Get-AzAppServicePlan -ResourceGroupName $rgName -Name $planName -ErrorAction SilentlyContinue
if($servicePlan){
Write-host "App service already exists " -foregroundcolor yellow
return $servicePlan
}
#create service plan
try{
$servicePlan = New-AzAppServicePlan -ResourceGroupName $rgName -Name $planName
                                            -Location $location -Tier 'Free'
                                            -NumberofWorkers 1 -WorkerSize 'small'

Write-host "App service plan Created" -foregroundcolor Green
return $servicePlan
}
catch{
Write-error "App service plan NOT created: $Error[0]" -ErrorAction Stop
}
}


# these guids will be unique to your Azure tenant and subscription
# fyi these are randomly generated and not my actual guids
$tenantId = "ba9ff786-e26a-4a09-ac62-412a0d1f1d76"
$subId = "d8cddcf7-1050-4524-89e3-28cea221fd80"

$azContext = Get-AzContext

if(!$azContext){
Connect-AzAccount -Tenant $tenantId -SubscriptionId $subId -UseDeviceAuthentication
}

#create service plan
$servicePlan = CreateAppServicePlan -name pav-example -location westeurope -environment dev

# Disconnect active account
Disconnect-AzAccount

One caveat, by default the PowerShell command 'New-AzAppServicePlan' will create a Windows based app service plan, according to the documentation on MSDN, by appending the -Linux switch this should not be the case, however when I tried it, I kept getting an "A parameter cannot be found that matches parameter name 'Linux'" exception, kind of a pain in the arse, one day I hope to come back and figure that out.

Wednesday 4 January 2023

Resource groups

Before we can configure just about anything in azure we need to create a 'Resource group' to hold our 'stuff'. If your are wondering what a resource group is in azure, you can think of it as a logical container for resources linked with your subscription. Basically it's a way to organise the things out deploy, those could be virtual machines, storage accounts, virtual networks, app services, app service plans, blob storage, etc. Basically any resource within azure must be stored within a resource group. One caveat is Azure services, they generally run at the subscription level, which is more ore less the thing you pay for.

To setup a resource group is pretty simple, log into your azure portal, and click the resource groups icon

you should see something like the following
I've blacked a few things out, for no particular reason, all of those details would be different for you anyway, the important thing is to click the create button.
once you've filled out all the mandatory details, you can add some tags if you like, this could prove useful especially if you are managing lots of resource groups and would like an easy way to filter them by, however you can always do it later... which is my favourite time to think of new key value pairs. 

Rather than expend mental energy thinking of good contrived tags, we're just gonna go ahead and create our resource group.
Let's click the 'Create' button and see what happens.... Shockingly, there's a resource group now listed with the name we provided.
We have our resource group, now that is good and dandy, now personally I prefer to script the creation of my Azure resources, so rather than going through the UI I can run a powershell script and create everything that I need. This way if i mess something up, I can just delete everything and start over. 


#create resource group
function CreateResourceGroup {
Param(
[Parameter(Mandatory=$true)][String]$name,
[Parameter(Mandatory=$true)][String]$location,
[Parameter(Mandatory=$true)][String]$environment)
$rgName = "rg-$name-$environment"
#check if resource group already exists
$resourceGroup = Get-AzResourceGroup -Name $rgName -ErrorAction SilentlyContinue
if($resourceGroup){
Write-host "Resource group already exists" -foregroundcolor yellow
return
}

#create resource group
Write-Host "Createing $rgName resource group in $location" -foregroundcolor magenta
Write-Host "With tags [application = $name; environment = $environment]" -foregroundcolor magenta
try {
$resourceGroup = New-AzResourceGroup -Name $rgName -Location $location -Tag @{Application=$name; Environment=$environment}
Write-host "Resource group created" -foregroundcolor green
write-host $resourceGroup
return
}
catch {
#failed to create resource group
Write-error "Resource group NOT created" -ErrorAction Stop
throw
}
}

# these guids will be unique to your Azure tenant and subscription
# fyi these are randomly generated and not my actual guids
$tenantId = "ba9ff786-e26a-4a09-ac62-412a0d1f1d76"
$subId = "d8cddcf7-1050-4524-89e3-28cea221fd80"

$azContext = Get-AzContext

if(!$azContext){
Connect-AzAccount -Tenant $tenantId -SubscriptionId $subId
}

# create resource group
CreateResourceGroup -name pav-example4 -location westeurope -environment dev

# Disconnect active account
Disconnect-AzAccount


this is the way I prefer to automate my deployments, there are other methods, namely config files you can use, and maybe one day I'll take the time to learn them.