DevOps *

Удивительно, на на хабре до сих пор нет поста о такой, весьма интересной, замене шеллу как xonsh (github), с моей точки зрения синтаксис всяких shell'ов ужасен и не вижу никаких оснований сохранять его в 21 веке, а Python, в свою очередь, обладает прекрасным синтаксисом и массой других преимуществ, поэтому, на мой взгляд, он и должен быть языком автоматизации по умолчанию, чего и пытаеся достичь xonsh.

Какое-то время использую xonsh, поэтому думаю, что могу рассказать о нём достаточно для того, чтобы начать пользоваться.

В последнем посте я рассказывал о Kubernetes, о том, как ThoughtSpot использует его для собственных нужд по поддержке разработки. Сегодня хотелось бы продолжить разговор о короткой, но от того не менее интересной истории отладки, которая произошла совсем недавно. Статья базируется на том, что containerization != virtualization. К тому же наглядно показывается, как контейнеризированные процессы конкурируют за ресурсы даже при оптимальных ограничениях по cgroup и высокой производительности машины.

Helm без хайпа. Трезвый взгляд

Helm — это менеджер пакетов для Kubernetes.

На первый взгляд, неплохо. Этот инструмент значительно упрощает процесс релиза, но порой может и хлопот доставить, ничего не попишешь!

В августе Southbridge провели интенсив по Кубернетес Слёрм-1.
В октябре мы его повторили (Слёрм-2) и добавили продвинутый курс (МегаСлёрм).

Удовольствие не из дешевых: Слёрм-2 стоил 35 000 ₽, МегаСлёрм — 75 000 ₽ (онлайн 15 и 35). Я общался с заказчиками, участниками и спикерами, проводил опросы и собирал статистику.

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

1. Слёрм помогает определиться по Кубернетес

Оказалось, понимание «нам подходит Кубернетес» ценнее, чем «мы можем в Кубернетес».

Руководители, отправляя своих инженеров (разработчиков, администраторов) на Слёрм, декларировали: «Пусть пощупает технологию и решит, подходит ли она для наших задач».

Участники Слёрма-1 рассказывали: «После интенсива мы внедрили Кубернетес, теперь я приехал на МегаСлёрм».

3 дня интенсива — в самый раз, чтобы увидеть технологию в полный рост, а не в режиме «Рабинович по мануалам установил». Тут даже вопросов нет, оно того стоит.

Часто в рамках проверки Pull Request, помимо, собственно, code review, возникает необходимость проделывать набор рутинных проверок. Некоторые проверки могут касаться оформления PR. Другие — проверять смежные условия, которые составляют основу процесса принятия изменений.
Если рутинные проверки не автоматизированы, человек может начать их забывать или обходить. Потому, что рутина — это скучно.

Visual Studio Team Services предлагает довольно удобную инфраструктуру для обработки Pull Request. Сюда входят настраиваемые политики merge builds, назначение ревьюеров, правила слияния принимаемых изменений. Все это дополненной удобной системой обсуждения и комментирования кода.

Мощнейшим инструментом расширения процесса Pull Request являются внешние подключаемые политики.

Об их создании и использовании и поговорим (и посмотрим код)

Для того чтобы быстро поднять рабочее окружение существует много способов. Один из них — поднять все необходимые сервисы в Docker-контейнерах. Чтобы ускорить создание новых проектов на Yii-framework я написал такую небольшую инструкцию, которую используют разработчики в нашей команде.

• Как методы и процессы разработки отражаются на эксплуатации?
• Что движет каждой стороной конфликта?
• В чем первопричина разногласий?

Эта статья является свободной интерпретацей официального руководства Creating Highly Available Clusters with kubeadm для Stacked control plane nodes. Мне не нравятся сложный язык и примеры использованные в нем, поэтому я написал свое руководство.

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

Вчера стартовал Слёрм-2, интенсив по Кубернетес. Первое выступление: Павел Селиванов рассказывает, как участники Слёрма будут осваивать Кубернетес, а потом читает лекцию по Docker. В чате жаловались, что "Докер за час — это далеко за гранью", на что Павел ответил: "Наша задача — не изучить Докер, а согласовать точки зрения на Докер, чтобы в дальнейшей работе не было разночтений".

С радостью сообщаем о выпуске GitLab 11.4 с невероятными обновлениями, призванными помочь командам разработчиков работать вместе более эффективно. Большинство команд разработчиков, внедряющих концепцию DevOps, стремится сократить продолжительности рабочего цикла. Поэтому приветствуются такие улучшения, которые сокращают потери времени и лишнюю работу и тем самым позволяют ускорить поставку приложений и добиться лучших результатов в бизнесе.