DevOps *

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

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

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

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

Эти источники позволяют выбрать наиболее подходящий подход к обучению и материалы для своего учебного процесса. Некоторые из них включают в себя курсы по Docker, Kubernetes, Ansible, Jenkins, Git и другим инструментам, необходимым для успешной работы в области DevOps.

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

В статье я собрал большой список курсов, книг, репозиториев и ресурсов, которые помогут вам стать DevOps-инженером🧑‍💻.

💬 На самом деле, моя идея написания тестов на архитектуру настолько проста, легко реализуема и при этом полезна, что я до сих пор толком не понимаю, почему я не встречал материалов на эту тему, и сама тема всё ещё не используется повсеместно 🙂
Статья написана по следам моих докладов на трёх крупных ИТ-конференциях, на каждой из которых ко мне подходили архитекторы и разработчики российских бигтехов, говорили, что я очень точно попал в их боли и предложил суперпрактику, которую они теперь будут внедрять. На всех трёх конференциях я получил высшие оценки от аудитории, а на двух из них доклад был признан лучшим в своей секции. В конце статьи приведена ссылка на видео доклада с одной из конференций.
В статье я поделюсь своей идеей и OpenSource-реализацией решения для написания тестов, разберу примеры тестов на небольшой учебной микросервисной архитектуре, а также расскажу про личный опыт и профит от применения этой практики.
Для разработчиков монолита тоже есть небольшой бонус: в OpenSource-репозитории появилась реализация и примеры тестов на архитектуру модульного монолита.

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

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

Опыт и карьера складываются из маленьких кирпичиков. Иногда, только они и формируют движение по пути в профессии. Запрос на «большие» цели или проекты без «работы» по маленьким целям, может быть опасным и иногда недостижимым путем.

Это вторая статья из цикла «Взаимодействие ИТ и ИБ». Первую статью можно прочитать здесь.

Зачем ИБ-шникам ИТ-системы?

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

Часто выходит так, что ИТ и ИБ-подразделения пользуются схожим инструментарием в части ИТ-систем. А иногда и не просто схожим, одинаковым. В результате чего могут возникать непримиримые противоречия и неутихающие споры, нередко заканчивающиеся чем-то вроде холодной войны между департаментами.

Если вам доводилось использовать HAProxy для балансировки трафика, вы наверняка как минимум слышали, что этот продукт умеет отслеживать показатели активности сервиса и пользователей и реагировать на них по предопределённым условиям. Обычно в статьях на эту тему приводится пример ограничения пользователя по исходному IP-адресу, если частота запросов с него превышает некоторый предопределённый заранее лимит. Вот, к примеру, такая статья с сайта разработчиков.

Я бы хотел немного углубиться в тематику использованного механизма stick tables, но поговорить не про пользователей, активно интересующихся вашим сайтом, а про нагрузочную способность, или ёмкость, всего сайта (ну или каких-то его путей). Во-первых, любой сервис ограничен в количестве одновременных запросов, которые возможно обслужить на существующих ресурсах. Во-вторых, чаще всего у сервиса не одна площадка или хотя бы не один экземпляр балансёра. А это значит, что поймать одинокого пользователя — это, конечно, здорово, но хотелось бы решить и другую интересную задачу: защитить сервис от перегрузки в целом и в случае, если балансёров более одного. Бонусом поговорим о проблеме умного перераспределения нагрузки между локациями.

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

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

Первым шагом dBrain.cloud на пути к построению кластеров большого объема стало разделение etcd. Далее мы взялись за controller-manager.

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

Чтобы не изобретать велосипед, мы решили рассмотреть известные операторы, позволяющие разворачивать базы данных PostgreSQL в Kubernetes и управлять ими.

Приветствую всех читателей. В данной публикации или инструкции хочу максимально подробно разложить "со своей колокольни разумеется" вопрос установки (MTA MDA) сервера.

Наши ресурсы:

Платформу для выполнения задачи взял из маленького одноплатного компьютера Odroid C1+ на базе Ubuntu 20 версии, купленный домен на хостинге в нашем случае medianet.pp.ua, статический ip адрес от интернет провайдера.

Постановка задачи:

Установка операционной системы Linux Ubuntu не ниже 18.04 LTS или что‑то Debian подобное.

Привет всем! На одном из проектов нам потребовалось внедрить непрерывную интеграцию и доставку CI/CD. Поиск готового решения показал, что все наши потребности может закрыть GitLab CI. Однако GitLab - платный продукт и на момент принятия решения возникли некоторые трудности с его коммерческим использованием. Поиски альтернативы не увенчались успехом, и было принято решение создать CI/CD своими силами из имеющихся OpenSource-инструментов.

Недавно мы закончили работу и получили завершенную платформу, которую можно использовать, как готовый инструмент с выстроенной непрерывной интеграцией и доставкой CI/CD и/или для перевода инфраструктуры в микросервисную архитектуру, согласно концепции инфраструктура как код IaC.

В данной серии статей мы хотим рассказать о нашем пути, этапах работы и компонентах платформы.

Вот мы и подобрались к самому интересному: запуску Kubernetes в Kubernetes. В этой статье мы поговорим о таких технологиях, как Kamaji и Cluster API, а также о том, как интегрировать их с KubeVirt.

В прошлых статьях мы уже рассказывали, как мы готовим Kubernetes на bare metal, и о том, как превратить Kubernetes в средство запуска виртуальных машин. Эта статья завершает серию, объясняя, как, используя всё вышеперечисленное, можно построить полноценный managed Kubernetes service и запускать виртуальные Kubernetes-кластеры по клику.

И начнём мы, пожалуй с Cluster API.

Считается, что построение CI/CD - задача для DevOps. Глобально это действительно так, особенно если речь идет о первоначальной настройке. Но часто с докручиванием отдельных этапов процесса сталкиваются и разработчики. Умение поправить что-то незначительное своими силами позволяет не тратить время на поход к коллегам (и ожидание их реакции), т.е. в целом повышает комфорт работы и дает понимание, почему все происходит именно так.

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

Ранее мы делали обзор инструментов для оценки безопасности кластера Kubernetes. Но что, если нам нужно обучить инженеров основам безопасности Kubernetes на реальных примерах и автоматизировать этот процесс? Недавно компания ControlPlane, специализирующаяся на Cloud Native-решениях, помогла решить этот вопрос. Она выложила в открытый доступ Simulator — инструмент для обучения инженеров поиску уязвимостей в Kubernetes. Мы во «Фланте» решили протестировать этот симулятор и понять, насколько он перспективен и полезен.

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

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

Хочется рассказать о нашем опыте внедрения CI/CD в компанию. О том, как в целом работать с ним и как это работает у нас.

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

Приятного прочтения, всем peace!

Kubernetes в большинстве случаев является стандартом де-факто, когда мы выбираем оркестратор контейнеров. Развернув Kubernetes в облаке, мы получаем возможность масштабировать рабочие ресурсы по мере необходимости при помощи Kubernetes cluster autoscaler механизма. Karpenter был представлен re:Invent 2021 как продукт с открытым исходным кодом, который подходит к процессу масштабирования k8s кластеров по-другому в сравнении с ClusterAutoscaler.