We are using docker-squash to squash images and we are facing 2 problems:
When trying to load the image using docker load -i squashed.tar, it returns the following:
Loaded image ID: sha256:e2be970be8222d5ab47d5c3633d437f86a5481d33df81dae00eb9ae0eeaeec00
However, upon firing docker images command, the image file doesn't show up!
We tried loading the docker file on other system and it says:
open /apps/docker/tmp/docker-import-734929610/0e0c7d7d5f7843e27756caa197f1ff2de3f7afb0890271b4a1fd95dd4c7bcaaa/layer.tar: no such file or directory
Can squashed images not be run on other system or are we missing something?
Please help!
Related
I have a Docker image in .tar format. When I load it using sudo docker load < image.tar, it works fine.
I used tar -xf image.tar to un-archive the file. I then un-archived each layer file so I could edit some scripts and update some libraries manually. Once I was done with this, I used tar -cf on each layer and then the entire image.
When I load the modified image the same way I loaded the original, it does not work. I get this error:
open /var/lib/docker/tmp/docker-import-742628246/image-edited/json: no such file or directory
What could I have done wrong to cause this error and how can I properly load the modified .tar file into Docker?
P.S.: The problem appeared on Docker 20.10.12, running on Kali Linux 2021.4 inside VMWare Workstation Player.
I am modifying some image tarball and trying to load it back to docker daemon, and saw the same error. I tried this: sha256sum the layer.tar in each layer, and search the config json file(the other json file at the same level as manifest.json, with a long sha value as filename) for the original hash, replace with the new sha256 value, then this error disappears.
But then again, another error like /var/lib/docker/tmp-xxxx/xxxxx cannot open file appears, then I think nothing should/can be modified in the layer tar, as we cannot bypass docker checking the integrity of image in any easy way.
I am planning to adding another layer to the image using Google jib tool, where I copy some script to the container which does the modification I want, so that original layers keep intact.
I have a Cassandra.tar.gz file which I want to convert into an image. I created a DockerFile (CassandarImageDockerFile.txt) with the following contents
FROM scratch
add apache-cassandra-3.11.6-bin.tar /
Then I ran the following command but noticed that that image size was running into GB while the .tar is only 140MB. I Ctrl+c to stopped the command
C:\Users\manuc\Documents\manu>docker build -f CassandraImageDockerFile.txt .
Sending build context to Docker daemon 4.34GB
What happened under the hood? Why did the image size go in GB? What is the right way to build the image?
The last arg to the build command is the build context. All files that you add or copy to the image must be within that context. It gets sent to the docker engine and the build runs within a sandbox (temp folder and containers) using that context. In this case, the context path is . aka the current directory. So look in that folder and all child directories for files that will total many GB. You can exclude files from being sent in the context to the engine using the .dockerignore file, with a nearly identical syntax to the .gitignore file.
Following things to check here.
Size of base image,.i.e., scratch.
Size of build context - Check the directory from where you are building the image.
For example, docker image build -t xyz:1 .
Here, the build context is the content of the current folder.
So, while building the image, docker sends the build context to the daemon and which gets copied over to the image, which might be the reason of huge size.
So, check the content of the directory and see if you are adding any unnecessary files to your image.
I think the image you are starting from already is some Gb of size. Can you please check? See that scratch image on the FROM on the DockerFile
I was reading few articles on how to get code inside docker container.
I found "In short, for production use ADD/COPY method, for the development use docker volume feature"
What i understand form the above
1) We will build an image with the code inside it for production. i.e in the production server i have to pull the image and run it. No need to worry about the code files because everything is packed in the image.
2) While developing use volumes to share the folder.
My question is: wheneve i do a change, i will build an image on development server and pull and run that image in the production server.
Assuming my image Dockerfile is as below:
FROM some-os -- 375Mb
COPY codefolder /root/ --25MB
When i put updated codefolder the image is different from previous.
Most of the times in some-os there are no changes. So codefolder only changes
So everytime (after the first time) i pull the modified image how much MB Is downloaded 400MB or 25 MB
Only the new layer is downloaded after the first time: 25M.
I'm using docker CE 17.06.1 to build a docker image. Everything works so far, except that a directory I created during the RUN command using mkdir, won't appear when I take a look at the final image. I also performed a ls after creation, to make sure it's really at the expected place. That directory isn't a mount directory or similar - just a simple directory. Is this expected behavior?
When I download a Docker image, it downloads dependencies, but only displays their hashes. Why does it not display what it is downloading?
For example:
➜ ~ docker run ubuntu:16.04
Unable to find image 'ubuntu:16.04' locally
16.04: Pulling from library/ubuntu
b3e1c725a85f: Downloading 40.63 MB/50.22 MB
4daad8bdde31: Download complete
63fe8c0068a8: Download complete
4a70713c436f: Download complete
bd842a2105a8: Download complete
What's the point in only telling me that it's downloading b3e1c725a85f, etc.?
An image is created on layers of filesystems represented by hashes. After it's creation, the base image tag may point to a completely different set of hashes without affecting any images built off of it. And these layers are based on things like run commands, the tag to call it something like ubuntu:16.04 is only added after the image is made.
So the best that could be done is to say 4a70713c436f is based on adding some directory based on a hash of an input folder itself, or a multi-line run command, neither of which makes for a decent UI. The result may have no tagged name, or it could have multiple tagged names. So the simplest solution is to output what's universal and unchanging for all scenarios, an unchanging hash.
To rephrase that pictorially:
b3e1c725a85f: could be ubuntu:16.04, ubuntu:16, ubuntu:latest, some.other.registry:5000/ubuntu-mirror:16.04
4daad8bdde31: could be completely untagged, just a run command
63fe8c0068a8: could be completely untagged, just a copy file
4a70713c436f: could point to a tagged base image where that tag has since changed
bd842a2105a8: could be created with a docker commit command (eek)