11.08.2021 14:03
mrrvz 10 1800 Источник


Два года назад мы уже рассказывали вам, что такое Cartridge и как с его помощью разрабатывать распределенные приложения. Это полноценный фреймворк, в который входит CLI-интерфейс, который сильно упрощает разработку и эксплуатацию приложений на Tarantool Cartridge.

Я расскажу вам, как можно использовать Cartridge CLI для эффективного использования ваших локальных приложений, и об интересных фичах самого CLI. Статья больше ориентирована на тех, кто уже использует Cartridge или хочет начать им пользоваться. Поехали!

Какие проблемы решает Cartridge CLI?


У нас есть Tarantool Cartridge, который решает проблемы взаимодействия и масштабирования нескольких микросервисов в рамках одного приложения. Поговорим о трудностях, которые возникают в процессе разработки.

С чего начать?


Вы захотели использовать Cartridge. Первая мысль, которая возникает в вашей голове: «Как мне запустить мое приложение?» Как минимум, вам нужно реализовать точку входа. Но при этом вы решите лишь часть проблемы — дальше нужно будет понять, как вообще запускать приложение.

Cartridge CLI содержит готовый шаблон приложения. В этом шаблоне есть все необходимые файлы (и не только) для того, чтобы запустить и сконфигурировать ваш кластер. Вам не нужно думать, какие файлы создать в проекте, что они должны из себя представлять и так далее. Кроме того, в стандартный шаблон легко вносить изменения в соответствии с вашими нуждами.

Сборка, запуск и настройка приложения


Приложение нужно собрать: как минимум — поставить сам Cartridge (он устанавливается как отдельный Lua-пакет), а как максимум — еще десяток зависимостей в виде Lua-пакетов (и не только), которые используются в вашем приложении. Конечно, вы можете написать свой скрипт, который будет собирать приложение за вас, и использовать его в каждом вашем приложении. Но зачем всякий раз придумывать велосипед?

Допустим, приложение вы успешно собрали. Теперь вы хотите локально запустить экземпляры и сконфигурировать приложение: создать наборы реплик, выставить им роли и так далее… В Cartridge CLI есть всего три команды, с помощью которых можно выполнить вышеуказанные действия в одну строчку: собрать, запустить и настроить ваше приложение.

Настройка набора реплик и failover


Да, управление через GUI нельзя называть проблемой. Для кого-то, может быть, это будет плюсом. Но я всё равно решил выделить как отдельное преимущество Cartridge CLI, и сейчас объясню почему:

  • Для того, чтобы сконфигурировать кластер через GUI, нужно зайти в браузер и сделать N кликов. Чтобы сделать то же самое с помощью CLI, достаточно ввести одну команду. Как минимум, это экономия времени.
  • Если вы решите сбросить конфигурацию кластера в GUI и заново настроить его, то всё придется повторить — сделать еще N кликов вместо вызова одной команды.
  • Вы можете однажды собрать минимальную конфигурацию кластера, сохранить её в файл и закоммитить в репозиторий. После этого кто угодно (в том числе и вы при каждом перезапуске кластера) сможет поднимать настроенный кластер одной командой.
  • Может быть, вам просто совсем не нравится пользоваться GUI.

Упаковка приложения


Представьте, что вы написали приложение и хотите отправить его клиенту в формате rpm-пакета. Сначала вам нужно будет описать файл .spec, установить (например) утилиту rpmbuild, и только после этого начать сборку пакета. Утомительно, не правда ли?

В Cartridge CLI процесс упаковки приложения унифицирован, содержит основные формы упаковки приложения (deb, rpm, tgz и Docker image) и много упрощающих этот процесс опций. Всё это позволяет не думать об упаковке в принципе, а просто вызвать одну команду с удобным интерфейсом.

Создаем и запускаем первое приложение


Для начала нам потребуется установить Cartridge CLI.

Установка на Debian или Ubuntu:

curl -L https://tarantool.io/IMYxqhi/release/2.7/installer.sh | bash
sudo apt install cartridge-cli

Установка на CentOS, Fedora или ALT Linux:

curl -L https://tarantool.io/IMYxqhi/release/2.7/installer.sh | bash
sudo yum install cartridge-cli

Установка на MacOS:

brew install cartridge-cli

Чтобы убедиться в успешной установке введите команду:

cartridge version

В случае, если всё прошло успешно, вы увидите следующее сообщение:


Не обращайте внимание на предупреждение, ведь проект мы еще не создали (и, соответственно, не установили сам Cartridge).

Команда cartridge create создает приложение с использованием стандартного шаблона приложения на Cartridge:

cartridge create --name myapp && cd myapp


Стандартный шаблон приложения содержит файлы:

### Файлы приложения
├── README.md
├── init.lua
├── stateboard.init.lua
├── myapp-scm-1.rockspec
├── app
│   ├── admin.lua         
│   └── roles             
### Сборка и упаковка
├── cartridge.pre-build
├── cartridge.post-build
├── Dockerfile.build.cartridge
├── Dockerfile.cartridge
├── package-deps.txt
├── systemd-unit-params.yml
### Локальный запуск приложения
├── instances.yml
├── replicasets.yml
├── failover.yml
├── .cartridge.yml
├── tmp
### Тестирование
├── deps.sh
├── test
│   ├── helper.lua
│   ├── integration
│   └── unit

Если вам не нравится стандартный шаблон приложения, то можете создать свой шаблон и использовать его:

cartridge create --from mytemplate --name mycustomapp && cd mycustomapp

В корне проекта сразу инициализируется локальный Git-репозиторий, который уже содержит первый коммит:


Чтобы запустить экземпляры, соберем наше приложение:

cartridge build

Сборка выполняется с помощью утилиты tarantoolctl: она устанавливает все необходимые зависимости, в том числе Cartridge. Зависимости описаны в файле myapp-scm-1.rockspec. Если в вашем проекте понадобилась еще какая-либо зависимость, отредактируйте файл .rockspec, поместив зависимость туда, и введите команду cartridge build.

Проект содержит файл cartridge.pre-build: он запускается перед установкой зависимостей. Например, вы можете установить нестандартные модули rocks с помощью той же tarantoolctl:

#!/bin/sh
tarantoolctl rocks make --chdir ./third_party/my-custom-rock-module

Проверим, что проект был успешно собран и все зависимости установлены:


На экране появилась информация о версии Cartridge и список rocks проекта — информация о них выводится на экран, если указан флаг --rocks.

В файле instances.yml можно сконфигурировать ваши экземпляры (имя, порт и так далее). Описание должно быть в формате <имя-приложения>.<имя экземпляра>. Стандартый шаблон приложения уже содержит этот файл:

myapp.router:
  advertise_uri: localhost:3301
  http_port: 8081

myapp.s1-master:
  advertise_uri: localhost:3302
  http_port: 8082

myapp.s1-replica:
  advertise_uri: localhost:3303
  http_port: 8083

myapp.s2-master:
  advertise_uri: localhost:3304
  http_port: 8084

myapp.s2-replica:
  advertise_uri: localhost:3305
  http_port: 8085

Чтобы запустить описанные в этом файле экземпляры, используйте команду cartridge start:

cartridge start -d 
# убедимся, что все инстансы приложения были успешно запущены
cartridge status


Не обязательно запускать сразу все экземпляры. Можно, например, запустить лишь один s1-master:

cartridge start s1-master -d 
cartridge status s1-master

Точкой входа в наше приложение является файл с именем init.lua. Именно он под капотом запускает cartridge start.

Стандартный шаблон приложения в своём корне содержит папку tmp.

  • tmp/run — директория, хранящая PID процессов-экземпляров и socket-файлы;
  • tmp/data — директория, хранящая данные экземпляров;
  • tmp/log — директория, хранящая логи экземпляров.

Вы можете изменить стандартные пути к вышеописанным директориям, указав новые пути в файле .cartridge.yml или с помощью флагов команды cartridge start. Чтобы запустить экземпляры в фоновом режиме, используйте флаг -d. В таком случае логи будут сохраняться в файл и мы сможем их посмотреть с помощью команды cartridge log:


С помощью флага --stateboard или настройки stateboard: true в файле конфигурации .cartridge.yml вы можете также запустить изолированный экземпляр Tarantool, который можно будет использовать в качестве поставщика состояний для failover. Я предлагаю всегда запускать экземпляр stateboard (в дальнейшем его можно использовать для настройки failover), поэтому стандартный шаблон приложения уже содержит флаг stateboard: true. При необходимости вы можете безболезненно убрать этот флаг из файла конфигурации.

Настраиваем топологию


Команда cartridge replicasets позволяет выполнять различные действия по изменению топологии кластера (например, из конфигурационного файла) и сохранять конфигурацию кластера в файл. Созданный командой cartridge create шаблон приложения содержит файл replicasets.yml, с помощью которого мы можем сконфигурировать базовую топологию нашего кластера:

cartridge replicasets setup --bootstrap-vshard
# убедимся, что топология была успешно настроена
cartridge replicasets list


Всё! Одной командой мы настроили топологию, а также включили шардирование. Круто, не правда ли? Рассмотрим файл replicasets.yml подробнее:

router:
  instances:
  - router
  roles:
  - failover-coordinator
  - vshard-router
  - app.roles.custom
  all_rw: false
s-1:
  instances:
  - s1-master
  - s1-replica
  roles:
  - vshard-storage
  weight: 1
  all_rw: false
  vshard_group: default
s-2:
  instances:
  - s2-master
  - s2-replica
  roles:
  - vshard-storage
  weight: 1
  all_rw: false
  vshard_group: default

В нем содержится три набора реплик с именами router, s-1 и s-2.

  • instances — в этом блоке описаны экземпляры, которые содержит каждый из набора реплик. Имена экземпляров должны совпадать с именами, которые описаны в instances.yml.
  • В блоке roles описаны роли для каждого набора реплик;
  • weight — vshard-вес набора реплик.
  • all_rw — флаг, указывающий, что все экземпляры в наборе реплик должны быть доступны как для чтения, так и для записи.
  • vshard_group — имя группы vshard, к которой принадлежит набор реплик.

Если вдруг вам захотелось настроить всё это в ручную (без использования конфига replicasets.yml), то можете воспользоваться другими опциями cartridge replicasets:

# объединим экземпляры s1-master и s1-replica в набор реплик s-1:
cartridge replicasets join --replicaset s-1 s1-master s1-replica
# добавим реплику router:
cartridge replicasets join --replicaset router router
# посмотрим текущие доступные роли и выберем из них подходящие для каждой из реплик:
cartridge replicasets list-roles
# добавим роль vshard-storage для набора реплик s-1:
cartridge replicasets add-roles --replicaset s-1 vshard-storage
# также добавим роли для реплики router:
cartridge replicasets add-roles \
  --replicaset router \
  vshard-router app.roles.custom failover-coordinator metrics
# и наконец забутстрапим vshard:
cartridge replicasets bootstrap-vshard
# посмотрим конфигурацию набора реплик:
cartridge replicasets list


Сбросить заданную конфигурацию кластера можно с помощью следующих команд:

cartridge stop
cartridge clean

Настраиваем failover


После конфигурации топологии кластера, можно настроить failover:

cartridge failover setup
# посмотрим состояние failover
cartridge failover status


Команда cartridge failover setup использует конфигурацию, описанную в файле failover.yml, который находится в корне созданного приложения.

mode: stateful
state_provider: stateboard
stateboard_params:
  uri: localhost:4401
  password: passwd

У failover может быть три состояния: eventual, stateful и disabled:

  • eventual и disabled не требуют никаких дополнительных настроек;
  • stateful требует указания поставщика состояний (поле state_provider) и указания параметров для этого поставщика. На данный момент поддерживаются поставщики stateboard и etcd2.

Подробнее об архитектуре failover вы можете прочитать здесь. А здесь вы можете прочитать о всех параметрах, которые вы можете указать при его конфигурации. Вы также можете использовать команду cartridge failover set для ввода настроек failover прямо в командной строке:

