I have some kind of problem running multi container application on Mac.
I have 3 containers working together: 2 simply web api (.NET Core) and the official container RabbitMQ, the 2 api exchange events using RabbitMq service.
The application runs correctly running docker compose project from Visual Studio debug, when Api1 receive a POST it creates some data on DB and send message to Api2 using rabbit; Api2 receive the message sent by Api1, both api are visible on localhost... so far so good.
When I try to move the application from Visual Studio debug to Docker I get some problems, my idea was to use the docker compose file generated by VS on the CLI of docker (docker-compose up), following the sequence of action I've done:
1) Executing docker-compose up from Docker CLI, the build of the containers present in docker-compose failed (I was expecting VS just execute the same docker-compose up during debug, so I was expecting the same results, but probably I was wrong).
Solution: I've removed the build and use the images created by VS during previous debug test (still available in docker image local repository), this bypass the build problem (I have to investigate anyway the reasons, but let's move to next point)
2) After step 1 I can run docker-compose up without error, but the 2 containers with the 2 apis exit immediately with code 0, the RabbitMQ container doesn't have any problems and keep running as expected.
Solution: I've add stdin_open:true and tty:true in docker-compose to solve this strange issue
3) After step 2 I've executed docker-compose up and I was able to see all containers running correctly, but the 2 api containers are not reachable anymore on localhost (the related port are exposed and published), so I cannot send any POST request to the api anymore
I am not a big expert of Docker, but to run this simple multi container application took me much more time than expected, and still I have doubts and issues, any suggestions are more than welcome.
Thanks
I've found and fixed all issues, I report here because I suppose should be useful for other people:
1) This issue is related to a bug in VS 2019, the problem occurred when you include in a solution some projects (in my case class library) that are not in the same folder of the solution, this will generate wrong destination path for the COPY command in the dockerfile, for this reason the build fail.
I've reported issue to Microsoft:
Wrong Copy command in Dockerfile
meanwhile waiting for a fix you can put all the project used in a solution in the same solution folder, this avoid the wrong path generated in dockerfile and therefore the failure of the build procedure.
2) This issue is present only in images created by docker-compose in debug (normally you can recognize them by the tag "dev"), these image are useful for debug but do not use them outside VS debug.
Once fixed point 1 the creation of images using docker-compose was executed correctly and images are working as expected (without adding stdin_open:true and tty:true in docker-compose).
3) Also this issue using the images created on point 1 is solved.
Related
I am not very familiar with CapRover, but my company uses it to deploy local branches to staging server. I completed a task in a ruby and rails project and tried to deploy my branch using the caprover deploy command.
The build passes, but the deployed app webpage goes to error 502. In the App Logs, it prints repeatedly that it could not find docker-entrypoint.sh: /bin/sh: 1: docker-entrypoint.sh: not found
Now, I use Windows and my colleagues use Linux. They tried to replicate the deploy on their machines and it is passing normally. That's why the suspicions falls on Windows causing it with some characters incompatibility, like slashes or quotations marks... I don't know how can I try to correct this issue without modifying the project files that they are already using and risk causing some problems where it is working...
I am not sure if I provided enough information for someone to try to help me fix this issue? I will gladly try to provide more infos if required
Thanks
When I have created a ASP.NET Web API application, I have checked to enable Docker for the project, not really knowing what that does. Now, I cannot start my application, becasue when I run it, I have the following error:
Error CTC1003 Visual Studio container tools require Docker to be running.
How can I disable Docker from the project?
What you've accidentally done is added support for containerizing your web API in a Docker container. Follow this to remove that support.
Remove lines that look like this from your .csproj files
<DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
<DockerComposeProjectPath>..\docker-compose.dcproj</DockerComposeProjectPath>
Remove these files if present, from solution and physical folder where the solution is homed.
docker-compose.dcproj
dockerfile.
.dockerignore
Dockerfile.build
Inside your project node there should be a Properties\launchsettings.json entry. Edit this to remove the "Docker" JSON element.
Finally, close and reopen the solution to make sure there are no mistakes, rebuild, and try to run. The profile that gets run is defined in launchsettings.json and is controlled by selecting the profile on the Debug toolbar (there may be other ways).
If none of that works, I suggest deleting (after backing up) and recreating the project without checking the Docker option.
I am working on project, where I need to have an access to debugging option.
I've tried to run my application as usually, but this time I received following message:
Unable to connect to web server 'IIS Express'
When I checked the console output I found there following note:
Failed to register URL "http://localhost:49748/" for site xxx application "/". Error description: The process cannot access the file because it is being used by another process. (0x80070020)
Successfully registered URL "https://localhost:44333/" for site xxx application "/"
I found also that 0x80070020 error - "in the case of IIS Express (or IIS) means that the port that it is attempting to listen on is being used by another process" (link to the similar question).
I can't understand what's happen here. When I try to run this application I'm receiving this error in my Visual Studio, but the application is starting in the background (I can manually navigate to the https://localhost:44333 and app is there). The problem is that I can't debug the code, cause the Visual Studio looks like 'unrelated' to this instance. Previously IIS Express was opening new browser window with URL of the application, and I was able to debugging my code.
I also can't understand why this problem is not appearing for brand new project - I've created new web app project to test this behaviour, and it does what I expect - I can use debugging in VS.
What I've tried to do so far is:
Restart VS,
Restart my local machine,
Change app url in solution explorer/properties/debug,
Remove applicationhost.config from .vs directory
and nothing works for me.
Before this issue appear I forked this repo: https://github.com/jasontaylordev/CleanArchitecture
and downloaded WSL and Docker - I doubt that this have an impact on my solution, but maybe this information will be helpful.
Is there anything what I can change/edit to back to my previous behaviour?
Thanks
I had this issue after upgrading to Windows 10 20H2. There are many answers I found on SO that did not work for me, but I found this blog that helped me figure out the problem. Try running netsh interface ipv4 show excludedportrange protocol=tcp on the command liine and check to make sure that the port you are using is not one of the excluded ports listed. If so, change it to one that is not excluded. I did this and everything worked as normal again.
I am using Docker for my deployment and as it stands I use Docker-Compose (.yml file) to launch ~6 containers simultaneously. Each image within the Compose file is locally found (no internet connection within deployment environment).
As it stands the steps my deployment takes are as follows:
Run docker-compose up (launches 6 containers from local images such as image1:latest, image2:latest, etc. using the images with the "latest" tag)
When exited/stopped, I have 6 stopped containers. Manually restart each of the six stopped containers (docker start xxx)
Manually commit each re-started container (docker commit xxx)
Manually re-tag each of the previous generation images incrementally (image1:latest -> image1:version1, image1:version2, etc.) and manually delete the image containing the "latest" tag
Manually tag each of the committed containers (which are now images) with the "latest" tag (image1:latest)
This process is rather user-involved and our deployment requires the user involvement to only be run the "docker-compose up" command then shutting down/stopping Docker-Compose.
The required end goal is to have a script, or Docker, take care of these steps by itself and end up with different generations of images (image1:version1, image1:version2, image1:latest, etc.).
So, my question is, how would I go about creating a script (or have Docker do it) where the script (or Docker) can autonomously:
Restart the stopped containers upon stopping/exiting of Docker-Compose
Commit the restarted containers
Re-tag the previous images with latest tags to an incremented version# (image1:version1, image1:version2, etc.) then delete the previous image1:latest image
Tag the newly committed restarted containers (which are now images) with the "latest" tag
This is a rather lengthy and intensive question to answer, but I would appreciate any help with any of the steps required to accomplish my task. Thank you.
The watchtower project tries to address this.
https://github.com/CenturyLinkLabs/watchtower
It auto restarts a running container when a base image is updated.
It is also intelligent so, for example, when in needs to restart a container that is linked to other containers, it does so without destroying the links.
I've never tried it but worth a shot!
Let us know how it goes. I'm gonna favourite this question as it sounds a great idea.
PS If watchtower proves a pain and you try to do this manually then ...
docker inspect
is your friend since it gives you loads of info about containers and images. Allowing you to determine current status.
I have deployed a node.js app in Bluemix using cf push. I have removed the start: entry from manifest.yml. In Bluemix I have set the environment variable BLUEMIX_APP_MGMT_ENABLEto devconsole+shell+inspector. This restages the app.
But when I open the App Manager by adding /bluemix-debug/manage/ I get a 404 error.
When I start Live Edit on the same project from DevOps Services I can open the App Manager. But I don't see what is different, it also seems to set the environment variable only.
What am I missing?
The Live Edit tool will automatically add 256MB to your application to facilitate execution of the additional features, which is likely why it is working with Live Edit.
Manually enabling the feature, however, will not automatically bump up the memory. Can you try adding some more memory to your application and restaging?
There are a couple of other limitations; refer to the Restrictions section on the App Management docs.
EDIT: Found issue in comments below. If command: node app.js is in manifest.yml, or if you are using -c with the CF CLI, it overrides the buildpack's ability to start the development utilities in App Mgmt. This happens even if you have the start command correctly specified in package.json or Procfile. To fix this, remove the manifest.yml entry, delete the application, and restage the application.