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

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

Вхід за допомогою ключа API

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

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-репозиторій проєкту до сайту на платформі, щоб надсилання змін ініціювало розгортання. Зафіксуйте zinnector.json у репозиторії: колега, який клонує репозиторій, зможе виконувати розгортання в те саме місце без додаткових вказівок. Він не містить жодних секретних даних.

Перегляд попередньої перевірки

zinnector check

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

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

Вона попереджає; вона ніколи не блокує. Будь-яке зауваження можна обійти за допомогою команди zinnector push --force, адже ви знаєте про свій сайт те, чого не знає засіб перевірки. Порівняння, яке не вдалося виконати, позначається як невідомо, а не як успішне, і у зведенні завжди зазначено, скільки таких випадків було виявлено. За замовчуванням локальною версією PHP вважається та, яка оголошена в zinnector.json; прапорець --probe запускає локальне середовище виконання та визначає її на практиці. Прапорець --strict повертає ненульовий код завершення також і для невідомих результатів, що й потрібно для перевірок у CI.

Надсилання змін

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 працює на платформі в межах вашого облікового запису, тому вона має доступ до тієї самої історії розгортань і журналів. Зсередини проєкту вона надсилає структуру проєкту — назви каталогів, версії та ідентифікатор сайту — і ніколи не передає вміст файлів.

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

• Початок роботи · Локальна розробка · Довідник команд · Усунення несправностей