I started the launch process using docker-compose up command, still processing from last 3 hours. Is it usually taking the time.?
This is processing in visual studio terminal.
Related
I'm developing an python-django app running in docker containers (django, celery, postgres, redist...etc). It runs on Windows 10 with WSL2-Debian & Docker Desktop.
During my work I need to observe the consoles of all those containers, so I can monitor apps behavior, like when you run docker-compose up so you got all of them live.
When you click on the container within windowed Docker Desktop app you can see the container's console output, but not actual - it looks like it works until some point of time and there are no updates of the consoles output.
I remember it was working live just prior to a two or three Docker Desktop updates, and I'm sure it was real time there, but not now.
Did I change a setting or Docker Desktop was bugged?
PS. When I start my containers with docker-compose up (without -d) I can observe live logs on my shell console, but not in Docker Desktop anymore.
Any help how to restore Docker Desktop live console view?
The Docker Desktop 3.4 (released June 9th, yesterday) is supposed to have resolved docker/for-win issue 11251.
I don't see the error after upgrading (with the normal docker-compose, not the beta docker-compose v2).
However, as commented by the OP twk and in issue 11251:
the live log is somehow broken - extra newline is added after every new line, but historical log entries (Eg. when you switch to/from another container) are displayed without newlines between entries (which is OK).
Update June 29th from Mathieu Champlon
Sorry it took a while but we now have an internal build that should fix it, if you wanted to give it a try:
win/stable/amd64/66242/Docker Desktop Installer.exe
Update Aug. 2021: Issue 11251 just closed with:
Docker Desktop 3.6.0 has been released containing a fix for this issue.
It's a bug in Docker Desktop v3.3.3
GitHub issue: https://github.com/docker/for-win/issues/11251 as pointed by #Drarig29
I've created a .net core web api project and am successfully running it under Docker Desktop for Window. It works fine as long as I'm running the project in Visual Studio. I run the "Docker" profile and hit it with localhost:8000/. I've configured it to use port 8000...
But when I stop the visual studio debugger, I can no longer access it even though when it still shows up as "RUNNING" in Docker Desktop. How can I access the service in the container, without running the project in Visual Studio?
I'm a newbie in this area, but if an image has been built and that image is running in a container, I'd think I'd be able to access it without needing to run the visual studio project. Isn't the container a "compiled, built, stood-up instance of my image, running in a docker host"???
Thanks, Brent
"Isn't the container a "compiled, built, stood-up instance of my image, running in a docker host"???" Yes, it is, you're 100% right, but in the Visual Studio, they made some performance adjustments so everything can run so smoothly, without any overhead of stopping and removing the container, updating the image and running it etc. In fact, under the hood, your binaries and source code are mapped via volume, so there's no need to juggle building new images etc. every time you run the app. If you run docker inspect on the container created by the Visual Studio, you'll be able to see that that mapping in the "Mounts" section of the JSON output.
I created a brand new ASP.NET Core web API app from the template with Docker enabled. I noticed that the container lifetime is linked with the Visual Studio process. If I close the Visual Studio the container is stopped and removed and as soon as I open the solution with the previously mentioned project in the Visual Studio the container is immediately up and running even though I haven't even started debugging yet.
If you want to run a container outside of the Visual Studio, you can always build the image from the Dockerfile in your project and run it.
It could look like this:
cd "path/with/your/Dockerfile"
docker build -t "your-image-name" .
docker run -it -p 8000:80 -n "your-container-name" "your-image-name"
I am running Windows 10 Professional Version 1809. Pushing docker images to docker.io takes endless time (does not finish even after several hours). On my physical Ubuntu machine in the same network pushing the same finishes in only a few seconds.
It seems this is not related to the way how I install docker. I tried Docker for Windows (using Hyper-V), Docker Machine (using VirtualBox) and also I installed Ubuntu+Docker within VirtualBox on my own. The result is always the same.
I already tried to disable Windows Defender, with no improvement at all.
Any ideas are welcome, since I am running out of ideas completely.
I'm a little newbie in the arch linux world, but i am a bit lost in this.
I have developped an electron app, simply one html page and one js page.
This application is a launcher for a machine the aim of this application is :
When i start the system, I must not see the wallpaper but directly the electron application.
The machine runs on Archlinux with LXDE environment.
I have been searching for a long time now, trying editing the /etc/xdg/LXDE/... lxsession/autostart
It is working, but the application takes 30 seconds to start....
I have been trying to change and run locally the application using chromium in command line in kiosk mode, but even chromium starts in 30 seconds.
I have been trying to use firefox instead, but it is the same situation.
The machine is composed of 4 cores intel, i don't think it is material beacause the system if very fast when i want to launch an application manually...
Sorry for my bad english,
I will appreciate, every information in order to know, how to privilege electron app boot within 1 second on arch linux / lxde
Thanks for advance,
Tom.
I am trying to run Cosmos DB emulator in a docker container. My OS is Windows 10.
I followed all the steps as explained by Microsoft here
Eventually, after importing the certificate the Enulator generates etc. I do manage to have a container running, but the UI looks empty (see below):
My understanding is that the UI should look like this instead:
This second UI is the one I can see running the emulator directly on my machine (no docker container involved)
Notice how the UI in the docker container says "Document DB", while the one running on my machine says "Cosmos DB". Not to mention the different layout (and the fact that the second one actually works)
What puzzles me is that I am certain this is the same installer we are looking at here. I know this because, after having this issue with the official Microsoft image, we build our own docker image using the same installer that put Cosmos DB Emulator on our machines and when we run it... same result.
To be clear - those 2 UIs are the result of the same installer, running in docker container and running on a windows 10 machine.
Has anyone else encountered the same issue and if so, have you found a way to fix this issue?
All help highly appreciated