Store configuration data using docker configs

Examples

Join a node to swarm as a manager

The example below demonstrates joining a manager node using a manager token.

A cluster should only have 3-7 managers at most, because a majority of managers must be available
for the cluster to function. Nodes that aren’t meant to participate in this management quorum
should join as workers instead. Managers should be stable hosts that have static IP addresses.

Join a node to swarm as a worker

The example below demonstrates joining a worker node using a worker token.

If the node is a manager, it will listen for inbound swarm manager traffic on this
address. The default is to listen on 0.0.0.0:2377. It is also possible to specify a
network interface to listen on that interface’s address; for example .

Specifying a port is optional. If the value is a bare IP address, or interface
name, the default port 2377 will be used.

This flag is generally not necessary when joining an existing swarm.

This flag specifies the address that will be advertised to other members of the
swarm for API access. If unspecified, Docker will check if the system has a
single IP address, and use that IP address with the listening port (see
). If the system has multiple IP addresses,
must be specified so that the correct address is chosen for inter-manager
communication and overlay networking.

It is also possible to specify a network interface to advertise that interface’s address;
for example .

Specifying a port is optional. If the value is a bare IP address, or interface
name, the default port 2377 will be used.

This flag is generally not necessary when joining an existing swarm. If
you’re joining new nodes through a load balancer, you should use this flag to
ensure the node advertises its IP address and not the IP address of the load
balancer.

This flag specifies the address that global scope network drivers will publish towards
other nodes in order to reach the containers running on this node.
Using this parameter it is then possible to separate the container’s data traffic from the
management traffic of the cluster.
If unspecified, Docker will use the same IP address or interface that is used for the
advertise address.

Secret value required for nodes to join the swarm

This flag specifies the availability of the node at the time the node joins a master.
Possible availability values are , , or .

This flag is useful in certain situations. For example, a cluster may want to have
dedicated manager nodes that are not served as worker nodes. This could be achieved
by passing to .

5: Управление кластером

После того, как менеджер и рабочие ноды были добавлены в кластер, все команды управления Docker Swarm нужно выполнять на ноде-менеджере. Поэтому вернитесь к терминалу, который вы использовали для добавления менеджера, и введите эту команду, чтобы просмотреть список членов кластера:

Согласно выводу, в кластере Docker Swarm есть 3 ноды – один менеджер и две рабочие ноды. Чтобы просмотреть список доступных команд для управления кластером, введите:

Для получения подробной информации о кластере вы можете использовать следующую команду (это общая команда Docker, ее можно запускать на менеджере или на рабочих нодах):

Команда сообщает статус кластера (active или pending), количество нод в кластере и роль ноды, с которой она запущена (менеджер или рабочая нода).

Если вы запустите эту команду на рабочих нодах, строка Is Manager будет показывать false.

Примечание: Вы можете добавлять или удалять ноды из кластера в любое время. Кроме того, вы можете менять роли нод: сделать рабочую ноду менеджером и наоборот.

4 ответа

Лучший ответ

Вы можете прочитать .

Чтобы использовать секреты, вам нужно добавить две вещи в ваш файл . Во-первых, блок верхнего уровня , который определяет все секреты. Затем еще один блок под каждой службой, который указывает , какие секреты должна получать служба.

Например, создайте два типа секретов, которые Docker будет понимать: внешние секреты и файловые секреты.

1. Создайте «внешний» секрет, используя

Первое: чтобы использовать секреты с Docker, узел, на котором вы находитесь, должен быть частью роя.

Затем создайте «внешний» секрет:

(Не забудьте включить последнюю черту, . Это легко пропустить.)

3. Создайте файл , который использует оба секрета

Теперь, когда созданы оба типа секретов, вот файл , который будет читать оба из них и записывать их в службу :

Docker может читать секреты либо из собственной базы данных (например, секреты, созданные с помощью ), либо из файла. Выше показаны оба примера.

Разверните стек, используя:

Это создаст один экземпляр службы с именем .

5. Убедитесь, что контейнер, созданный сервисом, имеет оба секрета.

Используйте , чтобы убедиться, что секреты существуют.

(Примечание: в приведенной ниже команде часть будет отличаться на вашем компьютере. Запустите , чтобы найти имя вашего контейнера.)

