Wdrażanie za pomocą Zinnector®: połącz, sprawdź, prześlij

Gdy projekt działa już lokalnie, cztery polecenia przenoszą go na działającą stronę w hostingu Zinn Digital®: logowanie, połączenie projektu ze slotem hostingowym, weryfikacja wstępna (pre-flight) oraz wdrożenie (push). W tym artykule omówiono każde z nich, zwracane przez nie komunikaty oraz polecenia przydatne na kolejnych etapach — ponowne wdrożenia, historię wdrożeń i dzienniki kompilacji.

Logowanie za pomocą klucza API

Proszę utworzyć klucz w panelu w zakładce Ustawienia → Klucze API, a następnie wykonać:

zinnector login

Klucz wprowadza się w wierszu poleceń — nigdy nie jest on przyjmowany jako argument polecenia, dzięki czemu nie trafi do historii powłoki ani do listy procesów. W środowisku CI można przekazać go przez potok: echo "$ZINN_API_KEY" | zinnector login --profile ci lub ustawić zmienną ZINNECTOR_TOKEN i całkowicie pominąć login. Klucz jest weryfikowany przed zapisaniem i przechowywany z uprawnieniami pliku 600. Polecenie zinnector whoami --scopes wyświetla organizację, do której nastąpiło zalogowanie, oraz uprawnienia przypisane do klucza; klucz piaskownicy (sandbox) jest odpowiednio oznaczony.

Połączenie projektu ze slotem

zinnector link                                   # wybór strony z listy
zinnector link example.com --repo acme/site --branch main

Polecenie link zapisuje identyfikator strony w pliku zinnector.json i — o ile nie użyto flagi --no-repo — łączy zdalne repozytorium git projektu ze stroną na platformie, dzięki czemu operacja push uruchamia wdrożenie. Plik zinnector.json należy zatwierdzić w repozytorium: współpracownik, który sklonuje repozytorium, wdroży projekt w to samo miejsce bez konieczności dodatkowych ustaleń. Plik ten nie zawiera żadnych poufnych danych.

Weryfikacja wstępna (pre-flight)

zinnector check

Jest to główne polecenie, dla którego powstał ten interfejs CLI. Porównuje ono Państwa projekt ze slotem docelowym i wyświetla każdą niezgodność — a także każde porównanie, którego nie udało się przeprowadzić:

• Wersję PHP, przy czym różnica wersji głównej (major) otrzymuje ocenę wysoką, ponieważ niezawodnie powoduje awarię strony, a różnica wersji podrzędnej (minor) — niższą, gdyż oznaczanie wszystkiego jako krytyczne uczy ignorowania ostrzeżeń.
• Czy slot może przełączyć się na wersję użytą do budowy, czy wersja PHP na slocie utraciła wsparcie (end of life) oraz czy maszyna faktycznie zastosowała tę wersję, czy jedynie otrzymała takie polecenie.
• Rozmiar i liczbę plików projektu w porównaniu z rzeczywistym limitem miejsca na dysku i wolnych i-węzłów na slocie — struktura plików WordPress może wyczerpać pulę i-węzłów na długo przed osiągnięciem limitu przestrzeni dyskowej.
• Wersje WordPress po obu stronach, stan zakończenia aprowizacji slotu oraz informację, czy podłączono repozytorium do wysyłki.

Polecenie generuje ostrzeżenia; nigdy nie blokuje działań. Każdy wynik można pominąć za pomocą zinnector push --force, ponieważ mają Państwo wiedzę o swojej witrynie, której narzędzie sprawdzające nie posiada. Porównanie, którego nie udało się wykonać, jest oznaczane jako nieznane, nigdy jako zaliczone, a podsumowanie zawsze wskazuje liczbę takich przypadków. Domyślnie lokalna wersja PHP to ta zadeklarowana w zinnector.json; flaga --probe uruchamia lokalne środowisko uruchomieniowe i dokonuje rzeczywistego pomiaru. Flaga --strict zwraca niezerowy kod wyjścia również przy pozycjach nieznanych, co jest pożądane w bramkach CI.

Wdrożenie (push)

zinnector push

Polecenie push przeprowadza weryfikację wstępną, wysyła zatwierdzone zmiany, uruchamia wdrożenie i monitoruje je do zakończenia, wyświetlając status końcowy oraz wdrożony commit. Flaga --dry-run wykonuje wszystkie kroki z wyjątkiem samego wdrożenia; --no-wait uruchamia proces i kończy działanie; --no-git wdraża zawartość znajdującą się już na platformie, bez wysyłania zmian. Jeżeli wdrożony commit różni się od właśnie wysłanego, zostanie wyświetlona odpowiednia informacja.

W przypadku problemów

zinnector deploys example.com        # historia wdrożeń — status, commit, wyzwalacz, komunikat
zinnector logs example.com --build   # dziennik kompilacji ostatniego wdrożenia
zinnector logs example.com --error   # dziennik błędów strony
zinnector deploy example.com         # ponowne wdrożenie zawartości znajdującej się na platformie
zinnector ai "dlaczego moje wdrożenie kończy się błędem?"

Polecenie zinnector ai działa na platformie w ramach Państwa konta, dzięki czemu ma dostęp do tej samej historii wdrożeń i tych samych dzienników zdarzeń. Uruchomione wewnątrz projektu przesyła wyłącznie jego strukturę — nazwy katalogów, wersje oraz identyfikator strony — i nigdy nie przekazuje zawartości plików.

Powiązane materiały

• Pierwsze kroki · Środowisko lokalne · Dokumentacja poleceń · Rozwiązywanie problemów