<![CDATA[Комментарии / Профиль igorcoding]]> https://habr.com/ru/users/igorcoding/comments/ ru editor@habr.com habr.com Sun, 26 Apr 2026 02:24:15 GMT https://habr.com/ru/ https://habrastorage.org/webt/ym/el/wk/ymelwk3zy1gawz4nkejl_-ammtc.png Хабр 01.11.2024 12:41:01 https://habr.com/ru/companies/kts/articles/854750/#comment_27499004 https://habr.com/ru/companies/kts/articles/854750/#comment_27499004 Согласен, про то, что удобно скрыть реализацию и подменять в будущем, спасибо)

]]> Fri, 01 Nov 2024 12:41:01 GMT 01.11.2024 11:09:01 https://habr.com/ru/companies/kts/articles/854750/#comment_27498662 https://habr.com/ru/companies/kts/articles/854750/#comment_27498662 Хороший вопрос, спасибо!

Посмотрел сейчас по гиту - активно в репозиторий с Terraform контрбьютит примерно 30 человек, не считая DevOps-команду (так как обычно это все-таки заботит в основном бэкенд-разработчиков, то фронтендеры изредка что-то добавляют, что им нужно — например, S3-бакеты). В модули же контрибьютят только DevOps-инженеры, просто из-за изначальной идеи, что модули и их удобство - ответственность инфраструктурной команды, а создание компонентов - ответственность разработчиков.

А по поводу сроков ситуация следующая — отвечу подробнее. Мне чуть проще оценить именно сколько занимал раньше и занимает сейчас полноценный деплой проекта в прод. Раньше, когда еще даже мы не централизовали создание всех ресурсов в Terraform, выкатка могла занимать хоть целый рабочий день — когда ты забываешь, что тебе надо определенные настройки в базе провернуть, особенным образом настроить очереди в реббите (например, добавив HA и зеркалирование) — время растягивается.
И на самом деле первая задача, которую мы очень хотели решить — это именно создавать все ресурсы сразу "правильно" со всеми нужными настройками и правилами, поэтому и начали появляться модули.
Сейчас же, процесс выкатки до прода (при условии, что все регламентные вопросы решены) может варьироваться от нескольких минут до пары часов. Так как у нас (как я описал в статье) присутствует обязательный процесс ревью и апрува от девопсов — выкатка начинает зависеть от свободности инженеров сейчас и вот время реакции на несрочные MR в репозиторий с инфрой - около часа. Но естественно если нужно срочно — это все может эскалироваться и ускоряться, поэтому такая вариативность.

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

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

]]> Fri, 01 Nov 2024 11:09:01 GMT 06.08.2024 14:18:06 https://habr.com/ru/companies/kts/articles/833354/#comment_27134656 https://habr.com/ru/companies/kts/articles/833354/#comment_27134656 Обычно окружения поднимаются на домене, содержащим название ветки в git. То есть не произвольный коммит поднимается в качестве стенда, а именно ветка, либо тег.

]]> Tue, 06 Aug 2024 14:18:06 GMT 18.12.2023 12:10:04 https://habr.com/ru/companies/kts/articles/781310/#comment_26279136 https://habr.com/ru/companies/kts/articles/781310/#comment_26279136 Нет, чтобы разработчик разбирался не только в том как приложение написано, а еще в том, как это приложение запускать в реальном мире и совместно с DevOps командой принимать те или иные решения.

]]> Mon, 18 Dec 2023 12:10:04 GMT 06.12.2023 12:11:55 https://habr.com/ru/companies/kts/articles/775050/#comment_26236704 https://habr.com/ru/companies/kts/articles/775050/#comment_26236704 Это так же, как в victoria metrics можно писать метриками инфлюкса или statsd. То есть ставим любимый инструмент, например, Victoria Metrics или Grafana Mimir и пишем в него разными способами (системы порой бывают разнородные, поэтому приятно иметь возможность интегрировать существующую инфру с новым инструментом мониторинга)

]]> Wed, 06 Dec 2023 12:11:55 GMT 06.12.2023 11:48:54 https://habr.com/ru/companies/kts/articles/775050/#comment_26236596 https://habr.com/ru/companies/kts/articles/775050/#comment_26236596 Да, спасибо, поправил

]]> Wed, 06 Dec 2023 11:48:54 GMT 31.10.2023 15:35:30 https://habr.com/ru/companies/kts/articles/723980/#comment_26112312 https://habr.com/ru/companies/kts/articles/723980/#comment_26112312 Спасибо большое за ваш комментарий! 