Если все хорошо, два секрета, которые мы создали на шагах 1 и 2, должны находиться внутри контейнера , который был создан при развертывании нашего стека.

110

Vanuan
17 Мар 2017 в 23:58

Если у вас есть служба и файл секретов :

Создайте файл композиции:

Предоставьте секрет, используя эту команду:

Разверните свой сервис с помощью этой команды:

Теперь ваше приложение может получить доступ к секретному файлу в . Вы можете жестко закодировать этот путь в вашем приложении или создать символическую ссылку.

Другой вопрос

Этот ответ, вероятно, относится к вопросу «как вы предоставляете свои секреты вашему скоплению докеров».

Исходный вопрос «Как вы управляете секретными значениями с помощью docker compose» подразумевает, что файл docker-compose содержит секретные значения. Это не так.

Другой вопрос: «Где вы храните канонический источник файла ». Это зависит от вас. Вы можете сохранить его в своей голове, распечатать на листе бумаги, использовать менеджер паролей, использовать специальное приложение / базу данных секретов. Черт возьми, вы даже можете использовать git-репозиторий, если он надежно защищен. Конечно, никогда не храните его внутри системы, которую вы защищаете с помощью

Я бы порекомендовал хранилище. Чтобы сохранить секрет:

Чтобы получить секрет и положить его в ваш рой:

Конечно, вы можете использовать сам докер кластер как единственный источник правды для ваших секретов, но если ваш докер кластер сломается, вы потеряете свои секреты. Поэтому убедитесь, что у вас есть резервная копия в другом месте.

Вопрос, который никто не задавал

Третий вопрос (который никто не задавал) — как предоставить секреты машинам разработчиков. Это может быть необходимо, когда есть внешняя служба, которую невозможно смоделировать локально, или большая база данных, которую невозможно скопировать.

Опять докер не имеет к этому никакого отношения (пока). Он не имеет списков контроля доступа, которые указывают, какие разработчики имеют доступ к каким секретам. И при этом у него нет никакого механизма аутентификации.

Идеальное решение выглядит следующим образом:

Разработчик открывает какое-то веб-приложение.
Аутентифицируется с использованием механизма единого входа.
Копирует длинный список команд и выполняет их в терминале.

Мы еще не увидели, появляется ли такое приложение.

Vanuan
10 Фев 2017 в 04:15

Examples

generates two random tokens, a worker token and a manager token. When you join
a new node to the swarm, the node joins as a worker or manager node based upon the token you pass
to swarm join.

After you create the swarm, you can display or rotate the token using
swarm join-token.

This flag enables automatic locking of managers with an encryption key. The
private keys and data stored by all managers will be protected by the
encryption key printed in the output, and will not be accessible without it.
Thus, it is very important to store this key in order to activate a manager
after it restarts. The key can be passed to to reactivate
the manager. Autolock can be disabled by running
. After disabling it, the encryption key
is no longer required to start the manager, and it will start up on its own
without user intervention.

This flag sets the validity period for node certificates.

This flag sets the frequency with which nodes are told to use as a
period to report their health.

This flag sets up the swarm to use an external CA to issue node certificates. The value takes
the form . The value for specifies what protocol should be used
to send signing requests to the external CA. Currently, the only supported value is .
The URL specifies the endpoint where signing requests should be submitted.

This flag forces an existing node that was part of a quorum that was lost to restart as a single node Manager without losing its data.

The node listens for inbound swarm manager traffic on this address. The default is to listen on
0.0.0.0:2377. It is also possible to specify a network interface to listen on that interface’s
address; for example .

Specifying a port is optional. If the value is a bare IP address or interface
name, the default port 2377 will be used.

This flag specifies the address that will be advertised to other members of the
swarm for API access and overlay networking. If unspecified, Docker will check
if the system has a single IP address, and use that IP address with the
listening port (see ). If the system has multiple IP addresses,
must be specified so that the correct address is chosen for
inter-manager communication and overlay networking.

It is also possible to specify a network interface to advertise that interface’s address;
for example .

Specifying a port is optional. If the value is a bare IP address or interface
name, the default port 2377 will be used.

