Серверное администрирование *

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

В Docker уже встроено несколько замечательных средств обеспечения безопасности:

• Docker-контейнеры минимальны: один или несколько работающих процессов, только необходимое программное обеспечение. Это снижает вероятность пострадать от уязвимостей в ПО.

  
  

• Docker-контейнеры выполняют специфическую задачу. Заранее известно, что должно выполняться в контейнере, определены пути к директориям, открытые порты, конфигурации демонов, точки монтирования и т. д. В таких условиях проще обнаружить какие-либо связанные с безопасностью аномалии. Этот принцип организации систем идет рука об руку с микросервисной архитектурой, позволяя значительно уменьшить поверхность атаки.

  
  

• Docker-контейнеры изолированы как от хоста, так и от других контейнеров. Этого удается добиться благодаря способности ядра Linux изолировать ресурсы с помощью cgroups и namespaces. Но есть серьезная проблема — ядро приходится делить между хостом и контейнерами (мы еще вернемся к этой теме чуть позже).

  
  
• Docker-контейнеры воспроизводимы. Благодаря их декларативной системе сборки любой администратор может легко выяснить, из чего и как был сделан контейнер. Крайне маловероятно, что у вас в итоге окажется неизвестно кем настроенная legacy-система, которую никому не хочется конфигурировать заново. Знакомо, не правда ли? ;)

Однако в основанных на Docker системах есть и слабые места. В этой статье мы как раз о них и поговорим, рассмотрев 7 проблем безопасности Docker.

Введение

Согласно данным, которые представил на Dockercon 2016 CEO компании Docker Бен Го́луб (Ben Golub), количество работающих в контейнерах Docker приложений за последние два года выросло на 3100%. Docker обеспечивает функционирование 460 тысяч приложений по всему миру. Это невероятно!

Если вы еще не начали использовать Docker, прочтите этот впечатляющий документ о его внедрении. Docker изменил подход к созданию приложений и стал крайне важным инструментом для разработчиков и DevOps-специалистов. Эта статья рассчитана на тех, кто уже использует Docker, и призвана открыть еще одну причину, по которой стоит продолжать это делать.

Мы бы хотели поделиться своим опытом использования docker-compose в больших проектах. Применив этот инструмент для автоматизации задач, связанных с разработкой, тестированием и конфигурированием, мы за несколько простых шагов смогли сделать нашу команду более эффективной и сфокусироваться непосредственно на разработке продукта.

Привет! Объявляем регистрацию на митап открытой. Мы в очередной раз принимаем в нашем офисе сообщество Zabbix. Ниже – описание выступлений. Начало мероприятия в 12:00.

— Сударь, каким образом вас взломали?
— Не образом, а контейнером.
Старинный анекдот

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

В этом июне, в качестве лейтмотива конференции DockerCon мы видели демо, в котором 3-узловой Swarm-кластер был создан за 30 секунд используя набор инструментов для кластеризации Swarm, интегрированную в Docker Engine 1.12.

Впечатляет, но естественно, мне нужно было попробовать сделать это самому, чтобы увидеть своими глазами.

Следуя устоявшемуся квартальному ритму выпуска значимых релизов, мы выпустили стабильные версии Angie и Angie PRO 1.10 — форка nginx, развиваемого в основном бывшими ключевыми разработчиками оригинального проекта.

Как и в прошлый раз, расскажем подробнее о нововведениях, приводя примеры. Вы узнаете, в чём ключевая фишка нового релиза (картинка под заголовком намекает); также слегка приоткроем завесу тайны над тем, что у нас припасено на будущее.

А пока — краткий список нововведений, которые будут разобраны ниже:

— автоматическое проксирование и балансировка веб-сервисов в Docker-контейнерах (или Podman);
— автоматическое получение TLS-сертификатов для потокового модуля (stream);
— прием соединений Multipath TCP (MPTCP);
— контроль перегрузки CUBIC в QUIC-соединениях;
— привязка сессий с внешним хранилищем в модуле stream;
— новые режимы привязки сессий при проксировании HTTP-запросов;
— режим постоянного перехода на резервную группу в модуле stream.

Привет, Хабр! Меня зовут Михаил Косцов, я руковожу практикой вычислительной инфраструктуры и систем резервного копирования в К2Тех. Сегодня расскажу о результатах тестирования отечественной СХД Аэродиск Engine AQ440. Это одно из российских решений класса midrange, которых сейчас становится все больше на рынке корпоративных систем хранения данных. СХД представлена в реестре Минпромторга, а ее производитель, компания Аэродиск, наверняка знаком многим из вас.

В последние годы на рынке появилось много отечественных решений, которые на бумаге выглядят впечатляюще, но на практике не всегда соответствуют заявленным характеристикам. Особенно это касается сложных систем вроде СХД, где нужно не просто собрать железо, но и создать надежное программное обеспечение. К тому же, метрокластер и репликация — функции высокого уровня, которые даже у зарубежных вендоров порой реализованы не идеально. Однако в случае Аэродиск Engine AQ440 результаты оказались интереснее, чем мы ожидали.

Мы решили проверить, насколько заявленная функциональность системы соответствует реальности, и как она справляется с различными сценариями использования. Честно говоря, начинали тестирование СХД от Аэродиск с небольшим скепсисом.

В этой статье расскажу о впечатлениях от системы, ее архитектуре, функциональности, производительности и отказоустойчивости. Мы протестировали All-Flash-конфигурацию, проверили работу метрокластера (функции, которой пока нет у других отечественных производителей СХД), и создали несколько аварийных ситуаций, чтобы оценить надежность системы.

Готовы узнать, как справляется российское решение с задачами корпоративного хранения данных? Давайте разбираться!

С версией 1.19 в Gitea появился собственный Github-подобный CI/CD. Насколько же трудно будет прикрутить к уже работающему Gitea серверу CI/CD. Давайте проверим!

Привет, Хабр! Меня зовут Владислав Балакин. Я тимлид группы дежурных инженеров в департаменте инфраструктурных решений и сервисов. Работаю с первого дня создания этой группы и знаю про нее абсолютно все. В круглосуточном режиме мы мониторим состояние и поддерживаем работоспособность ИТ-инфраструктуры наших заказчиков.

В предыдущих постах коллеги много и обстоятельно рассказывали о том, как отреагировал ИТ-рынок на уход зарубежных вендоров. И как кратный рост спроса на сервис и поддержку повлиял на наполнение нашего склада ЗИП. И т.д. И т.п. Но как все это реально отразилось на нашей работе? Сегодня вас ждет крик души рассказ о том, как сейчас проходит 24-часовая смена дежурного инженера КРОК. И о том, как мы в условиях роста загрузки выстраиваем работу, чтобы не уронить ни SLA, ни себя. Подробности под катом!

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