You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Well, this time I really did find the source of the problem....
The problem was I was using CRLF line endings in the endpoint.sh script. On the linux side, those CRLF added a \r to then end of each line. So, for example, the file name makemigrations in the endpoint.sh script was interpreted in linux as makemigrations\r for the filename. Of course, that file name was not found.
Well I thought I could just run the command RUN dos2unix endpoint.sh, but that did not work either.
In VS Code I chose to use the \n line endings for the endpoint.sh file.
Rebuilt the images and ran the containers.
Everything works just as bobby said it should.
It would have been nice if bobby would have told us this in the tutorial. Then again, I learned a heck-of-a-lot about Docker in the last two days trying to trouble shoot this.
You can close this now.
Well, I think I know why the api container started with no ENTRYPOINT of CMD in the Dockerfile. In the docker-compose.yml file, there is a command instruction which has the following...
command: python manage.py runserver 0.0.0.0:8000.
It appears, the command: instruction in the docker-compose.yml file is all that is needed to start the api.?
While it works after making the change below, my optimism was a little misplaced.
I noticed that I did not get a message in the terminal for the running api container (in docker desktop) that migrations had been performed. If the entrypoint.sh file was executed I should have seen notification in the terminal that migrations were performed. This made me think that the entrypoint.sh script was not executed. So I removed the CMD line entirely from the revised Dockerfile and rebuilt the image. To my surprise, the api started up again. Without any ENTRYPOINT defined or any CMD. So the dockerized image must have used the default entypoint (wherever that is). So, even though it works, I have not been able to execute the entrypoint.sh script.
In a previous issue I described a problem I had regarding the docker images being built in module_3. The app image ran in a container, but the api image always failed to start. It failed with an error "exec /code/docker/entrypoints/entrypoint.sh : file or directory not found".
I finally got it work.
In the Dockerfile for the api (./backend/docker/ dockerfiles/Dockerfile)
I changed the line
ENTRYPOINT ["/code/docker/entrypoints/entrypoint.sh"]
to
CMD /code/docker/entrypoints/entrypoint.sh
Then I rebuilt the images using docker-compose up -d --build.
Brought up Docker Desktop and the app and api were both running. I submitted a request to the api using the apps docker terminal and received the correct response.
I would love to know why this worked.
On to module_4
FMR
The text was updated successfully, but these errors were encountered:
Well, this time I really did find the source of the problem....
The problem was I was using CRLF line endings in the endpoint.sh script. On the linux side, those CRLF added a \r to then end of each line. So, for example, the file name makemigrations in the endpoint.sh script was interpreted in linux as makemigrations\r for the filename. Of course, that file name was not found.
Well I thought I could just run the command RUN dos2unix endpoint.sh, but that did not work either.
Ultimately I found that VS Code allows us to choose the line endings for files ( this link https://medium.com/@csmunuku/windows-and-linux-eol-sequence-configure-vs-code-and-git-37be98ef71df)
In VS Code I chose to use the \n line endings for the endpoint.sh file.
Rebuilt the images and ran the containers.
Everything works just as bobby said it should.
It would have been nice if bobby would have told us this in the tutorial. Then again, I learned a heck-of-a-lot about Docker in the last two days trying to trouble shoot this.
You can close this now.
Well, I think I know why the api container started with no ENTRYPOINT of CMD in the Dockerfile. In the docker-compose.yml file, there is a command instruction which has the following...
command: python manage.py runserver 0.0.0.0:8000.
It appears, the command: instruction in the docker-compose.yml file is all that is needed to start the api.?
While it works after making the change below, my optimism was a little misplaced.
I noticed that I did not get a message in the terminal for the running api container (in docker desktop) that migrations had been performed. If the entrypoint.sh file was executed I should have seen notification in the terminal that migrations were performed. This made me think that the entrypoint.sh script was not executed. So I removed the CMD line entirely from the revised Dockerfile and rebuilt the image. To my surprise, the api started up again. Without any ENTRYPOINT defined or any CMD. So the dockerized image must have used the default entypoint (wherever that is). So, even though it works, I have not been able to execute the entrypoint.sh script.
In a previous issue I described a problem I had regarding the docker images being built in module_3. The app image ran in a container, but the api image always failed to start. It failed with an error "exec /code/docker/entrypoints/entrypoint.sh : file or directory not found".
I finally got it work.
In the Dockerfile for the api (./backend/docker/ dockerfiles/Dockerfile)
I changed the line
ENTRYPOINT ["/code/docker/entrypoints/entrypoint.sh"]
to
CMD /code/docker/entrypoints/entrypoint.sh
Then I rebuilt the images using docker-compose up -d --build.
Brought up Docker Desktop and the app and api were both running. I submitted a request to the api using the apps docker terminal and received the correct response.
I would love to know why this worked.
On to module_4
FMR
The text was updated successfully, but these errors were encountered: