Läuft der Server auf Docker?
Wir hatten schonmal das Problem das es aus irgendwelchen Gründen bei „nicht-Docker“ Installationen weiter mit der alten Version lief.
Da half nur ein Neustart des Rechners / VM.
Ja der läuft in einem Docker container. Es wurde der Docker prozess schon mal neu gestartet und die komplette Proxmox VM ebenfalls.
Das komische ist, das es auch manchmal funktioniert hat und dieses mal wieder nicht
Hallo,
ich spiele jetzt schon einige Zeit damit rum aber bekomme es nicht hin, einen Alarmiator Server aufzusetzen der nur lokal läuft.
Um das ganze oben in einem komplett jungfräulichen Server zu testen, wollte ich den Alarmiator Server in einem Docker neu aufsetzen. Dies ging auch ohne Probleme.
jedoch macht mir hier der 2te Proxy vom ersten Alarmiator probleme.
Gibt es daher eine Möglichkeit das docker compose.yml so anzupassen, das der Alarmiator nur lokal ohne proxy und das ganze zertifikat zeug läuft und ich den z.b. über http://192.168… erreichen kann?
Die Alternative wäre den „produktiven“ Alarmiator abzuschalten und einen Testserver an diese Stelle zu setzen. Aber da es das letzte mal mehrere Stunden gedauert hat, wäre das nicht die optimalste Lösung.
Hallo,
habs geschafft, musste das docker compose etwas abändern.
Nun funktioniert es auch das bei einem Alarm die weiteren Einsatzmittel mit angezeigt werden, jedoch ist mir aufgefallen das es bereits die Version 1.4.3 ist. Werde mal den „produktiv Server“ auch patchen und dort erneut versuchen. Sollte es da nun auch gehen ist vorerst alles ok.
Sollte es nicht gehen werde ich wohl oder übel den Server inkl. Betriebssystem neu aufsetzen dürfen.
Hey,
kannst du mal zeigen was du im Docker Compose geändert hast? Ich hab leider noch nicht genau verstanden was du in deiner Nachricht heute Mittag genau meintest.
Wenn dein Produktiv Server auf Docker läuft sollte es ja schnell geupdated sein. Mach dir davor wie immer ein Backup und sichere es auf einem anderen Rechner. Da es ab Version 1.4.2 eine kleine Änderung gab bezüglich des Docker Compose Files, welche in unserem Update Guide vermerkt ist Update des ALARMiator Servers – ALARMiator – Handbuch empfehle ich das nochmal durchzugehen just in case : D
Hallo,
in meinem Docker Compose hab ich alles rausgeworfen, was mit dem Proxy zu tun hat und hab dem Alaramiator Server den port 5000 mitgegeben:
version: '3.0'
networks:
alarmiator-network:
name: alarmiator-network
driver: bridge
services:
alarmiator_service:
networks:
- alarmiator-network
ports:
- "5000:5000"
restart: always
image: alarmiator/alarmiator:latest-amd64
healthcheck:
test: curl --fail http://localhost:5000 || exit 1
interval: 20s
retries: 5
start_period: 600s
timeout: 10s
volumes:
- alarm-db:/alarmiatorserver/store
- alarm-katsys:/alarmiatorserver/plugins/inbound/katsys
- alarm-public-img:/alarmiatorserver/public/assets/img
- alarm-uploads:/alarmiatorserver/uploads
- alarm-logs:/alarmiatorserver/logs
volumes:
alarm-db:
alarm-katsys:
alarm-public-img:
alarm-uploads:
alarm-logs:
Ich hatte ursprünglich
Proxmox und da drauf Debian mit Docker und Alarmaitor 1.4.2 leider war dabei immer das Problem, bei einigen Alarmen die „weiteren Alaramierten Einsatzmittel“ weder im Alarmiator angezeigt noch auf der Alarmdepeche abgedruckt war.
Semurak
Meinte dann, das evtl da das Problem liegt.
Ich hab mir nun
Proxmox>Ubuntu>Docker aufgesetzt und dort den Alarmiator mit dem oben stehen Docker compose erstellt um mal zu testen wie es dann aus sieht.
Siehe da, hier werden die weiteren Mittel angezeigt.
Um aber das „testsystem“ und das „produktivsysem“ parallel laufen lassen zu könne, musste ich direkt auf das Testsystem. Ohne Proxy usw.
Lange rede kurzer sinn. Ich muss den Debian Server platt machen und alles neu auf Ubuntu aufsetzen.
Gruß Andreas
Wenn ich es richtig verstehe hast du auf einem Rechner folgendes stand jetzt installiert:
- Proxmox1:
- Debian
- ALARMiator Produktiv
- Nginx Proxy
- Debian
- Proxmox2:
- Ubuntu:
- ALARMiator Test
- Ubuntu:
Stimmt das so?
Ich kenne mich nicht mit Proxmox aus aber dein physikalischer Rechner auf dem alles läuft hat ja nur einen Port 80 deshalb kannst du wahrscheinlich keine zwei Proxies laufen lassen (deshalb hast du ja das compose file angepasst), da diese beide auf die Standardports 80 und 443 zugreifen wollen.
Was aber normalerweise sehr wohl geht ist beide ALARMiator Instanzen mit einem Proxy laufen zu lassen (egal in welchem virtualisiertem Rechner dieser läuft), da er ja zwischen deinen beiden Virtuellen Rechnern weiterleiten kann je nachdem wie du die Proxmox Rechner konfiguriert hast. (Ich bin mir nicht sicher, ob du das mal vor hattest von deiner ersten Nachricht heute Mittag)
Nun zum neu installieren. Ich verstehe noch nicht genau wieso du jetzt den ganzen Produktiv Server neu installieren möchtest?
Hallo,
das ursprüngliche Problem war das:
Das wurde mit der Version 1.4.2 behoben.
Ich habe auf meinen:
- Proxmox1:
- Debian
- ALARMiator Produktiv
- Nginx Proxy
- Debian
Die Version 1.4.2 bzw nun die 1.4.3 laufen. jedoch besteht das Problem immer noch.
auf meinem *
- Proxmox2:
- Ubuntu:
- ALARMiator Test
- Ubuntu:
läuft die Version 1.4.3 dort haben wir das Problem nicht.
daher sehe ich momentan keine andere Möglichkeit den Server neu zu installieren. Oder gäbe es eine Möglichkeit den Alarmiator Dockercontainer auf dem System:
- Proxmox1
zu löschen und neu zu installieren.
Denn, den kompletten Server inkl OS neu zu installieren ist schon etwas arbeit.
gruß
OK verstehe einen Versuch ist es Wert.
Es gibt für Docker Befehle um Container zu entfernen.
docker compose down
docker compose ps -a
Zeigt dir alle container an
.```
docker compose rm {id}
Entfernt einen Container vollständigDu hast oben gemeint das 2 Alamiator hinter einem Proxy laufen könnten.
Das vermute ich auch aber mein Problem ist das dabei:
und natürlich auch in den Cumtom locations:
Kann man da evtl. in dem docker Compose einen anderen namen zuweisen z.b.
http://alarmiator_service2:5000
Wenn ja wie?
dann denke ich sollte das auch mit 2 Alarmaitoren hiner einem Proxy funktionieren.
Gruß Andreas
Gibt hier mehrere Optionen:
Option 1: Mit zwei Proxmox
Hier musst du selber schauen, weil ich mich nicht auskenne aber du müsstest die Docker Container Ports über die Ports (Ich nehme mal unsere Standardports) auf deiner Proxmox mappen und dann könntest du im anderen Proxmox mit Proxy sowas machen wie http://proxmox2:5000
Option 2:
Du lässt alles mit einer großen docker compose in einer Proxmox(ginge natürlich auf jedem Rechner) laufen (das ist am einfachsten, weil da kenne ich mich wieder ein wenig aus : D)
version: '3.0'
networks:
alarmiator-network:
name: alarmiator-network
driver: bridge
services:
alarmiator_service:
networks:
- alarmiator-network
restart: always
image: alarmiator/alarmiator:latest-amd64
healthcheck:
test: curl --fail http://localhost:5000 || exit 1
interval: 20s
retries: 5
start_period: 600s
timeout: 10s
volumes:
- alarm-db:/alarmiatorserver/store
- alarm-katsys:/alarmiatorserver/plugins/inbound/katsys
- alarm-public-img:/alarmiatorserver/public/assets/img
- alarm-uploads:/alarmiatorserver/uploads
- alarm-logs:/alarmiatorserver/logs
nginxProxyManager:
networks:
- alarmiator-network
image: 'jc21/nginx-proxy-manager:latest'
restart: always
depends_on:
alarmiator_service:
condition: service_healthy
ports:
- '80:80'
- '81:81'
- '443:443'
healthcheck:
test: curl --fail http://localhost:81 || exit 1
interval: 20s
retries: 5
start_period: 10s
timeout: 10s
volumes:
- /nginx-pm/data:/data
- /nginx-pm/letsencrypt:/etc/letsencrypt
alarmiator_service_test:
networks:
- alarmiator-network
restart: always
image: alarmiator/alarmiator:latest-amd64
healthcheck:
test: curl --fail http://localhost:5000 || exit 1
interval: 20s
retries: 5
start_period: 600s
timeout: 10s
volumes:
- alarm-db-test:/alarmiatorserver/store
- alarm-katsys-test:/alarmiatorserver/plugins/inbound/katsys
- alarm-public-img-test:/alarmiatorserver/public/assets/img
- alarm-uploads-test:/alarmiatorserver/uploads
- alarm-logs-test:/alarmiatorserver/logs
volumes:
alarm-db:
alarm-katsys:
alarm-public-img:
alarm-uploads:
alarm-logs:
alarm-db-test:
alarm-katsys-test:
alarm-public-img-test:
alarm-uploads-test:
alarm-logs-test:
Das gibt dir zwei getrennte ALARMiator Instanzen mit eigener Datenbank usw.
Diese kannst du jetzt wie gewohnt über den nginx proxy ausliefern lassen. Du brauchst halt pro Instanz eine Domain bzw. Subdomain
Hello,
ich versuche mal kurz zusammenzufassen wie ich einen zweiten Server auf einem anderen Rechner (IP 192.168.0.23) zum laufen bekommen habe:
- Firewall port 80 und 443 im router für die IP 192.168.0.23 freigeben
- Die Ports 5000, 5010, 5020 ,5555 in der Ubuntu Firewall freigeben.
- „Test alarmiator“ mit einem Teil des oben geschriebenen docker compose (ohne nginx proxy da dieser bereits auf dem andern Server läuft) ausgeführt
- nginx proxy auf dem anderen Server öffnen und eine eigenen (neue domain) für den Testserver anlegen
und noch folgende Konfig für den Test Server hinterlegen:
Danach konnte ich über die die alte Domain auf den normalen Alarmiator Server und über die neue Domain auf den Testserver.
Freut mich, dass es so funktioniert wie du dir das vorgestellt hast mit den zwei Servern. Das ist dann quasi Option 1 mit zwei Proxmox Rechnern richtig?
Hast du jetzt noch das Problem, dass auf deinem Produktivserver das Update nicht funktioniert?
Genau Option 1.
Ja das Problem besteht immer noch.
Ich bin aber da auch nicht ganz schlau draus geworden.
wenn ich den Alarmiator docker container das erste mal installiere lädt er 100e MB runter und es dauert etwas.
Bei dem Vorgehen mit dem Löschen und neu aufspielen hat das ganze nur ein paar Sekunden gedauert.
Er läuft auf der Version 1.4.3 aber hat immer noch das Problem aus 1.4.1.
Ich bin etz mal her gegangen hab ein backup vom produktiven gezogen, das auf Test eingespielt und dort einen Datensatz aus der Produktiv katsys schnittstelle eingespielt.
Siehe da „work as expected“ .
Da ist irgendwas bei dem Update kaputt gegangen oder hängen gelblieben.
Alles klar ich war vorhin unterwegs und am Handy die ganzen Docker Befehle formatieren ist doof.
Das mit dem schnellen Download liegt daran, dass ein Image nicht gleich ein Container ist und das Image noch auf deinem Rechner gespeichert ist auch wenn die „Instanz“ der Container gelöscht wurde. Ein Image ist quasi alle Installationsschritte und ein Container ist Image + Daten ab dem ausführen des Images.
Du kannst Images wie folgt löschen:
docker image ls
Zeigt dir die Images an, welche auf dem Rechner liegen
docker image rm {id}
Entfernt ein Image
Mit den Befehlen von vorhin kannst du also den Container entfernen. Das Image löschen und dann nochmal alles neu runterladen.
Wenn du ein Backup gemacht hast kannst du zusätzlich noch die volumes löschen mit den gleichen Befehlen nur statt image immer
docker volume bla
Das löscht dann die virtuellen „Festplatten“ die benutzt werden um deine Datenbank und so weiter zu speichern.
Ich weiß leider wirklich nicht genau woran es liegt, dass dein einer Rechner nicht ordentlich updaten will.
Wenn du also Container, Image und Volume löscht sollte alles von der vorherigen Installation weg sein.
Danke für die Erklärung.
Hier schon mal den ls
root@alarmiator:/home/flan# docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
alarmiator/alarmiator latest-amd64 c8fd9f473442 3 weeks ago 2.66GB
alarmiator/alarmiator 59f0b016e746 5 weeks ago 2.76GB
jc21/nginx-proxy-manager latest 219fa0ba0547 6 weeks ago 843MB
eclipse-mosquitto 2-openssl d7cca5da912e 4 months ago 7.1MB
eclipse-mosquitto 2.0.15 a57b79223a14 4 months ago 11.9MB
eclipse-mosquitto latest a57b79223a14 4 months ago 11.9MB
alarmiator/alarmiator latest a55f9a2ce762 4 months ago 2.84GB
jc21/nginx-proxy-manager 60a6ddeeaa79 7 months ago 929MB
cedalo/streamsheets 2-milestone 75fdbda86213 18 months ago 1.23GB
cedalo/installer 2-linux 65ea91bd300b 19 months ago 123MB
hello-world latest feb5d9fea6a5 21 months ago 13.3kB
cedalo/management-center 2 440fdc5d07fd 24 months ago 145MB
Ich hab 0 dunst was das alles ist. Mosquitto und nginx is noch klar aber wieso sind da so viele alarmiator container?
Das mit dem löschen muss ich dann wohl morgen testen. Aktuell läuft ein Einsatz drüber 
Ok hier nochmal ein „Ablaufplan“, weil ich ja alle Befehle schön verteilt habe im Chat.
Die Images sind alle „verschieden“, weil Docker das so handhabt mit den Tags du hast einmal alarmiator, dann hast du alarmiator:latest und alarmiator:latest-amd64 die sind quasi alle unterschiedlich wegen dem Tag beim Download. Das lag an unserer Umstellung in 1.4.2 ist aber weiter nicht schlimm außer, dass du ein Image mehr hast als du brauchst.
Schritt 1:
docker compose down
Stoppt die Container für das komplette Setup
docker ps -a
Listet dir alle Container auf.
Hier suchst du den ALARMiator Container und löscht ihn mit der jeweiligen ID
docker rm {ID}
Jetzt wo du keinen ALARMiator Container mehr am Laufen hast kannst du die Images löschen entweder:
docker image prune
Löscht alle Images die keinen aktiven Container haben. Wenn du das nicht willst kannst du wie oben per ID einzeln löschen. Du kannst alle ALARMiator Images von deinem Server löschen er lädt dann das richtige runter.
Jetzt hast du nur noch volumes übrig die noch deiner Datenbank und KatSys Zertifikat usw. speichern.
Diese löscht du per Namen:
docker volume ls
docker volume rm {name]
Und danach solltest du nichts mehr übrig haben und mit einem neuen docker compose up hast du eine Brandneue Installation. Hier kannst du wieder dein Backup reinladen und schauen, ob es dann geht.
Wenn nicht wird bei dir auf dem Rechner irgendwas auf Betriebssystemebene geschossen sein. Weil eigentlich lösen die Images genau das Problem, dass beim Update etwas vergessen wird. Die sind auch auf jedem Rechner gleich wodurch wir als Team nicht mehr bei jedem auf Suche nach unterschieden in der Installation gehen müssen. Ich hab aktuell die Hoffnung, dass tatsächlich beim Download vom neuen Image was schief gegangen war und er nie versucht hat das neu runterzuladen.
Halt mich auf dem Laufenden : D
1 „Gefällt mir“
Hallo @Dazza ,
ich hab das nun so durchgeführt wie du oben beschrieben hast.
Hat einwandfrei funktioniert. Wenn ich nun auf unserer Productivumgebung den KatSys Datensatz erneut einspiele zeigt er mir auch die weiteren alarmierten mittel an.
Vorerst würde ich sagen, läuft alles.
Danke nochmals für eure Hilfe.
Gruß Andi
1 „Gefällt mir“
Super freut mich. Dann vermute ich, dass irgendwas schief ging beim Download des neuen Release Images und er diese jedes Mal lokal benutzt hat um das " Update" auszuführen.
Sehr ärgerlich aber wenigstens geht es wieder.
Beste Grüße : D
Edit:
Wir wissen nun woran es lag. In der docker compose sollte der Pfad alarmiatorserver/plugins/inboundk/katsys/pem lauten nicht alarmiatorserver/plugins/inbound/katsys. Denn dadurch wird immer die Plugin Version behalten, welche mit der ersten Installation des Servers aufgespielt wurde.
Bitte schaut in unser Handbuch um das neueste docker compose file zu nutzen: Update des ALARMiator Servers – ALARMiator – Handbuch
Vielen Dank nochmal Andi für das Bescheid geben.
2 „Gefällt mir“