Вы написали стандартные buzzwords которые любому сервису неплохо бы иметь.
Конкретно в случае гитлаба:
Обновление без простоя требуется очень редко. Для SaaS - да, для селф-хостед - ну такое. Пушить в гитлаб в процессе обновления версии - не для слабонервных.
При серьезном сбое одной ноды кубер Вас никак не спасет.
Мониторинг и логи в гитлабе идут из коробки, если что. Хотите - используете встроенное, хотите - забираете метрики внешним сервисом с готового эндпоинта.
Про скейл желание понятно, но даже в доке гитлаба указано, что до 2000 юзеров легко умещаются в одну ноду. Воркеров надо выносить, конечно.
Ну то есть я намекаю на то, что профит с развертывания k3s достаточно небольшой. А вот дополнительную точку отказа (и сложность переконфигурации) Вы подкидываете. Зачем?..
Статья, конечно, забавная, прям начиная с фразы "по историческим причинам".
Ох, сколько ада в этом мире оправдано этими словами. Приходишь в новую компанию, видишь полную хрень, спрашиваешь: почему так? По историческим причинам!
Потом растешь до большого начальника, творишь полную хрень в интересах бизнеса (сейчас быстренько накостыляем, а потом сделаем норм). Выводишь на работу новых сотрудников, а они спрашивают, почему так. По историческим причинам, вот почему! ))
---
Детально не читал, но версия гитлаба из статьи и скрипт ротации бекапов явно устарели. Не совсем уверен, зачем он такой, но современные гитлабы как бы самостоятельно умеют ротировать свои бекапы, и даже самостоятельно заливают их на любое внешнее хранилище (например, s3)
Короче, как руководство к действию я бы не стал принимать. Есть способы намного проще.
Гитлаб - это же не только кодики, которые под vcs, это и юзеры-логины-пароли-ключи, это переменные для CI, раннеры и дофига чего еще.
Далее, было бы ошибкой предполагать, что при падении gitlab как некоего общего source of truth вы запросто сможете восстановиться без потерь. Напомню, что у Вас и тысяч Ваших коллег есть данные (кстати, потенциально неактуальные) только по тем репам, которые вы пуллили давеча. По остальным репам информации у вас нет.
При этом кто-то из нескольких тысяч Ваших коллег мог запросто запушить последние изменения и грохнуть локальную репку, а еще некоторые могли внести изменения прямо через webide гитлаба.
И даже если (теоретически) можно в итоге поскрести по сусекам и собрать хоть какое-то общее хранилище кода - времени это займет столько, что Вы триста тысяч раз пожалеете, что не бекапили гитлаб.
Децентрализация гита - она только в головах. На практике дело обстоит намного хуже.
А почему CTO занимается проведением технических интервью? Разве это не задача тимлидов?
Pickle - только установщик, а они, я так понимаю, хотят именно репозиторий pecl переделать.
Ну, знаете как на фотках закрывают лица детей смайликами, чтобы их душу не украли?
Вот гугл и планирует научиться красть души с таких фото.
А расскажите плз что там под капотом.
Confluence тоже не встречается.
Вот же
"Уважаемый Имя Фамилия, пройдите по ссылке для сброса пароля"
Имя + Фамилия + email - очень даже ПД
Нуууу, вопрос терминологии.
Для создателей OCI-совместимых образов не изменилось чуть менее чем ничего. Как писали докерфайлы, так и будут писать.
А исчезновение докершима и замена containerd на cri-o для рядового потребителя не особо видна, вроде.
Вот бы еще сравнение бюджетов на инфру увидеть!
https://microservices.io/index.html
https://github.com/donnemartin/system-design-primer
Ну спасибо нафиг. А то ярославка слишком быстро едет, видимо.
Из статьи по ссылке:
Ну офигеть теперь. Человек высказал свои мысли, ему в ответ высказали свои. Вроде все норм, не?
Вы написали стандартные buzzwords которые любому сервису неплохо бы иметь.
Конкретно в случае гитлаба:
Обновление без простоя требуется очень редко. Для SaaS - да, для селф-хостед - ну такое. Пушить в гитлаб в процессе обновления версии - не для слабонервных.
При серьезном сбое одной ноды кубер Вас никак не спасет.
Мониторинг и логи в гитлабе идут из коробки, если что. Хотите - используете встроенное, хотите - забираете метрики внешним сервисом с готового эндпоинта.
Про скейл желание понятно, но даже в доке гитлаба указано, что до 2000 юзеров легко умещаются в одну ноду. Воркеров надо выносить, конечно.
Ну то есть я намекаю на то, что профит с развертывания k3s достаточно небольшой. А вот дополнительную точку отказа (и сложность переконфигурации) Вы подкидываете. Зачем?..
Любопытно.
А какие задачи и проблемы гитлаба в данном случае будет решать кубер, тем более однонодовый?
Настоятельно рекомендую:
отключить регистрацию
включить обязаловку 2fa (галка в админке)
закрыть инстанс вайтлистом (у гитлаба апишка наружу торчит, и не все методы оттуда Вы хотите экспозить)
У меня такое чувство, что Вы меня с автором поста перепутали.
Статья, конечно, забавная, прям начиная с фразы "по историческим причинам".
Ох, сколько ада в этом мире оправдано этими словами. Приходишь в новую компанию, видишь полную хрень, спрашиваешь: почему так? По историческим причинам!
Потом растешь до большого начальника, творишь полную хрень в интересах бизнеса (сейчас быстренько накостыляем, а потом сделаем норм). Выводишь на работу новых сотрудников, а они спрашивают, почему так. По историческим причинам, вот почему! ))
---
Детально не читал, но версия гитлаба из статьи и скрипт ротации бекапов явно устарели. Не совсем уверен, зачем он такой, но современные гитлабы как бы самостоятельно умеют ротировать свои бекапы, и даже самостоятельно заливают их на любое внешнее хранилище (например, s3)
Короче, как руководство к действию я бы не стал принимать. Есть способы намного проще.
Ну, для начала, бекап не гита, а гитлаба.
Гитлаб - это же не только кодики, которые под vcs, это и юзеры-логины-пароли-ключи, это переменные для CI, раннеры и дофига чего еще.
Далее, было бы ошибкой предполагать, что при падении gitlab как некоего общего source of truth вы запросто сможете восстановиться без потерь. Напомню, что у Вас и тысяч Ваших коллег есть данные (кстати, потенциально неактуальные) только по тем репам, которые вы пуллили давеча. По остальным репам информации у вас нет.
При этом кто-то из нескольких тысяч Ваших коллег мог запросто запушить последние изменения и грохнуть локальную репку, а еще некоторые могли внести изменения прямо через webide гитлаба.
И даже если (теоретически) можно в итоге поскрести по сусекам и собрать хоть какое-то общее хранилище кода - времени это займет столько, что Вы триста тысяч раз пожалеете, что не бекапили гитлаб.
Децентрализация гита - она только в головах. На практике дело обстоит намного хуже.
Мне кажется, в 2021 году лучше бы описать, чем эта IDE лучше уже существующих на рынке.
Но что такое «сушеный укроп»?..