Container, CI/CD

class: center, middle, first

# Software-Entwicklung 3

## Container, CI/CD

---

# Agenda

1. Recap
2. Container
3. CI/CD
---

# Recap: Was haben wir in der letzten Vorlesung besprochen?

* Build Management mit Maven
* Testing mit JUnit

> Blick ins [Repository](https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2023projekt)

---
class: center, middle
# Was muss getan werden um eine (Server-)Anwendung zu starten? Was sind die Probleme?

???

* Umgebung einrichten
* Unterschiedliche Versionen (Libraries, OS)
* Kompatibilitätsprobleme

---
# Möglichkeiten zur Problemlösung

* ...
* Virtuelle Maschinen
* Containerisierte Anwendungen

> Kapselung der Anwendung mit zugehöriger Umgebung
---
# Virtuelle Maschinen

_Schematische Darstellung_

---
# Container

_Schematische Darstellung_

---
# Docker

* Umsetzung für Container
* Erste Version 2013
* Container sind OCI (Open Container Initiative) kompatibel
* Enthält Versionsverwaltung für Images
  * Sammlung von Images auf https://hub.docker.com
* Alternative `podman`
* Teilweise lizenzpflichtig (Docker Desktop)
* `root`-Problematik

---
# Begriffe

**Image**: Containerabbild, das sämtliche Applikationen und Konfigurationen enthält. Kann auf bestehenden Images aufbauen.

**Container**: Instanziierung eines Images. Aus einem Image können beliebig viele Container gestartet werden.

**Dockerfile**: Beschreibt die Konfiguration eines Images.

**docker-compose.yml**: Konfigurationsdatei zur Ausführung ein oder mehrere Container.

---
# Grundprinzipien

* Jeder Container sollte nur einen Zweck erfüllen
* In Containern werden keine persistenten Daten gespeichert
* Sollen Daten persistiert werden, können z.B. `Volumes` oder `bind mounts` genutzt werden
* (weitere Prinzipen können folgen, abhängig von der Systemarchitektur)

---
# Beispiele

* Bauen eines Containers
* Starten eines Containers
* Containerzugriff
* Einbinden von Dateien des Hostsystems
* Zusammenfassendes Beispiel mit `docker compose`

## Dokumentationen/Links
* [Docker Installation](https://docs.docker.com/compose/install/)
* [Dockerfile](https://docs.docker.com/engine/reference/builder/)
* [Docker Compose - Getting started](https://docs.docker.com/compose/gettingstarted/)
* [Nginx Docker Doku](https://hub.docker.com/_/nginx)

---
# Bauen eines Containers

## `Dockerfile`

```
FROM nginx
COPY html-dir /usr/share/nginx/html
```
## Bauen

```bash
docker build -t se3-nginx:0.0.1 .
```
---
# Starten eines Container

```bash
# Starten
docker run --rm -d se3-nginx:0.0.1

# Prüfen, ob der Container läuft
docker ps

# Logs überprüfen (Containername entweder beim Start vergeben
# oder per docker ps)
docker logs <CONTAINER NAME>

# Container beenden
docker stop <CONTAINER NAME>
```
---
# Containerzugriff

```bash
docker run --rm -d - p 8080:80 se3-nginx:0.0.1
```
## Öffnen der Website
> http://localhost:8080

## Alternative Variante (ohne Dockerfile)
```bash
docker run --rm -d -p 8081:80 -v $(pwd)/html-dir:/usr/share/nginx/html:ro nginx
```
---
# `docker-compose`

```yaml
version: '2'
services:
  web:
    image: nginx
    volumes:
      - "./html-dir:/usr/share/nginx/html:ro"
    ports:
      - "8082:80"
```

## Start
`docker-compose.yml` muss sich im aktuellen Verzeichnis befinden

```bash
# Mit Apple Silicon Chip "docker compose", sonst "docker-compose"
docker compose up -d
```

---
class: center, middle

# CI/CD

## Continuous Integration & Continuous Deployment

---
# Was ist Continuous Integration?

_nach ["What is Continuous Integration?", AWS, 2022](https://aws.amazon.com/devops/continuous-integration/?nc1=h_ls)_

* DevOps-Verfahren
* Zentrales Repository
* Automatisiertes testen und bauen der Anwendung
* Früher:
  * Isolierte Arbeit an einzelnen Aufgaben
  * Code wurde spät zusammengeführt (=Integration)
* Ziele:
  * Bugs früher erkennen
  * Kürzere Veröffentlichungszeiten
  * Steigerung der Produktivität -> Warum?

---
# Mögliche Continuous Integration Vorgehensweise

_angepasst nach ["Continuous Integration", Martin Fowler, 2006](https://www.martinfowler.com/articles/continuousIntegration.html)_

* Code muss zentral in einem Repository abliegen. Definition eines Integrationsbranches.
* Automatisieren des Build-Prozesses
* Automatisieren des Test-Prozesses
* Regelmäßiger `merge` auf den Integrationsbranch
* Jeder `commit` auf den Integrationsbranch baut die Anwendung
* Schlägt ein Build fehl, soll dieser so schnell wie möglich repariert werden
* Build-Zeiten so schnell halten (nicht immer möglich)
* Testen in einem Klon der Produktionsumgebung
* Einfaches Bereitstellen der aktuellsten (kompilierten) Version

---
# Was ist Continuous Deployment?

_nach ["What is Continuous Deployment?", AWS, 2022](https://aws.amazon.com/devops/continuous-delivery/)_

* Automatisches Veröffentlichen der Software auf einer Testumgebung
* Unterschied zu Continuous Deployment
  * Continuous Deployment: Automatische Veröffentlichung auf Produktionsumgebung
  * Continuous Delivery: Manuelle Veröffentlichung inkl. Freigabe auf Produktionsumgebung
---
# Was ist Continuous Deployment?

_nach ["What is Continuous Deployment?", AWS, 2022](https://aws.amazon.com/devops/continuous-delivery/)_

---
# CI/CD mit GitLab

* Repository wird für CI/CD genutzt
* (Shared) Runner führen Aktionen in definierten Phasen(=Stages & Jobs) aus
* Eine Stage kann ein oder mehrere Jobs enthalten
* Ein Job kann auf einem Container-Image basieren
* Innerhalb des Image können Skripte ausgeführt werden
* Eine Pipeline besteht aus einer oder mehreren Stages

---
# Beispiel CI/CD mit GitLab

* Beschreibung in `.gitlab-ci.yml`
* Voraussetzungen:
  * CI/CD-Funktionen wurden für das Repo aktiviert: Settings ➡️ General ➡️ Visibility, project features, permissions ➡️ CI/CD (aktivieren)
  * Runner wurden zugewiesen: Settings ➡️ CI/CD ➡️ Runners ➡️ Enable shared runners for this project

> Blick ins [Projekt](https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2023projekt)