vault backup: 2026-05-24 15:03:28
This commit is contained in:
Dmitry
@@ -0,0 +1,40 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Docker - Дополнительные Знания
|
||||
---
|
||||
|
||||
# Docker - Дополнительные Знания
|
||||
|
||||
## Запуск Контейнера С Непривилегированным Пользователем
|
||||
|
||||
Рассмотрим пример работы с непривилегированным пользователем:
|
||||
|
||||
- не использовать root внутри контейнера и не запускать его с повышенными привелегиями
|
||||
- создать пользователя можно сразу создать в Dockerfile
|
||||
- переключить пользователя можно с помощью директивы **USER** в Dockerfile
|
||||
|
||||
```dockerfile
|
||||
FROM mariadb
|
||||
USER 999
|
||||
```
|
||||
|
||||
## Rootless-mode - Podman
|
||||
|
||||
Docker решил предпринять попытки отказаться от docker daemon и docker socket с root привилегиями и разрабатывает концепцию rootless-mode
|
||||
|
||||
- Идея нетривиальна в реализации, так как возникают особенности установки бинарников и запуска скриптов.
|
||||
- Логичной заменой есть Podman, написанный на golang, она уже rootless и daemonless по умолчанию.
|
||||
- Podman обратно совместим в docker (в т.ч. собирает свои образы из Dockerfile)
|
||||
- Существует podman builder, позволяющий описывать образы с помощью **bash**.
|
||||
- Практически все команды докера существуют в подмане.
|
||||
|
||||
## Связанные заметки
|
||||
- [[Super-user]] — "не использовать root внутри контейнера" — прямое применение принципа наименьших привилегий из Linux; rootless Podman реализует его на уровне демона
|
||||
- [[Проблемы дистрибутивов]] — реальный кейс: запуск Rails в контейнере как решение проблемы OpenSSL на Arch Linux
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Images, Dockerfile - Docker
|
||||
---
|
||||
|
||||
# Images, Dockerfile - Docker
|
||||
|
||||
Запуск контейнеров происходит на основе images (образов). Образы собираются с помощью Dockerfile.
|
||||
|
||||
Основные инструкции в Dockerfile:
|
||||
|
||||
- **FROM** - использование базового образа
|
||||
- **RUN** - выполнение команд и создание слоя образа
|
||||
- **COPY** - копирование в контейнер файлов и папок
|
||||
- **ADD** - аналогично COPY, но с распаковкой архивов
|
||||
|
||||
Дополнительные:
|
||||
|
||||
- _LABEL_ - описание метаданных
|
||||
- _ENV_ - задание переменных среды
|
||||
- _CMD_ - описание команд с аргументами для выполнения при запуске контейнера
|
||||
- _WORKDIR_ - задание рабочей директории для следующей инструкции
|
||||
- _ARG_ - задание переменных для передачи во время сборки
|
||||
- _ENTRYPOINT_ - предоставление команды с аргументами для вызова во время выполнения контейнера
|
||||
- _VOLUME_ - создание точки монтирования для работы с docker volume
|
||||
- _EXPOSE_ - открытие порта в контейнере
|
||||
|
||||
> Все эти команды создают отдельный слой (layer) для сборки контейнера
|
||||
|
||||
## Оптимизация Образа
|
||||
|
||||
```dockerfile
|
||||
FROM ubuntu
|
||||
|
||||
RUN apt update
|
||||
RUN apt install python3 -y
|
||||
RUN apt install python3-dev -y
|
||||
```
|
||||
|
||||
- Сокращение инструкций **RUN** (уменьшение количества слоев)
|
||||
|
||||
```dockerfile
|
||||
FROM ubuntu
|
||||
|
||||
RUN apt update
|
||||
RUN apt install python3 python3-dev -y
|
||||
```
|
||||
|
||||
> Docker будет пересобирать только те слои, которые были изменены
|
||||
|
||||
```dockerfile
|
||||
FROM ubuntu
|
||||
|
||||
RUN apt update && \
|
||||
apt install python3 python3-dev -y
|
||||
```
|
||||
|
||||
- Удаление кеша пакетных менеджеров
|
||||
|
||||
```dockerfile
|
||||
RUN apt update && \
|
||||
apt install python3 python3-dev -y \
|
||||
rm -rf /var/lib/apt/lists/*
|
||||
```
|
||||
|
||||
- Удаление файлов в той же инструкции, где их создавали
|
||||
- Инструкции, которые предположительно будут часто изменяться, ставить ниже остальных
|
||||
- Сокращение количество инструкций **COPY**
|
||||
|
||||
```dockerfile
|
||||
RUN apt update && \
|
||||
apt install python3 python3-dev -y \
|
||||
rm -rf /var/lib/apt/lists/*
|
||||
|
||||
COPY file1 file2 file3 ./dir
|
||||
```
|
||||
|
||||
- Использование легковесных базовых образов, где есть такая возможность
|
||||
|
||||
|
||||
|
||||
## Связанные заметки
|
||||
- [[Environment Variables]] — инструкция `ENV` в Dockerfile устанавливает переменные окружения внутри контейнера; это расширение того же механизма Linux env vars
|
||||
- [[Volume - Docker]] — инструкция `VOLUME` в Dockerfile объявляет точки монтирования для Docker Volumes
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Multistaging - Docker
|
||||
---
|
||||
|
||||
# Multistaging - Docker
|
||||
|
||||
При сборке docker-образов мы можем использовать механизм многоэтапной сборки - Multistaging.
|
||||
|
||||
При использовании multistaging мы разделяем процедуру сборки на несколько этапов, обозначая их метками.
|
||||
|
||||
|
||||
|
||||
**Использование механизма Multistaging позволяет:**
|
||||
|
||||
- Собирать легковесные образы.
|
||||
- Сократить время сборки образов и запуска на основе контейнеров.
|
||||
- Повысить производительность работы контейнеров.
|
||||
- Переиспользовать вспомогательные образы из промежуточных этапов.
|
||||
- Сократить поверхность атаки на наши контейнеры для потенциального
|
||||
злоумышленника.
|
||||
|
||||
## Связанные заметки
|
||||
- [[Основы - Docker]]
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Network Drivers - Docker
|
||||
---
|
||||
|
||||
# Network Drivers - Docker
|
||||
|
||||
При работе с docker возникает необходимость обеспечить работу контейнеров в сети:
|
||||
|
||||
- настройка правил маршрутизации (iptables)
|
||||
- формирование пакетов
|
||||
- инкапсуляция пакетов
|
||||
- шифрование и безопасность
|
||||
|
||||
Для этого используются Network Drivers
|
||||
|
||||
Сетевых драйверов поддерживаются несколько вариаций, каждый из них способен обеспечить все основные функции:
|
||||
|
||||
- bridge (мост)
|
||||
- host
|
||||
- overlay
|
||||
- macvlan
|
||||
- none
|
||||
- 3rd-party plugins
|
||||
|
||||
**Bridge**
|
||||
|
||||
Объединение контейнеров в bridge-сеть:
|
||||
|
||||
- контейнеры обьеденены в сеть
|
||||
- контейнеры в сети имеют связь друг с другом
|
||||
- контейнеры из другой сети не имеют сетевой связности
|
||||
- используется в docker **по умолчанию**
|
||||
|
||||
**Host**
|
||||
|
||||
Использует сеть хоста (удаляется сетевая изоляция)
|
||||
|
||||
- удаляет сетевую изоляцию между контейнером и хостом
|
||||
- возможны проблемы с занятым портов, сетевыми ограничениями хостовой сети (поддерживается только в Linux)
|
||||
|
||||
**Overlay**
|
||||
|
||||
Создание сети для объединения контейнеров на разных хостах путем создания оверлейной сети
|
||||
|
||||
- не поддерживает шифрование на win-хостах
|
||||
|
||||
**MacVLAN**
|
||||
|
||||
Работа с контейнерами, как с физическими устройствами
|
||||
|
||||
- присваивает каждому контейнеру в сети физический MAC-адрес
|
||||
- позволяет обращаться к контейнеру как к настоящему устройству
|
||||
- поддерживается только в Linux
|
||||
|
||||
**None**
|
||||
|
||||
Отключение всех сетей в контейнере
|
||||
|
||||
- может быть использован для изоляции контейнера
|
||||
|
||||
## Работа С Bridge-сетями
|
||||
|
||||
Docker по умолчанию использует bridge-сеть, так как он позволяет добиться большей изоляции от внешних сетей хоста.
|
||||
|
||||
Контейнеры внутри одного "бриджа" не имеют доступа к другим из других бридж сетей.
|
||||
|
||||
Если нам нужна гибкая настройка сети внутри самого контейнера, потребуются доп. **capabilities** (например, **CAP_NET_ADMIN**)
|
||||
|
||||
В качестве альтернативы можно рассмотреть CNI-плагины (сторонние - 3rd-party)
|
||||
|
||||
## Связанные заметки
|
||||
- [[Модель OSI]] — bridge/overlay/macvlan реализуют концепции L2/L3 из модели OSI; iptables работает на L3/L4
|
||||
- [[VLAN - Base]] — bridge-изоляция контейнеров ≈ VLAN-изоляция устройств: разные бриджи не видят друг друга, как разные VLAN
|
||||
- [[VPN]] — overlay-сеть реализует принцип VPN: инкапсуляция трафика одной сети поверх другой
|
||||
- [[Сегментация сети]] — изоляция контейнеров по bridge-сетям = программная сегментация сети
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Storage Drivers - Docker
|
||||
---
|
||||
|
||||
# Storage Drivers - Docker
|
||||
|
||||
Для работы с данными в контейнере имеется специальный контейнерный слой (**container layer**). Он появляется только в момент запуска контейнера, для работы с данными.
|
||||
|
||||
|
||||
|
||||
Для работы с данными в контейнерном слое и работы со слоями образа _docker_ задействует _**драйверы хранилища**_ **(storage drivers).**
|
||||
|
||||
Доступны в Docker 6 SD:
|
||||
|
||||
|
||||
|
||||
## Block Level (блочные хранилища)
|
||||
|
||||
- распределяют данные на блоки одинакового размеры по оборудованию
|
||||
- не зависит от пути к данным
|
||||
- быстрое получение
|
||||
|
||||
Примеры: ZFS, DeviceMapper
|
||||
|
||||
## File Level (файловые хранилища)
|
||||
|
||||
- данные хранятся единым фрагментов
|
||||
- присутсвует иерархия директорий
|
||||
- доступ к файлу зависит от единственного пути
|
||||
- наиболее распространенный способ хранения данных
|
||||
|
||||
Примеры: AUFS, Overlay, **Overlay2** (по умолчанию)
|
||||
|
||||
## Object Level (объектно-ориентированные хранилища)
|
||||
|
||||
- данные распределяются по оборудованию по частям
|
||||
- связывает объекты данных с их метадатой
|
||||
- объекты могут быть только перезаписаны (изменять нельзя)
|
||||
- для доступа требуется реализация API интерфейса
|
||||
|
||||
По умолчанию, в Docker используется Overlay2, изменить это можно в `/etc/docker/daemon.json`
|
||||
|
||||
**Backing Filesystem**
|
||||
|
||||
Резервная файловая система, в которой расположен `/var/lib/docker`
|
||||
|
||||
Для работы storage driver требуется **совместимая** backing filesystem.
|
||||
|
||||
|
||||
|
||||
## Связанные заметки
|
||||
- [[Основы - Docker]]
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Volume - Docker
|
||||
---
|
||||
|
||||
# Volume - Docker
|
||||
**Некоторые данные стоит хранить независимо от контейнера, для этого существует понятие Volume.**
|
||||
|
||||
Стоит так хранить: БД, логи, конфиги, артефакты, настройки, …
|
||||
|
||||
Для постоянного или персистентного хранения используются Docker Volume. Это буквально монтирование хостовой директории внутрь контейнера, для работы с данными контейнера напрямую.
|
||||
|
||||
Возможности Docker Volumes:
|
||||
|
||||
1. Выгрузка данных контейнера на постоянное хранение
|
||||
2. Работа в подмонтированных каталогах с интенсивной записью данных
|
||||
3. Совместное использование данных несколькими контейнерами
|
||||
|
||||
Docker volumes создают тома, которые монтируются в контейнер.
|
||||
По умолчанию тома docker volumes создаются в каталоге `/var/lib/docker/volumes/`
|
||||
|
||||
|
||||
|
||||
## Типы Volumes
|
||||
|
||||
1. **Host** DV:
|
||||
`docker run -v /home/mount/data:/var/lib/mysql/data`
|
||||
При запуске контейнера, мы пробрасываем конкретный каталог на хосте в конкретный каталог в контейнере
|
||||
(есть опция флагов, для редактирования прав доступа)
|
||||
2. **Anonymous** DV:
|
||||
`docker run -v /var/lib/mysql/data`
|
||||
При таком подходе, Volume создастся в `/var/lib/docker/volumes`
|
||||
3. **Names** DV:
|
||||
`docker run -v name:/var/lib/mysql/data`
|
||||
Аналогично второму варианту, Volume создается в директории по умолчанию, но ему присваивается метка `name`, которую можно переиспользовать.
|
||||
|
||||
## Организация Доступа К Файлам В Docker Volumes
|
||||
|
||||
По умолчанию, uid/gid внутри контейнера и на хосте идентичны, поэтому владелец/группа и права доступа внутри смонтированного каталога будут эквиванлентны.
|
||||
|
||||
Изменить данные поведение поможет фича под названием "userns-remap" - она позволит соотнести uid/gid контейнера к другим uid/gid хоста
|
||||
|
||||
Проблема в том, что по умолчанию, в volume владелец root - что не очень хорошо.
|
||||
|
||||
Для управления этой фичей, нужно отредактировать конфигурацию по пути `/etc/docker/daemon.json`
|
||||
|
||||
```bash
|
||||
{
|
||||
"userns-remap": "<username>"
|
||||
}
|
||||
```
|
||||
|
||||
## Связанные заметки
|
||||
- [[File Permissions]] — uid/gid маппинг в Docker Volumes напрямую зависит от Linux-прав доступа; проблема "владелец root по умолчанию" решается через chmod/chown
|
||||
- [[Active Storage]] — Active Storage в Rails хранит файлы вне БД; в Docker-деплое они должны персистироваться через Volume, иначе теряются при перезапуске контейнера
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- containerization
|
||||
- docker
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Основы - Docker
|
||||
---
|
||||
|
||||
# Основы - Docker
|
||||
|
||||
## Виртуализация
|
||||
|
||||
**Виртуализация** - это набор вычислительных ресурсов, обеспечивающих логическую изоляцию процессов, выполняющихся на одном физ.хосте.
|
||||
|
||||
## Связанные заметки
|
||||
- [[Storage Drivers - Docker]]
|
||||
- [[Multistaging - Docker]]
|
||||
Reference in New Issue
Block a user