---
title: "Ring CLI"
description: "Команда ring постачається в публічному репозиторії в cli/. Використовуйте upgrade, щоб підтягнути системні оновлення з upstream у свій клон, config і test для локальних перевірок, а prod чи status лише тоді, коли у вас власний кластер Kubernetes."
locale: "uk"
---
# Ring CLI

> **Info**
> **Статус:** Ring CLI постачається в публічному репозиторії в `cli/`. Раніше документація стверджувала, що CLI доступний лише в enterprise-версії, але це вже не так. `upgrade`, `config` і `test` працюють для будь-якого клону. `prod` і `status` очікують кластер Kubernetes, до якого ви підключаєтеся через SSH, і маніфести, які ви надаєте самі. Використовуйте вкладки **Засновник** / **Розробник** на бічній панелі, щоб відфільтрувати цю сторінку.

Команда `ring` є невеликим інструментом на Node.js (`commander`, Node 18 або новіший), який лежить поруч із застосунком у репозиторії Layer 1: `ring/cli/` поряд із `ring/web/`. Вона виконує три завдання: підтягує оновлення Ring з upstream у ваш клон, зберігає локальну конфігурацію розгортання і викочує Docker-образ у Kubernetes.

| Раніше в документації | Поточний репозиторій |
|-------------------|--------------|
| CLI немає в публічному репозиторії GitHub | `cli/` відстежується в корені репозиторію і публікується |
| Виконайте `npm link`, потім `ring --version` | Виконайте `npm run cli:install` з `web/`, потім `ring --help` |
| `ring deploy prod` | Команда називається `ring prod`. Підкоманди `deploy` немає |
| Спільнота користується лише скриптами | Спільнота може використовувати `ring upgrade` для безпечних злиттів з upstream |

### For founders

## Що CLI дає вашому клону

  
- **[Залишайтеся в актуальному стані](/docs/development/community-tooling.md)** — `ring upgrade` показує, які системні файли Ring змінилися в upstream, і зливає їх лише за вашою командою.

  
- **[Власний хостинг](/docs/deployment/self-hosted.md)** — Немає кластера? Використовуйте `install.sh` і звичайний хост із Node або Docker. CLI необов'язковий.

  
- **[Керований хостинг](/docs/development/oss-vs-enterprise.md)** — Для поселенців Ringdom конвеєр збирання і розгортання запускають за них.

### Типові сценарії

1. **Ви зробили форк Ring кілька місяців тому.** Ваш розробник запускає `ring upgrade`, щоб побачити зміни в upstream, переглядає diff, а потім застосовує його. Нічого не комітиться автоматично.
2. **У вас власний Kubernetes.** Ваш розробник спрямовує CLI на ваш керувальний вузол, реєстр і простір імен, а потім випускає нові версії через `ring prod`.
3. **Вам потрібен лише один сервер.** Обійдіться без CLI. Скористайтеся посібником із власного хостингу.

> **Tip**
> Одразу після встановлення значення CLI за замовчуванням вказують на власний продакшн-кластер і реєстр Ringdom. Попросіть розробника задати ваші значення через `ring config`, перш ніж запускати `prod` або `status`.

### For developers

## Встановлення

**Під'єднайте бінарний файл**

{`npm run cli:install   # cd ../cli && npm install && npm link
ring --help

# or run without a global link
npm run cli:dev -- --help`}

**Спрямуйте CLI на свою інфраструктуру**

Конфігурація зберігається в `~/.ring-platform.org/config.json` і починається зі значень за замовчуванням із `cli/config.js`.

{`ring config --set k8s.controlNode=
ring config --set k8s.namespace=
ring config --set k8s.deployment=
ring config --set app.url=https://
ring config --list`}

## Команди (з `cli/index.js`)

| Команда | Що робить | Основні параметри |
|---------|--------------|--------------|
| `ring upgrade` | Тристороннє злиття системних файлів з upstream у ваш клон. За замовчуванням лише попередній перегляд | `--apply`, `--repo `, `--branch `, `--force` |
| `ring config` | Читання і запис `~/.ring-platform.org/config.json` | `--set k=v`, `--get k`, `--list`, `--reset` |
| `ring test` | Перевірки бази даних і сервісів | `--type db-connection\|db-service\|user-data\|username` |
| `ring prod` | Збирання Docker, push, `kubectl apply`, `set image`, очікування rollout | `--deploy-version`, `--skip-build`, `--skip-push`, `--skip-deploy`, `--skip-manifest-apply`, `--apply-k8s-secrets`, `--dry-run` |
| `ring status` | Поди, сервіси та ingress через SSH, потім `GET {app.url}/api/health` | немає |

`ring prod` також має `--forge-buildkit` і `--from-forge`. Обидва параметри керують приватним збирачем Ringdom і поза ним не корисні.

## Як працює `ring upgrade`

- **Upstream:** `upgrade.repoUrl` за замовчуванням `https://github.com/connectplatform/ring`, гілка `main`, ім'я remote `ring-upstream`.
- **База:** останній синхронізований коміт upstream (`upgrade.lastSyncedRef`). Зачіпаються лише файли, змінені між базою та upstream.
- **Винятки:** шляхи з `.reggie-propagate-exclude.json` завжди пропускаються.
- **Безпека:** конфлікти залишаються у вигляді стандартних маркерів git. Нічого не комітиться. Історія записується в `.ring-upgrade-history.json` у корені git.

{`ring upgrade            # dry run: list upstream changes
ring upgrade --apply    # write the merge to your working tree
git diff                # review, then commit yourself`}

## Що потрібно для `ring prod`

| Вхідні дані | Звідки беруться |
|-------|---------------------|
| Репозиторій образу | `RING_DOCKER_REGISTRY` / `RING_DOCKER_NAMESPACE` / `RING_DOCKER_IMAGE` (за замовчуванням: реєстр Ringdom) |
| Маніфести | `web/k8s/deployment.yaml`, інакше `k8s/` в org-оверлеї (`cli/paths.js` `resolveK8sDir`). Їх немає в публічному репозиторії |
| Секрети кластера | `--apply-k8s-secrets` читає `RING_K8S_SECRETS_YAML` або `k8s/secrets.yaml` |
| Аргументи збирання | JSON у `RING_CLI_SECRETS_PATH` (`build_args`) |
| Хост із kubectl | `k8s.controlNode` або `RING_K8S_SSH_HOST` для одного запуску |

Завжди спочатку запускайте `ring prod --dry-run`. Ця команда виводить кожну команду збирання, push і `kubectl`, не виконуючи їх.

## Відомі прогалини

## Пов'язана документація

  
- [development/community-tooling](/docs/development/community-tooling.md) — Наступний крок: повний перелік публічних скриптів налаштування, що лежать поруч із CLI.

  
- [development/oss-vs-enterprise](/docs/development/oss-vs-enterprise.md) — Див. також: які частини конвеєра CLI працюють лише всередині Ringdom.

  
- [deployment/self-hosted](/docs/deployment/self-hosted.md) — Той самий процес: розгортання без Kubernetes, де CLI необов