I would to use Docker on a Self-Hosted Windwos 10 Agent. To do so I installed Docker for Windows and was able to use it on the agent. But when I wanted to use it with a Docker task in VSTS I got the error:
##[error]C:\Program Files\Docker\Docker\Resources\bin\docker.exe failed
with return code: 1
What is the problem?
The agent service (VSTS Agent (agentName)) was running as Network Service what is not enough to use Docker. It is necessary to run the service in another context. Therefore:
Go to services
Search for the VSTS agent service
Right click on the service
Select properties
Go to the Log On tab
And select Local System account
Then restart the service
Now it is possible to use Docker. See also Docker agent does not run under System Account
EDIT:
I encountered the problem also when the Docker service was running as Local System. In this context it was necessary to run the VSTS agent service as Local System too.
Related
I am facing an issue with the task AzureStaticWebApp#0. AzureStaticWebApp#0 uses docker command in the background. See image below:
We have been advised to only in-house agents and we don't have any agent which is UNIX based and can run the docker command. The problem this creates is that I need to use different agents for different tasks which is opening up another set of problems (For ex - Azure DevOps + Azure Static Web App - Read deployment token from variables)
My DevOps team has asked me to investigate why AzureStaticWebApp#0 use docker commands in the background.
Refer to this doc: Azure Static Web Apps
Azure Static Web Apps' build engine runs in a Linux Docker container, so it can only be run on a Linux build agent.
Since Azure Static Web App depends on Docker environment, it will run docker command in the background.
And the AzureStaticWebApp task only runs on Linux agents.
Well, how can I create a pipeline to build and release a Docker compose, with Azure Devops through the graphical interface (GUI) I am not an expert in devops but I have this challenge in my work.
I would point you toward a great guide by microsoft, it's for java applications but you can get what you need out of it.
Solution in general:
Open the Azure Portal. Select + Create a resource and search for
Container Registry. Select Create. In the Create Container Registry
dialog, enter a name for the service, select the resource group,
location and click Review + Create. Once the validation is success
click Create.
In your CI build you need to have 2 tasks, 1 for the build/compose where you provide and another to publish the image to your Azure Container Registry. You will use the "same task" for this.
This container registry is where you store the outputs of your builds, similar to artifacts in traditional CI builds. This is where you publish your application from during a release to on-prem or cloud.
You can read more about the parameters you need to provide and the settings in details in the guide.
P.S. Here is an example on how to dockerize and existing .NETCore application.
How do you build and release your Docker compose on local?
Normally, you can copy the related docker-compose CLI and Docker CLI that you execute on local to the shell script tasks (such as Bash, PowerShell, etc.) in the pipeline you set up on Azure DevOps.
Of course, there are also the available Docker Compose task and Docker task.
Is it possible to run a TeamCity server instance in a Linux container, and then run a Build Agent in a Windows container and have it connect?
The TeamCity Server just the central server, where Agents push the results.
The TC Server is responsible for to add to queue, send a task to Agent, wait, collect the result.
The Agent is responsible for executing Task, send the result to the server.
doesn't matter, where was run TC or Agent, important point is that if your configuration needs the Windows server then it can be run only Agent on the Windows.
conclusion.
The TC Server can be run as on Linux, as on Windows OS's
The TC Agent also can be run on Linux and OS, but:
If your configuration using the Windows component's, then the Configuration will add restrict OS type in the Agent Requirements
If you have few configurations with few OS type's just run few Agents on the some OS's
I noticed that all of my builds suddenly got stuck. If I click the build I get the following error: All eligible agents are disabled or offline
When I check my agent pools I get the following:
How can I bring them online/determine why they are offline?
Try logging into the VM, and run the run.cmd from an elevated powershell prompt in your agent directory.
Source: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops
Login to powershell.Navigate to the agent folder where it contains run cmd prompt and config cmd prompt.
Execute the following command
.\run.cmd
Check the date and time on your VM. If it's wrong, correct it.
Then run powershell as administrator and cd into the azagent folder that contains the run.cmd file (most likely C:\azagent\A4).
Execute the following command:
.\run.cmd
For me, issue was suddenly agents were reporting offline on the portal.
Restarted the agent service in the VM - didn't help
Removed config file also didn't help because logs were showing that dev.azure.com wasn't connecting
Simply just restarting VM helped, but still couldn't able to find the cause.
The VM that host the build agents can have a auto shut down time. Make sure your build vm is running by going to Virtual machines in the azure portal
My agent stopped going live when I updated our Azure Devops to the latest version 2019.1.3 iirc.
To solve this I did the following:
Went to services.msc on the agent machine. Stopped the existing service.
Went to agent folder and removed the existing configuration via "config.cmd remove"
Downloaded latest agent code from the Azure Devops Agent Pools portal page.
Replaced contents of old agent with new agent files.
Went back to agent folder and configured a new agent via "config.cmd". Told it to start as a service.
Voila! Service back running again.
One of my Azure agents started showing as offline. As a test, I ran curl https://dev.azure.com/{organization} and got back an error "curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed".
I fixed the issue by downloading IISCryptoCli.exe from https://www.nartac.com/Products/IISCrypto/Download and then running "IISCryptoCli.exe /template default /reboot".
I solved this by connecting to the agent via Remote Desktop Connection and running the "Run Puppet Agent" application.
Please check the agent from agent tab under releases.
There should be a server listed for the agent under agent tab.
Now connect to that server and check weather the agent batch file or cmd window is open or not.(this agent for is the same file which is downloaded while configuring the agent.if you are struggling to find the file then follow new agent steps and download zip again and search with that file name.)
Now open the(filename -run) file on that server with admin right if it is already not running. This will make agent online in devops portal.
Now check the agent tab again in devops portal under releases.
This
I'm trying to run build Docker task to create a docker image. I set up a docker host, I'm using defautl Docker Hub as registry and my whole environment is on Azure.
When I queue a build task it fails at Task Docker.
Log output:
check path : null
task result: Failed
Not found docker: null
Finishing task: Docker
[error]Task Docker failed. This caused the job to fail. Look at the logs for the task for more details.
Does someone have any thought on what may be happening?
After looking into this, it would seem this happens if Docker is not properly installed on the build agent for the service principal the agent is running under.
Keep in mind that:
The Build must be run in a private agent, as the hosted ones do not yet have Docker installed, as per a very small footnote in the bottom of the documentation.
The VSTS agent must be running with a principal that has the environment variables set for docker to run; the default is LocalService account, which won't have that installed. This turns out to be a problem with other stuff as well and I've found it best to have a special user principal to run the agent under, that can also log into the system.
Fixing these two issues made it work for me.
I was able to switch the agent to Hosted VS2017 which has Docker support.
If Linux is an option, try Hosted Linux Preview