I want to have a pipleline that does a maven build and then have a later step in the pipeline that uses a docker container to do some operation on the built artifact(s).
This page explains how to run a script in the context of a Docker container - great:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/container-phases?view=azure-devops&tabs=yaml
What I'm not seeing is documentation on how to access, from the Docker container, artifacts from previous build steps, or for that matter, the build environment itself.
GitLab, for example, allows you to share artifacts between steps and exposes a whole slew of environment information to container jobs. How is this accomplished in Azure DevOps?
Related
I have a multi-layer Asp.Net Application running. Due to it's multi-layer nature, I have to build a container for it and deploy it as a container.
Is there anyway I can deploy it to an existing server using Azure-Pipelines?
All other support that I am finding online is related to deploying to Azure App Services, however I would like to deploy to an existing production environment.
Is there anyway I can deploy it to an existing server using Azure-Pipelines?
Since you are deploying to the local environment, you can use Self-hosted Agent(Build Pipeline and Release Pipeline) or Deployment Group(Release Pipeline).
Then you could try the following pipeline settings.
Here is a blog about ASP.Net Application Deployment in Docker for Windows.
You could use Command Line Task to run the docker command. In this case, you can move the local build and deploy process to azure devops
By the way, if you have the Container registry Service connection in Azure Devops, you could use the Docker task or Docker Compose task.
I have a nodejs web application that I build in Azure Pipelines. I am planning to deploy the generated artifacts on a Azure VM (probably a dev test labs), as part of one of the pipeline steps.
I want to now run browser tests by pointing the browser to the hosted URL in the Azure VM. I want to use the Azure windows and linux VMs in a build pipeline to run the tests on this remote Azure VM and publish the results to the pipeline. These would be karma tests essentially running on the nodejs server.
In my current design, the test results are going to be available on the Azure VM hosting the nodejs application.
What I don't understand is how can I get these test results back to
the Azure Pipeline for publishing the same?
Is there a way I can architect this solution without having to setup my Azure VM as a
pipeline agent in Azure DevOps?
Is there a standard pattern to design such continuous test infrastructure using Azure DevOps?
Thanks
According to your description, you just want to use Microsoft host agent to access an url on your self-host agent (ignore it's Azure VM or your own physical machine, same to host agent).
It depends if that url are accessible through public internet.
The simplest solution here is deploy your build agent on that Azure VM directly. Then run build and test. You can do this through the following script and tasks:
run ng test or any command to raise your tests
publish test results with PublishTestResults task
publish code coverage results with PublishCodeCoverageResults task
Microsoft-hosted agent pool will not work for you with every scenarios. For many teams this is the simplest way to run your jobs. You can try it first and see if it works for your build or deployment. If not, you can use a self-hosted agent. Self-hosted agents give you more control for your builds, tests and deployments.
In your scenario, setup your Azure VM as a pipeline agent and run build/test on it should be the simplest and convenient solution.
We have a .NET Core Console App which we publish to an On Prem VM using publish feature in Visual Studio. Here is how we configure publishing to a file system.
Target location in the image is actually the folder structure of where we want our app to reside on the VM.
How can we configure the same in DevOps. I can't seem to find any good resource on this.
I have created a CI build pipeline.
You can follow below steps to deploy Console App to the On Prem VM.
1, Create a deployment agent on On-Prem VM. create a deployment group from azure devops portal. Follow the first part of this tutorial to create deployment group. Check the official document for more information about deployment group.
2, Create a release pipeline. See document here.
Setup the artifacts(you should have the publish build artifacts task in the CI build pipeline to publish the console app build artifacts to azure devops server.), and add stage for the release pipeline.
Add a deployment group job in the release stage.
see below screenshot to select the deployment group created in the first step, which contains the deployment agent on the ON-premise VM,
Add copy file task to copy the console app build artifacts to the folder on the ON-premise VM
Another workaround is to use self-hosted agent(steps are similar to above using deployment group). Check the detailed steps in this example.
Hope above helps!
I'm building an Azure DevOps pipeline to deploy a custom-build powershell application to several on-prem environments that we support. I configured the required agent pools and installed them as a service on the on-prem environment.
Next, I have set up my pipeline in Azure DevOps, selecting a GitRepo:
Build (with the steps: Use Nuget, Nuget Restore, Build solution, Update version, Copy Files, and Publish build Artifact)
Release (with step: Publish Build Artifact)
Some things are unclear for me:
Do I need the Publish Build Artifacts twice? Can the Build pipeline
end with Copy Files step, and that the Release pipeline picks up this
artifact?
It is my understanding that the release publishes the app to the
on-prem environment (in my case). Where can I set a custom path (ie:
C:\deployed_apps) where the app needs to be deployed? When I tested
this pipeline, I got errors that the path I created using an variable
was not found.
What am I missing in my setup to get this pipeline working?
As #Shayki Abramczyk
pointed out this task is not for deployment, it just upload your Build Artifacts to azure devops server where your release pipeline can download directly.
In your case, if you want deploy your application to several on-prem environments, You need to create a deployment group first, A deployment group is a logical set of deployment target machines that have agents installed on each one. You application will be deployed to those machines in a deployment group in release pipeline. Check here for more details about deployment group.
After the deployment group is created, you can add a deployment group job by click the 3 dots, and then specify your deployment group as below pic shows, You can then simply add a copy file task or other deployment tasks to deploy your application to your on-prem machine.
In the release pipeline you shouldn't use the Publish Build Artifact. in the end of the build you put this step, what this step does? upload your artifacts to the Azure DevOps or to a file share. now in the release pipeline you choose the build artifact (in the left pane). the first thing that the agent does when the release pipeline started is to download the build artifacts to the agent. now you need to take them and deploy it to your environments. how? it depends which kind of application is (it can be just copy files, it can be deploy to IIS, etc.).
You can put the path in the variables tab and use this variable when you deploy the app (with copy files task, for example).
I have a multi-container app running with App Service - Web App for Containers. It all works fine as long as the Docker Compose (Preview) configuration is provided under the Container Settings tab.
Currently, I am using Azure DevOps to create builds for specific containers, and then use the Continous Deployment option (in Azure Portal) under Container Settings to pull the latest deployed container image from ACR. This also works fine. I can run builds for individual containers, and deploy only specific container without affecting the web app. (Each container is a separate project, and only has a Dockerfile without requiring docker-compose)
However, when I create a Release from Azure DevOp using Azure App Service Deploy (version 4.*), the Docker Compose (Preview) configuration in Azure Portal is completely wiped out, and it defaults to Single Container and the application breaks. The Docker Compose configuration is needed as it makes the main container aware of the other containers.
I am using version 4.* of Azure App Service Deploy. I would like to use the Release feature of Azure DevOps as it provides more control.
Is there a way I can specify the docker-compose multi-container configuration from Azure App Service Deploy version 4 so that the App Service is aware of the multi-container configuration and not wipe out the multi-container config in Docker Compose (preview)
Thanks,
Karan
Replace the Azure App Service deploy task in your Release pipeline with an Azure Web App for Containers task. There are parameters for multiple images and a configuration file (Docker-Compose.yml).
As Dave mentioned this is possible using the AzureWebAppContainer task, however the documentation does not mention the options regarding multi-container deployment.
I had to dig into the source code of that task to discover the task parameters.
https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/AzureWebAppContainerV1/taskparameters.ts
I'll summarise my setup to give you an idea how it can be used. I have a multi-stage pipeline defined in YAML. There are two stages, the first stage builds and publishes the Docker images and the second stage updates the Web App for Containers app service.
The first stage also produces an artifact, namely the docker-compose.yml file that is used to configure the Web App for Containers app service. In my repository I have a template for this file. During the pipeline execution the tags of the docker images are replaced within this template (e.g. using envsubst or sed). Then the resulting docker-compose.yml file is published as an artifact.
- task: PublishBuildArtifacts#1
displayName: "Publish artifact"
inputs:
pathToPublish: $(Build.SourcesDirectory)/pipelines/assets/docker-compose.yml
artifactName: yml
In the second stage of the pipeline the artifact is downloaded and used to configure the Web App for Containers. In the example below the AzureWebAppContainer is a step of a deployment job.
- task: AzureWebAppContainer#1
displayName: 'Azure Web App for Containers'
inputs:
azureSubscription: '<YOUR_SUBSCRIPTION>'
appName: '<YOUR_WEB_APP_FOR_CONTAINERS>'
multicontainerConfigFile: $(System.ArtifactsDirectory)/yml/docker-compose.yml
The generated docker-compose.yml is stored as an artifact and you can always consult it later.