Больше возможностей для совместной работы и дополнительные уведомления

Мы в GitLab постоянно ищем новые способы улучшить совместную работу по всему жизненному циклу DevOps. Мы с радостью объявляем, что с этого выпуска поддерживаем несколько ответственных лиц для одного мердж-реквеста! Эта функция доступна с уровня GitLab Starter и по-настоящему воплощает наш девиз: «Каждый может внести свой вклад». Мы знаем, что с одним мердж-реквестом может работать много людей, чтобы все точно было в порядке, и теперь у вас есть возможность назначать несколько ответственных за мердж-реквесты!

А еще команды DevOps теперь получают автоматические уведомления о событиях деплоя в Slack и Mattermost. Добавьте новые уведомления в список событий отправки в этих двух чатах, и ваша команда будет почти моментально узнавать о новых деплоях.

Сокращение издержек с поддержкой контейнеров Docker в Windows и подготовкой кластеров Kubernetes на уровне экземпляра

Введение

Мы в Shopify занялись развертыванием Istio в качестве service mesh. В принципе все устраивает, кроме одной вещи: это дорого.

В опубликованных бенчмарках для Istio говорится:

С Istio 1.1 прокси потребляет примерно 0,6 vCPU (виртуальных ядер) на 1000 запросов в секунду.

Для первого региона в service mesh (по 2 прокси с каждой стороны соединения) у нас будет 1200 ядер только для прокси, из расчета один миллион запросов в секунду. Согласно калькулятору стоимости от Google получается примерно $40/месяц/ядро для конфигурации n1-standard-64, то есть один этот регион будет стоить нам больше 50 тыс. долларов в месяц за 1 млн запросов в секунду.

Айвен Сим (Ivan Sim) наглядно сравнил задержки service mesh в прошлом году и обещал то же самое для памяти и процессора, но не получилось:

Судя по всему, values-istio-test.yaml серьезно увеличит запросы к процессору. Если я все правильно посчитал, нужно примерно 24 процессорных ядра для панели управления и 0,5 ЦП для каждого прокси. У меня столько нету. Я повторю тесты, когда мне выделят больше ресурсов.

Я хотел сам убедиться, насколько показатели Istio схожи с другой service mesh с открытым кодом: Linkerd.

Данной статьей продолжается


Как мы уже писали в первой статье, есть весьма большое число программ резервного копирования, основанных на rsync.

Из тех, что больше всего подходят под наши условия, я буду рассматривать 3: rdiff-backup, rsnapshot и burp.

В комментариях к моей статье Docker: вредные советы было много просьб объяснить, чем так ужасен описанный в ней Dockerfile.

Краткое содержание предыдущей серии: два разработчика в жестком дедлайне составляют Dockerfile. В процессе к ним заходит Ops Игорь Иванович. Итоговый Dockerfile плох настолько, что ИИ оказывается на грани инфаркта.

Сейчас разберемся, что не так с этим Dockerfile.

Итак, прошла неделя.

Создание первой цепочки DevOps за пять шагов для новичков.

DevOps стал панацеей для слишком медленных, разобщенных и прочих проблемных процессов разработки. Но нужны минимальные познания в DevOps. Здесь будет рассмотрены такие понятия, как цепочка DevOps и как создать ее за пять шагов. Это не полное руководство, а только “рыба”, которую можно расширять. Начнем с истории.

Мое знакомство с DevOps

Когда-то я работал с облаками в Citi Group и разрабатывал веб-приложение IaaS, чтобы управлять облачной инфраструктурой Citi, но мне всегда было интересно, как можно оптимизировать цепочку разработки и улучшить культуру среди разработчиков. Грег Лавендер, наш техдиректор по облачной архитектуре и инфраструктуре, посоветовал мне книгу Проект «Феникс». Она прекрасно объясняет принципы DevOps, при этом читается, как роман.

