OverlayFS – jak działa warstwowy system plików Linux używany przez Docker i kontenery

Jednym z kluczowych mechanizmów, który umożliwił rozwój kontenerów Linux, jest OverlayFS (Overlay File System).

To właśnie dzięki niemu obrazy Dockera mogą być lekkie, szybkie i współdzielić wspólne warstwy.

Gdy pobieramy obraz:

docker pull nginx

nie otrzymujemy jednej dużej kopii systemu plików. Docker pobiera zestaw warstw, które są później składane w jeden widok dla kontenera.

Za tę funkcjonalność bardzo często odpowiada właśnie OverlayFS.

Czym jest OverlayFS?

OverlayFS to specjalny system plików typu union filesystem, czyli system łączący wiele katalogów w jeden spójny widok.

Zamiast kopiować dane, system tworzy logiczną warstwę nad istniejącymi katalogami.

Schemat:

                Kontener

                   ↓

             OverlayFS view

                   ↓

        ┌──────────────────┐
        │ Upper layer      │  ← zmiany kontenera
        ├──────────────────┤
        │ Lower layer 3    │
        ├──────────────────┤
        │ Lower layer 2    │
        ├──────────────────┤
        │ Lower layer 1    │  ← obraz bazowy
        └──────────────────┘

Dla aplikacji wygląda to jak jeden system plików.

Dlaczego powstał OverlayFS?

Klasyczny sposób uruchamiania aplikacji wymagałby:

System operacyjny

+

Biblioteki

+

Aplikacja

+

Konfiguracja

dla każdego środowiska osobno.

Przykład:

Masz 100 kontenerów Ubuntu.

Bez warstw:

Ubuntu 1 GB

x 100 kontenerów

= 100 GB

Z OverlayFS:

Ubuntu base layer

+

100 małych warstw zmian

Zużycie miejsca jest znacznie mniejsze.

Jak działa model warstw?

Obraz kontenera składa się z warstw read-only.

Przykład obrazu:

nginx image

Layer 4
Konfiguracja nginx

Layer 3
Pakiety

Layer 2
Biblioteki

Layer 1
Ubuntu base

Każda warstwa jest niezależna.

Podczas uruchomienia kontenera Docker dodaje specjalną warstwę zapisu:

Container

┌──────────────────┐
│ Writable layer   │
├──────────────────┤
│ Image layer 4    │
├──────────────────┤
│ Image layer 3    │
├──────────────────┤
│ Image layer 2    │
├──────────────────┤
│ Image layer 1    │
└──────────────────┘

Copy-on-Write (CoW)

Najważniejsza cecha OverlayFS to:

Copy-on-Write

Czyli:

dane są kopiowane dopiero wtedy, gdy zostaną zmodyfikowane.

Przykład.

Obraz zawiera:

/etc/nginx/nginx.conf

Kontener tylko odczytuje plik:

Lower layer

Nic się nie dzieje.

Ale aplikacja zmienia konfigurację:

nano /etc/nginx/nginx.conf

OverlayFS wykonuje:

Lower layer

nginx.conf

↓

kopiuj do Upper layer

↓

zmodyfikuj

Oryginał pozostaje nietknięty.

Warstwy OverlayFS

OverlayFS wykorzystuje kilka katalogów.

Najważniejsze:

Lowerdir

Warstwy tylko do odczytu.

Przykład:

/var/lib/docker/overlay2/

Zawierają obraz.

Upperdir

Warstwa zapisu.

Tutaj trafiają zmiany kontenera.

Workdir

Katalog roboczy wymagany przez OverlayFS.

Merged

Połączony widok.

To właśnie widzi proces.

Schemat:

lowerdir
    +
upperdir

    ↓

merged directory

OverlayFS w Dockerze

Sprawdzenie używanego storage driver:

docker info

Przykład:

Storage Driver: overlay2

Obecnie najczęściej używany:

overlay2

Dlaczego overlay2 jest lepszy niż stary overlay?

Starszy sterownik:

overlay

miał ograniczenia.

overlay2:

• obsługuje wiele warstw,
• lepiej wykorzystuje inode,
• ma lepszą wydajność,
• jest standardem w nowych instalacjach.

Przykład działania w Dockerze

Uruchamiamy:

docker run -it ubuntu bash

W kontenerze:

echo "test" > /plik.txt

Co się dzieje?

Nie zmienia się obraz Ubuntu.

Powstaje:

Upper layer

/
└── plik.txt

Po usunięciu kontenera:

docker rm container

warstwa zapisu znika.

OverlayFS i usuwanie plików

Ciekawy przypadek.

Załóżmy:

Obraz posiada:

/etc/config.conf

Kontener wykonuje:

rm /etc/config.conf

Czy plik znika z dolnej warstwy?

Nie.

