docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Reworking glossary to a table and removing left-side ToC (#1387) (#9769) 

* Reworking glossary to a table and removing left-side ToC

Signed-off-by: Adrian Plata <adrian.plata@docker.com>

* modifying CSS

* Fixing desktop links.

* Fixing swarm mode links.
This commit is contained in:
Adrian Plata 2019-10-30 13:15:39 -07:00 committed by GitHub
parent 1474fb5fb6
commit a1875f4d56
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 103 additions and 84 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

127
_data/glossary.yaml
View File

@ -1,39 +1,41 @@
amd64: |
<h3>Term</h3>: |
<h3>Definition</h3>
<a class="glossary" name="amd64">amd64</a>: |
AMD64 is AMD's 64-bit extension of Intel's x86 architecture, and is also
referred to as x86_64 (or x86-64).
aufs: |
<a class="glossary" name="aufs">aufs</a>: |
aufs (advanced multi layered unification filesystem) is a Linux [filesystem](#filesystem) that
Docker supports as a storage backend. It implements the
[union mount](http://en.wikipedia.org/wiki/Union_mount) for Linux file systems.
base image: |
<a class="glossary" name="base_image">base image</a>: |
A **base image** has no parent image specified in its Dockerfile. It is created
using a Dockerfile with the `FROM scratch` directive.
boot2docker: |
<a class="glossary" name="boot2docker">boot2docker</a>: |
[boot2docker](http://boot2docker.io/) is a lightweight Linux distribution made
specifically to run Docker containers. The boot2docker management tool for Mac
and Windows was deprecated and replaced by [`docker-machine`](#machine) which
you can install with the Docker Toolbox.
btrfs: |
<a class="glossary" name="btrfs">btrfs</a>: |
btrfs (B-tree file system) is a Linux [filesystem](#filesystem) that Docker
supports as a storage backend. It is a [copy-on-write](http://en.wikipedia.org/wiki/Copy-on-write)
filesystem.
build: |
<a class="glossary" name="build">build</a>: |
build is the process of building Docker images using a [Dockerfile](#dockerfile).
The build uses a Dockerfile and a "context". The context is the set of files in the
directory in which the image is built.
cgroups: |
<a class="glossary" name="cgroups">cgroups</a>: |
cgroups is a Linux kernel feature that limits, accounts for, and isolates
the resource usage (CPU, memory, disk I/O, network, etc.) of a collection
of processes. Docker relies on cgroups to control and isolate resource limits.
*Also known as : control groups*
cluster: |
<a class="glossary" name="cluster">cluster</a>: |
A cluster is a group of machines that work together to run workloads and provide high availability.
collection: |
<a class="glossary" name="collection">collection</a>: |
A collection is a group of swarm resources that Docker Engine - Enterprise uses for role-based
access control. Collections enable organizing permissions for resources like
nodes, services, containers, volumes, networks, and secrets. [Learn how to manage collections](/datacenter/ucp/2.2/guides/access-control/manage-access-with-collections/).
Compose: |
<a class="glossary" name="compose">Compose</a>: |
[Compose](https://github.com/docker/compose) is a tool for defining and
running complex applications with Docker. With Compose, you define a
multi-container application in a single file, then spin your
@ -41,10 +43,10 @@ Compose: |
be done to get it running.
*Also known as : docker-compose, fig*
copy-on-write: |
<a class="glossary" name="copy-on-write">copy-on-write</a>: |
Docker uses a
[copy-on-write](/engine/userguide/storagedriver/imagesandcontainers/#/the-copy-on-write-strategy)
technique and a [union file system](#union file system) for both images and
technique and a [union file system](#union_file_system) for both images and
containers to optimize resources and speed performance. Multiple copies of an
entity share the same instance and each one makes only specific changes to its
unique layer.
@ -61,7 +63,7 @@ copy-on-write: |
For more about copy-on-write in the context of Docker, see [Understand images,
containers, and storage
drivers](/engine/userguide/storagedriver/imagesandcontainers/).
container: |
<a class="glossary" name="container">container</a>: |
A container is a runtime instance of a [docker image](#image).
A Docker container consists of
@ -72,19 +74,19 @@ container: |
The concept is borrowed from Shipping Containers, which define a standard to ship
goods globally. Docker defines a standard to ship software.
Docker: |
<a class="glossary" name="docker">Docker</a>: |
The term Docker can refer to
- The Docker project as a whole, which is a platform for developers and sysadmins to
develop, ship, and run applications
- The docker daemon process running on the host which manages images and containers
(also called Docker Engine)
Docker Enterprise: |
<a class="glossary" name="docker_enterprise">Docker Enterprise</a>: |
Docker Enterprise is a platform to build, ship, and run
containerized applications, that you can deploy in the cloud or on-premise. It
includes a tested and certified version of Docker, web UIs for managing
your app resources, and support.
Docker Desktop for Mac: |
<a class="glossary" name="docker_desktop_for_mac">Docker Desktop for Mac</a>: |
[Docker Desktop for Mac](/docker-for-mac/) is an easy-to-install, lightweight
Docker development environment designed specifically for the Mac. A native
Mac application, Docker Desktop for Mac uses the macOS Hypervisor
@ -92,7 +94,7 @@ Docker Desktop for Mac: |
to build, debug, test, package, and ship Dockerized applications on a
Mac. Docker Desktop for Mac supersedes [Docker Toolbox](#toolbox) as
state-of-the-art Docker on macOS.
Docker Desktop for Windows: |
<a class="glossary" name="docker_desktop_for_windows">Docker Desktop for Windows</a>: |
[Docker Desktop for Windows](/docker-for-windows/) is an
easy-to-install, lightweight Docker development environment designed
specifically for Windows 10 systems that support Microsoft Hyper-V
@ -103,7 +105,7 @@ Docker Desktop for Windows: |
for Windows is the best solution if you want to build, debug, test, package, and
ship Dockerized applications from Windows machines. Docker Desktop for Windows
supersedes [Docker Toolbox](#toolbox) as state-of-the-art Docker on Windows.
Docker Hub: |
<a class="glossary" name="docker_hub">Docker Hub</a>: |
The [Docker Hub](https://hub.docker.com/) is a centralized resource for working with
Docker and its components. It provides the following services:
@ -111,11 +113,11 @@ Docker Hub: |
- User authentication
- Automated image builds and work-flow tools such as build triggers and web hooks
- Integration with GitHub and Bitbucket
Dockerfile: |
<a class="glossary" name="dockerfile">Dockerfile</a>: |
A Dockerfile is a text document that contains all the commands you would
normally execute manually in order to build a Docker image. Docker can
build images automatically by reading the instructions from a Dockerfile.
ENTRYPOINT: |
<a class="glossary" name="entrypoint">ENTRYPOINT</a>: |
In a Dockerfile, an `ENTRYPOINT` is an optional definition for the first part
of the command to be run. If you want your Dockerfile to be runnable without
specifying additional arguments to the `docker run` command, you must specify
@ -144,7 +146,7 @@ ENTRYPOINT: |
In practice, `ENTRYPOINT` is not often overridden. However, specifying the
`ENTRYPOINT` can make your images more flexible and easier to reuse.
filesystem: |
<a class="glossary" name="filesystem">filesystem</a>: |
A file system is the method an operating system uses to name files
and assign them locations for efficient storage and retrieval.
@ -153,107 +155,112 @@ filesystem: |
- Linux : ext4, aufs, btrfs, zfs
- Windows : NTFS
- macOS : HFS+
grant: |
<a class="glossary" name="grant">grant</a>: |
A grant enables role-based access control for managing how users and
organizations access Docker Engine - Enterprise swarm resources. A grant is made up of a
subject, a role, and a collection. For more about grants and role-based access
control, see [Grant permissions to users based on roles](/datacenter/ucp/2.2/guides/access-control/grant-permissions/).
image: |
<a class="glossary" name="image">image</a>: |
Docker images are the basis of [containers](#container). An Image is an
ordered collection of root filesystem changes and the corresponding
execution parameters for use within a container runtime. An image typically
contains a union of layered filesystems stacked on top of each other. An image
does not have state and it never changes.
Kitematic: |
<a class="glossary" name="kitematic">Kitematic</a>: |
A legacy GUI, bundled with [Docker Toolbox](#toolbox), for managing Docker
containers. We recommend upgrading to [Docker Desktop for Mac](#docker for Mac) or
[Docker Desktop for Windows](#docker for Windows), which have superseded Kitematic.
layer: |
containers. We recommend upgrading to [Docker Desktop for Mac](#docker_desktop_for_mac)
or [Docker Desktop for Windows](#docker_desktop_for_windows), which have
superseded Kitematic.
<a class="glossary" name="layer">layer</a>: |
In an image, a layer is modification to the image, represented by an instruction in the
Dockerfile. Layers are applied in sequence to the base image to create the final image.
When an image is updated or rebuilt, only layers that change need to be updated, and
unchanged layers are cached locally. This is part of why Docker images are so fast
and lightweight. The sizes of each layer add up to equal the size of the final image.
libcontainer: |
<a class="glossary" name="libcontainer">libcontainer</a>: |
libcontainer provides a native Go implementation for creating containers with
namespaces, cgroups, capabilities, and filesystem access controls. It allows
you to manage the lifecycle of the container performing additional operations
after the container is created.
libnetwork: |
<a class="glossary" name="libnetwork">libnetwork</a>: |
libnetwork provides a native Go implementation for creating and managing container
network namespaces and other network resources. It manages the networking lifecycle
of the container performing additional operations after the container is created.
link: |
<a class="glossary" name="link">link</a>: |
links provide a legacy interface to connect Docker containers running on the
same host to each other without exposing the hosts' network ports. Use the
Docker networks feature instead.
Machine: |
<a class="glossary" name="machine">Machine</a>: |
[Machine](https://github.com/docker/machine) is a Docker tool which
makes it really easy to create Docker hosts on your computer, on
cloud providers and inside your own data center. It creates servers,
installs Docker on them, then configures the Docker client to talk to them.
*Also known as : docker-machine*
namespace: |
<a class="glossary" name="namespace">namespace</a>: |
A [Linux namespace](http://man7.org/linux/man-pages/man7/namespaces.7.html)
is a Linux kernel feature that isolates and virtualizes system resources. Processes which restricted to
a namespace can only interact with resources or processes that are part of the same namespace. Namespaces
a class="glossary" namespace can only interact with resources or processes that are part of the same namespace. Namespaces
are an important part of Docker's isolation model. Namespaces exist for each type of
resource, including `net` (networking), `mnt` (storage), `pid` (processes), `uts` (hostname control),
and `user` (UID mapping). For more information about namespaces, see [Docker run reference](/engine/reference/run/)
and [Introduction to user namespaces](https://success.docker.com/KBase/Introduction_to_User_Namespaces_in_Docker_Engine).
node: |
<a class="glossary" name="node">node</a>: |
A [node](/engine/swarm/how-swarm-mode-works/nodes/) is a physical or virtual
machine running an instance of the Docker Engine in swarm mode.
machine running an instance of the Docker Engine in [swarm mode](#swarm_mode).
**Manager nodes** perform swarm management and orchestration duties. By default
manager nodes are also worker nodes.
**Worker nodes** execute tasks.
overlay network driver: |
<a class="glossary" name="overlay_network_driver">overlay network driver</a>: |
Overlay network driver provides out of the box multi-host network connectivity
for docker containers in a cluster.
overlay storage driver: |
<a class="glossary" name="overlay_storage_driver">overlay storage driver</a>: |
OverlayFS is a [filesystem](#filesystem) service for Linux which implements a
[union mount](http://en.wikipedia.org/wiki/Union_mount) for other file systems.
It is supported by the Docker daemon as a storage driver.
parent image: |
<a class="glossary" name="parent_image">parent image</a>: |
An image's **parent image** is the image designated in the `FROM` directive
in the image's Dockerfile. All subsequent commands are based on this parent
image. A Dockerfile with the `FROM scratch` directive uses no parent image, and creates
a **base image**.
persistent storage: |
Persistent storage or volume storage provides a way for a user to add a persistent layer to the running container's file system. This persistent layer could live on the container host or an external device. The lifecycle of this persistent layer is not connected to the lifecycle of the container, allowing a user to retain state.
registry: |
<a class="glossary" name="persistent_storage">persistent storage</a>: |
Persistent storage or volume storage provides a way for a user to add a
persistent layer to the running container's file system. This persistent layer
could live on the container host or an external device. The lifecycle of this
persistent layer is not connected to the lifecycle of the container, allowing
a user to retain state.
<a class="glossary" name="registry">registry</a>: |
A Registry is a hosted service containing [repositories](#repository) of [images](#image)
which responds to the Registry API.
The default registry can be accessed using a browser at [Docker Hub](#docker hub)
or using the `docker search` command.
repository: |
<a class="glossary" name="repository">repository</a>: |
A repository is a set of Docker images. A repository can be shared by pushing it
to a [registry](#registry) server. The different images in the repository can be
labeled using [tags](#tag).
Here is an example of the shared [nginx repository](https://hub.docker.com/_/nginx/)
and its [tags](https://hub.docker.com/r/library/nginx/tags/).
role: |
<a class="glossary" name="role">role</a>: |
A role is a set of permitted API operations on a collection of Docker Engine - Enterprise swarm
resources. As part of a grant, a role is assigned to a subject (a user, team, or
organization) and a collection. For more about roles, see [Roles and
permission levels](/datacenter/ucp/2.2/guides/access-control/permission-levels/).
role-based access control: |
<a class="glossary" name="role-based_access_control">role-based access control</a>: |
Role-based access control enables managing how Docker Engine - Enterprise users can access
swarm resources. UCP administrators create grants to control how users access
resource collections. A grant is made up of a subject, a role, and a collection.
A grant defines who (subject) has how much access (role) to a set of resources
(collection). For more about role-based access control, see
[Authentication](/datacenter/ucp/2.2/guides/access-control/).
SSH: |
<a class="glossary" name="SSH">SSH</a>: |
SSH (secure shell) is a secure protocol for accessing remote machines and applications.
It provides authentication and encrypts data communication over insecure networks such
as the Internet. SSH uses public/private key pairs to authenticate logins.
service: |
<a class="glossary" name="service">service</a>: |
A [service](/engine/swarm/how-swarm-mode-works/services/) is the definition of how
you want to run your application containers in a swarm. At the most basic level
a service defines which container image to run in the swarm and which commands
@ -265,7 +272,7 @@ service: |
application. Examples of services might include an HTTP server, a database, or
any other type of executable program that you wish to run in a distributed
environment.
service discovery: |
<a class="glossary" name="service_discovery">service discovery</a>: |
Swarm mode [service discovery](/engine/swarm/networking/#use-swarm-mode-service-discovery) is a DNS component
internal to the swarm that automatically assigns each service on an overlay
network in the swarm a VIP and DNS entry. Containers on the network share DNS
@ -275,14 +282,14 @@ service discovery: |
You don’t need to expose service-specific ports to make the service available to
other services on the same overlay network. The swarm’s internal load balancer
automatically distributes requests to the service VIP among the active tasks.
subject: |
<a class="glossary" name="subject">subject</a>: |
A subject represents a user, team, or organization in Docker Enterprise. A subject is
granted a role for access to a collection of swarm resources.
For more about role-based access, see [Authentication](/datacenter/ucp/2.2/guides/access-control/).
swarm: |
A [swarm](/engine/swarm/) is a cluster of one or more Docker Engines running in [swarm mode](#swarm mode).
Docker Swarm: |
Do not confuse [Docker Swarm](https://github.com/docker/swarm) with the [swarm mode](#swarm mode) features in Docker Engine.
<a class="glossary" name="swarm">swarm</a>: |
A [swarm](/engine/swarm/) is a cluster of one or more Docker Engines running in [swarm mode](#swarm_mode).
<a class="glossary" name="docker_swarm">Docker Swarm</a>: |
Do not confuse [Docker Swarm](https://github.com/docker/swarm) with the [swarm mode](#swarm_mode) features in Docker Engine.
Docker Swarm is the name of a standalone native clustering tool for Docker.
Docker Swarm pools together several Docker hosts and exposes them as a single
@ -290,16 +297,16 @@ Docker Swarm: |
works with Docker can now transparently scale up to multiple hosts.
*Also known as : docker-swarm*
swarm mode: |
<a class="glossary" name="swarm_mode">swarm mode</a>: |
[Swarm mode](/engine/swarm/) refers to cluster management and orchestration
features embedded in Docker Engine. When you initialize a new swarm (cluster) or
join nodes to a swarm, the Docker Engine runs in swarm mode.
tag: |
<a class="glossary" name="tag">tag</a>: |
A tag is a label applied to a Docker image in a [repository](#repository).
Tags are how various images in a repository are distinguished from each other.
*Note : This label is not related to the key=value labels set for docker daemon.*
task: |
<a class="glossary" name="task">task</a>: |
A [task](/engine/swarm/how-swarm-mode-works/services/#/tasks-and-scheduling) is the
atomic unit of scheduling within a swarm. A task carries a Docker container and
the commands to run inside the container. Manager nodes assign tasks to worker
@ -309,7 +316,7 @@ task: |
containers.
![services diagram](/engine/swarm/images/services-diagram.png)
Toolbox: |
<a class="glossary" name="toolbox">Toolbox</a>: |
[Docker Toolbox](/toolbox/overview/) is a legacy
installer for Mac and Windows users. It uses Oracle VirtualBox for
virtualization.
@ -320,7 +327,7 @@ Toolbox: |
For Windows 10 systems that support Microsoft Hyper-V (Professional, Enterprise
and Education), [Docker Desktop for
Windows](/docker-for-windows/) is the better solution.
Union file system: |
<a class="glossary" name="union_file_system">Union file system</a>: |
Union file systems implement a [union
mount](https://en.wikipedia.org/wiki/Union_mount) and operate by creating
layers. Docker uses union file systems in conjunction with
@ -338,7 +345,7 @@ Union file system: |
[UnionFS](https://en.wikipedia.org/wiki/UnionFS),
[AUFS](https://en.wikipedia.org/wiki/Aufs), and
[Btrfs](https://btrfs.wiki.kernel.org/index.php/Main_Page).
virtual machine: |
<a class="glossary" name="virtual_machine">virtual machine</a>: |
A virtual machine is a program that emulates a complete computer and imitates dedicated hardware.
It shares physical hardware resources with other users but isolates the operating system. The
end user has the same experience on a Virtual Machine as they would have on dedicated hardware.
@ -347,7 +354,7 @@ virtual machine: |
gets its own set of resources and does minimal sharing.
*Also known as : VM*
volume: |
<a class="glossary" name="volume">volume</a>: |
A volume is a specially-designated directory within one or more containers
that bypasses the Union File System. Volumes are designed to persist data,
independent of the container's life cycle. Docker therefore never automatically
@ -364,7 +371,7 @@ volume: |
- An **anonymous volume** is similar to a named volume, however, it can be difficult, to refer to
the same volume over time when it is an anonymous volumes. Docker handle where the files are stored.
x86_64: |
<a class="glossary" name="x86_64">x86_64</a>: |
x86_64 (or x86-64) refers to a 64-bit instruction set invented by AMD as an
extension of Intel's x86 architecture. AMD calls its x86_64 architecture,
AMD64, and Intel calls its implementation, Intel 64.

10
_scss/_content.scss
View File

@ -120,6 +120,16 @@ a.anchorLink {
visibility: hidden;
}
a.glossary {
color: $body-text-color;
text-decoration: none;
outline: none;
&:hover {
opacity: 1;
text-decoration: none;
}
}
.highlighter-rouge {
margin: 15px 0;
}

4
_scss/_night-mode.scss
View File

@ -148,6 +148,10 @@ body.night {
margin-bottom: 30px;
display: inline-block;
}
a.glossary,
.toc-nav i.fa{
color: $body-text-color-night;
}
.component img, .component-full-icon img {
opacity: 1;
-webkit-filter: grayscale(100%);

22
glossary.md
View File

@ -1,9 +1,10 @@
---
title: "Docker glossary"
title: "Glossary"
description: "Glossary of terms used around Docker"
keywords: "glossary, docker, terms, definitions"
notoc: true
noratings: true
skip_read_time: true
redirect_from:
- /engine/reference/glossary/
- /reference/glossary/
@ -19,14 +20,11 @@ like so:
<span id="glossaryMatch" />
<span id="topicMatch" />
## Glossary terms
To see a definition for a term, and all topics in the documentation that have
been tagged with that term, click any entry below:
{% for entry in site.data.glossary %}- [{{ entry[0] }}]
{% endfor %}
{% for entry in site.data.glossary %}[{{ entry[0] }}]: /glossary/?term={{ entry[0] }}
{: class="glossLink" data-content="{{ entry[1] | markdownify | strip_html | strip | truncatewords: 50, "..."}}" data-trigger="hover" id="popoverData{{ forloop.index }}" rel="popover" data-placement="bottom" data-original-title="Definition of: {{ entry[0]}}"}
{% endfor %}
<table border="1">
{% for entry in site.data.glossary %}
<tr>
<td>{{ entry[0] }}</td>
<td>{{ entry[1] | markdownify }}</td>
</tr>
{% endfor %}
</table>

24
js/docs.js
View File

@ -131,18 +131,18 @@ function renderNav(docstoc) {
}
outputHorzTabs.push('><a href="'+docstoc.horizontalnav[i].path+'">'+docstoc.horizontalnav[i].title+'</a></li>\n');
}
if (outputLetNav.length==0)
{
// either glossary was true or no left nav has been built; default to glossary
// show pages tagged with term and highlight term in left nav if applicable
renderTagsPage()
for (var i=0;i<glossary.length;i++)
{
var highlightGloss = '';
if (tagToLookup) highlightGloss = (glossary[i].term.toLowerCase()==tagToLookup.toLowerCase()) ? ' class="active currentPage"' : '';
outputLetNav.push('<li><a'+highlightGloss+' href="/glossary/?term=' + glossary[i].term + '">'+glossary[i].term+'</a></li>');
}
}
// if (outputLetNav.length==0)
// {
// either glossary was true or no left nav has been built; default to glossary
// show pages tagged with term and highlight term in left nav if applicable
// renderTagsPage()
// for (var i=0;i<glossary.length;i++)
// {
// var highlightGloss = '';
// if (tagToLookup) highlightGloss = (glossary[i].term.toLowerCase()==tagToLookup.toLowerCase()) ? ' class="active currentPage"' : '';
// outputLetNav.push('<li><a'+highlightGloss+' href="/glossary/?term=' + glossary[i].term + '">'+glossary[i].term+'</a></li>');
// }
// }
document.getElementById('jsTOCHorizontal').innerHTML = outputHorzTabs.join('');
document.getElementById('jsTOCLeftNav').innerHTML = outputLetNav.join('');
}