трям может кто подкинуть #link на "как в gitlab CI организовать деплой на удаленные сервера хоть как-нибудь, например запустить на них bash скрипт, который сделает git pull origin master"? пытаюсь въехать в эту тему, нормального туториала не найду

Ансиблом попробуйте

короче, регистрирую раннер, а дальше написть YAML скрипт, который будет коннектиться на каждый из серверов по ssh и экзекутить там баш скрипт, который будет пулить ветку?)

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

Запускайте в гитлабе ансибл и будет норм

А не проще гитлабом собирать пакет, а на серверах дергать apt update ? Просто делать на каждом сервере git pull кажется несколько менее удобным

хм, а кто как снепшотит эластику, находящуюся в докере? раскатана на трех нодах, "крон" на одной из нод, т.е. если она приляжет физически, то и снепшотов не видать свежих

не кубер)

хм, а кто как снепшотит эластику, находящуюся в докере? раскатана на трех нодах, "крон" на одной из нод, т.е. если она приляжет физически, то и снепшотов не видать свежих

Ну, отселить джобу в отдельный контейнер, раскатать по кластеру. В эластике создать индекс, в котором будет запись о том какой из контейнеров мастер, написать хартбиты для определения состояния мастера.

а это идея, спасибо!

локи? заморочь такой

Сделайте маленький сервис, который крон-джобами через etcd руляет Он вам точно пригодится в будущем

хм, а кто как снепшотит эластику, находящуюся в докере? раскатана на трех нодах, "крон" на одной из нод, т.е. если она приляжет физически, то и снепшотов не видать свежих

Пихаете в etcd список крон-задач, пишите сервис, который катаете на все ноды. 1. Он подписывается на изменения списка крон-задач 2. Планирует исходя из него когда что выполнить 3. Когда приходит время выполнить задачу: * пытается взять лок в etcd (специфичный для каждой задачи) * если не получается, то забивает * если получается, выполняет задачу

я слышал что некоторые ещё запускают Джобы по расписанию с помощью гитлаба. Вариант?

хотя... нода с гитлабом помрет и приехали

РИТ++ 2019 (https://ritfest.ru/) – Профессиональный фестиваль для тех, кто делает Интернет. 27 и 28 мая 2019г. в Кампусе СКОЛКОВО, Москва, пройдет отраслевая выставка и целый ряд профессиональных узкотематических конференций: системное администрирование и эксплуатация, высоконагруженные системы и базы данных, серверное программирование, управление проектами и предпринимательство, качественная разработка IT-продуктов, а также фронтенд-разработка. Мы решили расширить аудиторию фестиваля "Российские интернет-технологии" и предлагаем две новые возможности для участия: + Если вы студент, аспирант или преподаватель ВУЗа, то вы можете воспользоваться скидкой в 75% от стоимости билета - используйте скидочный код Academic{devops40} при заказе билетов на сайте конференции. Имейте в виду, что при регистрации мы попросим вас показать любой документ, удостоверяющий ваш статус." + Если вы частное лицо и нет компании, которая компенсировала бы вам билет, то вы можете воспользоваться скидкой в 50% - используйте скидочный код Personal{devops40}. В обоих случаях оплата возможна только как оплата от частного лица через Яндекс.Кассу и вы можете заказать билет только для себя. Впрочем вы можете передать скидочный код вашему сокурснику или другу и он может сделать то же самое. Надеемся, что вам у нас понравится 😊

Были ли у кого подводные камни с использованием logstash в отдельном ECS-сервисе на AWS? Кратко обрисую ситуацию: CloudWatch, собака, дорогой, да ещё и троттлит иногда. ELK на хетцнере(или даже Elastic Cloud) куда дешевле. Хотим отправлять логи туда, но прежде хотелось бы узнать, есть ли вдруг у кого какие best practices. Спасибо!

за трафик до хецнера не дороже будет?

Возможно, выйдет то на то, но в приоритете сейчас Elastic Cloud, начальство хочет SQL-интерфейс и машин лёнин для дата-сатанистов.

Привет, подскажите, правльно ли я хочу деплоить проект на докере: Создам контейнер, который будет вебпаком собирать фронт на vue, контейнер для nginx, который будет сервить свежесобранный фронт и проксировать запросы на бекенд сервисы, ну и контейнеры бекенд сервисов?

На первый взгляд всё правильно

Спасибо. А как правльно настроить volume, чтобы между двумя контейнерами бандл шарить? Просто на хост машине директорию в /tmp создать и маунтить её в контейнер со сборкой фронта и в контейнер nginx? Правильно понимаю, что если файлы фронта поменяются, после пересборки, то запущенный nginx будет отдавать новый бандл? Извините за глупые вопросы.

А почему не положить статику внутрь контейнера и пересобирать контейнер при каждом деплое?

А если при пересборке зайдёт клиент, а там даже заглушки (или старой версии) нет?

Вы контейнер с оркестратором используете или без? Если у вас Kubernetes - можно настроить canary deployment.

Я даже не знаю что такое оркестратор, извините, я простой кодерок. А с кубом никогда не работал.

Оркестратор это Kubernetes или Docker Swarm. Использовать без них Docker можно, но почти бессмысленно

Я слышал про swarm, но это нужно, насколько я знаю, для сервисов с распределением сервисов по машинам, для масштабируемости. А у меня малая нагрузка ожидается, я привык делать всё через docker-compose.