Гипотетическая ситуация — ваш работодатель поручил вам выбрать Identity and Access Management platform.

Обязательно: open‑source (Apache 2.0), self‑hosted, OAuth 2.0, OIDC, SAML, LDAP.

Для тех кому интересно узнать, что есть еще кроме Keycloak.

# Шаблон backend сервера на Golang — часть 5 — оптимизация Worker pool

Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.

Представленный Worker pool поддерживает работу с двумя типами задач

• "Короткие" — не контролируется предельный timeout выполнения и их нельзя прервать
• "Длинные" — контролируется предельный timeout выполнения и их можно прервать

Накладные расходы Worker pool на добавление в очередь, контроль очереди, запуск обработки task, контроль времени выполнения task:

• Для "коротких" task — от 300 ns/op, 0 B/op, 0 allocs/op
• Для "длинных" task — от 1400 ns/op, 16 B/op, 1 allocs/op

Для task, которые должны выполняться быстрее 200 ns/op представленный Worker pool использовать не эффективно

Собираются следующие метрики prometheus:

• wp_worker_process_count_vec — количество worker в работе
• wp_task_process_duration_ms_by_name — гистограмма длительности выполнения task в ms с группировкой по task.name
• wp_task_queue_buffer_len_vec — текущая длина канала-очереди task — показывает заполненность канала
• wp_add_task_wait_count_vec — количество задач, ожидающих попадания в очередь

Ссылка на репозиторий проекта.

Шаблон goapp в репозитории полностью готов к развертыванию в Docker, Docker Compose, Kubernetes (kustomize), Kubernetes (helm).

Ссылки на предыдущие части:

• Первая часть шаблона была посвящена HTTP серверу.
• Вторая часть шаблона была посвящена прототипированию REST API.
• Третья часть посвящена развертыванию шаблона в Docker, Docker Compose, Kubernetes (kustomize).
• Четвертая часть будет посвящена развертыванию в Kubernetes с Helm chart и настройке Horizontal Autoscaler.

Apache NlpCraft - библиотека с открытым исходным кодом, предназначенная для интеграции языкового интерфейса с пользовательскими приложениями. Новая версия 1.0.0 привнесла в проект наиболее существенные изменения за все время его существования. 

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

1. Предельное упрощение, отказ от всех вспомогательных enterprise возможностей, предельно точная фокусировка продукта.

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

Docs as Сode — подход к работе с текстами, подразумевающий написание текста как кода:

• в простом текстовом редакторе или IDE;
• с использованием системы контроля версий;
• с CI / CD / Code Review.

В настоящее время Docs as Code широко применяется при работе с технической документацией, давая техническим писателям и проектным командам массу удобств и преимуществ.

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

В этой статье я расскажу о таком эксперименте (забегая вперед, удачном). Моей дочери 11 лет, она пишет сказки, стихи и рассказы. Чтобы поддержать ее увлечение, я помог ей создать литературный сайт, используя подход Docs as Code. Она успешно освоила основы Markdown и Git. Сейчас она самостоятельно публикует новые произведения и обновляет новости на своем сайте https://lib-beliakova.github.io/.

Приветствую!

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

Кроме нее будут рассмотрены:

— Модуль для работы с транзакциями.

— Исключения в С и их реализацию.

— Клиент‑серверный протокол.

Добрый день. Меня зовут Иван, я дата‑инженер, основной профиль — доставка данных от источников до целевых систем DWH. Чаще всего работаю с Apache NIFI.

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

Зачем? Это странно...

Привет, Хабр! Это команда Eppie. Подробнее о нашем проекте бессерверной электронной почты можно почитать в этом посте.

Мы, параллельно с созданием собственного децентрализованного протокола, интегрируем в клиентское приложение Eppie популярные классические сервисы. Осенью мы познакомились с основателем Proton Энди Йеном и договорились добавить в Eppie возможность подключения почтового ящика ProtonMail. Насколько нам известно, ни один нативный десктопный клиент не умеет авторизоваться на сервере Proton — Eppie будет первым.

