Docker Migration from Nexus – Feature Not Working

koksime.yap_5909

I don’t think the reverse proxy strips the component API. In the configuration of the reverse proxy, we map a URL to a port, so when a client accesses the server using a specific URL, the request is routed to the corresponding listening port.

Thanks.

rhessinger

Hi @koksime-yap_5909,

Thank you very much for all the information. I was able to recreate your issue and I'm working on a fix right now. I have created a ticket, PG-3178, to track the fix and should have it resolved shortly. The next release is Friday of next week, but I can provide you with a pre-release to try as soon as the fix is ready if you would like. Please let me know.

Thanks,
Rich

koksime.yap_5909

Hi @rhessinger ,

Thanks for your help! I’m fine waiting until the release next Friday.

rhessinger

Hi @koksime-yap_5909,

Sounds good. The fix will be released on Friday December 19th.

Thanks,
rich

koksime.yap_5909

Hi @rhessinger ,

Thanks for the support. I am now able to import container images from Nexus.

However, I notice that images with OCI media type are not imported. Is that expected?

Output of execution:

INFO: Importing example:0.0.1...
WARN Docker image "example:0.0.1" not found.

The example:0.0.1 has the following value returned from the https://«NEXUS_HOST_AND_PORT»/service/rest/v1/components?repository=«REPOSITORY_NAME» API:

"contentType" : "application/vnd.oci.image.manifest.v1+json",

rhessinger

Hi @koksime-yap_5909,

There are certain types of OCI images that are not supported in ProGet (covered in this forums post), but the application/vnd.oci.image.manifest.v1+json image type manifest is supported. I'm guessing this is a quirk with Artifactory. What I have learned through implementing this importer is that Artifactory is very dependent on the order of accept headers. It is possible that the order is not quite right. Our order for the importers are:

private static HttpRequestMessage CreateDockerHttpRequest(HttpMethod method, string url)
{
    var request = new HttpRequestMessage(method, url);
    // Order matters here, especially with Artifactory
    request.Headers.Accept.Add(new("application/vnd.docker.distribution.manifest.v2+json"));
    request.Headers.Accept.Add(new("application/vnd.docker.distribution.manifest.list.v2+json"));
    request.Headers.Accept.Add(new("application/vnd.docker.distribution.manifest.v1+prettyjws"));
    request.Headers.Accept.Add(new("application/json"));
    request.Headers.Accept.Add(new("application/vnd.oci.image.manifest.v1+json"));
    request.Headers.Accept.Add(new("application/vnd.oci.image.index.v1+json"));

    return request;
}

Is it possible to share an example Docker file that we could build an image that has this import image? That way I can verify it mixed with standard Docker images.

Thanks,
Rich

koksime.yap_5909

Hi @rhessinger ,

Unfortunately I do not have an example of Dockerfile to build the image.

However, after further investigation, I noticed that this only happens when the top-level mediaType is missing in the image when I used the docker manifest inspect <image> to check the manifest.

After I updated the manifest with top-level mediaType manually, the ProGet is able to identify the image and migrate it from the Nexus.

rhessinger

Hi @koksime-yap_5909,

Ah ok. It make sense that we would not be able to pull those based on the accept headers. How many images do you have without a media type? Are these mostly old images or are there new ones missing this as well? Do you know how to recreate an image in Nexus without a media type?

Thanks,
Rich

koksime.yap_5909

Hi @rhessinger,

I currently do not have an overview on how many images without top-level mediaType.

To have an image in Nexus without top-level mediaType, you can use the oras CLI tool to manipulate the manifest.

For my testing, I used skopeo to copy an OCI image (e.g. alpine/git:v2.52.0) to Nexus.

skopeo copy --dest-creds <user>:<password> --dest-tls-verify=false docker://alpine/git:v2.52.0 docker://registry.nexus.example/docker/alpine/git:v2.52.0

Then I used the oras to:

fetch the manifest

oras manifest fetch --insecure registry.nexus.example/docker/alpine/git:v2.52.0 > manifest.json

Edit the manifest.json, and remove the top-level mediaType

Push the manifest back to the registry

oras manifest push --insecure --media-type application/vnd.oci.image.manifest.v1+json registry.nexus.example/docker/alpine/git:v2.52.0 manifest.json

After that, when inspecting the manifest with docker manifest inspect, the top-level mediaType should be missing from the image. And when trying to do migration in ProGet, it will show that the image is not found.

I hope the information shared above is useful. Thank you.

rhessinger

Hi @koksime-yap_5909,

Thanks for sharing the steps. I'm going to attempt to reproduce this and I'll let you know what i find!

Thanks,
Rich

koksime.yap_5909

Hi @rhessinger ,

Just checking in to see if you had a chance to look into this.

And I’d like to know whether a product fix is planned, or if I should rely on the workaround.

Thanks.

rhessinger

Hi @koksime-yap_5909,

I apologize for the delay. This is next on my list to review and I will have an update for you on Monday.

Thanks,
Rich

rhessinger

Hi @koksime-yap_5909,

After looking into this further, although we can fix the import to handle the images without a media type, it will still be broken when you attempt to pull those images using the Docker client. This is because ProGet will only send the manifest as it is stored in ProGet, where Nexus will manipulate it to match the accept headers of the client. Since it is only returning the manifest as it is stored, the media type will be null which will cause the Docker client to fail with a missing or empty Content-Type header.

Since we cannot assume what the mediaType should be, I think it would be better to resolve those prior to importing into ProGet. The nice thing is you can use the import logs to identify what images are missing the media type. You can run the import multiple times and it will only import the missing images and layers.

Thanks,
Rich

koksime.yap_5909

Hi @rhessinger,

Thanks for taking the time to investigate this and for the detailed update.

Given that the fix likely won’t work, I’ll proceed with the workaround on my side.

Appreciate the help.

rhessinger

Hi @koksime-yap_5909,

No problem! Happy to help!

Thanks,
Rich