1
votes

I am trying to run an image on ACI, whenever it is trying to pull image as this pulling image "mysql@sha256:asakjvnankvaknaklfvkabjaoenla" the container is failing, whereas in command i have given image as mysql:latest.

az container create \
    --resource-group $ACI_PERS_RESOURCE_GROUP \
    --name xxxxxxx \
    --location eastus \
    --image mysql:latest \
    --dns-name-label xxxxxxxx \
    --environment-variables MYSQL_ROOT_PASSWORD=password@123 \
    --ports 3306 33060 \
    --azure-file-volume-account-name $ACI_PERS_STORAGE_ACCOUNT_NAME \
    --azure-file-volume-account-key $STORAGE_KEY \
    --azure-file-volume-share-name $ACI_PERS_SHARE_NAME2 \
    --azure-file-volume-mount-path /var/lib/mysql

The issue is when it try to pull image as mysql@sha256:asakjvnankvaknaklfvkabjaoenla, the continer fails to start while if the image pulled is pulling image "mysql:latest" than container works.

Attaching the pic for refrenece. Successfull Container

Failed Container Not sure why this issue is happening

Command to run three containers

ACI_PERS_RESOURCE_GROUP=myresourcegroup
ACI_PERS_STORAGE_ACCOUNT_NAME=mydatabasest2501
ACI_PERS_LOCATION=eastus
ACI_PERS_SHARE_NAME=mysqlshare1
ACI_PERS_SHARE_NAME2=mysqlshare2
ACI_PERS_SHARE_NAME3=mysqlshare3


#I already have storage account so only creating fileshare


# Create the file share
az storage share create \
  --name $ACI_PERS_SHARE_NAME \
  --account-name $ACI_PERS_STORAGE_ACCOUNT_NAME
  

# Create the file share
az storage share create \
  --name $ACI_PERS_SHARE_NAME2 \
  --account-name $ACI_PERS_STORAGE_ACCOUNT_NAME


# Create the file share
az storage share create \
  --name $ACI_PERS_SHARE_NAME3 \
  --account-name $ACI_PERS_STORAGE_ACCOUNT_NAME  
 

 
  
  
  
echo $ACI_PERS_STORAGE_ACCOUNT_NAME

STORAGE_KEY=$(az storage account keys list --resource-group $ACI_PERS_RESOURCE_GROUP --account-name $ACI_PERS_STORAGE_ACCOUNT_NAME --query "[0].value" --output tsv)
echo $STORAGE_KEY  


az container create \
    --resource-group $ACI_PERS_RESOURCE_GROUP \
    --name contaier1 \
    --location eastus \
    --image mysql:latest \
    --dns-name-label uniqueddns1 \
    --environment-variables MYSQL_ROOT_PASSWORD=password@123 \
    --ports 3306 33060 \
    --azure-file-volume-account-name $ACI_PERS_STORAGE_ACCOUNT_NAME \
    --azure-file-volume-account-key $STORAGE_KEY \
    --azure-file-volume-share-name $ACI_PERS_SHARE_NAME \
    --azure-file-volume-mount-path /var/lib/mysql
    
    

az container create \
    --resource-group $ACI_PERS_RESOURCE_GROUP \
    --name contaier2 \
    --location eastus \
    --image mysql:latest \
    --dns-name-label uniqueddns2 \
    --environment-variables MYSQL_ROOT_PASSWORD=password@123 \
    --ports 3306 33060 \
    --azure-file-volume-account-name $ACI_PERS_STORAGE_ACCOUNT_NAME \
    --azure-file-volume-account-key $STORAGE_KEY \
    --azure-file-volume-share-name $ACI_PERS_SHARE_NAME2 \
    --azure-file-volume-mount-path /var/lib/mysql


az container create \
    --resource-group $ACI_PERS_RESOURCE_GROUP \
    --name contaier3 \
    --location eastus \
    --image mysql:latest \
    --dns-name-label uniqueddns3 \
    --environment-variables MYSQL_ROOT_PASSWORD=password@123 \
    --ports 3306 33060 \
    --azure-file-volume-account-name $ACI_PERS_STORAGE_ACCOUNT_NAME \
    --azure-file-volume-account-key $STORAGE_KEY \
    --azure-file-volume-share-name $ACI_PERS_SHARE_NAME3 \
    --azure-file-volume-mount-path /var/lib/mysql   
    
    
1
well, look at the logs? image is pulled successfully, so why do you think it has something to do with that4c74356b41
did you ever figure this out? I have the EXACT same problem. the cause is definitely related to the simultaneous creation of multiple containers using the same image. i create 7 container groups simultaneously, and 1-2 of them always pulls the container using a digest (container@shah256:...) vs the image tag (container:0.0.5). no idea why this occurs or why the container gets killed. fyi I have no file shares, and my container is in the ACR. I think maybe some sort of weird caching going on behind the scenes by ACI when the same image is pulledriptusk331

1 Answers

1
votes

The problem does not due to the reason that you think, it's a problem with the volume that mounts the Azure File Share to the existing folder which is the dependency of the MySQL. When you mount the File Share, it will Occlude the existing folder then all the files in this folder will not be accessible. Therefore MySQL will not work fine anymore by losing the dependencies. See more details here.

Mounting an Azure Files share to a container instance is similar to a Docker bind mount. Be aware that if you mount a share into a container directory in which files or directories exist, these files or directories are obscured by the mount and are not accessible while the container runs.

There are three ways to solve it. The first way is that not mount the File Share, but then you cannot persist the data of the database. The second way is to mount the File Share to a new folder that does not exist in the image and then copy the data to the new folder. The third way is that copy the dependencies into the File Share and then mount the File Share to the container, it will also work.

Update:

A possible solution is that you can push the MySQL image to an ACR and then use it to create ACI, in this way, all the things are the same, then maybe all ACI succeeds or fails.