Сегодня я расскажу о том, как быстро собрать отказоустойчивый кластер с балансировкой нагрузки с помощью keepalived на примере DNS-серверов.

Здесь даные советы для начинающих программистов. Этот материал для новичков. Опытные специалисты все это уже знают давно.

Несколько несложных примеров того, как на практике можно использовать продвинутые возможности Helm для эффективной организации безупречной continuous delivery в Kubernetes. Полезные рецепты, чтобы поддерживать конфигурации множества тестовых и production сред - удобно, безопасно, без копипасты и приятно на вид. Методы поддержания целостности сред - чтобы "зелёный" статус пайплайна всегда означал удачный деплоймент, а в случае неудачи среда бы сама восстанавливалась.

Helm — один из самых популярных пакетных менеджеров для Kubernetes, так что познакомиться с ним поближе стоит всем, кто сталкивается с задачами деплоя приложений. Эта статья завершает мое краткое, но достаточно полное введение в Helm.

Helm — один из самых популярных пакетных менеджеров для Kubernetes. Познакомиться с ним полезно любому DevOps-инженеру и всем, кто сталкивается с задачами деплоя приложений. Эта статья — первый из двух материалов, которые можно вместе можно рассматривать как краткое, но достаточно полное введение в Helm.

Elasticsearch - это поисковый движок, который позволяет в реальном времени работать с огромными объемами данных. Он основан на Lucene и предлагает не только полнотекстовый поиск, но и сложные запросы к данным, включая агрегацию.

Ruby on Rails — это фреймворк, который делает акцент на скорости и простоте разработки. Используя принципы convention over configuration и DRY, Rails позволяет сосредоточиться на уникальной логике приложения, минимизируя количество шаблонного кода.

В статье рассмсотрим как использовать Elasticsearch вместе с Ruby on Rails для реализации поиска внутри приложения.

В этой статье мы собираемся разобраться со следующими вопросами:

* Как виртуализировать сетевые ресурсы, чтобы контейнеры думали, что у них есть отдельные сетевые среды?

* Как превратить контейнеры в дружелюбных соседей и научить общаться друг с другом?

* Как выйти во внешний мир (например, в Интернет) изнутри контейнера?

* Как связаться с контейнерами, работающими на хосте Linux, из внешнего мира?

* Как реализовать публикацию портов, подобную Docker?

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

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

Но начнём мы с небольшого объяснения, почему система такая сложная. Вспомним суть:

1) Для логина на "не значимые" сайты (например в аккаунт очередного AI-продукта) мы используем уникальный пароль, который храним в программе хранения паролей (парольном менеджере)

2) Для логина на "более важные ресурсы" (например в аккаунт на github), мы используем уникальный пароль, который храним в парольном менеджере, плюс одноразовый пароль (TOTP - Time-based One-Time Password) который нам покажет специальное приложение на телефоне.

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

Привет, Хабр! Меня зовут Евгений Симигин, я занимаюсь внедрением DevOps-практик в Центре компетенций по разработке облачных и интернет-решений МТС Digital. А еще я – куратор практикумов docker и kubernetes на платформе rebrainme.com.

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

Небольшая инструкция о том, как используя Keycloak можно связать Kubernetes с вашим LDAP-сервером и настроить импорт пользователей и групп. Это позволит настраивать RBAC для ваших пользователей и использовать auth-proxy чтобы защитить Kubernetes Dashboard и другие приложения, которые не умеют производить авторизацию самостоятельно.

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

Не секрет, что микросервисы мало запустить. За их работой нужно следить, чтобы не было сбоев, а следовательно и недовольных пользователей. Для этого, нужны системы мониторинга и логирования. Команда платформы dBrain собрала свой универсальный стек системы мониторинга. Сегодня расскажем, какие проблемы возникают с мониторингом и как их решить.

В серии статей по теме DevOps мы рассказываем о проверенных инструментах выстраивания инфраструктуры, которыми с недавнего времени пользуемся сами. В первой части мы остановились на основных предпосылках внедрения и выбранном подходе. В этой статье вместе с  Lead DevOps инженером департамента информационных систем ИТМО Михаилом Рыбкиным рассмотрим подробнее фундамент нашей инфраструктуры — Kubernetes. 

Разумеется, статей об этом оркестраторе огромное множество, и можно на протяжении всей карьеры узнавать о нем что-то новое. Сразу уточним — в этой части мы не планируем копать глубоко. Попытаемся дать основы, описать Kubernetes так, чтобы сложилось базовое представление об этом инструменте. 

Не так давно мы в департаменте информационных систем (далее – ДИС) ИТМО начали выстраивать новую инфраструктуру для деплоя наших проектов. Образовательным организациям обычно с бюрократической точки зрения сложно прийти к масштабным внедрениям. Нам повезло ― мы смогли путем проб и ошибок выбрать удобные проверенные технологии и реализовать единую среду, которая задала формат взаимодействия между администраторами и разработчиками.

В общей сложности подбор инструментов и их внедрение заняли полтора года. Конечно, иногда был непросто: наступали на “грабли” и возвращались, чтобы выбрать более удачный путь. И это несмотря на то, что в общих чертах было изначально понятно, куда двигаться.

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

В рамках университетского блога мы вводим новую рубрику по DevOps, в которой Lead DevOps инженер ДИС Михаил Рыбкин расскажет, как вместе с командой внедрил платформу деплоя для разработчиков.

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

В серии статей по теме DevOps мы вместе с Lead DevOps инженером департамента информационных систем ИТМО Михаилом Рыбкиным рассказываем о проверенных инструментах выстраивания инфраструктуры, которыми с недавнего времени пользуемся сами. В предыдущих статьях мы уже рассмотрели предпосылки перехода на новую инфраструктуру, познакомились с азами Kubernetes и обсудили методы доставки кода. В рамках последней темы мы пришли к методологии GitOps, при которой конфигурация кластера описана декларативно и есть ровно один источник правды ― git с его историей версий и т. д. Но git не является достаточно доверенной средой для хранения секретов ― с его помощью мы не смогли бы обеспечить разделение доступов и т. п. Так что в следующей статье цикла мы рассказываем о том, как можно реализовать отдельное хранилище секретов, без которого полноценно перейти на GitOps невозможно.