Представитель нашего клиента, стек приложений которого обитает в облаке от Microsoft (Azure), обратился с проблемой: с недавнего времени часть запросов некоторых клиентов из Европы стала завершаться ошибкой 400 (Bad Request). Все приложения написаны на .NET, развёрнуты в Kubernetes…Читать полностью »
Это обновление моего предыдущего бенчмарка, который теперь работает на Kubernetes 1.14 с актуальной версией CNI на апрель 2019 года.
Во-первых, хочу поблагодарить команду Cilium: ребята помогли мне проверить и исправить скрипты мониторинга метрик.
Вот что изменилось с тех пор (если интересно):
Flannel остается самым быстрым и простым интерфейсом CNI, но все еще не поддерживает сетевые политики и шифрование.
Romana больше не поддерживается, так что мы удалили ее из бенчмарка.
WeaveNet теперь поддерживает сетевые политики для Ingress и Egress! Но производительность снизилась.
В Calico все еще нужно вручную настраивать максимальный размер пакета (MTU) для лучшей производительности. Calico предлагает два варианта установки CNI, так что можно обойтись без отдельного хранилища ETCD:
Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?
Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.
В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?
Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?
Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»
Так что изменилось? — Всё изменилось!
Читать полностью »
У нас было 2 анализатора кода, 4 инструмента для динамического тестирования, свои поделки и 250 скриптов. Не то, чтобы это всё было нужно в текущем процессе, но раз начал внедрять DevSecOps, то надо иди до конца.
Источник. Авторы персонажей: Джастин Ройланд и Дэн Хармон.
Что такое SecDevOps? А DevSecOps? В чем отличия? Application Security — о чём это? Почему классический подход больше не работает? На все эти вопросы знает ответ Юрий Шабалин из Swordfish Security. Юрий подробно на всё ответит и разберет проблемы перехода от классической модели Application Security к процессу DevSecOps: как правильно подойти к встраиванию процесса безопасной разработки в процесс DevOps и ничего не сломать при этом, как пройти основные этапы тестирования на безопасность, какие инструменты можно применять, чем они отличаются и как их правильно настроить, чтобы избежать подводных камней.
Читать полностью »
Дзииииииинь! На часах 3 утра, вы смотрите чудесный сон, и вдруг — звонок. На этой неделе вы дежурите, и, видимо, что-то случилось. Автоматизированная система зовет разобраться, в чем дело. Это важный момент управления современными компьютерными системами, но давайте посмотрим, как сделать уведомления удобнее для людей.
Знакомьтесь с философией мониторинга, родившейся за несколько десятилетий моих дежурств в разных командах по мониторингу. На нее во многом повлияла настоящая библия от Роба Еващука My Philosophy on Alerting (Моя философия уведомлений), включенная в книгу по Google SRE, и книга Джона Олспо Considerations for Alert Design (Замечания по настройке оповещений).
Келли Данн, Ариджит Мукхерьи и Максим Петаццони — спасибо за помощь в редактировании поста.
Я решил придумать красивую аббревиатуру, как у метода USE Брендана Грегга или метода RED Тома Уилки. Я зову это метод CASE. Он описывает четыре момента, на которые нужно обратить внимание при работе с автоматическим мониторингом:
Нас все чаще спрашивают про разработку микросервисов в Kubernetes. Разработчики, особенно интерпретируемых языков, хотят быстро поправить код в любимой IDE и без ожидания сборки/деплоя увидеть результат — по простому нажатию на F5. И когда речь шла про монолитное приложение, достаточно было локально поднять базу данных и веб-сервер (в Docker, VirtualBox…), после чего — сразу же наслаждаться разработкой. С распиливанием монолитов на микросервисы и приходом Kubernetes, с появлением зависимостей друг от друга, всё стало немного сложнее. Чем больше этих микросервисов, тем больше проблем. Чтобы вновь насладится разработкой, нужно поднять уже не один и не два Docker-контейнера, а иногда — даже не один десяток… В общем, на всё это может уходить достаточно много времени, поскольку требуется ещё и поддерживать в актуальном состоянии.Читать полностью »
Всем привет!
Ооочень хочется прям сразу приступить к теме, но правильнее будет немного рассказать про мою историю:
Я программист с опытом разработки frontend одностраничных приложений, scala/java и nodejs на сервере.
Довольно долго (уже точно пару — тройку лет), я придерживался мнения, что docker это манна небесная и вообще очень крутой инструмент и абсолютно каждый разработчик должен уметь пользоваться им. А отсюда вытекает, что и у каждого разработчика должен стоять docker на локальной машине. Да что там про моё мнение, вы полистайте вакансии, которые размещаются на том же hh. В каждой второй есть упоминание про docker и если вы им владеете — это будет вашим конкурентным преимуществом ;)
На своем пути я встечался с многими людьми, с их разным отношением к docker и к его экосистеме. Одни говорили, что это удобная вещь, гарантирующая кроссплатформенность. Вторые не понимали зачем им запускаться в контейнерах и какой профит от этого, третьим было вообще пофиг и они не парились (просто писали код и уходили домой — завидую, кстати, им :) )
Наш гость, создатель инструментов для разработчиков из Pantheon, рассказывает, как автоматизировать деплои WordPress с помощью GitLab CI/CD.
В Pantheon я занимаюсь связями с разработчиками, поэтому всегда ищу новые способы помочь разработчикам WordPress и Drupal решать проблемы с автоматизацией в рабочих процессах. Для этого я люблю экспериментировать с новыми инструментами и сочетать их друг с другом для эффективной работы.
Я часто вижу, как разработчики мучаются с одним промежуточным сервером.
Так себе удовольствие — ждать своей очереди использовать промежуточный сервер или отправлять клиентам URL с пометкой: «Вот здесь смотреть, а здесь пока не смотреть».
Среды multidev — один из крутых инструментов Pantheon — решают эту проблему, ведь с ними можно по запросу создавать среды под ветки Git. У каждой среды multidev свой URL и база данных, поэтому разработчики спокойно работают, проверяют качество и получают одобрение, не наступая друг другу на пятки.
Но в Pantheon нет инструментов для контроля версий или непрерывной интеграции и деплоя (CI/CD). Зато это гибкая платформа, с которой можно интегрировать любые инструменты.
Еще я заметил, что для разработки команды используют одни инструменты, а для сборки и деплоя — другие.
Например, у них разные инструменты для контроля версий и CI/CD. Приходится возиться и переключаться между инструментами, чтобы редактировать код и диагностировать проблемы.
Разбираемся, в чём суть методологии и кому она может принести пользу.
Также поговорим о DevOps-специалистах: их задачах, зарплатах и навыках.
Хотелось бы рассказать один интересный механизм работы с конфигурацией распределённой системы. Конфигурация представлена напрямую в компилируемом языке (Scala) с использованием безопасных типов. В этом посте разобран пример такой конфигурации и рассмотрены различные аспекты внедрения компилируемой конфигурации в общий процесс разработки.
(english)
