я, конечно, хз как там в Черногории, но с т.з. банальной безопасности это не подпись, а «филькина грамота». Я с тем же успехом, имея доступ к токену без владельца могу подписать любой документ. В чем смысл подписи — непонятно. Иное дело, если бы вы подписывали на самом устройстве документ, без «утечки» приватного ключа в какие-то «чудесные облака».
Я не стану повторять вопрос, но вы на него не ответили в полном объеме, а он (ответ) потянет на весьма немаленькое исследование и копания в сорцах, а если наложить ещё и версии...
это плохой вопрос и вот почему: 1) без спецификации там может быть что-угодно, да ещё и зависящее от платформы, runtime окружения, «времени суток и уровня воды на берегу» 2) код подобных типов склонен меняться и, зачастую, в более сложный мутировать, так что сегодняшнее представление о map может быть совсем неверным завтра (например — обрастать условиями на количество элементов в map-е или runtime эвристиками).
Вот вы сами рассуждаете о императивности и декларативности — и тут же просите от кандиата того, что в общем-то не декларируется нигде и никем (ну, исключая исходники, конечно). Реальность же такова, что ответ «там бакеты» вполне годный — это как минимум говорит о том, что человек где-то что-то слышал или имеет базовые (академические) представления о реализации подобных структур. А вот момент когда ему действительно понадобится лазить «в кишки» может и не настать вовсе, а когда настанет — добро пожаловать в мир профилирования…
А поясните для не-сварщиков на go: так и какая же функция хеширования используется? А где это специфицировано? А что менялось с версии 1.10 до 1.13+ в этой части?
уже не вспомню, но вероятно это — как раз вероятно не хватает ещё одного условия исключения…
А как же остальные 90% реальных пользователей кубернетес? У которых кластера от 5 до 20 узлов, и нет денег на специалистов, готовых не только написать IaC сценарий для развертывания кластера, но и регулярно изучать, что новенького появилось в кубе, что изменилось, а что и удалили. И согласно всем этим изменениям поддерживать свой сценарий в актуальном состоянии.
такие люди не справятся и с kubespray — столкнуться как например я с первой ошибкой и уйдут в rke/иное «k8s в два клика»/k8s as service. «Платишь орехами — получаешь обезъян».
Что дейсвительно таким нужно, так это не «ansible макороны» — а готовые образа мастеров, нод и т.д. (где уже всё стоит, настроено + cloud-init «инструкция» как их «запустить» чтобы при старте стать «кластером»). Все кто хочет «не стандарт» — идут на рынок за админами (ops-ами или как вы их хотите назвать — не так важно). Либо сервис (вот вам идея), который позволит натыкать что вы хотите (на там выбрать сеть, формат образов и т.п.), заплатить мини денюжку для подписки на выбранную конфигурацию и получать эти образа «по-подписке» для обновления свого кластера. И пусть эти ansible программы (kubespray) (да, это ведь эта конфа по слоности уже похожа на «взрослый» язык программирования) будет не их головной болью.
В эту степь сейчас идёт вся индустрия — immutable образа и это относится не только к контейнерам, но и к виртуалкам.
попробовал я давечА этот форк. Нус, скажем так из первых впечатлений:
1) использование hostname, а не hostnamectl — на centos8 cloud пришлось доставлять условными ручками (через cloud-init, конечно, хотя иные пакеты «инсталер» ставит). Ну и не забыть поставить iptables если вам оно надо будет «потом» (в процессе инсталяции иных компонент)…
2) использование (отключаемое, но всё же) запуска ionice внутри etcd офиц. (если не переопределён, конечно) образа, хотя его там уже давно выпилили. Как следствие etcd не поднимается, что как бы печально.
Короче как итог: если вы думаете что большие дядьки за вас все сделали и вы по трём командам развернете k8s в проде — врядли.
Мне так и осталось непонятным итоговая аудитория этого kubespray (и форка в частности): для «поиграться» есть более простые решения, для реально здоровых инсталяций (хотя бы в 100 нод) — в 90% придётся допиливать хотя бы это решение или рисовать своё (и не факт что рисовать своё будет быстрее чем допиливать и потом поддерживать в актуальности).
JohnRico — попросите спикера освятить вопрос «кому это надо»?
Это чудесно, что ваш большой и отличный проект состоит из одной сборки и вам ничего не надо менять из того, что делает msbuild «из коробки выбранной вами SDK» (и вы никогда не обновляли этот SDK так, что это сломало вам сборку). А, к примеру, когда этих сборок хотя бы 20-30 (даже в рамках одного solution), и надо менеджерить зависимости (версии) — начинается «DirectoryBuild.props» и другие «веселые друзья».
Почитайте о проекте Paket и про транзитивные зависимости например…
А уж какая веселуха у тулинга .net с теми же цифровыми подписями бинарей (не под виндой, хотя и под ней не без нюансов) и nuget пакетов — цельный issue года этак с 2016 открытый имеется — страниц на 200…
один исполняемый файл — это, конечно, отлично, пока вы не задумываетесь о том, как именно он работает с учетом таких вещех как, скажем, SELinux (и о безопасности в целом).
Внутреняя кухня до тех пор «внутреняя», пока вам не надо там что-то менять или вы не натыкаетесь на баги в этой внутрянке.
Рекомендовал бы сильно задуматься над кодом, например про CSRF.
Не надо изобретать велосипеды (которые ещё надо ой как проверять), есть уже достаточно продуманное решение в виде OpenId Connect и соотвествующих реализаций, где подобный обсуждаемому flow имеется «из коробки».
мне когда говорят что msbuild скрипты стали проще (применительно к платформе .net в целом) я прошу объяснить мне пару вещей (код ниже):
1) откуда новые файлы
2) как влиять на их генерацию (напишите мне «в блокноте/на память/без гуглежа»)
3) каких ещё вещей мне ожидать в следующие релизе .net5/6/7… в выхлопе моего софта, непосредственно к нему (к его работе) не относящегося и как мне обеспечить приемлемую скорость обновления этих версий с учётом правок билд конвейерных скриптов всявзи с этими изменениями.
4) а ещё помнится был (а может и есть?) SOS_README.md в зависимостях (попадал в deps.json) и приятно удивлял своей «необходимостью» при развёртывании («мусор, а приятно»)…
короче в msbuild очень много всяких «нюансов» и «сделали по-умолчанию, потому что это устраиват 99% юзеров, прочитавших книжку `.net за 21 час`» (кто там помнит на память содержимое и назнчение файла «PackageOverrides.txt» ?) И не стал он проще — он стал сложнее, и то как его используют делает его всё более запутанным. А «перезагрузку» (отказ от msbuild) M$ так и не осилили и похронили идею («прощай project.json»).
# представим что у нас netcoreapp3.1
mkdir c
cd c
dotnet new console
touch some.config
dotnet publish
ls -l bin/Debug/netcoreapp3.1/publish/
..... c.deps.json
..... c.dll
..... c.pdb
..... c.runtimeconfig.json
cd ..
# now web ....
mkdir w
cd w
dotnet new web
touch some.config
dotnet publish
ls -l bin/Debug/netcoreapp3.1/publish/
..... appsettings.Development.json
..... appsettings.json
..... some.config <== wow
..... w.deps.json
..... w.dll
..... web.config <== wow
..... w.pdb
..... w.runtimeconfig.json
у меня в докере собирается chromium (да ещё и в куче вариаций). Соберёте его за 20 сек не имея нехилого такого облака, с кешированием артефактов сборки (промежуточных) и т.п.? Если ваши проекты собираются за 20 сек, то это, круто, честно. И если пересборка не ломает выхлоп (вы же вкурсе что, например, комиляторы тоже имеют баги оптимизаторов и даже результат одного компилера от раза к разу может быть разный ?)
Готовы рисковать — ну ок, а ребята поступили в целом правильно и здраво — нет смысла пересобирать что уже собрано, если ABI «базы» не сломан.
ну вот у меня два стейджа: build и out.
Пусть build юзает ubuntu:18-04, и out его же.
Я меняю out в части FROM ubuntu:18-10.
У меня НЕ будет пересборки build, а будет взят кеш и out будет на него «ссылаться».
И чем это отличается от «я сам руками правлю манифест» по-факту?
UPD: а ну ок, вы ведёте речь про то что ковыряете сам registry, без условного 'docker build...'.
докер для сборки докер образов (если вы, конечно, хотите докер формат образов) не обязателен. и, более того: сейчас как раз все уходят от подобной практики.
Ну переделка оно «такое», я не знаю ваших деталей в части объемом — не могу и судить что выйгрышнее — свой велик или «студент на переделку». Вам де-факто и пришлось распортрошить докер файл на «стейджи».
так вам ж написали — время меньше, сборку приложения не надо делать. Не надо делать — не сломаешь. Вообще есть уже готовые иммутабельные сборки (дистры) линукс, что как раз и обеспечивают базовый обновляемый слой… и собственно они в будущем как я понимаю движ и будут решать туже самую задачу.
Вопрос больше чем не подошли мультистэйджинг сборки (а по-факту то что описано — оно и есть) — стейдж сборки приложения кеширован будет, а база+копирование из стейджа сборки результата, динамически слинкованного на «базовые либы» пересобирается. При этом, конечно, нельзя забывать про то что ABI базы должен не ломаться…
так ведь у вас поди там настроен (обыкновенно, например у десктоп версии убунты последних лет) NetworkManager, который использует systemd-resolved, который как бы поддерживает DoH уже давно. Ну а хром, соотвественно, использует локальный dns сервер (на локальном хосте), и трафик не утекает в интернеты между ним и dns сервером (нет смысла там tls делать особенно). Не?
это о браузере речь — браузер перед тем как сделать запрос (речь о js через fetch/XMLHttpRequest, не о, например img теге) с домена ХХХ на домен YYY сделает OPTIONS запрос на YYY и, если не увидит в ответе Access-Control-Allow-Origin с доменом ХХХ (ну или звездочку), то и запрос реальный делать не станет.
Руками-то собрать любой HTTP запрос и дёрнуть его не в браузере (curl например) труда не составляет, тут все упирается в браузер и его безопасность.
Например: Защищает стало быть от угона обычно токенов безопасности (того же httpOnly cookie) на чужой домен, когда сайтец выломали (на клиенте) и пытаются сделать из браузера запрос на свой домен. Проще говоря это позволяет установить доверительные отношения между от «домена-сайта» до «домена api».
А потом во всем обвинят «русских хакеров»...
это плохой вопрос и вот почему: 1) без спецификации там может быть что-угодно, да ещё и зависящее от платформы, runtime окружения, «времени суток и уровня воды на берегу» 2) код подобных типов склонен меняться и, зачастую, в более сложный мутировать, так что сегодняшнее представление о map может быть совсем неверным завтра (например — обрастать условиями на количество элементов в map-е или runtime эвристиками).
Вот вы сами рассуждаете о императивности и декларативности — и тут же просите от кандиата того, что в общем-то не декларируется нигде и никем (ну, исключая исходники, конечно). Реальность же такова, что ответ «там бакеты» вполне годный — это как минимум говорит о том, что человек где-то что-то слышал или имеет базовые (академические) представления о реализации подобных структур. А вот момент когда ему действительно понадобится лазить «в кишки» может и не настать вовсе, а когда настанет — добро пожаловать в мир профилирования…
такие люди не справятся и с kubespray — столкнуться как например я с первой ошибкой и уйдут в rke/иное «k8s в два клика»/k8s as service. «Платишь орехами — получаешь обезъян».
Что дейсвительно таким нужно, так это не «ansible макороны» — а готовые образа мастеров, нод и т.д. (где уже всё стоит, настроено + cloud-init «инструкция» как их «запустить» чтобы при старте стать «кластером»). Все кто хочет «не стандарт» — идут на рынок за админами (ops-ами или как вы их хотите назвать — не так важно). Либо сервис (вот вам идея), который позволит натыкать что вы хотите (на там выбрать сеть, формат образов и т.п.), заплатить мини денюжку для подписки на выбранную конфигурацию и получать эти образа «по-подписке» для обновления свого кластера. И пусть эти ansible программы (kubespray) (да, это ведь эта конфа по слоности уже похожа на «взрослый» язык программирования) будет не их головной болью.
В эту степь сейчас идёт вся индустрия — immutable образа и это относится не только к контейнерам, но и к виртуалкам.
1) использование hostname, а не hostnamectl — на centos8 cloud пришлось доставлять условными ручками (через cloud-init, конечно, хотя иные пакеты «инсталер» ставит). Ну и не забыть поставить iptables если вам оно надо будет «потом» (в процессе инсталяции иных компонент)…
2) использование (отключаемое, но всё же) запуска ionice внутри etcd офиц. (если не переопределён, конечно) образа, хотя его там уже давно выпилили. Как следствие etcd не поднимается, что как бы печально.
Короче как итог: если вы думаете что большие дядьки за вас все сделали и вы по трём командам развернете k8s в проде — врядли.
Мне так и осталось непонятным итоговая аудитория этого kubespray (и форка в частности): для «поиграться» есть более простые решения, для реально здоровых инсталяций (хотя бы в 100 нод) — в 90% придётся допиливать хотя бы это решение или рисовать своё (и не факт что рисовать своё будет быстрее чем допиливать и потом поддерживать в актуальности).
JohnRico — попросите спикера освятить вопрос «кому это надо»?
Note: я ниразу не ops, я с другой стороны.
Почитайте о проекте Paket и про транзитивные зависимости например…
А уж какая веселуха у тулинга .net с теми же цифровыми подписями бинарей (не под виндой, хотя и под ней не без нюансов) и nuget пакетов — цельный issue года этак с 2016 открытый имеется — страниц на 200…
Внутреняя кухня до тех пор «внутреняя», пока вам не надо там что-то менять или вы не натыкаетесь на баги в этой внутрянке.
Не надо изобретать велосипеды (которые ещё надо ой как проверять), есть уже достаточно продуманное решение в виде OpenId Connect и соотвествующих реализаций, где подобный обсуждаемому flow имеется «из коробки».
1) откуда новые файлы
2) как влиять на их генерацию (напишите мне «в блокноте/на память/без гуглежа»)
3) каких ещё вещей мне ожидать в следующие релизе .net5/6/7… в выхлопе моего софта, непосредственно к нему (к его работе) не относящегося и как мне обеспечить приемлемую скорость обновления этих версий с учётом правок билд конвейерных скриптов всявзи с этими изменениями.
4) а ещё помнится был (а может и есть?) SOS_README.md в зависимостях (попадал в deps.json) и приятно удивлял своей «необходимостью» при развёртывании («мусор, а приятно»)…
короче в msbuild очень много всяких «нюансов» и «сделали по-умолчанию, потому что это устраиват 99% юзеров, прочитавших книжку `.net за 21 час`» (кто там помнит на память содержимое и назнчение файла «PackageOverrides.txt» ?) И не стал он проще — он стал сложнее, и то как его используют делает его всё более запутанным. А «перезагрузку» (отказ от msbuild) M$ так и не осилили и похронили идею («прощай project.json»).
да и вообще много чего допилено надо думать.
Готовы рисковать — ну ок, а ребята поступили в целом правильно и здраво — нет смысла пересобирать что уже собрано, если ABI «базы» не сломан.
ну вот у меня два стейджа: build и out.
Пусть build юзает ubuntu:18-04, и out его же.
Я меняю out в части FROM ubuntu:18-10.
У меня НЕ будет пересборки build, а будет взят кеш и out будет на него «ссылаться».
И чем это отличается от «я сам руками правлю манифест» по-факту?
UPD: а ну ок, вы ведёте речь про то что ковыряете сам registry, без условного 'docker build...'.
Ну переделка оно «такое», я не знаю ваших деталей в части объемом — не могу и судить что выйгрышнее — свой велик или «студент на переделку». Вам де-факто и пришлось распортрошить докер файл на «стейджи».
Вопрос больше чем не подошли мультистэйджинг сборки (а по-факту то что описано — оно и есть) — стейдж сборки приложения кеширован будет, а база+копирование из стейджа сборки результата, динамически слинкованного на «базовые либы» пересобирается. При этом, конечно, нельзя забывать про то что ABI базы должен не ломаться…
Руками-то собрать любой HTTP запрос и дёрнуть его не в браузере (curl например) труда не составляет, тут все упирается в браузер и его безопасность.
Например: Защищает стало быть от угона обычно токенов безопасности (того же httpOnly cookie) на чужой домен, когда сайтец выломали (на клиенте) и пытаются сделать из браузера запрос на свой домен. Проще говоря это позволяет установить доверительные отношения между от «домена-сайта» до «домена api».