База знания
Деплойване с Zinnector®: свържете, проверете, качете
От локален проект до работещ сайт: влезте с API ключ, свържете проекта с хостинг слот, прегледайте проверката преди стартиране, която сравнява вашите PHP, дисково пространство и WordPress със слота, и качете – плюс повторни внедрявания, история на внедряванията и логове на компилацията, когато нещо се обърка.
Когато даден проект работи локално, четири команди го прехвърлят към активен сайт в хостинга на Zinn Digital®: влизане в профила, свързване на проекта с хостинг слот, проверка преди полет и качване (push). Тази статия разглежда всяка от тях, какво извежда тя, както и командите, които използвате след това – повторни деплойвания, история на деплойванията и логове за компилация.
Вход с API ключ
Създайте ключ в таблото за управление под Настройки → API ключове, след което:
zinnector login
Ключът се въвежда в подкана – той никога не се приема в командния ред, така че не може да попадне в историята на вашия shell или в списък с процеси. В CI го подайте с тръба (pipe): echo "$ZINN_API_KEY" | zinnector login --profile ci или задайте ZINNECTOR_TOKEN и пропуснете login изцяло. Ключът се проверява, преди да бъде съхранен, и се съхранява с файлов режим 600. zinnector whoami --scopes показва в коя организация сте влезли и какви разрешения притежава ключът; ключовете за пясъчна кутия (sandbox) се етикетират като такива.
Свързване на проекта със слот
zinnector link # изберете сайт от списък
zinnector link example.com --repo acme/site --branch main
link записва идентификатора на сайта в zinnector.json и, освен ако не подадете --no-repo, свързва git отдалеченото хранилище (remote) на проекта със сайта на платформата, така че качването (push) да го деплойва. Комтитирайте zinnector.json: колега, който клонира хранилището, след това деплойва на същото място, без да му бъде казвано. Той не съдържа чувствителна информация.
Проверка преди полет (Pre-flight)
zinnector check
Това е командата, заради която съществува CLI инструментът. Тя сравнява вашия проект със слота, на който предстои да бъде деплойван, и отпечатва всяко несъответствие – както и всяко сравнение, което не е могло да бъде направено:
- Версия на PHP, като разлика в основната версия (major version) се оценява като висока (high), тъй като тя надеждно чупи сайта, а разлика в поддържащата версия (minor) се оценява с по-нисък приоритет, защото оценяването на всичко като критично учи хората да пропускат предупреждението.
- Дали слотът може да премине към версията, на която сте градили, дали PHP на слота е с изтекъл живот (end of life) и дали машината е приложила версията, или просто ѝ е било казано.
- Размера и броя файлове на вашия проект спрямо дисковото пространство и inodes, които реално остават на слота – едно дърво на WordPress може да остане без файлове, дори когато е далеч под лимита си за диск.
- Версиите на WordPress от двете страни, дали слотът е завършил подготовката си (provisioning) и дали към него е свързано хранилище за качване.
Тя предупреждава; никога не блокира. Всяка констатация може да бъде пренаписана с zinnector push --force, тъй като вие знаете неща за собствения си сайт, които проверяващият инструмент не знае. Сравнение, което не е могло да бъде направено, се отчита като неизвестно (unknown), никога като успешно, и обобщението винаги показва колко такива е имало. По подразбиране локалната версия на PHP е тази, която е декларирана в zinnector.json; --probe стартира локалната среда за изпълнение (runtime) и я измерва вместо това. --strict излиза с ненулев код за грешка и при неизвестни стойности, което е точно това, което се изисква от CI гейт.
Качване (Push)
zinnector push
push стартира проверката преди полет, качва вашите коммити, задейства деплойването и го наблюдава до завършването му, като извежда крайния статус и деплойвания коммит. --dry-run прави всичко с изключение на деплойването; --no-wait го задейства и излиза; --no-git деплойва всичко, което платформата вече има, без качване. Ако деплойваният коммит не е този, който току-що е бил качен, това се отбелязва.
Когато нещо се обърка
zinnector deploys example.com # история на деплойванията — статус, коммит, задействане, съобщение
zinnector logs example.com --build # логът на компилацията от най-скорошното деплойване
zinnector logs example.com --error # логът за грешки на сайта
zinnector deploy example.com # повторно деплойване на това, което платформата вече има
zinnector ai "why is my deploy failing?"
zinnector ai се изпълнява на платформата спрямо вашия собствен акаунт, така че може да види същата история на деплойванията и логове. От вътрешността на проект тя изпраща структурата на проекта – имена на директории, версии и идентификатор на сайта – и никога съдържанието на файловете.
Свързани
Все още изпитвате затруднения?
Поддръжката е включена във всеки план с отговори на вашия собствен език.
Свържете се с поддръжката → Всички статии →