Budowanie obrazu za pomocą pliku Dockerfile

Tutaj budujesz obraz z aplikacji Flask i testujesz go przy użyciu polecenia docker run. Zakończysz pracę, gdy aplikacja zacznie odpowiadać, a Ty upewnisz się, że lokalny plik .env nie jest zawarty w nowym obrazie. Aplikacja testowa nie wymaga ani konta na GitHubie, ani zewnętrznego interfejsu API (API).

Przed budowaniem

Musisz zbudować obraz (image) i wykazać, że kontener utworzony na podstawie tego obrazu odpowiada. Wymagana jest zainstalowana aplikacja Docker oraz umiejętność uruchamiania i inspektowania kontенера, zgodnie z opisem w sekcji Uruchomienie i badanie kontenera. Jeśli nie masz aplikacji Flask, użyj aplikacji testowej poniżej. Pracuj w katalogu projektu na maszynie wirtualnej Linux, gdzie znajdują się plik app.py, ewentualne szablony oraz inne pliki projektowe.

Jeśli projekt znajduje się w repozytorium kodu, sekcja Git w terminalu pokazuje, jak sklonować go do maszyny wirtualnej. Możesz również utworzyć pliki edytorem tekstu VM. Użyj poleceń pwd i ls, aby upewnić się, że znajdujesz się we właściwym katalogu. Nie buduj obrazu z pustego katalogu ani ze Shella hosta Proxmox.

from flask import Flask
app = Flask(__name__)

@app.route("/")
def index():
    return "Cześć od kontenera!"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

Utwórz plik requirements.txt w tym samym katalogu. Plik ta zawiera listę pakietów Pythona do zainstalowania w obrazie. W przypadku prostej aplikacji z Flask 1, która używa wyłącznie Flask, zawartość wygląda następująco:

Flask

Jeśli aplikacja korzysta z innych bibliotek stron trzecich, muszą one być również wymienione wraz z poprawnymi nazwami pakietów, na przykład requests. Pliki takie jak .venv nie są kopiowane w celu instalacji pakietów; Docker instaluje je ponownie na podstawie tej listy. Wersje można przypiąć, np. za pomocą nazwa_pakietu==wersja, po sprawdzeniu, które wersje używa aplikacja.

Utwórz także plik .dockerignore przed pierwszym buildem. Zapobiega on skopiowaniu lokalnych sekretów, historii Git oraz lokalnego środowiska Python do obrazu:

.env
.git
__pycache__/
.venv/
app-data/

Dodaj również .env do pliku .gitignore, jeśli używasz Gita. Jeśli pliki ignorowania mają już zawartość, dodaj brakujące reguły zamiast zastępować pliki. Skorzystaj z sekcji [[Git w terminalu Poziom 5 – .gitignore i sekrety|.gitignore i sekrety]], aby zweryfikować śledzenie przed udostępnieniem kodu.

Utwórz obraz za pomocą pliku Dockerfile

docker build tworzy pakiet. docker run tworzy i uruchamia kontener z pakietu. Samo budowanie nie uruchamia aplikacji. Zobacz [[Docker Level 0 - Co to jest Docker|Poziom 0]], jeśli musisz ponownie odróżnić obraz od kontenera.

Plik Dockerfile opisuje kroki, które Docker ma wykonać podczas budowania obrazu. Każda linia wykonuje określoną czynność:

FROM python:3.12-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
EXPOSE 5000
CMD ["python", "app.py"]

Docker wykonuje budowanie etapami. COPY i RUN mogą dodawać warstwy systemu plików, podczas gdy m.in. CMD opisuje sposób uruchomienia kontenera. Docker może ponownie wykorzystać wcześniejsze wyniki budowania z pamięci podręcznej (cache budowy). Gdy dany etap musi zostać przebudowany, również kolejne etapy muszą być wykonane od nowa.

Dlatego kopiujemy wyłącznie requirements.txt, zanim użyjemy polecenia COPY . .: czasochłonna instalacja ma miejsce przed kodem źródłowym, który często ulega zmianom:

flowchart TB
    L1["Obraz bazowy: python:3.12-slim"] --> L2["Dział roboczy: /app"]
    L2 --> L3["Skopiuj requirements.txt"]
    L3 --> L4["Zainstaluj pakiety za pomocą pip"]
    L4 --> L5["Skopiuj kod źródłowy"]

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

Jeśli plik requirements.txt zostanie zmodyfikowany, Docker musi ponownie zainstalować pakiety. Jest to pożądane: nowy pakiet powinien faktycznie znaleźć się w obrazie. Jeśli zmieniono tylko kod źródłowy, Docker może użyć gotowej warstwy instalacyjnej i kontynuować budowanie od polecenia COPY . ..

Gdy Docker opublikuje port, przekierowuje ruch do programu wewnątrz contenera. Dlatego program musi nasłuchiwać na sieci contenera, a nie wyłącznie na adresie 127.0.0.1, który oznacza „ten kontener”. Jeśli program nasłuchuje wyłącznie na 127.0.0.1, inne maszyny nie będą mogły go osiągnąć przez port Dockera.

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000, debug=False)

