How to troubleshoot Docker problems
Relevant versions: This information pertains to Artifactory versions 4.0.2 and above
When troubleshooting Docker errors, it's best to compare what is supposed to happen against what your system is currently experiencing. You can eliminate a great deal of noise by simulating each step your client is taking and examining what HTTP error code is returned by Artifactory. In general, these are the error codes you might encounter and their meaning:
403 and 401: Authentication issue, examine authorization settings
404: Resource not found, check the repository for the resource
400: Incorrect request, use cURL to get reason phrase
50X: Server problem, examine the artifactory.log
Using curl
The libcurl terminal application can run basic REST API commands such as GET or PUT options. Your Artifactory request logs will display the exact API commands your Docker client uses. You can use the one that is failing (as listed in the request.log file) or use one of these examples below to try to acquire further information on the problem being encountered, as well as possible next steps.
Basic usage (with #comments):
curl -uadmin #Artifactory-username -vvv #verbosy -k #ignore-insecure-SSL -XGET #GET-request http://localhost:8081/artifactory/api/system/ping
cURL uses GET requests by default. Other commands, like PUT, require the --data field, along with a (typically, JSON) data payload. Here's a sample PUT command:
curl -uadmin:password -XPUT -H"Content-type: Application/json" --data '{"name":"test-group"}' http://localhost:8081/artifactory/api/security/groups/test-group
docker login docker.art.local
These are backend steps that occur when a user tries to authenticate against Artifactory using Docker:
docker login docker.art.local
*.art.local is the web address used by a reverse proxy configured for subdomain Docker repositories
1. The Docker client checks the existence of Artifactory via an anonymous GET request:
20180523095407|0|REQUEST|127.0.0.1|non_authenticated_user|GET|/api/docker/docker/v2/|HTTP/1.0|401|0
The 401 HTTP code should be expected if Artifactory does not allow anonymous access to the repository in question. If a 200 OK is seen by the Docker client, then credentials will not be used.
2. The Docker client gets an access token:
This can be replicated via the following cURL command:
which returns a JSON with the following token value:
docker pull docker.art.local/nginx
2. The client uses the information in the manifest file to pull the image layers that make up the image:
20180523095423|2169|REQUEST|127.0.0.1|admin|GET|/api/docker/docker/v2/nginx/blobs/sha256:4a99993b863683bef1c776732e14d2372f6ed52b48e94783f4a1b58af289db07|HTTP/1.0|200|201
This completes the pull. If a layer is missing, the container's manifest should be inspected, and all layer requests should return a 200 OK.
docker push docker.art.local/ubuntu
docker push docker.art.local/ubuntu
1. The Docker client will check for the existence of the layers it needs to push:
A 404 not found should be expected at this stage if the layer does not exist in Artifactory yet.
2. The client runs a POST command to submit the blob metadata:
3. The client will PATCH the rest of the blob metadata to Artifactory:
4. Finally the client sends the layer binary:
5. Artifactory moves the binaries from a temporary _uploads folder to the Docker image's main location at the base directory of the repository: