Внедряване със Zinnector®: свързване, проверка, качване

След като даден проект заработи локално, четири команди го пренасят към работещ сайт на хостинг от Zinn Digital®: влизане в профила, свързване на проекта с хостинг слот, преглед на предварителната проверка (pre-flight) и качване (push). Тази статия разглежда подробно всяка от тях, какво извежда тя и командите, към които прибягвате след това — повторни внедрявания, история на внедряванията и регистрационни файлове на компилацията.

Влизане в профила с API ключ

Създайте ключ в контролния панел под Настройки → API ключове, след което:

zinnector login

Ключът се въвежда при запитване на екрана — той никога не се приема директно в командния ред, така че не може да попадне в историята на Вашия шел или в списъка с процеси. В CI го предайте чрез конвейер: 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 хранилище на проекта към сайта в платформата, така че качването (push) да задейства внедряване. Ангажирайте (commit) zinnector.json: колега, който клонира хранилището, след това внедрява на същото място, без да се налага да му се казва. Той не съдържа тайни данни.

Преглед на предварителната проверка

zinnector check

Това е командата, заради която съществува CLI инструментът. Тя сравнява Вашия проект със слота, към който предстои да бъде внедрен, и извежда всяко несъответствие — както и всяко сравнение, което не е могла да направи:

• Версия на PHP, като разлика в основната версия се определя като висока, защото надеждно чупи сайта, а второстепенна разлика се оценява с по-нисък приоритет, тъй като оценяването на всичко като критично учи хората да пропускат предупреждението.
• Дали слотът може да превключи към версията, на която сте градили, дали версията на PHP на слота е с изтекъл жизнен цикъл и дали машината е приложила версията или само е била уведомена.
• Размерът и броят на файловете на Вашия проект спрямо аванса от дисково пространство и inode структури, действително останал на слота — структурата на WordPress може да изчерпи лимита за брой файлове, докато все още е далеч под лимита за дисково пространство.
• Версиите на WordPress от двете страни, дали слотът е завършил първоначалното осигуряване на ресурси и дали има свързано хранилище, към което да се качва.

Тя предупреждава; никога не блокира. Всяка констатация може да бъде пренебрегната с zinnector push --force, защото Вие знаете неща за собствения си сайт, които инструментът за проверка не знае. Сравнение, което не е могло да бъде направено, се отчита като unknown, никога като успешно, а обобщението винаги показва колко са били те. По подразбиране локалната версия на PHP е тази, декларирана в zinnector.json; --probe стартира локалната среда за изпълнение и вместо това я измерва пряко. --strict връща ненулев изходен код и при неизвестни стойности, което е точно целта при контролна проверка в CI.

Качване (Push)

zinnector push

push изпълнява предварителната проверка, качва Вашите ангажименти (commits), задейства внедряването и го следи до завършване, като извежда крайния статус и внедрения commit. --dry-run прави всичко с изключение на самото внедряване; --no-wait го задейства и прекратява изпълнението; --no-git внедрява каквото платформата вече има, без да качва нищо. Ако внедреният commit не е този, който току-що е бил качен, тя ще Ви уведоми.

Когато нещо се обърка

zinnector deploys example.com        # история на внедряванията — статус, commit, тригер, съобщение
zinnector logs example.com --build   # регистрационен файл от компилацията на най-новото внедряване
zinnector logs example.com --error   # регистрационен файл с грешки на сайта
zinnector deploy example.com         # повторно внедряване на това, което платформата вече съдържа
zinnector ai "why is my deploy failing?"

zinnector ai се изпълнява в платформата спрямо Вашия собствен акаунт, така че може да вижда същата история на внедряванията и регистрационни файлове. От вътрешността на даден проект то изпраща структурата на проекта — имена на директории, версии и идентификатора на сайта — и никога съдържание на файлове.

Свързани теми

• Първи стъпки · Локална разработка · Справочник с команди · Отстраняване на неизправности