Przejdź do głównej zawartości

Instalacja

Q247 może łączyć się z systemem kontroli wersji na dwa sposoby: z bezpiecznej infrastruktury chmurowej Q247 (Cloud Plugin) albo przez wtyczkę zainstalowaną lokalnie, w infrastrukturze Klienta (Private Plugin). Funkcjonalnie oba tryby działają tak samo, różnią się tylko tym, gdzie fizycznie uruchomiony jest proces skanujący.

Wdrożeniami zarządza się w Konfiguracji, w sekcji Wtyczki. Każde wdrożenie ma na liście własny znacznik trybu, Chmura albo On-Premise, oraz własną listę Konektorów.

Sekcja Wtyczki z listą wdrożeń i ich konektorami

Cloud Plugin​

To domyślny tryb. Nie wymaga żadnej konfiguracji w UI Q247 ani zaangażowania zespołu DevOps Klienta poza jednym: otwarciem dostępu sieciowego z Cloud Plugin do systemu SCM Klienta. Cloud Plugin jest dostępny dla każdego klienta i włączony domyślnie.

Na życzenie Klienta można dodać dodatkową warstwę zabezpieczeń między infrastrukturą Cloud Plugin a infrastrukturą Klienta, np. dedykowany kanał VPN. Pełne szczegóły bezpieczeństwa opisuje Bezpieczeństwo Enterprise Plugin.

Wymagania połączenia dla Cloud Plugin​

Trzeba otworzyć trasowanie sieciowe między adresem wyjściowym wtyczki chmurowej Q247 a punktem końcowym REST API systemu SCM Klienta. Aktualny adres podaje zespół wdrożeniowy Q247.

Private Plugin​

Klient tworzy własne wdrożenie w panelu, pobiera dla niego plik konfiguracyjny oraz plik wtyczki i uruchamia proces we własnej infrastrukturze.

1. Utworzenie wdrożenia​

W Konfiguracji, w sekcji Wtyczki, przycisk Dodaj wtyczkę otwiera formularz z jednym polem.

Formularz dodawania wtyczki z polem nazwy

PoleCo wpisaćPrzykład
Nazwaunikalna nazwa wdrożenia, do rozpoznania na liścieWtyczka Warszawa

Po zatwierdzeniu wdrożenie pojawia się na liście, oznaczone jako On-Premise, z pustą listą konektorów.

2. Pobranie plików​

Potrzebne są dwa pliki i pobiera się je z dwóch różnych miejsc:

  • Config, przycisk przy konkretnym wdrożeniu na liście. Pobiera plik konfiguracyjny wygenerowany dla tego wdrożenia. Przycisk pojawia się przy wdrożeniach On-Premise.
  • Plik wtyczki, przycisk w nagłówku sekcji Wtyczki. Pobiera najnowszą wersję samej wtyczki. Pojawia się, gdy organizacja ma co najmniej jedno wdrożenie On-Premise.
Kolejność pobierania plików

Plik konfiguracyjny powstaje dla konkretnego wdrożenia, więc najpierw utwórz wdrożenie, a dopiero potem pobieraj pliki. Przed dodaniem pierwszej wtyczki On-Premise żadnego z tych dwóch przycisków nie ma na ekranie.

Oba pliki (config.cfg i q247-enterprise-plugin-linux-*) muszą trafić do tego samego katalogu na docelowym serwerze.

3. Instalacja i uruchomienie​

Uruchomienie wtyczki:

nohup ./q247-enterprise-plugin-linux-vx.x.x --q247-ep-plugin-prod > q247-plugin.log 2>&1 &

W miejsce x.x.x wstaw numer wersji pobranego pliku wtyczki (Enterprise Plugin), taki jak w nazwie tego pliku.

Sprawdzenie, czy proces faktycznie działa:

# ps -efww | grep -i q247
q247 1372705 1 5 Apr17 ? 15:59:29 ./q247-enterprise-plugin-linux-vx.x.x --q247-ep-plugin-prod

Podczas pracy wtyczka korzysta z tych plików i katalogów:

  • q247-plugin.log: logi wtyczki.
  • q247-working: katalog roboczy, gdzie wtyczka tymczasowo przechowuje dane pobrane z repozytoriów Git.
  • plugin.data, plugin.data-shm, plugin.data-wal: lokalne pliki magazynu danych wtyczki.

Plik konfiguracyjny pobrany z panelu jest gotowy do użycia. Zawiera już adres backendu oraz poświadczenia wdrożenia, a ustawienia takie jak obsługa integracji Jiry i Confluence czy tryb pracy wtyczki przygotowuje zespół wdrożeniowy Q247 przed przekazaniem pliku.

Przygotowanie środowiska Klienta​

Poza samym uruchomieniem procesu w infrastrukturze Klienta trzeba przygotować poniższe elementy.

Dostęp sieciowy​