Через 2 недели стартуют интенсивы по Kubernetes: Слёрм-4 для тех, кто знакомится с k8s и МегаСлёрм для инженеров и архитекторов k8s.

На Слёрм-4 остались последние 10 мест в зале. Желающих освоить k8s на базовом уровне хватает.

Для Ops, который знакомится с Kubernetes, запустить кластер и задеплоить приложение – уже неплохой результат. У Dev запросы и того меньше: понять, как оптимизировать приложение под работу в кластере.

У инженеров и архитекторов задачи другого уровня:

• можно ли запустить базу данных в k8s, нужно ли это делать, что мы выигрываем и проигрываем от такой архитектуры;
• какие подходы к деплою очевидно не подходят для k8s;
• какие угрозы безопасности несет k8s (например, разработчик легко может получить админский доступ) и как их предотвратить;
• какие схемы автоматизации инфраструктуры допускает k8s и как научиться их находить и использовать.

Если вы уже дошли до такого уровня, на МегаСлёрме вас ждет много интересного.

Короткая история о fio и etcd

Производительность кластера etcd во многом зависит от производительности его хранилища. etcd экспортирует некоторые метрики в Prometheus, чтобы предоставить нужные сведения о производительности хранилища. Например, метрику wal_fsync_duration_seconds. В документации к etcd сказано: чтобы хранилище считалось достаточно быстрым, 99-й процентиль этой метрики должен быть меньше 10 мс. Если вы планируете запустить кластер etcd на машинах Linux и хотите оценить, достаточно ли быстрое у вас хранилище (например, SSD), можно использовать fio — популярный инструмент для тестирования операций ввода-вывода. Запустите следующую команду, где test-data — это каталог под точкой подключения хранилища:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Нужно просто посмотреть результаты и проверить, что 99-й процентиль длительности fdatasync меньше 10 мс. Если да, у вас достаточно быстрое хранилище. Вот пример результатов:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

GitLab 11.10 с пайплайнами на панели управления, пайплайнами для объединенных результатов и предложениями по нескольким строкам в мердж-реквестах.

Удобные сведения о работоспособности пайплайнов в разных проектах

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

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

Я на digital рынке с 2008 года, и за это время видел переход от веб-сайтов на Joomla (помните такую? ) до сегодняшнего Интернета с его mobile-first приложениями и сотнями миллионов IoT устройств, подключенных в сеть.
Атаки в Интернете также за это время неплохо развилиcь :)
Но рынок защиты от DDoS и используемые операторами технологии защиты от атак остаются все еще достаточно сильно закрытым.
Расскажу, что узнал про него, поддерживая веб-сайты и интернет-сервисы, находящиеся под непрерывными атаками несколько последних лет.


Регулярные атаки. 350k req total, 52k req legitimate

Когда я учился водить машину, на первом же занятии инструктор выехал на перекресток задним ходом, а потом сказал, что делать так нельзя — вообще никогда. Это правило я запомнил сразу и на всю жизнь.

Читаешь детям «Вредные советы» Григория Остера, и видишь, как легко и непринужденно до них доходит, что так делать нельзя.

О том, как правильно писать Dockerfile, написана куча статей. Но мне не попадалось инструкций, как писать неправильные Dockerfile. Восполняю этот пробел. И, может быть, в проектах, которые я получаю на поддержку, таких докерфайлов станет меньше.

Зачем же нужно делать резервные копии? Ведь оборудование весьма и весьма надежное, к тому же есть «облака», которые по надежности лучше физических серверов: при правильной настройке «облачный» сервер запросто переживет отказ инфраструктурного физического сервера, а с точки зрения пользователей сервисов, будет небольшой, еле заметный скачок времени обслуживания. К тому же дублирование информации зачастую требует оплатить «лишнее» процессорное время, дисковую нагрузку, трафик сети.

27-29 мая мы проводим четвертый Слёрм: интенсив по Kubernetes.

Бонус: онлайн-курсы по Docker, Ansible, Ceph

