Install Ansible to Use Python3 on Azure Ubuntu 18.04 VM

Ansible is an open-source configuration and infrastructure management tool providing capability to implement infrastructure as code (IaC). Especially in Linux based implementations ansible is used heavily, however, it can support automation on Windows platform as well. Let’s learn some Linux IaC with ansible in the coming posts and in this post, lets try to setup an ansible installation on a Ubuntu 18.04 VM with python3 support, in Azure. Setting up user for ansible in the VM was explained in previous post “Create New Linux Admin User in Azure Ubuntu VM”.

Create New Linux Admin User in Azure Ubuntu VM

We can setup Linux VMs in Azure for various reasons. Maybe it is for setting up a Jenkins or Ansible server. If we are setting up Ansible on a Linux VM in Azure it is recommended to use a separate user with Admin permissions, instead of the default user who has the root access as well. This is beneficial as in case we need to reset access for the default user, we can do so without harming anything setup for Ansible. In this post let us look at steps to add an additional admin user to Ubuntu Linux VM in Azure and how we can enable ssh to the VM with that user.

Resolving 409 Access Denied in Azure Kudu and App Service Editor

Sometimes you may need to edit files especially the web.config or appsettings.json files after deploying your application to Azure App Service via Kudu or using App Service Editor to change the setting for diagnostic purposes etc. For example, may be you want to enable logs by setting stdoutLogEnabled to true. However, if your application is deployed to Azure App Service via Azure DevOps pipelines’ Azure App Service deployment task, you may run into 409 Access Denied error. Let’s understand why the error occurs and how we can enable editing the files, in your deployed Azure App Service application/Function apps via Kudu or using App Service Editor.

New Manual Validation Task for YAML Pipelines

Even though YAML pipelines could be setup to wait for approvals based on environment approvals and checks, setting up a manual intervention task which was available to classic release pipelines, was not supported in YAML deployment pipelines till the latest feature release to Azure DevOps. With the introduction of new Manual Validation Task specifically supporting only YAML pipelines, now you can wait for resume/reject with an agentless job, during the YAML pipeline execution. Let’s look at how this new task works.

Create Windows or Linux Consumption Plan Using Azure CLI

While creating a function app with Azure CLI we can let it dynamically create a consumption plan, which would be created with a default name. However, if you want to have more control over naming of the consumption plan, it is better to create the consumption plan as a sperate step. Looking and Azure CLI documentation does not provide clear information on how to create a consumption plan. Therefore, let’s explore the needed commands to get a consumption plan on Windows or Linux platforms in this post.

Resolving “TF401019: The Git repository with name or identifier xxxx does not exist or you do not have permissions for the operation you are attempting.” in Azure Pipelines git Submodule Checkout

Submodule in Git repos help you to keep the common code modules in a separate repo and utilize in multiple other repos. In the classic and YAML build pipelines you can checkout git submodules as explained in the post “Git Repo Submodule Checkout in Azure DevOps Build Pipelines”. However, you may encounter the below issue while running such build pipelines having to perform a git submodule checkout.

Cloning into 'D:/a/1/s/Infra/AzCLI'...

remote: TF401019: The Git repository with name or identifier InfraCLI does not exist or you do not have permissions for the operation you are attempting.

fatal: repository 'https://dev.azure.com/yourorg/DevOps/_git/yourrepo/' not found

fatal: clone of 'https://yourorg@dev.azure.com/yourorg/DevOps/_git/yourrepo' into submodule path 'D:/a/1/s/Infra/AzCLI' failed

Failed to clone 'Infra/AzCLI'. Retry scheduled

Azure Service Connection via Variable Group in YAML CD/Release Pipeline Templates

In application deployment we may use different Azure subscriptions to setup infrastructure for non-prod and production environment infrastructure most of the time. In classic release pipelines we could easily create a resource group to setup deployment task needs, which should be used in multiples stages/environments such as Dev, QA, staging or production. For such groups when the task group is using Azure App Service Deployment, Azure CLI tasks we could supply the service connection name via a variable that can be stored in a variable group relevant to the given stage/environment scope. In YAML we can use a template to define the common steps and it is ideal if we could refer to variable group, to hold the service connection information related to the relevant stage/environment. However, the possibility to use the variable group variable for service connection, regardless of whether using a template in YAML or Azure deploy steps used directly in pipeline YAML seems to be not working as expected. Let’s look at the problem and alternative solutions.

Resolving “Response status code does not indicate success: 400 (Bad Request)” in NuGet Packages Push to GitHub Packages with GitHub Actions

GitHub packages registry can be use to keep your organization NuGet packages privately or share them publicly. If you create a package in a private repo it would be private to the repo or for the organization if you use an organization. If you keep your packages in a public repo you can share it publicly. Ideally when you build reusable NuGet packages you would build and publish such packages with GitHub action workflow to your GitHub packages. While implementing this you may encounter “Response status code does not indicate success: 400 (Bad Request)” at the push of the package, due to special needs of GitHub based NuGet packages. Let’s look at them in this post.