As title says I was renaming one of my docker images I built using Dockerfile and docker-compose.yml using the command docker tag old-image-name new-image-name, after that I used docker images to check on my current images and I had BOTH the old and the new one.
I removed the old one using docker image rm IMAGE_ID and since then I've been getting the following error failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount511639725/Dockerfile: no such file or directory when I try to start the container.
I've tried everything, other containers start without problem and I've successfully ran this container in the past. This are the only changes I've made, nothing changed on my Dockerfile or docker-compose.yml.
I've tried removing the images related to this stack to build again many times. also tried rebuilding the image with Dockerfile alone (not trough docker-compose.yml).
This error usually means it cannot find your docker file. It usually happens when its named incorrectly, make sure your docker file is named exactly as "Dockerfile"
I solved the problem, and it pains me that was very dumb on my side.
When I had the container running I was adding some network changes on my docker-compose.yml to use NGINX with the django project.
When I did those changes I changed build: . to build: ~/path/to/folder, I thought it would be able to recognize that path but apparently it has to be absolute or use the .
Solution: reverting to build: . or build: /home/your_user/path/to/folder asuming your folder is in /home/your_user/*, avoid using ~
Thanks for the replies everyone
Related
I have built a project with a webhost (httpd:2.4)
(Dockerfile Content:
FROM httpd:2.4
COPY . /usr/local/apache2/htdocs )
It's hosting a static website... and I'd like to be able to change that / publish future changes but that doesn't work in the way I was expecting it to...
I'm using
git clone [repository]
cd [repository]
docker-compose -f docker-compose/docker-compose.yml up -d
to run the project, which works perfectly fine
The problem is that I should be able to make changes to the website.
I supposed it would just work like that:
docker-compose -f docker-compose/docker-compose.yml down
changing the index.html (save)
docker-compose -f docker-compose/docker-compose.yml up -d
But even though (for the test) I deleted every single character in my index.html, it still shows up exactly the same as before
What am I missing? What commands would I have to run for the changes to get applied?
If you have a dockerfile, the file containing the below,
FROM httpd:2.4
COPY . /usr/local/apache2/htdocs
It means you are building a custom docker image for your need. And you are also using the COPY command to copy the project to your docker image which is done when building the custom docker image. This is a good solution to copy the code in the docker image for distribution purposes however might not be the best for development purposes.
If changes are made to the project, this is not reflected in the custom docker image until that docker image is rebuilt. After rebuilding the image, the current files of the project are copied to the docker image. Then after restarting the docker compose and by also using the latest image built, the changes will be visible.
If you do not want to build a docker image each time a change is made, it might be best to create a docker-compose file which will map your project directly to /usr/local/apache2/htdocs. This way when the changes made to the project will be reflected instantly without any build process.
Sample docker compose file with the project mapping to /usr/local/apache2/htdocs, this docker compose file needs to be located in the directory where the index.html lives.
version: '3.9'
services:
apache:
image: httpd:latest
container_name: webserver
ports:
- '8080:80'
volumes:
# mapping your root project's directory to htdocs
- ${PWD}:/usr/local/apache2/htdocs
This problem may arise if you have referenced a docker image inside your docker-compose.yml file instead of building the image there. When you reference an image, docker-compose up will create the corresponding containers with the exact same image.
You need to:
Build the image again AFTER you have made changes to your html file and BEFORE running docker-compose.
OR
Build the image inside docker-compose.yml like this
I am pretty new to Docker and am trying to build a Docker image with plain HTML, but I have this error message, saying
failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount602954594/Dockerfile: no such file or directory
My folder directory is like this:
C:\Users\hailey\Desktop\GitTest
|- Dockerfile.txt
|- README.md
|- testHelloWorld.html
Inside of the Dockerfile, I have
FROM ubuntu
WORKDIR C/Users/hailey/Desktop/GitTest
COPY testHelloWorld.html .
EXPOSE 8080
CMD ["html","testHelloWorld.html"]
I did my command docker build . inside of the directory C:\Users\hailey\Desktop\GitTest and then got:
[+] Building 0.1s (2/2) FINISHED
=> [internal] load build definition from Dockerfile
=> => transferring dockerfile: 2B
=> [internal] load .dockerignore
=> => transferring context: 2B
failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount602954594/Dockerfile: no such file or directory
What did I do wrong?
The name of Docker files doesn't have any extension. It's just Dockerfile with capital D and lowercase f.
You can also specify the Dockerfile name, such as docker build . -f Dockerfile.txt if you'd like to name it something else.
One can provide the filename of the Docker file using -f.
For instance, if your Docker file is called Dockerfile.base, call the build command as follows:
docker build . -f Dockerfile.base -t helloworld
Then, you can start the build image using the following command:
docker run --rm -it helloworld
I would like to sum up the information from different answers in one answer, and also add my own experience that brought me to this question:
Ensure that you're in the same directory that contains your dockerfile as where you're running your command from (running ls or dir depending on if you're using Linux or Windows/cmd shell respectively to determine if the file you'll use to build your docker container exists there)
Docker will accept at least two (maybe only two?) default names for dockerfiles: dockerfile and Dockerfile. If you have other capitals in the filename it will most likely fail. Also note that the default filenames have no file extension (so if you're to create the file in Notepad for instance, it may be a .txt or another extension by default). There is another answer here that shows how to save it without a filename from notepad, but you can also use the following commands in Linux and Windows command prompt, respectively:
mv dockerfile.txt dockerfile
ren dockerfile.txt dockerfile
If you need to use a different name instead of the default dockerfile/Dockerfile, then you can use the option -f (link to docs), which states:
-f, --file string Name of the Dockerfile (Default is 'PATH/Dockerfile')
Taken from another answer, here's an example of how you can use that command:
docker build . -f Dockerfile.base -t helloworld
And just to bring it all together, you don't need to use the filename again once the container is built, so you can just run it with:
docker run --rm -it helloworld
If you don't really need to use buildkit:
Try to set those .envs before executing your build/Docker composer:
export DOCKER_BUILDKIT=0
export COMPOSE_DOCKER_CLI_BUILD=0
The issue in my case was, the file name was correct, but the extension was txt.
I opened Notepad++ and pasted the FROM mcr.microsoft.com/dotnet/aspnet:3.1 line and after that saved that file from Notepad++ like below.
Once the file is saved, it will look like below:
For those who use docker-compose build also make sure you have properly set build path in docker-compose.yml:
version: '3.8'
services:
web:
build: ./services/web/ --> this folder should contain your Dockerfile, otherwise you will have the above error
I just had this same issue, and it turned out I had to place the Docker file in the right folder—the root project folder.
Sorry for hearing that you've an issue. Are you sure about naming your file -> "Dockerfile" ? it shouldn't be "dockerfile" nor "DockerFile"
Rename your Dockerfile.txt to just as this Dockerfile. Because the dockerfile has no extensions.
For me, I just go the root path of project where the Docker file exists.
I solved the problem by giving it the full file extension to my Dockerfile
docker build -t testapi . -f [YOUR_FILE_EXTENSION]/Dockerfile
when you give your file extension don't give the relative one give the whole extension such as D:/projects/asp6.0/publish/Dockerfile
I got the same error: It could be anything. Mine wasn't anything specific... I had incorrectly named and referenced one of the files in the configurations, so when trying to run build it could not find that file.
It had nothing to do with frontend dockerfile.v0 (totally different file). Check all your file are named and referenced correctly.
Apart from correcting the Dockerfile name, that error can also happen if you add an extra dot at the end
I had the same issue running "docker build -t getting-started ." from the Visual Studio Code terminal.
But when I've executed the same command in CMD (Windows 10) it worked with no problems.
Check the name of Dockerfile. It should be "Dockerfile".
As mentioned before... the issue for me was the Dockerfile name. I had "DockerFile" by accident.
Changing the name to Dockerfile with the lowercase f and rerunning the build command fixed the issue for me.
Just be in the same folder where your Dockerfile is located at and run the build command that is how I solved the issue.
Make sure you are in the correct directory first, and docker desktop is running.
Make sure you see the list using "ls" or "dir" command.
In my case I create Dockerfile using Mac's Textedit and it had a hidden .rtf extension.
After removing the extension it worked.
Another issue I had with this error was around the location in which I was executing the command.
It might be useful for some to run the command from the correct directory (where the Dockerfile resides) and include the appropriate naming convention when creating the docker file. Dockerfile.
I ran into a similar issue while building a Visual Studio 2019 generated Docker file:
failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount037306220/dockerfile: no such file or directory
Essentially, the Docker file is being referred from within the Windows Subsystem for Linux (WSL). The tool mounted my local file system and was accessing the Docker file in the context of WSL.
As file names are case sensitive on Linux, the Docker command faithfully reported the error:
>> dockerfile: no such file or directory
Renaming the Dockerfile to "dockerfile" resolved the issue.
I had the same issue working with a React app. I had to move the Dockerfile from src to the project root folder and restarted Docker desktop—it worked.
For me it was wrong directory specification of Dockerfile location. I initially specified parent directory (instead of the subdirectory where actually the Dockerfile was residing) in docker-compose.yml file.
1: Make sure docker file is named Dockerfile without extension.
2: Make sure your at running the command from the location where your Dockerfile is kept.
I had a similar issue, the error was "no space left on device".
I executed the command: docker system prune and it fixed the problem for me.
I met this problem , due to the network problem.
just use an Hongkong server instead, everything goes well~
I've been running a dev-setup for a while without issue. I'm using Docker for Windows with Windows Subsystem for Linux 2. It's been working very well. Today when trying to spin up docker-compose, it failed with the following error:
frederik#desktop:~/projects/caselab$ docker-compose -f docker-test.yml up
Recreating f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_caselab_db_1 ...
Recreating f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_caselab_db_1 ... error
ERROR: for f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_f26a365c8a83_caselab_db_1 Cannot create container for service db: mkdir 07ff2055c618dedc240ca3275de3f8c41d091136dc659cf463ee9fc62eed1853: permission denied
ERROR: for db Cannot create container for service db: mkdir 07ff2055c618dedc240ca3275de3f8c41d091136dc659cf463ee9fc62eed1853: permission denied
ERROR: Encountered errors while bringing up the project.
frederik#desktop:~/projects/caselab$
I shaved the contents of docker-test.yml down to simply:
version: '3'
services:
db:
image: postgres
logging:
driver: none
I tried running docker run postgres which worked without issue. I then tried copying all the contents of my folder to another folder. Now, running docker-compose -f docker-test.yml works without issues.
I think it's somehow related to permissions, though I can see no difference in permissions between the original folder and the new one.
As I do most of my editing in Visual Studio Code, running in Windows I'm thinking it may be related to the Windows / Linux boundary, though I'm not completely sure how. And - again - this setup has been running for months without issue so I'm at a loss for what I could have changed.
Any ideas?
I managed to solve it.
I noticed that running docker-compose up prepended a hash to the image name every single time the command was run. This resulted in a comically long image name.
Running docker-compose images showed this image being present.
Simply running docker-compose rm removed the image, which allowed the right image to be created and run.
I have filed this as a bug in docker-compose.
I am bringing up my project dependencies using docker-compose. So far this used to work
docker-compose up -d --no-recreate;
However today I tried running the project again after couple of weeks and I was greeted with error message
Creating my-postgres ... error
ERROR: for my-postgres Cannot create container for service postgres: b'Conflict. The container name "/my-postgres" is already in use by container "dbd06bb1d99eda6f075ea688df16e8b355e559e1759f084dee8f3cddfc535b0b". You have to remove (or rename) that container to be able to reuse that name.'
ERROR: for postgres Cannot create container for service postgres: b'Conflict. The container name "/my-postgres" is already in use by container "dbd06bb1d99eda6f075ea688df16e8b355e559e1759f084dee8f3cddfc535b0b". You have to remove (or rename) that container to be able to reuse that name.'
ERROR: Encountered errors while bringing up the project.
My docker-compose.yml file is
postgres:
container_name: my-postgres
image: postgres:latest
ports:
- "15432:5432"
Docker version is
Docker version 19.03.1, build 74b1e89
Docker compose version is
docker-compose version 1.24.1, build 4667896b
Intended behavior of this call is to:
make the container if it does not exist
start the container if it exists
just chill and do nothing if the container is already started
Docker Compose normally assigns a container name based on its current project name and the name of the services: block. Specifying container_name: explicitly overrides this; but, it means you can’t launch multiple copies of the same Compose file with different project names (from different directories) because the container name you’ve explicitly chosen won’t be used.
You almost never care what the container name is explicitly. It only really matters if you’re trying to use plain docker commands to manipulate Compose-managed containers; it has no impact on inter-service communication. Just delete the container_name: line.
(For similar reasons you can almost always delete hostname: and links: sections if you have them with no practical impact on your overall system.)
In my case I moved the project in an other directory.
When I tryed to run docker-compose up it failed because of some conflicts.
With command docker system prune I resolved them.
It's caused by being in a different directory than when you last ran docker-compose up. One option is to change back to the original directory. Or if you've configured it as a systemd service you can use systemctl.
Well...the error message seems pretty straightforward to me...
The container name "/my-postgres" is already in use by container
If you just want to restart where you left, you should use docker-compose start.
Otherwise, just clean up your workspace before running it :
docker-compose down
docker-compose up -d
Remove --no-recreate flag from your docker-compose command. And execute the command again.
$docker-compose up -d
--no-recreate is using for preventing accedental updates.
If there are existing containers for a service, and the service’s configuration or image was changed after the container’s creation, docker-compose up picks up the changes by stopping and recreating the containers. To prevent Compose from picking up changes, use the --no-recreate flag.
official docker docs.Link
I had similar issue
dcdown --remove-orphans
That worked for me.
I have a docker-compose-staging.yml file which I am using to define a PHP application. I have defined a data volume container (app) in which my application code lives, and is shared with other containers using volumes_from.
docker-compose-staging.yml:
version: '2'
services:
nginx:
build:
context: ./
dockerfile: docker/staging/nginx/Dockerfile
ports:
- 80:80
links:
- php
volumes_from:
- app
php:
build:
context: ./
dockerfile: docker/staging/php/Dockerfile
expose:
- 9000
volumes_from:
- app
app:
build:
context: ./
dockerfile: docker/staging/app/Dockerfile
volumes:
- /var/www/html
entrypoint: /bin/bash
This particular docker-compose-staging.yml is used to deploy the application to a cloud provider (DigitalOcean), and the Dockerfile for the app container has COPY commands which copy over folders from the local directory to the volume defined in the config.
docker/staging/app/Dockerfile:
FROM php:7.1-fpm
COPY ./public /var/www/html/public
COPY ./code /var/www/html/code
This works when I first build and deploy the application. The code in my public and code directories are present and correct on the remote server. I deploy using the following command:
docker-compose -f docker-compose-staging.yml up -d
However, next I try adding a file to my local public directory, then run the following command to rebuild the updated code:
docker-compose -f docker-compose-staging.yml build app
The output from this rebuild suggests that the COPY commands were successful:
Building app
Step 1 : FROM php:7.1-fpm
---> 6ed35665f88f
Step 2 : COPY ./public /var/www/html/public
---> 4df40d48e6a5
Removing intermediate container 7c0fbbb7f8b6
Step 3 : COPY ./code /var/www/html/code
---> 643d8745a479
Removing intermediate container cfb4f1a4f208
Successfully built 643d8745a479
I then deploy using:
docker-compose -f docker-compose-staging.yml up -d
With the following output:
Recreating docker_app_1
Recreating docker_php_1
Recreating docker_nginx_1
However when I log into the remote containers, the file changes are not present.
I'm relatively new to Docker so I'm not sure if I've misunderstood any part of this process! Any guidance would be appreciated.
This is because of cache.
Run,
docker-compose build --no-cache
This will rebuild images without using any cache.
And then,
docker-compose -f docker-compose-staging.yml up -d
I was struggling with the fact that migrations were not detected nor done. Found this thread and noticed that the root cause was, indeed, files not being updated in the container. The force-recreate solution suggested above solved the problem for me, but I find it cumbersome to have to try to remember when to do it and when not. E.g. Vue related files seem to work just fine but Django related files don't.
So I figured why not try adjusting the Docker file to clean up the previous files before the copy:
RUN rm -rf path/to/your/app
COPY . path/to/your/app
Worked like a charm. Now it's part of the build and all you need is run the docker-compose up -d --build again. Files are up to date and you can run make migrations and migrate against your containers.
I had similar issue if not same while working on dotnet core application.
What I was trying to do was rebuild my application and get it update my docker image so that I can see my changes reflected in the containerized copy.
So I got going by removing the underlying image generated by docker-compose up using the command to get my changes reflected:
docker rmi *[imageId]*
I believe there should be support for this in docker-compose but this was enough for my need at the moment.
Just leaving this here for when I come back to this page in two weeks.
You may not want to use docker system prune -f in this block.
docker-compose down --rmi all -v \
&& docker-compose build --no-cache \
&& docker-compose -f docker-compose-staging.yml up -d --force-recreate
I had the same issue because of shared volumes. For me the solution was to remove shared container using this command:
docker volume rm [VOLUME_ID]
Volume id or name you can find in "Mount" section using this command:
docker inspect [CONTAINER_ID]
None of the above solutions worked for me, but what did finally work was the following steps:
Copy/Move file outside of docker app folder
Delete File you want to update
Rebuild the docker img without updated file
Move copied file back into docker app folder
Rebuild again the docker image
Now the image will contain the updates to the file.
I'm relatively new to Docker myself and found this thread after experiencing a similar issue with an updated YAML file not seeming to be copied into a rebuilt container, despite having turned off caching.
My build process differs slightly as I use Docker Hub's GitHub integration for automating image builds when new commits to the master branch are made. The build happens on Docker's servers rather than the locally built and pushed container image workflow.
What ended up working for me was to do a docker-compose pull to bring down into my local environment the most up-to-date versions of the containers defined in my .env file. Not sure if the pull command defers from the up command with a --force-recreate flag set, but I figured I'd share anyway in case it might help someone.
I'd also note that this process allowed me to turn auto-caching back on because the edited file was actually being detected by the Docker build process. I just wasn't seeing it because I was still running docker-compose up on outdated image versions locally.
I am not sure it is caching, because (a) it is usually noted in the build output, whether cache was used or not and (b) 'build' should sense the changed content in your directory and nullify the cache.
I would try to bring up the container on the same machine used to build it to see if that is updated or not. if it is, the changed image is not propagated. I do not see any version used in your files (build -t XXXX:0.1 or build -t XXXX:latest) so it might be that your staging machine uses a stale image. Or, are you pushing the new image so the staging server will pull it from somewhere?
You are trying to update an existing volume with the contents from a new image, that does not work.
https://docs.docker.com/engine/tutorials/dockervolumes/#/data-volumes
States:
Changes to a data volume will not be included when you update an image.