HTML Diff
0 added 0 removed
Original 2026-01-01
Modified 2026-02-26
1 <p>Приложения запускаемые внутри Docker можно разделить на две большие группы: stateful и stateless. Первые хранят и обрабатывают данные, которые записываются в файловую систему, вторые ничего не сохраняют и работают только с теми данными, которые приходят к ним снаружи.</p>
1 <p>Приложения запускаемые внутри Docker можно разделить на две большие группы: stateful и stateless. Первые хранят и обрабатывают данные, которые записываются в файловую систему, вторые ничего не сохраняют и работают только с теми данными, которые приходят к ним снаружи.</p>
2 <p>По ходу курса, мы в основном встречались со stateless приложениями. Это наиболее простые в обслуживании приложения. Они легко могут останавливаться, переноситься на другой сервер и масштабироваться за счет параллельного запуска нескольких копий. Например Nginx, является таким приложением.</p>
2 <p>По ходу курса, мы в основном встречались со stateless приложениями. Это наиболее простые в обслуживании приложения. Они легко могут останавливаться, переноситься на другой сервер и масштабироваться за счет параллельного запуска нескольких копий. Например Nginx, является таким приложением.</p>
3 <p>Но большая часть реальных приложений является stateful. Типичные примеры включают в себя кеширование, хранение картинок, документов, данных в базе данных и так далее. Даже Nginx, при включенном кешировании, превращается в stateful приложение.</p>
3 <p>Но большая часть реальных приложений является stateful. Типичные примеры включают в себя кеширование, хранение картинок, документов, данных в базе данных и так далее. Даже Nginx, при включенном кешировании, превращается в stateful приложение.</p>
4 <p>Stateful приложения значительно сложнее в управлении, особенно если они упакованы в Docker. Представьте себе, что ваше приложение сохраняет картинки. По умолчанию это происходит внутри контейнера. Затем, по какой-то причине, контейнер удаляется и вместе с ним пропадают все картинки. Вы без проблем перезапустите контейнер с приложением, но картинок там уже не будет.</p>
4 <p>Stateful приложения значительно сложнее в управлении, особенно если они упакованы в Docker. Представьте себе, что ваше приложение сохраняет картинки. По умолчанию это происходит внутри контейнера. Затем, по какой-то причине, контейнер удаляется и вместе с ним пропадают все картинки. Вы без проблем перезапустите контейнер с приложением, но картинок там уже не будет.</p>
5 <p>При работе с Docker важно придерживаться правила неизменяемости контейнеров. Любые данные должны сохраняться куда-то наружу. В идеале запускать контейнеры с флагом --read-only, который запрещает любую запись внутри. Так заодно можно находить контейнеры, которые что-то пишут без предупреждения:</p>
5 <p>При работе с Docker важно придерживаться правила неизменяемости контейнеров. Любые данные должны сохраняться куда-то наружу. В идеале запускать контейнеры с флагом --read-only, который запрещает любую запись внутри. Так заодно можно находить контейнеры, которые что-то пишут без предупреждения:</p>
6 <p>Для работы с данными в Docker существует несколько механизмов, в этом уроке мы рассмотрим обмен данными с хост-системой.</p>
6 <p>Для работы с данными в Docker существует несколько механизмов, в этом уроке мы рассмотрим обмен данными с хост-системой.</p>
7 <p>Типичная ситуация, когда есть какой-то файл, обычно конфигурационный на хост-системе, и мы хотим чтобы при запуске контейнера этот файл оказался внутри. Например мы хотим чтобы внутри контейнера была доступна история bash-команд. Пример команды:</p>
7 <p>Типичная ситуация, когда есть какой-то файл, обычно конфигурационный на хост-системе, и мы хотим чтобы при запуске контейнера этот файл оказался внутри. Например мы хотим чтобы внутри контейнера была доступна история bash-команд. Пример команды:</p>
8 <p>Технически, bash внутри контейнера будет продолжать записывать историю команд во внутренний файл /root/.bash_history, но Docker сделает так, что этот файл будет "ссылаться" на файл в хост-системе по пути $HOME/.bash_history.</p>
8 <p>Технически, bash внутри контейнера будет продолжать записывать историю команд во внутренний файл /root/.bash_history, но Docker сделает так, что этот файл будет "ссылаться" на файл в хост-системе по пути $HOME/.bash_history.</p>
9 <p>Добавляя флаг -v можно пробросить во внутрь любое количество файлов:</p>
9 <p>Добавляя флаг -v можно пробросить во внутрь любое количество файлов:</p>
10 <p>Точно так же этот механизм работает и для целых директорий. Например ниже мы передаем всю директорию /etc/nginx внутрь контейнера:</p>
10 <p>Точно так же этот механизм работает и для целых директорий. Например ниже мы передаем всю директорию /etc/nginx внутрь контейнера:</p>
11 <p>Проброс директорий открывает возможности для хранения данных снаружи. Например так можно работать с<a>официальным образом PostgreSQL</a>:</p>
11 <p>Проброс директорий открывает возможности для хранения данных снаружи. Например так можно работать с<a>официальным образом PostgreSQL</a>:</p>
12 <p>Шаринг данных открывает возможность обмена между контейнерами. Для этого достаточно пробросить директорию в нужное количество контейнеров, которые будут туда писать и читать. Классический пример использования это общий кеш.</p>
12 <p>Шаринг данных открывает возможность обмена между контейнерами. Для этого достаточно пробросить директорию в нужное количество контейнеров, которые будут туда писать и читать. Классический пример использования это общий кеш.</p>
13 <p>У Docker есть определенные правила при указании путей:</p>
13 <p>У Docker есть определенные правила при указании путей:</p>
14 <ul><li>Путь на хост-машине может быть как относительным так и абсолютным</li>
14 <ul><li>Путь на хост-машине может быть как относительным так и абсолютным</li>
15 <li>Путь внутри контейнера должен быть абсолютным</li>
15 <li>Путь внутри контейнера должен быть абсолютным</li>
16 <li>Если файла или директории не существует внутри контейнера, то они будут созданы автоматически</li>
16 <li>Если файла или директории не существует внутри контейнера, то они будут созданы автоматически</li>
17 </ul><p>Делая шаринг нужно внимательно следить за именем файла на хост-машине. Если ошибиться в названии, Docker не укажет на ошибку, он просто создаст директорию с таким именем. Это поведение осталось от первых версий в качестве обратной совместимости. К сожалению оно приводит к трудноотловимым ошибкам.</p>
17 </ul><p>Делая шаринг нужно внимательно следить за именем файла на хост-машине. Если ошибиться в названии, Docker не укажет на ошибку, он просто создаст директорию с таким именем. Это поведение осталось от первых версий в качестве обратной совместимости. К сожалению оно приводит к трудноотловимым ошибкам.</p>