This flag allows you to configure the UDP port number to use for data path
traffic. The provided port number must be within the 1024 — 49151 range. If
this flag is not set or is set to 0, the default port number 4789 is used.
The data path port can only be configured when initializing the swarm, and
applies to all nodes that join the swarm.
The following example initializes a new Swarm, and configures the data path
port to UDP port 7777;

After the swarm is initialized, use the command to verify that
the port is configured:

This flag specifies default subnet pools for global scope networks.
Format example is

This flag specifies default subnet pools mask length for default-addr-pool.
Format example is

This flag sets up task history retention limit.

This flag sets the number of old Raft snapshots to retain in addition to the
current Raft snapshots. By default, no old snapshots are retained. This option
may be used for debugging, or to store old snapshots of the swarm state for
disaster recovery purposes.

This flag specifies how many log entries to allow in between Raft snapshots.
Setting this to a higher number will trigger snapshots less frequently.
Snapshots compact the Raft log and allow for more efficient transfer of the
state to new managers. However, there is a performance cost to taking snapshots
frequently.

This flag specifies the availability of the node at the time the node joins a master.
Possible availability values are , , or .

This flag is useful in certain situations. For example, a cluster may want to have
dedicated manager nodes that are not served as worker nodes. This could be achieved
by passing to .

3: Инициализация менеджера кластера

Предположим, node-1 будет менеджером кластера; войдите на ноду с локального компьютера:

Командная строка изменится и вы увидите, что подключились к нужной ноде. Чтобы сделать ноду менеджером Swarm, введите:

Примечание: Вместо node_ip_address укажите IP-адрес вашей ноды.

Вы увидите такой вывод:

To add a manager to this swarm, run ‘docker swarm join-token manager’ and follow the instructions.

В выводе вы найдете ID ноды (a35hhzdzf4g95w0op85tqlow1 в этом примере) и инструкции, как добавить другие ноды в кластер.

Итак, теперь у вас есть менеджер Docker Swarm. Настройте остальные ноды.

Исправление ошибок при запуске Docker Swarm

1) Если Docker swarm в LXC выдает ошибку:

или

То это означает, что у вас установлено старое ядро. Обновите ядро на хост машине согласно инструкции.

И не загружен модуль ядра br_netfilter. Его нужно загрузить командой:

Или прописать его в автозагрузку (об этом ниже в инструкции).

Более подробно об этой ошибке:https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1618283

2) Может возникнуть эта ошибка;

и syslog будет выдавать следующее

Это связано тоже с версией ядра и тем, что модуль br_netfilter не загружен.

3) Не пингуются контейнеры между собой и не пробрасывается порт. Это происходит по одной причине. Почему то виртуальные IP адреса и ingress в докер под LXC не работают. Решается это просто. Нужно включить dnsrr (DNS Round Robin) в секции для каждого сервиса и использовать mode: host при проброске портов. Ниже в самом конце статьи, я привожу пример yaml файла, где указаны эти параметры.

DNS Round Robin — это способ адресации к сервисам. В докере существуют два способа через виртуальные ip адреса (по умолчанию) и через DNS Round Robin. При использовании виртуальных IP адресов, для каждого сервиса создается IP адрес и все контейнеры его получают при поиске сервиса. При отправке пакета на этот IP адрес, докер сам разруливает к какому контейнеру отправить запрос. Получается виртуальный IP адрес — это промежуточный IP адрес. При использовании DNS Round Robin будут другие контейнеры будут получать прямые IP адреса контейнеров.

mode: host отвечает за проброс портов. Существует два варианта ingress (по умолчанию) и host. При использовании ingress обращение на порт любого серверу в Docker кластере будет переадресовано в контейнер, где указан проброс этого порта. Если поставить mode: host, то проброс потров будет работать только на том сервер, где запустился этот контейнер.

Мораль

Использовать кастомные Docker образы в Swarm чуть сложнее, чем в одиночном Docker. Если только мы не раскидали свой образ по всем хостам облака, что даже звучит сложно, с запуском и масштабированием сервиса на его основе будут сюрпризы. Проблема исчезает, если использовать свой собственный локальный реестр. Если не бояться SSL, то разворачивается он относительно просто даже с самописными сертификатами.

Если же образы будут создаваться и использоваться только внутри кластера, то можно даже не заморачиваться SSL и использовать простой HTTP реестр и обращаться к нему по localhost со всех нодов кластера. Это тоже работает.

