DevOps дайджест #8: GitLab включает поддержку Docker, как работает интернет, книги и немножко видео с конференций

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

В выпуске: хронология развития SSL/TLS, быстро поднимаем ipsec vpn сервер в Docker, 32 Best Reads on Lean, Agile and DevOps и опять про мониторинг и опыт в scaling.

Статьи и новости

Monitoring distributed systems.

«Blue. No! Yellow!» — забавная статья, в которой Uncle Bob пытается померять, например, на сколько % С++ программист продуктивнее С программиста. Выводы мне очень понравились.

Question for Web Developers who turned to DevOps. Парень расспрашивает DevOps выходцев из веб-разрботки о причине перехода и ощущениях в новой роли.

SSL/TLS and PKI Timeline. Хронология событий, повлиявших на SSL/TLS.

How the Internet works: Submarine fiber, brains in jars, and coaxial cables. Отличная статья о том, как работает интернет.

Scaleway открывает свой bare metal хостинг в публичный доступ. Очень интересное Cloud решение, на мой взгляд.

9 Lessons Learned Scaling Hotjar's Tech Architecture To Handle 21,875,000 Requests Per Hour. Советы по масштабированию веб-приложений на примере развития архитектуры Hotjar. Название сервиса слышу впервые, если честно.

Релизы, сервисы & интересный софт

Mattermost 3.0.

Vault, a tool for managing secrets.

Introducing Falco: open source, behavioral security from Sysdig. Новая security monitoring system от SysDig. В отличии от signature based систем, Falco является behavioral security monitoring системой. File integrity monitoring, Network monitoring а также интеграция с утилитами SELinux и AppArmor. В общем, интересное решение для мониторинга безопасности.

IPsec VPN Server on Docker.

GitLab Container Registry. Релиз версии 8.8 привнес интеграцию с Docker.

TOTP SSH port fluxing. Интересное решение для повышения безопасности коннекта по ssh. Аналогично 2 factor auth, каждые 30 секунд ssh демон меняет порт, активный порт можно смотреть в приложении на телефоне. Приложение чисто proof of concept.

Use atop for Linux server performance analysis, here’s why. Альтернатива top и htop со своими преимуществами.

Вышла версия 2.0 HTTP/2 сервера H2O.

Конференции

O'Reilly Security Conference — будет проходить 8-11 ноября 2016.

Записи с SREcon16 (Site Reliability Engineering).

Книги

The DevOps 2.0 Toolkit Automating the Continuous Deployment Pipeline with Containerized Microservices.

Microservices: from Design to Deployment. Free ebook from Nginx.

32 Best Reads on Lean, Agile and DevOps.

Юмор

Just returned from vacation; git pull:

← Предыдущий выпуск: DevOps дайджест #7
Следующий выпуск: DevOps дайджест #9 →

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Теми: DevOps, DevOps дайджест

Denis Zhdanov System engineer в eBay Classifieds Group 21.06.2016 17:06

Хорошую книжку забыли — www.artofmonitoring.com
Покупать (OMG!) лучше там же — так автору (twitter.com/kartar) больше всего денежка капает.

Відповісти

Підтримати

Oleksii Asiutin Director of Engineering в ThredUP 21.06.2016 17:17

Интересная, посмотрю, спасибо.

Denis Zhdanov

Юрій Ярош developer в bitsnap 21.06.2016 17:29

Riemann / ELK / graphite / grafana и еже с ним — не самые хорошие решения для логирования и мониторинга в рамках нагруженных проектов. Писать логи в СУБД с B-tree индексами и покрывать полнотекстовыми — довольно глупая затея, большинство не понимает что их перед этим ещё как-то нужно обрабатывать, а не складировать до несуразных размеров...

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

Oleksii Asiutin Director of Engineering в ThredUP 21.06.2016 17:34

А какие на Ваш взгляд реальные потребности пользователей? Какое решение используете как стандартное/нестандартное?

Юрій Ярош

Юрій Ярош developer в bitsnap 21.06.2016 17:51

Системы мониторинга должны быть автоматическими, а не автоматизированными — проблема в том что большинству пользователей нужно принимать решение на основе собранных данных, чаще всего on-site и post-mortem, вот большую часть этих самых решений можно принимать на основе рекомендательных систем и систем классификации.

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

Грубо говоря, поднялось количество мусорного трафика — часть перенесли на CDN, часть попытались классифицировать и отфильтровать через приватные каналы прямо на пограничных маршрутизаторах. И это всё может сделать сама система мониторинга и принятия решений, без участия администратора... администратору нужно только обучить что бы не было косяков.

Потом можно говорить о стандартизации форматов и содержимого собранных логов и стандартизации существующей базы рекомендаций.

Если не знаете как сделать существующие процессы эффективнее — просто добавьте машинное обучение.

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

Oleksii Asiutin

Denis Zhdanov System engineer в eBay Classifieds Group 21.06.2016 17:38

Riemann / ELK / graphite / grafana и еже с ним — не самые хорошие решения для логирования и мониторинга в рамках нагруженных проектов.

«А мужики то и не знают...»
Ну хоть на ненагруженных (e.g. 100ТБ логов в ELK, 500K метрик в графите) попользовать можно, и то хлеб.
А если серьезно, то очень наивно считать что можно прочитать книжку и стать специалистом «логирования и мониторинга в рамках нагруженных проектов». Это только с опытом приходит.
А как для обзора современных решений мониторинга («A hands-on introductory book») книга весьма хороша.

Юрій Ярош developer в bitsnap 20.06.2016 20:07

Касательно

Советую сразу прочитать SRE книгу — там чуть понятнее описано.

На практике проблема мониторинга в том, что он не захватывает критические события.
Грубо-говоря, если перевести все привычные графики в «японские свечи» — можно заметить много странностей, и «не все графики одинаково полезны».

Oleksii Asiutin Director of Engineering в ThredUP 21.06.2016 17:19

«не все графики одинаково полезны»

как бы да, согласен.

графики в «японские свечи»

работаем с такими графиками, но в продукте. В плане применения их для мониторинга: интересно. Благодарю.

Юрій Ярош developer в bitsnap 21.06.2016 17:32

Ну вот есть сэмплирующее профилирование которое берёт средний результат выполнения какого-либо процесса, потому что есть довольно много сторонних факторов, которые влияют на производительность, и нужно принимать решение на сколько собранные данные действительно соответствуют реальности. Ну там шеддулер выполнение приостанавливает на обработку software IRQ, всяких тасклетов и системных вызовов других процессов, промахи в кэше тоже довольно частое явление — в общем всякое случается.

Вот с мониторингом — всё тоже самое, с одной стороны в макро масштабах всё может быть гладко и ровно, а если график «отзумить» то там нагрузка прыгает от 74% до 0%, а на графиках показывается «среднее» значение.

Я изучал вопросы вертикального масштабирования и утилизации аппаратных мощностей существующего железа. На практике получается так что процессор «колбасит» от 50-51% загрузки до 100%, а показывает 74-75% нагрузки.