Nasazení pomocí Zinnector®: propojit, zkontrolovat, odeslat

Jakmile projekt běží lokálně, k jeho přenesení na živý web na hostingu Zinn Digital® stačí čtyři příkazy: přihlásit se, propojit projekt s hostingovým slotem, zkontrolovat předletovou kontrolu (pre-flight) a odeslat (push). Tento článek podrobně prochází každý z nich, co vypisují a jaké příkazy použijete poté – opakovaná nasazení, historii nasazení a protokoly sestavení.

Přihlášení pomocí klíče API

Vytvořte klíč v administračním rozhraní v části Settings → API keys, a poté:

zinnector login

Klíč se zadává na výzvu – nikdy není přijímán jako argument příkazového řádku, takže nemůže skončit v historii vašeho shellu ani ve výpisu procesů. V CI jej předejte přes rouru: echo "$ZINN_API_KEY" | zinnector login --profile ci, nebo nastavte proměnnou ZINNECTOR_TOKEN a příkaz login zcela přeskočte. Klíč je před uložením ověřen a uložen s oprávněními souboru 600. Příkaz zinnector whoami --scopes zobrazí, ke které organizaci jste přihlášeni a jaká oprávnění daný klíč nese; sandboxový klíč je jako takový označen.

Propojení projektu se slotem

zinnector link                                   # pick a site from a list
zinnector link example.com --repo acme/site --branch main

Příkaz link zapíše ID webu do souboru zinnector.json a – pokud nezadáte parametr --no-repo – propojí vzdálené gitové úložiště projektu s webem na platformě, takže odeslání (push) jej rovnou nasadí. Soubor zinnector.json verzujte (commit): kolega, který si repozitář naklonuje, pak nasazuje na stejné místo bez nutnosti dalších instrukcí. Neobsahuje žádné tajné údaje.

Kontrola předletové přípravy (pre-flight)

zinnector check

Toto je příkaz, kvůli kterému CLI existuje. Porovná váš projekt se slotem, do kterého má být nasazen, a vypíše všechny neshody – i každé porovnání, které se nepodařilo provést:

• Verze PHP, přičemž rozdíl v hlavní verzi (major) je označen jako vysoký (high), protože spolehlivě web rozbije, a rozdíl ve vedlejší verzi (minor) má nižší prioritu, jelikož označování všeho za kritické učí uživatele varování ignorovat.
• Zda slot může přepnout na verzi, na které jste projekt sestavili, zda PHP na slotu není po skončení životnosti (end of life) a zda server verzi již aplikoval, nebo mu to bylo pouze zadáno.
• Velikost a počet souborů vašeho projektu v porovnání s diskovou kapacitou a limitem inodů, které na slotu reálně zbývají – v adresářovém stromu WordPress může dojít volný počet souborů, i když má k zaplnění disku ještě daleko.
• Verze systému WordPress na obou stranách, zda slot dokončil zřizování (provisioning) a zda je připojen repozitář, do kterého lze odesílat.

Příkaz varuje, ale nikdy proces neblokuje. Každý nález lze obejít pomocí zinnector push --force, protože o svém vlastním webu víte věci, které kontrolní nástroj vědět nemůže. Porovnání, které nebylo možné provést, je nahlášeno jako neznámé (unknown), nikdy jako úspěšné, a souhrn vždy uvádí, kolik jich bylo. Ve výchozím nastavení je lokální verze PHP ta, která je deklarována v zinnector.json; parametr --probe místo toho spustí lokální běhové prostředí a verzi reálně změří. Parametr --strict vrací nenulový návratový kód i při neznámých hodnotách, což je přesně to, co se vyžaduje v rámci CI gate.

Odeslání (Push)

zinnector push

Příkaz push provede předletovou kontrolu, odešle vaše commity, spustí nasazení a sleduje jej až do dokončení, přičemž vypíše konečný stav a nasazený commit. Parametr --dry-run provede vše kromě samotného nasazení; --no-wait nasazení spustí a okamžitě se ukončí; --no-git nasadí to, co již na platformě je, aniž by cokoliv odesílal přes git. Pokud nasazený commit neodpovídá tomu, který byl právě odeslán, příkaz na to upozorní.

Když se něco pokazí

zinnector deploys example.com        # deploy history — status, commit, trigger, message
zinnector logs example.com --build   # the build log of the most recent deploy
zinnector logs example.com --error   # the site's error log
zinnector deploy example.com         # redeploy what the platform already has
zinnector ai "why is my deploy failing?"

Příkaz zinnector ai běží na platformě v kontextu vašeho vlastního účtu, takže má přístup ke stejné historii nasazení i protokolům. Ze složky projektu odesílá pouze jeho strukturu – názvy adresářů, verze a ID webu – a nikdy neobsahuje samotný obsah souborů.

Související

• Začínáme · Místní vývoj · Přehled příkazů · Řešení problémů