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 --q247-ep-plugin-prod > q247-plugin.log 2>&1 &

Sprawdzenie, czy proces faktycznie działa:

# ps -efww | grep -i q247
q247 1372705 1 5 Apr17 ? 15:59:29 ./q247-enterprise-plugin-linux --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 i nie wymaga edycji. 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 wtyczka wymaga kilku rzeczy po stronie infrastruktury. Wszystkie ustala się z zespołem wdrożeniowym Q247 na etapie wdrożenia.

Dostęp sieciowy​

Wtyczka łączy się wychodząco: z systemem kontroli wersji, z instancjami Jiry i Confluence, oraz z backendem Q247.

Jeśli integracje Jiry albo Confluence działają w wersji Data Center, dochodzi ruch przychodzący z tych instancji do wtyczki. Trzeba wtedy udostępnić port, na którym wtyczka nasłuchuje webhooków. Numer portu dla danego wdrożenia podaje zespół wdrożeniowy, a ruch pozostaje wewnątrz sieci Klienta.

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.

Zobacz też​