Привет, Хабр!
Меня зовут Рустем Галиев, я Senior DevOps Engineer в IBM, и мы продолжаем разбираться, как искать и эксплуатировать уязвимости в контейнеризированных средах на примере практических атак. Это третья часть, ссылки на первую две:
Часть первая
В этой статье разберём, для решения каких задач DevOps-специалисты могут использовать Python. Посмотрим на взаимодействие Python с системами контроля версий (CVS), инструментами CI/CD и другими аспектами DevOps.
Привет, Хабр!
Меня зовут Рустем Галиев, я Senior DevOps Engineer в IBM, и мы продолжаем разбираться, как искать и эксплуатировать уязвимости в контейнеризированных средах на примере практических атак. Первую часть статьи можно найти тут, а ссылку на третью добавлю сюда, когда выложу.
Привет, Хабр!
Меня зовут Рустем Галиев, я Senior DevOps Engineer в IBM.
В последние годы контейнеризация стала неотъемлемой частью инфраструктуры для современных приложений. Технологии контейнеризации, такие как Docker и Kubernetes, предоставляют удобный способ упаковки, развёртывания и масштабирования приложений, а также обеспечивают лёгкость миграции и управление зависимостями. Но, как и любая другая технология, контейнеры имеют свои уязвимости. Ошибки в конфигурации, слабые политики безопасности и недостаточная изоляция контейнеров могут превратить их в привлекательные цели для злоумышленников.
Эта статья расскажет, как искать и эксплуатировать уязвимости в контейнеризированных средах, рассматривая ключевые аспекты контейнерной безопасности, включая распространенные уязвимости, ошибки в конфигурации, а также методы для их выявления и эксплуатации. Мы обсудим примеры практических атак, таких как контейнерный брейкаут, межконтейнерные атаки, перехват данных и несанкционированное использование секретов, а также дадим рекомендации по предотвращению этих угроз.
Статью разделил на три части, ссылки на вторую и третью добавлю, после того как выложу.
Пятая и заключительная часть статьи, в которой Виталий Лихачёв, SRE в booking.com и спикер курса Слёрма «Golang-разработчик» рассказывает, о чём стоит подумать перед выкаткой сервиса в жестокий прод, где он может не справиться с нагрузкой или деградировать из-за резких всплесков при наплыве пользователей и по вечерам.
Статья состоит из 5 частей, которые выходят по очереди:
1. Надежность.
2. Масштабируемость/отказоустойчивость.
3. Resiliency/отказоустойчивость.
Четвертая часть статьи, в которой Виталий Лихачёв, SRE в booking.com и спикер курса Слёрма «Golang-разработчик» рассказывает, о чём стоит подумать перед выкаткой сервиса в жестокий прод, где он может не справиться с нагрузкой или деградировать из-за резких всплесков при наплыве пользователей и по вечерам.
Статья состоит из 5 частей, которые выходят по очереди:
1. Надежность.
2. Масштабируемость/отказоустойчивость.
3. Resiliency/отказоустойчивость.
Третья часть статьи, в которой Виталий Лихачёв, SRE в booking.com и спикер курса Слёрма «Golang-разработчик» рассказывает, о чём стоит подумать перед выкаткой сервиса в жестокий прод, где он может не справиться с нагрузкой или деградировать из-за резких всплесков при наплыве пользователей и по вечерам.
Статья состоит из 5 частей, которые выходят по очереди:
1. Надежность.
2. Масштабируемость/отказоустойчивость.
3. Resiliency/отказоустойчивость.
Вторая часть статьи, в которой Виталий Лихачёв, SRE в booking.com и спикер курса Слёрма «Golang-разработчик» рассказывает, о чём стоит подумать перед выкаткой сервиса в жестокий прод, где он может не справиться с нагрузкой или деградировать из-за резких всплесков при наплыве пользователей и по вечерам.
Статья состоит из 5 частей, которые будут выходить по очереди:
1. Надежность.
2. Масштабируемость/отказоустойчивость.
3. Resiliency/отказоустойчивость.
Опытом делится Виталий Лихачёв, SRE в booking.com и спикер курса Слёрма «Golang-разработчик». Он рассказывает, о чём стоит подумать перед выкаткой сервиса в жестокий прод, где он может не справиться с нагрузкой или деградировать из-за резких всплесков при наплыве пользователей и по вечерам.
Считайте это некоторым чек-листом, но не применяйте все пункты as is, потому что каждая система уникальна и иногда вполне допустимо построить менее надежную систему с целью значительного сокращения затрат на разработку, поддержку и эксплуатацию (например, отсутствие резервирования). Однако бэкапы обязательно должны быть 🙂
Некоторые термины не будем переводить не в силу лени автора, а в силу устойчивости терминов в литературе.
Отдельные пункты внимательный читатель может отнести сразу к нескольким разделам верхнего уровня. Поэтому деление на подгруппы довольно условное.
Если возникнет вопрос, а почему не описан некоторый X в чек-листе, то ответ простой: статья и так получилась огромной, и вы вероятно сможете найти что-то полезное для себя.
Статья состоит из 5 частей, которые будут выходить по очереди:
1. Надежность.
2. Масштабируемость/отказоустойчивость.
3. Resiliency/отказоустойчивость.
О понятии Sentinel говорят мало, особенно в русскоязычном пространстве. Вместе с Юрием Вашинко, опытным тимлидом и спикером нашего курса «С++ разработчик» сегодня рассмотрим, что такое Sentinel и как его использовать:
Steal Time и Load Average — вещи, которые линукс-админ видит ежедневно, но мало кто закапывается под капот и понимает, как оно устроено.
Кирилл Казарин, Senior DevOps и SRE менеджер, спикер нашего курса «Администрирование Linux.Мега», рассказал, что такое Steal Time: что это за метрика процессора, как она работает и как её понимать. Давайте разбираться:
Мы знаем, что многие это слышали: можно попросить работодателя оплатить обучение на профильных курсах. Но как это организовать? К кому идти и что говорить? Как аргументировать, что это будет полезно самой компании?
Мы попробовали разобраться и предлагаем план:
Системные сервисы в Linux обеспечивают управление процессами и службами: запускают, останавливают и отслеживают состояние. Одни из самых распространенных и значимых систем сегодня — Systemd, SysVinit, OpenRC и Upstart, о них и поговорим. Рассмотрим их особенности, плюсы и минусы, и отдельно — роль Systemd, который стал стандартом де-факто в современных дистрибутивах Linux.
Ловили ли вы себя когда-нибудь на мысли, что можно задействовать конкретный инструмент по-другому и решить сложную задачу, максимально задействуя существующие возможности? С меньшим количеством внешних зависимостей, будь то кеши, очереди или БД.
В данном случае таким инструментов является golang. Попробуем с его помощью решить одну не самую тривиальную задачу. Основная задача статьи — показать какие задачи можно достаточно легко решать на go, по максимуму используя горутины/каналы/блокировки.
Обсудили высокую доступность в k8s: эксперт Слёрма Кирилл Борисов — SRE, инцидент-менеджер и спикер конференций Highload++, Devops, DevOops, ProITFest — рассказал про использование Affinity и Anti-Affinity, Tolerations, PodDiscruption Budget и Horizontal Pod Autoscaler.
Делимся переводом статьи об интеграции Kubernetes и Ansible. Из статьи вы узнаете, как подготовить среду для работы, как развернуть кластер Kubernetes с помощью Ansible, как управлять ресурсами Kubernetes и автоматизировать обновления. Кроме того, вы узнаете, как развернуть плейбук Ansible в Kubernetes на облачном провайдере и использовать Ansible для CI/CD в Kubernetes.
Chaos engineering — это подход к проверке устойчивости приложений. Грубо говоря, мы умышленно ломаем что-либо в системе, чтобы посмотреть, как она будет себя вести, и делаем из этого эксперимента полезные выводы о надёжности и уязвимостях.
Перевели статью, о том, как применить этот подход к HashiCorp Vault — системе по управлению секретами.
Если вы когда-либо взаимодействовали с кластером Kubernetes, скорее всего, он был основан на etcd. etcd лежит в основе работы Kubernetes, но несмотря на это, напрямую взаимодействовать с ним приходится не каждый день.
Этот перевод статьи от learnk8s познакомит вас с принципами работы etcd, чтобы вы могли глубже понять внутреннюю работу Kubernetes и получить дополнительные инструменты для устранения неполадок в вашем кластере. Мы установим и сломаем кластер etcd с тремя нодами и узнаем, почему Kubernetes использует etcd в качестве базы данных.
Автомасштабирование обеспечивает эффективность и надёжность приложения. Оно автоматически адаптирует ресурсы в соответствии с потребностями. В периоды пиковой нагрузки — увеличивает, в более спокойные периоды — уменьшает для снижения затрат. Эта гибкость особенно полезна для обработки непредсказуемого трафика: приложения остаются отзывчивыми и не используют ресурсов больше, чем необходимо. Перевели статью о том, как настроить Kafka Scaler на основе задержки подписчика (consumer lag).
Очень непростая задача — управлять экосистемой развлечений, чтобы впечатлять людей разного возраста: от маленьких детей до взрослых поклонников Disney. Тем более что практически все развлечения Disney основаны на сложной технологической базе. Поэтому в Disney есть собственные команды SRE. Они ответственны за то, чтобы «волшебство» работало как часы.