fix: read the container IP from NetworkSettings.Networks

[tas50]

The bug

container_ip_address asked docker inspect for the top-level field:

cmd = "inspect --format '{{ .NetworkSettings.IPAddress }}'"

Docker 29 removed that field. On 29.7.2, NetworkSettings carries only:

Networks, Ports, SandboxID, SandboxKey

Asking for a field that is gone does not quietly return empty — Go's template engine fails the entire inspect:

template parsing error: template: :1:19: executing "" at
<.NetworkSettings.IPAddress>: map has no entry for key "IPAddress"

What it breaks

container_ip_address is reached whenever use_internal_docker_network is set — the documented way to run this driver from inside another container. That option is therefore broken outright on Docker 29. Reproduced with a real kitchen create:

driver:
  name: docker
  use_internal_docker_network: true

D  docker_command: docker inspect --format '{{ .NetworkSettings.IPAddress }}' 7cf7e9ef2988...
   template parsing error: ... map has no entry for key "IPAddress"
D  Message: Error getting internal IP of Docker container
>>>>>> Message: 1 actions failed.

It also fixes a case that was broken before the removal: a container on a user-defined network never had a top-level IPAddress — only a per-network one — so run_options: --network=… plus use_internal_docker_network failed on older daemons too.

The fix

Read NetworkSettings.Networks, which has been present since Docker 1.9 and so works on old and new daemons alike:

cmd = "inspect --format '{{range .NetworkSettings.Networks}}{{.IPAddress}} {{end}}'"

The address is picked by parsing each token with IPAddr rather than taking the first word, so a warning on stderr is not returned as an address — a mistake this codebase has made before. Output carrying no address now raises, instead of yielding "" to be recorded as the instance hostname and failing far from the cause.

A container on several networks has an address on each; the first is used, which is the only one in the single-network case this option exists for.

Verified against Docker 29.7.2

                       driver          docker
default bridge         172.17.0.7      172.17.0.7      MATCH
user-defined network   172.19.0.2      172.19.0.2      MATCH
missing container   -> Kitchen::ActionFailed

And the kitchen create that failed above:

Finished creating <default-ubuntu-2404> (0m1.14s).
hostname recorded: "172.17.0.7"   port: 22
docker says its IP is: 172.17.0.7

Specs

New cases in spec/container_helper_spec.rb: the address is returned, Networks is asked for and IPAddress is not, the first of several networks wins, IPv6 works, a stderr warning is ignored, no address raises, and a failed inspect raises.

$ bundle exec rake
43 files inspected, no offenses detected
280 examples, 0 failures

$ bundle exec rake doc
clean, 100.00% documented

🤖 Generated with Claude Code

[tas50]

Rebased onto main (now at 3.3.3, with #476, #477, #480 and #481 merged). One commit, no conflicts remaining.

The spec file conflicted because #476's #container_exists? and #container_running? group and this PR's #container_ip_address group were both inserted at the same anchor. They are complementary, so both are kept — resolved by taking main's file and re-inserting this group, rather than splicing the markers by hand. lib/kitchen/docker/helpers/container_helper.rb auto-merged, and git diff main -- lib/ is exactly the intended change and nothing else.

Re-verified after the rebase, against Docker 29.7.2:

                       driver          docker
default bridge         172.17.0.7      172.17.0.7      MATCH
user-defined network   172.18.0.2      172.18.0.2      MATCH
missing container   -> Kitchen::ActionFailed

And end to end, with the merged #476/#477 destroy changes now underneath it:

Finished creating <default-ubuntu-2404> (0m3.29s).
hostname="172.17.0.7" port=22
docker says: 172.17.0.7
kitchen destroy -> Test Kitchen is finished. (0m0.76s)

$ bundle exec rake
43 files inspected, no offenses detected
313 examples, 0 failures

$ bundle exec rake doc
clean, 100.00% documented