PyCharm плагин: Combine and Copy Files to Clipboard. Отличный инструмент для DevOps и K8S инженеров.

Когда работаешь с конфигурациями или управляешь инфраструктурой, часто сталкиваешься с ситуацией, когда необходимо быстро поделиться фрагментами кода или конфигураций с коллегами, либо передать структуру проекта для дальнейшего анализа. Плагин Combine and Copy Files to Clipboard для PyCharm стал для меня настоящим спасением в этих задачах.

В чем его сила?

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

Вот как это работает:

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

Простой пример:

Представьте, что у вас есть несколько файлов с конфигурациями Kubernetes или CI/CD пайплайнов. Вместо того, чтобы вручную копировать каждый файл и объяснять, где он находится в проекте, плагин Combine and Copy Files to Clipboard делает это за вас. Он собирает файлы, добавляет их содержимое в один блок и позволяет вам легко делиться этим с коллегами или использовать при работе с AI-инструментами, такими как ChatGPT.

Это действительно "Over Powered" инструмент для тех, кто хочет эффективно управлять своими задачами, не тратя время на рутину.

Мой опыт:

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

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

Цена:
- 30 дней бесплатно
- 1 USD/month после 30 дней

Книга Kubernetes in Action (2nd edition by Marko Lukša, Kevin Conner) — отличный старт для знакомства с Kubernetes

Когда я начал читать книгу Kubernetes in Action, сразу понял — это не просто теория. Автор делает акцент на понятном объяснении того, что такое Kubernetes, как он работает и почему его популярность так стремительно выросла. Честно говоря, я был впечатлен уже с первых страниц.

Что мне особенно понравилось

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

Теперь давайте разберем основные идеи первых глав (1.1 Introducing Kubernetes - 1.2 Understanding Kubernetes), которые привлекли мое внимание.

---

Введение в Kubernetes: Зачем это нужно?

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

Причем, как отмечает автор, имя Kubernetes символично. Как штурман направляет корабль, так Kubernetes направляет ваше приложение, оставляя за вами только ключевые решения.

---

Почему Kubernetes стал таким популярным?

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

---

Как Kubernetes решает повседневные задачи?

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

---

Основные компоненты Kubernetes

Автор подробно объясняет архитектуру Kubernetes, разделяя её на две главные плоскости: Control Plane и Workload Plane. Control Plane управляет состоянием всего кластера, а Workload Plane — это место, где запускаются приложения. Все выглядит логично, и благодаря иллюстрациям с каждым компонентом становится легче разобраться.

---

Личный опыт

Для меня этот материал стал отличным введением в тему. Книга Kubernetes in Action помогает понять не только теоретические основы, но и показывает, как Kubernetes действительно работает на практике. А самое главное — автор делает это легко и доступно, с примерами и наглядными пояснениями. Если вы хотите погрузиться в мир Kubernetes — это идеальная отправная точка.

От себя же я составил Mind Map первых двух частей, которым хотел бы поделиться в этом посте (пока что ссылкой на dropbox)

- https://www.dropbox.com/scl/fi/9fv5og1cchp44kofi9h0p/Kubernetes-in-Action-till-1.3.pdf?rlkey=vus4tw7vsrqf15naerns2x12v&st=6miusxfn&dl=0

Обзор следующих частей опубликую очень скоро🛥

SubStack: https://open.substack.com/pub/beops/p/kubernetes-in-action-2nd-edition?r=4g03ic&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

Всем привет! 🎉

Добро пожаловать на канал BeOps! Здесь я разбираюсь с DevOps, Kubernetes и разными инфраструктурами, делая сложные задачи простыми и доступными.

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

👉 BeOps Substack: https://beops.substack.com/
👉 TalkOps Apple Podcast: https://podcasts.apple.com/us/podcast/talkops/id1771206180
👉 BeOps Linkedin: https://www.linkedin.com/in/be-ops-54062132b/
👉 Medium: https://medium.com/@beops.it
👉 YouTube: https://www.youtube.com/@BeOps

Собеседование в Yandex Cloud: Консоль и траблшутинг

