I am working with Azure Container Instance group.. and one of my containers is constantly restarting.. it goes to a terminated state and restarts. Everything looks good in logs.. The container is running a spring framework + React application. When I run the containers locally.. it works perfectly.
Am not sure what is happening behind the scenes?
You could use Azure CLI to set a restart policy of OnFailure or Never.
az container create \
--resource-group myResourceGroup \
--name mycontainer \
--image mycontainerimage \
--restart-policy OnFailure
If you specify the restart policy and the issue still exists,there might be some problems with the application or script executed in your container. You could use az container show command to check the restartCount property.
az container show --name
--resource-group
For more details, refer to this article.
Related
from Azure we try to create container using the Azure Container Instances with prepared YAML.
From the machine where we execute az container create command we can login successfully to our private registry (e.g private.dev on JFrog Artifactory ) after entering password
docker login private.dev -u svc-faselect
Login succeeded
We have YAML file for deploy, and trying to create container using the az command from the SAME server.
az container create --resource-group FRONT-SELECT-NA2 --registry-login-server="private.dev"
--registry-username=svc-faselect --registry-password="..." --file ads-azure.yaml
An error response is received from the docker registry 'private.dev'. Please retry later.
I have only one image in my YAML file.
I am having real big problem to debug why this error is returned since Error response does not provide any useful information.
Search among the similar network issues but without success:
https://learn.microsoft.com/en-us/azure/container-registry/container-registry-troubleshoot-access
I see few moments that could be the reason of your problem.
There should be no = at az container create options
--registry-login-server --registry-password and --registry-username
https://learn.microsoft.com/en-us/cli/azure/container?view=azure-cli-latest#az_container_create-examples
Command should look like
az container create --resource-group FRONT-SELECT-NA2 --registry-login-server jfrogtraining-docker-dev.jfrog.io --registry-username svc-faselect --registry-password "..." --file ads-azure.yaml
I've successfully deployed RabbitMQ Bitnami docker to run as container instance in my Azure subscription, and I'm able to send messages to a queue which I defined via the RabbitMQ management web ui.
Thing is, that once i'm restarting the container instance, all messages and queues are gone.
I defined a file share under the same resource group, and invoked the following Azure CLI command to create the instance and "bind" it to the file share:
az container create -g learning1 --name rabbitmq-instance1 --image dbmregistry1.azurecr.io/bitnami/rabbitmq:latest --cpu 1 --memory 1 --ports 80 5672 15672 --dns-name-label db-rabbit1 --azure-file-volume-share-name dbshare1 --azure-file-volume-account-name {STORAGE-NAME} --azure-file-volume-account-key {KEY} --azure-file-volume-mount-path /data
But it seems not to be sufficient. In management web api it looks like that:
RabbitMQ node image
Appreciate any advice of what might be missing.
I've created a service principal with push and pull access to/from my private Azure Container Registry. Pushing to ACR works perfectly fine with the following command:
az login --service-principal -u "someSpID" -p "someSpSecret" --tenant "someTenantID"
az acr login --name "someRegistry"
docker push "someRegistry.azurecr.io/my-image:0.0.1"
And I am also able to pull the image directly with the following command:
docker pull "someRegistry.azurecr.io/my-image:0.0.1"
I want to deploy a container instance into a private subnet and I've configured the network security to allow access for my said subnet.
However, when I attempt to deploy a container instance with the following command into my private subnet, where I specified the same service principal which I had previously logged in with, I get an error response.
az container create \
--name myContainerGroup \
--resource-group myResourceGroup \
--image "someRegistry.azurecr.io/my-image:0.0.1" \
--os-type Linux \
--protocol TCP \
--registry-login-server someRegistry.azurecr.io \
--registry-password someSpSecret \
--registry-username someSpID \
--vnet someVNET \
--subnet someSubnet \
--location someLocation \
--ip-address Private
Error:
urllib3.connectionpool : Starting new HTTPS connection (1): management.azure.com:443
urllib3.connectionpool : https://management.azure.com:443 "PUT /subscriptions/mySubscription/resourceGroups/myResourceGroup/providers/Microsoft.ContainerInstance/containerGroups/myContainerGroup?api-version=2018-10-01 HTTP/1.1" 400
msrest.http_logger : Response status: 400
The image 'someRegistry.azurecr.io/my-image:0.0.1' in container group 'myContainerGroup' is not accessible. Please check the image and registry credential.
The same error ensues when I try and deploy the container instance through Azure Portal.
When I tried deploying a public image into the same subnet, it succeeds fine so it isn't a deployment permission issue, neither does it seem to be wrong service principal credentials as the docker pull "someRegistry.azurecr.io/my-image:0.0.1" works just fine. I can't quite wrap my head around this inconsistent behavior. Ideas anyone?
For your issue, here is a possible reason to explain the error you got. Let's look at the limitation describe here:
Only an Azure Kubernetes Service cluster or Azure virtual machine can
be used as a host to access a container registry in a virtual network.
Other Azure services including Azure Container Instances aren't
currently supported.
This limitation shows the firewall of the Azure Container Registry does not support the Azure Container Instance currently. It only supports that pull/push the image in the Azure VM or AKS cluster.
So the solution for you is that change the rules to allow all network and then try again. Or use the AKS cluster, but it will also cost more.
I have been working on the deployment of windows container from Azure Container Registry to Azure Container Service with Kubernetes Orchestra it was working fine previously.
Now I'm trying to create an acs kubernetes cluster of windows but the create command is only creating a master node and while deploying I'm getting the following error No nodes are available that match all of the following predicates:: MatchNodeSelector (1)
I have followed this link https://learn.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-windows-walkthrough to create the windows based kubernetes cluster.
This is the command I have used to create the cluster
az acs create --orchestrator-type=kubernetes \
--resource-group myResourceGroup \
--name=myK8sCluster \
--agent-count=2 \
--generate-ssh-keys \
--windows --admin-username azureuser \
--admin-password myPassword12
As per the above documentation, the above command should create a cluster named myK8sCluster with one Linux master node and two Windows agent nodes.
To verify the creation of cluster I have used the below command
kubectl get nodes
NAME STATUS AGE VERSION
k8s-master-98dc3136-0 Ready 5m v1.7.7
According to the above command, it shows that it created only the Linux master node, not the two windows agent nodes.
But in my case I require the windows agent nodes to deploy a windows based container in the cluster.
So I assume that due this I'm getting the following error while deploying No nodes are available that match all of the following predicates:: MatchNodeSelector (1)
As the documentation points out, ACS with a target of Kubernetes is deprecated. You want to use AKS (Azure Kubernetes as a Service).
To go about this, start here: https://learn.microsoft.com/en-us/azure/aks/windows-container-cli
Make sure you have the latest version of the CLI installed on your machine if you choose to do it locally, or use the Azure Cloud Shell.
Follow the guide on the rest of the steps as it will walk you through the commands.
For your issue, as I know the possible reason is that you need to enable the WindowsPreview feather. You can have a check through the CLI command like this:
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/WindowsPreview')].{Name:name,State:properties.state}"
When it's OK, you also need to pay attention to the Kubernetes version. When I use the command that you have used, then the windows nodes are created successfully, but it just shows the master when I execute the command kubectl get nodes. Even if I can see the windows node in the group.
Then I try the command with additional parameter --orchestrator-version and set the value as 1.12.7 and the whole command like below:
az acs create --orchestrator-type=kubernetes \
--resource-group myResourceGroup \
--name=myK8sCluster \
--agent-count=2 \
--generate-ssh-keys \
--windows --admin-username azureuser \
--admin-password myPassword12 \
--orchestrator-version \
--location westcentralus
Then it works well and the command kubectl get nodes -o wide show like below:
But as you know, the ACS will be deprecated. So I would suggest you use the AKS with Windows node in the preview version. Or you can use the aks-engine as the AKS Engine is the next version of the ACS-Engine project.
I run the following Azure CLI command:
az container create --resource-group Experimental --name my-sage
--image sagemath/sagemath-jupyter --ip-address public --ports 8888
and get the following error
The OS type 'null' of image 'sagemath/sagemath-jupyter' does not
match the OS type 'Linux' of container group 'my-sage'.
Even though the sagemath image is built on Ubuntu Xenial image: https://github.com/sagemath/docker-images
How can I fix this?
Currently, Azure Container instance does not support this image. You could try to create this image on Azure Portal, you will get same error log.
Please check this official document.
Azure Container Instances is a great solution for any scenario that can operate in isolated containers, including simple applications, task automation, and build jobs.
For your scenario, I suggest you could use Azure Container Service(aks).
The --os-type should default to Linux, if for some reason yours is not you can set the OS Type on the command.
az container create --resource-group Experimental --name my-sage
--image sagemath/sagemath-jupyter --ip-address public --ports 8888 --os-type Linux
Hope this helps.