OverlayFS tworzy specjalny znacznik:

whiteout file

Informuje:

ukryj ten plik z niższej warstwy.

Schemat:

Lower:

config.conf


Upper:

.whiteout config.conf

Efekt:

Dla kontenera:

plik nie istnieje

OverlayFS a bezpieczeństwo

OverlayFS sam w sobie nie jest mechanizmem bezpieczeństwa.

Jego zadanie:

• organizacja danych,
• wydajność,
• warstwowość.

Nie zastępuje:

• SELinux,
• AppArmor,
• Seccomp,
• namespaces.

Jednak ma znaczenie bezpieczeństwa.

Przykład:

Kontener zapisuje malware:

Upper layer

↓

tylko ten kontener

Nie zmienia obrazu bazowego.

OverlayFS i SELinux

W środowiskach enterprise trzeba uważać na konteksty SELinux.

Przykład:

Docker + RHEL:

Container

↓

OverlayFS

↓

SELinux labels

Błędne konteksty mogą powodować:

• brak dostępu do plików,
• błędy aplikacji.

Przydatne narzędzie:

restorecon

OverlayFS i wydajność

Zalety:

✅ szybkie tworzenie kontenerów
✅ oszczędność miejsca
✅ współdzielenie obrazów

Ale są ograniczenia.

Dużo zapisów = problem

OverlayFS najlepiej działa dla:

• odczytu,
• aplikacji stateless.

Gorzej:

• bazy danych,
• intensywny zapis.

Przykład:

PostgreSQL

↓

OverlayFS

↓

dużo operacji I/O

↓

spadek wydajności

Dlatego bazy danych często korzystają z:

• wolumenów,
• LVM,
• dedykowanego storage.

OverlayFS i Kubernetes

Kubernetes korzysta z warstwy storage przez runtime:

• containerd,
• CRI-O.

Schemat:

Pod

↓

Container Runtime

↓

overlay filesystem

↓

Linux kernel

OverlayFS vs klasyczny filesystem

Diagnostyka OverlayFS

Sprawdzenie mountów:

mount | grep overlay

Przykład:

overlay on /var/lib/docker/overlay2/... 

Informacje Docker:

docker system df

Pokazuje:

• obrazy,
• warstwy,
• wykorzystanie miejsca.

Najczęstsze błędy administratorów

1. Trzymanie danych produkcyjnych w warstwie kontenera

Źle:

Baza danych

↓

container writable layer

Po usunięciu kontenera:

dane znikają.

Lepiej:

Baza danych

↓

Volume

↓

dedykowany storage

2. Budowanie zbyt wielu warstw Dockerfile

Przykład:

RUN apt update
RUN apt install
RUN cleanup

Każdy krok tworzy warstwę.

Lepsze:

RUN apt update && \
apt install && \
cleanup

3. Ignorowanie rozmiaru obrazów

Niepotrzebne pliki pozostają w warstwach.

Warto używać:

• multi-stage builds,
• minimalnych obrazów,
• Alpine/distroless.

OverlayFS w architekturze nowoczesnego Linux

Współczesny kontener wykorzystuje kilka mechanizmów jednocześnie:

                Container

                   ↓

              OverlayFS
          (system plików)

                   +

             Namespaces
          (izolacja)

                   +

              cgroups v2
          (limity zasobów)

                   +

              Seccomp
          (syscalle)

                   +

          SELinux/AppArmor
          (kontrola dostępu)

Podsumowanie

OverlayFS jest jednym z fundamentów współczesnej konteneryzacji Linux.

To dzięki niemu:

• obrazy Dockera są lekkie,
• kontenery startują szybko,
• wiele środowisk może współdzielić te same dane bazowe.

Jednocześnie administrator musi pamiętać, że OverlayFS jest przede wszystkim mechanizmem organizacji i wydajności, a nie ochrony.

Bezpieczne środowisko kontenerowe wymaga połączenia:

• OverlayFS,
• Namespaces,
• cgroups v2,
• Seccomp,
• AppArmor/SELinux,
• nftables,
• audytu i monitoringu.

Dopiero wszystkie te elementy razem tworzą architekturę, na której można bezpiecznie budować współczesną infrastrukturę produkcyjną.

Polecane wpisy

Jak zainstalować Ubuntu?

Jak zainstalować Ubuntu? Przygotowanie: Pobierz plik ISO Ubuntu: Przejdź na stronę https://ubuntu.com/ i wybierz wersję Ubuntu, którą chcesz zainstalować. Kliknij Czytaj dalej

Migracja maszyn wirtualnych w Debianie: Przewodnik krok po kroku

Migracja maszyn wirtualnych w Debianie: Przewodnik krok po kroku Migracja maszyn wirtualnych to proces przenoszenia maszyn wirtualnych (VM) z jednego Czytaj dalej