Skip to content

[24.0 backport] Fix insecure registries reload#45571

Merged
thaJeztah merged 2 commits intomoby:24.0from
thaJeztah:24.0_backport_fix_insecure_registries_reload
May 19, 2023
Merged

[24.0 backport] Fix insecure registries reload#45571
thaJeztah merged 2 commits intomoby:24.0from
thaJeztah:24.0_backport_fix_insecure_registries_reload

Conversation

@thaJeztah
Copy link
Member

- What I did

Fixed a small bug where when both insecure-registries and registry-mirrors are set in daemon.json, when executing a daemon reload (such as with systemctl reload docker) the insecure registries are no longer in the daemon's loaded configuration.

- How I did it

Reordered the loading of the insecure registries to occur after the loading of the mirrors. This matches a newly started daemon's configuration loading order.

The overwriting occurs because loadMirrors() creates a new map for config.IndexConfigs.

I added a mirror to the unit test to demonstrate this.

- How to verify it

Through the unit tests:

  1. Apply only the first commit to daemon/reload_test.go
  2. Run make test-unit
  3. Apply the second commit
  4. Run make test-unit

Independently on Linux:

  1. Create a daemon.json that has both insecure-registries and registry-mirrors
  2. Start the dockerd daemon
  3. Verify the insecure registries are loaded with docker info
  4. Reload the daemon (e.g. systemctl reload docker or kill -s HUP <pid>)
  5. Without this fix, docker info will not show the registries are loaded. With it, it will.

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

Signed-off-by: Nolan Miles <nolanpmiles@gmail.com>
(cherry picked from commit 3b15156)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Nolan Miles <nolanpmiles@gmail.com>
(cherry picked from commit f3645a2)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah added this to the 24.0.1 milestone May 18, 2023
@thaJeztah
Copy link
Member Author

@corhere @neersighted PTAL

@thaJeztah
Copy link
Member Author

integration got stuck twice after it failed to stop a daemon; should not be related, but worth looking why it gets stuck and/or id there's something to improve elsewhere

=== RUN   TestDockerSwarmSuite/TestSwarmUpdate
=== RUN   TestDockerSwarmSuite/TestSwarmVolumePlugin
    check_test.go:565: [df7783e084b59] error while stopping the daemon: exit status 130
=== RUN   TestDockerSwarmSuite/TestUnlockEngineAndUnlockedSwarm
Error: The operation was canceled.

@thaJeztah
Copy link
Member Author

TestDockerSwarmSuite is happy now; the bin-image failure is known, and unrelated; bringing this one in

@thaJeztah thaJeztah merged commit a0bc3eb into moby:24.0 May 19, 2023
@thaJeztah thaJeztah deleted the 24.0_backport_fix_insecure_registries_reload branch May 19, 2023 08:51
@EncryptShawn
Copy link

Now that I have updated Docker to 24, insecure registries no longer works at all. Whatever I have in my daemon.json is ignored and never shows up in docker info and thus, I can no longer operate my datacenter since using a cert for a private repo on a private datacenter only leads us to fail once a year and do extra work to secure nothing inside our already secured datacenter.

Only seeing a few complaints about it and this is the only code update I see about messing with the insecure registry. Not sure its related but this all worked on this machine, prior to this update.

@neersighted
Copy link
Member

insecure-registries is widely used by many people; this PR was not intended to break it, and I can't reproduce it being currently broken. If you can reproduce this problem on a clean install of a 24.x version, please open a new issue with your configuration and other reproduction instructions there.

@sheenilim08
Copy link

insecure-registries is also not working for me.
Docker version 24.0.5
OS: Ubuntu 22.04.3 LTS
Kernel: 5.15.0-82-generic

/etc/docker/daemon.json
{
"insecure-registries": ["my_ip_address:port_number"]
}

after restarting the service "sudo systemctl restart docker", the insecure registry is not showing on "docker info"

@thaJeztah
Copy link
Member Author

@sheenilim08 I'm not able to reproduce; if you have steps to reproduce, please open a ticket with details instead.

cat /etc/docker/daemon.json
cat: /etc/docker/daemon.json: No such file or directory

docker info --format '{{json .RegistryConfig}}' | jq .
{
  "AllowNondistributableArtifactsCIDRs": null,
  "AllowNondistributableArtifactsHostnames": null,
  "InsecureRegistryCIDRs": [
    "127.0.0.0/8"
  ],
  "IndexConfigs": {
    "docker.io": {
      "Name": "docker.io",
      "Mirrors": [],
      "Secure": true,
      "Official": true
    }
  },
  "Mirrors": null
}

With a daemon.json and insecure registries;

mkdir -p /etc/docker
echo '{"insecure-registries":["123.456.789.1:5000", "123.123.123.0/24", "foo.example.com:123"]}' > /etc/docker/daemon.json

systemctl reload docker
docker info --format '{{json .RegistryConfig}}' | jq .
{
  "AllowNondistributableArtifactsCIDRs": null,
  "AllowNondistributableArtifactsHostnames": null,
  "InsecureRegistryCIDRs": [
    "123.123.123.0/24",
    "127.0.0.0/8"
  ],
  "IndexConfigs": {
    "123.456.789.1:5000": {
      "Name": "123.456.789.1:5000",
      "Mirrors": [],
      "Secure": false,
      "Official": false
    },
    "docker.io": {
      "Name": "docker.io",
      "Mirrors": [],
      "Secure": true,
      "Official": true
    },
    "foo.example.com:123": {
      "Name": "foo.example.com:123",
      "Mirrors": [],
      "Secure": false,
      "Official": false
    }
  },
  "Mirrors": null
}

@pytimer
Copy link

pytimer commented Aug 16, 2024

insecure-registries is also not working for me. Docker version 24.0.5 OS: Ubuntu 22.04.3 LTS Kernel: 5.15.0-82-generic

/etc/docker/daemon.json { "insecure-registries": ["my_ip_address:port_number"] }

after restarting the service "sudo systemctl restart docker", the insecure registry is not showing on "docker info"

+1, the same os and docker version. Reinstall still has this issue.

@thaJeztah
Copy link
Member Author

@pytimer Note that the 24.0 release is no longer maintained (see BRANCHES-AND-TAGS.md). So far (see above) we have not been able to reproduce the issue.

If you have a system to test on, are able to provide exact reproduction steps on a current version, feel free to open a ticket with details (as requested in the issue template when you open a ticket).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants