Продолжаем серию постов про то как построить своё собственное облако в экосистеме Kubernetes. В прошлой статье мы разобрали как можно подготовить базовый дистрибутив Kubernetes на базе Talos Linux и Flux CD. Теперь нам предстоит обсудить возможность запуска виртуальных машин и всего что для этого необходимо, а это в первую очередь хранилище и сеть.

Мы поговорим про такие технологии как KubeVirt, LINSTOR и Kube-OVN

Для начала мне стоит рассказать зачем вообще нужны виртуальные машины, почему бы нам не ограничиться только-лишь контейнерами?

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

Предисловие

В данной статье хочу поделиться содержанием pipeline.jenkinsfile с минимальной необходимостью для организации автоматизированного тестирования. Установку, настройку самого Jenkins мы рассматривать не будем, только pipeline и его содержание для АТ.

Поезд, сделанный польской компанией, внезапно сломался во время техобслуживания. Специалисты были беспомощны — поезд был в порядке, только никак не хотел ехать. Доведённые до отчаяния, они вызвали на помощь команду Dragon Sector, члены которой нашли такие чудеса, о которых машинисты даже и не мечтали.

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

— Ты должен вкручивать по 10 лампочек в минуту! Зачем иначе наша компания закупила подписку на LightGPT? Мы потратили 20 ср*ных долларов на человека! Мне кажется, я сам бы быстрее вкрутил, чем весь ваш отдел…

Цикл постов про Keycloak. Часть вторая: Контроль доступа на уровне приложения.

Этот пост является продолжением данной статьи. 

В прошлый раз мы настроили ABAC (Attribute Based Access Control) с использованием Keycloak, теперь реализуем проверку разрешений на уровне приложения.

Привет! Меня зовут Петр и мы в компании Nixys очень любим Redis. Эта база используется, если не на каждом нашем проекте, то на подавляющем большинстве. Мы работали как с разными инсталляциями Redis, так и с разными версиями, вплоть до самых дремучих, вроде 2.2. Несмотря на то, что в Интернете очень много статей и докладов по этой БД, мы в своей практике достаточно часто встречаемся с непониманием некоторых основных концепций Redis и со стороны разработчиков, и со стороны системных администраторов.

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

В отличие от таких операционных систем как HPUX (dbc_min_pct, dbc_max_pct) или AIX (minperm%, maxperm%), в Linux нет возможности настраивать размер кэша страниц, читаемых с диска (страничный кэш, page cache). Под страничный кэш Linux использует всю доступную память. Размер страничного кэша можно увидеть в /proc/meminfo в параметре "Cached". В /proc/meminfo есть также значение "Buffers", которое часто путают с размером страничного кэша. "Buffers" — это память, содержащая сырые дисковые данные (raw disk data) и выступающая в роли промежуточного буфера между процессами, ядром и диском.

В этой статье рассмотрим, как Linux работает с памятью, и, в частности, со страничным кэшем, а также исследуем, как доступный объем памяти влияет на производительность буферизованного ввода-вывода (buffered IO).

1. Как в свежей версии keycloak (v.22.0.3) настроить отказоустойчивость при развертывании в k8s в режиме standalone-ha.
2. Как закрыть ненужные векторы атаки, ограничив пользователям доступ только до нужных путей, но оставив возможность админам заходить на консоль админки keycloak.

Всем известно, что pod в Kubernetes может включать в себя несколько контейнеров: для Service Mesh, работы с внешним хранилищем секретов, журналирования и т. д. В итоге это множество вызывает вопросы. Правильно ли использовать столько контейнеров? Как их изолировать от пользовательских приложений? Можно ли вообще исключить дополнительные контейнеры из пользовательских релизов?

Я Максим Чудновский, занимаюсь Synapse Service Mesh в СберТехе. Расскажу, какие есть паттерны применения дополнительных контейнеров в Kubernetes, как они могут помочь в платформенной инженерии, и, самое главное, как полностью автоматизировать процесс управления жизненным циклом таких контейнеров.

Поскольку тема контейнеров довольно объёмна, в этом материале коснусь того, какие виды дополнительных «полезных» контейнеров бывают и как добавлять их в Kubernetes так, чтобы развести релизные процессы прикладных и платформенных команд. А в следующей статье поговорим, как автоматизировать управление дополнительными контейнерами и управлять кластером через политики.

Привет, Хабр! Меня зовут Сергей Баширов, я ведущий разработчик в Cloud.ru. Наша команда RnD занимается исследованиями и оптимизацией баз данных, файловых систем, объектных хранилищ, СХД и SDS в облачной инфраструктуре. И мы решили «импортозаместить в лучших традициях» вендорские решения на базе pNFS. За дело взялись вместе с моим коллегой — Константином Евтушенко (@kevtushx).

К сожалению менеджеров и на радость нам, годной инструкции по настройке в интернете не оказалось. Софт с открытым исходным кодом из коробки не завелся: пришлось погружаться в детали, отлаживать и чинить. В статье расскажу, как всё было, какие ошибки и выводы мы сделали, а также поделюсь подробной инструкцией по настройке стенда с блочным типом доступа к серверам данных. Если интересно — добро пожаловать под кат!

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

Привет! Меня зовут Сергей Птушкин, в этом посте я поделюсь с вами нашим чеклистом для оперативного и безболезненного переезда в Kubernetes. У SM Lab очень много разных продуктов, а как следствие — разных команд разработчиков и администраторов. У всех своя архитектура, стек, любимые языки программирования, SLA и требования по нагрузке.

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

Итак, давайте разберем на примере нашей ситуации. Мы переезжали в Kubernetes из Mesos и Oracle Weblogic и знали, что разработчики тестируют приложения при помощи docker-compose или локально на станциях. Нам нужно было придумать единый подход для следующих возможностей:

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

Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.

Данная информация предполагает знание основ языка запросов и я надеюсь, она окажется полезной для разработчиков, которые сейчас активно ищут работу а также, что ты прочитаешь этот текст до конца и добавишь свой вопрос к перечню (ну или поправишь неточности в существующих)

Привет, с вами команда разработки dBrain.cloud! Хотим поделиться историей миграции с Elasticsearch Beats Kibana (EBK) на Grafana Loki. Предпосылок перехода было немало: замена EBK лицензии Apache 2.0 на ограниченную SSPL 1.0, растущее потребление ресурсов, объемы требуемого места в хранилище и др. Сегодня покажем, как из грамотно подобранных и поселенных под одной крышей продуктов получилось собрать единый стек логирования и мониторинга.

Есть такие ребята — SRE (с англ. Site Reliability Engineering), которые выросли из старых добрых и бородатых системных администраторов. Но они устали заниматься ежедневной рутиной и решили всё автоматизировать. Именно поэтому 50% времени SRE пишут код.

Эта статья — переработанная версия доклада Отказоустойчивая работа с Redis с прошедшего 17 октября 2020 митапа PHP-разработчиков Йошкар-Олы.

Мы поговорим о подводных камнях использования Redis в системе, где важна отказоустойчивость — на примере хранения сессий в условном веб-сервисе, написанном на PHP, но многие замечания будут справедливы и для других платформ — например для микросервисов на Go. Статья будет полезна, если вы проектируете микросервисы или монолитные приложения с достаточно большой нагрузкой и интенсивно работаете с Redis либо столкнулись с потребностью в перепроектировании механизмов аутентификации и сессий.