Wtyczka łączy się wychodząco: z systemem kontroli wersji, z instancjami Jiry, Confluence i Azure DevOps Server, oraz z backendem Q247. Integracje Azure Boards i Azure Wiki pracują wyłącznie przez odpytywanie, więc nie dokładają żadnego ruchu przychodzącego.

Jeśli integracje Jiry albo Confluence działają w wersji Data Center i pobierają dane webhookami, dochodzi ruch przychodzący z tych instancji do wtyczki. Plik pobrany z panelu ustawia domyślnie port 443 dla HTTPS i 80 dla HTTP. Wtyczka uruchamia jeden nasłuch: HTTPS, jeśli może wczytać certyfikat TLS i klucz prywatny, a w przeciwnym razie HTTP (Certyfikat TLS dla odbiornika webhooków). Na firewallu dopuść port, na którym wtyczka faktycznie działa, i wpisz go w polu Port serwera wtyczki w formularzu konektora. Zwykle jest to port HTTPS. Ruch pozostaje wewnątrz sieci Klienta.

W trybie odpytywania API wtyczka łączy się z Jirą i Confluence wyłącznie wychodząco, a formularz konektora nie pokazuje wtedy pól serwera wtyczki. → Sposób pobierania danych w Jirze i w Confluence

Niestandardowe porty administrator infrastruktury Klienta ustawia w polach plugins.http.port i plugins.https.port pliku config.cfg. Poniższy fragment sekcji plugins ustawia port 60080 dla HTTP i 8443 dla HTTPS:

{
  "plugins": {
    "http": {
      "port": 60080
    },
    "https": {
      "port": 8443
    }
  }
}

Zmień tylko te dwie wartości, a pozostałe ustawienia z pliku konfiguracyjnego pobranego z panelu Q247 pozostaw bez zmian.

Certyfikat TLS dla odbiornika webhooków​

Odbiornik webhooków może pracować po HTTPS, co wymaga dostarczenia certyfikatu i klucza prywatnego dla adresu, pod którym wtyczka będzie widoczna dla Jiry i Confluence.

Brak certyfikatu nie zatrzymuje wtyczki

Wtyczka uruchomi się wtedy z nasłuchem nieszyfrowanym i będzie działać dalej, bez błędu widocznego w panelu Q247. Ruch webhooków przestaje być szyfrowany, mimo że konfiguracja wygląda na kompletną, dlatego certyfikat warto potwierdzić na starcie wdrożenia, a nie po fakcie.

Proxy i inspekcja TLS na firewallu​

Jeśli ruch wychodzący z sieci Klienta przechodzi przez jawne proxy, jego adres i ewentualne dane uwierzytelniające trzeba przekazać zespołowi wdrożeniowemu. Proxy transparentne nie wymaga niczego.

Jeśli firewall terminuje połączenia TLS i podpisuje je ponownie własnym certyfikatem, wtyczka nie rozpozna certyfikatu backendu Q247 i połączenie się nie uda. W takim przypadku Klient dostarcza plik PEM z certyfikatem firmowego CA. To samo dotyczy sytuacji, w której instancja Jiry, Confluence albo serwera Git ma certyfikat z prywatnego CA. → Certyfikat głównego CA w pliku konfiguracyjnym

Certyfikat głównego CA w pliku konfiguracyjnym​

Jeśli Jira Data Center, Confluence Data Center lub GitLab używają certyfikatów wystawionych przez własne CA (na przykład z OpenSSL, step-ca albo AD CS), wtyczka musi znać certyfikat głównego CA, żeby zweryfikować te serwery. Ścieżkę do pliku PEM z tym certyfikatem podaje się w sekcji ssl, którą administrator dopisuje bezpośrednio do głównego obiektu JSON w config.cfg, obok istniejących pól, takich jak endpoint i apikey:

{
  "ssl": {
    "caFilePath": "/sciezka/do/rootCA.pem",
    "sslMode": "strict"
  }
}

Poniżej przykład config.cfg z dopisaną sekcją ssl zaraz po polu dryrun.

Fragment pliku config.cfg z sekcją ssl w głównym obiekcie JSON

PoleWartość
caFilePathścieżka do pliku PEM z certyfikatem głównego CA, zapisanego na serwerze, na którym działa wtyczka
sslModestrict zostawia pełną weryfikację certyfikatów włączoną

Jeden plik wskazany w caFilePath obowiązuje dla wszystkich tych serwerów, więc przy różnych CA umieść ich certyfikaty w jednym pliku PEM. Wtyczka wczytuje config.cfg przy starcie, dlatego po dopisaniu sekcji uruchom ją ponownie. Gdy plik z certyfikatem nie daje się wczytać (zła ścieżka albo brak uprawnień), wtyczka zapisuje błąd w logu i wraca do domyślnej weryfikacji, a połączenia z serwerami z prywatnym CA nadal kończą się błędem certyfikatu.

Zobacz też​