Zaawansowana instalacja OTOBO za pomocą Docker Compose

Ta sekcja zawiera dodatkowe techniczne informacje na temat tego, co dzieje się "pod maską".

::: version Lista kontenerów Docker; 10+ Kontener otobo_web_1 : Serwer WWW OTOBO na porcie wewnętrznym 5000.

Kontener otobo_daemon_1 : Demon OTOBO. Demon OTOBO jest uruchamiany i okresowo sprawdzany.

Kontener otobo_db_1 : Uruchamia bazę danych MariaDB na porcie wewnętrznym 3306.

Kontener otobo_elastic_1 : Elasticsearch na portach wewnętrznych 9200 i 9300.

Kontener otobo_redis_1 : Uruchamia Redis jako usługę buforowania.

Opcjonalny kontener otobo_nginx_1 : Uruchamia nginx jako proxy zwrotne w celu zapewnienia obsługi HTTPS. :::

::: version Lista kontenerów Docker; 11 Kontener otobo-web-1 : Serwer WWW OTOBO na porcie wewnętrznym 5000.

Kontener otobo-daemon-1 : Demon OTOBO. Demon OTOBO jest uruchamiany i okresowo sprawdzany.

Kontener otobo-db-1 : Uruchamia bazę danych MariaDB na porcie wewnętrznym 3306.

Kontener otobo-elastic-1 : Elasticsearch na portach wewnętrznych 9200 i 9300.

Kontener otobo-redis-1 : Uruchamia Redis jako usługę buforowania.

Opcjonalny kontener otobo-nginx-1 : Uruchamia nginx jako proxy zwrotne w celu zapewnienia obsługi HTTPS. :::

Przegląd wolumenów Docker

Wolumeny Docker są tworzone na hoście dla danych trwałych. Pozwalają one na uruchamianie i zatrzymywanie usług bez utraty danych. Należy pamiętać, że kontenery są tymczasowe, a tylko dane w wolumenach są trwałe. otobo_opt_otobo : zawiera /opt/otobo w kontenerze web i daemon.

otobo_mariadb_data : zawiera /var/lib/mysql w kontenerze db.

otobo_elasticsearch_data : zawiera /usr/share/elasticsearch/data w kontenerze elastic.

otobo_redis_data : zawiera dane dla kontenera redis.

otobo_nginx_ssl : zawiera pliki TLS, certyfikat i klucz prywatny, musi być zainicjalizowany ręcznie.

Zmienne środowiskowe Docker

W instrukcjach przeprowadziliśmy tylko minimalną konfigurację. Jednak plik .env pozwala na ustawienie większej liczby zmiennych. Oto krótka lista najważniejszych zmiennych środowiskowych. Należy pamiętać, że obrazy bazowe obsługują więcej zmiennych środowiskowych.

Ustawienia MariaDB

OTOBO_DB_ROOT_PASSWORD : Hasło roota dla MariaDB. To ustawienie jest wymagane do uruchomienia usługi db.

Ustawienia Elasticsearch

Elasticsearch wymaga pewnych ustawień dla środowisk produkcyjnych. Proszę zapoznać się z https://www.elastic.co/guide/en/elasticsearch/reference/7.8/docker.html#docker-prod-prerequisites, aby uzyskać szczegółowe informacje.

OTOBO_Elasticsearch_ES_JAVA_OPTS : Przykładowe ustawienie: OTOBO_Elasticsearch_ES_JAVA_OPTS=-Xms512m -Xmx512m Proszę dostosować tę wartość dla środowisk produkcyjnych do 4g.

Ustawienia serwera WWW

OTOBO_WEB_HTTP_PORT : Ustaw tę wartość, jeśli port HTTP ma być inny niż domyślny port 80. Jeśli HTTPS jest włączony, port HTTP zostanie przekierowany na HTTPS.

Ustawienia proxy zwrotnego Nginx : Te ustawienia są używane, gdy HTTPS jest włączony.

OTOBO_WEB_HTTP_PORT : Ustaw tę wartość, jeśli port HTTP ma być inny niż domyślny port 80. Zostanie przekierowany na HTTPS.

OTOBO_WEB_HTTPS_PORT : Ustaw tę wartość, jeśli port HTTPS ma być inny niż domyślny port 443.

OTOBO_NGINX_SSL_CERTIFICATE : Certyfikat SSL dla proxy zwrotnego Nginx. Przykład: OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/acme.crt

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Klucz SSL dla proxy zwrotnego Nginx. Przykład: OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/acme.key

