I'm using Docker Desktop for Mac to run a Docker container running FileMaker Server 19 on Ubuntu Server. When I start up Docker Engine from scratch, i.e., no daemons running, then start the container, all works as expected. I can open FileMaker's admin console in a browser and I can open the hosted database with FileMaker Pro client app.
But if I stop the container from running and quit Docker Desktop and try to run the container again it starts up but I can't establish connections to it either with the FileMaker Pro client or a browser. The solution I've found is to quit the Docker processes that continue to run in the background and make the Docker engine restart from scratch. This obviously isn't desirable and it indicates to me that something isn't configured correctly in the network connection to the container.
I'm new to Docker, so apologies in advance if I'm missing something very basic. I searched for an solution online but can't find one.
Related
To be able to run docker-compose, I need to have docker desktop running, otherwise I'll get connection refused errors.
Is there a way I can start docker WITHOUT starting the desktop app to be able to then run what needs to be run?
I am very new to Docker as a whole.
I have a VPS with Debian 10 Buster, running Docker. I also installed Docker Desktop on my windows 10 pc. I like the GUI, and I googled if i can manage my VPS docker with this application, but found no answear.
Is this possible, or am i missing something obvious?
While I have not been able to connect the Windows 10 Docker Desktop application to my Docker engine running on my Debian 10 VPS, I found an alternative:
portainer.io
This is a service, with a free plan option(CE). You install this docker image following their documentation, and it runs on the host machine, in my case, the Debian VPS. I use this image on port 9000, so all I have to do to access it is open a browser and navigate to http://HOSTIPADDRESS:9000.
There you will find a gui similar to the Docker Desktop application.
I'm using docker desktop for mac.
I have built a docker image for a Node.js app that connects to an external MongoDB database via URI (the db is running on an AWS instance that I'm connected to over vpn). This works fine - I run the container and the app can connect to the database. Happy days.
Then...
I enable Kubernetes on docker desktop. I apply a deployment.yml to run the container but this deployment fails when trying to connect to the db. From my app's logs (I'm using mongoose):
MongooseServerSelectionError: connect EHOSTUNREACH [MY DB IP] +30005ms
Interestingly...
I can now no longer connect to the db by running my docker container either. I get the same error.
I have to disable kubernetes, restart docker desktop (twice), prune my previous container and network, and re-run my container. Then it will work again.
As soon as I enable kubernetes again, the db becomes unreachable again.
Any ideas why this is and/or how to fix it?
So the issue for us turned out to be an IP range clash. Exactly the same as described in this SO question:
Change Kubernetes docker-for-desktop cluster network ip
Unfortunately, like this user, we haven't been able to find a solution
I just started learning to use docker. My original purpose is to build a development environment image based on ubuntu, so that I can have a consistent development environment when I frequently switching between different machines: company windows PC, company windows laptop, macbook at home...
Now I've built an image FROM ubuntu. But what surprises me is that the container cannot be used as a running machine. When I run docker run xxxx, the container just exit immediately due to that I didn't run any service in it.
I found that I can use docker run -it xxx to get into /bin/bash on the machine and do something. But the container exit immediately I type exit in bash.
How can I use an ubuntu image as a long running server, and I can ssh into it from whatever machine I'm current using??
Checkout the LXD project from canonical, which is attempting to build a full OS capability using containers:
http://www.ubuntu.com/cloud/lxd
Docker, on the other hand, is designed primarily to package and deploy applications.
Dockers can totally be a long running process, it is designed first for running servers. The issue you are seeing is just because you didn't give it a process in your Dockerfile to run. If you do not then as you saw it will run like a service.
Try doing more of the docker lessons, you just need a CMD at the end to keep it running, like most containers use.
I'm setting up Oracle WebLogic 11g (10.3.6) in a Docker container (1.11) following Bruno's guide and docker files. I'm using History to grab the files for WL 11g since it's not official supported.
I have built all required components and am able to startup containers and WebLogic just fine, however after restarting the container WebLogic slows down considerably.
The container starts with: CMD ["startWebLogic.sh"]. If I use the WL Admin Console to stop the server, or use docker stop <container_name>, then use docker start <container_name> the container will come up, but Admin Console requests take 5+ minutes to complete.
Everything works fine on a fresh container using something like docker run -d --name wlsadmin --hostname wlsadmin -p 7001:7001 1036-domain but as soon as the container is restarted everything grinds to a halt.
I am not making any changes to the defaults. Simply starting a new container, stopping the container, and starting it back up again.
Does anyone have suggestions on how to troubleshoot this issue and get to the root cause?
I have also created WL 12.1 and WL 12.2 containers that all work successfully, even after restarts, but my legacy app only runs on WL 10.3.6, so I'm really trying to figure this out for 11g and am stumped.
Thanks for any help!
Turns out this is related to WebLogic and not Docker, namely how long it takes to generate random numbers.
Here is the solution
While the docker files did attempt to compensate for this, the implementation was not successful. I was able to fix the docker files and the Admin Console's performance returned to normal.