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

Это глава 37 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Перейдём теперь к конкретике: что конкретно означает «следовать семантике протокола» и «разрабатывать приложение в соответствии с архитектурным стилем REST». Напомним, речь идёт о следующих принципах: операции должны быть stateless; данные должны размечаться как кэшируемые или некэшируемые; интерфейсы взаимодействия между компонентами должны быть стандартизированы; сетевые системы многослойны.

Эти принципы мы должны применить к протоколу HTTP, соблюдая дух и букву стандарта: URL операции должен идентифицировать ресурс, к которому применяется действие, и быть ключом кэширования для GET и ключом идемпотентности — для PUT и DELETE; HTTP‑глаголы должны использоваться в соответствии с их семантикой; свойства операции (безопасность, кэшируемость, идемпотентность, а также симметрия GET / PUT / DELETE‑методов), заголовки запросов и ответов, статус‑коды ответов должны соответствовать спецификации.

Эта заметка является переводом поста в блоге Дэвида Ханссона под заголовком «Even Amazon can't make sense of serverless or microservices». Здесь минимум редактуры для сохранения оригинальной авторской подачи.

Команда Prime Video из Amazon опубликовала довольно примечательное тематическое исследование, посвящённое их решению отказаться от своей микросервисной serverless-архитектуры и заменить её монолитом. Этот шаг сэкономил им ошеломляющие 90% (!!) эксплуатационных расходов, а также упростил систему. Какая победа!

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

# Шаблон 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.

Шаблон 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

• У меня в Психотронке можно следить за подготовкой обновленной версии, ну и написать мне за помощью. А можете не следить: версия 2.0 выйдет на Хабре.
• В русскоязычном сообществе Zettelkasten в Телеграме сидят люди, которые хорошо разбираются в теме. Мы обожаем помогать новичкам.

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

Хотели бы вы иметь второй мозг? Мозг, способный запомнить всё. Мозг, в котором содержится вся полезная информация из книг, статей, видео, полученная вами?

Звучит прекрасно, не так ли? Может, когда‑то и казалось сказками, однако не сейчас.

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

В этом посте я пробегусь по пяти функциям и приемам для Postman, которые мы используем для тестирования систем, связанных с банковскими операциями в сегменте C2B – теми самыми, которые весь мир ежедневно проводит через всевозможные кассовые аппараты, банкоматы, терминалы и QR-коды.

Тема с testcontainer-ами относительно не новая, первые статьи на англоязычных ресурсах встречаются с 2016 года, но не смотря на это, до сих пор на просторах веба крайне мало гайдов для их развертывания из коробки. В большинстве своем это туториалы, где собрана солянка из зависимостей и аннотаций, которые мало того, что не нужны, но еще и могут запутать разработчика, решившего  с ними познакомиться. В этой статье я опишу свой практический кейс по развертыванию тестовых контейнеров для базы данных PostgreSQL. Основная задача их использования - быстрый deploy нужного сервиса в контейнере за небольшое время. В дополнении для наглядности запустим туда FlyWay миграции.

Алексей Барабанов, IT-директор «Хлебница» и спикер курса «RabbitMQ для админов и разработчиков», подготовил конспект о типовых архитектурных паттернах RabbitMQ. Из него вы узнаете, как настроить пайплайны обработки и реализовать очереди повторных попыток (в том числе, через механизм dead letter exchange). 

Хочу описать свои наработки и устоявшиеся подходы к тестированию PHP проектов. Последние годы я работаю с Symfony и здесь будет достаточно моментов специфичных для этого фреймворка. Так же в этой статье термин функциональные тесты (functional) является синонимом End-to-End тестов. Статья рассчитана на разработчиков уже знакомых с PHPUnit и Symfony, структурой composer файла. Врочем, здесь есть и общеизвестные моменты, чтобы облегчить понимание тем, кто только начинает писать тесты. Статья призвана упорядочить знания и показать какие-то удобные подходы. Формат статьи не позволяет раскрыть все нюансы. Тем не менее, я постараюсь озвучить все основные моменты, применяемые в работе и которые лично мне помогают на практике. 

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

Самое первое и главное заблуждение — "нужен поиск, так бери эластик!". Но в действительности, если вам нужен шустрый поиск для небольшого или даже вполне себе крупного проекта, вам стоит разобраться в теме поподробней и вы откажетесь от использования именно этой системы.

Постоянно откладываешь дела на потом и не видишь в этом проблемы? Мне это знакомо. Расскажу как не повторить моих ошибок и почему пора это прекращать. Не откладывай эту статью на потом!

На связи команда Тинькофф Инвестиций. В этой статье разберем, как клиенты с минимальными навыками программирования создают торговых роботов. Базой будет API брокера Тинькофф Инвестиций — Tinkoff Invest API. Добро пожаловать на борт!

Всем привет!

Про принципы работы Role Based Access Control (он же RBAC) слышали многие. Но реальное применение встречается довольно редко. Меня зовут Корняков Дмитрий, более 6 лет занимаюсь поддержкой инфраструктуры в команде Мир Plat.Form (НСПК). В статье расскажу про предпосылки создания, практическую реализацию и профит, который мы получили от ролевого доступа к ОС на инфраструктуре из 5000+ серверов в десятке доменов в разных ЦОД под управлением FreeIPA и Active Directory.

"Да что тут рассказывать – ещё на начальных курсах по админству про ролевую модель предоставления доступа рассказывают, и все всё знают."(с) Аноним

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

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