Ustawienia proxy zwrotnego Nginx dla Kerberos : Te ustawienia są używane przez Nginx, gdy Kerberos jest używany do Single Sign-On.

OTOBO_NGINX_KERBEROS_KEYTAB Plik keytab Kerberos. Domyślnie jest to /etc/krb5.keytab.

OTOBO_NGINX_KERBEROS_CONFIG : Plik konfiguracyjny Kerberos. Domyślnie jest to /etc/krb5.conf, zazwyczaj generowany z krb5.conf.template.

OTOBO_NGINX_KERBEROS_SERVICE_NAME : Nazwa usługi Kerberos. Nie jest jasne, gdzie to ustawienie jest faktycznie używane.

OTOBO_NGINX_KERBEROS_REALM : REALM Kerberos. Używany w /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_KDC : KDC Kerberos / kontroler AD. Używany w /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_ADMIN_SERVER : Serwer administracyjny Kerberos. Używany w /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_DEFAULT_DOMAIN : Domyślna domena Kerberos. Używana w /etc/krb5.conf.

NGINX_ENVSUBST_TEMPLATE_DIR : Zapewnia niestandardowy katalog szablonów konfiguracji Nginx. Zapewnia dodatkową elastyczność.

Ustawienia Docker Compose : Te ustawienia są używane bezpośrednio przez Docker Compose.

COMPOSE_PROJECT_NAME : Nazwa projektu jest używana jako prefiks dla wolumenów i kontenerów. Domyślnie ten prefiks jest ustawiony na otobo, co skutkuje nazwami kontenerów takimi jak otobo_web_1 i otobo_db_1. Zmień tę nazwę, jeśli chcesz uruchomić więcej niż jedną instancję OTOBO na tym samym serwerze.

COMPOSE_PATH_SEPARATOR : Separator dla wartości COMPOSE_FILE

COMPOSE_FILE : Użyj docker-compose/otobo-base.yml jako podstawy i dodaj pożądane pliki rozszerzeń. Np. docker-compose/otobo-override-http.yml lub docker-compose/otobo-override-https.yml.

OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX, ... : Używane do określenia alternatywnych obrazów Docker. Przydatne do testowania lokalnych kompilacji lub do używania zaktualizowanych wersji obrazów.

Niestandardowa konfiguracja proxy zwrotnego Nginx

Kontener otobo_nginx_1 zapewnia obsługę HTTPS, uruchamiając Nginx jako proxy zwrotne. Obraz Docker działający w kontenerze składa się z oficjalnego obrazu Docker Nginx, https://hub.docker.com/_/nginx, wraz z konfiguracją Nginx specyficzną dla OTOBO. Domyślna konfiguracja specyficzna dla OTOBO znajduje się wewnątrz obrazu Docker pod adresem /etc/nginx/template/otobo_nginx.conf.template. W rzeczywistości jest to tylko szablon dla ostatecznej konfiguracji. Istnieje proces, zapewniany przez obraz bazowy Nginx, który zastępuje makra w szablonie odpowiednimi zmiennymi środowiskowymi. Proces ten jest uruchamiany podczas startu kontenera. W domyślnym pliku szablonu używane są następujące makra:

OTOBO_NGINX_SSL_CERTIFICATE : Do konfiguracji SSL.

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Do konfiguracji SSL.

OTOBO_NGINX_WEB_HOST : Wewnętrznie używany host HTTP.

OTOBO_NGINX_WEB_PORT : Wewnętrznie używany port HTTP.

Zobacz krok [4.] aby dowiedzieć się, jak wykorzystać tę możliwość konfiguracji do ustawienia certyfikatu SSL.

Jeśli domyślne makra nie wystarczą, można pójść dalej w dostosowywaniu. Można to osiągnąć, zastępując domyślny szablon konfiguracji niestandardową wersją. Dobrą praktyką jest nie modyfikowanie konfiguracji bezpośrednio w działającym kontenerze. W tych przykładowych poleceniach używamy istniejącego szablonu jako punktu wyjścia.

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.conf

Dodaj następującą linię do pliku docker-compose/otobo-override-https.yml:

volumes:
  - /opt/otobo-docker/nginx/otobo_nginx.conf:/opt/otobo-docker/nginx/otobo_nginx.conf

Możesz to zrobić za pomocą swojego ulubionego edytora tekstu z Putty lub WinSCP.

nano docker-compose/otobo-override-https.yml