Действительно, после глубокого изучения признаю, что тут была отражена не совсем корректная информация. В самом деле, компактор не занимается дедупликацией данных в S3. Этим занимаются сами инджестеры с использованием кешей (https://grafana.com/docs/loki/latest/operations/storage/boltdb-shipper/#write-deduplication-disabled).

Судя по всему данные действительно пишутся в нескольких копиях в S3 и дедуплицириуются уже только на квериерах - ссылка1 и ссылка2, сравнивая таймстемпы и тексты логов.

В статью также внес изменения. Еще раз спсаибо за замечание!

P.S. Прошу прощения, что только сейчас отвечаю — пропустил изначально.

]]> Tue, 31 Oct 2023 15:35:30 GMT 25.04.2023 15:50:16 https://habr.com/ru/companies/kts/articles/723980/#comment_25485894 https://habr.com/ru/companies/kts/articles/723980/#comment_25485894 Их можно форвардить напрямую в промтейл - https://grafana.com/docs/loki/latest/clients/promtail/configuration/#syslog, если я правильно понял вопрос.

]]> Tue, 25 Apr 2023 15:50:16 GMT 13.04.2023 09:18:42 https://habr.com/ru/companies/kts/articles/723980/#comment_25440992 https://habr.com/ru/companies/kts/articles/723980/#comment_25440992 Loki поддерживает 2 вида ретеншена - через table manager и через компактор. Ретеншн через table manager полагается на lifecycle policy в S3. Поэтому это обязательно (но при условии что включен непосресдтвенно ретеншн через table_manager). Это нужно для того, чтобы правильно очищались индексы. Иначе Loki может считать что чанки есть (потому что индекс на них ссылается), а по факту их нет - и может выливаться в ошибки при запросах.

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

