Docker подробно рассказали про атрибут include — он уже сейчас доступен в Docker Compose v2.20.0 и появится в грядущем релизе Docker Desktop 4.22

🅰️ Командная строка docker поддерживает множество флагов для точной настройки контейнера и трудно запомнить их все при репликации среды. Сделать это еще сложнее, когда приложение представляет собой не отдельный контейнер, а комбинацию многих контейнеров с различными отношениями зависимостей. Именно поэтому Docker Compose быстро стал популярным инструментом.

Тем не менее, проблема сохраняется для больших приложений, использующих десятки, а может быть, и сотни контейнеров, с распределением прав собственности между несколькими командами. При использовании монорепозиториев команды часто имеют свой собственный “локальный” Docker Compose file для запуска подмножества приложения, но тогда им нужно полагаться на то, что другие команды предоставят справочный файл Compose, который определяет ожидаемый способ запуска их собственного подмножества.

Эта проблема не нова и обсуждалась в 2014 году, когда Docker Compose был совсем новым проектом. Теперь мы внедрили возможность “compose compose files” — не прошло и 10 лет! 🅱️

📌 Спецификация Compose, раздел про include

#новости

Всем DevOps! 🖖

Хочется порекомендовать отличный блог про инфраструктуру, платформы, Linux, Open Source, DevOps, Kubernetes, контейнеризацию и облака. А еще автор пишет про Python, Go и shell.

Начать знакомство можно, например, со статьи «Kubernetes Taints, Tolerations, and Understanding the PreferNoSchedule Effect» — в ней говорится про эффект PreferNoSchedule в Kubernetes и его отличия от NoExecute и NoSchedule. Есть классная схема про принцип работы PreferNoSchedule.

Еще автор иногда пишет на смежные темы, например, заметка «12 Tips for Effective Technical Blogging». Вдруг вы ведете блог или просто пишете на Хабр? Будет полезно 😎

P.S. Кстати про технические блоги и Хабр! Может, здесь есть авторы? Расскажите о своих блогах в комментариях (ТГ, Хабр, что угодно) 🙃 Почему решили вести блог? А если вы не автор, можете рассказать — что вообще думаете о технических блогах? Почему не хотите писать сами?

Ну и, конечно, делитесь — кого читаете?

#блог

Открытое исследование «Защита персональных данных 2023» 🔒

За 2022-2023 год ужесточились условия и регулирование по 152-ФЗ.

На форумах мы слышим как всё меняется, но лозунги со сцен конференций и обновление ФЗ — это одна сторона медали, а реальная практика и опыт сообщества — совсем другая.

Компания Cortel проводит открытое исследование «Защита персональных данных 2023» чтобы выяснить:

• Как эксперты на местах смотрят на ситуацию;
• Как в действительности обстоят дела с ПДн и их защитой на практике.

Пожалуйста поделитесь своим мнением и пройдите короткий опрос на 3 минуты по этой ссылке, вы очень поможете.

🛡 Результатами исследования поделятся осенью в этом канале.

Всем DevOps! 🖖

В одной из рассылок (старый добрый email 🥰) была поднята интересная тема.

Итак, полторы недели назад инженер по машинному обучению написал анализ под названием «Падение Stack Overflow». Из собранных им данных и из данных, которыми делится StackOverflow с самой активной частью комьюнити, следует, что Stack Overflow потерял около 50% своего трафика. Впрочем оказалось, что данные о трафике не учитывают изменения в Google Analytics. С учетом этого падение составило бы 35%. Тем не менее, самая тревожная часть статистики — это не трафик, а снижение количества задаваемых вопросов и ответов.

Кажется, что падение Stack Overflow (и прочих подобных сайтов) связано с активным развитием AI-инструментов для написания кода (ChatGPT, Copilot и т.д.) — пользователи все больше отдают им предпочтение.

Автор рассылки связался со Stack Overflow, чтобы получить официальный комментарий и разобраться в ситуации.

В общем, можете посмотреть это письмо в Telegraph, ну и поделиться своим мнением в комментариях :)

Пользуетесь ли вы AI-инструментами для работы с кодом? Или просто для рабочих задач? А Stack Overflow — пользуетесь?

#статьи

Всем DevOps! 🖖

Сегодня хочется рассказать что-нибудь полезное. Решили поделиться советами. Потом по традиции соберем в один пост, чтобы сохранять было удобнее :) Погнали!

Как выбрать оптимальную архитектуру для вашего Kubernetes-кластера?

Вопрос, конечно, интересный. Управление Kubernetes-кластером — это не та задача, где есть одно правильное решение на все случаи жизни. Есть много способов оптимизации кластера и главное здесь — это обеспечение стабильной и отказоустойчивой работы приложений.

Выбор правильного размера ноды критичен для разработки масштабируемых приложений. Иметь множество маленьких нод или несколько больших — это две крайности. Для кластера, которому нужно всего 24Gb памяти и 12 CPU лучше выбрать 12 машин по 1-CPU/2GB или две по 6-CPU/12GB ?

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

Отказоустойчивость

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

Если у нас есть две больших воркер ноды и одна их них упадет, то мы потеряем половину всех ресурсов кластера. Если вы не предусмотрели 100% запас ресурсов, то это приведет к катастрофе, так как оставшаяся нода не сможет выдержать двойную нагрузку. Наличие множества воркеров снижает эти риски на n. К примеру, если у вас есть 10 нод в кластере и выключится одна, то вы потеряете только 10% от всей мощности кластера.

Победители: множество маленьких нод 🎉

Сложность управления

С большим количеством нод вам нужно будет заботиться о большем количестве серверов, их обновлении и обслуживании. Сократив количество нод их проще обслуживать. Как DevOps и SRE вы можете использовать такие инструменты как Ansible или Puppet, чтобы упростить эти процессы за счет автоматизации.

Если вы используйте managed Kubernetes-кластер, то ваш облачный провайдер будет патчить и обновлять ноды за вас. В итоге с современными инструментами этот пункт не дает существенного преимущества.

Победители: нет 🎉

Простота в распределении контейнеров

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

Победители: несколько больших нод 🎉

Нагрузка на kubelet

Kubelet отвечает за взаимодействие с нижележащим container runtime (движком для контейнеров) для запуска приложений на воркер нодах. Если вы запускаете множество контейнеров на одной ноде, что типично для кластеров с большими нодами, это может перегрузить kubelet, так как ему нужно будет оперировать большим количеством контейнеров.

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

Победители: множество маленьких нод 🎉

Нагрузка на систему

И наоборот, множество нод нагружают ваши мастер ноды, так как им нужно взаимодействовать со множеством воркер нод. Kubernetes не оптимизирован для работы более чем с 500 нодами на кластер (хотя они и пишут, что могут управлять до 5000 нод).

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

Победители: несколько больших нод 🎉

*️⃣1/3: продолжение следует :)

#лонгрид