Запропонувати правку

Покращити цю статтю

Допрацюйте відповідь до «Що таке overlay2 storage driver і коли варто його змінити?». Ваші зміни проходять модерацію перед публікацією.

Потрібне підтвердження

Контент

Що ви змінюєте

Заголовок (UA)

Коротка відповідь (UA)

Показується над повною відповіддю для швидкого нагадування.

Відповідь (UA)

**Storage-driver'и** в Docker керують тим, як image-layer'и і writable container-layer комбінуються на host-filesystem. **overlay2** це сучасний дефолт, базований на kernel-овому **OverlayFS**. Він швидкий, добре підтримуваний і використовується практично кожним свіжим Docker-install. Інші driver'и (btrfs, zfs, vfs, devicemapper, fuse-overlayfs) існують для нішових випадків.

## Теорія

### TL;DR

- overlay2 = kernel OverlayFS + Docker-інтеграція. Швидкий і стабільний.
- Стакає N read-only image-layer'ів + 1 writable container-layer через union-mount.
- Copy-on-write: модифікація файлу з нижнього layer'а копіює його в upper-layer спочатку.
- Дефолт з Docker 17.06+. Потребує kernel 4.x і backing-FS, що підтримує `xattrs` (ext4, xfs з `ftype=1`).
- Інші driver'и існують; overlay2 виграє для general use.
- Зміна driver-а інвалідує всі images і containers в `/var/lib/docker`.

### Як OverlayFS працює

OverlayFS комбінує два каталоги у віртуальну filesystem:

```
lowerdir   = read-only image-layer'и (стакнуті)
upperdir   = writable container-layer (зміни йдуть сюди)
workdir    = scratch-простір, який kernel використовує внутрішньо
merged     = уніфікований view, що бачить container
```

Коли container читає файл, kernel walk'ає stack top-down: upperdir перший, потім кожен lowerdir. Перший збіг виграє. Коли container пише:

- **Новий файл:** створюється в upperdir.
- **Модифікація існуючого з lowerdir:** kernel **копіює весь файл** з lowerdir у upperdir, потім модифікує копію. Оригінал у lowerdir не чіпається.
- **Видалення файлу з lowerdir:** kernel пише special **whiteout marker** у upperdir. Файл здається зниклим, хоча ще існує в нижньому layer-і.
- **Видалення каталогу:** marker це `opaque directory` xattr.

Copy-on-write швидкий: file-metadata копіюються лінливо, page'и мапляться on demand. Але touch'нув 5GB-файл, скопіював 5GB.

### Де живе на диску

```
/var/lib/docker/overlay2/
├── <layer-id-1>/
│   ├── diff/        # реальні файли layer'а
│   ├── link         # короткий ім'я для lower= chain
│   └── lower        # parent-layer'и (../<id>/diff)
├── <layer-id-2>/
│   └── ...
└── l/
    ├── <short-name-1> -> ../<layer-id-1>/diff
    └── <short-name-2> -> ../<layer-id-2>/diff
```

`l/`-каталог містить короткі symlink'и, бо mount-команди мають length-ліміт на `lower=`-аргумент.

### Інші driver'и і коли їх розглядати

**btrfs** (Btrfs-filesystem)
- Якщо `/var/lib/docker` на btrfs-filesystem і хочеш native subvolume-snapshot.
- Корисно, якщо вже використовуєш btrfs cluster-wide.
- Трохи швидший image build/extract для деяких workload-ів.
- Уникай, якщо не крутиш btrfs; не міняй FS лише ради цього.

**zfs** (ZFS-filesystem)
- Та ж ідея, що з btrfs, але для ZFS.
- Сильна snapshot/clone-історія; production-grade на FreeBSD, OpenZFS на Linux.
- Уникай, якщо не крутиш ZFS з інших причин.

**fuse-overlayfs** (userspace overlay)
- Для **rootless Docker**, де user-UID не може робити реальні overlay-mount.
- Повільніший за overlay2 (userspace FUSE), але юзабельний.
- Дефолт для rootless-setup на старих kernel; сучасні kernel (>=5.13) дозволяють реальний overlay2 у user-namespace, прибираючи потребу.

**devicemapper** (block-level COW)
- RHEL/CentOS 7-епоха дефолт до того, як overlay2 був надійний на цих distro.
- Два режими: **loopback** (повільний, ext4-file backed, ніколи не використовуй для prod), **direct-lvm** (LVM thin-pool, manageable).
- Deprecated у 2023; не бери для нових install'ів.

**vfs** (без COW)
- Повна копія кожного layer'а. Масивне disk-використання. Використовуй тільки для testing або коли інший driver не працює.

### Як перевірити, що в тебе

```bash
docker info | grep -A 5 'Storage Driver'
# Storage Driver: overlay2
#  Backing Filesystem: extfs
#  Supports d_type: true
#  Using metacopy: false
#  Native Overlay Diff: true
```

`Backing Filesystem: extfs` (ext4) і `Supports d_type: true` потрібні. xfs має бути створений з `ftype=1`, щоб підтримувати overlay2.

## Приклади

### Перехід на overlay2 (з devicemapper або vfs)

Це destructive. Всі images/containers в `/var/lib/docker` стираються.

```bash
# Backup'ни все, що треба (images, volumes)
docker save -o backup.tar $(docker images -q)
# (і volumes через docker run --rm -v vol:/data -v /backup:/backup ubuntu tar czf /backup/vol.tgz /data)

# Зупини daemon
sudo systemctl stop docker

# Edit /etc/docker/daemon.json
sudo tee /etc/docker/daemon.json <<EOF
{
  "storage-driver": "overlay2"
}
EOF

# Wipe старий graph
sudo rm -rf /var/lib/docker

# Запусти daemon, він будує /var/lib/docker свіжий під overlay2
sudo systemctl start docker

# Верифікуй
docker info | grep 'Storage Driver'
# Restore images: docker load -i backup.tar
```

### Інспекція layer'а

```bash
# Знайти overlay2-каталог для container
docker inspect <container_id> --format '{{.GraphDriver.Data.MergedDir}}'
# /var/lib/docker/overlay2/<id>/merged

# Цей каталог це view container на FS, поки крутиться
sudo ls /var/lib/docker/overlay2/<id>/merged
# bin etc lib usr var ...
```

Корисно для forensic на FS зупиненого container.

### Disk-usage breakdown

```bash
sudo du -sh /var/lib/docker/overlay2 | sort -h
docker system df -v
# Показує per-image, per-container, per-volume disk-usage
```

Ефективність простору overlay2 приходить з layer-sharing: 50 container'ів, що шарять той самий image-base, зберігають одну копію кожного lower-layer плюс 50 малих upper-layer.

## Реальне застосування

- **Дефолт на кожному сучасному Linux:** kernel 4.x + ext4/xfs дають overlay2 з коробки.
- **Docker Desktop:** крутить Docker всередині Linux-VM, що використовує overlay2.
- **Container-кластери (Swarm/K8s):** кожна node використовує overlay2, якщо явно не сконфіговано.
- **Rootless Docker на старих kernel:** fuse-overlayfs.
- **Hyper-converged ZFS або btrfs storage-стек:** matching-driver, для snapshot-інтеграції.

### Коли заміна driver'а реально виправдана

1. **Глибоко використовуєш ZFS/btrfs** для host-filesystem і хочеш unified snapshot-management.
2. **Дотягнув до limit'ів overlay2** (дуже рідко): max-stack-depth ~127 lowerdir, kernel-version-specific quirks, екзотичні xattr-вимоги.
3. **Rootless Docker на kernel, що не дозволяє user-namespace overlay-mount.**

Інакше, лиши overlay2. Performance/stability-gap реальний для non-default driver-ів.

### Типові помилки

**Зміна driver-а без wipe `/var/lib/docker`**

Docker відмовляється стартувати, якщо metadata для одного driver існує, а ти просиш інший. Або wipe каталог, або використовуй окремий `data-root`.

**xfs без `ftype=1`**

overlay2 потребує xfs, форматований з `ftype=1`. Якщо твій xfs `ftype=0`, не можеш використати overlay2 на цій filesystem. Reformat або іншу mount-точку.

**Loopback devicemapper**

На старих системах можна знайти devicemapper у loopback-режимі (sparse-file). Він повільний і corrupt'иться під тиском. Мігруй на overlay2 негайно.

**Плутаниця storage-driver і Docker-volume**

Storage-driver керує image- і container-layer'ами. **Docker-volume** окремі; їхні дані живуть у `/var/lib/docker/volumes/` незалежно від driver-а.

### Питання для поглиблення

**Q:** Чому оригінальний `overlay`-driver замінили?

**A:** Оригінальний `overlay` мав проблеми з inode-exhaustion при багатьох layer'ах і глибші compatibility-issue. `overlay2` reuse'ить inode агресивніше і це рекомендований наступник.

**Q:** Чи storage-driver впливає на runtime-performance?

**A:** Трохи. overlay2 near-native для read; запис, що чіпає великі lower-layer-файли, повільний через copy-up. Для heavy file-write workload-ів, бери **volumes** або **bind-mount**, щоб обійти storage-driver повністю.

**Q:** Чи можу я мати кілька Docker-daemon з різними driver'ами?

**A:** Так, крути їх з окремими `--data-root`-каталогами. Рідко на практиці.

**Q:** (Senior) Як reason'ити про disk-простір, коли багато container'ів шарять lower-layer?

**A:** `docker system df -v` показує apparent vs shared-size. Перший container, що pull'ить base-layer, споживає повний розмір; наступні container'и додають лише writable upper-layer. Коли останній container, що використовує layer, прибраний, layer стає prunable. Тож 100 container'ів з `nginx:alpine` коштують приблизно `nginx_size + 100 * upper_layer_writes`, не `100 * nginx_size`.

**Q:** (Senior) Що таке `metacopy` і коли це матиме значення?

**A:** `metacopy=on` дозволяє overlay2 copy-up тільки metadata (chmod, chown) без копіювання file-data. Економить простір і час для permission-only змін. Off за замовчуванням для compatibility; включай, якщо розумієш tradeoff (трохи слабша COW-семантика навколо hardlink).

Markdown · перетягуйте зображення · ⌘B / ⌘I шорткати1101 слів

Для рев’юера

Примітка для модератора (необов’язково)

Бачить лише модератор. Прискорює рев’ю.