Хочу поделиться впечатлениями о втором собеседовании в Yandex Cloud, которое я недавно прошел. Эта секция называлась “Консоль и траблшутинг” и была посвящена навыкам работы в командной строке, пониманию операционных систем и способам диагностики различных проблем. Интересный момент — секция была без кодинга, и мне не пришлось сидеть и писать питон.

Интервьюер оказался настоящим ветераном — 12 лет работы в Яндексе, и общение сразу настроилось на легкую волну. Как и на первом этапе, все прошло в приятной атмосфере, говорили на “русско-айтишном”. Начали с привычного SSH-коннекта на яндексовскую машину, после чего я приступил к первому заданию.


Парсинг логов Nginx
Первое задание выглядело знакомо: нужно было распарсить Nginx логи. Довольно стандартная задача: нужно было посчитать все успешные (код ответа 200) и неуспешные ответы. К слову, это была уже третья такая задача за последние полгода.

Я использовал grep (https://man7.org/linux/man-pages/man1/grep.1.html) с регулярными выражениями, чтобы подсчитать успешные ответы:
grep ' HTTP/[0-9.]* 200 ' access.log | wc -l

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

Затем нужно было найти самые частые URL в логе. Мой любимый инструмент для таких задач — awk (https://linux.die.net/man/1/awk). В паттернизированном логе легко можно сосчитать когда появляется путь (типа /authenticate или /set/fflzuns), Подсчитать количество повторений каждого уникального URL (uniq -c), отсортировать его и вывести например 3 самых частых пути
awk '{print $6}' access.log | sort | uniq -c | sort -nr | tail -n 3

Определение типа системы
Следующий вопрос был интереснее: мне нужно было определить, виртуальная машина это, физическая или контейнер. Начал я с проверки файла /proc/1/cgroup, который иногда содержит информацию о контейнеризации, но файл оказался пустым. Тогда я использовал hostnamectl (https://man7.org/linux/man-pages/man1/hostnamectl.1.html), и вывод показал, что это виртуалка. Вывод выглядел примерно так:

 Static hostname: ixx
       Icon name: computer-vm
         Chassis: vm
  Virtualization: xen

Мы дальше исследовали какие процессоры стоят на даной машине и я использовал lscpu (https://man7.org/linux/man-pages/man1/lscpu.1.html).

Диагностика производительности
Дальше по накатанной был разговор про производительность системы (top/atop/laod averages/free/vmstat), процессы (ps -ef) и виды процессов. Я не смог развернуто ответить про статус процессов (Zombie, Sleep, Uninterrupted sleep, etc.) но думаю, что однажды я пойму эту концепцию до конца.
Найдя огромные load average values и только лишь один процесс который отжирает половину ядра (потому что top показывает процент на ядро, а не на все ядра) мне пришлось ответить на кажущийся простым вопрос - так что же нагружает систему. Я предположил что это какие то интенсивные IO операции и мы макнулись в прекрасный мир iostat (https://linux.die.net/man/1/iostat). Тула предназначенная для мониторинга статистики ввода-вывода (I/O) и загрузки процессоров (CPU) в Unix-подобных операционных системах. С ее помощью я смог понять что на сервере огромный %iowait, то есть процент времени CPU, когда он ожидал завершения операций ввода-вывода.


Финал: Исследование неизвестного сервиса
Финальная задача была исследовать неизвестный сервис (назовем его mi-service), который занимался операциями записи и чтения на диск. Я использовал systemctl для проверки статуса службы, но это не дало результата, поэтому я переключился на анализ логов в /var/log/mi-service. Именно там я нашел нужную информацию о работе демона (ну вы поняли) и выяснил, какие порты он использует, с помощью netstat -tuln (https://linux.die.net/man/8/netstat).

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

Оптимизация использования ConfigMap для NGINX в Kubernetes

Недавно я столкнулся с проблемой в одном из своих Kubernetes проектов, где nginx.conf в подах не обновлялся после сборки и деплоя Docker-образа, несмотря на изменения в конфигурацию. Проблема оказалась в том, что Kubernetes использовал ConfigMap для управления конфигурацией NGINX, а конфигурация в Docker-образе просто игнорировалась.

Решение проблемы и оптимизация процесса навели на размышления о том, как правильно управлять конфигурациями в Kubernetes и Docker. В этом посте я расскажу, как убрать избыточные шаги в Dockerfile и правильно работать с конфигурацией через ConfigMap.

---

Почему ConfigMap важен?

Прежде чем мы углубимся в изменения Dockerfile, давайте разберемся, зачем вообще нужен ConfigMap. Kubernetes использует ConfigMap для хранения и управления конфигурациями контейнеров. Это позволяет обновлять конфигурацию приложений без необходимости пересобирать Docker-образы и перезапускать все приложение целиком. Это особенно удобно в ситуациях, когда конфигурация может меняться в зависимости от среды (например, dev, staging, production), а сам код остается неизменным.

Проблема: Зачем копировать nginx.conf в Docker, если есть ConfigMap?

Изначально мой Dockerfile копировал nginx.conf в образ:

# Копирование конфигурационного файла nginx.conf
COPY nginx/nginx.conf /etc/nginx/nginx.conf

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

Решение: Удаление лишнего копирования из Dockerfile

Чтобы избавиться от дублирования и оптимизировать процесс сборки, я обновил Dockerfile, удалив строку, которая копирует nginx.conf. Теперь конфигурация управляется только через Kubernetes.

Вот как выглядит финальный Dockerfile после исправлений:

FROM nginx:1.21.6

# Удаляем ненужные конфигурации, которые могут вызвать конфликты
RUN rm -f /etc/nginx/conf.d/* /etc/nginx/snippets/*

# Обеспечиваем наличие каталога для SSL-сертификатов
RUN mkdir -p /etc/nginx/ssl && chmod -R 755 /etc/nginx

# Копируем только необходимые HTML-файлы для нашего приложения
COPY html/index.html /usr/share/nginx/html/index.html
COPY html/index2.html /usr/share/nginx/html/index2.html

# Устанавливаем права на выполнение для точки входа, если это необходимо
RUN chmod +x /docker-entrypoint.sh

Почему это решение лучше?

1. Избежание дублирования конфига. Теперь конфигурация NGINX управляется исключительно через ConfigMap. Это позволяет обновлять конфигурацию без пересборки Docker-образа.

2. Упрощение CI/CD-процессов. Теперь процесс деплоя становится более гибким, так как для внесения изменений в конфигурацию NGINX не требуется заново собирать образ. Достаточно обновить ConfigMap и перезапустить поды.

3. Поддержка среды без изменения кода. ConfigMap позволяет легко адаптировать конфигурацию под разные среды (например, использовать одну конфигурацию для development и другую для production) без необходимости изменения Docker-образа.

Как обновить ConfigMap и перезапустить поды?

После внесения изменений в конфигурацию NGINX, необходимо обновить ConfigMap:

kubectl delete configmap nginx-config
kubectl create configmap nginx-config --from-file=nginx/nginx.conf

После этого достаточно перезапустить деплоймент:

kubectl rollout restart deployment nginx-deployment


Теперь NGINX будет использовать обновленную конфигурацию из ConfigMap.

---

Личный опыт

Эта ситуация показала мне, как важно избегать дублирования конфигурации между Docker и Kubernetes. Благодаря такому подходу удается упростить процесс обновления конфигурации и сделать деплой более гибким. Если в вашем проекте активно используется Kubernetes, стоит обратить внимание на использование ConfigMap для управления конфигурациями, а не встраивать их в Docker-образы.

Надеюсь, этот пост был полезен для тех, кто работает с Docker и Kubernetes и стремится оптимизировать свои CI/CD процессы.

Книга Kubernetes in Action (2nd edition by Marko Lukša, Kevin Conner) - продолжаем знакомиться с книгой.

Я продолжаю изучать K8S и углубился в вопрос контейнеров. Дальше обзор второй главы книги которая мне дала понять очень много теории из мира контейнеров.

📦 Что такое контейнеры и зачем они нужны в Kubernetes?

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

🤔 Зачем нужны контейнеры?

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

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

🔮 Контейнеры vs Виртуалки: в чем разница?

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

💪 Отмечаем преимущества:

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

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

🐧 Важные технологии Linux, которые делают контейнеры возможными

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

Контейнеры существуют благодаря функциям ядра Linux. Основные технологии, которые обеспечивают работу контейнеров, включают:

- Namespaces: Эта функция позволяет каждому процессу видеть только свою собственную версию файлов, процессов и сетевых интерфейсов. Благодаря этому контейнеры изолированы друг от друга. Какие бывают типы namespaces? Вот тут я был сильно удивлен.
- Mount namespace (mnt): Отвечает за изоляцию точек монтирования файловых систем. Процесс, работающий в отдельном mount namespace, видит только те файловые системы, которые смонтированы внутри этого пространства имен. Это означает, что контейнеры могут иметь свои собственные файловые структуры, даже если они используют один и тот же хост.
- Process ID namespace (pid): Изолирует идентификаторы процессов. Каждый контейнер имеет свой собственный набор PID, что позволяет избежать пересечения с процессами других контейнеров или хоста. Процессы внутри контейнера видят только те процессы, которые принадлежат этому контейнеру, что повышает безопасность и управляемость.
- Network namespace (net): Изолирует сетевые интерфейсы, IP-адреса, порты и сетевые стеки. Это позволяет каждому контейнеру иметь свой собственный виртуальный сетевой интерфейс, а также выделенные IP-адреса и маршруты. Благодаря network namespaces контейнеры могут взаимодействовать с сетью так, как будто они работают на разных физических машинах.
- Inter-process Communication namespace (ipc): Изолирует механизмы межпроцессного взаимодействия, такие как очереди сообщений и разделяемая память. Это помогает избежать утечек данных и нежелательного взаимодействия между процессами разных контейнеров.
- User namespace (user): Позволяет контейнерам иметь собственные пользовательские и групповые идентификаторы. Это важно для обеспечения безопасности, так как процессы могут работать от имени root внутри контейнера, но быть обычными пользователями на хосте.
- UTS namespace: Отвечает за изоляцию имени хоста и доменного имени системы. Это дает контейнеру возможность иметь собственное имя хоста, создавая впечатление, что он работает на отдельной машине.
- Time namespace: Позволяет контейнеру иметь собственные настройки системного времени, что может быть полезно для тестирования и других специфических сценариев.
- Cgroups (Control Groups) - это механизм в ядре Linux, который позволяет ограничивать, отслеживать и изолировать использование ресурсов (таких как процессор, память, дисковый ввод-вывод и сеть) для каждого процесса или группы процессов. Cgroups особенно важны для контейнеров, так как они обеспечивают разделение ресурсов и предотвращают ситуации, когда один контейнер потребляет все доступные ресурсы системы. Вот как Cgroups управляют основными ресурсами:
- Ограничение использования процессора: Cgroups позволяют ограничить использование процессорного времени контейнером. Это может быть реализовано двумя способами:
- cpusets: позволяет выделить конкретные ядра процессора для использования контейнером.
- CPU shares: распределение процессорного времени между контейнерами на основе относительных весов. Например, если контейнеру A назначено 1024 «доли» CPU, а контейнеру B — 512, то A получит в два раза больше процессорного времени, чем B.
- Ограничение памяти: Cgroups позволяют задавать жесткие лимиты на использование оперативной памяти контейнером. Если контейнер превысит лимит, то Linux может начать «вытеснять» данные из памяти в swap (если он разрешен) или даже завершить контейнер для освобождения памяти. Например, можно установить ограничение, чтобы контейнер использовал не более 1 ГБ памяти.
- Ограничение сетевых ресурсов: Позволяет ограничивать использование сети контейнером. Это может быть полезно для предотвращения перегрузки сетевого интерфейса одним контейнером, если несколько контейнеров работают на одном сервере.
- Ограничение дискового ввода-вывода: Cgroups могут ограничивать скорость операций чтения и записи на диск для каждого контейнера. Это предотвращает ситуации, когда один контейнер может замедлить систему, выполняя интенсивные операции ввода-вывода.

🐳 Docker: Как он упростил работу с контейнерами

Хотя контейнерные технологии существуют уже давно, популярными они стали благодаря Docker. Docker упростил процесс создания, распространения и запуска контейнеров на разных системах.

- Images - это то, что содержит приложение и все его зависимости. Docker позволяет создавать образы, которые могут запускаться на любой системе с установленным Docker.
- Registries (e.g. Docker Hub) — это публичный репозиторий для хранения и распространения контейнерных образов.

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

Когда вы запускаете контейнер через Docker, это по сути процесс, который изолирован от других процессов на вашей системе. При этом Docker гарантирует, что контейнер видит только те ресурсы, которые ему разрешены.

🔐 Безопасность и изоляция контейнеров (Cgroups и неймспейсы были не всё!)

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

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

⚓️ Как Kubernetes управляет контейнерами?

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

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

❓Добавлю FAQ раздел (для TL;DR публики)

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

2. Почему контейнеры быстрее виртуальных машин? Контейнеры не требуют запуска полноценной операционной системы, поэтому они стартуют практически мгновенно.

3. Как Docker изолирует контейнеры с помощью ядра Linux? Docker использует функции ядра Linux, такие как namespaces и cgroups, чтобы изолировать процессы и ресурсы для каждого контейнера.

4. Какие риски связаны с контейнерами? Главный риск — это общая операционная система для всех контейнеров. Если в ней есть уязвимость, один контейнер может потенциально повлиять на другие.

5. Как Kubernetes управляет контейнерами? Kubernetes автоматизирует развертывание, управление и масштабирование контейнеров, что делает управление большими системами с множеством микросервисов значительно проще.

Плюс, по классике, mind map 1-3 частей этой великолепной книги тут:

- https://www.dropbox.com/scl/fi/afeuq65sb7wxc2mzvpgud/Kubernetes-in-Action-till-3.pdf?rlkey=2f88qx4he5880b8vb594uv4h4&st=ltge2a9u&dl=0

Опять этот git…Интересный проект на кистартере: Карточная колода с командами Git

Девченка из Молдовы стартовала интересный проект на Kickstarter — .dot, Dev Cheatsheet: Git. Это карточная колода, созданная для помощи разработчикам (особенно джунам) в изучении команд Git. Основная цель — сделать процесс обучения легким и увлекательным.

Что это за проект?

.dot, Dev Cheatsheet: Git — это набор из 56 карточек, каждая из которых содержит полезные команды Git, советы и минималистичный дизайн, чтобы помочь освоить этот инструмент. Основные функции Git довольно просты, но он так же может быть сложным и громоздким если мы начнем пользоваться всем функционалом. Кароче, с удобными визуальными подсказками обучение будет точно проще.

Что входит в набор?

- 16 карт с командами Git — карты с описаниями основных команд Git и иллюстрациями для быстрой ссылки и легкого запоминания.
- 2 Джокера — включают основные сведения о Git и GitHub.
- 2 дополнительных карты с паттерном — двусторонние карты с дизайном, который соответствует задней стороне колоды.
- 36 стандартных игровых карт — карты с командами Git, их определениями и примерами использования.

Почему стоит поддержать этот проект?

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

Цена и сроки

Начальная цена на Kickstarter составляет 20 евро. Оплата будет списана только в случае успешного завершения кампании, а доставка начнётся в декабре 2024 года.

Перейти на страницу проекта на Kickstarter

Неделя выдалась очень загруженной и крайне регрессивной из-за апдейтов macOS. Об этом и будет этот пост боли. 😢

Мой проект использует инфраструктуру, описанную в Terraform , с поддержкой нескольких облачных провайдеров (в данном случае — Azure и GCP). Вся конфигурация логично разделена по типам окружений и элементам инфраструктуры, типа такого:

- общие элементы которые описывают схожие для обоих облаков элементы
    - GCP
        - dev
            - 00-folders
            - 01-projects
            - 02-iam
            - 03-network-firewall
            - 04-compute
            - 0…storage, logging, gke, dnz zones, secrets, etc.
        - prod
            - mirror from dev
        - etc.
    - Azure
        - dev
        - prod

Особенно удобно использование terraform_remote_state, который позволяет держать снимки инфраструктуры в облачных хранилищах и использовать их для описания дальнейших ресурсов.
- https://developer.hashicorp.com/terraform/language/state/remote-state-data

Я могу описать GCP folders (о них больше инфы можно найти здесь https://cloud.google.com/resource-manager/docs/creating-managing-folders) и потом хранить ”снимок” этой части инфры в GCP bucket. Дальше, когда я буду описывать проекты которые будут находиться в этих папках (https://cloud.google.com/resource-manager/docs/creating-managing-projects), я смогу использовать terraform_remote_state. Например так

resource "google_folder" "development" {
  display_name = "development"
  parent       = var.root_folder_id
}

resource "google_folder" "development_barebone" {
  display_name = "development-barebone"
  parent       = google_folder.development.id
}

При переходе к описанию проектов можно извлечь идентификаторы папок через terraform_remote_state:

module "dev_bb_project" {
  source  = "terraform-google-modules/project-factory/google"
  version = "14.3.0"

  folder_id = data.terraform_remote_state.dev_folders_remote_data.outputs.development_barebone_folder_id
}

Однако радость закончилась, когда вышло обновление macOS 15.0 (Sequoia 🌲). С новой функцией управления сетевыми режимами начались серьезные проблемы с подключением к удаленному состоянию в GCP. Вот пример ошибки:

Error: error loading state: Failed to open state file at gs://infrastructure/dev/01-dev-projects/default.tfstate:
Get "<https://storage.googleapis.com/infrastructure/dev/01-dev-projects/default.tfstate>": local error: tls: bad record MAC

или

Error: Error when reading or editing Project "development-71b9": 
Get "https://cloudresourcemanager.googleapis.com/v1/projects/development-71b9?alt=json&prettyPrint=false": oauth2: cannot fetch token: 
Post "https://oauth2.googleapis.com/token": net/http: TLS handshake timeout

или

error loading the remote state: Failed to open state file at gs://infrastructure/dev/00-dev-folders/default.tfstate: Get "https://storage.googleapis.com/infrastructure/dev/00-dev-folders/default.tfstate":
oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token":
unexpected EOF

После долгих попыток — смены сетей, регенерации сервисных аккаунтов, повторных настроек — проблема оставалась. Лишь работа на старых машинах с macOS 14 показала, что проблема явно связана с апдейтом операционной системы. Ошибки касались TLS-соединений, OAuth-токенов и таймаутов на уровне сетевого стека. 🛜

Оказалось что Apple добавила новую функцию для управления сетевыми режимами, направленную на “улучшение” конфиденциальности при подключении к Wi-Fi сетям:

1. Off (отключено): В этом режиме устройство использует стандартный аппаратный MAC-адрес без изменений. Этот режим обеспечивает максимальную стабильность при работе с сетевыми сервисами, но может использоваться для отслеживания устройства.
2. Fixed (фиксированный: При выборе этого режима ваше устройство использует приватный MAC-адрес, который не меняется при подключении к одной и той же сети. Это компромисс между конфиденциальностью и стабильностью. Этот режим подходит для использования с защищенными сетями (например, WPA2), и он выбран по умолчанию.
3. Rotating (ротация): В этом режиме MAC-адрес устройства изменяется каждые две недели. Это нацеленное на повышение конфиденциальности решение может вызывать проблемы с сервисами, которые требуют стабильности сетевых настроек, как в случае с Terraform. При подключении к сетям с низким уровнем безопасности этот режим выбирается по умолчанию.

Эти новые режимы оказывают влияние на такие системы, как Terraform, поскольку смена MAC-адреса или проблемы с TLS могут нарушать работу инфраструктурных сервисов. В моем случае это привело к тому, что удаленное состояние не загружалось должным образом, а подключение к GCP сервисам периодически прерывалось. Даже переключение между сетевыми режимами не помогло устранить проблему.

Решение 🧩

К счастью, решение оказалось простым: Apple выпустила обновление macOS 15.1, которое устранило проблему. Вся проблема была только в том что я потратил 3 дня на изолирование этой проблемы и документирование ресерча сей.

После обновления всё снова заработало как раньше:

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

Этот опыт — яркий пример того, как системные обновления могут ломать даже базовые вещи. Плюс, пострадали не только Terraform-проекты: разработчики также жалуются на проблемы с SSL, VPN, и RDP. Надеюсь, Apple учтет эти нюансы в дальнейших апдейтах, чтобы избежать таких сюрпризов.

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

- macOS 15.0 SSL проблемы: https://forums.sketchup.com/t/macos-15-0-sequoia-ssl-problems/291274
- VPN и RDP проблемы после обновления: https://www.securityweek.com/cybersecurity-products-conking-out-after-macos-sequoia-update/

Третье интервью в Yandex Cloud: Python и траблшутинг

После двух успешных раундов интервью в Yandex Cloud, пришло время для третьего, и вот что мне удалось пройти.

Python задача: поиск подотрезков

Интервью началось с классической задачи по Python. Мне дали массив, состоящий из нулей и единиц, и нужно было найти максимальную длину подотрезка, состоящего из единиц, при условии удаления одного элемента. Пример:

assert maxOnes([1, 1, 0, 1]) == 3
assert maxOnes([1, 1, 0, 0, 1]) == 2

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

def maxOnes(arr):
    n = len(arr)
    max_len = 0
    zero_count = 0
    left = 0
    
    for right in range(n):
        if arr[right] == 0:
            zero_count += 1
        
        while zero_count > 1:
            if arr[left] == 0:
                zero_count -= 1
            left += 1

        max_len = max(max_len, right - left)
    return max_len

Усложнение: удаление произвольного числа нулей

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

def maxOnesWithKDeletions(arr, k):
    n = len(arr)
    max_len = 0
    zero_count = 0
    left = 0

    for right in range(n):
        if arr[right] == 0:
            zero_count += 1
        
        while zero_count > k:
            if arr[left] == 0:
                zero_count -= 1
            left += 1

        max_len = max(max_len, right - left + 1)
    return max_len

Разбор алгоритмов

Мы обсудили временную сложность обоих решений и, что неожиданно для меня, заговорили о Big O для памяти vs процессора. Я предположил, что первое решение использует O(1) памяти, так как мы обрабатываем элементы на месте, а второе — O(n), где n — длина массива. Про сложность по процессору я не помню что ответил, но интервьюер одобрительно покачал головой.

Траблшутинг бинарников

Дальше перешли к траблшутингу, что, честно говоря, было для меня более привычно.

1. Бинарник app1 не запускается
Начал с проверки exit code с помощью echo $? — код возврата был 1, что говорит о какой-то ошибке. Далее применил strace для отслеживания системных вызовов программы. Оказалось, что бинарник пытался записать данные в файл app1.txt, но по ошибке был создан файл app11.txt. После создания правильного файла бинарник запустился.
2. Проблема с app2 (EADDRINUSE)
Программа app2 не запускалась из-за того, что порт 8080 уже был занят. Команда ss -tuln :8080 помогла найти процесс, который занимал этот порт — это оказался Nginx. Я завершил процесс с помощью sudo kill -9.
3. Ошибка “Too many open files” в app3
Лимит на количество открытых файлов в системе оказался 4097, а программа пыталась открыть 4098 файлов. С помощью ulimit -n я увеличил этот лимит до 10000, и программа успешно запустилась.

Финальная задача: очистка файлов

Последняя задача состояла в том что в папке есть почти несчетное кол-во файлов и нужно было удалить только те, что размер имеют от 2 до 4 кб. Загвоздка была в том что размеры эти были включительные, то есть я не мог указать 2K / 4K и дропнуть их. Я воспользовался man find и с подсказкой интервьюера, обнаружил что там есть флаг (который по сути больше как суффикс) с - который используется для более точного контроля над размером файлов. Я перевел 2 и 4 КБ в байты и исполнил такую команду
find /path/to/garbage -type f -size +2047c -size -3073c -delete
Файлы были успешно удалены.

После этого меня попросили удалить оставшиеся файлы в несколько потоков, для чего я использовал xargs:

ls | xargs -0 -P 4 rm -f

Итоги

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

Теперь жду приглашения на следующий раунд!

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

Почему?

Тестирование сетевого подключения с помощью curl в одноразовом поде полезно, когда нужно проверить доступность других подов. Например, если приложение не может достучаться до другого сервиса, или подозреваете проблемы с сетевыми правилами. Даже если сеть работает корректно, всегда стоит проверить доступность напрямую.

Пример команды

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

kubectl run --image=curlimages/curl -it --restart=Never --rm client-pod curl 10.244.2.4:8080

Эта команда создаёт под, запускает в нем curl, проверяет соединение с сервисом по IP и порту, а затем удаляет под. Это полезно тем, что под создается только для выполнения теста и сразу удаляется, не занимая ресурсы кластера.

Кейсы использования

1. Тестирование доступа между подами. Когда приложение пытается подключиться к другому сервису, но соединение по какой-то причине не проходит. Например, после настройки NetworkPolicy, нужно убедиться, что поды действительно могут общаться друг с другом. В таких случаях удобно запустить одноразовый под с curl и проверить доступность.
2. Отладка сетевых проблем. В случае, если сервис не доступен, используя одноразовый под, можно быстро проверить, проблема ли в приложении или в сетевой инфраструктуре (например, проблемный ingress, firewall, или ошибки в конфигурации сервисов).

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

Product Manager разруливает спринтовые таски

Иногда приходится забрать файл из контейнера или закинуть туда что-то свое, и тут на помощь приходит команда kubectl cp. В продакшене, конечно, так особо не поиграешь, но в разработке — вполне себе полезный трюк.

Как это работает

Представьте, вы нашли баг в своем HTML-файле, который под обслуживает. Вроде бы и мелочь, но пересобирать образ лень. Вместо этого вы просто вытаскиваете файл:

kubectl cp service:/html/index.html /tmp/index.html

Правите его локально, возвращаете обратно:

kubectl cp /tmp/index.html service:/html/

И обновляете страницу.

Когда пригодится?

1. Экономия на пересборке образа: Все мы знаем, как это бывает: нашел проблему в конфигурации или статику обновить надо, а Dockerfile уже видит, как его пересобирают в десятый раз за день. Не беда! Просто скопируйте файл, поправьте его, и без лишних танцев с образами верните обратно в контейнер.
2. Лог-файлы — это золото: Логи — это как черный ящик самолета, если что-то пошло не так. Но зачем ломать голову над тем, как их достать, если можно просто взять и скачать их на локальную машину с помощью kubectl cp. Это как будто на минуточку заглянули в контейнер, чтобы забрать нужные документы.

И только один нюанс: контейнер должен дружить с tar. Если вдруг нет — что ж, будет повод его подружить!

⏰ Интересный концепт для прокрастинаторов (точно не про меня)

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

1. YouTube Addiction Rehab

Это расширение для Chrome фильтрует ваши интересы и отсеивает мусорные рекомендации. Цель — оставить в ленте только полезные видео и избавить от «тёмных кроличьих нор», куда YouTube любит затягивать. Отлично подходит для тех, кто хочет осознанно управлять своим временем и не поддаваться на алгоритмические соблазны.

2. BlockTube

Более продвинутое решение для тех, кто хочет вручную настроить свой YouTube. BlockTube даёт возможность:

• Блокировать видео и каналы по названию
• Исключать комментарии на основе ключевых слов или имени автора
• Убирать YouTube Shorts и фильмы
• Прятать просмотренные видео из рекомендаций
• Настраивать фильтры по длительности роликов
• И даже отключать раздражающие всплывающие окна «Видео приостановлено, продолжить просмотр?»

Для правильных пацанов есть поддержка regex📜 и возможность интегрировать JavaScript-функции для кастомной блокировки.

Ссылки на расширения:

• YouTube Addiction Rehab
• BlockTube

В итоге, если YouTube всё-таки затягивает, эти инструменты могут стать отличным решением.