Where is Docker container real location in Windows 10? - windows

I recently installed Docker in Windows 10 (updated to Dec 2020). I can't find the real path of the container config. I need to change a container configuration.
It is not C:\ProgramData\Docker\\ nor C:\ProgramData\DockerDesktop\\.
I searched everywhere and I cannot find the config files.
Can you help me find them?

The configuration file might not exist but you can create it C:\ProgramData\Docker\config\daemon.json and add all the configurations that you need.
{
"authorization-plugins": [],
"dns": [],
"dns-opts": [],
"dns-search": [],
"exec-opts": [],
"storage-driver": "",
"storage-opts": [],
"labels": [],
"log-driver": "",
"mtu": 0,
"pidfile": "",
"data-root": "",
"cluster-store": "",
"cluster-advertise": "",
"debug": true,
"hosts": [],
"log-level": "",
"tlsverify": true,
"tlscacert": "",
"tlscert": "",
"tlskey": "",
"group": "",
"default-ulimits": {},
"bridge": "",
"fixed-cidr": "",
"raw-logs": false,
"registry-mirrors": [],
"insecure-registries": [],
"disable-legacy-registry": false
}
Worst case you can enter them from the Dashboard under the tab Docker Engine:
Resources:
https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon

As per two-years old post, something has changed.
Just in case someone is using Docker Engine v.20.10 like myself, it stores config files (config.json, daemon.json and features.json) under the path:
c:\Users\<user_name>\.docker\

Related

Ansible-semaphore not running tasks in the order that they were added to queue

I'm using ansible-semaphore API to handle playbook execution, when i call the start task endpoint:
start task endpoint
I need the tasks to run in the order they're added to the queue via API.
But apparently they are running in a random order:
tasks queue
In my settings I have set to only run one task at a time, which stopped it from running multiple tasks also in random order.
UI settings
In Semaphore's config.json I noticed the "concurrency_mode" setting:
{
"bolt": {
"host": "/home/ubuntu/semaphore.bolt",
},
"mysql": {
"host": "localhost",
"user": "root",
"pass": "*****",
"name": "semaphore",
"options": {}
},
"postgres": {
"host": "localhost",
"user": "postgres",
"pass": "*****",
"name": "semaphore",
"options": {}
},
"dialect": "postgres",
"port": "",
"interface": "",
"tmp_path": "/tmp/semaphore",
"cookie_hash": "*****",
"cookie_encryption": "*****",
"access_key_encryption": "*****",
"email_sender": "",
"email_host": "",
"email_port": "",
"web_host": "",
"ldap_binddn": "",
"ldap_bindpassword": "",
"ldap_server": "",
"ldap_searchdn": "",
"ldap_searchfilter": "",
"ldap_mappings": {
"dn": "",
"mail": "",
"uid": "",
"cn": ""
},
"telegram_chat": "",
"telegram_token": "",
"concurrency_mode": "",
"max_parallel_tasks": 0,
"email_alert": false,
"telegram_alert": false,
"slack_alert": false,
"ldap_enable": false,
"ldap_needtls": false
}
But the docs don't mention the options for this field:
Is it possible to run the queue in chronological order? What setting do I have to change?
I tried changing the "concurrency_mode" in the config.json to "false" with no results.
I also tried adding a few seconds delay between the tasks addition to queue, no results either.

How can new docker image have dependent child images

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

Description of all the attributes that are displayed in respose after opening REST based Ambari Services

Is there any link or reference where descriptions of all the attributes for Ambari Services are available?
I see many attributes like "component_name", "desired_stack_id", "stale_configs", "upgrade_state" and many others when I check the response from http://.....:8080/api/v1/clusters/....../hosts/...../host_components/HIVE_SERVER. I want to understand the significance of all these attributes.
"cluster_name": "",
"component_name": "HIVE_SERVER",
"desired_stack_id": "",
"desired_state": "STARTED",
"hdp_version": "",
"host_name": "",
"maintenance_state": "OFF",
"service_name": "HIVE",
"stack_id": "",
"stale_configs": false,
"state": "STARTED",
"upgrade_state": "NONE"
I see useful information around this at below link:
https://github.com/apache/ambari/blob/trunk/ambari-server/docs/api/v1/index.md

Sublime FTP/SFTP