cartridge failover set stateful \
  --state-provider etcd2 \ 
  --provider-params '{"lock_delay": 15}'

Для отключения failover используйте следующие команды:

cartridge failover disable
# или
cartridge failover set disabled

Подключаемся к экземплярам


Вам вдруг понадобилось подключиться экземпляру и ввести там интересующие вас команды, например, выполнить cartridge.reload_roles()? Легко!

С помощью cartridge enter вы можете подключиться к экземпляру через консольный сокет, размещенный в run-dir. Никаких дополнительных параметров не нужно, достаточно ввести имя экземпляра, указанного в instances.yml:

cartridge enter instance-name


Вы также можете использовать cartridge connect для подключения к интересующему вас экземпляру. Отличие этого подхода в том, что вы можете указать адрес экземпляра или путь к UNIX-сокету.

cartridge connect localhost:3301 \
  --username admin \
  --password secret-cluster-cookie
# либо
cartridge connect admin:secret-cluster-cookie@localhost:3301

Упаковываем приложение


Для упаковки приложения есть команда cartridge pack <tуpe>. На данный момент поддерживается четыре варианта упаковки:

  • deb — deb-пакет;
  • rpm — rpm-пакет;
  • tgz — tgz-архив;
  • docker — Docker-образ.

Например, для упаковки вашего приложения в tgz-архив используйте следующую команду:

cartridge pack tgz


Хотите собрать rpm- или deb-пакет, но при этом используете MacOS? Вы не можете сделать это просто так: в упакованном приложении будут rocks и исполняемые файлы, которые нельзя использовать в Linux. Специально для такого случая существует флаг --use-docker, который собирает в Docker:

cartridge pack deb --use-docker

Помимо --use-docker, команда cartridge pack имеет множество других полезных опций. Рассмотрим самые интересные из них.

Добавляем зависимости в пакет


Добавим в наш rpm- или deb-пакет какую-нибудь зависимость. Например, unzip:

cartridge pack deb --deps unzip>=6.0

Либо вы можете описать зависимости для вашего пакета в файле package-deps.txt, который уже находится в корне созданного приложения:

unzip==6.0
neofetch>=6,<7
gcc>8

Теперь, упаковав приложение с помощью команды cartridge pack deb, ваш пакет будет содержать зависимости unzip, neofetch и gcc. Вы можете использовать файл с другим именем для указания ваших зависимостей с помощью флага --deps-file:

cartridge pack rpm --deps-file=path-to-deps-file

Добавляем сборочные сценарии до (и после)


А что если во время упаковки вам нужно создать файл, папку, поставить какую-либо утилиту — то есть внести какие-либо изменения в сценарий упаковки приложения? Для этого используются файлы preinst.sh и postinst.sh.

Все пути к исполняемым файлам в сценариях до и после установки должны быть абсолютными. Либо используйте /bin/sh -c '':

/bin/sh -c 'touch file-path'
/bin/sh -c 'mkdir dir-path'

С помощью флагов --preinst и --postinst вы можете использовать файлы с любым именем:

cartridge pack rpm \
  --preinst=path-to-preinst-script \
  --posints=path-to-posinst-script

Сценарии работают только для сборки rpm- и deb-пакетов.

Кешируем пути


При каждом запуске упаковки приложение собирается с нуля. Например, сборка всех зависимостей (т.е. rocks) начинается заново. Чтобы этого избежать (и уменьшить время переупаковки приложения), существует опция кеширования путей и файл pack-cache-config.yml:

- path: '.rocks':
  key-path: 'myapp-scm-1.rockspec'
- path: 'node_modules':
  always-cache: true
- path: 'third_party/custom_module':
  key: 'simple-hash-key'

Рассмотрим подробнее параметры конфигурационного файла:

  • path — путь от корня проекта до кешируемого пути;
  • key-path — путь до файла, содержимое которого будет ключом кеширования. В примере выше для пути .rocks ключом кеширования является файл myapp-scm-1.rockspec — если изменить его, то cache hit не произойдет и все rocks приложения будут собираться заново;
  • always-cache — кеширование указанного пути всегда, независимо от каких-либо ключей;
  • key — простой ключ кеширования в виде строки.

