W poniższym artykule postaram się w kilku słowach napisać jak i gdzie szukać przyczyn źle lub niepoprawnie działającej naszej aplikacji Harbor.
Dostęp do logów Harbor
Domyślnie dane rejestru każdego Harbnor’a są przechowywane w katalogu /data/
na hoście . Ważne jest to, że dane te pozostają niezmienione, nawet gdy kontenery Harbor zostaną usunięte i/lub odtworzone. Oczywiście można zmienić tę lokalizację, edytując wartość data_volume
w pliku harbor.yml
.
Dodatkowo Harbor używa narzędzia rsyslog
do zbierania logów z każdego kontenera. Domyślnie pliki logów są przechowywane w katalogu /var/log/harbor/
na docelowym hoście na potrzeby ewentualnie szukania przyczyn problemu naszej aplikacji. Oczywiście i wtym przypadku można zmienić lokalizację katalogu logów, edytując odpowiednią opcję w pliku harbor.yml
.
Harbor nie uruchamia się lub działa nieprawidłowo
Jeśli Harbor nie uruchamia się lub działa nieprawidłowo.
Co możemy w takiej sytuacji zarobić. Należy wykonać następujące polecenie, w celu sprawdzania, czy wszystkie kontenery Harbor są porwanie uruchomione i wyświetla się stani “Up”.
bashSkopiuj kodsudo docker compose ps
Przykład wyniku naszego polecenia:
Jeśli jakiś kontener nie znajduje się w stanie “Up”, sprawdź odpowiedni plik logu tego kontenera w katalogu /var/log/harbor
. Na przykład, jeśli kontener harbor-core
nie działa, sprawdź plik core.log
.
root@HARBORPOC01:~/harbor# /usr/libexec/docker/cli-plugins/docker-compose ps
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
harbor-core goharbor/harbor-core:v2.10.2 "/harbor/entrypoint.…" core 3 months ago Up 3 months (healthy)
harbor-jobservice goharbor/harbor-jobservice:v2.10.2 "/harbor/entrypoint.…" jobservice 3 months ago Up 3 months (healthy)
harbor-log goharbor/harbor-log:v2.10.2 "/bin/sh -c /usr/loc…" log 3 months ago Up 3 months (healthy) 127.0.0.1:1514->10514/tcp
harbor-portal goharbor/harbor-portal:v2.10.2 "nginx -g 'daemon of…" portal 3 months ago Up 3 months (healthy)
nginx goharbor/nginx-photon:v2.10.2 "nginx -g 'daemon of…" proxy 3 months ago Up 3 months (healthy) 0.0.0.0:80->8080/tcp, 0.0.0.0:443->8443/tcp
redis goharbor/redis-photon:v2.10.2 "redis-server /etc/r…" redis 3 months ago Up 3 months (healthy)
registry goharbor/registry-photon:v2.10.2 "/home/harbor/entryp…" registry 3 months ago Up 3 months (healthy)
registryctl goharbor/harbor-registryctl:v2.10.2 "/home/harbor/start.…" registryctl 3 months ago Up 3 months (healthy)
trivy-adapter goharbor/trivy-adapter-photon:v2.10.2 "/home/scanner/entry…" trivy-adapter 3 months ago Up 3 months (healthy)
root@HARBORPOC01:~/harbor#
Przeglądnie logów.
Jeśli któryś z naszych ma tatus “UP” nasz Harbor nie działa poprawnie należy przejść do katalogu z logami i przyjrzeć się dogłębniej, co jest przyczyna zaistniałej sytuacji przeglądają każdy z logów.
root@HARBORPOC:01~/harbor# ls /var/log/harbor/ -l
total 759416
-rw-r–r– 1 10000 10000 21693623 Jan 11 02:00 core.log
-rw-r–r– 1 10000 10000 7612770 Aug 25 12:01 core.log.1.gz
-rw-r–r– 1 10000 10000 106880832 Jan 11 02:00 jobservice.log
-rw-r–r– 1 10000 10000 5593170 Aug 15 08:00 jobservice.log.1.gz
-rw-r–r– 1 10000 10000 170192668 Jan 11 02:24 portal.log
-rw-r–r– 1 10000 10000 9354051 Sep 20 23:00 portal.log.1.gz
-rw-r–r– 1 10000 10000 97019253 Jan 11 02:24 proxy.log
-rw-r–r– 1 10000 10000 35381855 Jan 11 02:23 redis.log
-rw-r–r– 1 10000 10000 129276075 Jan 11 02:24 registryctl.log
-rw-r–r– 1 10000 10000 9627117 Oct 10 22:00 registryctl.log.1.gz
-rw-r–r– 1 10000 10000 175127441 Jan 11 02:24 registry.log
-rw-r–r– 1 10000 10000 9814850 Sep 17 02:00 registry.log.1.gz
-rw-r–r– 1 10000 10000 14371 Sep 19 00:37 trivy-adapter.log
root@HARBORPOC:01~/harbor#