I am trying to connect to my cpanel server using sublime text 3.
Server is added successfully. And remote path is also validated successfully.
But when try to Sync Remote->Local it is just not happening.
{
// The tab key will cycle through the settings when first created
// Visit http://wbond.net/sublime_packages/sftp/settings for help
// sftp, ftp or ftps
"type": "ftp",
"save_before_upload": true,
"upload_on_save": true,
"sync_down_on_open": false,
"sync_skip_deletes": false,
"sync_same_age": true,
"confirm_downloads": false,
"confirm_sync": true,
"confirm_overwrite_newer": false,
"host": "XXXXXX",
"user": "XXXXX",
"password": "XXXXXXX",
"port": "21",
"remote_path": "XXXXXX",
"ignore_regexes": [
"\\.sublime-(project|workspace)", "sftp-config(-alt\\d?)?\\.json",
"sftp-settings\\.json", "/venv/", "\\.svn/", "\\.hg/", "\\.git/",
"\\.bzr", "_darcs", "CVS", "\\.DS_Store", "Thumbs\\.db", "desktop\\.ini"
],
//"file_permissions": "664",
//"dir_permissions": "775",
//"extra_list_connections": 0,
"connect_timeout": 30,
//"keepalive": 120,
//"ftp_passive_mode": true,
//"ftp_obey_passive_host": false,
//"ssh_key_file": "~/.ssh/id_rsa",
//"sftp_flags": ["-F", "/path/to/ssh_config"],
//"preserve_modification_times": false,
//"remote_time_offset_in_hours": 0,
//"remote_encoding": "utf-8",
//"remote_locale": "C",
//"allow_config_upload": false,
}
And in the console I finally got this:
"Select via quick panel? No".
And the process got terminated by itself.
SFTP has some options for that to put on your sftp-config.json file at the root of your folder :
Set those values like this:
"confirm_downloads":false,
"confirm_sync":false,
"confirm_overwrite_newer":true

What's the container of a base docker image?

I am learning to use docker. I know that each docker image is build on a base image which doesn't have a parent.
Then from a base image, we can customize some stuff via containers (maybe a very short life container) to commit a new image.
So I understand that the process is like this: base image -> container -> new image 1 -> container -> new image 2
However, I inspect the json data of the base image. I still can see that it has a container's information:
[{
"Architecture": "amd64",
"Author": "",
"Comment": "",
"Config": {
"AttachStderr": false,
"AttachStdin": false,
"AttachStdout": false,
"Cmd": null,
"CpuShares": 0,
"Cpuset": "",
"Domainname": "",
"Entrypoint": null,
"Env": null,
"ExposedPorts": null,
"Hostname": "3f37dbc61890",
"Image": "",
"Labels": null,
"MacAddress": "",
"Memory": 0,
"MemorySwap": 0,
"NetworkDisabled": false,
"OnBuild": null,
"OpenStdin": false,
"PortSpecs": null,
"StdinOnce": false,
"Tty": false,
"User": "",
"Volumes": null,
"WorkingDir": ""
},
"Container": "3f37dbc61890b0bb37cc8479db94602bcc2d6e177d76c0f3d7d53346c0dc580c",
"ContainerConfig": {
"AttachStderr": false,
"AttachStdin": false,
"AttachStdout": false,
"Cmd": [
"/bin/sh",
"-c",
"#(nop) ADD file:777fad733fc954c0c161670c48c10ea1787a6e5d544daa20e55d593279df3fa3 in /"
],
"CpuShares": 0,
"Cpuset": "",
"Domainname": "",
"Entrypoint": null,
"Env": null,
"ExposedPorts": null,
"Hostname": "3f37dbc61890",
"Image": "",
"Labels": null,
"MacAddress": "",
"Memory": 0,
"MemorySwap": 0,
"NetworkDisabled": false,
"OnBuild": null,
"OpenStdin": false,
"PortSpecs": null,
"StdinOnce": false,
"Tty": false,
"User": "",
"Volumes": null,
"WorkingDir": ""
},
"Created": "2015-04-21T22:18:45.67739694Z",
"DockerVersion": "1.6.0",
"Id": "706766fe101906a1a6628173c2677173a5f8c6c469075083f3cf3a8f5e5eb367",
"Os": "linux",
"Parent": "",
"Size": 188104128,
"VirtualSize": 188104128
}]
3f37dbc61890b0bb37cc8479db94602bcc2d6e177d76c0f3d7d53346c0dc580c is
the container id of the base image.
what is a container of a base image? I feel like it becomes the hostname.
What is the hostname actually?
I'm not sure of your terminology. If a base image is by definition an image that has no parent, then the image in your example is not a base image.
But an image may have no parent. scratch, for example, has no parent:
$ docker inspect -f '{{.Container}}' ubuntu
a4c15f8c80978475a53f96721f935de5823bc8c29aff14eb00a15f9b9d96cddd
$ docker inspect -f '{{.Container}}' scratch
$
You can also create an image that has no parent using import:
$ echo hello world > foo && tar -cf- foo | docker import -
3e8fc0cb69fae0bd3f9711031df6d3b7bf6a7e8c9745657d9261e7b803718c67
$ docker inspect -f '{{.Container}}' 3e8fc0c
$
Unlike scratch, this image may have files in it. In fact, you can flatten a complex image using this technique.
$ docker create ubuntu # create container from image
6b90bf145c193ef8e4ecb789372d2fd619769a20d96c8f3f586dcfbc501b0611
$ docker export 6b90bf1 > ubuntu.tar # export container fs to tarball
$ docker import - flat_ubuntu < ubuntu.tar
4ef4ffb9514212acf6a19b2eeda8855b8c0445924311043ba5cba6574d40d772
$ docker inspect -f '{{.Container}}' 4ef4ffb
$
It's important to note that while this new image has the exact same files as the original image, it doesn't have the other docker features like environment, volume, entrypoint, etc.
I would not necessarily call this a "base" image. I would call it a "flat" image. I would say a base image is the image you indicate in a Dockerfile FROM directive. In my terminology a base image need not be flat.

Resources