I am recently working on GitLab CI/CD and I want to set up a runner on digital ocean droplet however I get the following error:
$ docker network create web
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Cleaning up project directory and file based variables
00:00
ERROR: Job failed: exit code 1
how should I avoid this problem, consider that the docker is up and running on the droplet ubuntu with 8 GB ram
it can be only one of this reason:
a) gitlab-runner user is not in docker group
id gitlab-runner
should show something like
uid=998(gitlab-runner) gid=998(gitlab-runner) groups=998(gitlab-runner),1001(docker)
b) docker service is not running in droplet
Related
Our Spinnaker is deployed on Ubuntu 18, Spinnaker version is 1.20.3. The only way we can view the logs is to run journalctl -u $microservice there are no logs on /var/log/spinnaker.
Is this normal?
Yes. The preferred way of installation for Spinnaker is in Kubernetes. A quick and easy way for you to get started and easily migrate is to backup all you config with halyard, export the pipelines as json and run Minnaker in any Ubuntu 18 Compute box
Then import your old spinnaker data and pipelines.
The Ubuntu18 debian deploy flavor that you are running could be useful to debug cloud driver issues or for development purposes.
I suggest that you perform the migration to a Kubernetes cluster.
The reason why none of the Spinnaker microservices output any logs to their log file directories in /var/log/spinnaker is because the preferred method of installation for Spinnaker is to use Kubernetes.
If the microservices were to create log files in /var/log/spinnaker, there is a good chance that the Kubernetes pods would die due to running out of storage, hence they all output their logs to STDOUT, and can be retrieved from Kubernetes by running:
kubectl -n spinnaker logs POD_NAME > my_logfile_name.log
If you prefer to run Spinnaker on a VM rather than in Kubernetes and want to enable the log files so that you can debug a specific issue instead of using journalctl, you can edit the systemd service file for the particular microservice, for example Clouddriver, and add the following line in the [Service] section:
StandardOutput=append:/var/log/spinnaker/clouddriver/clouddriver.log
Then you reload the systemctl daemon and restart the service and it will then output its logs to the specified log file instead of STDOUT, for example:
sudo systemctl daemon-reload
sudo systemctl restart clouddriver.service
We have an application which uses SSH to copy artifact from one node to other. While creating the Docker image (Linux Centos 8 based), I have installed the Openssh server and client, when I run the image from Docker command and exec into it, I am successfully able to run the SSH command and I also see the port 22 enabled and listening ( $ lsof -i -P -n | grep LISTEN).
But if I start a POD/Container using the same image in the Kubernetes cluster, I do not see port 22 enabled and listening inside the container. Even if I try to start the sshd from inside the k8s container then it gives me below error:
Redirecting to /bin/systemctl start sshd.service Failed to get D-Bus connection: Operation not permitted.
Is there any way to start the K8s container with SSH enabled?
There are three things to consider:
Like David said in his comment:
I'd redesign your system to use a communication system that's easier
to set up, like with HTTP calls between pods.
If you put a service in front of your deployment, it is not going to relay any SSH connections. So you have to point to the pods directly, which might be pretty inconvenient.
In case you have missed that: you need to declare port 22 in your deployment template.
Please let me know if that helped.
Created a 2 node Kubernetes cluster as:
KUBERNETES_PROVIDER=aws NUM_NODES=2 kube-up.sh
This shows the output as:
Found 2 node(s).
NAME STATUS AGE
ip-172-20-0-226.us-west-2.compute.internal Ready 57s
ip-172-20-0-227.us-west-2.compute.internal Ready 55s
Validate output:
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok
scheduler Healthy ok
etcd-0 Healthy {"health": "true"}
etcd-1 Healthy {"health": "true"}
Cluster validation succeeded
Done, listing cluster services:
Kubernetes master is running at https://52.33.9.1
Elasticsearch is running at https://52.33.9.1/api/v1/proxy/namespaces/kube-system/services/elasticsearch-logging
Heapster is running at https://52.33.9.1/api/v1/proxy/namespaces/kube-system/services/heapster
Kibana is running at https://52.33.9.1/api/v1/proxy/namespaces/kube-system/services/kibana-logging
KubeDNS is running at https://52.33.9.1/api/v1/proxy/namespaces/kube-system/services/kube-dns
kubernetes-dashboard is running at https://52.33.9.1/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard
Grafana is running at https://52.33.9.1/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana
InfluxDB is running at https://52.33.9.1/api/v1/proxy/namespaces/kube-system/services/monitoring-influxdb
I can see the instances in EC2 console. How do I ssh into the master node?
Here is the exact command that worked for me:
ssh -i ~/.ssh/kube_aws_rsa admin#<masterip>
kube_aws_rsa is the default key generated, otherwise controlled with AWS_SSH_KEY environment variable. For AWS, it is specified in the file cluster/aws/config-default.sh.
More details about the cluster can be found using kubectl.sh config view.
"Creates an AWS SSH key named kubernetes-. Fingerprint here is the OpenSSH key fingerprint, so that multiple users can run the script with different keys and their keys will not collide (with near-certainty). It will use an existing key if one is found at AWS_SSH_KEY, otherwise it will create one there. (With the default Ubuntu images, if you have to SSH in: the user is ubuntu and that user can sudo"
https://github.com/kubernetes/kubernetes/blob/master/docs/design/aws_under_the_hood.md
You should see the ssh key-fingerprint locally in ssh config or set the ENV and recreate.
If you are throwing up your cluster on AWS with kops, and use CoreOS as your image, then the login name would be "core".
I'd like to create a ssh tunnel from my computer to a remote server to a docker container running Jupyter Notebook (computer>server>Docker container) that allows me to run a Jupyter Notebook in my browser on my computer.
The Docker container is hosted on a machine running OS X (El Capitan). Docker is using the default machine IP: 192.168.99.100.
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
default * virtualbox Running tcp://192.168.99.100:2376 v1.11.1
I am able to physically sit at the server running the Docker container and use my browser (192.168.99.100:8888) to create Jupyter Notebooks from that Docker container. This verifies that my Docker port bindings work and that I'm running the Jupyter Notebook correctly.
However, I don't know how to establish a ssh tunnel from a client machine to that remote machine's Docker container and launch a Jupyter Notebook in my browser on the client machine.
The output from:
$ docker ps
produces the following:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
48a8ac126c72 kubu4/bioinformatics:v11 "/bin/bash" 55 minutes ago Up 55 minutes 8787/tcp, 0.0.0.0:8888->8888/tcp stupefied_pasteur
My attempts at creating a ssh tunnel to the remote machine's Docker container results in the following error message in Terminal when I try to launch the Jupyter Notebook in my browser on the client machine (localhost:8888):
channel 3: open failed: connect failed: Connection refused
I'm currently using the following in my .ssh/config file to create the tunnel:
Host tunnel3
HostName remote.ip.address
User user
ControlMaster auto
ServerAliveInterval 30
ServerAliveCountMax 3
LocalForward localhost:8888 localhost:8888
I can use this tunneling configuration to successfully launch Jupyter Notebooks in my client browser if I run the Jupyter Notebook on the remote machine outside of the Docker container that's on the remote machine.
Just for added info, this is the output when I launch the Jupyter Notebook in the remote machine's Docker container:
$ jupyter notebook
[I 18:23:32.951 NotebookApp] Writing notebook server cookie secret to /root/.local/share/jupyter/runtime/notebook_cookie_secret
[I 18:23:33.072 NotebookApp] Serving notebooks from local directory: /usr/local/bioinformatics
[I 18:23:33.073 NotebookApp] 0 active kernels
[I 18:23:33.073 NotebookApp] The Jupyter Notebook is running at: http://0.0.0.0:8888/
[I 18:23:33.074 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
I figured it out! The "A-ha!" moment was remembering that the remote machine running Docker was OS X (El Capitan). All my Docker builds/tests had been performed on a Linux (Ubuntu 14.04) machine. The difference, it turns out, is critical to solving this problem.
Docker installs on Ubuntu allow you to use "localhost" to address the Docker container. Docker installs on OSX generate an IP address to use to address the Docker container.
Realizing this, I changed my ssh tunneling configuration in the.ssh/config file on my client computer.
Old tunneling config:
Host tunnel3
HostName remote.ip.address
User user
ControlMaster auto
ServerAliveInterval 30
ServerAliveCountMax 3
LocalForward localhost:8888 localhost:8888
New tunneling config:
Host tunnel3
HostName remote.ip.address
User user
ControlMaster auto
ServerAliveInterval 30
ServerAliveCountMax 3
LocalForward localhost:8888 192.168.99.100:8888
With this change, I can successfully create/use Jupyter Notebooks in my client browser that are actually hosted in the Docker container on the remote machine, using localhost:8888 in the URL bar.
Had the same problem, trying to ssh-tunnel into a google cloud instance, then into a docker container.
Local machine: Ubuntu (14.04)
Cloud Instance: Debian (9-stretch)
Find the IP address Debian assigns to docker (credit):
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' container_name_or_id
This gave me 172.18.0.2 for the first instance running, 172.18.0.3 for the second, ..0.4, ..0.5, etc. (Note: The below didn't work if I was running multiple containers on the same instance. Since I only need to run one container, I'm not going to figure out how to fix it)
ssh into the compute instance
Make sure ports are exposed between your Docker container and Compute instance (I used 8888:8888), then (credit):
gcloud compute ssh {stuff to your instance} -- -L 8888:172.18.0.2:8888
Run jupyter
jupyter-notebook --no-browser --ip=0.0.0.0 --allow-root
Now I can open my local browser to localhost:8888/?token... and use jupyter running in a container on my gcloud instance.
I'm trying to follow beginner tutorial on Docker's website and I suffer with an error on login.
OS is Ubuntu 14.04, I'm not using VirtualBox and I'm not behind any proxy and want to push to the "regular" docker repository (not private one).
All threads I've found mention proxies and private repositories but that isn't my case, I'm just trying to do simple beginner tutorial.
Here is my attempt:
$ sudo docker login
[sudo] password for myuname:
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: myDHuname
Password:
Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
My docker info:
Containers: 5
Running: 0
Paused: 0
Stopped: 5
Images: 5
Server Version: 1.11.0
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 28
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge null host
Kernel Version: 3.19.0-58-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.686 GiB
Name: myuname-ThinkPad-T420
ID: 6RW3:X3FC:T62N:CWKI:JQW5:YIPY:RAHO:ZHF4:DFZ6:ZL7X:JPOD:V7EC
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Epilogue
Now docker login is passing. I have not touched anything since yesterday when it was broken...
I can't reproduce the behavior anymore.
I encounter this issue when my first use docker. I've shadowsocks proxy on, and configed as pac mode. When I try to run docker run hello-world, I get this timeout error. When I set the proxy mode to global, the error is aslo there.
But when I disable the proxy, docker runs well. It pull remote image successfully.
docker for windows
Note: Some users reported problems connecting to Docker Hub on Docker
for Windows stable version. This would manifest as an error when
trying to run docker commands that pull images from Docker Hub that
are not already downloaded, such as a first time run of docker run
hello-world. If you encounter this, reset the DNS server to use the
Google DNS fixed address: 8.8.8.8. For more information, see
Networking issues in Troubleshooting.
The error Client.Timeout exceeded while awaiting headers indicates:
GET request to the registry https://registry-1.docker.io/v2/ timedout
The library responsible (most likely libcurl) timed out before a response was heard
The connection never formed (proxy/firewall gobbled it up)
If you see the below result you can rule out timed out and network connectivity
$ curl https://registry-1.docker.io/v2/
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}
If you get the above response next would be to check if your user environment has some proxy configuration.
env | grep "proxy"
Note: The docker runs as root. Maybe you have http_proxy in your env. Most likely I am wrong. Anywho see what happens with the curl GET request
change the proxy settings in the firefox. May be you are in access restricted mode. Just add the server address in the firefox settings -> preferences -> advanced -> network -> configuration (settings). Add the server ip in the no proxy for the issue can be resolved