-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Workaround for Docker images not identifying the true base image #17
Labels
Milestone
Comments
nishakm
added
arch
Architecture changes are needed
show-stopper
We really really need a solution!
labels
Mar 7, 2018
#41 might be a good solution. The flow might go something like this:
There is still a distinction between baseOS package managers and application level package managers. Some name changes in the architecture is needed here for clarity. |
nishakm
pushed a commit
that referenced
this issue
May 24, 2018
In order to use the layer-by-layer inspection, the control flow for the reporting needs to change from inspecting the base image first and then inspecting the full image to just building the image and then inspecting it layer by layer. This is a lot of architecture work referenced in #17 but for now, use the old method of using Docker containers. Added chroot=False flags for get_pkg_attr_list function call Signed-off-by: Nisha K <nishak@vmware.com>
nishakm
pushed a commit
that referenced
this issue
Jul 14, 2018
Changes to work with bare filesystem layers Tern will now use overlayfs to apply diff filesystem layers one by one and run commands against them in a chroot environment. This allows us to isolate the context in with the diff filesystems are created and hence have more accuracy on what packages are installed in which layers. This also allows us to inspect the true base filesystem of the image that was built using a Dockerfile and if not, then try to inspect just the base image that would be pulled from Dockerhub or another container registry. This will also help us provide a raw container image to inspect instead of just the Dockerfile. Note that the tern executable will work as expected at this merge but may not work elsewhere along the development branch. Resolves #5 #17 #51 #60 #61 #63 Signed-off-by: Nisha K <nishak@vmware.com>
Resolved in #67 |
rnjudge
pushed a commit
to rnjudge/tern
that referenced
this issue
Jun 5, 2020
In order to use the layer-by-layer inspection, the control flow for the reporting needs to change from inspecting the base image first and then inspecting the full image to just building the image and then inspecting it layer by layer. This is a lot of architecture work referenced in tern-tools#17 but for now, use the old method of using Docker containers. Added chroot=False flags for get_pkg_attr_list function call Signed-off-by: Nisha K <nishak@vmware.com>
rnjudge
pushed a commit
to rnjudge/tern
that referenced
this issue
Jun 5, 2020
Changes to work with bare filesystem layers Tern will now use overlayfs to apply diff filesystem layers one by one and run commands against them in a chroot environment. This allows us to isolate the context in with the diff filesystems are created and hence have more accuracy on what packages are installed in which layers. This also allows us to inspect the true base filesystem of the image that was built using a Dockerfile and if not, then try to inspect just the base image that would be pulled from Dockerhub or another container registry. This will also help us provide a raw container image to inspect instead of just the Dockerfile. Note that the tern executable will work as expected at this merge but may not work elsewhere along the development branch. Resolves #5 tern-tools#17 tern-tools#51 tern-tools#60 tern-tools#61 tern-tools#63 Signed-off-by: Nisha K <nishak@vmware.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
When using FROM in a Dockerfile, the image that gets pulled from the Docker registry does not identify the images that they may have been based off. The only indication that this actually happens is from the 'history' in the json config file of the Docker container. There is, however, no indentifier for each of the layers in this base image other than the layer sha.
Currently the implementation uses a direct lookup in base.yml. Perhaps we can do something like this:
The text was updated successfully, but these errors were encountered: