Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie Source2Image - Vom Code zum fertigen Image mit einer Build-Chain basierend auf Docker
Ähnlich wie Source2Image - Vom Code zum fertigen Image mit einer Build-Chain basierend auf Docker (20)
Source2Image - Vom Code zum fertigen Image mit einer Build-Chain basierend auf Docker
- 1. SOURCE TO IMAGE Vom Code zum fertigen Image mit einer Build-Chain basierend auf Docker
- 2. Agenda Source to Image 2 1 Konzeption von Build-Vorgängen 2 Warum Build-Vorgänge auslagern? 3 Demonstration 4 Fazit
- 4. Konzeption von Build-Vorgängen Source to Image 4 Source- Code Container • Build-Artefakte werden im Container generiert • Nicht mehr notwendige Build-Dependencies sind zur Laufzeit verfügbar • Simple Lösung • Schnell zu implementieren
- 5. Konzeption von Build-Vorgängen Source to Image 5 Source- Code Build- Container Service- Container Binary • Build-Artefakte werden in einem gesonderten Container erzeugt • Build-Dependencies sind zur Laufzeit nicht mehr verfügbar • Leichtgewichtigere Service-Container
- 6. Konzeption von Build-Vorgängen Source to Image 6 Source- Code Build- Container Service- Container Binary Source- Code Service- Container Service- Container Binary
- 7. InfrastrukturArtefakt-VerwaltungContinious- Integration Source-Code- Verwaltung Konzeption von Build-Vorgängen Source to Image 7 Source- Code Build- Container Service- Container Binary Source- Code Service- Container Service- Container Binary
- 9. Vorteile Source to Image 9 Sicherheit Gesteigerte Build-Geschwindigkeit • Reduzierte Downloadzeit • Schnellere Buildvorgänge für Artefakte Performance • Kleinere Images • Keine unnötigen Dateien Einheitliche Builds • Build-Container /-Images sind immer gleich • Keine fehlenden Dependencies • Weniger potentielle Schwachstellen • Leichte Wartbarkeit
- 10. Demonstration
- 11. Demonstration - Grundlagen Source to Image 11 • Aufbau des Dockerfiles für den Build- Vorgang und die Bereitstellung • Je nach Phase ändern sich Passagen Simpler Webservice basierend auf GO - Kompilierte Größe: 3,9 MB Anwendung Dockerfile
- 12. Demonstration Source to Image 12 Phase 1 - Build-Vorgang mit Standards • Full-Image mit allen Build-Dependencies • Golang-onbuild Image wird verwendet
- 13. Demonstration Source to Image 13 Verwendung des Standardimages • Alle Build-Dependencies sind noch enthalten • Nicht notwendige Binaries sind enthalten Phase 1 - Fazit
- 14. Demonstration Source to Image 14 Phase 2 - Build-Vorgang mit kleinerem Grundimage • Kleineres Image mit allen Dependencies • golang:alpine Image wird verwendet
- 15. Demonstration Source to Image 15 Verkleinerung des Images durch Verwendung des Golang:Alpine-Images • Geringere Größe als das Standardimage für GO • Unnötige Daten sind noch enthalten • Gute Grundlage für einen Build-Container Phase 2 - Fazit
- 16. Demonstration Source to Image 16 Build- Container Service- Container Binary Möglichkeiten für diesen Vorgang: • Verwendung von “docker cp“ Beispiel: docker cp IDCONTAINER:/go/bin/pokedex /tmp/ • Verwendung von Volumes Beispiel: docker run -v /tmp/:/tmp IMAGENAME • Verwendung von Docker in Docker Auslagerung des Build-Vorgangs
- 17. Demonstration Source to Image 17 Verkleinerung des Laufzeit-Images durch Verwendung des Alpine-Images • Geringe Größe • Extrahierung der Binaries • Reduktion auf das Notwendigste Phase 3 - Fazit
- 18. Demonstration Source to Image 18 Durch Verwendung eines Images von Scratch erhalten wir noch eine kleine Reduktion • Geringere Größe • Minimalste Bereitstellung Phase 4 - Fazit
- 19. Fazit Source to Image 19 Golang Golang:Alpine Alpine Scratch 709 MB 263 MB 7.99 MB 4.01 MB 30 Sicherheitslücken 30 Sicherheitslücken 0 Sicherheitslücken 0 Sicherheitslücken Geringer Aufwand Geringer Aufwand Gesteigerter Aufwand Hoher Aufwand
- 20. VIELEN DANK FÜR IHRE AUFMERKSAMKEIT Franz-Schubert Straße 75 70195 Stuttgart +49 711 699 475 60 info@dibuco.de www.dibuco.de