Teraz możesz edytować plik /opt/otobo-docker/nginx/otobo_nginx.conf. Aby zastosować zmiany, kontenery muszą zostać ponownie uruchomione:

docker-compose up -d --build

Single Sign-On z obsługą Kerberos w Nginx

Aby włączyć uwierzytelnianie Kerberos, proszę oprzeć swój plik .env na przykładowym pliku .docker_compose_env_https_kerberos. Włącza to specjalną konfigurację w docker-compose/otobo-override-https-kerberos.yml. Ten plik konfiguracyjny Docker Compose wybiera obraz Nginx, który obsługuje Kerberos. Przekazuje również niektóre ustawienia specyficzne dla Kerberos jako wartości środowiskowe do działającego kontenera Nginx. Ustawienia te są wymienione powyżej. Jak zwykle, wartości dla tych ustawień można podać w pliku .env. Większość tych ustawień jest używana jako wartości zastępcze dla szablonu https://github.com/RotherOSS/otobo/blob/rel-10_1/scripts/nginx/kerberos/templates/krb5.conf.template . Zastępowanie odbywa się podczas uruchamiania kontenera. W działającym kontenerze dostępna jest wtedy dostosowana konfiguracja w /etc/krb5.conf. Zapewnienie niestandardowego pliku /etc/krb5.conf jest nadal możliwe. Można to osiągnąć poprzez zamontowanie wolumenu, który nadpisuje /etc/krb5.conf w kontenerze. Można to osiągnąć poprzez ustawienie OTOBO_NGINX_KERBEROS_CONFIG w pliku .env i włączenie dyrektywy mount w docker-compose/otobo-override-https-kerberos.yml. /etc/krb5.keytab jest zawsze specyficzny dla instalacji i dlatego musi być zawsze montowany z systemu hosta. Instrukcja instalacji Kerberos SSOsso-kerberos

Wybór niestandardowych portów

Domyślnie porty 443 i 80 obsługują odpowiednio HTTPS i HTTP. Mogą wystąpić sytuacje, w których jeden lub oba z tych portów są już używane przez inne usługi. W takich przypadkach domyślne porty można nadpisać, podając OTOBO_WEB_HTTP_PORT i OTOBO_WEB_HTTPS_PORT w pliku .env.

Pomijanie uruchamiania określonych usług

Obecna konfiguracja Docker Compose uruchamia pięć, sześć, jeśli włączony jest HTTPS, usług. Istnieją jednak uzasadnione przypadki użycia, w których jedna lub więcej z tych usług nie jest potrzebna. Głównym przykładem jest sytuacja, gdy baza danych ma być uruchamiana jako zewnętrzna baza danych, a nie jako usługa Docker.

docker-compose up -d web nginx daemon redis elastic

Oczywiście ten sam cel można osiągnąć, edytując plik docker-compose/otobo-base.yml i usuwając odpowiednie definicje usług.

Dostosowywanie Docker Compose OTOBO

Zamiast edytować pliki w docker-compose/ i ryzykować nadpisanie własnych opcji przy następnej aktualizacji folderu otobo-docker, zaleca się utworzenie dodatkowego pliku YAML, w którym poszczególne usługi są nadpisywane dodatkowymi opcjami. Częstym przykładem jest udostępnienie kontenera bazy danych z zewnątrz przez port 3306. W tym celu można utworzyć dodatkowy plik Docker Compose, który wygląda następująco:

cat custom_db.yml
services:
  db:
    ports:
      - "0.0.0.0:3306:3306"

Teraz musimy poinformować docker-compose o uwzględnieniu naszego nowego pliku. W tym celu należy dodać plik YAML do zmiennej COMPOSE_FILE w pliku .env, na przykład:

COMPOSE_FILE=docker-compose/otobo-base.yml:docker-compose/otobo-override-http.yml:custom_db.yml

Teraz możemy użyć docker-compose, aby odbudować nasze kontenery:

docker-compose stop
docker-compose up -d

Dzięki tej metodzie można dostosować każdą usługę lub wolumen.

Dostosowywanie obrazu Docker OTOBO

Wiele dostosowań można wprowadzić w zewnętrznym wolumenie otobo_opt_otobo, który odpowiada katalogowi /opt/otobo w obrazie Docker. Działa to na przykład dla lokalnych modułów Perla, które można zainstalować w /opt/otobo/local. Oto przykład instalacji niezbyt użytecznego modułu CPAN Acme::123.

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