Services and tasks

A service is the definition of the tasks to execute on the manager or worker nodes. It
is the central structure of the swarm system and the primary root of user
interaction with the swarm.

When you create a service, you specify which container image to use and which
commands to execute inside running containers.

In the replicated services model, the swarm manager distributes a specific
number of replica tasks among the nodes based upon the scale you set in the
desired state.

For global services, the swarm runs one task for the service on every
available node in the cluster.

A task carries a Docker container and the commands to run inside the
container. It is the atomic scheduling unit of swarm. Manager nodes assign tasks
to worker nodes according to the number of replicas set in the service scale.
Once a task is assigned to a node, it cannot move to another node. It can only
run on the assigned node or fail.

List nodes

To view a list of nodes in the swarm run from a manager node:

The column shows whether or not the scheduler can assign tasks to
the node:

means that the scheduler can assign tasks to the node.
means the scheduler doesn’t assign new tasks to the node, but existing
tasks remain running.
means the scheduler doesn’t assign new tasks to the node. The
scheduler shuts down any existing tasks and schedules them on an available
node.

The column shows node participation in the Raft consensus:

No value indicates a worker node that does not participate in swarm
management.
means the node is the primary manager node that makes all swarm
management and orchestration decisions for the swarm.
means the node is a manager node participating in the Raft
consensus quorum. If the leader node becomes unavailable, the node is eligible for
election as the new leader.
means the node is a manager that can’t communicate with
other managers. If a manager node becomes unavailable, you should either join a
new manager node to the swarm or promote a worker node to be a
manager.

For more information on swarm administration refer to the Swarm administration guide.

How Docker manages configs

When you add a config to the swarm, Docker sends the config to the swarm manager
over a mutual TLS connection. The config is stored in the Raft log, which is
encrypted. The entire Raft log is replicated across the other managers, ensuring
the same high availability guarantees for configs as for the rest of the swarm
management data.

When you grant a newly-created or running service access to a config, the config
is mounted as a file in the container. The location of the mount point within
the container defaults to in Linux containers. In Windows
containers, configs are all mounted into and
symbolic links are created to the desired location, which defaults to
.

You can set the ownership ( and ) for the config, using either the
numerical ID or the name of the user or group. You can also specify the file
permissions (). These settings are ignored for Windows containers.

If not set, the config is owned by the user running the container
command (often ) and that user’s default group (also often ).
If not set, the config has world-readable permissions (mode ), unless a
is set within the container, in which case the mode is impacted by
that value.

You can update a service to grant it access to additional configs or revoke its
access to a given config at any time.

A node only has access to configs if the node is a swarm manager or if it is
running service tasks which have been granted access to the config. When a
container task stops running, the configs shared to it are unmounted from the
in-memory filesystem for that container and flushed from the node’s memory.

If a node loses connectivity to the swarm while it is running a task container
with access to a config, the task container still has access to its configs, but
cannot receive updates until the node reconnects to the swarm.

You can add or inspect an individual config at any time, or list all
configs. You cannot remove a config that a running service is
using. See for a way to
remove a config without disrupting running services.

To update or roll back configs more easily, consider adding a version
number or date to the config name. This is made easier by the ability to control
the mount point of the config within a given container.

To update a stack, make changes to your Compose file, then re-run . If you use a new config in
that file, your services start using them. Keep in mind that configurations
are immutable, so you can’t change the file for an existing service.
Instead, you create a new config to use a different file

You can run to stop the app and take down the stack. This
removes any config that was created by with the same stack
name. This removes all configs, including those not referenced by services and
those remaining after a .

Load balancing

The swarm manager uses ingress load balancing to expose the services you
want to make available externally to the swarm. The swarm manager can
automatically assign the service a PublishedPort or you can configure a
PublishedPort for the service. You can specify any unused port. If you do not
specify a port, the swarm manager assigns the service a port in the 30000-32767
range.

External components, such as cloud load balancers, can access the service on the
PublishedPort of any node in the cluster whether or not the node is currently
running the task for the service. All nodes in the swarm route ingress
connections to a running task instance.

Swarm mode has an internal DNS component that automatically assigns each service
in the swarm a DNS entry. The swarm manager uses internal load balancing to
distribute requests among services within the cluster based upon the DNS name of
the service.

