DevOps *

Сталкиваясь с атаками на веб-ресурсы, администраторы пытаются перекрыть вредоносный трафик настройками веб-сервера, установкой Rate Limit, созданием правил блокировок или ограничением доступа по IP из списка стран. Эти действия требуют навыков и не всегда приводят к ожидаемым последствиям.

В статье расскажу, как обеспечить быструю и качественную защиту веб-приложений и API от большей части угроз OWASP Top-10 с использованием бесплатной версии Nemesida WAF Free.

Развертывание Kubernetes на физических серверах  рекомендуется организациям, которые находятся в поисках новых возможностей в сфере управления инфраструктурой. Рассмотрим 6 причин попробовать K8s на выделенных серверах. 

Kubernetes в общедоступном облаке - это подходящее решение для приложений малого и среднего размера, которые имеют предсказуемые потребности в плане масштабирования. Вместе с тем, bare metal-облако - это путь для организаций, стремящихся к большему контролю и стабильной производительности.

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

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

Привет! Недавно X5 провела об опенсорсном проекте Keyckloack. По традиции публикуем запись мероприятия и презентации спикеров.

• Автоматизированное управление конфигурацией, тестированием и развертыванием приложений;
• Контроль версий для обеспечения совместной работы и откатов;
• CI для автоматизации сборки кода и обеспечения высокого уровня обратной связи за счет более частых выпусков ПО с меньшим риском.

Традиционно для сценариев поточной обработки с использованием Map-Reduce рассматриваются такие решения как Hadoop/Spark, либо используются конвейерные системы (например Kafka), для которых есть возможность реализовать концепцию потоков (streams) с помощью дополнительных инструментов (в случае с Kafka это Kafka Connect (для подключения к источникам и получателям потока) и Kafka Streams для реализации Map-Reduce на потоке сообщений.

Начиная с версии 3.9 RabbitMQ анонсировал поддержку нового типа очереди, оптимизированного для поточной обработки. В этой статье мы посмотрим на основные отличия очередей RabbitMQ от классического режима очереди сообщений, а также возможные сценарии использования (с примерами кода на Go).

Привет, Хабр! 

Думаю, для вас не секрет, что в последние годы контейнеризация вышла в лидеры на DevOps благодаря своим возможностям, включая эффективное использование ресурсов и гибкость. Так что Microsoft и Docker потратили немало времени на создание удобной среды, в которой можно было бы провести запуск приложений .NET внутри контейнеров. 

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

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

А вы когда-нибудь задумывались о границах масштабируемости Kubernetes? Для тех, кого порой посещают такие мысли, мы решили опубликовать перевод заметки "Kubernetes Scalability thresholds", вам точно будет интересно ознакомиться.

Deployment и DeploymentConfig — это, казалось бы, похожие объекты API для OpenShift Container Platform. Но на самом деле они предлагают разные гибкие методы управления интерфейсом пользователей. Расскажем о различиях и приведём примеры, когда какие объекты лучше использовать.

Технический долг — головная боль многих разработчиков. Это та ситуация, когда ты видишь, что можно сделать лучше, но не делаешь этого из-за высокой нагрузки, малого количества времени и ещё по тысяче причин. В итоге долг накапливается, накапливается, накапливается... А потом что-то происходит.

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

Такой вот звонок ко мне пришел от нашего VP of Engineering Виктора около 7 вечера 9 марта прошлого года. Дело в том, что Виктор знает русский, но никогда не жил в России, поэтому он часто добавляет "как у вас говорят" или какие-то другие только ему ведомые присказки, поговорки и пословицы. Но сейчас не об этом.

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

7 часов вечера по Калифорнии - это такое редкое время, когда Москва еще не проснулась, а наши уже закончили и можно отдохнуть. На тот момент у нас еще не было команды в Томске и я с 7 до 10-11 вечера обычно отдыхал. Но не 10 марта. И вообще не в марте. Честно говоря, слабо помню как выглядел март прошлого года после 10-го числа. И апрель тоже. Время немного ускорили той весной и потом отпустили уже летом.

На сегодняшний день это один из, или же самый известный способ автоматического анализа кода и его ревью. Популярностью он обязан тому, что этот сервис бесплатен и доступен, а так же для его установки не требуется много усилий. Интерфейс выглядит современно и понятно. Sonarqube, хоть и написан на java, не ест много ресурсов :)