Мы вывели из Слёрма темы, которые важны для работы с Kubernetes, но напрямую к k8s не относятся. Как, почему и что получилось — под катом.
Все участники Слёрма-4 получат доступ к этим курсам.

Полный манибек в первый день

На питерском Слёрме два участника оставили крайне негативные отзывы. Как я жалел, что нельзя вернуться в прошлое и расстаться с ними без взаимных претензий.

Если вы поймете, что на Слёрме категорически не нравится, в первый день напишите любому из организаторов. Мы отключим доступы и вернем полную цену участия.

Консультации техдира

Если кто знает Дмитрия Симонова (он собрал клуб техдиректоров), мы пригласили его на Слёрм (учиться, а не выступать). Он обещал консультировать всех желающих. Вряд ли это будет интересно администраторам и разработчикам, а вот управленцам от IT — очень даже.

KlusterKit: набор инструментов с открытым исходным кодом для упрощения деплоев Kubernetes и работы в физически изолированных локальных средах

Сегодня мы с радостью объявляем, что Platform9 открывает исходные коды Klusterkit, набора из трех инструментов, по лицензии Apache v2.0 на GitHub.

Наши клиенты выкатывают ПО в частных дата-центрах, которые часто не подключены к интернету (по соображениям безопасности или по другим причинам). Эти крупные компании хотят использовать преимущества Kubernetes и модернизировать свои приложения и при этом выкатывать их в разных дата-центрах, у которых нередко нет связи с внешним миром. И тут на помощь приходит Klusterkit, который упрощает поставку и управление кластерами K8s в физически изолированных средах.

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

1. etcdadm, CLI для упрощенного управления кластером etcd.
2. nodeadm, CLI для администрирования нод, который дополняет kubeadm и развертывает зависимости, нужные kubeadm.
3. cctl, инструмент управления жизненным циклом кластера, который принимает Cluster API из сообщества Kubernetes и использует nodeadm и etcdadm, чтобы без лишних хлопот поставлять и поддерживать высокодоступные кластеры Kubernetes в локальных и в том числе физически изолированных средах.

Вместе эти три инструмента выполняют следующие задачи:

Это обновление моего предыдущего бенчмарка, который теперь работает на Kubernetes 1.14 с актуальной версией CNI на апрель 2019 года.

Во-первых, хочу поблагодарить команду Cilium: ребята помогли мне проверить и исправить скрипты мониторинга метрик.

Что изменилось с ноября 2018

Вот что изменилось с тех пор (если интересно):

Flannel остается самым быстрым и простым интерфейсом CNI, но все еще не поддерживает сетевые политики и шифрование.

Romana больше не поддерживается, так что мы удалили ее из бенчмарка.

WeaveNet теперь поддерживает сетевые политики для Ingress и Egress! Но производительность снизилась.

В Calico все еще нужно вручную настраивать максимальный размер пакета (MTU) для лучшей производительности. Calico предлагает два варианта установки CNI, так что можно обойтись без отдельного хранилища ETCD:

Дзииииииинь! На часах 3 утра, вы смотрите чудесный сон, и вдруг — звонок. На этой неделе вы дежурите, и, видимо, что-то случилось. Автоматизированная система зовет разобраться, в чем дело. Это важный момент управления современными компьютерными системами, но давайте посмотрим, как сделать уведомления удобнее для людей.

Знакомьтесь с философией мониторинга, родившейся за несколько десятилетий моих дежурств в разных командах по мониторингу. На нее во многом повлияла настоящая библия от Роба Еващука My Philosophy on Alerting (Моя философия уведомлений), включенная в книгу по Google SRE, и книга Джона Олспо Considerations for Alert Design (Замечания по настройке оповещений).

Келли Данн, Ариджит Мукхерьи и Максим Петаццони — спасибо за помощь в редактировании поста.

Что такое CASE?

