I'm getting started with docker using docker-toolbox on win 10 home. I'm experimenting with scrapy splash project (https://github.com/scrapy-plugins/scrapy-splash). I've installed the toolbox on a flash drive (e:)
If I understand correctly I have installed docker using the docker toolbox. When I click on the docker quickstart terminal, I get the screenshot.
I ran:
$ docker-machine start
but when I :
$ docker run -it scrapinghub/splash
2019-05-25 22:33:53+0000 [-] Log opened.
2019-05-25 22:33:53.053632 [-] Splash version: 3.3.1
2019-05-25 22:33:53.054895 [-] Qt 5.9.1, PyQt 5.9.2, WebKit 602.1, sip 4.19.4, Twisted 18.9.0, Lua 5.2
2019-05-25 22:33:53.055695 [-] Python 3.5.2 (default, Nov 12 2018, 13:43:14) [GCC 5.4.0 20160609]
2019-05-25 22:33:53.056773 [-] Open files limit: 1048576
2019-05-25 22:33:53.057319 [-] Can't bump open files limit
2019-05-25 22:33:53.165435 [-] Xvfb is started: ['Xvfb', ':1788299128', '-screen', '0', '1024x768x24', '-nolisten', 'tcp']
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
2019-05-25 22:33:53.257636 [-] proxy profiles support is enabled, proxy profiles path: /etc/splash/proxy-profiles
2019-05-25 22:33:53.258827 [-] memory cache: enabled, private mode: enabled, js cross-domain access: disabled
2019-05-25 22:33:53.422507 [-] verbosity=1, slots=20, argument_cache_max_entries=500, max-timeout=90.0
2019-05-25 22:33:53.424799 [-] Web UI: enabled, Lua: enabled (sandbox: enabled)
2019-05-25 22:33:53.426021 [-] Site starting on 8050
2019-05-25 22:33:53.426778 [-] Starting factory <twisted.web.server.Site object at 0x7efcd8d8dcc0>
2019-05-25 22:33:53.427649 [-] Server listening on http://0.0.0.0:8050
I tried to open the browser at
http://0.0.0.0:8050
But get the error in the title. What am I doing wrong?
edit:
I had to remove prior container by :
docker container ls
docker rm -f <container-name>
Then it worked at :
http://192.168.99.100:8050/
You missed the publishing part.
docker run -it -p 8050:8050 scrapinghub/splash
Related
I have a Docker image which contains JRE, some Java web application and jmxterm. The latter is used for running some ad-hoc administrative tasks. The image is used on the CentOS 7 server with Docker 1.13 (which is pretty old but is the latest version which is supplied via the distro's repository) to run the web application itself.
All works well, but after updating jmxterm from 1.0.0 to the latest version (1.0.2), I get the following warning when entering the running container and starting jmxterm:
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
After this, jmxterm does not react to arrow keys (when trying to navigate through the command history), nor does it provide autocompletion.
Some quick investigation shows that the problem may be reproduced in the clean environment with CentOS 7. Say, this is how I could bootstrap the system and the container with all stuff I need:
$ vagrant init centos/7
$ vagrant up
$ vagrant ssh
[vagrant#localhost ~]$ sudo yum install docker
[vagrant#localhost ~]$ sudo systemctl start docker
[vagrant#localhost ~]$ sudo docker run -it --entrypoint bash openjdk:11
root#0c4c614de0ee:/# wget https://github.com/jiaqi/jmxterm/releases/download/v1.0.2/jmxterm-1.0.2-uber.jar
And this is how I enter the container and run jmxterm:
[vagrant#localhost ~]$ sudo docker exec -it 0c4c614de0ee sh
root#0c4c614de0ee:/# java -jar jmxterm-1.0.2-uber.jar
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
root#0c4c614de0ee:/# bea<TAB>
<Nothing happens, but autocompletion had to appear>
Few observations:
the problem does not appear with older jmxterm no matter which image do I use;
the problem arises with new jmxterm no matter which image do I use;
the problem is not reproducible on my laptop (which has newer kernel and Docker);
the problem is not reproducible if I use latest Docker (from the external repo) on the CentOS 7 server instead of CentOS 7's native version 1.13.
What happens, and why the error is reproducible only in specific environments? Is there any workaround for this?
TLDR: running new jmxterm versions as java -jar jmxterm-1.0.2-uber.jar < /dev/tty is a quick, dirty and hacky workaround for having the autocompletion and other stuff work inside the interactive container session.
A quick check shows that jmxterm tries to determine the terminal device used by the process — probably to obtain the terminal capabilities later — by running the tty utility:
root#0c4c614de0ee:/# strace -f -e 'trace=execve,wait4' java -jar jmxterm-1.0.2-uber.jar
execve("/opt/java/openjdk/bin/java", ["java", "-jar", "jmxterm-1.0.2-uber.jar"], 0x7ffed3a53210 /* 36 vars */) = 0
...
[pid 432] execve("/usr/bin/tty", ["tty"], 0x7fff8ea39608 /* 36 vars */) = 0
[pid 433] wait4(432, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 432
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
The utility fails with the status of 1, which is likely the reason for the error message. Why?
root#0c4c614de0ee:/# strace -y tty
...
readlink("/proc/self/fd/0", "/dev/pts/3", 4095) = 10
stat("/dev/pts/3", 0x7ffe966f2160) = -1 ENOENT (No such file or directory)
...
write(1</dev/pts/3>, "not a tty\n", 10not a tty
) = 10
The utility says "not a tty" while we definitely have one. A quick check shows that... There is really no PTY device in the container though the standard streams of the shell are connected to one!
root#0c4c614de0ee:/# ls -l /proc/self/fd
total 0
lrwx------. 1 root root 64 Jun 3 21:26 0 -> /dev/pts/3
lrwx------. 1 root root 64 Jun 3 21:26 1 -> /dev/pts/3
lrwx------. 1 root root 64 Jun 3 21:26 2 -> /dev/pts/3
lr-x------. 1 root root 64 Jun 3 21:26 3 -> /proc/61/fd
root#0c4c614de0ee:/# ls -l /dev/pts
total 0
crw-rw-rw-. 1 root root 5, 2 Jun 3 21:26 ptmx
What if we check the same with latest Docker?
root#c0ebd608f79a:/# ls -l /proc/self/fd
total 0
lrwx------ 1 root root 64 Jun 3 21:45 0 -> /dev/pts/1
lrwx------ 1 root root 64 Jun 3 21:45 1 -> /dev/pts/1
lrwx------ 1 root root 64 Jun 3 21:45 2 -> /dev/pts/1
lr-x------ 1 root root 64 Jun 3 21:45 3 -> /proc/16/fd
root#c0ebd608f79a:/# ls -l /dev/pts
total 0
crw--w---- 1 root tty 136, 0 Jun 3 21:44 0
crw--w---- 1 root tty 136, 1 Jun 3 21:45 1
crw-rw-rw- 1 root root 5, 2 Jun 3 21:45 ptmx
Bingo! Now we have our PTYs where they should be, so jmxterm works well with latest Docker.
It seems pretty weird that with older Docker the processes are connected to some PTYs while there are no devices for them in /dev/pts, but tracing the Docker process explains why this happens. Older Docker allocates the PTY for the container before setting other things up (including entering the new mount namespace and mounting devpts into it or just entering the mount namespace in case of docker exec -it):
[vagrant#localhost ~]$ sudo strace -p $(pidof docker-containerd-current) -f -e trace='execve,mount,unshare,openat,ioctl'
...
[pid 3885] openat(AT_FDCWD, "/dev/ptmx", O_RDWR|O_NOCTTY|O_CLOEXEC) = 9
[pid 3885] ioctl(9, TIOCGPTN, [1]) = 0
[pid 3885] ioctl(9, TIOCSPTLCK, [0]) = 0
...
[pid 3898] unshare(CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWNET|CLONE_NEWPID) = 0
...
[pid 3899] mount("devpts", "/var/lib/docker/overlay2/3af250a9f118d637bfba5701f5b0dfc09ed154c6f9d0240ae12523bf252e350c/merged/dev/pts", "devpts", MS_NOSUID|MS_NOEXEC, "newinstance,ptmxmode=0666,mode=0"...) = 0
...
[pid 3899] execve("/bin/bash", ["bash"], 0xc4201626c0 /* 7 vars */ <unfinished ...>
Note the newinstance mount option which ensures that the devpts mount owns its PTYs exclusively and does not share them with other mounts. This leads to the interesting effect: the PTY device for the container stays on the host and belongs to the host's devpts mount, while the containerized process still has access to it, as it obtained the already-open file descriptors just in the beginning of its life!
The latest Docker first mounts devpts for the container and then allocates the PTY, so the PTY belongs to container's devpts mount and is visible inside the container's filesystem:
$ sudo strace -p $(pidof containerd) -f -e trace='execve,mount,unshare,openat,ioctl'
...
[pid 14043] unshare(CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWNET) = 0
...
[pid 14044] mount("devpts", "/var/lib/docker/overlay2/b743cf16ab954b9a4b4005bca0aeaa019c4836c7d58d6073044e5b48446c3d62/merged/dev/pts", "devpts",
MS_NOSUID|MS_NOEXEC, "newinstance,ptmxmode=0666,mode=0"...) = 0
...
[pid 14044] openat(AT_FDCWD, "/dev/ptmx", O_RDWR|O_NOCTTY|O_CLOEXEC) = 7
[pid 14044] ioctl(7, TIOCGPTN, [0]) = 0
[pid 14044] ioctl(7, TIOCSPTLCK, [0]) = 0
...
[pid 14044] execve("/bin/bash", ["/bin/bash"], 0xc000203530 /* 4 vars */ <unfinished ...>
Well, the problem is caused by inappropriate Docker behavior, but how comes that older jmxterm worked well in the same environment? Let's check (note, that Java 8 image is used here, as older jmxterm does not play well with Java 11):
root#504a7757e310:/# wget https://github.com/jiaqi/jmxterm/releases/download/v1.0.0/jmxterm-1.0.0-uber.jar
root#504a7757e310:/# strace -f -e 'trace=execve,wait4' java -jar jmxterm-1.0.0-uber.jar
execve("/usr/local/openjdk-8/bin/java", ["java", "-jar", "jmxterm-1.0.0-uber.jar"], 0x7fffdcaebdd0 /* 10 vars */) = 0
...
[pid 310] execve("/bin/sh", ["sh", "-c", "stty -a < /dev/tty"], 0x7fff1f2a1cc8 /* 10 vars */) = 0
So, older jmxterm just uses /dev/tty instead of asking tty for the device name, and this works, as this device is present inside the container:
root#504a7757e310:/# ls -l /dev/tty
crw-rw-rw-. 1 root root 5, 0 Jun 3 21:36 /dev/tty
The huge difference between these versions of jmxterm is that newer tool version uses higher major version of jline, which is the library responsible for interaction with the terminal (akin to the readline in the C world). The difference between major jline versions leads to the difference in jmxterm's behavior, and current versions just rely on tty.
This observation leads us to the quick and dirty workaround which does not require neither updating Docker nor patching the jline/jmxterm tandem: we may just attach jmxterm's stdin to /dev/tty forcibly and thus make jline use this device (which is now referenced by /proc/self/fd/0) instead of the /dev/pts entry (which, formally, is not always correct, but is still enough for ad-hoc use):
root#0c4c614de0ee:/# java -jar jmxterm-1.0.2-uber.jar < /dev/tty
Welcome to JMX terminal. Type "help" for available commands.
$>bea<TAB>
bean beans
Now we have the autocompletion, history and other cool things we need to have.
If you are trying to run an interactive application (that needs tty) inside a docker container or a pod in kubernetes, then the following should work.
For docker-compose use:
image: image-name:2.0
container_name: container-name
restart: always
stdin_open: true
tty: true
For kubernetes use:
spec:
containers:
- name: web
image: web:latest
tty: true
stdin: true
On my mac I am running Windows Server 2016 in VMware. In there I am running Ubuntu in vagrant/Virtual Box. In there I am trying to run a django app in a docker container with nginx/uwsgi.
uwsgi is failing to start with:
[uWSGI] getting INI configuration from /opt/django/CAPgraph/uwsgi.ini
*** Starting uWSGI 2.0.15 (64bit) on [Thu Aug 17 20:01:23 2017] ***
compiled with version: 6.4.0 20170805 on 17 August 2017 06:10:50
os: Linux-3.13.0-128-generic #177-Ubuntu SMP Tue Aug 8 11:40:23 UTC 2017
nodename: 37db4344b5ae
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 1
current working directory: /
detected binary path: /usr/local/bin/uwsgi
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
chdir() to /opt/django/CAPgraph/
your memory page size is 4096 bytes
detected max file descriptor number: 524288
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
bind(): Operation not permitted [core/socket.c line 230]
In VMware the folder is set for sharing for everyone with write permission. That is mounted in the vagrant VM where it is 777, and in the docker container is it also 777. I can create files in the dir from all 3 places. But it seems uwsgi cannot create the socket.
I tried a short python script as a test from vagrant and that could not create a socket either:
vagrant#vagrant-ubuntu-trusty-64:/vagrant$ python -c "import socket as s; sock = s.socket(s.AF_UNIX); sock.bind('/vagrant/app.sock')"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 1] Operation not permitted
Anyone know how I can resolve this?
UPDATE: I changed the dir to /tmp where I can create a socket with my python script, but still uwsgi fails with the same error.
UPDATE 2: I created the socket in /tmp with my python script, chmod-ed it to 777 and still I get the same error from uwsgi.
Use any other folder other than /vagrant. I usually use /home/vagrant
The problem is that /vagrant is not same as a normal folder. If you execute the command mount | grep vagrant you will find it uses a vboxfs file system, which for some reason doesn't gel well with docker
I am trying to configure a Splash server with Docker in order to render javascript for scrapy.
I downloaded and installed Docker Toolbox (The latest version of Docker does not install on my Macbook pro 2009 due to lack of CPU MMU support).
I runned "docker run -p 5023:5023 -p 8050:8050 -p 8051:8051 scrapinghub/splash" in Docker Quickstart Terminal. The command performs but after "Starting factory..." I can not get my shell prompt back.
I tried to access http://localhost:8050/ in my browser and to ping localhost:8050 but this does not work: "This site can’t be reached". I would appreciate any help to understand what is the problem. Thank you!
## .
## ## ## ==
## ## ## ## ## ===
/"""""""""""""""""\___/ ===
~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~
\______ o __/
\ \ __/
\____\_______/
docker is configured to use the default machine with IP 192.168.99.100
For help getting started, check out the docs at https://docs.docker.com
Ordinateur:~ jb$ docker run -p 5023:5023 -p 8050:8050 -p 8051:8051 scrapinghub/splash
Unable to find image 'scrapinghub/splash:latest' locally
latest: Pulling from scrapinghub/splash
75c416ea735c: Pull complete
c6ff40b6d658: Pull complete
a7050fc1f338: Pull complete
f0ffb5cf6ba9: Pull complete
be232718519c: Pull complete
de1c9f88de34: Pull complete
0b8cdf21020f: Pull complete
cf35f91dcdb5: Pull complete
bfbc20b51f2f: Pull complete
f434ae0e9eb2: Pull complete
Digest: sha256:0a91eb2de229289b0c83f39d8bd079d2464a954001869417a5297aa60820af5b
Status: Downloaded newer image for scrapinghub/splash:latest
2017-07-26 10:45:59+0000 [-] Log opened.
2017-07-26 10:45:59.513146 [-] Splash version: 3.0
2017-07-26 10:45:59.515698 [-] Qt 5.9.1, PyQt 5.9, WebKit 602.1, sip 4.19.3, Twisted 16.1.1, Lua 5.2
2017-07-26 10:45:59.516027 [-] Python 3.5.2 (default, Nov 17 2016, 17:05:23) [GCC 5.4.0 20160609]
2017-07-26 10:45:59.516214 [-] Open files limit: 1048576
2017-07-26 10:45:59.516349 [-] Can't bump open files limit
2017-07-26 10:45:59.657299 [-] Xvfb is started: ['Xvfb', ':806019943', '-screen', '0', '1024x768x24', '-nolisten', 'tcp']
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
2017-07-26 10:45:59.992921 [-] proxy profiles support is enabled, proxy profiles path: /etc/splash/proxy-profiles
2017-07-26 10:46:00.273110 [-] verbosity=1
2017-07-26 10:46:00.273490 [-] slots=50
2017-07-26 10:46:00.275082 [-] argument_cache_max_entries=500
2017-07-26 10:46:00.276541 [-] Web UI: enabled, Lua: enabled (sandbox: enabled)
2017-07-26 10:46:00.278098 [-] Site starting on 8050
2017-07-26 10:46:00.278647 [-] Starting factory <twisted.web.server.Site object at 0x7f751d78ccf8>
If I restart docker and run "docker ps" I can see that the container is running:
Ordinateur:~ jb$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e2c23b576b88 scrapinghub/splash "python3 /app/bin/..." 2 hours ago Up 2 hours 0.0.0.0:5023->5023/tcp, 0.0.0.0:8050-8051->8050-8051/tcp gallant_feynman
Docker is available at address other than localhost. From your logs:
docker is configured to use the default machine with IP 192.168.99.100
Try accessing http://192.168.99.100:8050 instead of localhost. If you're using docker-machine, you can also get an ip address using docker-machine ip default command.
The server was running normally, I just had to replace localhost by my IP. Thank you!
The private registry was worked well based on docker 1.10.3,but I can not pull/push images after the docker updated to 1.12.0.
I had modified the /etc/sysconfig/docker as:
OPTIONS='--selinux-enabled=true --insecure-registry=myip:5000'
or
OPTIONS='--selinux-enabled=true --insecure-registry myip:5000'
but when I exec pull/push,I got this error:
$ docker pull myip:5000/cadvisor
Using default tag: latest
Error response from daemon: Get https://myip:5000/v1/_ping: http: server gave HTTP response to HTTPS client
when I change back docker to 1.10.3, it still work well as below:
$ docker pull myip:5000/cadvisor
Using default tag: latest
Trying to pull repository myip:5000/cadvisor ...
latest: Pulling from myip:5000/cadvisor
09d0220f4043: Pull complete
a3ed95caeb02: Pull complete
151807d34af9: Pull complete
14cd28dce332: Pull complete
Digest:
sha256:33b6475cd5b7646b3748097af1224de3eee3ba7cf5105524d95c0cf135f59b47
Status: Downloaded newer image for myip/cadvisor:latest
Some relative information are listed below:
docker version
Client:
Version: 1.12.0
API version: 1.24
Go version: go1.6.3
Git commit: 8eab29e
Built:
OS/Arch: linux/amd64
Server:
Version: 1.12.0
API version: 1.24
Go version: go1.6.3
Git commit: 8eab29e
Built:
OS/Arch: linux/amd64
docker info
Containers: 4
Running: 1
Paused: 0
Stopped: 3
Images: 241
Server Version: 1.12.0
Storage Driver: devicemapper
Pool Name: docker-253:0-6809-pool
Pool Blocksize: 65.54 kB
Base Device Size: 107.4 GB
Backing Filesystem: xfs
Data file: /dev/loop0
Metadata file: /dev/loop1
Data Space Used: 5.459 GB
Data Space Total: 107.4 GB
Data Space Available: 34.74 GB
Metadata Space Used: 9.912 MB
Metadata Space Total: 2.147 GB
Metadata Space Available: 2.138 GB
Thin Pool Minimum Free Space: 10.74 GB
Udev Sync Supported: true
Deferred Removal Enabled: false
Deferred Deletion Enabled: false
Deferred Deleted Device Count: 0
Data loop file: /var/lib/docker/devicemapper/devicemapper/data
WARNING: Usage of loopback devices is strongly discouraged for production use. Use '--storage-opt dm.thinpooldev' to specify a custom block storage device.
Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
Library Version: 1.02.107-RHEL7 (2016-06-09)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: host overlay null bridge
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-229.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 62.39 GiB
Name: server_3
ID: TITS:BL4B:M5FE:CIRO:5SW6:TVIV:HW36:J7OS:WLHF:46T6:2RBA:WCNV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 21
Goroutines: 32
System Time: 2016-08-02T10:33:06.414048675+08:00
EventsListeners: 0
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
127.0.0.0/8
docker exec <registry-container> registry -version
registry github.com/docker/distribution v2.2.1
After I restart the docker daemon in debug mode, the daemon logs when reproducing my problem are listed below:
DEBU[0794] Calling POST /v1.24/images/create?fromImage=10.10.10.40%3A5000%2Fcadvisor&tag=latest
DEBU[0794] hostDir: /etc/docker/certs.d/10.10.10.40:5000
DEBU[0794] hostDir: /etc/docker/certs.d/10.10.10.40:5000
DEBU[0794] Trying to pull 10.10.10.40:5000/cadvisor from https://10.10.10.40:5000 v2
WARN[0794] Error getting v2 registry: Get https://10.10.10.40:5000/v2/: http: server gave HTTP response to HTTPS client
ERRO[0794] Attempting next endpoint for pull after error: Get https://10.10.10.40:5000/v2/: http: server gave HTTP response to HTTPS client
DEBU[0794] Trying to pull 10.10.10.40:5000/cadvisor from https://10.10.10.40:5000 v1
DEBU[0794] hostDir: /etc/docker/certs.d/10.10.10.40:5000
DEBU[0794] attempting v1 ping for registry endpoint https://10.10.10.40:5000/v1/
DEBU[0794] Fallback from error: Get https://10.10.10.40:5000/v1/_ping: http: server gave HTTP response to HTTPS client
ERRO[0794] Attempting next endpoint for pull after error: Get https://10.10.10.40:5000/v1/_ping: http: server gave HTTP response to HTTPS client
ERRO[0794] Handler for POST /v1.24/images/create returned error: Get https://10.10.10.40:5000/v1/_ping: http: server gave HTTP response to HTTPS client
DEBU[1201] clean 2 unused exec commands
What's more, I just run a simple command to launch the private registry for test, anything else is by default:
docker run -d -p 5000:5000 --restart=always --name registry -v 'pwd'/data:/var/lib/registry registry:2
No proxy is configured. In summary, it is only a quiet sample environment for test.
I had the same issue.
This helped for me:
Create or modify /etc/docker/daemon.json on the client machine
{ "insecure-registries":["myregistry.example.com:5000"] }
Restart docker daemon
sudo /etc/init.d/docker restart
For Windows users
Add local registry here and apply:
For Mac Users:
Update the docker preferences using the (docker) icon in top bar
Preferences -> Daemon -> Insecure Registry [Click (+) sign] -> add :port
hit "Apply & Restart" button at bottom
I also had same issue and followed below steps:
1. Create file
vi /etc/docker/daemon.json
2. Add below content
{
"insecure-registries":["192.168.1.142:5000"]
}
3.Restart Docker
service docker restart
If you are using Windows and you get this error you need to create a file here: "C:\ProgramData\docker\config\daemon.json"
and do the same as #Bspec mentioned above:
{ "insecure-registries":["myregistry.example.com:5000"] }
Then restart docker using PowerShell commands:
Stop-Service docker
Start-Service docker
modifying "/etc/docker/daemon.json" didn't work for me.
Putting it under "/etc/sysconfig/docker" as below, worked.
INSECURE_REGISTRY="--insecure-registry 192.168.24.1:8787"
In order to push, add the ip to insecure registry on the client side (e.g. for Windows)
To pull, add it to the server side (in this case Ubuntu)
vim /etc/docker/daemon.json
and then restart Docker.
None of the solutions worked on Ubuntu 18.04 so spend some time to find the root cause.
Steps to solve an issue
sudo vi /lib/systemd/system/docker.service
# ExecStart=dockerd .... --insecure-registry=192.168.99.100:5000
sudo systemctl stop docker.service
sudo systemctl daemon-reload
sudo systemctl start docker.service
What was the issue?
I would recommend to check where exactly dockerd options are configured regardless of you Linux distribution with:
sudo find /etc /lib -name 'docker*' | while read -r line; do grep dockerd $line /dev/null; done
first test localy
docker push localhost:5000/<ImageName>
if docker pushed is Done going to another server and do it:
sudo nano /etc/docker/daemon.json
{"insecure-registries" : ["<HostName or IP Address registry server>:5000"]}
Saving and...
and for next
sudo systemctl daemon-reload
sudo service docker restart
nice!
now docker pushing on another server:
docker tag <image id> <HostName or IP Address registry server>:5000/<ImageName>
docker push <HostName or IP Address registry server>:5000/<ImageName>
Enjoy It.
System
OSX 10.9.5
Docker version 1.4.1, build 5bc2ff8
Image niallo/strider (latest) a51ba391459b
Goal
Setup a docker instance as per this guide
First attempt
I followed the guide steps, but when I ran the final image:
docker run -d -p 3000:3000 -p 27000:27017 -p 44:22 niallo/strider
I was not able to access the dashboard through localhost
Second attempt: boot2docker ip
I did some googling and found these OSX specific instructions. Including the boo2docker ip:
curl $(boot2docker ip 2> /dev/null):3000
This succeeds in getting the dashboard html.
Outstanding problem
However in the browser the html asset loads, but the front end assets scripts/app.js and styles/style.css are all broken links.
curl $(boot2docker ip 2> /dev/null):3000/styles/styles.css
Note: all the other assets are fine
Does anyone have any insight? I really wanna play with docker!
More details
Info
bash-3.2$ docker info
Containers: 9
Images: 29
Storage Driver: aufs
Root Dir: /mnt/sda1/var/lib/docker/aufs
Dirs: 47
Execution Driver: native-0.2
Kernel Version: 3.16.7-tinycore64
Operating System: Boot2Docker 1.4.1 (TCL 5.4); master : 86f7ec8 - Tue Dec 16 23:11:29 UTC 2014
CPUs: 4
Total Memory: 1.961 GiB
Name: boot2docker
ID: DA3Y:GVFJ:6NO7:FFNL:RNLW:2QXY:UV3F:YWAS:OBFF:42YG:LRU7:CBHV
Debug mode (server): true
Debug mode (client): false
Fds: 18
Goroutines: 17
EventsListeners: 0
Init Path: /usr/local/bin/docker
Docker Root Dir: /mnt/sda1/var/lib/docker
Processes
IMAGE COMMAND PORTS
niallo/strider:latest "/usr/bin/supervisor 0.0.0.0:44->22/tcp, 0.0.0.0:3000->3000/tcp, 0.0.0.0:27000->27017/tcp
All the docker links in tutorial you have linked are broken. I can't even find the source dockerfile for this build and hence don't recommend using it and can't really help you debug.
However, The Strider github page recommends using docker-strider image for running strider in docker. The instructions seem straight forward but you can ask another question on SO if you get stuck.