DevOps *

В очередном сборнике из недавних кейсов в нашей практике расскажу, как мы продлевали root-сертификаты Let's Encrypt для старой CentOS, боролись с внезапным переключением DNS и Ingress, решали непростую задачу с шардами в Elasticsearch и не только.

В этом году DevOps & TechLead Conf 2022 пройдут на одной площадке. Участников ждут погружение в инженерные процессы в IT (от XP до devOps & beyond), musthave-инструменты и практики изменений в командах для быстрых и качественных релизов.

Мы встретились с экспертами из Программного комитета конференций — Дмитрием Зайцевым и Анастасией Асеевой-Нгуен. Поговорили о болях DevOps-инженеров и техлидов, о новых форматах и о самых актуальных темах в индустрии. О том, что получилось — читайте под катом.

Хотелось бы поделиться "граблями", на которые успел наступить при работе с docker, интересными фишками и вообще рассказать про эту замечательную технологию.

Настройка cервера с помощью docker для простых проектов. Инструкция для самых маленьких. Часть вторая: docker-compose.

Мы продолжаем цикл обучающих статей для самых маленьких наших читателей. В данном обучении мы бы хотели разобрать docker-compose. Данная статья рассчитана на начинающих системных администраторов. Если вы являетесь опытным администратором, можете смело пропускать данный материал. Она призвана объяснить простыми словами, что такое docker-compose. Не смотря на то, что тема уже достаточно подробно отражена в сети, мы решили подробно описать общие стандарты администрирования с нуля, поскольку регулярно получаем большое количество базовых вопросов от людей, так или иначе, связанных с нашей сферой. Целью статей не является показать как развернуть идеальное окружение, а лишь указать на нюансы в работе и защитить начинающих специалистов от базовых ошибок при настройке.

В этом посте будет описано практическое применение semantic-release для terraform модуля terraform-yandex-compute (Модуль Terraform, который создает вычислительные ресурсы в облаке Яндекса) c Github action.

А так же будет рассмотрено использование Pre-commit в Github action.

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

Представим ситуацию: решили вы повысить производительность информационной системы. Команда девелоперов для этой цели развернула новые ноды, добавила элементы ИС, зарелизила изменения, система работает эффективнее, и, казалось бы, все счастливы. Да только от радости забыли поставить новые элементы на мониторинг. Так и будете вы спокойно пить кофе, любуясь зелеными огоньками на экране рядом с каждым компонентом системы, пока разъяренные пользователи не cымитируют DDoS атаку на внешний интерфейс вашего хелпдеска, когда один из новых элементов откажет.

Sonatype Nexus — программный продукт, который представляет собой менеджер репозиториев для хранения артефактов. По умолчанию установка происходит без включенного SSL. В данной статье будет описана установка Sonatype Nexus в контейнере Docker с использованием Nginx в качестве обратного прокси сервера, а также будет рассмотрено получение бесплатного доменного имени на сайте freenom.com и создание SSL-сертификата при помощи службы Let’s Encrypt.

При настройке CI/CD для приложений мы в компании, как правило, используем Vault от HashiCorp. К тому же сами приложения зачастую используют Vault для хранения секретных данных. Но для того, чтобы начать использовать Vault, сначала необходимо произвести его настройку. Раньше нам приходилось вручную производить подобные манипуляции для каждого проекта, что отнимало немало времени. Найти готовый модуль, который подошел бы нам, не удалось. Поэтому мы написали свой terraform-модуль, который позволяет автоматизировать данный процесс.

На текущий момент созданный нами terraform-модуль покрывает все наши требования, но в дальнейшем он будет дорабатываться. Модуль позволяет создавать политики доступа и хранилища секретов, включать необходимые способы авторизации (certs, jwt, oidc, kubernetes и т.д.), создавать токены, jwt/oidc/token-роли и идентификационные группы. Также при помощи него можно генерировать TLS-сертификаты и jwt ключи в определенной директории.

Настройка LEMP сервера с помощью docker для простых проектов. Часть первая: База

Мы продолжаем цикл обучающих статей для начинающих системных администраторов. В серии "Настройка LEMP сервера с помощью docker для простых проектов" мы разберем docker и docker-compose, рассмотрим, как поднять стек LAMP+Nginx с помощью docker, а также расскажем вам, в чем преимущество контейнеризации и виртуализации.

Старт любого нашего проекта начинается с подготовки инфраструктуры. Времени на это порой уходит довольно много. Как минимум необходимо нарезать виртуалки или донастроить Kubernetes, настроить CI, базы данных, логирование, мониторинг и прочие компоненты. В лучшем случае в этих заботах проходит несколько дней, а ни строчки кода еще не написано. Знакомая ситуация?

Эта история началась весной 2021 года.

