Geavanceerde installatie van OTOBO met Docker Compose
Dit gedeelte geeft enkele verdere technische inzichten in wat er achter de schermen gebeurt.
::: version Lijst van Docker-containers; 10+ Container otobo_web_1 : OTOBO webserver op interne poort 5000.
Container otobo_daemon_1 : OTOBO daemon. De OTOBO daemon wordt gestart en periodiek gecontroleerd.
Container otobo_db_1 : Draait de MariaDB database op interne poort 3306.
Container otobo_elastic_1 : Elasticsearch op interne poorten 9200 en 9300.
Container otobo_redis_1 : Draait Redis als caching service.
Optionele Container otobo_nginx_1 : Draait nginx als reverse proxy voor het leveren van HTTPS-ondersteuning. :::
::: version Lijst van Docker-containers; 11 Container otobo-web-1 : OTOBO webserver op interne poort 5000.
Container otobo-daemon-1 : OTOBO daemon. De OTOBO daemon wordt gestart en periodiek gecontroleerd.
Container otobo-db-1 : Draait de MariaDB database op interne poort 3306.
Container otobo-elastic-1 : Elasticsearch op interne poorten 9200 en 9300.
Container otobo-redis-1 : Draait Redis als caching service.
Optionele Container otobo-nginx-1 : Draait nginx als reverse proxy voor het leveren van HTTPS-ondersteuning. :::
Overzicht van Docker-volumes
De Docker-volumes worden op de host aangemaakt voor persistente data. Deze maken het mogelijk om de services te starten en te stoppen zonder dataverlies. Houd er rekening mee dat containers tijdelijk zijn en alleen data in de volumes permanent is. otobo_opt_otobo : bevat /opt/otobo in de web en daemon containers.
otobo_mariadb_data : bevat /var/lib/mysql in de db container.
otobo_elasticsearch_data : bevat /usr/share/elasticsearch/data in de elastic container.
otobo_redis_data : bevat data voor de redis container.
otobo_nginx_ssl : bevat de TLS-bestanden, certificaat en private sleutel, moet handmatig geïnitialiseerd worden.
Docker-omgevingsvariabelen
In de instructies hebben we slechts een minimale configuratie uitgevoerd. Maar het .env-bestand maakt het mogelijk om meer variabelen in te stellen. Hier is een korte lijst van de belangrijkste omgevingsvariabelen. Houd er rekening mee dat de basisimages meer omgevingsvariabelen ondersteunen.
MariaDB-instellingen
OTOBO_DB_ROOT_PASSWORD : Het root-wachtwoord voor MariaDB. Deze instelling is nodig om de db-service te draaien.
Elasticsearch-instellingen
Elasticsearch vereist enkele instellingen voor productieomgevingen. Lees alstublieft https://www.elastic.co/guide/en/elasticsearch/reference/7.8/docker.html#docker-prod-prerequisites voor gedetailleerde informatie.
OTOBO_Elasticsearch_ES_JAVA_OPTS : Voorbeeldinstelling: OTOBO_Elasticsearch_ES_JAVA_OPTS=-Xms512m -Xmx512m Pas deze waarde aan voor productieomgevingen tot 4g.
Webserver-instellingen
OTOBO_WEB_HTTP_PORT : Stel deze waarde in als de HTTP-poort moet afwijken van de standaardpoort 80. Als HTTPS is ingeschakeld, wordt de HTTP-poort omgeleid naar HTTPS.
Nginx-webproxy-instellingen : Deze instellingen worden gebruikt wanneer HTTPS is ingeschakeld.
OTOBO_WEB_HTTP_PORT : Stel deze waarde in als de HTTP-poort moet afwijken van de standaardpoort 80. Wordt omgeleid naar HTTPS.
OTOBO_WEB_HTTPS_PORT : Stel deze waarde in als de HTTPS-poort moet afwijken van de standaardpoort 443.
OTOBO_NGINX_SSL_CERTIFICATE : SSL-certificaat voor de Nginx-webproxy. Voorbeeld: OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/acme.crt
OTOBO_NGINX_SSL_CERTIFICATE_KEY : SSL-sleutel voor de Nginx-webproxy. Voorbeeld: OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/acme.key
Nginx-webproxy-instellingen voor Kerberos : Deze instellingen worden door Nginx gebruikt wanneer Kerberos wordt gebruikt voor Single Sign-On.
OTOBO_NGINX_KERBEROS_KEYTAB Kerberos keytab-bestand. De standaard is /etc/krb5.keytab.
OTOBO_NGINX_KERBEROS_CONFIG : Kerberos-configuratiebestand. De standaard is /etc/krb5.conf, normaal gesproken gegenereerd uit krb5.conf.template.
OTOBO_NGINX_KERBEROS_SERVICE_NAME : Kerberos-servicenaam. Het is niet duidelijk waar deze instelling daadwerkelijk wordt gebruikt.
OTOBO_NGINX_KERBEROS_REALM : Kerberos REALM. Gebruikt in /etc/krb5.conf.
OTOBO_NGINX_KERBEROS_KDC : Kerberos kdc / AD Controller. Gebruikt in /etc/krb5.conf.
OTOBO_NGINX_KERBEROS_ADMIN_SERVER : Kerberos admin server. Gebruikt in /etc/krb5.conf.
OTOBO_NGINX_KERBEROS_DEFAULT_DOMAIN : Kerberos standaarddomein. Gebruikt in /etc/krb5.conf.
NGINX_ENVSUBST_TEMPLATE_DIR : Biedt een aangepast Nginx-configuratietemplatedirectory. Biedt extra flexibiliteit.
Docker Compose-instellingen : Deze instellingen worden rechtstreeks door Docker Compose gebruikt.
COMPOSE_PROJECT_NAME : De projectnaam wordt gebruikt als prefix voor de volumes en containers. Standaard is dit prefix ingesteld op otobo, wat resulteert in containernamen zoals otobo_web_1 en otobo_db_1. Wijzig deze naam als u meer dan één instantie van OTOBO op dezelfde server wilt draaien.
COMPOSE_PATH_SEPARATOR : Scheidingsteken voor de waarde van COMPOSE_FILE
COMPOSE_FILE : Gebruik docker-compose/otobo-base.yml als basis en voeg de gewenste extensiebestanden toe. Bijvoorbeeld docker-compose/otobo-override-http.yml of docker-compose/otobo-override-https.yml.
OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX, ... : Gebruikt voor de specificatie van alternatieve Docker-images. Nuttig voor het testen van lokale builds of voor het gebruik van bijgewerkte versies van de images.
Aangepaste configuratie van de Nginx-webproxy
De container otobo_nginx_1 biedt HTTPS-ondersteuning door Nginx als reverse proxy te draaien. De Docker-image die in de container draait, bestaat uit de officiële Nginx Docker-image, https://hub.docker.com/_/nginx, samen met een OTOBO-specifieke configuratie van Nginx. De standaard OTOBO-specifieke configuratie is te vinden binnen de Docker-image op /etc/nginx/template/otobo_nginx.conf.template. In feite is dit slechts een sjabloon voor de uiteindelijke configuratie. Er is een proces dat wordt geleverd door de Nginx-basisimage, dat de macro's in het sjabloon vervangt door de bijbehorende omgevingsvariabelen. Dit proces wordt uitgevoerd wanneer de container wordt gestart. In het standaard sjabloonbestand worden de volgende macro's gebruikt:
OTOBO_NGINX_SSL_CERTIFICATE : Voor het configureren van SSL.
OTOBO_NGINX_SSL_CERTIFICATE_KEY : Voor het configureren van SSL.
OTOBO_NGINX_WEB_HOST : De intern gebruikte HTTP-host.
OTOBO_NGINX_WEB_PORT : De intern gebruikte HTTP-poort.
Zie stap [4.] voor het gebruik van deze configuratiemogelijkheid om het SSL-certificaat in te stellen.
Als de standaardmacro's niet volstaan, kan de aanpassing verder gaan. Dit kan worden bereikt door het standaard configuratiesjabloon te vervangen door een aangepaste versie. Het is een goede praktijk om de configuratie niet zomaar in de draaiende container te wijzigen. In deze voorbeeldopdrachten gebruiken we het bestaande sjabloon als uitgangspunt.
cd /opt/otobo-docker
mkdir nginx
docker cp otobo_nginx_1:/etc/nginx/conf.d/otobo_nginx.conf /opt/otobo-docker/nginx/otobo_nginx.conf
docker exec otobo_nginx_1 rm /etc/nginx/conf.d/otobo_nginx.confVoeg de volgende regel toe aan het bestand docker-compose/otobo-override-https.yml:
volumes:
- /opt/otobo-docker/nginx/otobo_nginx.conf:/opt/otobo-docker/nginx/otobo_nginx.confHiervoor kunt u uw favoriete teksteditor gebruiken met Putty of WinSCP.
nano docker-compose/otobo-override-https.ymlNu kunt u het bestand /opt/otobo-docker/nginx/otobo_nginx.conf bewerken. Om de wijzigingen toe te passen, moeten de containers opnieuw worden gestart:
docker-compose up -d --buildSingle Sign-On met Kerberos-ondersteuning in Nginx
Om authenticatie met Kerberos te activeren, baseer alstublieft uw .env-bestand op het voorbeeld bestand .docker_compose_env_https_kerberos. Dit activeert de speciale configuratie in docker-compose/otobo-override-https-kerberos.yml. Dit Docker Compose-configuratiebestand selecteert een Nginx-image dat Kerberos ondersteunt. Het geeft ook enkele Kerberos-specifieke instellingen door als omgevingswaarden aan de draaiende Nginx-container. Deze instellingen zijn hierboven vermeld. Zoals gebruikelijk kunnen de waarden voor deze instellingen worden opgegeven in het .env-bestand. De meeste van deze instellingen worden gebruikt als vervangende waarden voor het sjabloon https://github.com/RotherOSS/otobo/blob/rel-10_1/scripts/nginx/kerberos/templates/krb5.conf.template . De vervanging vindt plaats tijdens het opstarten van de container. In de draaiende container is dan de aangepaste configuratie in /etc/krb5.conf beschikbaar. Het leveren van een gebruikersspecifiek /etc/krb5.conf-bestand is nog steeds mogelijk. Dit kan worden bereikt door een volume te mounten dat /etc/krb5.conf in de container overschrijft. Dit kan worden bereikt door OTOBO_NGINX_KERBEROS_CONFIG in te stellen in het .env-bestand en de mount-richtlijn in docker-compose/otobo-override-https-kerberos.yml te activeren. /etc/krb5.keytab is altijd installatiespecifiek en moet daarom altijd vanaf het host-systeem worden gemount. Kerberos SSO-installatiehandleidingsso-kerberos
Kiezen van niet-standaard poorten
Standaard bedienen de poorten 443 en 80 respectievelijk HTTPS en HTTP. Er kunnen gevallen zijn waarin een of beide van deze poorten al door andere services worden gebruikt. In deze gevallen kunnen de standaardpoorten worden overschreven door OTOBO_WEB_HTTP_PORT en OTOBO_WEB_HTTPS_PORT in te stellen in het .env-bestand.
Overslaan van het starten van specifieke services
De huidige Docker Compose-configuratie start vijf, zes indien HTTPS is ingeschakeld, services. Er zijn echter geldige gebruiksscenario's waarin een of meer van deze services niet nodig zijn. Het belangrijkste voorbeeld is wanneer de database niet als Docker-service, maar als externe database moet worden gedraaid.
docker-compose up -d web nginx daemon redis elasticNatuurlijk kan hetzelfde doel worden bereikt door het bestand docker-compose/otobo-base.yml te bewerken en de relevante service-definities te verwijderen.
Docker Compose van OTOBO aanpassen
In plaats van de bestanden onder docker-compose/ te bewerken en het risico te lopen uw eigen opties te overschrijven met de volgende update van de otobo-docker-map, is het raadzaam om een extra YAML-bestand aan te maken waarin de specifieke services met extra opties worden overschreven. Een veelvoorkomend voorbeeld zou zijn om de databasecontainer toegankelijk te maken via poort 3306 van buitenaf. Hiervoor zou u een extra Docker Compose-bestand kunnen aanmaken dat er als volgt uitziet:
cat custom_db.yml
services:
db:
ports:
- "0.0.0.0:3306:3306"Nu moeten we docker-compose laten weten dat we ons nieuwe bestand moeten opnemen. Hiervoor moet u uw YAML-bestand toevoegen aan de variabele COMPOSE_FILE in het .env-bestand, bijvoorbeeld:
COMPOSE_FILE=docker-compose/otobo-base.yml:docker-compose/otobo-override-http.yml:custom_db.ymlNu kunnen we docker-compose gebruiken om onze containers opnieuw op te bouwen:
docker-compose stop
docker-compose up -dMet deze methode kunt u elke service of elk volume aanpassen.
Docker-image van OTOBO aanpassen
Veel aanpassingen kunnen worden gedaan in het externe volume otobo_opt_otobo, dat overeenkomt met de map /opt/otobo in het Docker-image. Dit werkt bijvoorbeeld voor lokale Perl-modules die in /opt/otobo/local kunnen worden geïnstalleerd. Hier is een voorbeeld dat de niet erg nuttige CPAN-module Acme::123 installeert.
docker exec -it ${COMPOSE_PROJECT_NAME:=otobo}_web_1 bash
pwd/opt/otobo
cpanm -l local Acme::123--> Working on Acme::123
Fetching http://www.cpan.org/authors/id/N/NA/NATHANM/Acme-123-0.04.zip ... OK Configuring Acme-123-0.04 ... OK Building and testing Acme-123-0.04 ... OK Successfully installed Acme-123-0.04 1 distribution installed
Het mooie van deze aanpak is dat het Docker-image zelf niet hoeft te worden gewijzigd. Het installeren van extra Debian-pakketten is iets lastiger. Een aanpak is om een aangepaste Dockerfile te maken en de OTOBO-image als basis-image te gebruiken. Een andere aanpak is om direct vanuit een draaiende container een aangepaste image te maken. Dit kan met het commando docker commit, https://docs.docker.com/engine/reference/commandline/commit/. Een goede beschrijving van dit proces is te vinden op https://phoenixnap.com/kb/how-to-commit-changes-to-docker-image. Voor de laatstgenoemde aanpak zijn er twee hindernissen te overwinnen. Ten eerste draait de otobo-image standaard als gebruiker otobo met UID 1000. Het probleem is dat de gebruiker otobo niet de rechten heeft om systeem-pakketten te installeren. Dus het eerste deel van de oplossing is om de optie --user root te gebruiken bij het starten van de image. De tweede hindernis is dat het standaard entrypoint-script /opt/otobo_install/entrypoint.sh onmiddellijk stopt wanneer het als root wordt aangeroepen. De overweging achter deze ontwerpbeslissing is dat onbedoeld uitvoeren als root moet worden vermeden. Het tweede deel van de oplossing is daarom om een ander entrypoint-script te specificeren dat niet uitmaakt wie de aanroeper is. Hiermee komen we tot de volgende voorbeeldopdrachten, waarbij we OTOBO Fortune Cookies toevoegen: Haal een getagde OTOBO-image op, als we die nog niet hebben, en controleer of de image al Fortune Cookies levert:
docker run rotheross/otobo:rel-10_0_10 /usr/games/fortune/opt/otobo_install/entrypoint.sh: line 57: /usr/games/fortune: No such file or directory
Voeg Fortune Cookies toe aan een benoemde container die de originele OTOBO-image draait. Dit gebeurt in een interactieve sessie als gebruiker root:
docker run -it --user root --entrypoint /bin/bash --name otobo_orig rotheross/otobo:rel-10_0_10
apt update
apt install fortunes
exit
docker ps -a | headMaak een image van de gestopte container en geef deze een naam. Houd er rekening mee dat de standaardgebruiker en het entrypoint-script moeten worden hersteld: Ten slotte kunnen we het controleren:
docker run otobo_with_fortune_cookies /usr/games/fortuneA platitude is simply a truth repeated till people get tired of hearing it. -- Stanley Baldwin
De gewijzigde image kan worden ingesteld in uw .env-bestand en vervolgens worden gebruikt voor plezier en winst.
Lokale images bouwen
INFO
Het lokaal bouwen van Docker-images is meestal alleen nodig tijdens de ontwikkeling. Andere gebruiksscenario's zijn wanneer recentere basis-images moeten worden gebruikt voor een installatie of wanneer extra functionaliteiten aan de images moeten worden toegevoegd.
De Docker-bestanden die nodig zijn om Docker-images lokaal te bouwen, maken deel uit van de git-repository https://github.com/RotherOSS/otobo:
- otobo.web.dockerfile
- otobo.nginx.dockerfile
- otobo.elasticsearch.dockerfile Het script voor het daadwerkelijk bouwen van de images is bin/docker/build_docker_images.sh.
cd /opt
git clone https://github.com/RotherOSS/otobo.gitGa naar de gewenste branch. Bijvoorbeeld
git checkout rel-10_0_11cd otoboWijzig de Docker-bestanden indien nodig
bin/docker/build_docker_images.sh
docker image lsDe lokaal gebouwde Docker-images worden getagd als local-<OTOBO_VERSION>, waarbij de versie uit het RELEASE-bestand wordt gebruikt. Nadat de lokale images zijn gebouwd, kunt u terugkeren naar de docker-compose-map. De lokale images worden gedeclareerd door OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX in te stellen in .env.
Automatische installatie
In plaats van het proces via http://yourIPorFQDN/otobo/installer.pl te doorlopen, kunt u een kortere weg nemen. Dit is nuttig om de testsuite uit te voeren op een verse installatie.
WARNING
docker-compose down -v verwijdert alle eerdere setups en data.
docker-compose down -v
docker-compose up --detach
docker-compose stop daemon
docker-compose exec web bash\
-c "rm -f Kernel/Config/Files/ZZZAAuto.pm ; bin/docker/quick_setup.pl --db-password otobo_root"
docker-compose exec web bash\
-c "bin/docker/run_test_suite.sh"
docker-compose start daemonLijst met nuttige commando's
Docker
docker system prune -aSysteemschoonmaak (verwijdert alle ongebruikte images, containers, volumes, netwerken)docker versionToont de versie- en vele andere nuttige Docker-commando's.
Docker Compose
docker-compose configControleert en toont de configuratiedocker-compose psToont de draaiende containers- en andere nuttige Docker Compose-commando's.