Container Registry:Image building diagnosis

Image building diagnosis overview

The image building diagnosis feature combines expert experience with the AI capabilities of Tongyi Qianwen to precisely locate the root cause of issues and provide actionable repair suggestions.

The diagnosis feature consists of two main parts:

• Rule detection: Includes instruction checks and error log analysis.

• Root cause analysis: Includes the identified root cause and repair suggestions.

  The service collects relevant data from your Container Registry (ACR) instance and identifies anomalies. It then performs an in-depth diagnosis to determine the root cause of issues and proposes solutions.

Diagnosis process

Image building diagnosis first collects the necessary data from your Container Registry (ACR) instance and then performs an in-depth analysis of any exceptions. After you initiate a diagnosis, the process consists of three stages:

• Data preprocessing: Collects required data, such as instance status, repository configuration, build rule information, and build logs, to quickly analyze build exceptions.

• Rule detection: Analyzes the collected data to identify exceptions, potential risks, and opportunities to optimize the build process.

• Root cause analysis: Automatically determines the root cause of issues and provides repair suggestions, based on the collected data and detected items.

Diagnosis results

The diagnosis results include two parts:

• Items to be fixed: Includes the root cause of the exception, a repair suggestion, and the location of the exception.

• AI diagnosis: Analyzes build instructions or configuration items in-depth based on exception details to provide comprehensive optimization suggestions.

Diagnosis rules and repair suggestions

1. On the Image Build Diagnostics page, click Diagnostics. In the Select Image Build Task panel that appears, select the image build task to diagnose using the following parameters.

   • Namespace: The namespace to which the image build task belongs.

   • Repositories: The image repository to which the image build task belongs.

   • Image Build Task ID: The ID of the image build task.

   After making your selections, carefully read the notes, select I understand and agree, and then click Initiate Diagnostics.

2. After the diagnosis is complete, you can take action based on the repair suggestions on the page. The following table describes common diagnosis rules, root causes of exceptions, and their corresponding repair suggestions.

   Diagnosis rule group	Diagnosis rule name	Root cause	Repair suggestion
   Dockerfile syntax detection	Invalid port definition	The port or protocol format in the EXPOSE instruction is incorrect.	When using the EXPOSE instruction, ensure the port is a number between 0 and 65535, and the protocol is TCP or UDP.
   	Copy instruction syntax detection	The destination path is not a directory when copying multiple source files.	Ensure the destination path is a directory.
   	Build stage does not exist	The build stage specified by the COPY instruction does not exist.	Ensure the stage name refers to a previously defined build stage.
   	Duplicate stage name	A build stage name is reused.	Avoid using duplicate build stage names.
   	Invalid first instruction	The first instruction is not FROM or ARG.	Ensure the first instruction is FROM or ARG.
   	Compilation error	A precompilation error occurred in the Dockerfile.	Correct the syntax errors in the Dockerfile or wait for the repair suggestion from the root cause analysis.
   	Compilation warning	A precompilation warning occurred in the Dockerfile.	Review the relevant instructions in the Dockerfile, as they may not run as expected.
   Image tag detection	Base image tag not specified	No specific image tag is provided for the base image.	Specify a fixed image tag. Using an unspecified tag (which defaults to latest) makes your build unpredictable, as the base image can change unexpectedly.
   	Base image does not exist	The base image name is incorrect or the image does not exist.	Check the base image name or select a different base image that exists.
   Runtime error detection	Command execution error	A command failed to run.	Check if the command specified in the Dockerfile is correct, or wait for the repair suggestion from the root cause analysis.
   	Command does not exist	The specified command does not exist.	Ensure the command specified in the Dockerfile exists in the base image.
   	File does not exist	A source file or directory in a COPY instruction does not exist.	Verify that the file or directory referenced by the COPY command in the Dockerfile exists in the build context.
   Invalid instruction detection	Invalid command detection	The Dockerfile contains unsupported instructions such as Kill or Shutdown.	Using instructions such as Kill or Shutdown in the build process can cause security and stability issues. You must remove these instructions.
   	sudo command detection	The sudo command is ineffective in a build process.	Remove the sudo instruction.
   Upload stage error detection	Tag conflict	The image tag conflicts with an existing image tag in the repository.	To resolve the image tag conflict, disable the tag immutability feature for the repository or avoid repeatedly pushing an image with the same tag.
   Image size optimization detection	Potential optimization for apt-get instructions	The apt update and apt install commands are in separate instructions.	Separating the apt update and apt install instructions can increase the image size and reduce the efficiency of repeated builds.
   	Potential optimization for apt-get instructions	The apt-get install command runs without the --no-install-recommends parameter.	To reduce the image size, add the --no-install-recommends parameter to your apt-get install command.
   	Potential optimization for package installation	Package manager cache is not cleared after package installation.	To reduce the image size, clear the cache after you install packages. For example, use the apt-get clean command for Ubuntu, use the apk add command with the --no-cache flag for Alpine, or use the yum clean all command for CentOS.
   	Multi-stage build detection	The Dockerfile does not use a multi-stage build to separate build-time dependencies from the final image.	Use a multi-stage build to compile your application in a separate build stage, and then copy the resulting artifacts to the final image. This can significantly reduce the final image size.
   	Redundant compressed packages	Downloaded archives are not cleaned up after extraction.	To reduce the image size, combine the download, extraction, and cleanup commands for compressed packages into a single RUN instruction.
   Build instruction optimization detection	Relative path detection	The WORKDIR instruction uses a relative path.	Using a relative path with WORKDIR can lead to an unexpected working directory and cause build failures. Use an absolute path for clarity and reliability.
   	Root user detection	The USER instruction switches to the root user.	Switching to the root user during the build creates a security risk when the container is running. You must remove this instruction.
   	Path switching optimization detection	A RUN instruction uses the cd command to change directories.	The effect of a cd command is limited to the RUN instruction in which it appears. To set the working directory for subsequent instructions, use the WORKDIR instruction instead.
   	CMD or ENTRYPOINT override detection	The Dockerfile contains multiple CMD or ENTRYPOINT instructions.	If you use multiple CMD or ENTRYPOINT instructions, only the last one takes effect. Ensure the final instruction is the one you intend to use.