В стандартном шаблоне приложения уже содержится один кешируемый путь:

- path: '.rocks'
  key-path: myapp-scm-1.rockspec

Я предлагаю всегда кешировать содержимое папки .rocks опираясь на содержимое файла .rockspec. Для одного пути может быть только один кеш. Например, у вас в кеше находится папка .rocks, вы меняете ключ и запускаете упаковку приложения. В этот момент старый кеш .rocks удаляется и заменяется новым на основе нового ключа.

Чтобы отключить кеширование путей, используйте флаг --no-cache. С полным списком опций команды cartridge pack вы можете ознакомиться здесь.

Подробнее о процессе упаковки


Команда cartridge pack помимо упаковки приложения в пакет ещё и собирает его (аналогично команде cartridge build). По умолчанию сборка выполняется во временной директории ~/.cartridge/tmp. Вы можете изменить её на свою, установив значение переменной окружения CARTRIDGE_TEMPDIR:

  • Если эта директория не существует, она будет создана и использована для сборки приложения, а затем удалена.
  • В противном случае сборка будет выполнена в директории CARTRIDGE_TEMPDIR/cartridge.tmp.

Создание временной директории (в которой будет выполняться сборка) с исходными файлами вашего приложения происходит в три этапа:

  1. Копирование файлов во временную директорию и её очистка. Папка с приложением копируется во временную директорию, выполняется команда git clean -X -d -f для удаления неотслеживаемых файлов и удаляются папки .rocks и .git.
  2. Сборка приложения в очищенной директории.
  3. Запуск скрипта cartridge.post-build (если он существует).

В корне проекта находится файл cartridge.post-build. Это скрипт, основная цель которого — удаление артефактов сборки из результирующего пакета. После сборки приложения во временной директории генерируются специальные файлы, такие как VERSION и VERSION.lua, которые содержат версию приложения. В случае сборки в rpm и deb инициализируются директории systemd и tmpfiles. Далее приложение упаковывается.

Подробнее о структуре и дальнейшей работе с полученными rpm- и deb-пакетами вы можете прочитать здесь. А здесь — про работу с Docker-образами.

Итоги


Cartridge CLI содержит удобный и унифицированный интерфейс для управления приложением и позволяет не придумывать велосипед. В этой статье я рассказал о том, как можно из командной строки максимально эффективно и удобно управлять вашим локальным приложением, написанным на Tarantool Cartridge: запускать, настраивать топологию и failover, упаковывать приложение и подключаться к его экземплярам.

Cartridge CLI имеет еще одну команду, о которой я не рассказал в этой статье. Команда cartridge admin призвана упростить разработчикам написание и поддержку эксплуатационных кейсов, повысить переиспользование операций, оптимизировать поставку в эксплуатацию. Почитать подробнее об этом вы можете в этой статье.

Если у вас что-то вдруг пошло не так, или вы знаете, как можно улучшить продукт, то всегда можете завести тикет в нашем GitHub-репозитории. Мы всегда поможем с решением вашей проблемы и будем рады интересным предложениям!

