База знань

Розгортання за допомогою Zinnector®: зв'яжіть, перевірте, надішліть

Від локального проєкту до живого сайту: увійдіть за допомогою ключа API, зв’яжіть проєкт із хостинг-слотом, перевірте звіт перед розгортанням, який порівнює ваші PHP, диск і WordPress зі слотом, та виконайте публікацію, а також повторні розгортання, історію розгортань і логи збірки на випадок виникнення проблем.

Коли проєкт починає працювати локально, чотири команди переносять його на живий сайт на хостингу Zinn Digital®: увійти в систему, зв'язати проєкт із хостинговим слотом, переглянути передстартову перевірку та виконати push. У цій статті описано кожну з них, те, що вона виводить, а також команди, які знадобляться згодом — повторні розгортання, історію розгортань і логи збірки.

Увійдіть за допомогою ключа API

Створіть ключ у панелі керування в розділі Settings → API keys, а потім:

zinnector login

Ключ вводиться у підказці — він ніколи не приймається в командному рядку, тому не може потрапити до історії оболонки чи списку процесів. У CI передайте його через пайплайн: echo "$ZINN_API_KEY" | zinnector login --profile ci, або встановіть ZINNECTOR_TOKEN і повністю пропустіть login. Ключ перевіряється перед збереженням і зберігається з правами доступу файлу 600. Команда zinnector whoami --scopes показує, до якої організації ви увійшли та які дозволи має ключ; ключ пісочниці позначено відповідно.

Зв'яжіть проєкт зі слотом

zinnector link                                   # вибрати сайт зі списку
zinnector link example.com --repo acme/site --branch main

Команда link записує ідентифікатор сайту в zinnector.json і, якщо ви не передасте прапорець --no-repo, підключає віддалений репозиторій git проєкту до сайту на платформі, щоб push виконував розгортання. Закомітьте zinnector.json: колега, який клонує репозиторій, зможе розгорнути його в те саме місце без додаткових інструкцій. Він не містить жодних секретних даних.

Прочитайте передстартову перевірку

zinnector check

Це команда, заради якої й існує CLI. Вона порівнює ваш проєкт зі слотом, на який його буде розгорнуто, і виводить кожну невідповідність, а також кожне порівняння, яке не вдалося виконати:

  • Версію PHP, причому різниця у мажорній версії класифікується як висока (high), оскільки це надійно ламає сайт, а різниця у мінорній — нижче, адже класифікація всього як критичного вчить людей ігнорувати попередження.
  • Чи може слот перемкнутися на версію, на якій ви виконували збірку, чи минув термін підтримки PHP слота, і чи застосувала машина цю версію, чи їй лише сказали це зробити.
  • Розмір проєкту та кількість файлів порівняно з дисковим простором та індексами inode, які фактично залишилися на слоті — дерево WordPress може вичерпати ліміт файлів, навіть перебуваючи далеко від ліміту диска.
  • Версії WordPress з кожного боку, чи завершено налаштування слота, і чи підключено репозиторій для виконання push.

Вона попереджає, але ніколи не блокує. Будь-яку знахідку можна перевизначити за допомогою zinnector push --force, оскільки ви знаєте про свій власний сайт те, чого перевірка не знає. Порівняння, яке не вдалося виконати, позначається як unknown (невідомо), ніколи як успішне, а в підсумку завжди зазначається їхня кількість. За типом локальна версія PHP є тією, яка оголошена в zinnector.json; прапорець --probe завантажує локальне середовище виконання та вимірює її натомість. Прапорець --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 "чому мій деплой зазнає невдачі?"

Команда zinnector ai працює на платформі з вашим власним обліковим записом, тому вона має доступ до тієї самої історії розгортань і логів. Зсередини проєкту вона надсилає структуру проєкту — назви директорій, версії та ідентифікатор сайту — і ніколи не надсилає вміст файлів.

Пов'язані матеріали

Все ще потрібна допомога?

Підтримка включена до кожного тарифного плану та надається рідною мовою.

Звернутися до підтримки Усі статті