"Load image from archive and push to registry" errors... "image does not exist locally"

[llakssz]

SUMMARY

Going by the examples here, pushing an image from a .tar file to a private registry is not working.
Ansible complains that the image does not exist locally.
Correct, the image does not exist locally, that's why I'm trying to push the .tar file.
I'm using source: load, not source: local, so I'm confused as to why my local images are getting checked, so I think this is a bug.

ISSUE TYPE

• Bug Report

COMPONENT NAME

community.docker.docker_image?

ANSIBLE VERSION

ansible 2.9.12
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/myuser/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/myuser/.local/lib/python3.6/site-packages/ansible
  executable location = /home/myuser/.local/bin/ansible
  python version = 3.6.9 (default, Oct  8 2020, 12:12:24) [GCC 8.4.0]

CONFIGURATION

blank (ansible-config dump --only-changed returns nothing)

OS / ENVIRONMENT

Ubuntu 18.04

STEPS TO REPRODUCE

- hosts: localhost
  tasks:
  - name: Load image from archive and push to a private registry
    community.docker.docker_image:
      name: registry.int.test/new-image-name
      tag: 1.2.3
      push: yes
      load_path: debian.tar
      source: load

tar file was created like:

docker pull debian
docker save debian > debian.tar

EXPECTED RESULTS

I'm not sure of the exact output I should be seeing, but I want the task to not fail! 😀

ACTUAL RESULTS

[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [localhost] ***********************************************************************************************************************************************************************************

TASK [Gathering Facts] *****************************************************************************************************************************************************************************
ok: [localhost]

TASK [Load image from archive and push to a private registry] **************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Error pushing image registry.int.test/new-image-name: An image does not exist locally with the tag: registry.int.test/new-image-name"}

PLAY RECAP *****************************************************************************************************************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

Extra

If it's of any use (shows my registry is functional, with the hello-world image etc), this works fine, hello-world-test.tar gets created :

- hosts: localhost
  tasks:
  - name: Archive image
    community.docker.docker_image:
      name: registry.int.test/hello-world
      tag: latest
      archive_path: hello-world-test.tar
      source: local

[felixfontein]

I think that loading images only works well when you specify the same name and tag that the image had when being saved. At least that's how docker save and docker load operate, and the module uses the same API as docker load, which - AFAIK - does not allow to query how the image that's loaded is actually called (or maybe one can extract that from the returned log).

I'm not very sure about this though, since I never store or load images to/from tar (or other) files.

[llakssz]

Thanks for your reply.

Ok, I tested what you said:
Simply getting the name and version/tag from my tar file:
docker load -i debian.tar => Loaded image: debian:latest

A new playbook, using the right name and version.

- hosts: localhost
  tasks:
  - name: Load image from archive and push to a private registry
    community.docker.docker_image:
      name: registry.int.test/debian
      tag: latest
      push: yes
      load_path: debian.tar
      source: load

The output is the same:
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Error pushing image registry.int.test/debian: An image does not exist locally with the tag: registry.int.test/debian"}

[felixfontein]

That's because name must be debian. The name of the image is debian:latest, not registry.int.test/debian:latest, and that's why the module cannot find it after loading. (At least I think so.)

[llakssz]

That's because name must be debian.

From the docs, Name format will be one of: name, repository/name, registry_server:port/name.
I was using option 2: (repository/name).

But ok, using name just for the name, and then I still need to put the registry url somewhere so I'd use repository:

- hosts: localhost
  tasks:
  - name: Load image from archive and push to a private registry
    community.docker.docker_image:
      repository: registry.int.test
      name: debian
      tag: latest
      push: yes
      load_path: debian.tar
      source: load

This doesn't error out, but it only adds the image to my local docker images. It doesn't get pushed to my registry.
If I use a registry url that doesn't exist:

TASK [Load image from archive and push to a private registry]
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Error pushing image blablabla.int.test: denied: requested access to the resource is denied"}

Error pushing image blablabla.int.test: ... seems like it thinks there is an image named the same as my registry name?

If I add https:// to the registry url (which is not allowed, I'm just testing):

TASK [Load image from archive and push to a private registry]
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: docker.errors.InvalidRepository: Repository name cannot contain a scheme (https://registry.int.test)
fatal: [localhost]: FAILED! => {"changed": false, "msg": "An unexpected docker error occurred: Repository name cannot contain a scheme (https://registry.int.test)"}

This shows me the registry url I provide does get processed somewhere, otherwise I wouldn't have gotten those 2 errors above.

At the moment I'm out of ideas, if someone else could have a try, or has any other input, that would be great! Thanks

[llakssz]

I think I have it, although I still think the implementation/documentation is not perfect. So I think a good idea to keep the issue open.

These are my steps:

Pull down an image, create a tar, and delete the image from our local docker.
(I may have put these steps above, I'm just adding them again for reproducibility!)

docker pull alpine:latest
docker save alpine:latest > alpine.tar
docker rmi alpine

Then run this playbook:

- hosts: localhost
  tasks:
  - name: Load image from archive and push to a private registry
    community.docker.docker_image:
      repository: registry.int.test/alpine
      name: alpine
      tag: latest
      push: yes
      load_path: alpine.tar
      source: load

The difference from my previous attempts was that this one includes the image name at the end of the repository value.

This will add the alpine image to our local docker, then tag it with our repository, and finally push the image to the remote registry!

It's important to keep in mind that the image will remain in our local docker install, but we can remove it afterwards if needed:
docker images

alpine   latest   ...
registry.int.test/alpine   latest   ...

[felixfontein]

That's because name must be debian.

From the docs, Name format will be one of: name, repository/name, registry_server:port/name.
I was using option 2: (repository/name).

These are three different (!) names for Docker.

The difference from my previous attempts was that this one includes the image name at the end of the repository value.

I.e. as in the module documentation and examples.

I think I have it, although I still think the implementation/documentation is not perfect.

The documentation and the interface could surely be improved. I don't agree on that the implementation isn't perfect, though, I think it did precisely what you told the module to do. (Which was different from what you wanted the module to do.)

If docker wouldn't come with such a chaos of image naming (and in some cases a not very helpful API, like the API for loading images from archives), life would definitely be easier for everyone.

[llakssz]

What I meant by the implementation/documentation not being perfect is that following the example did not work for me.
Whether that is due to a problem in the documentation, or a problem in the implementation, I'm not too sure.

Thanks for the assistance!

[felixfontein]

resolved_by_pr #55