Комментарии (10)


  1. mobilesfinks
    11.08.2021 15:36
    #23359672
    +3

    Cartridge CLI содержит удобный и унифицированный интерфейс для управления приложением и позволяет не придумывать велосипед.

    Да весь этот картридж состоит из сплошных велосипедов:
    * сборка Докер образа через `cartridge pack docker`, который внутри себя генерит какой-то Докерфайл, который непонятно как работает. В темплейте приложения присутствуют пустые темплейты докерфайла. Попытка обвязать это всё в CI выливается в нехилый такой велосипед. А ведь можно было просто добавить чистый Dockerfile
    * в instances.yml описаны инстансы на локалхостах которые "запускаются командой cartridge start" - вы там docker-compose впилили ещё в картридж?
    * в статье ни слова о том, как управлять реальными инстансами, а только всё на кошках, которые подняты локально
    * как подключиться к уже существующему кластеру не описанному в instances.yml и поглядеть его состояние? не, я увидел команду connect, но я подключаюсь напрямую в cli чего-то (то ли тарантула, то ли картриджа). На help меня шлют в документацию. А добавить хелпа по командам не судьба? Хотелось бы увидеть, что там с удалённым кластером то творится без залезания в cli
    Я попробовал:

    • описал сервера в instances.yaml.

    • Сделал cartridge replicasets list.

    • Получил: ⨯ Failed to find some instance joined to cluster: No running instances found

    Что там было про "не придумывать велосипеды"?

    Там ещё много чего можно было бы перечислить, но не хочется. Документации много, прям много. Но толку от неё вообще мало.
    Попробуйте найти список переменных окружения используемых для конфигурации тарантула в контейнере картриджа. В документации этого я не нашёл. Знаете где? В файлике cartridge.yaml во вновь сгенерённом приложении. С одной стороны логично, с другой - в документации опишите.


    1. akudiyar
      12.08.2021 11:17
      #23362084

      в instances.yml описаны инстансы на локалхостах которые "запускаются командой cartridge start" - вы там docker-compose впилили ещё в картридж?

      Cartridge -- не только ценный мех фреймворк, но и обвязка из инструментов для работы с кластером Tarantool, cartridge-cli. cartridge start - это часть cartridge-cli. Уже есть развёрнутая статья о том, что такое cartridge-cli: https://habr.com/ru/company/mailru/blog/548228/

      в статье ни слова о том, как управлять реальными инстансами, а только всё на кошках, которые подняты локально

      Используйте ansible. Об этом у нас уже написаны отдельные развёрнутые статьи:
      https://habr.com/ru/company/mailru/blog/478710/
      И даже прям реальный кейс прода на 500 инстансов, совсем не "на кошках":
      https://habr.com/ru/company/mailru/blog/543086/

      как подключиться к уже существующему кластеру не описанному в instances.yml и поглядеть его состояние?

      Используйте cartridge connect: https://www.tarantool.io/ru/doc/latest/book/cartridge/cartridge_cli/#usage


      1. mobilesfinks
        12.08.2021 15:52
        #23363114
        +1

        Используйте ansible. 

        Да, я видел. Теперь расскажите как раздеплоить ваш тарантул через докер контейнеры. Ваша роль такого не умеет. Моя инфраструктура не предполагает деплой приложений вне докера.

        Используйте cartridge connect:

        Это называется издевательство. Я же отписал в комментарии - я попадаю в консоль картриджа. И? Что мне с этой консолью делать? запрос хелпа опять шлёт в документацию тарантула - где хочешь там и ищи команды.
        В документации (по вашей ссылке) ссылка на "enter and connect" - выдаёт 404 ошибку - такой страницы не существует.
        Это называется Уровень сопровождения и тех документации - он крайне низкий, если не сказать никакой.

        По поводу деплоя на 500 инстансов

        Вскоре мы нашли оркестратор, который не требует постоянных root-привилегий — supervisord.

        Шёл 2021 год, докер медленно сдавал позиции демонлесс утилитам, а разработка тарантула только открыла для себя supervisord
        Ау! Вы реально? Сразу скажу, что я сам использовал supervisord для части своих задач. Но блин, у вас картридж вроде как образы собирает, а вы на это просто забили. Но учитывая как у вас эта сборка организована, там тоже понятно всё.


        1. akudiyar
          12.08.2021 16:23
          #23363224

          Теперь расскажите как раздеплоить ваш тарантул через докер контейнеры

          1. Собираете образ с приложением с помощью cartridge pack docker или используете свой на базе нужной вам ОС, подключая репозиторий Тарантула, как описано на сайте.

          2. Описываете docker-compose.yml c указанием вашего образа / делаете docker run -d ваш_образ / прописываете образ в конфигурацию Docker Swarm, etc...

          3. ?????

          4. PROFIT!

          Вроде, ничего сложного.

          Что мне с этой консолью делать?

          А что вы хотите сделать?

          Это обычная консоль инстанса Тарантула, вы можете вызывать box.cfg, посмотреть содержимое спейсов через box.space.myspace:select(), переключиться в SQL режим, выполнить любой Lua-код, обратиться к API Cartridge или других модулей. Всё это есть в документации на сайте, а также в примерах в github и статьях тут, на Хабре.

          выдаёт 404 ошибку - такой страницы не существует.

          Грустно, что у нас здесь был косяк, но мы непрерывно исправляем документацию. Сообщить о таком косяке очень просто: надо выделить строчку и нажать Ctrl+Enter, а потом нажать "Отправить".

          Шёл 2021 год, докер медленно сдавал позиции демонлесс утилитам

          Ну так попробуйте Kubernetes operator для Tarantool.


    1. mrrvz Автор
      14.08.2021 17:42
      #23369982

      > сборка Докер образа через cartridge pack docker, который внутри себя генерит какой-то Докерфайл, который непонятно как работает. В темплейте приложения присутствуют пустые темплейты докерфайла.

      https://www.tarantool.io/en/doc/latest/book/cartridge/cartridge_cli/#build-and-runtime-images

      > в статье ни слова о том, как управлять реальными инстансами, а только всё на кошках, которые подняты локально

      Cartridge CLI используется для разработки локальных приложений, о чем сказано в самом начале статьи. Для управления удаленными инстансами, используйте ansible.

      > Что там было про "не придумывать велосипеды"?

      Команда ``cartridge replicasets`` (как и в целом Cartridge CLI) предназначена для локальной разработки. А  list у вас не работает, потому что инстансы нужно сначала поднять и настроить из топологию.

      > Попробуйте найти список переменных окружения используемых для конфигурации тарантула в контейнере картриджа.

      https://www.tarantool.io/en/doc/latest/book/cartridge/cartridge_cli/#docker


      1. mobilesfinks
        16.08.2021 11:08
        #23374928
        +2

        Команда ``cartridge replicasets`` (как и в целом Cartridge CLI) предназначена для локальной разработки.

        Тогда вам просто необходимо научиться называть статьи правильно

        Управляем кластером на Tarantool из командной строки

        Так управляем кластером или всё же для локальной разработки?

        Настройка набора реплик и failover

        Да, управление через GUI нельзя называть проблемой. Для кого-то, может быть, это будет плюсом. Но я всё равно решил выделить как отдельное преимущество Cartridge CLI, и сейчас объясню почему:

        Нафига всю статью рассказывать как красиво ваш CLI управляет кластером, когда ваш кластер это мулька локальная к реальности не имеющая отношения вообще?


  1. mobilesfinks
    13.08.2021 11:44
    #23365874
    +2

    Ну так попробуйте Kubernetes operator для Tarantool.

    Знаете, первым делом это и сделали
    Как оказалось он кластер не собирает. Вдруг кластер остаётся в позиции "все сервера Unconfigured". Ну и что там ваш оператор делает? Умеет из шаблонов собирать стейтфулсет манифесты?
    А где конфигмапы для инстансов?
    Как вы конфигурите это безобразие? Никак. Ручками похоже.

    А что вы хотите сделать?

    Ну например сделать так как написано в статье 

    cartridge replicasets list

    и увидеть что там на поднятом кластере с репликами.
    А не лезть в консоль и не искать какие же команды ввести. Ну вот я первый раз поднимаю кластер тарантула и вообще тарантул в глаза первый раз вижу. Вместо помощи пользователю у вас постоянные отсылки в документацию, в которой непонятно, что и как описано.
    Я же писал, документация есть, её много, но она бестолковая.
    Мне как новому пользователю ваш продукт непонятен, неясен, плохо документирован, имеет множество проблем на старте подготовки к старту и на базе бутстрапа. 

    Вроде, ничего сложного.

    Так мы это и без вас знаем. Только вот по ссылке указано как установить тарантул, а не картридж.
    Попробуйте запихнуть `cartridge pack docker` в докер раннер гитлаба например. Вы огребётесь. Потому, что ваш сборщик это велосипед, который собирает сначала билд образ, потом в билд образе второй образ, монтирует сам что-то куда-то из основной системы и тд. Если я верно понял вы реализовали мультистейдж на уровне своего велосипеда. FYI В докерфайлах мультистейдж уже давно реализован.

    Намного правильней было бы, если бы вы просто описали процесс сборки образа без картриджа и показали, потом, как он собирает это одной командой - так было бы правильнее и логичнее. И каждый мог бы выбрать самостоятельно - собирать самому или через pack docker.

    У вас в документации упор на "соберите приложение". Мне это приложение не нужно. Мне нужен кластер. Поднять несколько инстансов, указать им конфиг, и чтобы они собрались. Так сделано в эластике, монге и многих других кластерных решения. В вашем случае в документации описаны вроде файлы конфигурации, но Где они? Как их указывать при старте? Что писать? Местами какие-то упоминания про конфигурирования есть, но это настолько всё неявно, настолько всё размазанно, что непонятно про конфигурацию ничего.
    Сгенерите приложение и радуйтесь - вот посыл который исходит из вашей документации.


    1. mrrvz Автор
      14.08.2021 18:16
      #23370070

      > Намного правильней было бы, если бы вы просто описали процесс сборки образа без картриджа и показали, потом, как он собирает это одной командой - так было бы правильнее и логичнее. И каждый мог бы выбрать самостоятельно - собирать самому или через pack docker.


      Сам Cartridge не умеет собирать приложения (это фича CLI) - и это можно понять прочитав статью или хотя бы ее введение. Вы документацию так же читаете, между строк? Тогда все понятно =)

      Вы уже несколько раз смешиваете понятия Cartridge и Cartridge CLI:

      Cartridge - это фреймворк, с помощью которого может поднять свой кластер. В том числе, он может быть удаленным.
      Cartridge CLI - специальная утилита, упрощающая жизнь при локальной разработке с использованием Cartridge.

      Сборка образа картриджа описана здесь: https://www.tarantool.io/en/doc/latest/book/cartridge/cartridge_cli/#build-and-runtime-images


      1. mobilesfinks
        16.08.2021 10:51
        #23374872
        +1

        Вы уже несколько раз смешиваете понятия Cartridge и Cartridge CLI:

        CLI - command line interface - в "народе" эта приставка ставится к утилитам которые работают в командной строке.
        Зачем утилиту для локальной разработки называть именем фреймворка который используется для боевой задачи?
        Вы сами вносите путаницу во всю документацию и приставка CLI и никакая другая тут вам не помогут.

        Сборка образа картриджа описана здесь: https://www.tarantool.io/en/doc/latest/book/cartridge/cartridge_cli/#build-and-runtime-images

        Спасибо кэп. Вместо этого можно было сделать один мультистейджовый Докерфайл и не захламлять сознание вот тем бредом, что там написан. Но вы идёте своим путём.
        Хотя вот сейчас я увидел по крайней мере, что там есть ссылки на ссылки в которых описано как собирается это всё. Ок, теперь мне их этого раздербанненого документа нужно будет составить пайп сборки. Крайне непонятно при первичном чтении. Я ожидаю, что все пункты будут освещены в главе, а вы просто ссылок повыткали и радуетесь.
        Да, ещё можно же просто предоставить свой офф образ и собирай туда какой хочешь картридж, там уже всё будет готово, но увы - это не про ваш продукт.


  1. mobilesfinks
    16.08.2021 11:11
    #23374944
    +1

    Это полноценный фреймворк, в который входит CLI-интерфейс, который сильно упрощает разработку и эксплуатацию приложений на Tarantool Cartridge.

    Cartridge - это фреймворк, с помощью которого может поднять свой кластер. В том числе, он может быть удаленным.Cartridge CLI - специальная утилита, упрощающая жизнь при локальной разработке с использованием Cartridge.

    Кто-то включает заднюю? Про только локальную разработку не сказано. Везде и в статье и в документации эта "утилита" позиционируется как полноценный инструмент для работы с кластером. Только постоянно забывается, что кластер оказывается локальный.
    Вот потому и у вас документация хреновая - вы подменяете понятия, придумываете свои велосипеды и пытаетесь протолкнуть сырое поделие как нечто готовое к серьёзной эксплуатации.