Можно собирать как локально, так и брать образа из сетевого регистри компании, если такое есть. Кроме того, docker по слоям запоминает, так что, если слои не меняются, они и не пересобираются
Ссылки перебил, по поводу "закопать стюардессу". Для относительно простых задач авторизации, в частности, доступ к полному списку сущностей или к конкретной сущности IS используем до сих пор и, как по мне, он прекрасно справляется, ну, для более сложных ACL, ABAC или RBAC (https://habr.com/ru/companies/custis/articles/248649/)
Валидация токенов осуществляется в каждом сервисе отдельно, IS мы используем только для выдачи полномочий. То есть шифровать или записывать токен может только IS, а читать каждый сервис самостоятельно:
var tokenValidationParameters = new TokenValidationParameters
{
ValidateAudience = false,
ValidateIssuerSigningKey = true,
ValidateLifetime = false,
IssuerSigningKey = securityKey,
ValidateIssuer = false,
};
services.AddSingleton(tokenValidationParameters)
.AddSingleton<JwtSecutiryTokenDecodeService>()
.AddSingleton<AccessVerificator>();
services.AddAuthentication("Bearer")
.AddJwtBearer("Bearer", options =>
{
options.TokenValidationParameters = tokenValidationParameters;
});
services.AddAuthorization(options =>
{
// политика по-умолчанию общая для всех
options.AddPolicy("TestPolicy", policy =>
{
policy.AuthenticationSchemes = new List<string> { "Bearer" };
policy.RequireAuthenticatedUser();
policy.RequireClaim("aud", "test");
});
});
Тестировался сервис, обмен данными с которым осуществлялся по трем rpc http, http2, grpc (3 разных теста) с небольшими возможностями инфраструктуры в кубере нагрузка давалась разная примерно до 5к одновременно работающих пользователей. Grpc нагрузку выдержал, http нет (c keep_alive не игрались)
Как-то делали нагрузочное тестирование на gatling сравнивали http, http2 и grpc. Так вот, судя по результатам, grpc очень хорошо держит нагрузку. Http2 разваливается при большом количестве соединений
Selenium IDE, если правильно понял, обладает теми же недостатками в плане shadowdom и dragAndDrop. К тому же работать из кода значительно быстрее и привычнее. И да, у нас была необходимость делать автоматизированный регресс
При написании скриптов для http мы не нашли способа сериализации ответа в объект Scala.
Ещё есть проблема с увеличением буфера памяти, поскольку при массовой загрузки файлов в какой-то момент можно напороться на нехватку памяти, при том, что ресурсы машины используются далеко не полностью. (параметры -Xms, -Xmx пробовали менять)
см. ниже ("Cypress и Puppeteer -- JS only ")
Не пробовали, нам Selenium и Playwright за глаза
Сервисы на C#, но сути вы правы из особенностей разве только некоторые особенности студии
Можно собирать как локально, так и брать образа из сетевого регистри компании, если такое есть. Кроме того, docker по слоям запоминает, так что, если слои не меняются, они и не пересобираются
Тоже смотрю, если получится подборку сделаю
Спасибо за предложение, обязательно попробуем!
Стек: c#, angular ts. Рассматривали ближе к этим языкам
Ссылки перебил, по поводу "закопать стюардессу". Для относительно простых задач авторизации, в частности, доступ к полному списку сущностей или к конкретной сущности IS используем до сих пор и, как по мне, он прекрасно справляется, ну, для более сложных ACL, ABAC или RBAC (https://habr.com/ru/companies/custis/articles/248649/)
Валидация токенов осуществляется в каждом сервисе отдельно, IS мы используем только для выдачи полномочий. То есть шифровать или записывать токен может только IS, а читать каждый сервис самостоятельно:
Помимо Gatling есть очень похожая реализация на .Net NBomber (https://github.com/PragmaticFlow/NBomber)
На тот момент не рассматривали, искали инструмент для тестирования GRPC
Как по памяти или инъекции кода? И ещё по собственным функциям? Насколько понимаю это выражения с++?
Сами тесты пишут разработчики, которые больше ориентируются в c#
Можно ссылку на репозиторий или статью?
Тестировался сервис, обмен данными с которым осуществлялся по трем rpc http, http2, grpc (3 разных теста) с небольшими возможностями инфраструктуры в кубере нагрузка давалась разная примерно до 5к одновременно работающих пользователей. Grpc нагрузку выдержал, http нет (c keep_alive не игрались)
Как-то делали нагрузочное тестирование на gatling сравнивали http, http2 и grpc. Так вот, судя по результатам, grpc очень хорошо держит нагрузку. Http2 разваливается при большом количестве соединений
Чистого сафари нет https://playwright.dev/docs/browsers
Selenium IDE, если правильно понял, обладает теми же недостатками в плане shadowdom и dragAndDrop. К тому же работать из кода значительно быстрее и привычнее. И да, у нас была необходимость делать автоматизированный регресс
Спасибо, за найденную ошибку!
При написании скриптов для http мы не нашли способа сериализации ответа в объект Scala.
Ещё есть проблема с увеличением буфера памяти, поскольку при массовой загрузки файлов в какой-то момент можно напороться на нехватку памяти, при том, что ресурсы машины используются далеко не полностью. (параметры -Xms, -Xmx пробовали менять)