Рубрика «devops» - 62

@DevOps Meetup #2 в Mail.ru Group: 22 августа - 1

Привет, друзья. Без громких слов, приглашаем всех Dev, Ops и сочувствующих на @DevOps Meetup #2 — послушать:

  • как Райффайзенбанк перешел от зоопарка инструментов CI/CD к централизованному конвейеру на базе стека Atlassian;
  • о сложностях логирования и мониторинга от «Рунет Бизнес Систем» — вы узнаете, как сделать полезную и безопасную агрегацию в условиях динамической инфраструктуры;
  • и напоследок выступит Росгосстрах с рассказом о лучших практиках своего DevOps’а.

Встреча пройдет 22 августа (четверг) в 18:30 в московском офисе Mail.ru Group (Ленинградский проспект, д. 39, стр. 79). Регистрация обязательна и закрывается 20 августа в 23:59 (или раньше, если закончатся места).
Читать полностью »

7 недостающих факторов в подходе 12 factor app - 1

Прим. перев.: Тот восторг, что испытали наши тимлиды, увидев в блоге IBM Cloud этот материал — своеобразное «расширение» легендарного Twelve-Factor App, — говорит сам за себя. Поднятые автором вопросы не просто на слуху, а по-настоящему жизненны, т.е. актуальны в повседневной жизни. Их понимание полезно не только для DevOps-инженеров, но и разработчиков, создающих современные приложения.

Известная методология «12 factor application» представляет собой свод четко определенных правил для разработки микросервисов. Они широко используются для запуска, масштабирования и деплоя приложений. В облачной платформе IBM Cloud Private мы следуем тем же 12 принципам при разработке контейнеризированных приложений. В статье «Kubernetes & 12-factor apps» обсуждается специфика применения этих 12 заповедей (они поддерживаются моделью оркестровки контейнеров Kubernetes).

Размышляя о принципах разработки контейнеризированных микросервисов, работающих под контролем Kubernetes, мы пришли к следующему выводу: вышеуказанные 12 факторов совершенно справедливы, однако для организации production-среды крайне важны и другие, а в частности:Читать полностью »

Технические детали взлома банка Capital One на AWS - 1

19 июля 2019 года банк Capital One получил сообщение, которого боится каждая современная компания — произошла утечка данных. Она затронула более 106 миллионов человек. 140 000 номеров социального страхования США, один миллион номеров социального страхования Канады. 80 000 банковских счетов. Неприятно, согласитесь?

К сожалению, взлом произошёл совсем не 19 июля. Как выяснилось, Пейдж Томпсон, она же Erratic, совершила его между 22 марта и 23 марта 2019 года. То есть почти четыре месяца назад. На самом деле, только с помощью внешних консультантов Capital One сумела узнать, что нечто произошло.
Читать полностью »

Всем привет!

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

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

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

Едим слона по частям. Стратегия мониторинга работоспособности приложений на примерах - 1
Читать полностью »

Привет! Представляю вашему вниманию перевод статьи «Service mesh data plane vs control plane» автора Matt Klein.

Сервисная сеть, «Плоскость данных» и «Плоскости управления» (Service mesh data plane vs. control plane) - 1

В этот раз «захотелось и перевелось» описание обоих компонентов service mesh, data plane и control plane. Это описание мне показалось самым понятным и интересным, а главное подводящим к пониманию «А нужно ли оно вообще?».

Поскольку идея «Сервисной сети (Service mesh)» становится все более популярной в течение последних двух лет (Оригинальная статья от 10 октября 2017), а число участников в пространстве возросло, я увидел соразмерный рост путаницы среди всего технического сообщества в отношении того, как сравнивать и противопоставлять разные решения.
Читать полностью »

Об админах, девопсах, бесконечной путанице и DevOps-трансформации внутри компании - 1

Что нужно для успеха IT-компании в 2019 году? Лекторы на конфах и митапах говорят много громких и не всегда понятных нормальным людям слов. Борьба за время деплоя, микросервисы, отказ от монолита, DevOps-трансформация и много-много чего ещё. Если отбросить словесную красоту и говорить прямо и по-русски, то всё сводится к простому тезису: делайте качественный продукт, причем делайте его с комфортом для команды.

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

Вся эта история от «по модулю» прекрасна, но… Так получилось, что часть админов резко окрестили в DevOps, а от самих DevOps-инженеров стали требовать, как минимум, навыков телепатии и ясновидения.
Читать полностью »

Увидел публикацию о том, что PVS таки научился анализировать под Линуксами, и решил попробовать на своих проектах. И вот что из этого получилось.

Читать полностью »

Беспростойная миграция MongoDB в Kubernetes - 1

Эта статья продолжает наш недавний материал про миграцию RabbitMQ и посвящена MongoDB. Поскольку мы обслуживаем множество кластеров Kubernetes и MongoDB, пришли к естественной необходимости мигрировать данные из одной инсталляции в другую и делать это без простоя. Основные сценарии прежние: перенос MongoDB из виртуального/железного сервера в Kubernetes или же перенос MongoDB в рамках одного кластера Kubernetes (из одного пространства имён в другое).Читать полностью »

4-6 сентября в Санкт-Петербурге, в конференц-зале Selectel пройдет трехдневный Слёрм DevOps.

Слёрм DevOps: от Git до SRE со всеми остановками - 1

Мы строили программу, исходя из мысли, что теоретические труды по DevOps, как и мануалы к инструментам, каждый может прочитать самостоятельно. Интересны только опыт и практика: объяснение, как делать надо и не надо, и рассказ, как делаем мы.

В каждой компании, у каждого администратора или разработчика свой уровень DevOps. Одни неправильно используют Git, другие внедряют SRE. Курс организован так, чтобы каждый нашел что-то актуальное, что можно внедрить здесь и сейчас.

Мы начинаем с Git, потом смотрим на разработку приложения, взаимодействие кода и инфраструктуры, строим CI/CD, описываем инфраструктуру как код (IaC), тестируем получившееся решение, настраиваем мониторинг, собираем и изучаем логи, и в конце доходим до SRE: превращаем надежность в измеряемую и управляемую историю.

Читать полностью »

Эмоджи классные, с их помощью можно даже отразить всю суть рассказа о самом популярном пакетном менеджере для Kubernetes:

  • коробка — это Helm (это самое подходящее, что есть в последнем релизе Emoji);
  • замок — безопасность;
  • человечек — решение проблемы.

Безопасность Helm - 1

Конечно, построить весь рассказ на основе одних эмоджи будет трудно, поэтому дальше схемы будут более традиционного формата.

Поговорим про Helm.

  • Кратко, что такое Helm, если вы не знали или забыли. Какие проблемы он решает и где находится в экосистеме.
  • Рассмотрим архитектуру Helm. Ни один разговор о безопасности и о том, как сделать инструмент или решение более безопасным, не может обойтись без понимания архитектуры компонента.
  • Обсудим компоненты Helm.
  • Самый животрепещущий вопрос— будущее — новая версия Helm 3. 

Все в этой статье относится к Helm 2. Эта версия сейчас находится в продакшене и, скорее всего, именно его вы сейчас используете, и именно в нем есть угрозы безопасности.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js