Feature highlights

Cluster management integrated with Docker Engine: Use the Docker Engine
CLI to create a swarm of Docker Engines where you can deploy application
services. You don’t need additional orchestration software to create or manage
a swarm.
Decentralized design: Instead of handling differentiation between node
roles at deployment time, the Docker Engine handles any specialization at
runtime. You can deploy both kinds of nodes, managers and workers, using the
Docker Engine. This means you can build an entire swarm from a single disk
image.
Declarative service model: Docker Engine uses a declarative approach to
let you define the desired state of the various services in your application
stack. For example, you might describe an application comprised of a web front
end service with message queueing services and a database backend.
Scaling: For each service, you can declare the number of tasks you want to
run. When you scale up or down, the swarm manager automatically adapts by
adding or removing tasks to maintain the desired state.
Desired state reconciliation: The swarm manager node constantly monitors
the cluster state and reconciles any differences between the actual state and your
expressed desired state. For example, if you set up a service to run 10
replicas of a container, and a worker machine hosting two of those replicas
crashes, the manager creates two new replicas to replace the replicas that
crashed. The swarm manager assigns the new replicas to workers that are
running and available.
Multi-host networking: You can specify an overlay network for your
services. The swarm manager automatically assigns addresses to the containers
on the overlay network when it initializes or updates the application.
Service discovery: Swarm manager nodes assign each service in the swarm a
unique DNS name and load balances running containers. You can query every
container running in the swarm through a DNS server embedded in the swarm.
Load balancing: You can expose the ports for services to an
external load balancer. Internally, the swarm lets you specify how to distribute
service containers between nodes.
Secure by default: Each node in the swarm enforces TLS mutual
authentication and encryption to secure communications between itself and all
other nodes. You have the option to use self-signed root certificates or
certificates from a custom root CA.
Rolling updates: At rollout time you can apply service updates to nodes
incrementally. The swarm manager lets you control the delay between service
deployment to different sets of nodes. If anything goes wrong, you can
roll back to a previous version of the service.

Operate manager nodes in a swarm

Swarm manager nodes use the Raft Consensus Algorithm to manage the
swarm state. You only need to understand some general concepts of Raft in
order to manage a swarm.

There is no limit on the number of manager nodes. The decision about how many
manager nodes to implement is a trade-off between performance and
fault-tolerance. Adding manager nodes to a swarm makes the swarm more
fault-tolerant. However, additional manager nodes reduce write performance
because more nodes must acknowledge proposals to update the swarm state.
This means more network round-trip traffic.

Raft requires a majority of managers, also called the quorum, to agree on
proposed updates to the swarm, such as node additions or removals. Membership
operations are subject to the same constraints as state replication.

Maintain the quorum of managers

If the swarm loses the quorum of managers, the swarm cannot perform management
tasks. If your swarm has multiple managers, always have more than two.
To maintain quorum, a majority of managers must be available. An odd number of
managers is recommended, because the next even number does not make the quorum
easier to keep. For instance, whether you have 3 or 4 managers, you can still
only lose 1 manager and maintain the quorum. If you have 5 or 6 managers, you
can still only lose two.

Even if a swarm loses the quorum of managers, swarm tasks on existing worker
nodes continue to run. However, swarm nodes cannot be added, updated, or
removed, and new or existing tasks cannot be started, stopped, moved, or
updated.

See for
troubleshooting steps if you do lose the quorum of managers.

About secrets

In terms of Docker Swarm services, a secret is a blob of data, such as a
password, SSH private key, SSL certificate, or another piece of data that should
not be transmitted over a network or stored unencrypted in a Dockerfile or in
your application’s source code. You can use Docker secrets to centrally manage
this data and securely transmit it to only those containers that need access to
it. Secrets are encrypted during transit and at rest in a Docker swarm. A given
secret is only accessible to those services which have been granted explicit
access to it, and only while those service tasks are running.

You can use secrets to manage any sensitive data which a container needs at
runtime but you don’t want to store in the image or in source control, such as:

Usernames and passwords
TLS certificates and keys
SSH keys
Other important data such as the name of a database or internal server
Generic strings or binary content (up to 500 kb in size)

