Jitendra Kumar

Error //./pipe/docker_engine: Access is denied. In the default daemon configuration on Windows.

jikuma — Mon, 19 Mar 2018 15:19:21 GMT

While executing VSTS\TFS docker task, you might get the following error.

error during connect: Post : open //./pipe/docker_engine: Access is denied. In the default daemon configuration on Windows, the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running.

The error means that the VSTS agent which is executing the docker client does not have permission to write to the named pipe 'docker_engine'.

When you install docker engine by default only the administrator group has the permission to write to the 'docker_engine' named pipe. If you configure VSTS agent service with the user account which is not the agent machine administrator, you will face this issue.

Solution 1:

Step 1. Add the user\group used to configure VSTS agent as an administrator.

Step 2. Restart the VSTS agent service.

Solution 2

Step 1: Create a new group. Say 'docker_engine'

Step 2: Add the user which is used to configure VSTS agent to this group.

Step 3: edit the docker daemon configuration json file to add ("group": "docker_engine"). More info here.

Step 4: Restart the VSTS agent service.

Kubernetes Services task failing in VSTS.

jikuma — Tue, 19 Dec 2017 23:06:06 GMT

Fix for this issue has been deployed. Now you can pin your kubernetes task to a particular version of kubectl client by specifying the version in the Advance section of the task.

If your kubernetes task is failing since 17/12/2017, this is because latest version 1.9.0 of kubectl is released. Unfortunately, kubernetes task always pulls the latest version of kubectl which is not compatible with the older kubectl server. The workaround involves having kubectl setup on the agent machine so that task does not pull the latest version. If you are running release on your private agent. Download the version of kubectl you want from https://storage.googleapis.com/kubernetes-release/release/%version%/bin/windows/amd64/kubectl.exe like https://storage.googleapis.com/kubernetes-release/release/v1.8.0/bin/windows/amd64/kubectl.exe Keep it in a folder say "C:\kube\". Now update the Path variable to include the folder path. Once u have made the change make sure to restart the agent and if running agent as service restart the service. Check by echoing Path variable if the change is reflecting or not. You might have to also restart your command prompt. If you are running release on hosted agent Download the desired kubectl version. Check it in the source code or add it as a part of artifact. In the release definition add a powershell task and set Type to file path. Use file picker in Script path to navigate to kubectl.exe Select till folder path of kubectl.exe in above example "$(System.DefaultWorkingDirectory)/first/" Switch the type to Inline script. In inline script add Write-Host "##vso[task.setvariable variable=path;]$env:path;$Args" In Argument section add the folder path of kubectl. This will fix the release add the k8 task will start using the k8 client which is part of the artifact. If you face any issue, you can add command line task to echo Path variable to check if it is updated or not. You can also execute where kubectl to check which kubectl is being used.

Setting up continuous deployment from Docker Hub using VSTS Release Management

jikuma — Tue, 05 Dec 2017 20:25:39 GMT

