I'm using Jenkins on Docker on my local Mac Machine.
And I'm running another Docker on ubuntu VirtualBox. So now, there are 2 docker machines. one is on my mac machine and one is on my Ubuntu VirtualBox machine. I'm running Jenkins on Mac Docker. Now in the Jenkins pipeline, I want to build an image on my ubuntu machine.
I've configured Jenkins docker cloud and in the docker host URL, it is connected to the ubuntu docker-machine.
But while building a new image, I'm getting the error. Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
I've tried even adding ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:4243 -H unix:///var/run/docker.sock
at /lib/systemd/system/docker.service
WHen i check ps -aux,
Can someone please help me out?
help is appreciated.
First personally if I had a setup like that I would not bother connecting to the remote docker and would just install a Jenkins agent on the ubuntu machine and make it talk to the Jenkins master.
But if you want to do it they way you have it set up right now we a Jenkins talking from inside out one docker host into another docker host I suggest looking into the following:
Your Jenkins master and the ubuntu machine a very isolated they might as well just be on different machines not even in the same room. Unix domain sockets, the ones that are identified by unix://* are made for communicating within a single local OS kernel, trying to bridge them into remote machine will lead to disaster.
So the only way Jenkins could communicate to the remote host is via a remote protocol like TCP. Most of the time when you install docker with the default settings it doesn't even listen to TCP at all, mostly for security reasons.
First thing you should do is to configure a docker inside of the ubuntu machine to listen on TCP port and accept connections from remote hosts. You can use netstat -nat to see if anything is listening on TCP 4243. When things are configured correctly you see the line that stats with 0.0.0.0:4243 or something like that in the output of the nestat
Second you need to make sure your the firewalls/iptables/netfilter configuration on the Ubuntu host lets in connections from outside. A good test to try is to telnet <ubuntu-ip> 4243 from a terminal session on your Mac.
Then you need to make sure you that docker networking is configured correctly so that connections from the inside of the container that is running Jenkins end up on your ubuntu box. To test you need to exec -it into your jenkins container and repeat the telnet test. On modern linuxes telnet is usually not installed, so you can use curl -vvv which will always end up with an error, so just look at the verbose output to see if the error because things cannot communicate (timeout, connection reset etc) or the error occurs because your curl tried to talk HTTP to docker and got gibberish response. In the later case you can consider things to be set up correctly.
Finally you need to tell Jenkins Docker to communicate to the remote docker via TCP. Usually that is given on the command line to your docker run, docker ps, docker exec
I've configured it by defining the slave label in my Jenkins Pipeline.
Jenkins agents run on a variety of different environments such as physical machines, virtual machines, Kubernetes clusters, and Docker images.
In your Jenkins Pipeline or In your JenkinsFile, you've to set the agent accordingly to what you're using either using Docker image or any virtual machine.
Also Thank you so much #Vlad, all the things you told me, were really helpful.
Related
can i run docker socket over ssh?
i'm trying to run unix:///var/run/docker.sock but i'm getting the error "Is daemon service running?, Cannnot connect to daemon service"
Jenkins master and the ubuntu machine a very isolated they might as well just be on different machines not even in the same room. Unix domain sockets, the ones that are identified by unix://* are made for communicating within a single local OS kernel, trying to bridge them into remote machine will lead to disaster.
how can i use Docker sock over ssh?
stephen proposed a solution but i find this one more adequate to your use case.
you can simply use
ssh xxx "docker run yyy"
or you can use env variables :
be sure that you have ssh key authentification active
and call all your docker commands with this env variable defined :
DOCKER_HOST=remoteservername
docker will use ssh connection to run commands
you can also use -H (works the same)
see more here
https://betterprogramming.pub/docker-tips-access-the-docker-daemon-via-ssh-97cd6b44a53
I want to use Zabbix to monitor my server (just one so far). In order to keep things neat, I've decided to run it in Docker containers. I just have doubts about the usage of the agent in a container. As far as I understand it should be able to monitor the host itself. But containers are usually isolated. So what's the point to run the agent in the container?
And if there is a reason to do so, should the network mode for agent's container be "host"?
Intro:
I've just done a fully Dockerized Zabbix 6.2 installation using Zabbix's GitHub Docker-Compose repo. My experience was that the Docker install was the better path, but other's might of course have different views.
Although it looks really daunting- there's a lot of components in it- Zabbix's Docker-Compose repo is the quickest and least painful way to fire-up a Zabbix installation; much easier to setup than a manual config.
I used their repo to configure an all-singing-all-dancing Zabbix infrastructure on a Raspberry Pi4 with 8GB RAM using a 64bit ARM version of Ubuntu 20.04 LTS. It would have taken ages to get the same results with a manual config.
There was one issue regarding connectivity problems I note at the end however. But once you get past that it's plug-n-chug.
Configuration:
Below is a very general outline of the process of configuring Zabbix using their Docker-Compose repo.
Server Infrastructure
The basic form of raising the components is:
docker-compose -f docker-compose_v3_ubuntu_pgsql_latest.yaml --profile all up -d
NOTE: 172.16.238.3 is the default IP of the Zabbix Server in my testing- it should be yours as well- but validate the IP.
Agents:
Starting an Agent is as simple as:
docker run --add-host=zabbix-server:172.16.238.3 -p 10050:10050 -d --privileged --name myHost-zabbix-agent -e ZBX_SERVER_HOST="zabbix-server" -e ZBX_PASSIVE_ALLOW="true" zabbix/zabbix-agent:ubuntu-6.0-latest
Just change "myHost-zabbix-agent" and add the new Zabbix Agent in the Web interface.
To get the IP of a new Zabbix agent raised with the above command:
docker ps
Then get the random id for it and:
docker exec -u root -it (random ID for agent from docker ps) bash
Once inside the container, reveal it's IP with:
hostname -I
Use this IP for the Agent's interface in the Zabbix server's web interface. As you've rightly remarked, since the agent runs in a container, it's isolated and the default IP pf 127.0.0.1 won't work: you need a routable IP for the Zabbix Server to reach the Agent on.
Then move on to the next host, changing the hostname in the docker run command above, get the Ip and add it in the Zabbix Server's web interface.
Conclusion:
Nothing stopping you from tailoring the configuration- Zabbix has made it very tweakable- but using Zabbix's Docker-Compose GitHub repo enables you to get some decent monitoring in place quickly with little effort and reduces the grunt work to the bare minimum; important if you have a lot of hosts.
There was one issue with configuring Agents' connectivity- Docker inserted an iptables rule which broke connectivity by NAT'ing the traffic, but I documented how to get around the problem here:
Dockerized Zabbix: Server Can't Connect to the Agents by IP
Hope this saves you some cycles-
I installed Docker on Windows 10, and I pulled jenkins docker from Docker Hub. Next, I started my jenkins docker,
docker run --rm -u root -p 8080:8080 -v my_host_path:/var/jenkins_home jenkins
Next, I used Manage Jenkins and Manage Plugins to install Docker plugin, then went to the Configure page and tried to add Docker Cloud.
After I entered Docker Host URI : tcp://127.0.0.1:2375, I wanted to "Test Connection", but unfortunately got failed.
I tried to follow the instruction as below link:
How to find "Docker Host URI" to be used in Jenkins "Docker Plugin"?
But I can't not find any docker setting file under /etc/default/* in my jenkins container, so I can't set the DOCKER_OPTS argument.
Could someone give me any advise? Thank you !
Problem context: end of Chapter 3 exercise from the book "Continuous Delivery with Docker and Jenkins" by Rafal Leszko
from Configure and troubleshoot the Docker daemon page
Important: Setting hosts in the daemon.json is not supported on Docker Desktop for Windows or Docker Desktop for Mac.
Setting the docker host uri does NOT work on Windows. So either of these won't work in the Settings > Daemon tab:
"hosts" : "-H tcp://0.0.0.0:2375"
"DOCKER_OPTS" : "-H tcp://0.0.0.0:2375"
Exposing the daemon without TLS (checkbox on General tab) as recommended in some places did not work for me either.
The solution to connecting the Docker plugin in Jenkins with the docker host, is:
use the special DNS name host.docker.internal
From the docs:
How do I connect from a container to a service on the host?
Windows has a changing IP address (or none if you have no network access). We recommend that you connect to the special DNS name host.docker.internal, which resolves to the internal IP address used by the host. This is for development purposes and will not work in a production environment outside of Docker Desktop for Windows.
The gateway is also reachable as gateway.docker.internal.
For more information about the networking features in Docker Desktop for Windows, see Networking.
While the 'will not work in a production environment outside of Docker Desktop for Windows' disclaimer might bother some, I believe Docker for Windows is not meant for production use cases anyway.
Additionally, publish this mapping for Jenkins agent-master communication -p 50000:50000
new to docker and docker swarm. Trying docker and docker swarm both.
initially i had started a docker daemon and was able to connect it on http port i.e. 2375. I had installed docker colud plugin in jenkins and added http://daemon-IP:2375 and was able to create containers. well it creates a container, does my build inside it and destroys the container.
My Query is, will i be able to connect to docker swarm on http port, the same way i a am connecting to a standalone docker daemon ? is there any documentation on it. or the my understanding about the swarm is wrong.
please suggest.
Thanks
Yeah you can connect to a remote host the same way you are doing via the Unix Socket. People very often forget that docker is a client-server architecture and your "docker run..." commands are basically just commands issued by the docker client.
If you set certain environment variables:
DOCKER_HOST=tcp:ip.address.of.host:port
DOCKER_TLS_VERIFY=1
DOCKER_CERTS=/directory/where/certs/are
(The last two are optional for TLS connections, which I would highly recommend. You'd have to setup https://docs.docker.com/engine/security/https/ which is recommended for a production environment)
Once you've set your DOCKER_HOST environment variable, if you issue a docker command and get a response, it will be from the remote host if everything is setup correctly.
I setup both of my mesos-master and mesos-slave on a standalone server. E.g. To start my mesos-slave, I used this command:
sudo bin/mesos-slave.sh --master=zk://<IP address of server>:2181/mesos --log_dir=/var/log/mesos --containerizers=docker,mesos
What I am trying to figure out is how the containerizer on Mesos is implemented with just --containerizers=docker,mesos.
Will it be able to automatically detect whether Docker is installed on the mesos-slave? If it is, which tcp port will it normally get? port 4243 or 2375?
Mesos will try to autodetect docker by running docker version. You can specific an absolute path for the docker executable by passing the --docker=/path/to/docker flag to the slave. There are other docker-specific flags for the slave, like --docker_sandbox_directory, --docker_remove_delay, and --docker_stop_timeout. For more details on those, see https://mesos.apache.org/documentation/latest/configuration/
Mesos currently uses the docker command-line interface locally from the slave node, not via the remote API, so I don't think the docker port is relevant here.