Another use case for using secrets is to provide a layer of abstraction between
the container and a set of credentials. Consider a scenario where you have
separate development, test, and production environments for your application.
Each of these environments can have different credentials, stored in the
development, test, and production swarms with the same secret name. Your
containers only need to know the name of the secret to function in all
three environments.

You can also use secrets to manage non-sensitive data, such as configuration
files. However, Docker supports the use of configs
for storing non-sensitive data. Configs are mounted into the container’s
filesystem directly, without the use of a RAM disk.

Windows support

Docker includes support for secrets on Windows containers. Where there are
differences in the implementations, they are called out in the
examples below. Keep the following notable differences in mind:

Microsoft Windows has no built-in driver for managing RAM disks, so within
running Windows containers, secrets are persisted in clear text to the
container’s root disk. However, the secrets are explicitly removed when a
container stops. In addition, Windows does not support persisting a running
container as an image using or similar commands.
On Windows, we recommend enabling
BitLocker
on the volume containing the Docker root directory on the host machine to
ensure that secrets for running containers are encrypted at rest.
Secret files with custom targets are not directly bind-mounted into Windows
containers, since Windows does not support non-directory file bind-mounts.
Instead, secrets for a container are all mounted in
(an implementation detail which
should not be relied upon by applications) within the container. Symbolic
links are used to point from there to the desired target of the secret within
the container. The default target is .
When creating a service which uses Windows containers, the options to specify
UID, GID, and mode are not supported for secrets. Secrets are currently only
accessible by administrators and users with access within the
container.

Как Docker управляет конфигурациями

Когда вы добавляете конфигурацию в рой,Docker отправляет конфигурацию менеджеру роя по взаимному TLS соединению.Конфигурация хранится в журнале Raft,который зашифрован.Весь Raft-журнал реплицируется другими менеджерами,обеспечивая такие же гарантии высокой доступности конфигураций,как и для остальных данных управления роем.

Когда вы предоставляете вновь созданному или работающему сервису доступ к конфигурации, эта конфигурация монтируется в виде файла в контейнере. Расположение точки монтирования в контейнере по умолчанию равно в контейнерах Linux. В контейнерах Windows все конфиги монтируются в а символические ссылки создаются в нужном месте, по умолчанию .

Вы можете установить владельца ( и ) для конфигурации, используя числовой идентификатор или имя пользователя или группы. Вы также можете указать права доступа к файлу ( ). Эти параметры игнорируются для контейнеров Windows.

Если не задано, конфигурация принадлежит пользователю, выполняющему команду контейнера (часто ) и группе по умолчанию этого пользователя (также часто ).
Если не установлено, конфигурация имеет права на чтение для всего мира (режим ), если в контейнере не установлен , и в этом случае на значение влияет режим .

Вы можете в любое время обновить службу,чтобы предоставить ей доступ к дополнительным конфигурациям или отменить ее доступ к данному конфигуратору.

Узел имеет доступ к конфигам только в том случае, если он является менеджером роя или если он выполняет сервисные задачи, которым был предоставлен доступ к конфигурации. Когда задача контейнера перестает выполняться, общие для нее конфигурации отключаются из файловой системы в памяти для этого контейнера и сбрасываются из памяти узла.

Если узел теряет подключение к рою во время работы контейнера задач с доступом к конфигурации,контейнер задач все равно имеет доступ к своим конфигурациям,но не может получать обновления до тех пор,пока узел не переподключится к рою.

Вы можете добавить или проверить индивидуальную конфигурацию в любое время, или перечислить все конфигурации. Вы не можете удалить конфигурацию, которую использует работающая служба. См. для способа удаления конфигурации без прерывания работы служб.

Для более простого обновления или отката конфигураций,подумайте о добавлении номера версии или даты к названию конфигурации.Это становится проще благодаря возможности управления точкой монтирования конфигов в заданном контейнере.

Чтобы обновить стек, внесите изменения в свой файл Compose, затем повторно запустите . Если вы используете новую конфигурацию в этом файле, ваши службы начнут использовать их. Помните, что конфигурации являются неизменяемыми, поэтому вы не можете изменить файл для существующего сервиса. Вместо этого вы создаете новую конфигурацию для использования другого файла

