github.com/khulnasoft/cli@v0.0.0-20240402070845-01bcad7beefa/docs/reference/glossary.md (about)

     1  ---
     2  description: "Glossary of terms used around Docker"
     3  keywords: "glossary, docker, terms, definitions"
     4  ---
     5  
     6  <!-- This file is maintained within the docker/cli GitHub
     7       repository at https://github.com/khulnasoft/cli/. Make all
     8       pull requests against that repo. If you see this file in
     9       another repository, consider it read-only there, as it will
    10       periodically be overwritten by the definitive file. Pull
    11       requests which include edits to this file in other repositories
    12       will be rejected.
    13  -->
    14  
    15  # Glossary
    16  
    17  A list of terms used around the Docker project.
    18  
    19  ## base image
    20  
    21  An image that has no parent is a **base image**.
    22  
    23  ## bridge
    24  
    25  In terms of generic networking, a bridge is a Link Layer device which forwards
    26  traffic between network segments. A bridge can be a hardware device or a
    27  software device running within a host machine's kernel.
    28  
    29  In terms of Docker, a bridge network uses a software bridge which allows
    30  containers connected to the same bridge network to communicate, while providing
    31  isolation from containers which are not connected to that bridge network.
    32  The Docker bridge driver automatically installs rules in the host machine so
    33  that containers on different bridge networks cannot communicate directly with
    34  each other.
    35  
    36  The default bridge network, which is also named `bridge`, behaves differently
    37  from user-defined bridge networks. Containers connected to the default `bridge`
    38  network can communicate with each other across the bridge by IP address but
    39  cannot resolve each other's container name to an IP address unless they are
    40  explicitly linked using the `--link` flag to `docker run`.
    41  
    42  For more information about Docker networking, see
    43  [Understand container communication](https://docs.docker.com/engine/userguide/networking/default_network/container-communication/).
    44  
    45  ## btrfs
    46  
    47  btrfs (B-tree file system) is a Linux [filesystem](#filesystem) that Docker
    48  supports as a storage backend. It is a [copy-on-write](https://en.wikipedia.org/wiki/Copy-on-write)
    49  filesystem.
    50  
    51  ## build
    52  
    53  build is the process of building Docker images using a [Dockerfile](#dockerfile).
    54  The build uses a Dockerfile and a "context". The context is the set of files in the
    55  directory in which the image is built.
    56  
    57  ## cgroups
    58  
    59  cgroups is a Linux kernel feature that limits, accounts for, and isolates
    60  the resource usage (CPU, memory, disk I/O, network, etc.) of a collection
    61  of processes. Docker relies on cgroups to control and isolate resource limits.
    62  
    63  *Also known as : control groups*
    64  
    65  ## Compose
    66  
    67  [Compose](https://github.com/docker/compose) is a tool for defining and
    68  running complex applications with Docker. With compose, you define a
    69  multi-container application in a single file, then spin your
    70  application up in a single command which does everything that needs to
    71  be done to get it running.
    72  
    73  *Also known as : docker-compose, fig*
    74  
    75  ## copy-on-write
    76  
    77  Docker uses a
    78  [copy-on-write](https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/#/the-copy-on-write-strategy)
    79  technique and a [union file system](#union-file-system) for both images and
    80  containers to optimize resources and speed performance. Multiple copies of an
    81  entity share the same instance and each one makes only specific changes to its
    82  unique layer.
    83  
    84  Multiple containers can share access to the same image, and make
    85  container-specific changes on a writable layer which is deleted when
    86  the container is removed. This speeds up container start times and performance.
    87  
    88  Images are essentially layers of filesystems typically predicated on a base
    89  image under a writable layer, and built up with layers of differences from the
    90  base image. This minimizes the footprint of the image and enables shared
    91  development.
    92  
    93  For more about copy-on-write in the context of Docker, see [Understand images,
    94  containers, and storage
    95  drivers](https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/).
    96  
    97  ## container
    98  
    99  A container is a runtime instance of a [docker image](#image).
   100  
   101  A Docker container consists of
   102  
   103  - A Docker image
   104  - Execution environment
   105  - A standard set of instructions
   106  
   107  The concept is borrowed from Shipping Containers, which define a standard to ship
   108  goods globally. Docker defines a standard to ship software.
   109  
   110  ## data volume
   111  
   112  A data volume is a specially-designated directory within one or more containers
   113  that bypasses the Union File System. Data volumes are designed to persist data,
   114  independent of the container's life cycle. Docker therefore never automatically
   115  delete volumes when you remove a container, nor will it "garbage collect"
   116  volumes that are no longer referenced by a container.
   117  
   118  
   119  ## Docker
   120  
   121  The term Docker can refer to
   122  
   123  - The Docker project as a whole, which is a platform for developers and sysadmins to
   124  develop, ship, and run applications
   125  - The docker daemon process running on the host which manages images and containers
   126  
   127  
   128  ## Docker for Mac
   129  
   130  [Docker for Mac](https://docs.docker.com/docker-for-mac/) is an easy-to-install,
   131  lightweight Docker development environment designed specifically for the Mac. A
   132  native Mac application, Docker for Mac uses the macOS Hypervisor framework,
   133  networking, and filesystem. It's the best solution if you want to build, debug,
   134  test, package, and ship Dockerized applications on a Mac. Docker for Mac
   135  supersedes [Docker Toolbox](#toolbox) as state-of-the-art Docker on macOS.
   136  
   137  
   138  ## Docker for Windows
   139  
   140  [Docker for Windows](https://docs.docker.com/docker-for-windows/) is an
   141  easy-to-install, lightweight Docker development environment designed
   142  specifically for Windows 10 systems that support Microsoft Hyper-V
   143  (Professional, Enterprise and Education). Docker for Windows uses Hyper-V for
   144  virtualization, and runs as a native Windows app. It works with Windows Server
   145  2016, and gives you the ability to set up and run Windows containers as well as
   146  the standard Linux containers, with an option to switch between the two. Docker
   147  for Windows is the best solution if you want to build, debug, test, package, and
   148  ship Dockerized applications from Windows machines. Docker for Windows
   149  supersedes [Docker Toolbox](#toolbox) as state-of-the-art Docker on Windows.
   150  
   151  ## Docker Hub
   152  
   153  The [Docker Hub](https://hub.docker.com/) is a centralized resource for working with
   154  Docker and its components. It provides the following services:
   155  
   156  - Docker image hosting
   157  - User authentication
   158  - Automated image builds and work-flow tools such as build triggers and web hooks
   159  - Integration with GitHub and Bitbucket
   160  
   161  
   162  ## Dockerfile
   163  
   164  A Dockerfile is a text document that contains all the commands you would
   165  normally execute manually in order to build a Docker image. Docker can
   166  build images automatically by reading the instructions from a Dockerfile.
   167  
   168  ## filesystem
   169  
   170  A file system is the method an operating system uses to name files
   171  and assign them locations for efficient storage and retrieval.
   172  
   173  Examples :
   174  
   175  - Linux : ext4, btrfs, zfs
   176  - Windows : NTFS
   177  - macOS : HFS+
   178  
   179  ## image
   180  
   181  Docker images are the basis of [containers](#container). An Image is an
   182  ordered collection of root filesystem changes and the corresponding
   183  execution parameters for use within a container runtime. An image typically
   184  contains a union of layered filesystems stacked on top of each other. An image
   185  does not have state and it never changes.
   186  
   187  ## libcontainer
   188  
   189  libcontainer provides a native Go implementation for creating containers with
   190  namespaces, cgroups, capabilities, and filesystem access controls. It allows
   191  you to manage the lifecycle of the container performing additional operations
   192  after the container is created.
   193  
   194  ## libnetwork
   195  
   196  libnetwork provides a native Go implementation for creating and managing container
   197  network namespaces and other network resources. It manage the networking lifecycle
   198  of the container performing additional operations after the container is created.
   199  
   200  ## link
   201  
   202  links provide a legacy interface to connect Docker containers running on the
   203  same host to each other without exposing the hosts' network ports. Use the
   204  Docker networks feature instead.
   205  
   206  ## node
   207  
   208  A [node](https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/) is a physical or virtual
   209  machine running an instance of the Docker Engine in swarm mode.
   210  
   211  **Manager nodes** perform swarm management and orchestration duties. By default
   212  manager nodes are also worker nodes.
   213  
   214  **Worker nodes** execute tasks.
   215  
   216  ## overlay network driver
   217  
   218  Overlay network driver provides out of the box multi-host network connectivity
   219  for docker containers in a cluster.
   220  
   221  ## overlay storage driver
   222  
   223  OverlayFS is a [filesystem](#filesystem) service for Linux which implements a
   224  [union mount](https://en.wikipedia.org/wiki/Union_mount) for other file systems.
   225  It is supported by the Docker daemon as a storage driver.
   226  
   227  ## registry
   228  
   229  A Registry is a hosted service containing [repositories](#repository) of [images](#image)
   230  which responds to the Registry API.
   231  
   232  The default registry can be accessed using a browser at [Docker Hub](#docker-hub)
   233  or using the `docker search` command.
   234  
   235  ## repository
   236  
   237  A repository is a set of Docker images. A repository can be shared by pushing it
   238  to a [registry](#registry) server. The different images in the repository can be
   239  labeled using [tags](#tag).
   240  
   241  Here is an example of the shared [nginx repository](https://hub.docker.com/_/nginx/)
   242  and its [tags](https://hub.docker.com/r/library/nginx/tags/)
   243  
   244  
   245  ## service
   246  
   247  A [service](https://docs.docker.com/engine/swarm/how-swarm-mode-works/services/) is the definition of how
   248  you want to run your application containers in a swarm. At the most basic level
   249  a service  defines which container image to run in the swarm and which commands
   250  to run in the container. For orchestration purposes, the service defines the
   251  "desired state", meaning how many containers to run as tasks and constraints for
   252  deploying the containers.
   253  
   254  Frequently a service is a microservice within the context of some larger
   255  application. Examples of services might include an HTTP server, a database, or
   256  any other type of executable program that you wish to run in a distributed
   257  environment.
   258  
   259  ## service discovery
   260  
   261  Swarm mode [service discovery](https://docs.docker.com/engine/swarm/networking/#use-swarm-mode-service-discovery) is a DNS component
   262  internal to the swarm that automatically assigns each service on an overlay
   263  network in the swarm a VIP and DNS entry. Containers on the network share DNS
   264  mappings for the service via gossip so any container on the network can access
   265  the service via its service name.
   266  
   267  You don’t need to expose service-specific ports to make the service available to
   268  other services on the same overlay network. The swarm’s internal load balancer
   269  automatically distributes requests to the service VIP among the active tasks.
   270  
   271  ## swarm
   272  
   273  A [swarm](https://docs.docker.com/engine/swarm/) is a cluster of one or more Docker Engines running in [swarm mode](#swarm-mode).
   274  
   275  ## Docker Swarm
   276  
   277  Do not confuse [Docker Swarm](https://github.com/docker/swarm) with the [swarm mode](#swarm-mode) features in Docker Engine.
   278  
   279  Docker Swarm is the name of a standalone native clustering tool for Docker.
   280  Docker Swarm pools together several Docker hosts and exposes them as a single
   281  virtual Docker host. It serves the standard Docker API, so any tool that already
   282  works with Docker can now transparently scale up to multiple hosts.
   283  
   284  *Also known as : docker-swarm*
   285  
   286  ## swarm mode
   287  
   288  [Swarm mode](https://docs.docker.com/engine/swarm/) refers to cluster management and orchestration
   289  features embedded in Docker Engine. When you initialize a new swarm (cluster) or
   290  join nodes to a swarm, the Docker Engine runs in swarm mode.
   291  
   292  ## tag
   293  
   294  A tag is a label applied to a Docker image in a [repository](#repository).
   295  tags are how various images in a repository are distinguished from each other.
   296  
   297  *Note : This label is not related to the key=value labels set for docker daemon*
   298  
   299  ## task
   300  
   301  A [task](https://docs.docker.com/engine/swarm/how-swarm-mode-works/services/#/tasks-and-scheduling) is the
   302  atomic unit of scheduling within a swarm. A task carries a Docker container and
   303  the commands to run inside the container. Manager nodes assign tasks to worker
   304  nodes according to the number of replicas set in the service scale.
   305  
   306  The diagram below illustrates the relationship of services to tasks and
   307  containers.
   308  
   309  ![services diagram](https://docs.docker.com/engine/swarm/images/services-diagram.png)
   310  
   311  ## Union file system
   312  
   313  Union file systems implement a [union mount](https://en.wikipedia.org/wiki/Union_mount) and operate by creating
   314  layers. Docker uses union file systems in conjunction with
   315  [copy-on-write](#copy-on-write) techniques to provide the building blocks for
   316  containers, making them very lightweight and fast.
   317  
   318  For more on Docker and union file systems, see [OverlayFS storage driver](https://docs.docker.com/storage/storagedriver/overlayfs-driver/),
   319  and [Btrfs storage driver](https://docs.docker.com/storage/storagedriver/btrfs-driver/).
   320  
   321  Example implementations of union file systems are
   322  [UnionFS](https://en.wikipedia.org/wiki/UnionFS), and [Btrfs](https://btrfs.wiki.kernel.org/index.php/Main_Page).
   323  
   324  ## virtual machine
   325  
   326  A virtual machine is a program that emulates a complete computer and imitates dedicated hardware.
   327  It shares physical hardware resources with other users but isolates the operating system. The
   328  end user has the same experience on a Virtual Machine as they would have on dedicated hardware.
   329  
   330  Compared to containers, a virtual machine is heavier to run, provides more isolation,
   331  gets its own set of resources and does minimal sharing.
   332  
   333  *Also known as : VM*