Dlaczego usługa Compose używa niewłaściwego pliku zmiennych środowiskowych dopiero po ponownym uruchomieniu hosta?

Usługa Compose może po ponownym uruchomieniu używać innych wartości zmiennych środowiskowych, gdy uruchamiany podczas startu systemu launcher rozpozna inny katalog projektu, plik env lub źródło wartości o wyższym priorytecie.

Ręczne polecenie może być wykonywane z właściwego folderu i przy użyciu jednego środowiska powłoki, podczas gdy systemd, harmonogram NAS-a lub Portainer uruchamia ten sam plik Compose po starcie systemu z innego kontekstu. Usługa może również ponownie uruchamiać istniejący kontener, którego środowisko zostało ustalone w momencie utworzenia, zamiast ponownie odczytywać zmodyfikowany plik. Przed jednoczesną edycją kilku plików porównaj wygenerowany model Compose oraz środowisko procesu działającego w kontenerze dla ścieżki ręcznej i uruchamianej podczas startu systemu.

Porównaj działające środowisko z zamierzonym plikiem

Zapisz identyfikator kontenera, czas jego utworzenia, obraz, etykiety Compose, nazwę projektu oraz rzeczywiste wartości widoczne wewnątrz głównego procesu. Porównaj je z zamierzonym plikiem env, nie wypisując sekretów do współdzielonych dzienników.

Środowisko procesu w systemie Linux udostępnia wartości przekazane podczas uruchamiania, co stanowi mocniejszy dowód niż odczytanie pliku env, którego bieżący kontener mógł nigdy nie użyć.

Jeśli kontener zawiera stare wartości i został utworzony przed wdrożeniem wykonywanym podczas ponownego uruchomienia systemu, usługa mogła jedynie go zrestartować. Jeśli kontener jest nowy, przejdź do analizy priorytetów i rozpoznawania ścieżek.

Zastosuj właściwą kolejność priorytetów zmiennych środowiskowych Compose

Wymień każde źródło wartości dla jednej nieszkodliwej zmiennej: flagi CLI, wartości powłoki, environment:, env_file:, domyślny lub jawnie wskazany plik .env oraz ENV obrazu.

Docker definiuje formalną kolejność priorytetów zmiennych środowiskowych, dlatego prawidłowy plik env może nadal przegrać z wartością o wyższym priorytecie wstrzykniętą przez usługę uruchamianą podczas startu systemu lub menedżera stosu.

Nie szukaj wyłącznie plików o zduplikowanych nazwach. Wyszukaj nazwę zmiennej w wygenerowanym modelu Compose, pliku jednostki, ustawieniach menedżera, środowisku powłoki oraz wartościach domyślnych obrazu.

Sprawdź katalog projektu i względne ścieżki do plików env

Porównaj katalog roboczy polecenia ręcznego z katalogiem roboczym launchera uruchamianego podczas startu systemu, argumentami pliku Compose, katalogiem projektu oraz względnymi odwołaniami env_file.

Specyfikacja Compose definiuje model aplikacji używany do rozpoznawania usług i konfiguracji, dlatego wybrana definicja projektu i jej ścieżki są danymi wejściowymi wdrożenia, a nie właściwościami odczytywanymi ponownie z działającego kontenera.

W przypadku plików env kluczowych podczas uruchamiania systemu używaj ścieżek bezwzględnych, jeśli narzędzie wdrożeniowe je obsługuje, albo ustaw jawny katalog projektu i katalog roboczy, aby uruchomienia ręczne i automatyczne rozpoznawały te same pliki.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź katalog roboczy systemd i pliki środowiskowe

Odczytaj efektywną jednostkę, wszystkie pliki dodatkowe, WorkingDirectory=, Environment=, EnvironmentFile= oraz ExecStart=. Porównaj jednostkę ładowaną podczas startu systemu z poleceniem używanym ręcznie.

Ustawienia wykonywania systemd definiują katalog roboczy usługi i pliki środowiskowe, które nie dziedziczą automatycznie bieżącego katalogu ani wyeksportowanych zmiennych interaktywnej powłoki logowania.

Po zmianie jednostki lub pliku dodatkowego przeładuj menedżera systemd i ponownie sprawdź efektywną jednostkę. Edycja szablonu lub nieużywanego pliku nie zmieni usługi, która faktycznie jest uruchamiana.

Sprawdź zmienne menedżera stosu i zapisany stan wdrożenia

Jeśli Portainer lub interfejs NAS-a zarządza stosem, porównaj zapisane zmienne, przesłany plik env, ścieżkę wdrożenia Git, sposób aktualizacji przez webhook oraz wyświetlany model Compose.

Portainer rozróżnia sposób działania plików .env i stack.env, dlatego wartości wprowadzone w menedżerze mogą różnić się od pliku edytowanego bezpośrednio na hoście.

Wybierz jedno źródło prawdy. Stos zarządzany z Git lub edytora internetowego nie powinien być po każdym ponownym uruchomieniu systemu uruchamiany ręcznie z innej lokalnej kopii.

Utwórz kontener ponownie zamiast tylko go restartować

Porównaj czas utworzenia kontenera z czasem edycji pliku env. Wygeneruj zamierzoną konfigurację Compose, a następnie kontrolowanie utwórz ponownie tylko daną usługę.

Wskazówki Red Hat dotyczące systemd zalecają przed ponownym uruchomieniem sprawdzenie plików oraz nadpisań faktycznie używanych przez usługę, aby zapobiec odtworzeniu kontenera przez nieaktualną jednostkę lub wrapper z użyciem starych wartości.

Restart kontenera nie odtwarza jego środowiska na podstawie Compose. Utwórz go ponownie dopiero po zabezpieczeniu danych trwałych i potwierdzeniu, że wygenerowany model wskazuje właściwe woluminy i sekrety.

Spraw, aby uruchomienie ręczne, ponowne uruchomienie systemu i ponowne wdrożenie tworzyły ten sam model

Ustal na stałe pliki Compose, nazwę projektu, katalog projektu, ścieżkę do pliku env, właściciela stosu oraz zależność uruchamiania podczas startu systemu. Zapisz zanonimizowaną wygenerowaną konfigurację oraz nieszkodliwy odcisk środowiska.

Artykuł ZimaSpace dotyczący zakresu kopii zapasowej Docker przedstawia powiązaną zasadę: pliki środowiskowe i definicje wdrożenia należy zachowywać razem ze stanem trwałym.

Problem zostaje rozwiązany, gdy ręczne odtworzenie, ponowne uruchomienie hosta, zaplanowana aktualizacja oraz ponowne wdrożenie przez menedżera stosu tworzą usługę z identycznym zanonimizowanym odciskiem środowiska.

Często zadawane pytania

Jaka jest różnica między .env a env_file?

Plik .env projektu zwykle dostarcza wartości interpolacji do Compose, natomiast plik env_file usługi dostarcza zmienne do kontenera. Ich wzajemne oddziaływanie i priorytet zależą od kompletnego modelu Compose.

Czy restart kontenera ponownie wczytuje zmieniony plik env?

Nie. Wartości środowiskowe są ustalane podczas tworzenia kontenera. Zwykle trzeba utworzyć usługę ponownie na podstawie poprawionej konfiguracji Compose.

Dlaczego problem pojawia się dopiero po ponownym uruchomieniu systemu?

Ścieżka uruchamiania po restarcie może korzystać z jednostki systemd, harmonogramu, zmiennych zapisanych przez menedżera, innego katalogu roboczego lub starszej kopii Compose, która różni się od uruchomienia ręcznego.