Резюмируя, настраивать ретеншн нужно через один из двух механизмов - table manager или compactor. При этом для первого нужны lifecycle policy в S3 бакете. Полиси без настройки ретеншена могут привести к ошибкам в запросах.

]]> Thu, 13 Apr 2023 09:18:42 GMT 12.04.2023 12:49:00 https://habr.com/ru/companies/kts/articles/723980/#comment_25437634 https://habr.com/ru/companies/kts/articles/723980/#comment_25437634 Здравствуйте! Для управления временем хранения логов отвечает компактор. Вот тут подробная документация на эту тему - https://grafana.com/docs/loki/latest/operations/storage/retention

]]> Wed, 12 Apr 2023 12:49:00 GMT 16.08.2022 11:40:55 https://habr.com/ru/companies/kts/articles/682062/#comment_24635036 https://habr.com/ru/companies/kts/articles/682062/#comment_24635036 Получается нужно все равно вешать лейблы на неймспейсы? Это нас как раз не устраивало в том же kubed - хотелось просто описать регулярку, под которую должны попадать нс-ы, чтоб сикрет в них прилетал.

]]> Tue, 16 Aug 2022 11:40:55 GMT 14.08.2022 11:49:14 https://habr.com/ru/companies/kts/articles/682062/#comment_24628328 https://habr.com/ru/companies/kts/articles/682062/#comment_24628328 Не рассматривали, спасибо за ссылку. Правда не до конца понимаю, как с помощью kyverno в данном случае решить наш сценарий - чтобы Secret копировался только в нужные неймспейсы, а не во все?

]]> Sun, 14 Aug 2022 11:49:14 GMT 14.08.2022 11:47:15 https://habr.com/ru/companies/kts/articles/682062/#comment_24628320 https://habr.com/ru/companies/kts/articles/682062/#comment_24628320 Так мы ведь и выписываем wildcard сертификаты. В статье описывается подход как скопировать выписанный сертификат между неймспейсами, где он нужен.

]]> Sun, 14 Aug 2022 11:47:15 GMT 13.08.2022 13:52:43 https://habr.com/ru/companies/kts/articles/682062/#comment_24626368 https://habr.com/ru/companies/kts/articles/682062/#comment_24626368 Можете пояснить вопрос? Где именно не подошел kustomize?

]]> Sat, 13 Aug 2022 13:52:43 GMT 13.08.2022 13:52:09 https://habr.com/ru/companies/kts/articles/682062/#comment_24626366 https://habr.com/ru/companies/kts/articles/682062/#comment_24626366

  • Да, я согласен, что в kubed есть возможность синхронизировать secret или configmap по всем неймспейсам сразу. Но это не подходит для нас. Для нас важно было копировать TLS-сертификат между неймспейсами "текущего" проекта. То есть, например, есть проект A и он раскладывается по веткам на домены main.projectA.example.com, feature-1.projectA.example.com, feature-2.projectA.example.com и т.д. Сертификат для *.projectA.example.com должен быть выпущен в единственном экземпляре (мы условились что будем это делать для ветки main) и в остальные фича-бранчи сертификат должен быть скопирован. А каждая фича-бранч раскладывается в отдельном неймспейса, поэтому нужно уметь указать в какие нс копировать. Ну и нам этот сертификат не нужен, например в неймспейсах для проекта B. Поэтому в общем единственный возможный сценарий использования kubed - это прослатвлять лейблы на нс, а это затруднительно для нас было.

  • Спасибо за ссылку!

  • Согласен, пока просто такого сценария у нас не возникало, но добавить можно, спасибо.

    • ]]>     Sat, 13 Aug 2022 13:52:09 GMT     03.02.2022 21:16:23 https://habr.com/ru/companies/kts/articles/646207/#comment_24028871 https://habr.com/ru/companies/kts/articles/646207/#comment_24028871 Все же GIL мешает запускать потоки из питона. Понятно, что всегда можно всегда на си запустить тред, но во-первых это просто сложнее, во-вторых все равно нет возможности иметь доступ к питонячьим объектам - чтобы к ним обратиться нужно захватить GIL. Отсутствие GIL решает эти проблемы. Да, напишем числодробилку на чем-то производительнее (C, Cython, что угодно), но использовать это будет сильно проще.

    ]]>     Thu, 03 Feb 2022 21:16:23 GMT     03.02.2022 10:32:04 https://habr.com/ru/companies/kts/articles/646207/#comment_24026243 https://habr.com/ru/companies/kts/articles/646207/#comment_24026243 Возможность скейлиться по ядрам - самое главное. Условно запустить веб-сервер, который будет использовать все мощности сервера, а не довольствоваться однопоточным asyncio. Сейчас для эмуляции подобного нужно запускать несколько реплик приложения и балансировать между ними. При этом очевидные минусы - это то, что у нас раздельная память у процессов, доп проксирование и т.д.

    Также отсутствие GIL позволит не бояться cpu-intensive задач, то есть можно будет просто создать в питоне прям поток, подробить числа в фоне. Сейчас единственный выход - это multiprocessing со своими очевидными минусами.

    ]]>     Thu, 03 Feb 2022 10:32:04 GMT     07.12.2021 10:43:43 https://habr.com/ru/companies/kts/articles/593599/#comment_23794509 https://habr.com/ru/companies/kts/articles/593599/#comment_23794509 Спасибо за комментарий! Отвечу по пунктам

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

    2. Да, в разделе про недостатки деплоя это имелось в виду, дописал явно про StatefulSet, спасибо.

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

    ]]>     Tue, 07 Dec 2021 10:43:43 GMT     29.11.2021 09:55:17 https://habr.com/ru/companies/kts/articles/591853/#comment_23763335 https://habr.com/ru/companies/kts/articles/591853/#comment_23763335 Не совсем, metallb лишь выдаст доступный ip-адрес из пула, узел, которого должен привлекать трафик в кластер. Уже логика на этом узле должна как-то запроксировать трафик к нужным подам.

    ]]>     Mon, 29 Nov 2021 09:55:17 GMT     29.11.2021 09:50:41 https://habr.com/ru/companies/kts/articles/591853/#comment_23763311 https://habr.com/ru/companies/kts/articles/591853/#comment_23763311 Как написал выше, что зачастую кластера находятся во внутренней сети и просто так трафик не пропустить в кластер. Хочется еще отметить, что в вашем предложении с DaemonSet+hostnetwork есть проблема - а как в итоге клиенту выбрать на какой узел попасть? Помещать в dns все узлы кластера плохой путь - при добавлении/удалении узла из кластера нужно вносить изменения в dns, а они распространяются не моментально. Поэтому желательно иметь какую-то одну точку входа, желательно отказоустойчивую.
    С подходом внешнего ингресс контроллера можно как избежать лишних проксирований, так и запустить несколько балансировщиков в HA режиме, например с помощью keepalived.

    ]]>     Mon, 29 Nov 2021 09:50:41 GMT