Since in last post, we discussed on how to run Azure Pipelines agents as docker containers and configure them accordingly, the next step would be to run them on the Kubernetes platform. This kubernetes cluster can be on-premise and/or cloud and could be self managed or managed by the cloud service provider itself.
One of the reasons you may want to run them on Kubernetes is because you want better utilization of your kubernetes cluster. Another reason might be to leverage your existing knowledge of the kubernetes platform and work on it. Another reason would be to not use Microsoft hosted agents, as by default you would get only 1800 minutes of agent time to utilize, for free accounts.
Continue reading “Run Azure DevOps Private Agents in Kubernetes Clusters”
You can easily store your environment related secrets in the Azure Pipelines releases as variables and mark them as secrets which will encrypt and hide them. So anyone having access to the release definition would be not able to view them. Most of the times, it suffices as once set, they become encrypted and can not be viewed in text form.
However, sometimes it may happen that the person who keeps the secret would not be the same person as who is creating the release definition. Think of that as a way of segregating the responsibilities between the two. Also, it may be possible that the person who has provisioned the environment is not comfortable to share the secrets with anyone in plain text. After all, the best way to keep a secret is not to tell anyone about it. This is where the Azure Key Vault fits in very nicely. It can be used to store and transfer the secrets/certificates needed for your environment in a secure way.
Continue reading “Store the app secrets in Azure Key Vault and use during Azure Pipelines”
Few days back, we learned about how to publish Azure Container Instances where-in we can deploy either a container or group of containers and use the same. Azure Web App for Containers allows you to not only run your containers but it also brings forth the PaaS innovations for the Web App. So it brings best of the both worlds together. It also allows you to not worry about the maintaining an container orchestrator mechanism. You can prefer to package their code and dependencies into containers using various CI/CD systems like Jenkins, Maven, Travis CI or VSTS, alongside setting up continuous deployment web hooks with App Service.
In this blog post we’ll learn more about how to deploy .NETCore application packaged as docker container and using CI/CD in Azure Pipelines (Formerly VSTS). Continue reading “Configure CI/CD in Azure Pipelines to deploy docker containers as Azure Web App”
Containers are fast becoming the preferred way to package, deploy, and manage cloud applications. Azure Container Instances offers the fastest and simplest way to run a container in Azure, without having to manage any virtual machines and without having to adopt a higher-level service.
Azure Container Instances is a great solution for any scenario that can operate in isolated containers, including simple applications, task automation, and build jobs. Also, Azure Container Instances supports the deployment of multiple containers onto a single host by using a container group aka pods in terms of Kubernetes. Multi-container container groups or Pods are useful when building an application sidecar for logging, monitoring, or any other configuration where a service needs a second attached process.
Continue reading “Configure CI/CD for Azure Container Instances using Azure / Azure DevOps Pipelines”
While trying to create the Azure Container Instances on one of the newly created Azure Subscription, we came across this strange error, “ERROR: The subscription is not registered to use namespace ‘Microsoft.ContainerInstance'”. So we checked our configuration and the way we were creating the Azure Containers, and it all seemed okay. So we dig a little around by using PowerShell, authenticate to Azure using Login-AzureRmAccount and fire few commands.
The first command we fired was classic Get-Command to check if there are any existing cmdlets to help with Azure Resources and sure enough, there it was:
Continue reading “Troubleshooting ERROR: The subscription is not registered to use namespace ‘Microsoft.ContainerInstance’.”