👨‍💻 Технический долг под прикрытием

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

Плюсы feature flags:

+ Можно включать и выключать функции в любое время, даже после деплоя.

+ Возможность быстро отключить нерабочую или багованную функциональность без полного отката.

+ Поддержка A/B тестирования и постепенного развертывания.

+ Код можно внедрять «в тёмную», активируя позже.

Минусы feature flags:

- Неочищенные флаги превращают код в сложный для понимания и поддержки.

- Флаги в разных окружениях могут рассинхронизироваться и приводить к неожиданным багам.

- Изменения через UI платформ часто не отражаются в Git, что мешает отслеживанию.

- Управление токенами и доступом часто организовано недостаточно строго.

- Платформы не всегда хорошо вписываются в существующие CI/CD процессы.

- Масштабирование и цены могут вырасти непредсказуемо.

💬 Как думаете, фича флаги это мастхев или без них намного лучше? Делитесь мыслями в комментариях 👇

🐸Библиотека devops'a #междусобойчик

💾 Когда GitOps не справляется

GitOps становится всё более популярным для автоматизации развертывания и управления инфраструктурой через Git. Как и с любым новым подходом — возникают вопросы.

Недавно один из наших подписчиков поднял интересный вопрос:

GitOps утверждает, что все изменения должны быть в Git, но как быть с настройками и инфраструктурой, которые трудно или невозможно описать в коде?

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

Несколько способов решения этой проблемы:

1. Используйте инструменты типа Terraform или Ansible для настройки. Они могут работать параллельно с GitOps, обеспечивая гибкость.

2. Для чувствительных данных используйте хранилища секретов, чтобы избежать хранения паролей в Git.

3. Сочетайте GitOps для приложений с традиционными методами для специфических конфигураций.

Не обязательно строго придерживаться концепции, если она не позволяет эффективно работать.

💬 Как решаете проблему нестандартных конфигураций? Делитесь своими методами в комментариях 👇

🐸Библиотека devops'a #междусобойчик

📣 Какой контент реально нужен девопсу

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

Многие считают, что девопсам нужно погружаться в глубокие технические темы — гайды по внедрению Terraform, Kubernetes, настройки сетевой инфраструктуры и AWS, потому что все с этим работают.

С другой стороны огромные гайды про AWS и другие облачные сервисы могут и не иметь смысла, если в реальности с ними работали единицы.

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

💬 Что думаете вы? Какой контент нужен настоящему девопсу, а какой это просто пыль в глаза незнающим, чтобы они думали, что всё так сложно? Делитесь мыслями в комментариях 👇

🐸Библиотека devops'a #междусобойчик

📎 Когда пайплайн — это просто уведомления

Подписчик поделился с нами историей о том, как он пришёл в команду, где были «готовые» пайплайны. На первый взгляд автоматизация настроена и можно спокойно работать. Но оказалось, что не всё так просто.

История подписчика:

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

Когда разработчики ставили определённые сервисы, то в один из чатов приходило уведомление, спустя минут 15-20 разработчик писал мне и говорил, что у него не ставится сервис. Я начал разгребать что там такое.

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

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

💬 Были у вас странные наработки? Делитесь выходками своими или своих коллег в комментариях👇

P.S. Если хотите задать вопрос сообществу или поделиться историей, заполните нашу гугл-форму.

🐸Библиотека devops'a #междусобойчик

👀 Тест на внимание для DevOps

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

💬 Делитесь результатами, но не раскрывайте все секреты сразу!

🐸Библиотека devops'a #междусобойчик

✏️ CMD vs ENTRYPOINT

Один из подписчиков недавно задал интересный вопрос:

Когда лучше использовать CMD, а когда ENTRYPOINT в Docker?

Эти два параметра могут запутать, но их применение зависит от того, как вы хотите запустить контейнер.

1️⃣ ENTRYPOINT — основная команда контейнера

Если вам нужно задать команду, которая всегда будет выполняться при запуске контейнера, используйте ENTRYPOINT.

Он задает команду, которая является обязательной для запуска контейнера, и её нельзя переопределить (без указания дополнительных аргументов).

Пример:

ENTRYPOINT ["python", "app.py"]

В этом случае контейнер всегда будет запускать python app.py

2️⃣ CMD — параметры по умолчанию

CMD — это параметры, которые могут быть переданы командной строкой при запуске контейнера.

Если CMD используется в Dockerfile, но команда не была указана при запуске контейнера, то используется команда из CMD. Он также может быть переопределен во время запуска.

Пример:

CMD ["python", "app.py"]

Но если вы хотите передать другие параметры, например:

docker run my_image python other_app.py

То CMD будет переопределен.

3️⃣ Комбинированное использование

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

Пример:

ENTRYPOINT ["python"]
CMD ["app.py"]

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

Используйте CMD, если хотите задать параметры по умолчанию, которые можно переопределить при запуске контейнера.

Используйте оба вместе, чтобы задать команду с возможностью замены параметров.

