I am new to both dockers and couchdb.
I have a Linux box (let's call it A) on which I have docker installed. On this, I am running a container (lets called it docker1) on which I've installed couchdb.
I now need to open the couchdb console and open the views. I know I can normally do it by doing http://localhost:ip/, but in this case couchdb is installed on a docker container. I know we can access the container port from the docker container host. However, I need to access the couchdb instance running on a docker container (docker1) from the Windows PC from which I am accessing the Linux box A.
Is there a good way to access the console from the Windows PC?
If not, is there a way to access the couchdb view? I want to edit it so that there are multiple keys.
Assuming you have GUI access to your Linux box (from your description, I'm guessing it's not just a VM hosted on the Windows box), and if you're using a recent build of CouchDB (and the default port), you should be able to administer your CouchDB databases from your Linux box by navigating to http://localhost:5984/_utils/index.html in a browser.
If you only have command-line access to your Linux box, you should be able to access the same interface from your Windows box as long as the port (5984) is open and accessible to HTTP traffic.
execute this on the Linux host.
docker run -p 5984:5984 -d couchdb
Now you can connect from the Windows host by using the LAN ip of the Linux host and the port 5948.
Related
I have installed wsl2 , i have ubuntu in it, i have docker in windows enabled wsl2 integration for docker desktop software....my team sent me a docker to run it runs on port 8000, but i am dumb i dont know how to access it, they told they use vbox and port forward 127.0.0.1 to access it from localhost
I want to access it moreover i want to check it whether it works or not i tried curl localhost:8000
In ubuntu of wsl
In Windows browser
I am new so do tell what information you all want i can provide
I use docker-compose to spin up a few containers as part of an application I'm developing. One of the containers needs to start a docker swarm service on the host machine. On Docker for Windows and Docker for Mac, I can connect to the host docker daemon using the REST Api by using the "host.docker.internal" DNS name and this works great. However, if I run the same compose file on linux, "host.docker.internal" does not work (yet, seems it may be coming in the next version of docker). To make matters worse, on Linux I can use network mode of "host" to work around the issue but that isn't supported on Windows or Mac.
How can I either:
Create a docker-compose file or structure a containerized application to be slightly different based on the host platform (windows|mac|linux) without having to create multiple docker-compose.yml files or different application code?
Access the host docker daemon in a consistent way regardless of the host OS?
If it matters, the container that is accessing the docker daemon of the host is using the docker python sdk and making api calls to docker over tcp without TLS (this is used for development only).
Update w/ Solution Detail
For a little more background, there's a web application (aspnet core/C#) that allows users to upload a zip file. The zip file contains, among other things, an exported docker image file. There's also an nginx container in front of all of this to allow for ssl termination and load balancing. The web application pulls out the docker image, then using the docker daemon's http api, loads the image, re-tags the image, then pushes it to a private docker repository (which is running somewhere on the developer's network, external to docker). After that, it posts a message to a message queue where a separate python application uses the python docker library to deploy the docker image to a docker swarm.
For development purposes, the applications all run as containers and thus need to interact with docker running on the host machine as a stand alone swarm node. SoftwareEngineer's answer lead me down the right path. I mapped the docker socket from the host into the web application container at first but ran into a limitation of .net core that won't be resolved until .net 5 which is that there's no clean way of doing http over a unix socket.
I worked around that issue by eventually realizing that nginx can reverse proxy http traffic to a unix socket. I setup all containers (including the dynamically loaded swarm service from the zips) to be part of an overlay network to give them all access to each other and allowing me to hit an http endpoint to control the host machine's docker/swarm daemon over http.
The last hurdle I ran into was that nginx couldn't write to the mapped in /var/run/docker.sock file so I modified nginx.conf to allow it to run as root within the container.
As far as I can tell, the docker socket is available at the path /var/run/docker.sock on all systems. I have personally verified this with a recent Linux distro (Ubuntu), Windows 10 Pro running Docker for Windows (2.2.0) with both WSL2 (Ubuntu and Alpine) and the windows cmd (cli) and powershell. From memory, it works with OSX too, and I used to do the same thing in WSL1.
Mapping this into a container is achieved on any terminal with the -v, --volume, or --mount flags. So,
docker container run -v /var/run/docker.sock:/var/run/docker.sock
Mounts the socket into an identical path within the container. This means that you can access the socket using the standard docker client (docker) from within the container with no extra configuration. Using this path inside a Linux container is recommended because the standard location and is likely to be less confusing to anyone maintaining your code in the future (including yourself).
I'm new to both docker and Nifi, I found this command that installs via docker and used it on a virtual machine that I have in GCP but I would like to access this container via webserver. In docker ps this appears to me:
What command do I need to execute to gain access to the tool via port 8080?
The container has already exposed port 8080 on the host, as evidence by the output 0.0.0.0:8080->8080/tcp. You read that as {HOST_INTERFACE}:{HOST_PORT}->{CONTAINER_PORT}/{PROTOCOL}.
Navigate to http://SERVER_ADDRESS:8080/ (or maybe http://SERVER_ADDRESS:8080/nifi) using your web browser. You may need to modify the firewall rules applied to your VM to ensure that you can access that port from your local machine.
I have a docker running my PHP app.
This docker needs to run inside a VM in a remote datacenter.
I work from a computer that can connect to the mentioned VM.
My intention is to have the Xdebug session that is initiated inside the docker reach my computer (more precisely my PHPStorm).
Both docker and the VM are running Centos (company approved/installed images).
The development computer is OSx.
I am able to use ssh remote forward (aka: tunnel) to forward any requests from the VM to my computer.
I want to either:
- be able to open a tunnel from my computer directly to the docker container in the VM
- or be able to continue the current tunnel in from the VM to the docker.
Have found no way to do the first option and have ran into a lot of issues trying to do the second.
Any suggestions?
I have a linux on cloud with a installed docker service on it. How can I use my VS on cloud instead of docker-machine on my OSX? it means instead of install VirtualBox and create a VM on it by docker-machine, I use my server on cloud as docker server.
To access a remote Docker daemon simply pass the -H flag to your docker commands:
docker -H=tcp://192.168.0.100:2375 images
You need to ensure that the remote Docker daemon is listening on the appropriate network interface. Be aware though that doing this on an external server is highly insecure, anyone that can reach the port has effectively root access on the server. At the very least read this article on securing the Docker daemon.
Personally I would only recommend using a port binding via ssh tunnel to access the remote Docker daemon.
You might get a solution from docker-machine's generic driver. Just start the virtual server in cloud, set up proper SSH keys and get started :) It should work just the same as with a VM within VirtualBox.
I'm not sure how to get VS auto-started if it is shut down though. Via a could-vendor specific command line program?
Edit: I should have read the docs better, the first cloud example actually shows the usage of digital ocean driver. If it is already running then just use the generic driver.