Piękno tego podejścia polega na tym, że sam obraz Docker nie wymaga modyfikacji. Instalacja dodatkowych pakietów Debiana jest nieco bardziej skomplikowana. Jednym z podejść jest utworzenie niestandardowego Dockerfile i użycie obrazu OTOBO jako obrazu bazowego. Innym podejściem jest utworzenie zmodyfikowanego obrazu bezpośrednio z działającego kontenera. Można to zrobić za pomocą polecenia docker commit, https://docs.docker.com/engine/reference/commandline/commit/. Dobry opis tego procesu można znaleźć na stronie https://phoenixnap.com/kb/how-to-commit-changes-to-docker-image. W przypadku tego ostatniego podejścia istnieją dwie przeszkody do pokonania. Po pierwsze, obraz otobo domyślnie działa jako użytkownik otobo z UID 1000. Problem polega na tym, że użytkownik otobo nie ma uprawnień do instalowania pakietów systemowych. Zatem pierwszą częścią rozwiązania jest użycie opcji --user root podczas uruchamiania obrazu. Drugą przeszkodą jest to, że domyślny skrypt wejściowy /opt/otobo_install/entrypoint.sh natychmiast się kończy, gdy jest wywoływany jako root. Uzasadnieniem tej decyzji projektowej jest unikanie niezamierzonego uruchamiania jako root. Zatem drugą częścią rozwiązania jest określenie innego skryptu wejściowego, który nie przejmuje się tym, kto jest wywołującym. To prowadzi nas do następujących przykładowych poleceń, w których dodajemy ciasteczka z fortuną do otobo: Pobierz oznaczony obraz OTOBO, jeśli jeszcze go nie mamy, i sprawdź, czy obraz już zapewnia ciasteczka z fortuną:

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

Dodaj ciasteczka z fortuną do nazwanego kontenera, który uruchamia oryginalny obraz OTOBO. Odbywa się to w interaktywnej sesji jako użytkownik 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 | head

Utwórz obraz z zatrzymanego kontenera i nadaj mu nazwę. Należy pamiętać, że domyślny użytkownik i skrypt wejściowy muszą zostać przywrócone: Na koniec możemy to sprawdzić:

docker run otobo_with_fortune_cookies /usr/games/fortune

A platitude is simply a truth repeated till people get tired of hearing it. -- Stanley Baldwin

Zmodyfikowany obraz można ustawić w pliku .env, a następnie wykorzystać do zabawy i zysku.

Tworzenie lokalnych obrazów

INFO

Lokalne tworzenie obrazów Docker jest zazwyczaj wymagane tylko podczas rozwoju. Inne przypadki użycia obejmują sytuacje, gdy nowsze obrazy bazowe powinny być używane do instalacji lub gdy do obrazów należy dodać dodatkowe funkcjonalności.

Pliki Docker potrzebne do lokalnego tworzenia obrazów Docker są częścią repozytorium git https://github.com/RotherOSS/otobo:

• otobo.web.dockerfile
• otobo.nginx.dockerfile
• otobo.elasticsearch.dockerfile Skrypt do faktycznego tworzenia obrazów to bin/docker/build_docker_images.sh.

cd /opt
git clone https://github.com/RotherOSS/otobo.git

Przejdź do pożądanego brancha. np.

git checkout rel-10_0_11

cd otobo

Zmodyfikuj pliki Docker w razie potrzeby

bin/docker/build_docker_images.sh
docker image ls

Lokalnie utworzone obrazy Docker są oznaczane jako local-<OTOBO_VERSION>, gdzie wersja jest pobierana z pliku RELEASE. Po utworzeniu lokalnych obrazów można wrócić do katalogu docker-compose. Lokalne obrazy są deklarowane przez ustawienie OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX w pliku .env.

Automatyczna instalacja

Zamiast przeprowadzać proces przez http://yourIPorFQDN/otobo/installer.pl, można wziąć skrót. Jest to przydatne do uruchomienia zestawu testów na świeżej instalacji.

WARNING

docker-compose down -v usunie wszystkie poprzednie konfiguracje i dane.

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 daemon

Lista przydatnych poleceń

Docker

• docker system prune -a Czyszczenie systemu (usuwa wszystkie nieużywane obrazy, kontenery, wolumeny, sieci)
• docker version Wyświetla wersję
• i wiele innych przydatnych poleceń Docker.

Docker Compose

• docker-compose config Sprawdza i wyświetla konfigurację
• docker-compose ps Wyświetla działające kontenery
• i inne przydatne polecenia Docker Compose.