Azure Container Service is an offering from Microsoft which makes it simple to create, configure, and manage a cluster of virtual machines that are preconfigured to run containerized applications. The following guide is based on steps mentioned in https://docs.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-walkthrough but deviates a little. First, the guide is based on using Azure Cloud Shell which creates two issues. In my experience, this cloud shell is not ready for prime time usage as you will keep getting issues like authentication failure, for some reason the shell will expire after every 20 mins, etc. Also CI/CD cannot be build on top of the cloud shell.
Most likely scenario would be using a CI/CD tool like Jenkins, VSTS etc. using a custom agent and then you would need to run shell commands for deploying containers. In this blog post, we’ll examine how to prepare a ubuntu based workstation for this and deploy a kubernetes cluster on Azure Container Service.
This is a very short post and relies on the knowledge that UID of root user is always 0 regardless of the name of the root account. If the effective UID returned by id -u is not zero, the user is not executing the script with root privileges. Below simple code can be used to check against if script is running as root or not:
if [ "$(id -u)" -ne 0 ]; then
echo 'This script must be run by root user' > &2
I have spent some time to gather list of most used docker commands and below is a summary for same. These are not full blown commands, just to get you started and then you can use inbuilt command help.
Whenever a new .NET assembly project is created in Visual Studio, a file named AssemblyInfo is created that contains attributes used to define the version of the assembly during compilation. Using assembly versions effectively enables various team members to identify deployed assemblies and helps troubleshoot problems that may occur in a particular environment (e.g. Development, Test, or Production).
When building the solution, there are two version numbers that need to be considered: the file version number and the .NET assembly version number. As part of the best practices, the AssemblyFileVersion attribute should be incremented automatically as part of the build process. It is therefore intended to uniquely identify a build. The AssemblyVersion attribute is the version that .NET uses when linking assemblies. In this blog post, we’ll learn how to use the build process to auto specify the AssemblyFileVersion and AssemblyInformationalVersion.
We recently came across this problem. One of the developers had created a new branch in the one of the source code repositories hosted on the Visual Studio Team Services aka VSTS. Other developers were unable to see this newly created branch in their visual studio team explorer pane:
In previous blog post, we learned how to do baby steps for implementing IaaC. We learned how to use ARM templates, Git and Visual Studio to code your subnets in the Azure. Now, there is no doubt that Git has taken over the world for source code management. And while it is good for managing versions of source code, those versions and details are confined to your local machine. If someday your local machine goes kaput, its all in water. For that, you need to sync your changes to a centralized source code management system. Also having centralized source code management allows more than one person to work on the same repository.