Documentation overhaul (TESTING/CONTRIBUTING/ARCHITECTURE/SECURITY/CLAUDE.md, CHANGELOG.md, drop unmaintained src/README.md) plus CI-built Docker images: Gitea Actions now builds and pushes the servicedesk image to the Gitea container registry on Dockerfile changes, and compose.yaml pulls that image instead of building locally. No application behavior changes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
64
install.md
64
install.md
@@ -28,9 +28,17 @@ osobne pliki, w dwóch różnych miejscach.
|
||||
na hosta (`ports: ["8080:80"]`) i obsłużyć TLS inaczej (patrz sekcja 2 niżej, w
|
||||
razie potrzeby reverse-proxy przed kontenerem).
|
||||
|
||||
### 1.1. Plik `.env` w katalogu głównym (Docker Compose)
|
||||
### 1.1. Pliki `compose.yaml` i `.env` w katalogu głównym
|
||||
|
||||
Skopiuj/utwórz `.env` obok `compose.yaml`:
|
||||
Oba są celowo `.gitignore`'owane (podobnie jak `src/.env`) — kopiujesz je z
|
||||
szablonów przy pierwszym wdrożeniu, a potem edytujesz lokalnie:
|
||||
|
||||
```bash
|
||||
cp compose.yaml.example compose.yaml
|
||||
cp .env.example .env
|
||||
```
|
||||
|
||||
`.env`:
|
||||
|
||||
```env
|
||||
HOSTNAME=servicedesk.twoja-domena.pl
|
||||
@@ -38,6 +46,7 @@ MYSQL_ROOT_PASSWORD=wygeneruj-silne-haslo
|
||||
MYSQL_DATABASE=servicedesk
|
||||
MYSQL_USER=servicedesk
|
||||
MYSQL_PASSWORD=wygeneruj-inne-silne-haslo
|
||||
# IMAGE_TAG=latest
|
||||
```
|
||||
|
||||
- `HOSTNAME` — domena, pod którą Traefik wystawi aplikację (trafia do reguły
|
||||
@@ -45,6 +54,8 @@ MYSQL_PASSWORD=wygeneruj-inne-silne-haslo
|
||||
- `MYSQL_*` — dane bazy dla kontenera `mariadb`; `MYSQL_USER`/`MYSQL_PASSWORD` to
|
||||
**te same** wartości, które za chwilę wpiszesz do `src/.env` jako `DB_USERNAME`/
|
||||
`DB_PASSWORD`.
|
||||
- `IMAGE_TAG` — który tag obrazu `servicedesk` wdrożyć (patrz sekcja 1.3a); domyślnie
|
||||
`latest`, jeśli zmienna nie jest ustawiona.
|
||||
|
||||
### 1.2. Plik `src/.env` (Laravel)
|
||||
|
||||
@@ -100,17 +111,52 @@ MAIL_FROM_ADDRESS=noreply@twoja-domena.pl
|
||||
MAIL_FROM_NAME="${APP_NAME}"
|
||||
```
|
||||
|
||||
### 1.3. Budowa i start kontenerów
|
||||
### 1.3. Start kontenerów
|
||||
|
||||
Obraz `servicedesk` **nie jest budowany lokalnie** — `compose.yaml` odwołuje się
|
||||
do obrazu zbudowanego przez CI i wypchniętego do rejestru kontenerów Gitea (patrz
|
||||
1.3a). Uruchomienie stacka to więc zawsze:
|
||||
|
||||
```bash
|
||||
docker compose up -d --build
|
||||
docker compose pull
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
`--build` jest potrzebny **tylko przy pierwszym uruchomieniu** (budowa obrazu z
|
||||
`Dockerfile`). Później, przy zwykłych zmianach w kodzie PHP/Blade — źródło jest
|
||||
zamontowane z `./src`, więc `docker compose restart` (albo nic — Laravel odświeża
|
||||
się natychmiast) wystarczy; `--build`/`docker compose build` uruchamiaj tylko gdy
|
||||
zmienia się sam `Dockerfile`.
|
||||
Przy zwykłych zmianach w kodzie PHP/Blade nic więcej nie trzeba robić — źródło
|
||||
jest zamontowane z `./src`, Laravel odświeża się natychmiast. `docker compose
|
||||
pull` uruchamiaj ponownie tylko wtedy, gdy chcesz podnieść nowszy tag obrazu
|
||||
(np. po zmianie w `Dockerfile` i przebudowie przez CI).
|
||||
|
||||
### 1.3a. Automatyczne budowanie obrazu (CI, Gitea Actions)
|
||||
|
||||
`.gitea/workflows/build.yml` buduje i wypycha obraz do wbudowanego rejestru
|
||||
kontenerów Gitea (`gitea.kzbikowski.pl/kzbkowski/servicedesk`) po każdym pushu na
|
||||
`main`, który zmienia `Dockerfile` (celowo nie odpala się na zwykłe zmiany w
|
||||
`src/` — obraz nie zawiera kodu aplikacji, tylko PHP/Apache/rozszerzenia, więc
|
||||
przebudowa dla samego kodu byłaby marnowaniem czasu CI). Wypycha dwa tagi:
|
||||
`latest` i `<sha commita>`.
|
||||
|
||||
To **tylko build + push** — świadomie bez auto-deployu na produkcję. Po tym jak
|
||||
CI skończy, wdrożenie nowego obrazu na serwerze wciąż jest ręcznym krokiem:
|
||||
|
||||
```bash
|
||||
cd /ścieżka/do/repo
|
||||
docker compose pull
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
Zanim to zadziała po raz pierwszy, potrzebne jest jednorazowe zalogowanie hosta
|
||||
produkcyjnego do rejestru Gitea (żeby `docker compose pull` miał czym
|
||||
autoryzować pobranie obrazu, jeśli repozytorium/paczka nie są publiczne):
|
||||
|
||||
```bash
|
||||
docker login gitea.kzbikowski.pl -u <twoja-nazwa-uzytkownika>
|
||||
```
|
||||
|
||||
Jeśli to zupełnie pierwsze wdrożenie (rejestr jeszcze nie ma żadnego wypchniętego
|
||||
obrazu `servicedesk`) — poczekaj, aż workflow CI przejdzie choć raz (np. przez
|
||||
push/PR zmieniający `Dockerfile`, albo ręczne odpalenie z zakładki Actions w
|
||||
Gitea), zanim spróbujesz `docker compose pull` na serwerze.
|
||||
|
||||
### 1.4. Instalacja aplikacji wewnątrz kontenera
|
||||
|
||||
|
||||
Reference in New Issue
Block a user