Лучше поздно, чем никогда. Или как мы чуть не допустили серьёзную ошибку, не имея поддержки обычных Dockerfiles для сборки образов приложения.
Речь пойдёт про werf — GitOps-утилиту, которая интегрируется с любой CI/CD-системой и обеспечивает управление всем жизненным циклом приложения, позволяя:
Прим. перев.: Автор этого материала — Cindy Sridharan, инженер из компании imgix, занимающаяся вопросами разработки API и, в частности, тестирования микросервисов. В этом материале она делится своим развёрнутым видением актуальных проблем в области распределённой трассировки, где, по её мнению, наблюдается недостаток по-настоящему эффективных инструментов для решения насущных задач.
[Иллюстрация заимствована из другого материала про распределенную трассировку.]
Считается, что распределенную трассировку сложно внедрять, да и отдача от нее в лучшем случае сомнительная. «Проблемность» трассировки объясняют множеством причин, при этом часто ссылаются на трудоемкость настройки каждого компонента системы для передачи соответствующих заголовков вместе с каждым запросом. Хотя эта проблема действительно имеет место, ее вовсе нельзя назвать непреодолимой. Она, кстати, не объясняет, почему разработчики не очень любят трассировку (даже уже функционирующую).Читать полностью »
Когда в Linux сервер базы данных непредвиденно завершает работу, нужно найти причину. Причин может быть несколько. Например, SIGSEGV — сбой из-за бага в бэкенд-сервере. Но это редкость. Чаще всего просто заканчивается пространство на диске или память. Если закончилось пространство на диске, выход один — освободить место и перезапустить базу данных.
Когда у сервера или процесса заканчивается память, Linux предлагает 2 пути решения: обрушить всю систему или завершить процесс (приложение), который съедает память. Лучше, конечно, завершить процесс и спасти ОС от аварийного завершения. В двух словах, Out-Of-Memory Killer — это процесс, который завершает приложение, чтобы спасти ядро от сбоя. Он жертвует приложением, чтобы сохранить работу ОС. Давайте сначала обсудим, как работает OOM и как его контролировать, а потом посмотрим, как OOM Killer решает, какое приложение завершить.
Southbridge со своим Слёрмом — единственная в России компания, которая имеет сертификат KTP (Kubernetes Training Provider).
Слёрму исполнился год. За это время наши интенсивы по Кубернетес прошло 800 человек. Самое время заняться мемуарами.
9-11 сентября в Питере, в конференц-зале Selectel пройдет очередной Слёрм, пятый по счету. Будет введение в Kubernetes: каждый участник создаст кластер в облаке Selectel и задеплоит туда приложение.
Под катом — история Слёрма, начиная с идеи и до сегодняшнего дня.
Павел Селиванов на открытии Слёрма-4
24-25 августа, традиционно в последние выходные лета, в Санкт-Петербурге пройдет компьютерный фестиваль Chaos Constructions 2019. На конференции в рамках фестиваля вашему вниманию будут представлены более 60 докладов на разные тематики.
.
Изначально фестиваль был посвящен демосцене, а те компьютеры, которые теперь ретро, были самыми современными. Все началось в 1995 году с фестиваля ENLiGHT, который был организован Петром Соболевым (frog). В те годы толком не было ни системного администрирования, ни интернета, первые программисты создавали код, который выводил звуки и анимацию. Первопроходцы собирались раз в год под одной крышей показать свои работы и поделиться кодом, который и сейчас доступен для просмотра и изучения на http://ftp.cc.org.ru, где можно посмотреть работы за все эти годы. Из демопати ENLiGHT вырос компьютерный фестиваль Chaos Constructions. В 1999 году мероприятие впервые проходило под новым именем, постепенно на фестивале появилась выставка из коллекций энтузиастов. Сейчас эта выставка известна как объединение RTS, вы можете посещать её в разных городах России и на крупнейших фестивалях, и на небольших мероприятиях.
Читать полностью »
В прошлой статье я рассказал про нашу инфраструктуру большого нагрузочного теста. В среднем мы создаём порядка 100 серверов для подачи нагрузки и порядка 150 серверов для работы нашего сервиса. Все эти сервера нужно создавать, удалять, конфигурировать и запускать. Мы используем для этого те же инструменты, что и на проде, чтобы уменьшить количество ручной работы:
Благодаря скриптам Terraform и Ansible, все операции от создания инстансов до запуска сервера выполняются всего шестью командами:
#запускаем нужные инстансы в консоли aws
ansible-playbook deploy-config.yml #обновляем версии серверов
ansible-playbook start-application.yml #запускаем наше приложение на этих серверах
ansible-playbook update-test-scenario.yml --ask-vault-pass #обновляем Jmeter сценарий, если в нём были изменения
infrastructure-aws-cluster/jmeter_clients:~# terraform apply #создаем jmeter сервера для подачи нагрузки
ansible-playbook start-jmeter-server-cluster.yml #запускаем jmeter кластер
ansible-playbook start-stress-test.yml #запускаем тестВ общем случае с помощью shell команды можно получить любую метрику, без написания кода и интеграций. А значит в консоли должен быть простой и удобный инструмент для визуализации.
Наблюдение за изменением состояния в базе данных, мониторинг размера очередей, телеметрия с удаленных серверов, запуск деплой скриптов и получение нотификации по завершению — конфигурируется за минуту простым YAML файлом.
Код доступен на гитхабе. Инструкции по установке — для Linux, macOS и (экспериментально) Windows.
Авторы: Тед Янг, Притам Шах и «Комитет технических спецификаций» (Карлос Альберто, Богдан Друту, Сергей Канжелев и Юрий Шкуро).
Совместный проект обзавелся названием: http://opentelemetry.io
Для обучения в жизни нет лучшего времени, чем сегодня.
На дворе 2019 год, и тема DevOps сейчас актуальна, как никогда. Говорят, что дни системных администраторов прошли, как миновала эпоха мейнфреймов. Но так ли это на самом деле?
Как это часто бывает в IT, ситуация изменилась. Появилась методология DevOps, но она не может существовать без человека с навыками системного администратора, то есть без Ops.
До того как DevOps-подход приобрёл свой современный облик, я относил себя к категории Ops. И я хорошо знаю, что испытывает сисадмин, когда понимает, сколько же всего он пока не умеет и как мало времени у него на то, чтобы этому научиться.Читать полностью »
Сегодня в Southbridge на планерке обсуждали бирюзовый менеджмент.
Были те, кто предлагал двигаться сверху вниз, от идеи к практике. Мол, давайте внедрим философию бирюзового менеджмента: найдем эталон, примем решение о том, как должны делиться роли, как должна строиться коммуникация, и начнем двигаться в этом пути.
Были те (и я в том числе), кто хотел двигаться снизу вверх, от практики к идее. У нас есть конкретные задачи и конкретные проблемы. Давайте решать их, опираясь на бирюзовые инструменты, и бирюзовый менеджмент сложится сам собой.
Если сравнивать управление с разработкой, то путь сверху вниз — это создание монолита, а путь снизу вверх — это микросервисная архитектура. Сейчас, в нашем «микросервисном» управлении, мы можем два раза в день перестроить управленческий контур и немедленно «выкатить его в продакшен».
И программа Слёрм DevOps создана для тех, кто предпочитает двигаться снизу вверх.