Вы можете запустить , чтобы остановить приложение и удалить стек. Это удалит любую конфигурацию, созданную при с тем же именем стека. Это удаляет все конфиги, включая те, на которые не ссылаются сервисы, и те, которые остались после .

О конфигурациях

В Docker 17.06 представлены конфиги службы swarm, которые позволяют хранить нечувствительную информацию, такую как файлы конфигурации, вне образа службы или работающих контейнеров. Это позволяет вам сохранять ваши образы как можно более общими, без необходимости встраивать файлы конфигурации в контейнеры или использовать переменные среды.

Конфиги работают аналогично секретам , за исключением того, что они не шифруются в состоянии покоя и монтируются непосредственно в файловую систему контейнера без использования RAM-дисков. Конфигурации могут быть добавлены или удалены из службы в любое время, и службы могут совместно использовать конфигурацию. Вы даже можете использовать конфиги в сочетании с переменными или метками среды для максимальной гибкости. Значения конфигурации могут быть общими строками или двоичным содержимым (размером до 500 КБ).

Настройки поддерживаются как в службах Linux,так и в службах Windows.

поддержка Windows

В Docker 17.06 и выше включена поддержка конфигураций на контейнерах Windows.Там,где есть различия в реализации,они называются в примерах ниже.Имейте в виду следующие заметные различия:

Файлы конфигурации с пользовательскими целями не монтируются напрямую в контейнеры Windows, так как Windows не поддерживает монтирование файлов без каталогов. Вместо этого все конфиги для контейнера монтируются в (подробности реализации, на которые не следует полагаться приложениям) внутри контейнера. Символьные ссылки используются для указания оттуда на желаемую цель конфигурации в контейнере. Целью по умолчанию является .
При создании службы, использующей контейнеры Windows, параметры для указания UID, GID и режима не поддерживаются для конфигураций. В настоящее время настройки доступны только администраторам и пользователям, имеющим доступ к внутри контейнера.
В Windows создайте или обновите службу, используя с форматом . Это передает файл учетных данных gMSA непосредственно на узлы до запуска контейнера. Учетные данные gMSA не записываются на диск на рабочих узлах. Для получения дополнительной информации обратитесь к Развертыванию сервисов к рою .

Что такое режим Swarm

Docker в Swarm режиме это просто Docker Engine, работающий в кластере. Кроме того, что он считает все кластерные хосты единым контейнерным пространством, он получает в нагрузку несколько новых команд (вроде и ) и концепцию сервисов.

Сервисы — это ещё один уровень абстракции над контейнерами. Как и у контейнера, у сервиса будет имя, базовый образ, опубликованные порты и тома (volumes). В отличие от контейнера, сервису можно задать требования к хосту (constraints), на которых его можно запускать. Да и вообще, сервис можно масштабировать прямо в момент создания, указав, сколько именно контейнеров для него нужно запустить.

Но важно понимать одну большую разницу. Сама по себе команда не создаёт никаких контейнеров

Она описывает желаемое состояние сервиса, а дальше уже Swarm менеджер будет искать способы это состояние достигнуть. Найдёт подходящие хосты, запустит контейнеры, будет следить, чтобы с ними (и хостами под ними) всё было хорошо, и перезапустит контейнер, если «хорошо» закончится. Иногда желаемое состояние сервиса так и не будет достигнуто. Например, если в кластере закончились доступные хосты. В таком случае сервис будет висеть в режиме ожидания до тех пор, пока что-нибудь не изменится.

Nodes

A node is an instance of the Docker engine participating in the swarm. You can also think of this as a Docker node. You can run one or more nodes on a single physical computer or cloud server, but production swarm deployments typically include Docker nodes distributed across multiple physical and cloud machines.

To deploy your application to a swarm, you submit a service definition to a
manager node. The manager node dispatches units of work called
to worker nodes.

Manager nodes also perform the orchestration and cluster management functions
required to maintain the desired state of the swarm. Manager nodes elect a
single leader to conduct orchestration tasks.

Worker nodes receive and execute tasks dispatched from manager nodes.
By default manager nodes also run services as worker nodes, but you can
configure them to run manager tasks exclusively and be manager-only
nodes. An agent runs on each worker node and reports on the tasks assigned to
it. The worker node notifies the manager node of the current state of its
assigned tasks so that the manager can maintain the desired state of each
worker.