Dev Ops – Page 16 – My Point of View

Installing PowerShell and Az moduel for Azure

Microsoft has switched from AzureRM modeule to Az module. Here is GitHub link to download and install;

https://github.com/PowerShell/PowerShell/releases/tag/v7.1.3

The easiest method is to download. Navigate to the release page;

As of this writing v7.2.0 is available. Scroll down the page and you will see this msi package under Assets;

Download and install. To test open PowerShell in admin mode and type this;

$PSVersionTable.PsVersion

Your PowerShell installation is done. It’s time to install Az-Moduel to interact with Azure.

Install-Module -Name Az -AllowClobber -Force

The -Force flag will install a second version of this module if one already exist.

You might be prompted for NuGet provider pre-requisite at installation startup;

Run this command to install pre-requisite;

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force

Re-run Az installation command;

Install-Module -Name Az -AllowClobber -Force

This might take a minute or two depending on your connection speed. Once done, i can run this command to see how many Az module version i have installed;

Get-InstalledModule -Name Az -AllVersions | Select-Object -Property Name, Version

Since i have only a single version installed, so that’s what i see. if i had multiple versions installed, i would have seen many lines. By default, PowerShell uses the most recent version.

This concludes installation of Az module into PowerShell.

Time to do some good stuff. Run this command to connect to Azure;

Connect-AzAccount

This will open up browser and ask about your credentials. After verification it will show that your session is authenticated. Navigate back to PowerShell an you can see authentiation message.

If you have multiple Active Azure subscriptions, First one will be selected by default.

Run an azure resource command to confirm PowerShell is working;

Get-AzVM, Get-AzWebApp

Switching to another subscriptions

Run this command to see all of your subscriptions;

Get-AzSubscription

You will see a list of assigned subscriptions. To switch to another subscription, store your subscription in a context variable and switch the context.

$context = Get-AzSubscription -SubscriptionId <Subscription ID from list of subscriptions>

Set AzContext $context

Hope this will help.

DistributedCom error when running SSIS package on windows box

When I run integration services package from inside of the windows box, they work. When I try to run them from outside of the box using my laptop, they fail. SQL Agent job works from either side.

Upon further investigation, I noticed these events in windows system event log;

It seems that DistributedCOM component has permission issue; Add user’s to this window group;

Now we need to perform some DCOM component configuration to grant access to the Integration services service.

Run Dcomcnfg.exe. Dcomcnfg.exe provides a user interface for modifying settings in the registry.

On the location tab, make sure “Run application on this computer” is checked.

On the security tab, click Edit in the Launch and Activation Permission area. Add users and assign appropriate permissions, and then click ok.

Repeat above steps for Access permissions.

Restart database server.

Multiple environments, do I need Azure Key Vault for each environment?

I started getting this problem today when I try to use same secret for my second application in a single key vault;

Multiple resources/entities can access a single Key Vault instance – provided they’re all in the same location (data center).

You may choose to segment your keys, secrets and certificates, either by placing them in different Key Vaults or by using different access methods/identities, however that’s not necessary.

The only time you need a separate Key Vault instance is when the resources/entities accessing it are in another location (data center/region).

It’s worth noting that you don’t need to worry too much about provisioning Disaster Recovery for resources using Key Vault, as the SLA Microsoft provide is unsurprisingly good: https://docs.microsoft.com/en-gb/azure/key-vault/key-vault-disaster-recovery-guidance. One caveat to that would be if you’re running IaaS/PaaS instances and want to run a DR fail-over yourself to another data center, at which point you’d need to manually migrate the keys/secrets/certificates in your main Key Vault into another instance (and re-point your VMs accordingly)

Resources

https://docs.microsoft.com/en-us/answers/questions/77182/key-vault-for-multiple-app-service-should-i-create.html

https://docs.microsoft.com/en-us/azure/key-vault/general/best-practices

Copy an existing pipeline

The easiest way is to clone existing pipeline through Azure DevOps portal. Click on Pipelines -> Your pipeline à Click the ellipse in the upper right corner (three vertical dots), then click clone.

If clone is not available due to any reason, you can create a new pipeline based on an existing yaml file which is basically cloning.

Pipelines -> New Pipeline -> Configure (3^rd page of the wizard) -> Select “Existing Azure Pipelines YAML file”.

Here you can select the branch and the file you want to use. However, this does not copy the variables set in the pipelines.

Above solution will work within same project. If you want to clone/import pipeline from a different project, Select “Export to YAML” from source project pipeline. This will download a YAML file on your local. Open file, make changes and import to your new project repo.

Resources

https://docs.microsoft.com/en-us/azure/devops/pipelines/create-first-pipeline?view=azure-devops&tabs=java%2Ctfs-2018-2%2Cbrowser#clone-a-pipeline

https://stackoverflow.com/questions/57827447/is-there-a-way-to-clone-or-copy-an-existing-ci-cd-pipeline-in-azure-devops

Azure Storage redundancy

Locally redundant storage (LRS) replicates your data three times within a single data center in the primary region. LRS provides at least 99.999999999% (11 nines) durability of objects over a given year.

The following diagram shows how your data is replicated within a single data center with LRS:

LRS is the lowest-cost redundancy option and offers the least durability. If a disaster such as fir or flooding occurs with the data center, all replicas of a storage account may be lost or unrecoverable.

Zero-redundant storage

Zone-redundant storage (ZRS) replicates your Azure Storage data synchronously across three Azure availability zones in the primary region. Each availability zone is a separate physical location with independent power, cooling, and networking. ZRS offers durability for Azure Storage data objects of at least 99.9999999999% (12 9’s) over a given year.

The following diagram shows how your data is replicated across availability zones in the primary region with ZRS:

Microsoft recommends using ZRS in the primary region for scenarios that require consistency, durability, and high availability.

If your application is restricted to replicating data only within a country or region due to data governance requirements, you may opt for LRS or ZRS. The reason, In some cases, the paired regions across which the data is geo-replicated may be in another country or region.

Resource

https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy