---
# System prepended metadata

title: SQ08A

---

> [color=#47e8a8]
> [name=Lucas]
> [time=Tue, Apr 04]
> [name=Lukas]
> [time=Tue, Apr 04]
> [[hackmd.io/@LucLukWissM324/By6hvMgbn](https://hackmd.io/-p-oNA4FTiCWimnyeLPtuQ)]
# SQ08A


Für den Build Prozess des Docker Image haben wir jeweils eine Dockerfile Datei in den Datenordnerdes Frontend und des Backends.
## Backend
```dockerfile
# Build stage
FROM maven:latest AS build
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src/ /src/
RUN mvn package -DskipTests

# Run stage
FROM openjdk:latest
WORKDIR /app
COPY --from=build /target/demo-0.0.1-SNAPSHOT.jar /app/
CMD ["java", "-jar", "/app/demo-0.0.1-SNAPSHOT.jar"]
```
Mit dem Befehlt `docker build -t backend:latest ` den Buildprozess starten.
<img src="https://i.imgur.com/iMYTIVO.png" style="filter:drop-shadow(0px 0px 5px black); margin:2vh;">


Das image wurde erfolgreich gebuildet und ist im Docker als image vorhanden.

<img src="https://i.imgur.com/Fxq9Dl2.png" style="filter:drop-shadow(0px 0px 5px black); margin:2vh;">

---

## Frontend
```dockerfile=
FROM node:17-alpine

WORKDIR /frontend

COPY package.json .
COPY package-lock.json .

RUN npm install

COPY . .

EXPOSE 3000

CMD ["npm", "start"]
```

Mit dem Befehl`docker build -t frontend .` den Buildprozess starten.


<img src="https://i.imgur.com/wcBxI1W.png" style="filter:drop-shadow(0px 0px 5px black); margin:2vh;">


---


## Image auf Gitlab

Um den Push der Images auf Gitlab zu ermöglichen mussten wir uns über docker auf Gitlab einloggen.

```bash
docker login registry.gitlab.com -u $name -p $pw
```

Dann den build prozess für front und backend ein weiteresmal ausführen mit dem username und repository als link.

```bash
docker build -t registry.gitlab.com/thisisvv/m324-todoapp/$name:latest .  
```

Nun können die Images auf gitlab gepusht werden.

```bash
docker push registry.gitlab.com/thisisvv/m324-todoapp/$name:latest
```
<img src="https://i.imgur.com/xxEYH8U.png" style="filter:drop-shadow(0px 0px 5px black); margin:2vh;">

<img src="https://i.imgur.com/diEly8A.png" style="filter:drop-shadow(0px 0px 5px black); margin:2vh;">

<img src="https://i.imgur.com/xbNQgZu.png" style="filter:drop-shadow(0px 0px 5px black); margin:2vh;">

Auf der Gitlab Website unter Repository -> "Packages and registries" -> "Container Registry" können wir nun verifizieren ob das Image erfolgreich hochgeladen wurde.

<img src="https://i.imgur.com/7lLVYIG.png" style="filter:drop-shadow(0px 0px 5px black); margin:2vh;">


Docker run des Frontend und Backends

<img src="https://i.imgur.com/CYhRw3q.png" style="filter:drop-shadow(0px 0px 5px black); margin:2vh;">



## Docker Compose File

Das Docker compse FIle hat den zweck, dass die dockerfiles für das Frontend und Backend mit einem Siongle command gestarted werden. Diese images werden direkt von gitlab Repository geladen.

```dockerfile
version: '3'

services:
  backend:
    image: registry.gitlab.com/thisisvv/m324-todoapp/backend
    ports:
      - "8080:8080"
  frontend:
    image: registry.gitlab.com/thisisvv/m324-todoapp/frontend
    ports:
      - "3000:3000"
```

Mit dem command `docker-compose up` werden die images automatisch gestarted.

![](https://i.imgur.com/2vUxIN8.png)

Auf Portainer:
![](https://i.imgur.com/OS6KENH.png)



---

## Was machen die Variabeln CI_JOB_TOKEN und CI_REGISTRY 

Die Variablen `CI_JOB_TOKEN` und `CI_REGISTRY` sind in der Regel Umgebungsvariablen, die in einer Continuous Integration (CI)-/Continuous Deployment (CD)-Pipeline verwendet werden, um Informationen über die aktuellen CI/CD-Jobs und den Container-Registry-Zugriff bereitzustellen.

1.  `CI_JOB_TOKEN`: Dies ist ein Token, das von der CI/CD-Pipeline bereitgestellt wird und Zugriff auf Informationen und Ressourcen des aktuellen CI/CD-Jobs ermöglicht. Es kann verwendet werden, um auf Artefakte zuzugreifen, die während des CI/CD-Jobs erstellt wurden, oder um in anderen Teilen der Pipeline auf Job-spezifische Informationen zuzugreifen. Es handelt sich normalerweise um ein temporäres Token, das nur während der Ausführung des CI/CD-Jobs gültig ist und zur Sicherheit beiträgt.
    
2.  `CI_REGISTRY`: Dies ist eine Umgebungsvariable, die normalerweise den URL des Container-Registrierungsservers enthält, in dem Container-Images für die Verwendung in der CI/CD-Pipeline gespeichert sind. Container-Registrierungen sind Repositories für Container-Images, die von der CI/CD-Pipeline verwendet werden, um Container-Images bereitzustellen und zu verteilen. Der Wert dieser Variable kann in der Pipeline verwendet werden, um auf die Container-Images zuzugreifen oder Container-Images in die Registrierung hochzuladen.



