Теперь будет - обсуждаем Docker, Kubernetes, методы для CI/CD, пишем пайплайны тестирования и билдов, выбираем очередного убийцу Докера, пытаемся понять почему наш sh скрипт нихуя не работает и почему в Jenkins вылетают одни ошибки.
>>1902332 > Нахуй перекат? Там 37 постов всего. Так там и не девопс тред, а вопрос какого-то ньюфага, я его приложил просто шоб было
>>1902326 У тебя пол доски анимублядями аватаркоебами забит. ДевОпс - это не админство, это кодоебство и работа твоего ПО в контейнерах/серверах. Я не знаю лучшего места, чем эта доска. Эта тема вообще ко всему относится, но больше к программистам.
Хотел уже было создать свой отдельный тред, но нашёлся этот. Итак. Вот, например, где-то на серваках стартует несколько экземпляров одного нодовского приложения, обращающихся к одной и той же бд. Если все экземпляры попытаются создавать/добавлять новые поля в таблицы в бд, ничё хорошего из этого не получится. Значит, таблицы нужно создавать заранее скриптом. Так? А если нужно обновить приложение и бд, то, получается, нужно гасить все экземпляры, обновлять бд, обновлять приложение и перезапускать его эксемпляры. А если нужно, чтобы приложение работало постоянно? Получается, нужно как-то создавать новую бд с обновлёнными таблицами на основе данных из старых таблиц и в реальном времени копировать туда все новые данные из старой бд, которая пока ещё взаимодействует со старыми экземплярами приложения. Потом запускать экземпляры нового приложения и в один момент как-то переключать пользователей на эти новые экземпляры. Или как? Как всё это делать правильно, без гемора и по фэншую? Что почитать на эту тему?
>>1905490 Ололош, для этого существует такое понятие, как отказоустойчивые БД: кластеризация, репликация, зеркалирование. Выбирай любое в зависимости от движка БД и не еби мозг тупыми вопросами. А лучше вообще не лезь, это не твое раз ты элементарных вещей не втыкаешь. Пиздуй лучше в эникей ебашить
>>1902319 (OP) Посоветуйте что нужно изучать для вката, есть знания linux на базовом уровне, понимание о работе OC и компьютерных сетей, и небольшой опыт программирования на c#,python,php
>>1905490 > где-то на серваках стартует несколько экземпляров одного нодовского приложения, обращающихся к одной и той же бд В SQL базах есть такое понятие, как гарантия атомарности. Если ты пошлешь одновременно 2 запроса на запись - ты не сломаешь базу, они просто выполнятся последовательно.
> ничё хорошего из этого не получится Почему? Запросы не приведут к конфликтам и ошибкам, если ты об этом.
> А если нужно обновить приложение и бд, то, получается, нужно гасить все экземпляры Нет, почему? Практики разные бывают, но в общем случае - добавляется реплика сервиса, накатывает миграции, а затем постепенно деплоятся остальные реплики, заменяя старые. Естественно это все нужно самому настраивать либо использовать готовые решения. Миграции в scalable приложениях - это целая отдельная тема
> А если нужно, чтобы приложение работало постоянно? Получается, нужно как-то создавать новую бд с обновлёнными таблицами на основе данных из старых таблиц и в реальном времени копировать туда все новые данные из старой бд, которая пока ещё взаимодействует со старыми экземплярами приложения. Нет, лол. Просто миграции специально делают не ломающими предыдущую схему. Например тебе нужно поменять у поля тип, вместо того, чтобы тупо удалить нахуй колонку и заменить новой - ты делаешь это в 2 этапа. Первая миграция - добавление новой колонки, вторая миграция - удаление старой и переименование новой. Второй этап происходит после того, как поды (реплики) старого приложения были полностью заменены на новые. Это очень кратко и базово, существуют различные техники. Но да, как в монолите с одним инстансом уже не получится просто хуякнуть миграцию и забыть. Вообще при микросервисной/растущим в ширь скейлингом приходит и много новых проблем, таких как shared state, лоадбалансинг и т.д. и т.п.
> Потом запускать экземпляры нового приложения и в один момент как-то переключать пользователей на эти новые экземпляры. Или как? Объясню на пальцах: у тебя есть один инстанс (пусть будет процесс, грубо говоря приложение одно), ты туда направляешь все запросы (не важно, пусть будет nginx). Теперь ты задумался, что хорошо бы два инстанса сделать, чтобы на каждый из них меньше нагрузка была, соответственно увеличив пропускную способность твоего сайтика (пусть будет просто сайт пока). Тебе нужно какое-то подобие лоадбалансера, т.е. балансировщика нагрузки, который будет запросы от юзера направлять на каждое приложение равномерно, самый простейший - это прописать в NS записях твоего домена разные айпишники/порты твоих двух сервисов, правда тут уже не лоадбалансер, а тупо рандом, более сложные штуки - это умные лоадбалансеры, которые направляют запросы на менее нагруженные инстансы. Не буду вдаваться в подробности. Короче в итоге у тебя все запросы не напрямую в твой инстанс шлются, а в некий gateway лоад балансер, а он уже полностью копирует их и передает на конкретный из двух инстансов, а затем ответ от них также отдает обратно. Естественно писать логику лоадбалансера и спавнить инстансы приложения руками - это слишком долго и муторно. Для этого придумали кучу инструментов, например в том-же кубернетесе есть external service с функциями лоадбалансера, или тот-же traefik, да дохуя их. Кубернетес еще и автоматически умеет спавнить реплики под нужную нагрузку, умеет их убивать и ты можешь прописать различные правила для всего этого. Это и есть девопс.
> Как всё это делать правильно, без гемора и по фэншую? Можешь начать с гайда по кубернетесу, из него уже по мере надобности изучать ответвления. Кубер удобен тем, что там все есть из коробки. Но, естественно, в проде одним кубером все не ограничивается, для каждой темы есть отдельные более продвинутые инструменты.
Заебался дрючится с серверами своих проектов (я сам у себя выполняю роль около-СТО) - сейчас у меня зоопарк из 6 железных серваков на hetzner.
Заебало настраивать и устанавливать каждый раз один и тот же софт, следить чтобы ничего не упало и перезапускать если это случилось. Стек у меня в целом обычный:
nginx php-fpm mysql (percona) redis sphinx
иногда что-то дополнительное вроде rabbitMQ или CouchBase.
Фишка в том, что я люблю потюнить настройки - в том числе серверные а-ля swapiness и ulimit, иногда меняю настройки софта и делаю бенчмарки.
Есть ли что-то, что позволит мне не логинится каждый раз на сервер, а просто править конфиг, делать деплой и чтобы "и нее там внутре неонка" - в смысле как-то автоматизировать эту рутину.
Посоветуйте что-нибудь, пожалуйста. Платное\бесплатное - не так важно.
Terraform, docker, ansible? Я в целом не очень сейчас в курсе, что происходит в devops - но могу быстро освоить\или оплатить услуги специалиста по первоначальной настройке.
>>1919313 Да я уже, лол. Хотя насчёт простецкой я бы поспорил. Как пошли всякие доработки - так оно начало жиреть как пиздец, уже до тысячи строк отъелось и хз остановится ли. Я потому и спрашиваю, что не хочу свой велосипед писать.
>>1919192 Ансибл - Помнить что ансибл это не shell и использовать модули,от шелл портянок надо отвыкать(хотя понимать что там написано стоит) - Использовать шаблоны jinja templates, без regexp и sed костыликов в конфигах - Использовать папки конфигураций приложения *.d(conf.d,sysctl.d) и не лезть в дефолт конфиги
Учить: 1. ADV-IT на ютубе, просто обьясняет, для вката самое то, 5 часов плей лист(полезно читать коменты под видео) можно после этого погляжеть это https://www.youtube.com/watch?v=4QSyR0PcIR0
2.примерное понятие как стоить плейбуки, чел много говорит, но послушать стоит