В Proton реализована собственная версия протокола SRP (Secure Remote Password). Наш криптограф портировал библиотеку на C#. Если хотите посмотреть код, вот ссылка на репозиторий в GitHub.

SRP — пример «доказательства с нулевым разглашением». Смысл процедуры в том, чтобы доказать факт владения определенной информацией, не раскрывая при этом саму информацию. В частности, аутентификация по SRP позволяет пользователю ProtonMail доказать, что он знает пароль, не передавая пароль серверу. Сейчас расскажем, как это устроено изнутри.

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

Помните, несколько лет назад была проведена согласованная клеветническая компания против Ричарда Столлмана, в которой он был ложно обвинён в одобрении изнасилований, и по результатом которой его вынудили уволиться с поста президента Фонда Свободного Программного Обеспечения?

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

И вот сейчас, в релизе ядра Linux 6.2, произошло очень важное изменение — разрешён приём кода в ядро Linux под лицензией Copyleft-Next, для которой заявлена совместимость с GPLv2, что подтверждено юристами компаний SUSE и Red Hat (кто бы сомневался?).

Данная лицензия также содержит пункт о предоставлении прав на запатентованные технологии, что делает Copyleft-Next совместимой и с Apache 2.0. А для обеспечения полной совместимости с GPLv2, в тексте Copyleft-Next явно указано, что производная работа может поставляться не только под исходной лицензией Copyleft-Next, но и под лицензией GPL.

Но как говорится, «есть нюанс».

Защита от изменений API, которые могут повлиять на ваших клиентов, — одна из самых больших проблем при разработке HTTP API. Если вы вносите критические изменения, то создаете клиентам серьёзные проблемы. Стабильный API — ключ к удовлетворенности клиентов и, в конечном счете, к успеху в бизнесе.

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

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

В статье я расскажу, как можно (при необходимости) быстро и дешево собрать кластер Beowulf на основе домашних компьютеров. Выполню я это с помощью компьютеров находящихся в аудитории университета, используя существующую локальную сеть. Используемые программные инструменты: средства численного моделирования механики сплошных сред OpenFOAM, сетевого протокола прикладного уровня SSH и распределенного протокола файловой системы NFS. Все выполнялось под управлением операционной системы ubuntu 20.04.

Пакетный менеджер Homebrew раздаёт 52 миллиона пакетов в месяц. Чтобы это делать, он использует хранилища контейнеров, отлично подходящие для этой задачи. Как это работает?

Шаблон backend сервера на Golang — часть 3 (Docker, Docker Compose, Kubernetes (kustomize)

Первая часть шаблона посвящена HTTP серверу.

Вторая часть шаблона посвящена прототипированию REST API.

Третья часть посвящена развертыванию шаблона в Docker, Docker Compose, Kubernetes (kustomize).

Четвертая часть будет посвящена развертыванию в Kubernetes с Helm chart и настройке Horizontal Autoscaler.

Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.

Для корректного развертывания в Kubernetes, в шаблон пришлось внести изменения:

• способа конфигурирования — YAML, ENV, Kustomize
• подхода к логированию — переход на zap
• способа развертывания схемы БД — переход на liquibase
• добавление метрик prometheus

Ссылка на новый репозиторий.

Шаблон goapp в репозитории полностью готов к развертыванию в Docker, Docker Compose, Kubernetes (kustomize), Kubernetes (helm).

Настоящая статья не содержит детального описание используемых технологий

Содержание

1. Изменение подхода к конфигурированию
2. Добавление метрик prometheus
3. Изменение подхода к логированию
4. Развертывание схемы БД
5. Сборка Docker image
6. Сборка Docker-Compose
7. Схема развертывания в Kubernetes
8. Подготовка YAML для Kubernetes
9. Kustomization YAML для Kubernetes
10. Тестирование Kubernetes с kustomize