Я решил придумать красивую аббревиатуру, как у метода USE Брендана Грегга или метода RED Тома Уилки. Я зову это метод CASE. Он описывает четыре момента, на которые нужно обратить внимание при работе с автоматическим мониторингом:

Наш гость, создатель инструментов для разработчиков из Pantheon, рассказывает, как автоматизировать деплои WordPress с помощью GitLab CI/CD.

В Pantheon я занимаюсь связями с разработчиками, поэтому всегда ищу новые способы помочь разработчикам WordPress и Drupal решать проблемы с автоматизацией в рабочих процессах. Для этого я люблю экспериментировать с новыми инструментами и сочетать их друг с другом для эффективной работы.

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

Так себе удовольствие — ждать своей очереди использовать сервер или отправлять клиентам URL с пометкой: «Вот здесь смотреть, а здесь пока не смотреть».

Среды multidev — один из крутых инструментов Pantheon — решают эту проблему, ведь с ними можно по запросу создавать среды под ветки Git. У каждой среды multidev свой URL и база данных, поэтому разработчики спокойно работают, проверяют качество и получают одобрение, не наступая друг другу на пятки.

Но в Pantheon нет инструментов для контроля версий или непрерывной интеграции и деплоя (CI/CD). Зато это гибкая платформа, с которой можно интегрировать любые инструменты.

Еще я заметил, что для разработки команды используют одни инструменты, а для сборки и деплоя — другие.

Например, у них разные инструменты для контроля версий и CI/CD. Приходится возиться и переключаться между инструментами, чтобы редактировать код и диагностировать проблемы.

Я создал Kube Eagle — экспортер Prometheus. Оказалось, крутая штука, которая помогает лучше разбираться в ресурсах маленьких и средних кластеров. В итоге я сэкономил не одну сотню долларов, потому что подбирал правильные типы машин и настраивал ограничения ресурсов приложений под рабочие нагрузки.

Я расскажу о преимуществах Kube Eagle, но сначала объясню, из-за чего вышел сыр-бор и для чего понадобился качественный мониторинг.

В современных ЦП очень много ядер. Годами приложения посылали запросы в базы данных параллельно. Если это отчетный запрос ко множеству строк в таблице, он выполняется быстрее, когда задействует несколько ЦП, и в PostgreSQL это возможно, начиная с версии 9.6.

Понадобилось 3 года, чтобы реализовать функцию параллельных запросов — пришлось переписать код на разных этапах выполнения запросов. В PostgreSQL 9.6 появилась инфраструктура для дальнейшего улучшения кода. В последующих версиях и другие типы запросов выполняются параллельно.

Быстрое обнаружение утечки секретов

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

В этом релизе мы представляем опцию обнаружения секретов в рамках нашего функционала SAST. Каждый коммит сканируется в задании CI/CD на наличие секретов. Есть секрет — и разработчик получает предупреждение в мердж-реквесте. Он на месте аннулирует утекшие учетные данные и создает новые.

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

Специалисты по инфраструктуре на GitLab отвечают за работу GitLab.com — самого большого экземпляра GitLab в природе. Здесь 3 миллиона пользователей и почти 7 миллионов проектов, и это один из самых крупных опенсорс-сайтов SaaS с выделенной архитектурой. Без системы баз данных PostgreSQL инфраструктура GitLab.com далеко не уедет, и что мы только не делаем для отказоустойчивости на случаи любых сбоев, когда можно потерять данные. Вряд ли такая катастрофа случится, но мы хорошо подготовились и запаслись разными механизмами бэкапа и репликации.

Репликация — это вам не средство бэкапа баз данных (см. ниже). Но сейчас мы увидим, как быстро восстановить случайно удаленные данные с помощью отложенной репликации: на GitLab.com пользователь удалил ярлык для проекта gitlab-ce и потерял связи с мерж-реквестами и задачами.

С отложенной репликой мы восстановили данные всего за 1,5 часа. Смотрите, как это было.