Co to jest dockerfile?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: Dockerfile to plik tekstowy z instrukcjami, według których Docker buduje obraz aplikacji — pakiet zawierający jej kod, potrzebne narzędzia i ustawienia. Z takiego obrazu można uruchamiać kontenery, czyli odizolowane procesy z przygotowanym środowiskiem. Dockerfile opisuje więc, jak przygotować aplikację do uruchomienia, ale sam nie jest działającym kontenerem.
Dockerfile, obraz i kontener — trzy różne rzeczy
Dockerfile można porównać do przepisu, obraz do przygotowanego według niego zestawu, a kontener do uruchomionego egzemplarza tego zestawu. Jeden obraz może posłużyć do utworzenia wielu kontenerów, na przykład kilku instancji tej samej aplikacji.
W Dockerfile określasz między innymi środowisko bazowe, pliki do skopiowania, zależności do zainstalowania i domyślne polecenie startowe. Dzięki temu nie trzeba ręcznie przygotowywać każdego serwera według osobnej instrukcji. Po zmianie kodu lub zależności zwykle budujesz nowy obraz.
Kontener nie jest pełną maszyną wirtualną: korzysta z jądra systemu środowiska, w którym działa silnik kontenerowy. Obraz pomaga ujednolicić środowisko aplikacji, ale nie usuwa wszystkich różnic między komputerami. Nadal znaczenie mają na przykład architektura procesora, konfiguracja sieci i dostęp do plików.
Jakie instrukcje zawiera Dockerfile?
Plik zwykle nazywa się Dockerfile, bez rozszerzenia. Każda instrukcja opisuje konkretny krok budowania albo ustawienie obrazu. Najczęściej spotkasz:
FROM— wybiera obraz bazowy, na przykład środowisko Pythona lub Node.js.WORKDIR— ustawia katalog roboczy dla kolejnych instrukcji i uruchamianej aplikacji.COPY— kopiuje pliki z kontekstu budowania do obrazu.RUN— wykonuje polecenie podczas budowania, na przykład instaluje biblioteki.ENV— ustawia zmienne środowiskowe.EXPOSE— deklaruje port używany przez aplikację; nie udostępnia go automatycznie poza kontenerem.CMD— określa domyślne polecenie wykonywane przy uruchomieniu kontenera.
Kluczowe jest rozróżnienie RUN i CMD. Polecenie RUN działa podczas tworzenia obrazu, natomiast CMD dopiero przy uruchamianiu kontenera. Instalacja zależności zwykle należy do RUN, a start serwera do CMD.
Istnieje też ENTRYPOINT, które określa główny program kontenera. Można połączyć je z CMD, aby przekazywać temu programowi domyślne argumenty. Do pierwszego prostego przykładu wystarczy samo CMD.
Prosty przykład: strona HTML w kontenerze
Załóżmy, że chcesz uruchomić lokalnie prostą stronę bez instalowania Pythona na swoim komputerze. Potrzebujesz działającego Dockera oraz katalogu z dwoma plikami: index.html i Dockerfile.
W pliku index.html umieść:
<!doctype html>
<html lang="pl">
<meta charset="utf-8">
<title>Przykład Dockera</title>
<h1>Strona działa w kontenerze</h1>
</html>
Plik Dockerfile może wyglądać tak:
FROM python:3.13-slim
WORKDIR /app
COPY index.html .
EXPOSE 8000
CMD ["python", "-m", "http.server", "8000", "--bind", "0.0.0.0"]
Docker użyje obrazu zawierającego Pythona, ustawi katalog /app i skopiuje do niego stronę. Przy starcie kontenera uruchomi prosty serwer HTTP. Adres 0.0.0.0 oznacza nasłuchiwanie na wszystkich interfejsach sieciowych kontenera, co pozwala dotrzeć do serwera przez opublikowany port.
W terminalu, w katalogu z tymi plikami, wykonaj:
docker build -t moja-strona .
docker run --rm -p 127.0.0.1:8080:8000 moja-strona
Pierwsze polecenie buduje obraz i nadaje mu nazwę moja-strona. Kropka wskazuje bieżący katalog jako kontekst budowania, czyli zestaw plików dostępnych dla procesu budowania. Drugie polecenie uruchamia kontener i łączy lokalny port 8080 z portem 8000 kontenera.
Otwórz w przeglądarce http://localhost:8080. Wiązanie portu z 127.0.0.1 ogranicza dostęp do lokalnego komputera. Serwer zatrzymasz skrótem Ctrl+C, a opcja --rm usunie zakończony kontener. To przykład do nauki, nie konfiguracja serwera produkcyjnego.
Co wpływa na szybkość i bezpieczeństwo budowania?
Docker może ponownie wykorzystać wyniki wcześniejszych kroków dzięki pamięci podręcznej, czyli cache. Zmiana plików użytych przez daną instrukcję może wymusić ponowne wykonanie tego kroku i kolejnych zależnych kroków. Dlatego w aplikacji z bibliotekami często najpierw kopiuje się plik zależności i instaluje pakiety, a dopiero potem kopiuje kod zmieniany częściej.
Plik .dockerignore wyklucza zbędne pliki z kontekstu budowania. Typowo są to katalog .git, lokalne środowiska, logi i pliki z sekretami. Zmniejsza to ilość przesyłanych danych oraz ryzyko przypadkowego dołączenia poufnych materiałów.
Haseł i tokenów nie zapisuj w Dockerfile ani nie kopiuj do obrazu. Usunięcie sekretu w późniejszym kroku nie gwarantuje usunięcia go z wcześniejszych warstw obrazu. Sekrety potrzebne podczas budowania przekazuj mechanizmami sekretów BuildKit, a dane wymagane przez działającą aplikację — odpowiednią konfiguracją środowiska uruchomieniowego.
W zastosowaniach produkcyjnych rozważ uruchamianie aplikacji jako użytkownik bez uprawnień administratora. Kontroluj także wersję obrazu bazowego: tag może z czasem wskazywać zmieniony obraz, natomiast digest identyfikuje konkretną zawartość. Dostępne wersje i sposób aktualizacji sprawdzaj w oficjalnej dokumentacji wybranego obrazu.
Kiedy potrzebujesz Dockerfile, a kiedy Compose?
Dockerfile odpowiada na pytanie: „Jak zbudować obraz?”. Docker Compose służy do opisania i uruchamiania zestawu usług, na przykład aplikacji, bazy danych i pamięci podręcznej, wraz z ich sieciami, portami i wolumenami. Wolumen to mechanizm przechowywania danych niezależnie od życia pojedynczego kontenera.
Te narzędzia mogą współpracować: Compose może zbudować obraz według Dockerfile, a następnie uruchomić go obok gotowego obrazu bazy danych. Jeśli korzystasz wyłącznie z gotowych obrazów, własny Dockerfile nie zawsze jest potrzebny.
Zacznij od zbudowania i uruchomienia jednego prostego obrazu. Następnie zastąp przykładową stronę własną aplikacją, jawnie określ jej zależności i sprawdź, które pliki rzeczywiście powinny trafić do obrazu.
Zobacz też: Co to jest API?
Przeczytaj także