Now you can set up continuous deployment from DockerHub using Visual Studio Team Services Release management. A release can get triggered automatically once an image is updated in docker hub. We will see how this can help us automatically keep our Azure web app updated with the source code sitting in GitHub. Step 1: (Code): You can keep your code on GitHub. For example https://github.com/jikuma/nodeJsSampleService. This is a simple site which displays "Hello Docker Hub". We want to automatically create/update a container image once any edit is made to source code. Once an image is pushed to Docker hub, we further want to automatically trigger VSTS release to update my website hosted in Azure web app. Step 2: (CI): Once we have a code we want to automatically build and push an image to docker hub. Step: 2.1 (Link GitHub to your Docker Hub Account): Log in to your docker hub account If you have not already connected your GitHub account to DockerHub account, you will have to link these account. Here are steps to do it. Step: 2.1.a: Click on link account Select link GitHub and then provide details to link your GitHub account If a GitHub account is already linked you will get list of your GitHub repository Step: 2.2 (Create a Docker Hub image/repository using GitHub repo) Click on Create -> Create Automated Build -> Github Select the repository you want to create image from Enter repo details and select Create. A docker hub repository will be created for you. Step: 2.3 (Verify that CI is set up for you): Go to Build settings tab of Docker hub repo and check if the setting is correct. It's saying that whenever a change is made to master branch of the GitHub repo it will trigger image build and will update the docker hub repo. Your CI is set up. You can now make changes to your Github repo and check if Docker hub repository/image is getting updated or not. You can see a build getting triggered in the Build Details tab. Step 3: (Setting up CD: update my website as soon as the new image is pushed to Docker hub). Step 3.1: Let's create an Azure web app using this docker hub image. Step 3.1.a Log into the Azure portal https://portal.azure.com Step 3.1.b Select App service Click on the plus to create new web app. Search for ‘Web App for Containers’, and press 'Create'. Give details, like app name and click on 'Configure Container'. Input the image details. Click ok, to create the web app. Once the web app is created, visit the site to check if deployment is successful. Once you have successfully deployed your web app, we will set up a CD so that whenever the image is updated in the DockerHub, web app gets updated automatically. Step 3.2: (Setup CD using VSTS Release Definition): Let's create a Release Definition in VSTS to achieve Continuous deployment Log in to your VSTS account. If you don't already have a VSTS account, here are steps to get started. Step 3.2.a (Create a Docker Registry endpoint.) In the VSTS Project, create a service endpoint by clicking on the Gear icon -> Services. Step 3.2.b: Select “+ New Service Endpoint" -> Docker Registry. Step 3.2.c: Create a Docker Registry endpoint by entering docker hub credentials. Click on 'Verify Connection' to check if provided credentials are valid. Click "OK" to create an endpoint. Step 3.2.d: Now, Create new release definition. Hower over "Build and Release" and select Release. Click on "+" icon and select "Create release Definition." Let's start with an empty template. Step 3.2.e: Add an Artifact. Select an artifact of type Docker hub and select the namespace and repo from the drop-down. Step 3.2.f: Once Artifact is created click on the lightning icon and enable continuous deployment. Step 3.2.g: Now, let's add the tasks to update the web app. Go to add task ui of 'Environment 1' by clicking on "1 phase, 0 task". Add a task to deploy web app and another to restart the web app. Deploy Web app: Enter the details of the web app. Inside tag field input the variable name $(BUILD.BUILDID). The value of BUILD.BUILDID is the image tag name for which release has been queued. Restart Web App: Enter the details in the task and save the RD. Now you are all set. Step 4: Validation (Validate that a check-in in GitHub will automatically update your web app) Step 4.1: Make a change in your github repo. We have changed the message on the site from "Hello DockerHub - updated - 15" to "Hello Docker hub. CD should automatically update the azure web app." Commit the change. Step 4.2: (Validate CI) It will automatically trigger a build in docker hub to update the docker hub repo. Validate that in docker hub, check if a new build to update the image is triggered. Step 4.3 (Validate CD): Once new image in dockerhub is updated, a release will automatically get triggered in VSTS. This will update your webapp. Step 4.4 (Validate web app): Refresh the website for the change to take effect You can also manually select the image tag to deploy without setting the CD. For this, you have to create a release and select the tag from the drop-down with which you want to update the web app.

Running tests in parallel using VSTS Release Management

jikuma — Tue, 13 Dec 2016 18:57:04 GMT

Release Management now supports running the tasks inside a phase in parallel on multiple agents. In this blog post, I will walk you through how this can be leveraged to run tests in parallel. Scenario: I have a dotnet core project. I want to test it against Windows, Linux, iOS. Additionally, I want these tests to run in parallel. Step 1: Create a new variable TargetOS variable and initialize it with Windows_NT ,linux ,darwin. Step 2. Add two dotnet core tasks for restore and test. Step 3: Select Multi-Configuration from Type of parallelism. Step 4: Specify Multipliers as TargetOS and set Maximum number of agents as equal to more than the OS in TargetOS variable. If you have lots of runtimes and want to run those in parallel, but you want to limit the concurrency so that you do not starve another build/release for an agent. Then you should set Maximum number of agents to the value equal to the desired number of agent it is allowed to take simultaneously. Step 5: In demand specify Agent.OS -equals $(TargetOS) Depending on the number of OS specified in TargetOS variable, test runs will be created. Here three test run will be created each having the corresponding value of variable TargetOS variable. For example, the test run for Windows_NT will have TargetOs as Windows_NT. We use this variable in demand to target appropriate agent. For Windows demand will evaluate to Agent.OS -equals Windows_NT. This test will run on the agent with the capability Agent.OS as Windows_NT. Also, make sure that the agent capabilities match the demands after the variable is replaced. Step 6: Queue the release This will create three test run and each will target agent with respective OS. The first test run is for iOS, second for Windows and third for Linux. We can check this in the name of Multiplier Node. If your tests take very long to run and you want to cut the time, there is an upcoming version of VS Test task which can slice the tests in a single test run, each of which can run parallelly. To use this new task, you can use Multi-Agent parallel execution. If you chose to run release with Parallel execution as Multi-Agent, the test is simply duplicated to run on multiple agents and each agent pull the appropirate slice from the server.