Так себе совет, потому что COPY сделает слой с колёсами, которые нужны только при установке. Правильнее будет сделать через mount, но тогда задействуется buildkit. Хотя это не проблема для большинства ситуаций, я считаю.
Т.е. тут реально кто-то обсуждает, что в блоге OTUS'а "замыкания" перевели как "закрытия", но никто не оценил совершенство очепятки kокальная переменная, которая настолько идеально передаёт качество самого материала?
Вы что-то путаете. Это при курсе в 50руб/доллар бюджетные смартфоны были в пределах 20-25к рублей. При текущем курсе всё логично за 45к ожидать бюджетную модель.
Вы как-то обошли стороной GitOps, а я считаю, что это очень важный момент при поддержке сложных систем.
GitOps прекрасно живёт и без куба вместе CI/CD системами. Я не вижу здесь проблемы.
Меня больше беспокоит производительность PostgreSQL в контейнере, насколько она разная при прочих равных?
Без hugepages раз в 10 в некоторых случаях медленнее запросы. Есть даже случай почти 100кратного ускорения для таблицы. Но это почти на уровне эзотерики, потому что я до сих пор не понимаю откуда такой прирост.
Это ключевая проблема производительности. Как ни странно, но для меня это ключевая метрика, потому что напрямую влияет на затраты бизнеса.
И не вздумайте в него лезть напрямую. Это будет большой ошибкой.
Ну для того же кубера без этого не обойтись, но намного проще установка, взять тот же RKE2 от Rancher.
...
Это я ещё не говорю про бэкапы, восстановление, менеджмент пользователей. Для всего нужно писать скрипты рукам, если хочешь по уму.
Вы добавите просто ещё один уровень, а значит требования к поддержке, user management, бэкапам, резервированию, обновлениям...
Если хотя бы часть этих проблем сможет решить оператор, то почему бы не попробовать?
Будет простой обмен одних проблем на другие. Работает этот оператор на тех же принципах, что и Ansible, Terrafrom и т.п. Проблемы там те же.
Ладно, лично я логику понял. Не могу с ней согласиться, но как я уже сказал, это ваш опыт, ваши проблемы.
А какой у вас опыт? Сколько кластеров? Где крутятся, в какой обвязке работают?
Я вынужден работать с кубером с 1.6 версии. Я серёфил на хайпе кубера и openstack'а, потому что работал в консалтинге. При этом мне пришлось написать не один оператор. Поэтому я говорю исходя из опыта работы изнутри (как разработчик операторов) и снаружи (как тот, кто поддерживает кластеры).
Ну т.е. вы собираетесь развернуть кластер более 70 нод и на нём поднимать по контейнеру или как? Допустим вы реализуете через StatefulSet + host network. Какие преимущества поддержки, кроме статуса и логов вы получите?
Есть же гораздо легче варианты вроде Nomad, Docker Swarm, CoreOS, Portainer+Docker. Блин, да всё что угодно подходит на мой взляд гораздо лучше, чем костыляние кубера, который в первую очередь подразумевает работу с эфимерными контейнерами, которые можно легко заскейлить в любой момент. Если говорить за StatefulSet, он там максимально чужеродный, но сделал впервую очередь, чтоб внутри кластера создавать сервисы (ну т.е. вы создаёте БД, сервис с ClusterIP и всякая эфимерщина подключается внутри).
Я не осуждаю - у всех свои экзотические фантазии. Но мне правда интересно, чем лучше такая реализация.
Просто интересно, какого профита вы хотите этим добиться? Постгря такая штука, которая гораздо лучше себя чувствует вне контекста контейнеров. Какая вообще польза от кубера для такого статического деплоя?
Справедливости ради, в защиту автора, задача приложения для знакомств такая же как и у любого другого - срубить деньжат с пользователей. Зачастую, цели бизнеса и пользователей не совпадают.
Ситуация, конечно, утрированная, но не далека от истины. Если пользователи нашли друг друга, то они перестанут приносить доход, пока ищут партнёров. Свингеры не в счёт. Эти кролики в вечном поиске, но их всё же не так много.
Вы никак не сможете средствами кубера балансировать на разные кластеры БД с одного порта. Вам нужно либо поставить какой-то пуллер и ему дать порт, либо вешать кластеры на разные порты.
Именно так. Только надо допилить ручками некоторые вещи, чтобы работало как надо. В интернете полно мануалов. Я хотел статью написать, но руки не доходят. Там очень много нюансов надо объяснять.
Это про конфигурацию или код писать надо?
Да. Там нужно для больших запросов кое-что подправить в конфиге и для автоматического анализа пару-тройку функций написать.
Когда требования постоянно меняются комплексно (т.е. "нам нужен белый автомобиль" поменялось на "нам нужно рыть землю") это смена задачи, а не направления. Здесь скорее gitflow нужен, чтоб спокойно оставить наработки и пойти в другую задачу.
А если в задаче уточнились детали, то тесты вперёд обычно выигрывают, потому что сразу всплывают все места, где нужно внести изменения, при этом не нужно искать что сломалось - оно всё вылазит на поверхность. Более того, при реализации тестов, быстрее возникают вопросы к задаче для уточнения, особенно если задача комплексная. Например, какие заголовки использовать, требования к протоколу передачи данных, формат полей и т.п.
Единственное место, где не нужно и вредно TDD - вёрстка.
Для постгреса есть расширение, которое если немного допилить, то можно собирать даже автоматически запросы и даже explain по ним всем сделать и записать в готовую табличку. Даже эффективнее порой, чем методом пристального взгляда собирать статистику по данным и запросам. Я просто запускал в docker-compose окружение, прогонял тестовые сценарии, потом смотрел табличку с сортировкой по проблемным запросам (время выполнения и наличие seq scan).
TDD в значительной степени подразумевает, что вы должны знать, как ведет себя система, еще до ее реализации. Вы должны знать, что вы делаете.
В большинстве случаев вы этого не знаете. Все разработчики, которых я знаю, не знают этого заранее. Я не знаю этого заранее.
Ужас. Я не хотел бы переходить на личности, но это прям даже звучит дико. Если вы не знаете что пишите, то как пишите? Методом научно-ненаучного тыка? По вдохновению правой пятки? Возможно с таким подходом TDD и правда мешать будет. Возможно проблема не в методологии.
Смысл написания тестов до кода, что тесты проверяют функциональность, которая требуется. Если нет требований, то что конечно тесты не написать. Но говорить о вреде TDD просто потому что у вас процессы... ну мягко скажем не очень, как минимум глупо.
Когда в семье, кроме жены, трое детей, то, благодаря distcc, можно компилировать почти на сотне потоков. Хотя возмущения ребенка о просадке FPS могут потребовать некоторых компромиссов )
А я думал, что это я псих, когда маму на Kubuntu перетащил. Но есть и попсихованнее.
новичку которому нужен линукс лучше начинать с минта
Нее, ну это скучно. Если глаза не красные от того, что неделю пытаешься собрать ядро так, чтобы запустить какую-нибудь экзотическую звуковуху, а домашние, соседи, коллеги и парочка суперкомпьютеров не написали вам гневное письмо, что не надо использовать их ресурсы для того, чтобы пересобрать "мир" с новымы USE-флагами для 1% оптимизации работы, то не уверен, что это вообще линуксовый опыт. Попса какая-то и виндузятничество.
P.S.: Это лютый сарказм, если что, и океан самоиронии про студенческие годы.
Так себе совет, потому что COPY сделает слой с колёсами, которые нужны только при установке. Правильнее будет сделать через mount, но тогда задействуется buildkit. Хотя это не проблема для большинства ситуаций, я считаю.
Т.е. тут реально кто-то обсуждает, что в блоге OTUS'а "замыкания" перевели как "закрытия", но никто не оценил совершенство очепятки
kокальная переменная, которая настолько идеально передаёт качество самого материала?Thorium продолжает поддерживать семёрку. Хотя я на кубунте на нём, но репы под семёрку ещё есть.
Я думаю за счёт дублирования на бумаге, они планируют внести это всё вручную, вызвав всех сотрудников на работу с посылками. Больше похоже на правду.
Либо они действительно имеют бэкапы, которые не затронула атака.
Вы что-то путаете. Это при курсе в 50руб/доллар бюджетные смартфоны были в пределах 20-25к рублей. При текущем курсе всё логично за 45к ожидать бюджетную модель.
Сочетание этих фирм и стандарт защиты данных это сюр какой-то. "ИП Дырявые Вёдра" - прям так и пусть назовут свой синдикат.
GitOps прекрасно живёт и без куба вместе CI/CD системами. Я не вижу здесь проблемы.
Без hugepages раз в 10 в некоторых случаях медленнее запросы. Есть даже случай почти 100кратного ускорения для таблицы. Но это почти на уровне эзотерики, потому что я до сих пор не понимаю откуда такой прирост.
Это ключевая проблема производительности. Как ни странно, но для меня это ключевая метрика, потому что напрямую влияет на затраты бизнеса.
И не вздумайте в него лезть напрямую. Это будет большой ошибкой.
Вы добавите просто ещё один уровень, а значит требования к поддержке, user management, бэкапам, резервированию, обновлениям...
Будет простой обмен одних проблем на другие. Работает этот оператор на тех же принципах, что и Ansible, Terrafrom и т.п. Проблемы там те же.
Ладно, лично я логику понял. Не могу с ней согласиться, но как я уже сказал, это ваш опыт, ваши проблемы.
Я вынужден работать с кубером с 1.6 версии. Я серёфил на хайпе кубера и openstack'а, потому что работал в консалтинге. При этом мне пришлось написать не один оператор. Поэтому я говорю исходя из опыта работы изнутри (как разработчик операторов) и снаружи (как тот, кто поддерживает кластеры).
Ну т.е. вы собираетесь развернуть кластер более 70 нод и на нём поднимать по контейнеру или как? Допустим вы реализуете через StatefulSet + host network. Какие преимущества поддержки, кроме статуса и логов вы получите?
Есть же гораздо легче варианты вроде Nomad, Docker Swarm, CoreOS, Portainer+Docker. Блин, да всё что угодно подходит на мой взляд гораздо лучше, чем костыляние кубера, который в первую очередь подразумевает работу с эфимерными контейнерами, которые можно легко заскейлить в любой момент. Если говорить за StatefulSet, он там максимально чужеродный, но сделал впервую очередь, чтоб внутри кластера создавать сервисы (ну т.е. вы создаёте БД, сервис с ClusterIP и всякая эфимерщина подключается внутри).
Я не осуждаю - у всех свои экзотические фантазии. Но мне правда интересно, чем лучше такая реализация.
Просто интересно, какого профита вы хотите этим добиться? Постгря такая штука, которая гораздо лучше себя чувствует вне контекста контейнеров. Какая вообще польза от кубера для такого статического деплоя?
Разница в 600М существенная. Интересно, что они из стандартных пакетов выпилили.
Справедливости ради, в защиту автора, задача приложения для знакомств такая же как и у любого другого - срубить деньжат с пользователей. Зачастую, цели бизнеса и пользователей не совпадают.
Ситуация, конечно, утрированная, но не далека от истины. Если пользователи нашли друг друга, то они перестанут приносить доход, пока ищут партнёров. Свингеры не в счёт. Эти кролики в вечном поиске, но их всё же не так много.
Вы никак не сможете средствами кубера балансировать на разные кластеры БД с одного порта. Вам нужно либо поставить какой-то пуллер и ему дать порт, либо вешать кластеры на разные порты.
Именно так. Только надо допилить ручками некоторые вещи, чтобы работало как надо. В интернете полно мануалов. Я хотел статью написать, но руки не доходят. Там очень много нюансов надо объяснять.
Да. Там нужно для больших запросов кое-что подправить в конфиге и для автоматического анализа пару-тройку функций написать.
Когда требования постоянно меняются комплексно (т.е. "нам нужен белый автомобиль" поменялось на "нам нужно рыть землю") это смена задачи, а не направления. Здесь скорее gitflow нужен, чтоб спокойно оставить наработки и пойти в другую задачу.
А если в задаче уточнились детали, то тесты вперёд обычно выигрывают, потому что сразу всплывают все места, где нужно внести изменения, при этом не нужно искать что сломалось - оно всё вылазит на поверхность. Более того, при реализации тестов, быстрее возникают вопросы к задаче для уточнения, особенно если задача комплексная. Например, какие заголовки использовать, требования к протоколу передачи данных, формат полей и т.п.
Единственное место, где не нужно и вредно TDD - вёрстка.
Для постгреса есть расширение, которое если немного допилить, то можно собирать даже автоматически запросы и даже explain по ним всем сделать и записать в готовую табличку. Даже эффективнее порой, чем методом пристального взгляда собирать статистику по данным и запросам. Я просто запускал в docker-compose окружение, прогонял тестовые сценарии, потом смотрел табличку с сортировкой по проблемным запросам (время выполнения и наличие seq scan).
Ужас. Я не хотел бы переходить на личности, но это прям даже звучит дико. Если вы не знаете что пишите, то как пишите? Методом научно-ненаучного тыка? По вдохновению правой пятки? Возможно с таким подходом TDD и правда мешать будет. Возможно проблема не в методологии.
Смысл написания тестов до кода, что тесты проверяют функциональность, которая требуется. Если нет требований, то что конечно тесты не написать. Но говорить о вреде TDD просто потому что у вас процессы... ну мягко скажем не очень, как минимум глупо.
Внуки, видимо, в steam не умеют, раз шугаются. Или привыкли пиратить, откуда и проблемы были.
А я думал, что это я псих, когда маму на Kubuntu перетащил. Но есть и попсихованнее.
Нее, ну это скучно. Если глаза не красные от того, что неделю пытаешься собрать ядро так, чтобы запустить какую-нибудь экзотическую звуковуху, а домашние, соседи, коллеги и парочка суперкомпьютеров не написали вам гневное письмо, что не надо использовать их ресурсы для того, чтобы пересобрать "мир" с новымы USE-флагами для 1% оптимизации работы, то не уверен, что это вообще линуксовый опыт. Попса какая-то и виндузятничество.
P.S.: Это лютый сарказм, если что, и океан самоиронии про студенческие годы.