DevOps *

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

Сегодня мы расскажем о том, как подходили к созданию сообщества практики по автоматизации DevOps CI/CD в Сбере. Рассмотрим предпосылки, методологии и лучший мировой опыт, который использовали, а также ключевые проблемы и ошибки. В этой статье опытом делится Рашид Галиев – руководитель группы развития методологии DevOps и внедрения инженерных практик CI/CD, эксперт команды ядра сообщества DevOps в Сбере.

Начну с цифр и предпосылок: у нас порядка 16000 инженеров разных ролей и областей экспертизы, около 3000 продуктовых команд, большое количество систем со своим независимым релизным циклом и достаточно много внедрений в месяц.

DevOps-инженер Константин Кулишов рассказал, как создал свой ChatOps, чтобы дать разработчикам возможность вносить изменения в проект в любое время. Константин выложил ChatOps на GitHub и подробно описал процесс создания.

В этой серии постов я хотел бы поговорить о Linux Page Cache. Я считаю, что данные знания теори и инструментов жизненно необходимы и важны для каждого SRE. Общее понимание как работает Page Cache помогает и в рутинных повседневных задачах, и в экстренной отладке на продакшене. При этом Page Cache часто оставляют без внимания, а ведь его лучшее понимание. как правило, приводит к:

- более точному планированию емкости системы и лимитов сервисов и контейнеров;
- улучшенным навыкам отладки приложений, интенсивно использующих память и диски (СУБД и храанилища данных);
- созданию безопасных и предсказуемых сред выполнения специальных задач, связанных с памятью и/или вводом-выводом (например: сценарии резервного копирования и восстановления, rsyncоднострочники и т.д.).

Я покажу, какие утилиты вы можете использовать, когда имеете дело с задачами и проблемами, связанными с Page Cache, как правильно к ним подходить, и как понять реальное использование памяти.

Добрый день, сегодня мы развернем serverless инфраструктуру на базе AWS lambda для загрузки изображений (или любых файлов) с хранением в приватном AWS S3 bucket. Использовать мы будем terraform скрипты, залитые и доступные в моем репозитории kompotkot/hatchery на GitHub.

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

В целях упрощения мы воспользуемся функционалом Bugout.dev Resources, в нашем примере выполняющий функцию удаленной базы данных для хранения записей о принадлежности файла к заметки.

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

Это мое личное мнение основанное на десятке лет работы с различными системами конфигураций и двухлетнего периода миграции 200+ ролей с Ansible на SaltStack.

Сотни статей уже было написано про сравнение таких систем как Puppet, Chef, Ansible и SaltStack. У каждой из них есть своя ниша и серебряной пули не существует. Эта статья не ставит целью сделать очередное сравнение, которое устареет через ~6 месяцев. Мне скорее хочется показать вам несколько фундаментальных отличий между этими системами.

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

Зачем собирать образ с помощью Packer?

1. Время создания инстанса из готового образа значительно меньше, чем время, которое нужно затратить с нуля на подготовку виртуальной машины к работе. Это достаточно критичный момент, так как порой очень важно ввести в работу новый инстанс нужного типа за кратчайшее время для того, чтобы начать пускать на него трафик.
2. Помимо того что образ виртуальной машины для DEV, TEST, Staging окружений, он всегда будет соответствовать по набору ПО и его настройкам тому серверу, который используется в production. Важность этого момента трудно недооценить — крайне желательно, чтобы деплой нового кода на продакшн привел к тому, чтобы сайт продолжал корректную работу с новой функциональностью, а не упал из-за какой-то ошибки, связанной с недостающим модулем или отсутствующим ПО.
3. Автоматизация сборки production- и development-окружений экономит время системного администратора. В глазах работодателя это также должно быть несомненным плюсом, так как это означает, что за то же время администратор сможет выполнить больший объем работы.
4. Время для тестирования набора ПО, его версий, его настроек. Когда мы подготавливаем новый образ заранее, у нас есть возможность (и, что самое главное, время!) для того, чтобы спокойно и вдумчиво проанализировать различные ошибки, которые возникли при сборке образа, и исправить их. Также есть время для тестирования работы приложения на собранном образе и внесения каких-то настроек для оптимизации приложений. В случае же, если мы настраиваем инстанс, который нужно было ввести в работу еще вчера, все возникающие ошибки, как правило, исправляются по факту их возникновения уже на работающей системе — конечно же, это не совсем правильный подход.

DevOps-инженеры компании inDriver Радик Сейфуллин и Александр Плотников распилили старое монолитное приложение и создают новое, а Евгений Бутырин, технический редактор Слёрма, пообщался с ребятами об этом: опыте с Kafka, проблемах, решениях и обучении. 

В статье хочу познакомить читателя с идеей, что образы docker - это такие же простые приложения, как apt пакеты. А утилита DAM (Docker Application Manager) - пример их пакетного менеджера.

Статья может быть полезна:
- тем, кто работает с docker на автономных системах или с ограниченным доступом к интернет;
- кому нравится идея - один пакетный менеджер для разных архитектур и операционок;
- кто пробует запихать свое легаси с linux дистрибутива в контейнеры и контролировать его обновление;
- или интересна тому, кто просто проектирует микросервисные архитектуры

Введение

Когда я устанавливаю Vault в Kubernetes, я держу в голове, что очень важно иметь возможность сделать автоматическое распечатывание(Auto-Unseal), чтобы кластер Vault был по настоящему высокодоступным.

В моей предыдущей статье "Highly available Vault cluster in Kubernetes" (ссылка), несмотря на то, что я изо всех сил пытался сделать кластер Vault максимально доступным, без автоматического распечатывания кластер Vault мог бы выдержать частичный отказ подов, но не пережил бы перезагрузку всего кластера.