Привет! Меня зовут Кирилл Цветков. Я DevOps, инженер, линуксовый админ – именно через запятую и никак иначе. В этой статье я попробую последовательно рассказать вам что такое DevOps, и примирить два конфликтующих стереотипа, которые это слово окружают.

1. Отделили ли вы сборки от продуктового кластера?

В нашем блоге уже была статья про инфобез. Но Алексей Федин, ведущий инженер в этой отрасли, сказал, что она неправильная. Мы исправляемся и даём слово Алексею, который решил помочь разобраться в сфере и сделать то, что в ИТ любят больше всего: категоризировать, отсортировать, представить в виде списка и нарисовать схему. Документов и схем в интернете уже создано множество: попроще, посложнее, со связями отдельных элементов или без. Это мало помогает, а иногда и ещё больше запутывает. Основная наша аудитория  — люди, далёкие от инфобеза, а иногда и от ИТ. Поэтому рассказываем обо всём по-простому, своими словами.

Туториал по основам докера в котором простыми словами объясняется, как собирать образы и разворачивать контейнеры. Тут же можно узнать, чем контейнер отличается от виртуалки, что такое образ и увидеть простой кейс.

Фото Todd Diemer, Unsplash.com

В PayPal мы недавно начали прощупывать почву с Kubernetes. Большинство наших рабочих нагрузок выполняется на Apache Mesos, и в рамках этой миграции нам необходимо было понять несколько аспектов производительности кластеров, работающих под управлением Kubernetes, с control plane, специфичной для PayPal. Главным среди этих аспектов является понимание масштабируемости платформы, а также определение возможностей для улучшения за счет настройки кластера.

В отличие от Apache Mesos, который может масштабироваться до 10 000 нод из коробки, масштабирование Kubernetes является нетривиальной задачей. Масштабируемость Kubernetes ограничивается не только количеством нод и подов, но и некоторыми другими аспектами, такими как количество создаваемых ресурсов, количество контейнеров в поде, общее количество сервисов и производительность при развёртывании подов (pod deployment throughput). В этой статье мы опишем некоторые проблемы, с которыми столкнулись при масштабировании, и то, как мы их решили.

Мы рады представить релиз GitLab 14.7 с трансляцией событий аудита, соответствием GitLab Runner стандарту FIPS 140-2, групповыми токенами доступа и многим другим!

Привет! Меня зовут Артемий Окулов, я lead центра компетенций CI/CD в X5 Group.

То, чем мы с командой занимаемся, можно отнести к области под названием Developer Experience. В какой-то момент ИТ в компании достигает такой зрелости, что появляются tools team, enabling team и инициативы, направленные на повышение developer experience. Одной из таких инициатив мы и занимаемся. Если вкратце, мы хотим упростить старт новых продуктов в компании за счет предоставления шаблонов.

В X5 Group много web-сервисов, и с переходом на продуктовый подход виден рост количества команд, которые все чаще прибегают к их созданию. Конечно, каждая команда должна быть кросс-функциональной, чтобы успех реализации продукта зависел в большей степени от самой команды. Но часто мы сталкиваемся с тем, что найти инженера с ролью devops в команду — это задача нескольких месяцев. А терять столько времени на старте — непозволительная роскошь. Поэтому в компании ведутся работы по созданию “стартовых наборов”, решающих задачу минимум — быстрого старта разработки и создания dev-окружения силами самих разработчиков.

В поставку такого “стартового набора” входит и CI/CD pipeline. В этой статье, в частности, мы бы хотели поделиться подходом шаблонизации GitLab Pipelines, который мы стараемся продвигать у себя в компании, и рассказать про инструмент, который для этого разработали.