-
Notifications
You must be signed in to change notification settings - Fork 23
Expand file tree
/
Copy pathcompose.yml
More file actions
246 lines (242 loc) · 10.3 KB
/
Copy pathcompose.yml
File metadata and controls
246 lines (242 loc) · 10.3 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
# #532: a projekt-nevet a top-level `name:` adja (docker compose spec). Ez prefixeli
# a containereket, a volume-okat és a hálózatot — így ugyanez a compose-rendszer több
# példányban futhat egy szerveren (pl. prod + staging) ütközés nélkül. A portokat és az
# image-taget külön env-változó paraméterezi (default = a mostani érték → dev változatlan).
# Docs: https://docs.docker.com/reference/compose-file/version-and-name/
name: ${PROJECT:-miserend}
services:
tmp-init:
image: busybox
volumes:
- tmp:/data
command: sh -c "chown -R 33:33 /data"
restart: "no"
sqlite-init:
image: busybox
volumes:
- sqlite:/data
command: sh -c "chown -R 33:33 /data"
restart: "no"
data-init:
image: ghcr.io/szentjozsefhackathon/miserend-elasticsearch-data:2026.4.18
volumes:
- elasticsearch_data:/data
restart: "no"
# #673: saját OSRM útvonaltervező.
#
# OPCIONÁLIS — `profiles` alatt van, tehát a sima `docker compose up` NEM indítja,
# és a CI-ra sincs hatással. Bekapcsolva:
# docker compose --profile osrm up -d
#
# Miért érdemes: nem pénzt spórol (a mi forgalmunkon a fizetős szolgáltatók is a
# díjmentes keretükön belül vannak), hanem függetlenséget ad: nincs API-kulcs,
# nincs napi limit, és nem tud alólunk kicsúszni egy szolgáltatói feltétel-változás
# (lásd a Stamen 2023-as költözését, ami egy halott csempe-réteget hagyott — #653).
# Cserébe nekünk kell üzemeltetni: ~389 MB RAM és havi újraépítés.
#
# Mért értékek magyarországi kivonaton, car profillal:
# memória futás közben 389 MB | útvonal-válasz 10–20 ms | gráf-építés ~27 s
# csúcs-RAM építéskor 1,9 GB | lemez 306 MB PBF + 588 MB gráf
# A kivonat letöltése külön, busybox-ban: az osrm-backend image-ben NINCS letöltő
# eszköz (se wget, se curl, se nc — kimértem). Ugyanaz a minta, mint a data-init.
osrm-fetch:
image: busybox
profiles: ["osrm"]
volumes:
- osrm_data:/data
- ./osrm/fetch-pbf.sh:/fetch-pbf.sh:ro
environment:
# Kisebb kivonattal is működik (füstteszthez pl. egy andorrányi terület).
- OSRM_PBF_URL=${OSRM_PBF_URL:-https://download.geofabrik.de/europe/hungary-latest.osm.pbf}
- OSRM_FORCE_DOWNLOAD=${OSRM_FORCE_DOWNLOAD:-0}
entrypoint: ["/bin/sh", "/fetch-pbf.sh"]
restart: "no"
osrm-init:
image: ${OSRM_IMAGE:-ghcr.io/project-osrm/osrm-backend:v5.27.1}
profiles: ["osrm"]
volumes:
- osrm_data:/data
- ./osrm/build-graph.sh:/build-graph.sh:ro
environment:
- OSRM_FORCE_REBUILD=${OSRM_FORCE_REBUILD:-0}
entrypoint: ["/bin/sh", "/build-graph.sh"]
restart: "no"
depends_on:
osrm-fetch:
condition: service_completed_successfully
osrm:
image: ${OSRM_IMAGE:-ghcr.io/project-osrm/osrm-backend:v5.27.1}
profiles: ["osrm"]
# `mld` — ehhez kell a partition+customize lépés; cserébe a lekérdezés gyors
# marad úgy is, hogy az élsúlyok frissíthetők teljes újraépítés nélkül.
command: ["osrm-routed", "--algorithm", "mld", "/data/region.osrm"]
volumes:
- osrm_data:/data
ports:
- ${OSRM_PORT:-5000}:5000
restart: always
depends_on:
osrm-init:
condition: service_completed_successfully
networks:
inner:
aliases:
- osrm
# Nincs /health végpont, és letöltő eszköz sincs a képben — ezért bash /dev/tcp-vel
# kérünk egy valódi útvonalat. Nem konkrét `"code":"Ok"`-ot várunk, mert az a gráf
# területétől függ (egy kis kivonaton a budapesti pont NoSegment): azt ellenőrizzük,
# hogy az osrm-routed értelmes JSON-nal válaszol, vagyis fut és betöltötte a gráfot.
healthcheck:
test:
- CMD
- /bin/bash
- -c
- 'exec 3<>/dev/tcp/127.0.0.1/5000 && printf "GET /route/v1/driving/19.04,47.49;19.05,47.50?overview=false HTTP/1.0\r\n\r\n" >&3 && grep -q "\"code\":" <&3'
interval: 15s
timeout: 10s
retries: 10
start_period: 30s
mysql:
image: mariadb:12
volumes:
- db_data:/var/lib/mysql
- ./mysql/initdb.d:/docker-entrypoint-initdb.d
- ./mysql/mysql.conf.d:/etc/mysql/mysql.conf.d
ports:
- ${MYSQL_PORT:-3306}:3306
restart: always
# #668: a jelszavak eddig ide voltak égetve. Az alapértelmezés a régi érték, tehát
# `.env` nélkül minden ugyanúgy megy; egyedit az .env-ben lehet adni.
# A MYSQL_USER/MYSQL_PASSWORD párost maga az image hozza létre, a miserend
# adatbázisra korlátozott jogokkal (ezt használja a kézi restore, l. server.md).
environment:
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:-pw}
MYSQL_DATABASE: miserend
MYSQL_USER: ${MYSQL_USER:-user}
MYSQL_PASSWORD: ${MYSQL_PASSWORD:-pw}
healthcheck:
test: [CMD, mariadb-admin, ping, -h, localhost, -u, "${MYSQL_USER:-user}", "-p${MYSQL_PASSWORD:-pw}"]
timeout: 5s
retries: 10
networks:
inner:
aliases:
- mysql
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:8.10.1
entrypoint: ["/entrypoint-wrapper.sh"]
command: ["eswrapper"]
# #557: az ES-nek eddig NEM volt restart-policyja (a mysql/miserend-nek igen),
# ezért ha elhalt (crash/OOM), halva maradt, amíg valaki kézzel újra nem indította
# → a keresés leállt. Az always-szel a docker magától visszahozza.
restart: always
environment:
- discovery.type=single-node
- ES_JAVA_OPTS=-Xms512m -Xmx512m
- xpack.security.enabled=false
- cluster.name=miserend
ulimits:
memlock:
soft: -1
hard: -1
ports:
- ${ES_HTTP_PORT:-9200}:9200
- ${ES_TCP_PORT:-9300}:9300
volumes:
- elasticsearch_data:/usr/share/elasticsearch/data
- ./elasticsearch/entrypoint.sh:/entrypoint-wrapper.sh:ro
networks:
inner:
aliases:
- elasticsearch
# Az ES lassan áll fel (JVM + cluster-init); a "started" (process indul) != "kész".
# A healthcheck a 9200-on `yellow` cluster-státuszt vár, hogy a rá-épülő miserend
# (és így a tesztek) csak akkor induljanak, ha az ES tényleg fogadja a kéréseket.
healthcheck:
test: ["CMD-SHELL", "curl -fsS 'http://localhost:9200/_cluster/health?wait_for_status=yellow&timeout=1s' > /dev/null || exit 1"]
interval: 10s
timeout: 5s
retries: 30
start_period: 40s
miserend:
image: ${MISEREND_IMAGE:-localhost/miserend:latest}
# #721/#720: itt NINCS `../webapp:/miserend/webapp` bind mount. Korábban volt, és
# eltakarta az image tartalmát: a Dockerfile hiába futtatta le az `ng build`-et a
# megfelelő NG_CONFIG-gal (és a calendar_deploy.py-t), futásidőben a hoszt git-
# checkoutja került a helyére. Így minden környezet a beversenyzett, régi naptár-
# csomagot szolgálta ki. Ugyanezért ragadt be a `vendor_data`/`node_modules_data`:
# a named volume csak az ELSŐ létrehozáskor kapja meg az image tartalmát, a
# production deploy pedig `up -d`-t hív `down -v` nélkül — így egy új composer/npm
# függőség (pl. a leaflet) soha nem jutott ki élesbe.
#
# A fejlesztői mountok a compose.dev.yml-be kerültek. Következmény: a szerveren
# a `webapp/` alatti kézi fájlmódosítás többé NEM érvényesül — a beállítás az
# `.env`-ből jön (a config.php minden értéke env()-en át olvas).
volumes:
# A feltöltött képek futásidőben keletkeznek és a hoszton élnek (a .dockerignore
# ki is hagyja őket az image-ből), ezért ez az egy könyvtár marad bind mount.
- ../webapp/kepek:/miserend/webapp/kepek
- tmp:/miserend/webapp/fajlok/tmp
- sqlite:/miserend/webapp/fajlok/sqlite
- ./miserend/apache/ports.conf:/etc/apache2/ports.conf
ports:
- ${APP_PORT:-8000}:8000
user: "www-data"
restart: "always"
depends_on:
sqlite-init:
condition: service_completed_successfully
mysql:
condition: service_healthy
elasticsearch:
condition: service_healthy
# #610: az SMTP-beállításokat át KELL adni a konténernek. A `.env` önmagában csak a
# compose-fájl interpolációjához kell, a PHP-hez nem jut el belőle semmi. Enélkül a
# config.php alapértéke érvényesült, ami a dev mailcatcher-be küldött minden levelet.
# A `.env` a compose.yml mellé (docker/.env) kerül.
environment:
- MISEREND_WEBAPP_ENVIRONMENT=production
# #668: eddig ez NEM volt átadva, ezért a config.php beégetett root/pw
# alapértéke érvényesült, és az .env-ben hiába állított volna bárki mást.
- MYSQL_MISEREND_USER=${MYSQL_MISEREND_USER:-root}
- MYSQL_MISEREND_PASSWORD=${MYSQL_MISEREND_PASSWORD:-pw}
# #171: a konténer maga ütemezze-e a cront. Alapból ki: az éles telepítés ma a
# hosztról ütemez, és ha mindkettő menne, kétszer futna minden munka.
- CRON_ENABLED=${CRON_ENABLED:-0}
- CRON_INTERVAL=${CRON_INTERVAL:-300}
- SMTP_HOST=${SMTP_HOST:-}
- SMTP_PORT=${SMTP_PORT:-25}
- SMTP_USER=${SMTP_USER:-}
- SMTP_PASSWORD=${SMTP_PASSWORD:-}
- SMTP_SECURE=${SMTP_SECURE:-}
# OSM letöltéshez, és méginkább módosításhoz szükség lehet adatokra
# a .env.example alapján a .env -ben vannak megadva
# a config.php -ban van default, vagy innen veszi
- OSM_URL=${OSM_URL:-}
- OSM_CLIENT=${OSM_CLIENT:-}
- OSM_CLIENT_SECRET=${OSM_CLIENT_SECRET:-}
- OSM_APPLICATION_CODE=${OSM_APPLICATION_CODE:-}
- OSM_ACCESS_TOKEN=${OSM_ACCESS_TOKEN:-}
# A LoRaWAN gyóntatás-jelzők megosztott titka. Üresen a végpont a régi módon,
# azonosítás nélkül fogad adatot — l. Api\LoRaWAN::checkSharedSecret().
- LORAWAN_TOKEN=${LORAWAN_TOKEN:-}
# Az alap overpass túlterhelt lehet. Lásd: .env.example
- OVERPASS_API_URL=${OVERPASS_API_URL:-}
# Opcionális lokális útvonaltervező. Lásd: docs/osrm.md
- OSRM_URL=${OSRM_URL:-}
networks:
inner:
aliases:
- miserend
networks:
inner:
driver: bridge
volumes:
db_data: {}
elasticsearch_data: {}
# #673: a letöltött PBF és a belőle épített gráf. Csak az `osrm` profillal jön létre.
osrm_data: {}
tmp: {}
sqlite: {}
vendor_data:
node_modules_data: