I'm currently using resource: container in azure pipeline to pull my custom image tools from ACR, and use this image to create a container than can run several CLI commands on my pipeline.
Pulling this custom image tools takes so much time, roughly around 5mins and I want to avoid that as it is considered as a wasted time and a blockage since I do debugging most of the time.
Question: Is it possible to create an Azure Container Instance that constantly run my custom image tools then call this container inside my pipeline to run some cli commands?
I'm having a hard time finding documentation, so I'm not really sure if it is possible.
You can try to set up a self-hosted agent in your custom Docker image, and when running the container on ACI, it will install the agent and connect it to your Azure DevOps.
Then, you can use this self-hosted agent to run your pipeline job which needs to run the CLI commands. Since the self-hosted agent is hosted in the container, the job runs on the self-hosted agent will run in the container.
About how to configure set up self-hosted agent in Docker image, you can reference the document "Run a self-hosted agent in Docker".
Related
I am trying to create a CI/CD pipeline for a multi-container solution implemented via docker-compose.yml. The goal is to run a container group in Azure Container Instances.
I went with this task DockerCompose#0 for the release pipeline, and the steps to build containers and to deploy them to Azure Container Registry are straighforward.
But, I cannot figure out if it's possible to configure this task to deploy and run containers in ACI. There is an option to Run the Images, but the images are run on the agent's docker host:
How do I instruct this task that the containers to be run in ACI? I know there is a way to do that via Docker CLI with a step to connect to the ACI context, but I can't figure out how to switch to the ACI context from the DevOps pipeline.
How do I instruct this task that the containers to be run in ACI?
Ans:
The new release pipeline needs to start with an empty job and provide a name for the release definition. Next, we need to add artefacts to our application. Since all we want to deploy is a Docker image located in the ACR, select the artefact type as the Azure Container Registry (ACR).
Here is the blog tutorial to Configure CI/CD for Azure Container Instances using Azure / Azure DevOps Pipelines given by #mohitgoyal.
Azure Container instances
This is the first time i use docker image
when i trying build and upload new version code and push in Azure Container registries
but if i want to apply new version code , i must restart Container instances by manual to apply new version code , it annoys me and is a waste of time
How to resolove auto restart or redeploy when i push new version code in Container registries in Azure ?
this is log deploy azure of myself
I can think of a couple of ways to do this.
AKR Webhooks
I probably will approach this by looking at the webhooks in AKR.
Then, create a Logic App to receive the webhook call when a new image is pushed. References.
In the Logic App, you can call one of the Azure Container Instance APIs to restart the container group.
You will need to consider the security of the Logic App, which can only be called by your AKR's webhook.
CI/CD Pipelines
Assume that you have used a CI/CD platform like Azure DevOps, where you can create build pipelines.
The pipeline can build and push the images to your AKR, then create a step to run Az command to update the instance group.
I probably prefer the pipeline approach as I can see the history of what images have been released on the DevOps page.
I am using azure devops for CI/CD pipelines and one thing I couldn't find out, getting images from Azure container registry and run those images inside of my onpremise debian server. (I build and pushed the images to ACR already).
On release pipeline section:
I set Azure Container repository as source type and selected the latest artifact from there
then created a dev stage
Added a Command line tool to execute some scripts on server
-->This is the step where I lost<-- I need somehow to get these image from repository and fire compose up command in the server.
Extra info: you cannot use your docker-compose.yml(which mine is inside of the azure repo in same project) because you are using ACR as source type, not the build itself or source code.
*in my humble opinion this is a good case to enrich a content. Because there is lack of docs and videos on internet.
thanks,
I have a containerized app's image that builds on master push and ends up in azure container registry. I need to setup the next step where this image ends up on my linux on prem server.
I have established the connection with the server using a deployment group agent, which claims is healthy.
I have created a pipeline which takes the built image artifact as input but I am completely failing to grasp and create the step in which the artifact is being pulled on / pushed to the server (and ideally run too).
I am looking at the tasks in the pipelines > task section in Azure Devops but I cannot find a place to add some specific steps neither I am very sure what steps to add.
I would very much appreciate any tip on how to deploy a container from acr to on premises linux server using azure devops pipelines. Thank you in advance.
You can check this link which shows how to create Azure Pipeline CI/CD for docker container ,make sure all these steps are followed:
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops
I've installed sonarqube bitnami instance and manually installed sonar-scanner looking for a way to trigger the scan from cloud build, Is there a way I can reference this sonarqube VM instance in my cloudbuild.yaml (Don't want to use docker)
Like for example using container its pulled like (gcr.io/project-id/sonar-scanner:latest) I want it to be pulled from that bitnami VM instance.
It wouldn't be possible to use a VM instance to perform a build step. All steps that carried out on Cloud Build are performed using container images that are pulled and run on a single VM.
What you might be able to do is create an image that replicates as closely as possible the environment you have on that VM and include it as a custom build step.