💬 А какие у вас есть примеры использования CMD и ENTRYPOINT? Поделитесь своим опытом в комментариях 👇

🐸Библиотека devops'a #междусобойчик

📣 Как правильно называть окружения

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

— Сторонники англоцентричной схемы

Prod / Pre-prod / Staging / Dev

Стандартизировано, «понимают» все инструменты CI/CD и внешние подрядчики.

Очевидный минус для русскоязычной команды — англицизмы раздражают, к тому же споры о дефисах и транслитерации («preprod» vs «pre-prod») могут затянуться.

— Сторонники русификации

Бой / Пром / Тест / Разраб.

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

💬 Что думаете вы? Какие аргументы перевесили в ваших проектах — «Prod» или «Бой»? Разверните своё мнение в комментариях 👇

🐸Библиотека devops'a #междусобойчик

💬 Кубер это революция в управлении инфраструктурой или ненужная сложность

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

⚠️ Основные претензии к Kubernetes:

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

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

— Сетевые и распределенные проблемы в Kubernetes могут быть сложными для диагностики.

Что думает наш админ:

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

💬 Какая ваша позиция по поводу Kubernetes? Супер-пупер игрушка или ненужный хлам? Делитесь мыслями в комментариях 👇

💃 Нравится контент? Отблагодарите нас бустом, а мы подготовим больше годного контента.

🐸Библиотека devops'a #междусобойчик

🧩 Эмодзи-ребус

Сегодня мы загадали то, что мы проводим не так часто. Что изображено на картинке? Пишите догадки в комментариях 👇

🐸Библиотека devops'a #междусобойчик

🛡 100.000 записей уже утекло и ещё 200.000 на подходе

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

Один из подписчиков недавно спросил:

Бывали ли у вас утечки данных или секретов? И как вы их обнаружили?

Чтобы помочь вам системно подойти к защите, рассмотрим ключевые шаги:

• Ведение централизованного доступа к секретам (Vault, AWS CloudTrail).

• Настройка алертов на аномалии: резкий рост числа запросов, доступ в нерабочие часы.

• Принцип наименьших привилегий: выдача минимальных прав сервисным аккаунтам.

• Автоматическое сканирование репозиториев на «вшитые» пароли и токены.

• Пост-инцидентный анализ (post-mortem) с документированием причин и уроков.

💬 А у вас были случаи утечек? Как вы их обнаружили и какие меры приняли? Поделитесь в комментариях 👇

Небольшая история от админа:

На нашем последнем проекте как-то раз один разработчик по-быстрому затащил в репозиторий приватный токен для тестового API прямо в коде. Никто этого не заметил, пока вечером в прод не пришёл шквал аномальных запросов.

С тех пор у нас в CI работал сканер git-secrets, и больше никто не позволяет себе «быстренько вставить» секреты в код.

P.S. Если хотите задать вопрос сообществу или поделиться историей, заполните нашу гугл-форму.

🐸Библиотека devops'a #междусобойчик

📣 Фоновые задачи в Linux: что использовать

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

*️⃣cron — проверенная классика

• Простота настройки через crontab, знакома всем администраторам.

• Минимальные зависимости — работает практически на любом дистрибутиве.

• Ограниченное управление: нет «жёстких» гарантий запуска при простоях системы, сложнее отлавливать ошибки и собирать логи.

⏲️ systemd-таймеры — современный подход

• Единая точка управления сервисами и таймерами, интеграция с journalctl.

• Расширенные возможности: запуска по событиям, автоматический перезапуск, контроль зависимостей.

• Зависимость от systemd — не подходит для систем с альтернативными init-системами.

✏️ Специализированные планировщики (Jenkins, Rundeck, Apache Airflow)

• Гибкость оркестрации сложных рабочих процессов, визуальные интерфейсы, сложные зависимости между задачами.

• Централизованное управление, уведомления, отчётность и интеграции с разными системами.

• Повышенные накладные расходы на установку, настройку и сопровождение сервера планировщика.

💬 Какой инструмент для фоновых задач используете вы? Ждём вас в комментариях👇

🐸Библиотека devops'a #междусобойчик

💵 Виртуальные ошибки стоят реальных денег

Когда ты работаете в стартапе, всегда есть ощущение, что «мы справимся». Но когда начинается работа с облачными провайдерами, такие вещи могут привести к большим расходам.

Один из наших подписчиков поделился своей историей:

Работая в стартапе, я столкнулся с неожиданными расходами в DigitalOcean. Как-то раз я заметил, что наш счёт был значительно выше, чем ожидалось, и был в шоке, когда увидел итоговую сумму. Ошибки в конфигурации одного из наших облачных серверов.

💬 Вопрос к тем, кто работал не на своём железе — как это предотвратить? Делитесь своими способами, вдруг это спасёт чей-нибудь кошелёк 👇

P.S. Если хотите задать вопрос сообществу или поделиться историей, заполните нашу гугл-форму.

🐸 Библиотека devops'a #междусобойчик