В этой статье хорошо объяснено, почему это произошло. Для меня проблема заключается в том, что я не пользуюсь "службой AWS KMS", которую можно было бы использовать, или подобной службы безопасности от "облачного" провайдера, потому что я управляю Kubernetes на self-hosted "облаке" (в этой статье объясняется моя настройка).

В Vault версии 1.1 добавлена поддержка "Transit Auto Unseal", которая заключается в использовании второго Vault кластера B для автоматического распечатывания (Auto-Unseal) кластера А.

Итак, вот идея: развернуть 2 кластера Vault A и B и настроить их так, чтобы они делали автоматическое распечатывание друг для друга.

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

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

Для этого используют обычный print() но по стандарту ограничен одной консолью, или loggin() но его нужно относительно дольше настраивать, чем проект console-debugger, по причине того что нужно указывать файл, стиль вывода даны в файл, рейтинг обработки, в ручную запускать слежение за файлом, в ручную закрывать слежение за файлом, когда вам больше не нужен обработчик.

Я понимаю плюсы лорнирования но они не подходят для дебаггинга ...

В прошлой статье я рассказал как собрать CI часть пайплайна непрерывной поставки CI/CD на базе Azure DevOps Pipelines для Microsoft Dynamics CRM. Сегодня же поговорим о CD (Continuous Deployment) части.

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

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

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

Привет, Хабр! Немного запоздало (ко дню программиста) делюсь подборкой бесплатных книг по программированию. Все они полезные, уровень скорее профессиональный, хотя и для развития от базового тоже подойдет, но, к сожалению, на английском. Среди тем книг: .NET, Алгоритмы, Android, iOS, Angular, C, C++, C#, JS, Linux, Python. В целом, найдется почти любая тема, которая приходит в голову.

Дисклеймер. Все эти книги взяты с одного ресурса, который существует за счет донейшенов. Получить книги можно без осуществления донейшенов, ресурс полностью бесплатный, пожертвования опциональны. Все книги написаны на основе контента со StackOverflow и являются код-ориентированными. Книги со временем обновляются. По ссылкам -- книги, актуальные на 15.09.2021.

Kubernetes стал стандартом для запуска микросервисных (и не только) приложений. Компании разных размеров — от стартапов до enterprise — стараются проектировать свои приложения готовыми для запуска в Kubernetes-кластере.

А для запуска приложения в K8s обычно используют Helm-шаблоны с описанием манифестов. Хотя формат шаблонов легко читается и прост в изучении, он может вызвать определенные сложности, когда логика деплоя приложения разрастается, когда создаются дополнительные тестовые контуры (с деплоем только отдельных частей приложения) и т.д. При активном использовании Go-шаблонов рефакторинг манифестов может превратиться в нетривиальную задачу*.

Что делать, если у разработчиков нет времени разбираться со всеми тонкостями Helm-шаблонов, синтаксисом YAML и Go templates, но нужно запустить приложение в Kubernetes? Ответом на этот вопрос может стать использование cdk8s.

Если вы, как и я, отвечаете за успешный запуск критически важных приложений, помогающих бизнесу быть на передовой в цифровой трансформации, то, несомненно, поймете, о чем пойдет речь в этой статье. Для руководства такой миссией, помимо навыков проектирования архитектуры, требуются также навыки менторинга и управления инженерными ресурсами, а также контроль работы бизнес-аналитиков, выявляющих требования. Эти навыки в значительной степени детерминированы и управляемы по сравнению с другими, необходимыми для обеспечения надежной и безопасной работы приложений. Из-за этого разработчиков часто противопоставляют администраторам инфраструктуры и специалистам по информационной безопасности, считая их "последней миле" на пути к запуску приложения. Но у администраторов и "безопасников" возникают следующие проблемы:

Мы активно деплоим свои приложения в Kubernetes и используем HTTP-пробы для сервисов. Однако решили провести эксперимент с exec-пробами и… положили на лопатки кластер! Как так? Ведь именно exec пробы первыми описываются во всех руководствах и книгах по Kubernetes, включая официальные! Что же не так?

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

Всем привет!

Сегодня я хотел бы поделиться опытом настройки AWS Auto Scaling Group (ASG) на основе использования оперативной памяти (RAM).

Всё началось с того, что на одном из проектов нам понадобилось настроить масштабирование EC2-инстансов по использованию памяти, а стандартный ASG Target Tracking Scaling Policy позволяет создавать политики только на основе следующих метрик: среднее использование ЦПУ, средний входящий или исходящий сетевой траффик и количество запросов на цель ALB...

Недавно в своей работе начал практиковаться с Hadoop, Spark и Hive от Apache на примере организации распределенного хранилища данных в крупном и сложном проекте. Так как я хорошо дружу с Linux и вселенной Docker, только одна команда позволит не мучиться с лишней установкой Big Data-решении от Apache, не нагружая при этом свою Linux-машину(при наличии Docker и Docker-Compose).

Фото Florencia Viadana, Unsplash.com

После почти пятилетних разработок протокол HTTP/3 наконец приближается к окончательному выпуску. Предыдущие итерации уже доступны как экспериментальная функция, но в 2021 году мы ждём широкого распространения протокола. Что такое HTTP/3? Зачем выпускать его так рано после HTTP/2? Как его можно или нужно использовать? Как он влияет на производительность?

Когда мы в Tarantool столкнулись с задачей настройки мониторинга для сдачи проекта заказчику, мы решили её с помощью grafonnet. Это библиотека для написания дашбордов Grafana с помощью кода на языке jsonnet, которая заметно облегчила нам жизнь.

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