Description
When using VSCode DevContainers with finch to re-open a "workspace within a container" (after successfully opening "workspace within a container" once and exiting), the "DevContainers Log" reports the following error: TypeError: Cannot read properties of null (reading 'Ports').
After some investigation, we observed two scenarios with finch using nerdctl:
- When a container is launched without a published port, the response of
nerdctl inspect --mode=dockercompat omits the Ports key-value pair from the NetworkSettings.
- When
nerdctl inspect --mode=dockercompat inspects an "Exited" container, the NetworkSettings key contains a null value.
Compared to the Docker scenarios:
- When a container is launched without a published port, the response of
docker inspect, the Ports key-value pair is present within NetworkSettings entity, but the value is an empty structure.
- When
docker inspect inspects an "Exited" container, the NetworkSettings key contains a complete structure of expected keys, all with "zero-value" values.
This bug affects integration of VSCode DevContainers with finch because DevContainers expects the complete NetworkSettings structure with all "zero-value" members for both of the scenarios.
Steps to reproduce the issue
Scenario 1: Container without published ports returns NetworkSettings without Ports entity
- Using finch, launch a container with specified ports
a. finch run -p 8080:80 -d alpine:latest sleep infinity, which invokes nerdctl run -p 8080:80 -d alpine:latest sleep infinity
- Inspect the container to verify response payload
a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
- Confirm the presence of
Ports entity within NetworkSettings struct
"NetworkSettings": {
"Ports": {
"80/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "8080"
}
]
},
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "10.4.0.9",
"IPPrefixLen": 24,
"MacAddress": "xx:xx:xx:xx:xx:xx",
"Networks": {
"unknown-eth0": {
"IPAddress": "10.4.0.9",
"IPPrefixLen": 24,
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "xx:xx:xx:xx:xx:xx"
}
}
}
- Create another container without a published port
a. finch run -d alpine:latest sleep infinity, which invokes nerdctl run -d alpine:latest sleep infinity
- Inspect the new container to verify response payload
a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
- Confirm the lack of presence of
Ports entity within NetworkSettings struct
"NetworkSettings": {
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "10.4.0.10",
"IPPrefixLen": 24,
"MacAddress": "xx:xx:xx:xx:xx:xx",
"Networks": {
"unknown-eth0": {
"IPAddress": "10.4.0.10",
"IPPrefixLen": 24,
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "xx:xx:xx:xx:xx:xx"
}
}
}
Inspecting an Exited Container
- Using finch, launch a container with specified ports
a. finch run -p 8070:70 -d alpine:latest sleep infinity, which invokes nerdctl run -p 8070:70 -d alpine:latest sleep infinity
- Inspect the container to verify response payload
a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
- Confirm the presence of
Ports entity within NetworkSettings struct
- Stop the container
a. finch container stop <container_id>, which invokes nerdctl container stop <container_id>
- Inspect the container to verify response payload
a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
- Confirm the
null value of NetworkSettings struct
Describe the results you received and expected
For the "container with published port", the NetworkSettings includes the expected Ports struct and all appropriate information. This is already successful and should be maintained during any changes.
The expected results should be as follows for the two scenarios:
- When a container is launched without a published port, the response of
nerdctl inspect --mode=dockercompat should include the Ports key-value pair within the NetworkSettings with a value of { }.
- When
nerdctl inspect --mode=dockercompat inspects an "Exited" container, the NetworkSettings key should map to a struct containing all keys mapping to "zero-value" values.
What version of nerdctl are you using?
Observed behavior with both:
- Local build from branch release/1.7
- Local build from branch main
Are you using a variant of nerdctl? (e.g., Rancher Desktop)
None
Host information
No response
Description
When using VSCode DevContainers with
finchto re-open a "workspace within a container" (after successfully opening "workspace within a container" once and exiting), the "DevContainers Log" reports the following error:TypeError: Cannot read properties of null (reading 'Ports').After some investigation, we observed two scenarios with
finchusingnerdctl:nerdctl inspect --mode=dockercompatomits thePortskey-value pair from theNetworkSettings.nerdctl inspect --mode=dockercompatinspects an "Exited" container, theNetworkSettingskey contains anullvalue.Compared to the Docker scenarios:
docker inspect, thePortskey-value pair is present withinNetworkSettingsentity, but the value is an empty structure.docker inspectinspects an "Exited" container, theNetworkSettingskey contains a complete structure of expected keys, all with "zero-value" values.This bug affects integration of VSCode DevContainers with
finchbecause DevContainers expects the completeNetworkSettingsstructure with all "zero-value" members for both of the scenarios.Steps to reproduce the issue
Scenario 1: Container without published ports returns NetworkSettings without Ports entity
a.
finch run -p 8080:80 -d alpine:latest sleep infinity, which invokesnerdctl run -p 8080:80 -d alpine:latest sleep infinitya.
finch inspect --mode=dockercompat <container_id>, which invokesnerdctl inspect --mode=dockercompat <container_id>Portsentity withinNetworkSettingsstructa.
finch run -d alpine:latest sleep infinity, which invokesnerdctl run -d alpine:latest sleep infinitya.
finch inspect --mode=dockercompat <container_id>, which invokesnerdctl inspect --mode=dockercompat <container_id>Portsentity withinNetworkSettingsstructInspecting an Exited Container
a.
finch run -p 8070:70 -d alpine:latest sleep infinity, which invokesnerdctl run -p 8070:70 -d alpine:latest sleep infinitya.
finch inspect --mode=dockercompat <container_id>, which invokesnerdctl inspect --mode=dockercompat <container_id>Portsentity withinNetworkSettingsstructa.
finch container stop <container_id>, which invokesnerdctl container stop <container_id>a.
finch inspect --mode=dockercompat <container_id>, which invokesnerdctl inspect --mode=dockercompat <container_id>nullvalue ofNetworkSettingsstructDescribe the results you received and expected
For the "container with published port", the
NetworkSettingsincludes the expectedPortsstruct and all appropriate information. This is already successful and should be maintained during any changes.The expected results should be as follows for the two scenarios:
nerdctl inspect --mode=dockercompatshould include thePortskey-value pair within theNetworkSettingswith a value of{ }.nerdctl inspect --mode=dockercompatinspects an "Exited" container, theNetworkSettingskey should map to a struct containing all keys mapping to "zero-value" values.What version of nerdctl are you using?
Observed behavior with both:
- Local build from branch
release/1.7- Local build from branch
mainAre you using a variant of nerdctl? (e.g., Rancher Desktop)
None
Host information
No response