Ок. Смысл есть.
Упомяну только лайфхак. На github можно подписываться на людей и видеть в общей ленте то, что они старят (15-20 подписок на людей из ваших тем и будете в курсе всего). Так я и узнал про этот урок, кто-то из мира gamedev поставил star на эту репу.
Думаю стиль автора, но раз вы перевели, то солидарны.
А сравнение выглядит как jQuery vs React, которое большей частью бессмысленно, разные вещи. Показывайте профит, если он есть, без поливания грязью упоминания "конкурентов" и все ок будет.
Да. Там драйвер умеет скачивать бинари или архив бинаря и запускать в chroot. В каком-то ci создается артифакт и выполняется nomad run с ссылкой на этот артифакт — все хорошо работает.
И эти банкоматы с кучаей ограничений вроде «макс 15к» и тп. Уже больше года практически не пользуюсь наличными (может быть 5-10к за год снял). В МСК нет проблем, которые мешают отказаться от нала. МСК это 8% населения страны, думаю если бы половина МСК отказалась от сбера, то сбер бы опомнился.
Однозначно стоит использовать консул и хранить там конфиги. С таким шаблоном все переменные из папки консула попадают в ENV и при изменении конфига nomad пересоздает jobs.
template {
data = <<EOH
{{ range ls "backend" }}
{{ .Key }}={{ .Value }}{{ end }}
EOH
destination = "secrets/file.env"
env = true
}
Плюс относительно куба:
— меньше ресурсов на control plane (для куба это обязательно 3 мастера 2 ядра/4 gb памяти, многие проекты могут спокойно жить в таком)
— куб использует CNI, который часто лишний (имеет смысл только для network policy, но если у вас все разруливается на уровне приложения, то бесполезно ну и есть consul connect на крайний случай)
— не нужна плоская сетка
— можно крутить все без докера, если golang или java
— hard way у куба это прилично времени (установка всего руками), у nomad это один вечер (сюда же входит написание ansible ролей), админить проще в общем
— nomad agent -dev и дев окружение готово, никаких minikube и тп
Минусы относительно куба:
— нет «все делается в одном стиле», нужно использовать много разношостных тулов
— очень мало готовых рецептов
— безопасность целиком админе (хочешь делай, хочешь нет)
— ничего нет для stateful
ИМХО. Эти переходы выглядят печально, потому что Linux пытаются использовать как Windows. Linux не Windows. У нас в компании все ПО крутиться в Web и от OS требуется только мессенджер, почту и браузер запустить — Linux отлично живет. Возможно в Германии все получилось, если бы часть денег вложили в «crm/erp/etc» вместо excel и тп, которые систематизируют процессы и тп, а второй волной, как следствие, переход на Linux.
PS. Я знаю кучу старого ПО, которое запускается четко на одном дистре и никак иначе. Такая же ситуация же с windows-linux.
Это не первая проблема яндекс облака за пару месяцев. В прошлый раз 2 vm из 20 упали в read only из-за «балансировки хранилища» (база prometheus покараптилась). Это не должно быть моей проблемой, если я плачу 2-3 раза больше голого железа.
У pg user и role синоним. Роли могут наследоваться.
> это понятно, для 3.5 пользователей можно так, а для более-менее приличного портала, уже накладно
Это имеет смысл, если нет четких классических ролей (к примеру менеджеру из одного отдела разрешили смотреть данные другого). Бываю ситуации, тут на месте смотреть стоит.
> т.е. перед каждым запросом создается роль? Я не силен в PG, хочу для себя понять
У пользователя в таблице хранится поле role и перед каждым запросом пользователя делается
-- какие-то "переменные" на которые опирается логика ограничений
set role to 'my_app_user';
select set_config('app.user_id', '1000');
-- сам запрос
select * from my_posts;
> немного ограничивает в возможностях, какую-то сложную логику
Ограничивает, но достаточные сложные кейсы все равно возможно. В таком месте в последнюю очередь хочется много ограничений.
Без проблем делаются ограничения вида «этот пользователь может удалять любые коментарии в своих постах, если они не от админа».
Смотря что нужно. Для in-house софта можно и так, но никогда так не делал.
А так завожу пользователя под каждую роль, условно admin/user/guest + current_setting('user_id')::int (set role, set user_id перед запросом). Это подход не лично мой, я узнал его из доков postgraphile/postgREST и начал использовать везде — удобно.
Т.е роли для грубой настройки и where/policies для тонкой
create view my_posts as
select *
from posts
where author_id = current_setting('user_id');
grant select on my_posts to my_app_user;
grant delete on my_posts to my_app_admin;
С row level security чуть сложнее, но еще точнее можно. И еще раз — смысл в том, что это написанный инструмент, который не зависит от языка, а сейчас пишут на чем удобно и крайне больно из условного монолита вытаскивать настройки безопасности, а так они на уровне базы и все просто.
Разделение доступа запросто решается через роли в базах типа postgres/oracle, у которых есть row level security. Это старый проверенный механизм, который лучше большинства поделок. Главное перестать бояться пользоваться базой по полной.
Проблема SELECT N + 1 решена в таких штуках как join-monster, postgraphile, prisma и тп. Они даже полей лишних не выбирают. Но dataloader тоже не плох.
Завидую прямоте ваших рук, только как программисту больно смотреть на море копипасты в коде =)
Ок. Смысл есть.
Упомяну только лайфхак. На github можно подписываться на людей и видеть в общей ленте то, что они старят (15-20 подписок на людей из ваших тем и будете в курсе всего). Так я и узнал про этот урок, кто-то из мира gamedev поставил star на эту репу.
Только вчера кинул звезду этому репозиторию. Спасибо за перевод.
Но есть смысл переводить текст, где большая часть текста — код и картинки?
Думаю стиль автора, но раз вы перевели, то солидарны.
А сравнение выглядит как jQuery vs React, которое большей частью бессмысленно, разные вещи. Показывайте профит, если он есть, без
поливания грязьюупоминания "конкурентов" и все ок будет.Но стиль ваших статей вызывает только негативные эмоции.
Traifik сейчас хорош, а настройка роутинга через теги сервиса бомба (аналог ingress в кубе)
Однозначно стоит использовать консул и хранить там конфиги. С таким шаблоном все переменные из папки консула попадают в ENV и при изменении конфига nomad пересоздает jobs.
Плюс относительно куба:
— меньше ресурсов на control plane (для куба это обязательно 3 мастера 2 ядра/4 gb памяти, многие проекты могут спокойно жить в таком)
— куб использует CNI, который часто лишний (имеет смысл только для network policy, но если у вас все разруливается на уровне приложения, то бесполезно ну и есть consul connect на крайний случай)
— не нужна плоская сетка
— можно крутить все без докера, если golang или java
— hard way у куба это прилично времени (установка всего руками), у nomad это один вечер (сюда же входит написание ansible ролей), админить проще в общем
— nomad agent -dev и дев окружение готово, никаких minikube и тп
Минусы относительно куба:
— нет «все делается в одном стиле», нужно использовать много разношостных тулов
— очень мало готовых рецептов
— безопасность целиком админе (хочешь делай, хочешь нет)
— ничего нет для stateful
PS. Я знаю кучу старого ПО, которое запускается четко на одном дистре и никак иначе. Такая же ситуация же с windows-linux.
Travis CI MIT? Я что-то проспал?
> это понятно, для 3.5 пользователей можно так, а для более-менее приличного портала, уже накладно
Это имеет смысл, если нет четких классических ролей (к примеру менеджеру из одного отдела разрешили смотреть данные другого). Бываю ситуации, тут на месте смотреть стоит.
> т.е. перед каждым запросом создается роль? Я не силен в PG, хочу для себя понять
У пользователя в таблице хранится поле role и перед каждым запросом пользователя делается
> немного ограничивает в возможностях, какую-то сложную логику
Ограничивает, но достаточные сложные кейсы все равно возможно. В таком месте в последнюю очередь хочется много ограничений.
Без проблем делаются ограничения вида «этот пользователь может удалять любые коментарии в своих постах, если они не от админа».
А так завожу пользователя под каждую роль, условно admin/user/guest + current_setting('user_id')::int (set role, set user_id перед запросом). Это подход не лично мой, я узнал его из доков postgraphile/postgREST и начал использовать везде — удобно.
Т.е роли для грубой настройки и where/policies для тонкой
С row level security чуть сложнее, но еще точнее можно. И еще раз — смысл в том, что это написанный инструмент, который не зависит от языка, а сейчас пишут на чем удобно и крайне больно из условного монолита вытаскивать настройки безопасности, а так они на уровне базы и все просто.
Проблема SELECT N + 1 решена в таких штуках как join-monster, postgraphile, prisma и тп. Они даже полей лишних не выбирают. Но dataloader тоже не плох.