Docker mounting remote volume with sshfs - docker

I know that this question has been done on the web, but I am not able to find a suitable solution for me.
I have one server (VM1) with sshfs installed that should provide remote file system storage. I have another server (VM2) where containers are run, I would like that these containers use volumes hosted in VM1.
I followed this official docker guide
So in VM1 I ran:
docker plugin install vieux/sshfs DEBUG=1 sshkey.source=/home/debian/.ssh/
In VM 2 I ran:
docker volume create --name remotevolume -d vieux/sshfs -o sshcmd=debian#vm1:/home/debian/sshfs300 -o IdentityFile=/home/csicari/data/Mega/lavoro/keys/vm-csicari.key -o -o allow_other -o nonempty
This is the inspect output:
[
{
"CreatedAt": "0001-01-01T00:00:00Z",
"Driver": "vieux/sshfs:latest",
"Labels": {},
"Mountpoint": "/mnt/volumes/895d7f7679f69131500c786d7fe5fdc1",
"Name": "remotevolume",
"Options": {
"IdentityFile": "/home/csicari/data/Mega/lavoro/keys/vm-csicari.key",
"sshcmd": "debian#vm1:/home/debian/sshfs300"
},
"Scope": "local"
}
]
In VM1 I ran also:
docker run -it -v remotevolume:/home -d ubuntu
But I got this error:
docker: Error response from daemon: VolumeDriver.Mount: sshfs command execute failed: exit status 1 (read: Connection reset by peer
). See 'docker run --help'.

Maybe this is a long back asked question maybe it will help other newbies. The remote VM /etc/ssh/sshd_config file content check the property PasswordAuthentication yes
If it is 'yes' we can use with password passing parameter. otherwise, change it to 'no' and restart the ssh or sshd service.
service ssh restart
service ssh status
And also PasswordAuthentication. Depending on your PAM configuration, so check that as well.
If it is AWS instance reset the password using the command passwd ubuntu # Here ubuntu is the default user in ec2 ubuntu instance

Related

Not able to access the container over localhost

Docker beginner here.
I created a simple asp.net web application , which on run shows me the default page of application.
Using the docker build command, I create a image out of it and further using the docker run command docker run -d --name {containername} -p 81:8080 {imageid}. Now when I try to access the container image over local host on browser i.e. http://localhost:81/, I am getting 'The site cannot be reached' error. I expected the same default page of application to open over the exposed port 81.
My docker client is windows/amd and docker server is linux/amd. The docker version I am using is 19.03.08
Using docker inspect I could see
"PortBindings": {
"8080/tcp": [
{
"HostIp": "",
"HostPort": "81"
}
]
},
and "IPAddress": "" in networksettings.
docker ps and docker ps -a
I would appreciate any help or suggestion.
From the screen shots attached, it seems your container is killed as soon as its started. You should have a process running in the container to keep it up & running. Only then will you be able to access via the host ip:port
In this case http://localhost:81
In your docker ps -a the status is exited. Ideally it should be something like this if your container is up & running.
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4c01db0b339c ubuntu:12.04 bash 17 seconds ago Up 16 seconds

Run docker inside ubuntu container

