Wie integriere ich Git mit Docker? (Verwendung von .dockerignore und .gitignore)

.dockeringore und .gitignore können sich nicht gegenseitig ersetzen, da sie unterschiedliche Objekte und Timings haben: Ersterer steuert die Kontextübertragung während des Builds und Letzterer steuert die Übermittlung des Code-Repositorys, wobei ignoriert wird, dass die Regeln nicht interoperabel sind und das grammatikalische Verhalten unterschiedlich ist.

Warum .dockerignore und .gitignore sich nicht gegenseitig ersetzen

Weil ihre Ziele und ihr Timing völlig unterschiedlich sind: .gitignore steuert, welche Dateien nicht in das Git-Repository eingegeben werden, während .dockerignore steuert, welche Dateien während docker build nicht an den Docker-Daemon gesendet werden. Selbst wenn eine Datei durch .gitignore ausgeschlossen wird, kann Docker sie dennoch packen, solange sie im Build-Kontextverzeichnis vorhanden ist – dies verlangsamt den Build, legt vertrauliche Informationen offen und führt sogar dazu, dass das Image nicht gestartet werden kann.

• Häufige Fehler: COPY . /app in Dockerfile bringt node_modules oder .env in das Image, aber der lokale git status zeigt, dass diese Dateien überhaupt nicht verfolgt werden.
• Verwendungsszenario: In der CI/CD-Pipeline wird das Git-Warehouse geklont und direkt docker build . Zu diesem Zeitpunkt ist der Build-Kontext das gesamte Arbeitsverzeichnis .dockerignore ist die einzige Verteidigungslinie.
• Auswirkungen auf die Leistung: Das Ignorieren großer Verzeichnisse (z. B. dist/ , __pycache__/ ) kann das Kontextübertragungsvolumen erheblich reduzieren, insbesondere bei Remote-Buildern (z. B. docker/build-push-action von GitHub Actions).

So schreiben Sie .dockerignore und leicht zu übersehende Pfade

Seine Syntax ähnelt .gitignore , aber sein Verhalten ist einfacher – es unterstützt nur den Präfixabgleich und kein ** Platzhalterzeichen (Docker 24.0 hat mit der experimentellen Unterstützung begonnen, aber die meisten Produktionsumgebungen verwenden immer noch die alte Version). Das Kritischste ist: Es liest nicht .dockerignore im Unterverzeichnis, sondern nur das im Stammverzeichnis.

• Muss explizit ignoriert werden: node_modules/ (der abschließende Schrägstrich gibt das Verzeichnis an), .git , .DS_Store , README.md (falls es im Bild nicht benötigt wird)
• Einfache Fallstricke: log/ kann ./log/ ignorieren, aber nicht src/log/ ; es muss als **/log/ geschrieben werden (aus Gründen der Kompatibilität mit älteren Versionen können zwei Zeilen geschrieben werden: log/ und */log/ )
• Achten Sie auf die Reihenfolge: Die vorherigen Regeln überschreiben die folgenden nicht, Leerzeilen und Kommentare, die mit # beginnen, werden jedoch übersprungen; ! Die Verneinung gilt nur für die unmittelbar nächste Zeile und ist daher mit Vorsicht zu verwenden

So koordinieren Sie, wenn Git und Docker Richtlinienkonflikte ignorieren

Ein typischer Konflikt ist: Sie möchten, dass .env weder in Git noch im Image enthalten ist, es aber während der Entwicklung vorhanden sein muss – dann sollten sowohl .gitignore als auch .dockerignore es schreiben, aber der Docker-Build-Befehl selbst muss diese Einschränkung umgehen (z. B. durch die Verwendung --secret oder die Injektion der Mount-Methode).

• Verwendungsszenario: Bereitstellung in mehreren Umgebungen, .env.production wird in Git ignoriert, aber während der CI-Erstellung ist eine sichere Injektion erforderlich
• Parameterunterschiede: docker build --secret id=env,src=.env.production . Es ist sicherer, als .env in das Bild zu zwingen; Dementsprechend muss .env weiterhin in .dockerignore beibehalten werden
• Auswirkungen auf die Kompatibilität: Ältere Versionen von Docker (--secret nicht und können sich nur auf den Build-Parameter --build-arg verlassen, um den Wert zu übergeben. Bei dieser Methode verbleibt der Wert jedoch im Bildebenenverlauf. Vermeiden Sie unbedingt die Weitergabe des Schlüssels.

Praktische Methode zur Überprüfung, ob .dockerignore wirksam ist

Achten Sie nicht nur darauf, ob die Datei in git status aufgeführt ist, sondern stellen Sie auch sicher, dass sie nicht im Build-Kontext enthalten ist. Der direkteste Weg besteht darin, Dockerfile vorübergehend zu ändern und einen Schritt zum Überprüfen des Befehls hinzuzufügen.

• Praktische Vorschläge: Fügen Sie RUN find . -name ".env" -o -name "node_modules" | head -20 am Anfang Dockerfile und dann docker build --no-cache . Prüfen Sie, ob die Ausgabe leer ist
• Häufiges Fehlerphänomen: Sending build context to Docker daemon 125.6MB im Build-Protokoll angezeigt, und die Zahl ist weitaus höher als erwartet – ein Hinweis darauf, dass .dockerignore nicht funktioniert. Höchstwahrscheinlich ist der Pfad falsch geschrieben oder der Speicherort ist falsch (er muss in dem Verzeichnis abgelegt werden, in dem sich docker build befindet).
• Debugging-Fähigkeiten: Führen Sie tar -cf - . | tar -t | grep -E "(node_modules|\.env)" | head -10 , um den Prozess des Docker-Verpackungskontexts zu simulieren und Fische, die durch das Netz gerutscht sind, schnell zu lokalisieren

Das eigentliche Problem besteht nicht darin, eine falsche Reihe von Regeln zu schreiben, sondern in der Standardvermutung, dass „da Git sich nicht darum kümmert, sollte sich Docker auch nicht darum kümmern“ – diese Annahme ist im Containerisierungsprozess fast immer falsch.

Das obige ist der detaillierte Inhalt vonWie integriere ich Git mit Docker? (Verwendung von .dockerignore und .gitignore). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!