Let's say we have a (containerized) backend which is only sparely used. Maybe once every couple of days or so, a (static) web front-end calls an API endpoint of that backend.
The backend conveniently happens to be stateless. No data store or anything.
We want to minimize the hosting cost for it, and ideally would like per-second billing. It's only gonna be running for a few minutes every month, and we only want to be charged for that usage. Basically, we want Function as a Service (FaaS), but for a whole backend and not just a single function.
Azure Container Instances appears to be great fit for this scenario. It can spin up the backend in a container when needed. The backend then can shut itself down again after a certain period of non-usage.
So, let's create a container instance...
az container create \
--resource-group myResourceGroup \
--name mycontainer \
--image mycontainerimage \
--restart-policy Never
--dns-name-label mybackend123
--ports 80
Great, our backend is live at its FQDN http://mybackend123.eastus.azurecontainer.io!
As stated above, it'll shut itself down after a period of non-usage. Thanks to --restart-policy Never, ACI won't restart the container but keep it around in status Stopped.
My question is: is there any way to automatically start the container again if a web request to the FQDN arrives?
Sure, we can wake it up ourselves by running...
az container start --resource-group myResourceGroup --name mycontainer
... or with an equivalent API call. But then the service that does that needs to be running all the time! Ideally, I'd like the container to start itself whenever a request comes in.
Azure Container Instances don't have a wehbook or HTTP trigger that will start them. However, you could use an Azure Function or Logic App that would effectively run az container start for you and then call THAT with HTTP. With either of those approaches, you'd have to setup some IAM permissions to give the Function or Logic App permissions to the ACI resource to start it.
One approach would be to:
Create an Azure Function with an HTTP trigger and a managed identity
Give the Managed identity contributor access to ACI container group
Run az container start or the equivalent REST call inside the function to start the ACI container
Call the Azure function (using the function token) to start the container.
Related
I have an Azure Container Instance (ACI) that is deployed from a custom container image, which I stored in Azure Container Registry (ACR).
The container image runs a simple Python script (background worker, no exposed ports), which works locally on my Windows 11 system, using Docker Desktop. The script prints some logging text using the print() function, so I can see what's going on inside the application.
While ACI starts the container, it doesn't show any events, under the container Events tab, and it also doesn't show any logs, under the Logs tab.
However, the container is actually running, and I can use the Connect tab to open an interactive shell into the container. I can run ps -aux and see that the Python script (entrypoint) is actually running.
Question: Why are the Events and Logs not populating in the Azure Container Instances service, even though the container is successfully up and running?
NOTE: I am deploying to the West Central US Azure region.
under the container Events tab, and it also doesn't show any logs, under the Logs tab.
We have another option in Azure CLI to get the Logs of Azure Container Instance.
In Azure Portal, Open Cloud shell.
Run the below command in Azure Cloudshell - Bash.
az container logs --name YourContanerInstanceName --resource-group YourRGName
OutPut of Logs:
To get the Events, use the below CLI Command.
az container show --resource-group YourRGName --name YourContanerInstanceName
Output of Events:
Why are the Events and Logs not populating in the Azure Container Instances service, even though the container is successfully up and running?
Also refer Options to View Container Logs.
Reference taken from MSDoc Container logs and Diagnostic Events.
my scenario is like I have shared container registry in one subscription say subscription A, I need to pull image from ACR to ACA through DevOps pipelines. The ACAs are present for each environment like dev, test, UAT & etc which is in another subscription say subscription B. I am using 'az containerapp up' command in azure devops pipelines to pull image of the shared ACR. Getting error 'The resource is not found in the subscription B'. What might be the alternative possible solution because we need to reduce cost of using container registry for each environment.
I am using service connections to pull image and the service connections are separate for separate subscriptions.
I know that they are in different subscriptions but I searched on websites to connect two different subscriptions.
Is there a possibility that I can connect two different service connections in azure devops & use one service connection to pull that image.
Before integrating the Azure CLI command az containerapp up with Azure pipelines, please first confirm you are able to pull the ACR image from Sub B to deploy the container app in Sub A via CloudShell or LocalPowerShell.
I tested to create ARM service connection with Tenant Root Management Group whose referenced service principle had access to both subscriptions; the issue still existed.
In local PowerShell, I az login with my user account and still could reproduce the issue.
az containerapp up `
--name XXcontainerapp `
--image XXacrsubB.azurecr.io/azurecontainerappdemo:XX `
--resource-group rg-containerapp `
--environment TestEnv `
--registry-username XXacrsubB `
--registry-password XXXXXX
It seemed to be a limitation with this command az containerapp up. You may consider reporting the issue with Azure CLI.
I have an azure container instance running in a vnet within a subnet.
I have been (until now) able to update the image of this container instance with a command like this one:
az container create \
--resource-group my_rg\
--name containername \
--image containerregistry.azurecr.io/myimage:latest \
--registry-login-server containerregistry.azurecr.io \
--registry-username username \
--registry-password password \
--vnet my_vnet \
--subnet my_subnet
Until now, when I needed to update the image in my container, I would build it, push it to my container registry in azure, and run this command.
The container would stop and restart with the new image.
It may not be the issue but I upgraded my azure cli recently, I am now on version 2.34.1.
When I run this command now I get this message:
(NetworkProfileCannotChange) The network profile of existing container group 'containername' cannot be changed. To change a network profile, you must delete and then create the container group with the changed property.
Code: NetworkProfileCannotChange
I don't want to change my network profile, I just want to update the image.
I have seen it with
az network profile list --resource-group my_rg
It looks fine for me.
I have double checked, my vnet and my subnet have not changed.
I don't understand why this command does not work anymore.
Any idea of what's happening ?
Cheers
Tested in my enviroment it is working fine for me with both the version.
Earlier i was using the AZ CLI version 2.32.0 able to create the Container.
Now i have updated the AZ CLI version to 2.34.1 and trying to change or update the image of container using the same command with same existing VNET and Subnet
Getting Simmillar Kind of Error when i am changing the Subnet name.
Suggestion 1 : Would suggest you to recheck if your existing container is not taking another subnet or VNET when you are creating container with updated images.
Suggestion 2 : Sometimes it might stopes you to update the Image on Running and exist conatainer, you get this error: "If you are going to update the os type, restart policy, network profile, CPU, memory or GPU resources for a container group, you must delete it first and then create a new one"
Suggestion 3 : TO avoid the recreation of conatainer scheduled container instance that is running once a day. Whenever it starts it is pulling the docker image with the :latest tag from the azure container registry. This avoids re-creation of the container group.
For more information You can refer this https://circleci.com/blog/azure-custom-images/ and Related Issue
Created a program to restart the Azure App Service instance programmatically. I am using below api to stop the w3wp process.
https://management.azure.com/subscriptions/{subscriptionid}/resourceGroups/{resourcegroup}/providers/Microsoft.Web/sites/{sitename}/instances/{instanceId}/processes/{processId}?api-version=2021-02-01
This is a DELETE (HttpVerb) call and it is throwing 403 - Forbidden error.
However i could execute GET calls for the same clientId. I would like to know whether it is an access issue with the clientid i am using or the approach am following to stop the process is not right.
If it is an clientId access issue, where to check it and what specific access has to be requested.
You should restart the App Service instead of trying to stop the w3wp process:
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/restart?api-version=2021-02-01
https://learn.microsoft.com/en-us/rest/api/appservice/web-apps/restart
Using the CLI:
az webapp restart --name MyWebapp --resource-group MyResourceGroup
https://learn.microsoft.com/en-us/cli/azure/webapp?view=azure-cli-latest#az_webapp_restart
I have successfully created a docker image that runs inside a docker container. The container successfully executes the image (a .NET app) but the image crashes shortly after startup because it encounters an error with Azure Services. The reason is because the docker container is attempting to access Azure Services to fetch an authorization token (to fetch secrets from a key vault) and does not have authority to do so.
I should note that it is possible to run the app locally outside of a container via the Azure CLI after using az login to verify my credentials. Then, when the app is started via Azure CLI, it is 'allowed' to access Azure Services to get autho tokens and consequentially fetch data from my key vault.
Would like to know if there is a way to run an az login script with credentials inside a docker container before the .NET app image executes, so that I can start the application from within the Azure CLI (inside the container) after my credentials have been verified. I have looked through the documentation and have not seen a way to configure something like this.
To use the Azure CLI and login inside the container, you need to install the Azure CLI inside the container, then login with an non-interactive model. I would recommend the service principal. You can take a look at the command:
az login --service-principal -u <app-url> -p <password-or-cert> --tenant <tenant>
For more details, see Create an Azure service principal with Azure CLI. After login, then you can start your application as need.
Here are 2 options which don't require Azure CLI in the container, Azure Managed Identity from within a docker container running locally,
inject an access token into the container using ENV variable
use device authentication flow to obtain an access token
I read this answers a while ago. I was looking for the similar solution but using the service principal. I found that Docker can run Kubernetes and there is AAD-Pod-Identity https://github.com/Azure/aad-pod-identity which can do work for me, but it doesn't work for Docker Kubernetes. I forked their Go repository and make modification for mic component. Now it works for Docker Kubernetes, not sure whether Azure team has plans get these modifications on board or not.
You can get detailed instructions how to get things running here: https://github.com/Wallsmedia/aad-pod-identity
Azure CLI would not work for a Docker, because you have setup Azure CLI and login and then run your application.