2 days I try to run the docker inside an ubuntu container:
docker run -it ubuntu bash
Install docker by instruction of https://docs.docker.com/engine/install/ubuntu/ or/and https://phoenixnap.com/kb/how-to-install-docker-on-ubuntu-18-04
Finally I have installed docker:
root#e65411d2b70a:/# docker -v
Docker version 19.03.6, build 369ce74a3c
But when I try to run docker run hello-world have some problem
root#5ac21097b6f6:/# docker run hello-world
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.
In service list not docker:
root#5ac21097b6f6:/# service docker start
docker: unrecognized service
root#5ac21097b6f6:/# service --status-all
[ - ] apparmor
[ + ] cgroupfs-mount
[ - ] dbus
[ ? ] hwclock.sh
[ - ] procps
[ ? ] ubuntu-fan
When try to run dockerd:
root#5ac21097b6f6:/# dockerd
INFO[2020-04-23T07:01:11.622627006Z] Starting up
INFO[2020-04-23T07:01:11.624389266Z] libcontainerd: started new containerd process pid=154
INFO[2020-04-23T07:01:11.624460438Z] parsed scheme: "unix" module=grpc
INFO[2020-04-23T07:01:11.624477203Z] scheme "unix" not registered, fallback to default scheme module=grpc
INFO[2020-04-23T07:01:11.624532871Z] ccResolverWrapper: sending update to cc: {[{unix:///var/run/docker/containerd/containerd.sock 0 <nil>}] <nil>} module=grpc
INFO[2020-04-23T07:01:11.624560679Z] ClientConn switching balancer to "pick_first" module=grpc
INFO[2020-04-23T07:01:11.664827037Z] starting containerd revision= version="1.3.3-0ubuntu1~18.04.2"
ERRO[2020-04-23T07:01:11.664943052Z] failed to change OOM score to -500 error="write /proc/154/oom_score_adj: permission denied"
...
INFO[2020-04-23T07:01:11.816951247Z] stopping event stream following graceful shutdown error="context canceled" module=libcontainerd namespace=plugins.moby
failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.6.1: can't initialize iptables table `nat': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.
(exit status 3)
Not understand why Permission denied if user root.
Install sudo and add root to the group, but it's not help.
apt-get install sudo
usermod -a -G sudo root
- sudo dockerd have the save problem.
How to make work docker inside ubuntu container? Do you have ideas?
ps. I know about docker-in-docker, I need exactly docker inside ubuntu-container
pss. I know about -v /var/run/docker.sock:/var/run/docker.sock - but needed independent the docker service inside ubuntu-container.
When running docker in docker, the container must use the docker engine on your host.
Here is a simple working setup:
1) Create a dockerfile with docker CLI installed. I am using the official compose image, so you also have docker-compose
FROM docker/compose:1.25.5
WORKDIR /app
ENTRYPOINT ["/bin/sh"]
2) When running it, mount the docker sock
$ docker build -t dind .
$ docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock dind
Form within the container, you now have docker. Try running docker ps
If you want to do docker in docker without -v /var/run/docker.sock:/var/run/docker.sock then I am afraid that there is no good way to do this.
Sharing the docker socket from host is the classic way to make docker containers run within another docker container.
I was trying my best to run containers within containers just like you for the past few days. Wasted many hours. So far most of the people advise me to do stuff like using the docker's DIND image which is not applicable for my case, as I need the main container to be Ubuntu OS, or to run some privilege command and map the daemon socket into container, like -v /var/run/docker.sock:/var/run/docker.sock
(Which never ever works for me, or for any Ubuntu OS I tried. Reason being, the main container which is based on Ubuntu OS does not comes with systemd which is important to run docker containers conveniently like a usual local machine)
The solution I found was to use Nestybox on my Ubuntu 20.04 system and it works best. Its also extremely simple to execute, provided your local system is ubuntu (which they support best), as the container runtime are specifically deigned for such application. It also has the most flexible options.
The free edition of Nestybox is perhaps the best method as of Nov 2022. Highly recommends you to try it without bothering all the tedious setup other people suggest. They have many pre-constructed solutions to address such specific needs with a simple command line.
The Nestybox provide special runtime environment for newly created docker container, they also provides some ubuntu/common OS images with docker and systemd in built.
Their goal is to make the main container function exactly the same as a virtual machine securely. You can literally ssh into your ubuntu main container as well without the ability to access anything in the main machine. From your main container you may create all kinds of containers like a normal local system does. That systemd is very important for you to setup docker conveniently inside the container.
One simple common command to execute sysbox:
dock run --runtime=sysbox-runc -it any_image
If you think thats what you are looking for, you can find out more at their github:
https://github.com/nestybox/sysbox
Quicklink to instruction on how to deploy a simple sysbox runtime environment container:
https://github.com/nestybox/sysbox/blob/master/docs/quickstart/README.md

Docker-compose not reading logging config in /etc/docker/daemon.json

I've got a daemon.json file, stored in /etc/docker/daemon.json. to configure the docker daemon with following contents:
{
"log-driver" : "syslog",
"log-opts": {
"syslog-facility": "local1",
"tag": "{{.Name}}"
},
"storage-driver": "devicemapper",
"storage-opts": [
"dm.fs=xfs",
"dm.thinpooldev=/dev/mapper/vg00-docker--pool",
"dm.use_deferred_removal=true"
]
}
None of the docker-compose services have logging options configured, nor are any of the docker containers configured to start with --log-driver in their cmd or entrypoint.
Inspecting the output of the docker info command, I can verify that the logging driver is set to syslog.
However when running a docker-compose stack, all of the containers still show json-file upon inspecting them with the command docker inspect --format='{{.HostConfig.LogConfig.Type}}' , which seems to me as if docker-compose is not respecting the /etc/docker/daemon.json config file, just for the logging config, as the storage-driver is set correctly.
The docker version I used to run this is 17.12.0, docker-compose is at 1.19.0
/etc/docker/daemon.json is default config file and docker daemon should access if exists when starts. Maybe there's something wrong in your file according to the configuration (because it looks ok according to syntax).
Let's try to force config-file read with debug enabled and see which error it shows.
/usr/bin/dockerd stop
/usr/bin/dockerd start -D -l debug --config-file /etc/docker/daemon.json
After that, you can see logs with journalctl -u docker
Alternatively, you know that you can test easily each config param passing them one by one via cli instead json config file, in order to figure out which of them causes that configuration is not load.
/usr/bin/dockerd stop
/usr/bin/dockerd start -D -l debug --log-driver syslog --storage-driver devicemapper ...
Adding one by one you will be able to check if for example it fails with storage-opts because /dev/mapper/vg00-docker--pool is not mounted or whatever.

Docker experimental version on Red Hat

I have a Red Hat machine on an AWS cloud. I installed Ansible and Docker (experimental version as the community edition cannot be installed now on Red Hat). Now I am runnig a simple command to check whether Docker works:
ansible local -m shell -a "docker pull hello-world"
I'm getting the following error:
localhost | FAILED | rc=1 >>
Using default tag: latest
Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon. Is the docker daemon running on this host?). Using system default: https://index.docker.io/v1/Cannot connect to the Docker daemon. Is the docker daemon running on this host?
When I use
sudo ansible local -m shell -a "docker pull hello-world"
localhost | UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).\r\n",
"unreachable": true
}
I have tested Ansible by copying a file into local host and it works fine whereas with Docker I'm facing this issue. Is there anything I am missing or anything that needs to be setup for Docker's experimental version?
You don't want to run ansible through sudo but tell ansible that it should run the command using sudo. That can be done by adding the -s flag
ansible local -s -m shell -a "docker pull hello-world"