Я много работал с Docker-контейнерами под Windows и страдал.

Страдал от того, как медленно запускается Docker Desktop.

Страдал от того, сколько он ест оперативной памяти.

Страдал от того, что постоянно что-то ломалось при обновлениях.

Страдал от того, что на Windows Server надо устанавливать Docker через какой-то особенный механизм, не работающий через proxy и не работающий на Windows Server 2016. Причём в связи с тем, что Docker Inc. передала enterprise-сервис компании Mirantis, этот способ через какое-то время вообще перестанет работать. В результате вы получаете Docker, собранный из непонятно каких исходников. Всё, что про них известно — они точно не такие, как в Docker Desktop. Вообще, для инструмента, задача которого — просто скачать один единственный пакет и установить его, в трекере задач этого проекта на удивление много багов.

Страдал от того, что Docker Desktop прекратил поддержку Windows 10 LTSC 2019, которая продолжает поддерживаться Microsoft вплоть до 2024 года (а расширенная поддержка — аж до 2029).

И я спросил себя: а почему, за что, как так? Есть ли какая-то такая фундаментальная причина, по которой софт, решающий эту задачу, обязан доставлять столько неудобств? И не нашёл её. 

А потому подошел к проблеме по принципу: если тебя что-то не устраивает, сделай это лучше.

После чего быстренько придумал название проекту и создал репозиторий.

Привет, Хабр! Сергей Бондарев, архитектор Southbridge и спикер в Слёрме, недавно провёл вебинар «Kubernetes'22: выбор между self-hosted и managed-решением». Сегодня публикуем текстовую версию вебинара.

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

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

Стандартную восьмерку DevOps вы все видели, вот она.

Данная статья посвящена настройке и работе с Docker Swarm.

Swarm это стандартный оркестратор для docker контейнеров, доступный из «коробки», если у вас установлен сам docker.

Что нам потребуется для освоения:

Этой ночью представят новую версию Kubernetes. Удаление Dockershim — если не самое значимое, то уж точно самое обсуждаемое изменение в релизе 1.24. Также среди интересных нововведений: «мониторинг здоровья» томов; Network Policy Status для оценки состояния подресурсов; набор тестов, с помощью которых определяется готовность Windows-кластеров к production.

В обзоре рассказываем обо всех улучшениях — новых (alpha) и о тех, что перешли на уровень выше (beta, stable).

Репутационные и денежные риски, связанные с уязвимостями, огромны. На фоне этого понятен повышенный интерес к безопасности и стремление выстроить цикл безопасной разработки (SSDLC). Сегодня мы поговорим об одном из подходов, используемых в SSDLC, – SAST.

Смотри, ты устроился работать в большую компанию, где много команд, каждая разрабатывает свой продукт, часть из них создаёт микросервисы вокруг ядра, часть создаёт свои отдельные полноценные продукты. И, допустим, вся разработка до сих пор не использует централизованное хранение кода, работает без CI/CD и без наработок DevOps. Твоей первой задачей поставили организовать подход к хранению исходного кода в рамках всей компании. По секрету скажу, большие компании любят, когда используется единый подход, индивидуализм для бизнес-конвейеров всегда означает сложность управления сроками разработки, поставки и т.д. Задача, которая кажется простой на первый взгляд, всегда обрастает сложностями в нюансах.

Ты настроен на волну NotOps и в этой статье я постараюсь ответить на вопросы:

Последнее время появилась острая необходимость проверять, что прилетело с очередными обновлениями кода в папку /vendor /venv или любую другую, где лежат исходники внешних зависимостей проекта. (poetry, composer, go install и тд., кто на чем пишет).

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

Часть задач сводится к тому, чтобы найти определенный текст, ключевые слова, хардкод (например ip адрес) или опасный системный вызов. В голову сразу приходит grep. Но мы же хотим не только искать по одному слову и только в одном или группе файлов. Мы хотим проверить весь код по всем возможным словарям, которые определим сами.

Помогая пользователям NGINX с разрешением проблемных ситуаций, мы поняли, что большинство из них часто совершает одни и те же ошибки конфигурации. Более того, подобные ситуации вполне могут возникнуть даже у самих инженеров NGINX! В этой статье рассмотрим 10 наиболее распространенных ошибок и объясним как их исправить.

1. Недостаточное количество файловых дескрипторов;
2. Директива error_log off;
3. Отсутствие keepalive-соединения с вышестоящими серверами;
4. Упущение механизмов наследования директив;
5. Директива proxy_buffering;
6. Неправильное использование директивы if;
7. Чрезмерные проверки работоспособности;
8. Незащищенный доступ к метрикам;
9. Использование ip_hash, когда весь трафик поступает из одного и того же блока /24 CIDR;
10. Игнорирование преимуществ вышестоящих групп.