Некоторое время назад я получил довольно непростую задачу написать техническое задание для нашей службы поддержки на тему OpenID Connect (OIDC).

Тут же я понял, что хоть я и знаком с OAuth и SAML, я не знал практически ничего об OpenID Connect (кроме того, что благодаря этому Pokemon Go получает сведения о моем профиле сразу после авторизации в Google+).

К счастью, мои коллеги подробно посвятили меня во все детали и снабдили необходимыми ресурсами для ознакомления. Хотя, честно говоря, ни одно из объяснений не показалось мне достаточно хорошим и качественным. Поэтому представляю моё видение данного процесса.

На самом деле почти никто не знает, что такое GitOps. Я тоже заблуждался, пока не начал готовить доклад, а потом статью по этой теме. Самое распространенное определение GitOps — это «хранение состояния в Git», но оно не единственное и не самое главное. Это звучное словечко  придумали в Weaveworks, но его название несколько разнится с его реальным пониманием. Созвучие с DevOps — скорее, маркетинговый ход, чем реальное отражение сущности. Основная идея GitOps в том, что помимо хранения состояния в Git, у нас есть непрерывный процесс его синхронизации с реальным миром, то есть, что у вас Kubernetes-кластере или где либо ещё в вашем окружении.

Меня зовут Андрей Квапил. Я работал в чешском хостинге WEDOS. Он не сильно популярен в России, но это крупнейший хостинг на территории Чехии (просто Чехия маленькая).  Сейчас я работаю во Фланте, но именно на примере европейского хостинга WEDOS, хочу рассказать историю имплементации GitOps.

В этой статье мы рассмотрим память внутри контейнера Kubernetes. Какие есть основные типы памяти, как они управляются и какие коварные моменты с ними связаны. В этой статье вы узнаете ответы на интересные вопросы:

• Какие метрики памяти считаются неправильно?

• Сколько раз надо прочитать файл, чтобы он хорошо закешировался?

• Какую память учитывает Out-of-memory killer?

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

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

Джон Такер помогает разобраться с ключевыми аспектами управления ресурсами CPU в Kubernetes. Он объясняет разницу между запросами и лимитами, показывает их влияние на производительность приложений и делится практическими советами по настройке контейнеров. Если хотите улучшить работу кластеров, эта статья станет вашим гидом.

Одна из важных задач при работе с Kubernetes - рациональное распределение ресурсов. Для этого необходимо правильно назначать контейнерам лимиты(limits) и запросы (requests). Но это не всегда простая задача.

Может возникнуть ситуация, при которой, вы зарезервировали намного больше ресурсов, чем необходимо приложению, потому что хотите избежать проблем связанных с исчерпывается памяти в контейнерах или возникновения троттлинга ЦП. В таком случае вам придётся оплачивать неиспользуемые ресурсы. Учтите, что планировщику Kubernetes будет сложнее найти подходящий узел для таких рабочих нагрузок.

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

Мониторинг сегодня – фактически обязательная «часть программы» для компаний любых размеров. В данной статье мы попробуем разобраться в многообразии программного обеспечения для мониторинга и рассмотрим подробнее одно из популярных решений – систему на основе Prometheus и Grafana

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

Материал подготовлен в соавторстве с пользователем wedmeed

В 2017 году, когда начинался наш проект во Вьетнаме, мы столкнулись с новым для нас зверем IBM DataPower. IBM DataPower – продукт, представляющий собой gateway между клиентами и бэкендами, предназначенный для фильтрации, маршрутизации, обогащения или других преобразований проходящих через него сообщений (далее – запросов). Обучаться нужно было быстро, времени на раскачку не было, поэтому нам было предложено самостоятельно ознакомиться с ним, после чего были многочасовые конференции по скайпу с нашим коллегой из Москвы, который передавал нам свои знания и опыт работы с этим продуктом.

Самостоятельное обучение основывалось на изучении документации и просмотре обучающих видео из интернета – и тут меня ждал подвох. Мне практически не удалось найти информации на русском языке. К слову, мои знания английского языка на тот момент были не на высшем уровне, к тому же это был мой первый проект и, наверное, именно эти факторы усложнили мне жизнь. Это сподвигло меня написать обучающую статью на русском языке и в максимально простом изложении для начинающих разработчиков, которые столкнулись с этим продуктом и пытаются оперативно понять его азы. Статья не освободит вас от чтения документации, но облегчит жизнь на первых этапах понимания «как это работает».

Стоит также заметить, что приведенная в практике структура будет приближена к реальному проекту, что позволит вам использовать ее как базу, расширяя и дополняя под ваши требования. В заключение к разделам «Теория» будет приведено несколько слов об уже реализованном проекте, а также некоторые особенности, на которые стоит обратить внимание.

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

В докладе я препарирую Istio, дабы понять, как он работает, какие у него подводные камни и как им правильно пользоваться.

Это мой второй доклад про Istio и Service Mesh. Первый я сделал на конференции Kuber Conf 2021: «Что ждать от внедрения Istio?». Рекомендую ознакомиться сначала с ним, будет несколько проще.

Чтобы перейти с bash на zsh необходимо знать базовые отличия между ними — без этого будет сложно провести первоначальную настройку zsh в ~/.zshrc.

Я не нашёл краткого описания этих отличий когда переходил сам, и мне пришлось потратить немало времени на вычитывание документации zsh. Надеюсь, эта статья упростит вам переход на zsh.

Зачем переходить

Для начала — а стоит ли вообще тратить своё время и внимание на переход? Учить ещё один диалект sh, менее распространённый чем POSIX sh или bash, заново заниматься настройкой рабочего окружения…

На мой взгляд, если вы проводите много времени в консоли, вам нравятся Vim или Emacs и вы уже потратили немало времени на их настройку "под себя" — однозначно стоит! Zsh по духу очень на них похожа: это очень сложная и гибкая программа, чьи возможности полностью мало кто знает, но потратив некоторое время на настройку можно получить очень удобную лично вам рабочую среду.

В первой части мы рассмотрели базовые операции, такие как добавление новых атрибутов, создание индексов и ограничений и т.д.

Эта статья посвящена двум более сложным миграциям:

- обновление большой таблицы
- разделение таблицы на две

Рассмотрим подходы, которые позволяют провести миграции с минимальным простоем для приложения.