Docker volume not used with Redis (mount does show up with inspect)

My final conclusion is that I wasn't able to set the /c/users/... location because it wasn't shared in "Docker".
After this I was able to see the /c/users/.. directory in all my container instances. I was then able to use the -v flag with this directory on every instance basically writing files to my host machine.
What I still don't get is that I don't think I'm actually using volumes at the moment... But it works...
I'm trying to have my Docker-hosted Redis instance to persist its data but the mounted volume doesn't seem to be used. I was using Docker with VirtualBox/boot2docker where the composition worked, however I have since moved to Docker for Windows where the compose file still works, but I'm not sure about the volumes property.
My docker-compose.yml file:
vq-redis:
image: redis:latest
ports:
- "6379:6379"
volumes:
- /c/users/r/.docker/data/redis/data:/data
It doesn't matter if I add or remove the volumes definition, because it will always show something like this with docker inspect:
"Mounts": [
{
"Name": "40791b26771b5d62778d85b0ef24e74e516f95d32cf217424232ce8f8a1b8c6f",
"Source": "/var/lib/docker/volumes/40791b26771b5d62778d85b0ef24e74e516f95d32cf217424232ce8f8a1b8c6f/_data",
"Destination": "/data",
"Driver": "local",
"Mode": "rw",
"RW": true,
"Propagation": "rprivate"
}
],
Is the volumes property still working with Docker for Windows or am I missing a point?
Edit:
If I run...
docker run --name vq-redis -d -v //c/users/r/.docker/data/vq-redis:/data redis redis-server --appendonly yes
... I can see the container appearing in Kitematic and with docker inspect I can see a mount going to my local folder. However the local folder isn't shown in Kitematic...
If I add data to the Redis server hosted in the container, then stop the container and start it again the data is gone.
I tried setting the local folder manually in Kitematic. This restarts the container so it seems, but I'm unsure if the initial parameters are passed again. You say:
"If the volumes aren't networked on run"
I guess they were actually networked on run as seen in the console.
Still, I can add data to the Redis instance hosted in the container. But as soon as I restart the container it's gone...
It should work. I assume you didn't get any errors (e.g., permission issues, etc.) and that you are removing old builds before rebuilding. Does the "/var/lib/docker/volumes/4079..." directory get created?
You could try using double leading slashes on Windows, which was a work-around for some versions:
volumes:
- //c/users/r/.docker/data/redis/data:/data
Redis wouldn't have anything to do with the volume not being created but have you tried other services or even basic docker create -v ... or docker run -v ...?
UPDATE:
There may be some gaps in your understanding of how Docker works that may be getting in the way here.
If you do docker run --name some-redis -d redis redis-server --appendonly yes it will create a volume similar to the one you have in your docker inspect output. Clearly you don't have a /var/lib/docker/volumes/... directory on your Windows machine -- that's in the VM docker host (e.g., boot2docker). How you get to the Docker host volumes differs depending on a number of factors.
If the volumes aren't networked on run, restarting won't help. Do docker stop some-redis && docker rm some-redis and re-run.
Eg. running this command
docker run --name some-redis -d -v $(pwd)/data:/data redis redis-server --appendonly yes
should work as you expect.
ls ./data => appendonly.aof.
It will obviously be empty at first. Destroying the container and creating a new one with the same directory will show the data is still there:
docker exec some-redis echo "set bar baz" | redis-cli
docker stop some-redis
docker rm some-redis
docker run --name some-redis2 -d -v $(pwd)/data:/data redis redis-server --appendonly yes
docker exec some-redis2 echo "get bar" | redis-cli
=> "baz"
(the previous value for "bar" set in the destroyed container).
If this doesn't work for you there could be some issues specific to your environment -- perhaps try a Vagrant-based solution or beta Docker or a native Linux host.

Resources