To jest konfiguracja do ćwiczeń z serwerem deweloperskim Flask. Przed użyciem rozwiązania w środowisku produkcyjnym należy uruchomić je na odpowiednim serwerze WSGI; zobacz Flask: konfiguracja produkcyjna.

EXPOSE 5000 opisuje port, którego używa aplikacja; nie publikuje go samodzielnie. Robi to -p 127.0.0.1:5000:5000 w poniższym poleceniu. Zbuduj i uruchom:

docker build -t min-app:latest .
docker run -d --name min-app -p 127.0.0.1:5000:5000 min-app:latest
docker logs -f min-app

Naciśnij Ctrl+C, aby zakończyć wyświetlanie dziennika. Kontener nadal będzie działał.

Test z samego wirtualnego serwera (VM):

curl http://127.0.0.1:5000

Otrzymasz z powrotem zawartość głównej trasy aplikacji. W wyrażeniu -p 127.0.0.1:5000:5000 oznacza 127.0.0.1:5000 port 5000 na serwerze, ale wyłącznie dla programów działających bezpośrednio na tym serwerze. Ostatnia liczba to port wewnątrz kontenera. Jeśli coś nie działa, najpierw sprawdź wynik polecenia docker ps, logi oraz czy port został poprawnie opublikowany.

Przedrostek 127.0.0.1 sprawia, że port jest zamknięty przed siecią, więc inne maszyny nie mają dostępu do aplikacji podczas jej budowania i testowania. To bezpieczny standard dla aplikacji w fazie rozwoju. Bez 127.0.0.1 (-p 5000:5000) port nasłuchuje na wszystkich kartach sieciowych serwera. Potrzebujesz tego dopiero wtedy, gdy inna maszyna lub proxy ma uzyskać dostęp do aplikacji, co omawiamy w Poziomie 3.

Punkt kontrolny: Własne obraz działa

Polecenie curl http://127.0.0.1:5000 powinno wyświetlać główną stronę aplikacji. Dla aplikacji testowej odpowiedź to Cześć z kontenera!. Wyjaśnij, co utworzyło polecenie docker build i co uruchomiło polecenie docker run. W przypadku błędu odczytaj dziennik przed przejściem dalej.

Upewnij się, że plik .env jest wykluczony

Nie potrzebujesz prawdziwego klucza, aby to sprawdzić. Jeśli projekt nie ma jeszcze pliku .env, możesz go utworzyć z zawartością PIGGY_TEST=nieszkodliwa_wartosc_testowa. Zachowaj istniejący plik; nie nadpisuj swoich wartości.

1. Sprawdź, czy plik .env znajduje się zarówno w pliku .dockerignore, jak i w pliku .gitignore.
2. Jeśli używasz Gita, wykonaj ćwiczenia z sekcji [[Git w terminalu Poziom 5 - gitignore i sekrety|ćwiczenie .gitignore]]. Zignorowany plik nie powinien być również śledzony wcześniej.
3. Przebuduj obraz i sprawdź tę ścieżkę pliku bez wyświetlania jego treści:

docker build -t min-app:latest .
docker run --rm --entrypoint sh min-app:latest -c 'test ! -e /app/.env && echo ".env nie istnieje w /app"'

Oczekiwany wynik to „plikt .env nie istnieje w /app”. Jeśli komunikat się nie pojawi, sprawdź plik ignorowania przed udostępnieniem obrazu. Dotyczy to ścieżki pliku w gotowym systemie plików nowego obrazu. Nie odświeża starych obrazów, innych plików z danymi poufnymi ani wartości zapisanych bezpośrednio w kodzie lub w pliku Dockerfile. Najpierw zmień prawdziwy klucz, jeśli poprzedni został udostępniony.

Jeśli budowanie lub aplikacja zawiodą

W przypadku błędu ModuleNotFoundError sprawdź plik requirements.txt i zbuduj ponownie. W razie problemów z pobieraniem obrazu bazowego lub pakietów Pythona przetestuj połączenie sieciowe za pomocą metody [[Metoda debugowania poziomu 1 – systematyczne debuggowanie|debugowania]]. Brak odpowiedzi HTTP wymaga odczytu logów przez docker logs min-aplikacje oraz weryfikacji adresu Flask i mapowania portów.

Następny krok

Pokaż odpowiedź aplikacji oraz kontrolę pliku .env. Wyjaśnij, co opisuje Dockerfile, czego dotyczy proces budowania i co uruchamia docker run. Przejdź do Docker - Publikowanie aplikacji. Jeśli chcesz opisać uruchamianie i aktualizację w pliku Compose, to Uruchomienie i aktualizacja aplikacji za pomocą Compose jest opcjonalnym rozszerzeniem tematu.

Compose i aktualizacje są obecnie omawiane na stronie Uruchomienie i aktualizacja aplikacji za pomocą Compose.

Zapis danych jest wyjaśniany na stronie Zachowywanie danych poza kontenerem; zastosowanie Compose znajduje się na stronie Uruchomienie i aktualizacja aplikacji za pomocą Compose.

Instrukcja dotycząca API znajduje się teraz na stronie Zmienna środowiskowa i klucz API i ma charakter opcjonalny.