I have used Docker on a Linux machine and just started using it on Windows too.
I am on a unfortunate location where they use 172.17.0.0/16 subnet that conflicts with default Docker bridge subnet.
C:\>docker network inspect bridge
[
{
"Name": "bridge",
"Id": "d6ae8949e4e098ad4443ba2cd72bed5f9f96d81f5d2d00197b9443b8a8c1d1f6"
,
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16"
}
]
},
"Internal": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
I know there is an option for Linux (https://docs.docker.com/engine/reference/commandline/dockerd/ bip) to change this. But is there also an option for Windows?
PS. I have tried adding "bip": "10.11.12.0/24" to JSON Daemon configuration but Docker crashes on startup:
Related
I am new to Docker and want to understand image management better. A new image that I just created using
docker image build -t jefe/mh_db:v.1.1.0 ./
When I try to delete using
docker image rm d4c0c9225252
where d4c0c9225252 is the Image ID, returns
Error response from daemon: conflict: unable to delete d4c0c9225252 (cannot be forced) - image has dependent child images
Yes it's related to other posts regarding cannot delete. But I want to understand why a dependency exists.
How can this child image have images that are dependent upon it? I literally just created it
The dockerfile that is used in building the image
FROM mysql:5.7.27
MAINTAINER jefe
# Specify ports
EXPOSE 3306
Update
docker image ls | grep d4c0c9225252
jefe/mh_db v.1.1.0 d4c0c9225252 2 hours ago 373MB
Additionally
docker inspect d4c0c9225252
[
{
"Id": "sha256:d4c0c922525201d62e49ac73d03e27653e77e2ac5e3f11334a7a09d7c6d977fe",
"RepoTags": [
"jefe/mh_db:v.1.1.0"
],
"RepoDigests": [],
"Parent": "sha256:b0fead29523e498fd0f990abcc2b2bbb46952ad3361fbebcc304e31be69bd840",
"Comment": "",
"Created": "2019-08-08T15:24:57.324861036Z",
"Container": "6abc71375823faeb4819720a09ae348b0da4d9ae213c167c3911ca706d7c8b92",
"ContainerConfig": {
"Hostname": "6abc71375823",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": {
"3306/tcp": {},
"33060/tcp": {}
},
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"GOSU_VERSION=1.7",
"MYSQL_MAJOR=5.7",
"MYSQL_VERSION=5.7.27-1debian9"
],
"Cmd": [
"/bin/sh",
"-c",
"#(nop) ",
"EXPOSE 3306"
],
"ArgsEscaped": true,
"Image": "sha256:b0fead29523e498fd0f990abcc2b2bbb46952ad3361fbebcc304e31be69bd840",
"Volumes": {
"/var/lib/mysql": {}
},
"WorkingDir": "",
"Entrypoint": [
"docker-entrypoint.sh"
],
"OnBuild": null,
"Labels": {}
},
"DockerVersion": "19.03.1",
"Author": "jefe",
"Config": {
"Hostname": "",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": {
"3306/tcp": {},
"33060/tcp": {}
},
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"GOSU_VERSION=1.7",
"MYSQL_MAJOR=5.7",
"MYSQL_VERSION=5.7.27-1debian9"
],
"Cmd": [
"mysqld"
],
"ArgsEscaped": true,
"Image": "sha256:b0fead29523e498fd0f990abcc2b2bbb46952ad3361fbebcc304e31be69bd840",
"Volumes": {
"/var/lib/mysql": {}
},
"WorkingDir": "",
"Entrypoint": [
"docker-entrypoint.sh"
],
"OnBuild": null,
"Labels": null
},
"Architecture": "amd64",
"Os": "linux",
"Size": 373273403,
"VirtualSize": 373273403,
"GraphDriver": {
"Data": {
"LowerDir": "/var/lib/docker/overlay2/11891a42dc63fb6851e3fb12a1dd7e7285d18df83ecfd1f5aa40e44466921c58/diff:/var/lib/docker/overlay2/e0c695335789cba5a8e6524804bd1c2d1836db16650105e6863e7023bc289753/diff:/var/lib/docker/overlay2/2b4e10627f78a0185f8975b62b954a14e79fc6fb71a3caae07180e8e00f51b44/diff:/var/lib/docker/overlay2/f9dd057675e39a3eab99143f07bcb7df8a44eba5d1f1d15e567471a7c3a9e491/diff:/var/lib/docker/overlay2/c28612d7a8d1b187ddb7fc995c5fe733e0c18def13df798f1de5af2bdac9d3f4/diff:/var/lib/docker/overlay2/f8e41886d7ae8d8939ae2dc11b4ff941ef931aa18bc2f8cb0f724cc9e270ab3c/diff:/var/lib/docker/overlay2/8796390ee625b42b56d7822d128cc50bf88fbfd1f7f5ac9e7ecda9e721944946/diff:/var/lib/docker/overlay2/86552fa54367c794979383dbba257f1292f2a137dae0304d1eb036ba2249bc7b/diff:/var/lib/docker/overlay2/168353bdf70d8140026c2cf58da64eee7409f710832be601dad3e0cc6a02c01a/diff:/var/lib/docker/overlay2/ac908915344e5f65df6e0121f77bd48fdaa822974317cdb83a59f0618893ddb2/diff",
"MergedDir": "/var/lib/docker/overlay2/1826972009d9ce18265129a2d4928b708bf6780370530e4c1be8b1efd096b2cd/merged",
"UpperDir": "/var/lib/docker/overlay2/1826972009d9ce18265129a2d4928b708bf6780370530e4c1be8b1efd096b2cd/diff",
"WorkDir": "/var/lib/docker/overlay2/1826972009d9ce18265129a2d4928b708bf6780370530e4c1be8b1efd096b2cd/work"
},
"Name": "overlay2"
},
"RootFS": {
"Type": "layers",
"Layers": [
"sha256:d56055da3352f918f4d8a42350385ea5b10d0906e746a8fbb4b850f9284deee5",
"sha256:b78ec9586b345b0efdb0297261c0044652563045a28a7cc6d27dd314eda1e0eb",
"sha256:c6926fcee1912ebb41215a70b1d0ed77e3b8db38cfe69b936d18b346096e144c",
"sha256:007a7f930352c0fd98663021fb1ee08768462eb5bc9045342da9e9f73fd79a7f",
"sha256:2f1b41b24201f4ae635819b1d7717ab04c000f04e7708de3bb012a60d3ef630b",
"sha256:77737de99484a6e2e2ae4bea0cf7ec4d3063827a6dd49a243694ef00929350d2",
"sha256:7e7fffcdabb3e0655bf46756dd04018ce051f81fbaba8bff3703ac987def88be",
"sha256:83bba64580292cc5af1fd3cabb74b18c143e05cd45d882c9e09edc8ff79a1119",
"sha256:94f63a189eef2bdb32668faa0ce08dc5da01eccb91ad548f28052048e810e5f8",
"sha256:0c3e10ddbe75e0a4efcee6aa06716b651227ceb358e78922b9fe9ea7f5a63992",
"sha256:5572431ce4dea5defe6a0d0586ad3b25a74d59bfbbb05c2a257c5d71a27eba4c"
]
},
"Metadata": {
"LastTagTime": "2019-08-08T15:24:57.393863976Z"
}
}
Docker wont let you delete an image if you have more than one tag on it. To find out the tags you can filter the output of docker image ls
docker image ls | grep d4c0c9225252
Newbie to Microservices here.
I have been looking into develop a microservice with spring actuator while having Consul for service discovery and fail recovery.
I have configured a cluster as explained in Consul documentation.
Now what I'm trying to do is configure a Consul Watch to trigger when any of my service is down and execute a shell script to restart my service. Following is my configuration file.
{
"bind_addr": "127.0.0.1",
"datacenter": "dc1",
"encrypt": "EXz7LsrhpQ4idwqffiFoQ==",
"data_dir": "/data",
"log_level": "INFO",
"enable_syslog": true,
"enable_debug": true,
"enable_script_checks": true,
"ui":true,
"node_name": "SpringConsulClient",
"server": false,
"service": { "name": "Apache", "tags": ["HTTP"], "port": 8080,
"check": {"script": "curl localhost >/dev/null 2>&1", "interval": "10s"}},
"rejoin_after_leave": true,
"watches": [
{
"type": "service",
"handler": "/Consul-Script.sh"
}
]
}
Any help/tip would be greatly appreciate.
Regards,
Chrishan
Take a closer look at the description of the service watch type in the official documentation. It has an example, how you can specify it:
{
"type": "service",
"service": "redis",
"args": ["/usr/bin/my-service-handler.sh", "-redis"]
}
Note that it has no property handler and but takes a path to the script as an argument. And one more:
It requires the "service" parameter
It seems, in you case you need to specify it as follows:
"watches": [
{
"type": "service",
"service": "Apache",
"args": ["/fully/qualified/path/to/Consul-Script.sh"]
}
]
I installed DC/OS with 3 masters and 3 agents and face a problem with virtual networking. Here is my Marathon app spec:
{
"id": "/nginx",
"cmd": null,
"cpus": 1,
"mem": 128,
"disk": 0,
"instances": 1,
"container": {
"type": "DOCKER",
"volumes": [],
"docker": {
"image": "nginx",
"network": "BRIDGE",
"portMappings": [
{
"containerPort": 80,
"hostPort": 0,
"servicePort": 10002,
"protocol": "tcp",
"name": "main1",
"labels": {
"VIP_0": "9.0.0.0:34562"
}
}
],
"privileged": false,
"parameters": [],
"forcePullImage": false
}
},
"portDefinitions": [
{
"port": 10002,
"protocol": "tcp",
"labels": {}
}
]
}
I see the following in the DC/OS virtual network section:
VIRTUAL NETWORK NAME | SUBNET | AGENT PREFIX LENGTH
dcos 9.0.0.0/8 24
The containers stays in waiting for a long time. If I remove the port mapping section it runs successfully.
Basically I need to know how to work with this new virtual network, and fix the service discovery and load balancing without using any extra stuff.
Took me some time to figure it out as well...
You need to:
Remove all ports assignment in the task definition
Describe the name of the network to attach to (default network created is named "dcos")
{
"id": "yourtask",
"container": {
"type": "DOCKER",
"docker": {
"image": "your/image",
"network": "USER"
}
},
"acceptedResourceRoles" : [
"slave_public"
],
"ipAddress": {
"networkName": "dcos"
},
"instances": 2,
"cpus": 0.2,
"mem": 128
}
I am trying to run a Consul container on each of my Mesos slave node.
With Marathon I have the following JSON script:
{
"id": "consul-agent",
"instances": 10,
"constraints": [["hostname", "UNIQUE"]],
"container": {
"type": "DOCKER",
"docker": {
"image": "consul",
"privileged": true,
"network": "HOST"
}
},
"args": ["agent","-bind","$MESOS_SLAVE_IP","-retry-join","$MESOS_MASTER_IP"]
}
However, it seems that marathon treats the args as plain text.
That's why I always got errors:
==> Starting Consul agent...
==> Error starting agent: Failed to start Consul client: Failed to start lan serf: Failed to create memberlist: Failed to parse advertise address!
So I just wonder if there are any workaround so that I can start a Consul container on each of my Mesos slave node.
Update:
Thanks #janisz for the link.
After taking a look at the following discussions:
#3416: args in marathon file does not resolve env variables
#2679: Ability to specify the value of the hostname an app task is running on
#1328: Specify environment variables in the config to be used on each host through REST API
#1828: Support for more variables and variable expansion in app definition
as well as the Marathon documentation on Task Environment Variables.
My understanding is that:
Currently it is not possible to pass environment variables in args
Some post indicates that one could pass environment variables in "cmd". But those environment variables are Task Environment Variables provided by Marathon, not the environment variables on your host machine.
Please correct if I was wrong.
You can try this.
{
"id": "consul-agent",
"instances": 10,
"constraints": [["hostname", "UNIQUE"]],
"container": {
"type": "DOCKER",
"docker": {
"image": "consul",
"privileged": true,
"network": "HOST",
"parameters": [
"key": "env",
"value": "YOUR_ENV_VAR=VALUE"
]
}
}
}
Or
{
"id": "consul-agent",
"instances": 10,
"constraints": [["hostname", "UNIQUE"]],
"container": {
"type": "DOCKER",
"docker": {
"image": "consul",
"privileged": true,
"network": "HOST"
}
},
"env": {
"ENV_NAME" : "VALUE"
}
}
I made an application Dockerized in a Docker container. I intended to make the application able to access files from our HDFS. The Docker image is to be deployed on the same cluster where we have HDFS installed via Marathon-Mesos.
Below is the json to be POST to Marathon. It seems that my app is able to read and write files in the HDFS. Can someone comment on the safety of this? Would files changed by my app correctly changed in the HDFS as well? I Googled around and didn't find any similar approaches...
{
"id": "/ipython-test",
"cmd": null,
"cpus": 1,
"mem": 1024,
"disk": 0,
"instances": 1,
"container": {
"type": "DOCKER",
"volumes": [
{
"containerPath": "/home",
"hostPath": "/hadoop/hdfs-mount",
"mode": "RW"
}
],
"docker": {
"image": "my/image",
"network": "BRIDGE",
"portMappings": [
{
"containerPort": 8888,
"hostPort": 0,
"servicePort": 10061,
"protocol": "tcp",
}
],
"privileged": false,
"parameters": [],
"forcePullImage": true
}
},
"portDefinitions": [
{
"port": 10061,
"protocol": "tcp",
"labels": {}
}
]
}
You might have a look at the Docker volume docs.
Basically, the volumes definition in the app.json would trigger the start of the Docker image with the flag -v /hadoop/hdfs-mount:/home:RW, meaning that the host path gets mapped to the Docker container as /home in read-write mode.
You should be able to verify this if you SSH into the node which is running the app and do a docker inspect <containerId>.
See also
https://mesosphere.github.io/marathon/docs/native-docker.html