Правильно ли я понял, что при обновлении воркер узлов, вы просто обновляете kubelet и рестартуете его?
Как я понял, из кучи кластеров и нод, у вас всего один раз он не поднялся. Просто в доке советуют делать drain, но это так долго =(. А вы обновили столько нод, и практически в 99.99% случаев kubelet успешно поднялся, похоже в доке перегибают с осторожностью?
В первую очередь это нужно чтобы любой мастер можно было выключить в любой момент и легко пережить аварию/обслуживание
Тогда мне непонятно как вы этого достигли. Ранее вы писали:
Одна нода приложения работает с одним мастером, но все ноды поделены на 4 «зоны», это просто 4 разных окружения
У вас бэкенды поделены на 4 типа, и каждый пишет в свой мастер. В такой конфигурации непонятно, как можно в любой момент отключить хоть один мастер. Тут только наверное если использовать какой-то proxy, например proxysql, который видит что мастер упал/отключен и в этом случае направляет трафик бэкенда на другой мастер.
У меня один мастер. Я пробовал slave_parallel_type=LOGICAL_CLOCK и разное количество воркеров. Это никак не помогает. Параллельность выполнения проверял как в этой статье. Но теперь я знаю что эту ситуацию можно улучшить с помощью binlog_transaction_dependency_tracking.
Я кажется понял зачем в вашей схеме несколько мастеров. Видимо для того чтобы ускорить репликацию, так как вместо одного канала, появляется несколько каналов репликации. Так как сами мастера это же не разгружает, всё равно все запросы на запись попадают на каждый мастер.
О, спасибо. Я похоже не внимательно читал доку. Не знал что эта опция может улучшить параллельность выполнения.
Получается binlog_transaction_dependency_tracking=WRITESET, требует transaction_write_set_extraction=XXHASH64 (или MURMUR32). А transaction_write_set_extraction в свою очередь требует binlog_format=ROW.
Итого:
а расскажите пожалуйста подробнее про несколько потоков репликации, я о такой фиче не знаю. Пробовал slave_parallel_workers, но оно плохо параллелит и по сути никак не ускоряет репликацию в моем кейсе. Потоки это что-то другое, или вы про эту настройку?
Ну так это другой вопрос. Вопрос безопасного хранения секретов в k8s vs хранения их в vault. Понятно что в vault с этим лучше, поскольку это ПО которое именно для этого предназначено.
Теперь сравните это с тем, в скольких местах мы можем у кубера это все дело прочитать
А давайте сравним, эта информация будет полезна многим. Раз уж утверждаете, то давайте по существу и с аргументами. В каких местах можно несанкционированно прочитать секреты куба, не имея к ним доступ по RBAC?
Но я так и не понял, как к этому относится формат хранения секретов куба(base64). По этой логике, когда я сохраняю секрет в vault в строке формата base64, то он становится небезопасным?
Отличная безопасность когда все секреты лежат в base64 — прям непрошибаемая!
Эм, это все равно что сказать: секреты в vault хранятся в открытом тексте, потому что я могу их прочитать когда у меня есть к ним доступ: vault kv get secret. Или пароль небезопасный, потому что мне его сообщили.
Мы можем прочитать base64 секрета в кубе, когда мы имеем к нему доступ, ровно также как и в vault. base64 очевидно там для удобства хранения бинарных данных. Секреты в кубе в etcd хранятся в шифрованном виде, при монтировании в pod'ы как файлов, секреты всегда хранятся в памяти, и монтируются в tmpfs и никогда не сохраняются на диске узла. Многим этого достаточно, а кому недостаточно и нужно централизованное хранение секретов, используют vault и интегрируют его с кластерами k8s.
Мне не нравится что в статье категорично сравнивают две крайности облако и свой цод куда железки везут месяц.
В том же hetzner стоковые железки ты получаешь через 15 минут после заказа. Если надо автоматически быстро масштабироваться, берёшь у них же виртуалки через api.
Также мне не нравится что всегда говорят облако дешевле, но реальных цифр не приводят. Потому что мои подсчёты на конкретном кейсе говорят об обратном. Наверняка есть кейсы когда облако действительно дешевле, например при сочетании маленьких нагрузок и очень сложной инфраструктуры, когда за обслуживание инфраструктуры бизнес платит больше чем за саму инфраструктуру. То есть хотелось бы не маркетинга, а истории вот мы перешли в amazon с servers.com, с экономили 20 000$ на таких-то вещах. Или подробный и честный разбор всех нюансов. Просто сейчас складывается ощущение, что в сообществе априори облака считаются дешевле, а если ты начинаешь разговор об этом, тебя считают маргиналом.
Мне не нравится что в статье категорично сравнивают две крайности облако и свой цод.
В том же hetzner стоковые железки ты получаешь через 15 минут после заказа. Если надо автоматически быстро масштабироваться, берёшь у них же виртуалки через api.
Также мне не нравится что всегда говорят облако дешевле, но реальных цифр не приводят. Потому что мои подсчёты на конкретном кейсе говорят об обратном. Наверняка есть кейсы когда облако действительно дешевле, например при сочетании маленьких нагрузок и очень сложной инфраструктуры, когда за обслуживание инфраструктуры бизнес платит больше чем за саму инфраструктуру. То есть хотелось бы не маркетинга, а истории вот мы перешли в amazon с servers.com, с экономили 20 000$ на таких-то вещах. Или подробный и честный разбор всех нюансов. Просто сейчас складывается ощущение, что в сообществе априори облака считаются дешевле, а если ты начинаешь разговор об этом, тебя считают маргиналом.
Сапппорт в hetzner не классный, но он в разы лучше ботов в амазон. Да весь дц может стать недоступен, как и az в амазон, что я тоже наблюдал. Что в амазон, что в hetzner надо все дублировать в разных az/дц.
Согласен, если нужна хорошая надёжность и sla 99.999 то с hetzner не по пути
Проблемы поддержки своей инфраструктуры:
Высокая стоимость и низкая надёжность
amazon RDS: single az, db.m6g.8xlarge (виртуалка), 32 vCPUs, 128GiB озу, 1800GiB Provisioned IOPS (SSD), 3000 iops. Стоймость — 2732$ в месяц.
Частые проблемы, тормозит, тех поддержка отвечает очень долго и невнятно, надо доказывать что ты не верблюд.
hetzner: AX161(железка), AMD EPYC 7502P 32-Core "Rome" (Zen2), 128 GB DDR4 ECC RAM, два локальных nvme диска на 1.92 TB (NVMe SSD Datacenter Edition). Стоймость 109 + 53(диски) = 162€. Берем таких три, для построения отказоустойчивости. Итого 162*3 = 486€ в месяц.
Не тормозит, 50,80,90,95 перцентли по времени запроса гораздо лучше(ниже) чем в RDS, в случае проблем с железом тех. поддержка отвечает за 10-30 минут, довольно подробно отвечают в случае проблем.
Масштабируем на мой кейс, таких СУБД около 9.
AWS RDS: 9 * 2732 = 24 588$ в месяц.
hetzner: 9 * 486 = 4374€ в месяц.
Разница в ~5 раз. При этом rds проигрывает по производительности.
На оба случая нужны devops инженеры и примерно одинаковое количество. Спецы по облакам стоят дороже.
Можно посчитать остальную инфраструктуру, и порядок разницы увеличивается всё больше, особенно за трафик. Если требуется горизонтально масштабировать приложение, это можно делать и на таких хостерах как hetzner, так как там можно создавать виртуалки через api.
Я несколько раз считал во сколько обойдется в amazon инфраструктура компании где я работаю, и это всегда примерно в 5-8 раз дороже. А везде пишут должно быть дешевле. Скорее всего я где-то допускаю серьезную ошибку.
puppet для удаления ресурса, который не описан, использует метод модуля absent, без разницы какой модуль, он будет вызывать этот метод нужного модуля. В ansible в модулях тоже есть такой метод, но он просто не будет вызван, поскольку ansible ничего не знает о ресурсах, которые в нем не в плейбуках, но они есть на хосте и могут сломать конфигурацию итоговую.
и не должно быть общим для разных ресурсов
Если писать свои костыли для очистки, конечно не должно.
никаких скриптов
Угу, оно и видно. Вместо ресурсов такси, вместо графа зависимостей, копирование кода на хост и выполнение его по порядку. Упала какая-то таска, handler не выполнился. Обычный императивный скрипт на мой взгляд, хоть и оформлен в yaml формате. Но в этом одновременно и приемущество ansible на задачах не про управление конфигурациями.
если прям нужно такое, хотя не понимаю зачем — никто не мешает сначала удалить все файлы
Это плохое решение и оно не общее для любых типов ресурсов. Аналогичное с правилами iptables или правами к базе приведет к ужасным последствиям. Да и каждый раз удалять все файлы при применении конфигурации это дичь. Если ничего не поменялось, то не надо это менять, а в таком решении мы получим статус о changed task'ах — при любых прогонах. Опять скрипты вместо управления конфигурациями.
terraform всё таки позиционируется на провижионе инфраструктуры, а не управлении софтом на серверах. О чём честно пишут в доках:
Terraform is not a configuration management tool
контекст:
Configuration management tools install and manage software on a machine that already exists. Terraform is not a configuration management tool, and it allows existing tooling to focus on their strengths: bootstrapping and initializing resources.
Terraform focuses on the higher-level abstraction of the datacenter and associated services, while allowing you to use configuration management tools on individual systems. It also aims to bring the same benefits of codification of your system configuration to infrastructure management.
If you are using traditional configuration management within your compute instances, you can use Terraform to configure bootstrapping software like cloud-init to activate your configuration management software on first system boot.
А мне кажется логично. Если я описал в системе управления конфигурациями как должна выглядеть директория /etc/nginx/conf.d и конфигурации в ней, я ожидаю что система будет всегда делать её такой, какой я описал. А если кто-то что-то там поменял, например добавил файл, то естественно это уже не то что я описал в коде, поэтому файл должен быть удалён. Более того, такой лишний файл конфигурации может сломать всю конфигурацию nginx, поэтому от системы управления конфигурациями я ожидаю больших гарантий того, как она за этим следит.
Тоже самое и с правилами iptables и другими вещами. Я не говорю что это имеет смысл во всём, но такая возможность у системы конфигураций должна быть на мой взгляд.
декларация состояния системы после применения одного плэя
Не одного play, а одного task по идее, в одном play нет декларативности, поскольку там несколько task'ов могут описать один и тот же объект с разными состояниями. Если бы была декларативность на уровне одного play, то это уже было бы неплохо.
На мой взгляд декларативность не может применяться к одному объекту с одним действием/описанием над ним. Например:
a = 10
Конечно такая конструкция всегда декларативна, в любом языке, пока она не превратится в такую:
a = 10
...
...
a = 12
Декларативность это как раз про декларацию полного состояния, как это делает terraform например.
Ну это печально что тут сказать. Из всех ролей вытаскивать task'и определенного модуля, чтобы реализовать хоть какой-то purge — сильно неудобное в поддержке решение и оно совсем не будет работать как в puppet. Так как puppet просто применяет absent ко всем ресурсам которые не описаны, ansible так не может сделать принципиально.
Даже если обложиться костылями, и занести все эти ресурсы в один play, что уже неудобно, можно сказать не юзабельно, и нет никакой гарантии что такие ресурсы никогда не попадут в другие роли. Придется реализовать своими силами само удаление этих ресурсов и это будет не тоже самое что вызвать absent модуля этих ресурсов.
Либо давайте пример такой task'и purge. Я вангую там будет очередной костыль в виде shell скрипта или в лучшем случае отдельный модуль, который удаляет ресурсы, отсутствующие в контексте play, но эти решения оба плохи, так как такие ресурсы должны управляться родным модулем и удалятся его средствами через absent.
Также такое решение ужасно с точки зрения надежности. Легко забыть и добавить task в какую-нибудь роль, а потом обнаружить что результат выполнения такого таска будет удален или не удален, зависит от порядка выполнения, что очередной раз нам показывает императивную природу ansible.
Поэтому "можно реализовать" — это лукавство. Можно, но с кучей ограничений, таких что пользоваться таким решением просто невозможно. Причина этих ограничений: другая архитектура, слабая декларативность, императивная природа инструмента. Это принципиальные отличия.
Зачем вы удаляете и создаете ту же директорию?
Я везде где писал эту конструкцию, указывал ее в качестве примера недостаточной декларативности ansible. Она валидна для ansible, он её успешно выполняет. В декларативном описании один и тот же объект не может быть разным одновременно, он должен быть константой, а не переменной. Ваш вопрос бессмысленен, и похож на прием демагогии: вы пытаетесь выставить меня глупо, будто я эту конструкцию использую, и что-то хочу с помощью неё сделать.
В другом треде вы мне приписывали, что я меняю условия задачи, хотя это не так. Тоже похоже на демагогический приём.
Не вижу смысла дальше дискутировать, пока тред не превратился в демагогию окончательно.
это есть из коробки в werf, советую попробовать. Запушенные в kubernetes образы он также не чистит.
А как это сделано, вручную? Или Deckhouse при обновлении умеет автоматически выкручивать replicas этих компонентов в ноль?
Правильно ли я понял, что при обновлении воркер узлов, вы просто обновляете kubelet и рестартуете его?
Как я понял, из кучи кластеров и нод, у вас всего один раз он не поднялся. Просто в доке советуют делать drain, но это так долго =(. А вы обновили столько нод, и практически в 99.99% случаев kubelet успешно поднялся, похоже в доке перегибают с осторожностью?
Тогда мне непонятно как вы этого достигли. Ранее вы писали:
У вас бэкенды поделены на 4 типа, и каждый пишет в свой мастер. В такой конфигурации непонятно, как можно в любой момент отключить хоть один мастер. Тут только наверное если использовать какой-то proxy, например proxysql, который видит что мастер упал/отключен и в этом случае направляет трафик бэкенда на другой мастер.
У меня один мастер. Я пробовал
slave_parallel_type=LOGICAL_CLOCKи разное количество воркеров. Это никак не помогает. Параллельность выполнения проверял как в этой статье. Но теперь я знаю что эту ситуацию можно улучшить с помощью binlog_transaction_dependency_tracking.Я кажется понял зачем в вашей схеме несколько мастеров. Видимо для того чтобы ускорить репликацию, так как вместо одного канала, появляется несколько каналов репликации. Так как сами мастера это же не разгружает, всё равно все запросы на запись попадают на каждый мастер.
О, спасибо. Я похоже не внимательно читал доку. Не знал что эта опция может улучшить параллельность выполнения.
Получается
binlog_transaction_dependency_tracking=WRITESET, требуетtransaction_write_set_extraction=XXHASH64(илиMURMUR32). А transaction_write_set_extraction в свою очередь требуетbinlog_format=ROW.Итого:
Эх, не хотел на ROW формат переходить. Уж очень много места сьедает, сейчас итак за ден, бинлоги на 250GiB скапливаются.
а расскажите пожалуйста подробнее про несколько потоков репликации, я о такой фиче не знаю. Пробовал slave_parallel_workers, но оно плохо параллелит и по сути никак не ускоряет репликацию в моем кейсе. Потоки это что-то другое, или вы про эту настройку?
Ну так это другой вопрос. Вопрос безопасного хранения секретов в k8s vs хранения их в vault. Понятно что в vault с этим лучше, поскольку это ПО которое именно для этого предназначено.
А давайте сравним, эта информация будет полезна многим. Раз уж утверждаете, то давайте по существу и с аргументами. В каких местах можно несанкционированно прочитать секреты куба, не имея к ним доступ по RBAC?
Но я так и не понял, как к этому относится формат хранения секретов куба(base64). По этой логике, когда я сохраняю секрет в vault в строке формата base64, то он становится небезопасным?
Эм, это все равно что сказать: секреты в vault хранятся в открытом тексте, потому что я могу их прочитать когда у меня есть к ним доступ:
vault kv get secret. Или пароль небезопасный, потому что мне его сообщили.Мы можем прочитать base64 секрета в кубе, когда мы имеем к нему доступ, ровно также как и в vault. base64 очевидно там для удобства хранения бинарных данных. Секреты в кубе в etcd хранятся в шифрованном виде, при монтировании в pod'ы как файлов, секреты всегда хранятся в памяти, и монтируются в tmpfs и никогда не сохраняются на диске узла. Многим этого достаточно, а кому недостаточно и нужно централизованное хранение секретов, используют vault и интегрируют его с кластерами k8s.
Мне не нравится что в статье категорично сравнивают две крайности облако и свой цод куда железки везут месяц.
В том же hetzner стоковые железки ты получаешь через 15 минут после заказа. Если надо автоматически быстро масштабироваться, берёшь у них же виртуалки через api.
Также мне не нравится что всегда говорят облако дешевле, но реальных цифр не приводят. Потому что мои подсчёты на конкретном кейсе говорят об обратном. Наверняка есть кейсы когда облако действительно дешевле, например при сочетании маленьких нагрузок и очень сложной инфраструктуры, когда за обслуживание инфраструктуры бизнес платит больше чем за саму инфраструктуру. То есть хотелось бы не маркетинга, а истории вот мы перешли в amazon с servers.com, с экономили 20 000$ на таких-то вещах. Или подробный и честный разбор всех нюансов. Просто сейчас складывается ощущение, что в сообществе априори облака считаются дешевле, а если ты начинаешь разговор об этом, тебя считают маргиналом.
Мне не нравится что в статье категорично сравнивают две крайности облако и свой цод.
В том же hetzner стоковые железки ты получаешь через 15 минут после заказа. Если надо автоматически быстро масштабироваться, берёшь у них же виртуалки через api.
Также мне не нравится что всегда говорят облако дешевле, но реальных цифр не приводят. Потому что мои подсчёты на конкретном кейсе говорят об обратном. Наверняка есть кейсы когда облако действительно дешевле, например при сочетании маленьких нагрузок и очень сложной инфраструктуры, когда за обслуживание инфраструктуры бизнес платит больше чем за саму инфраструктуру. То есть хотелось бы не маркетинга, а истории вот мы перешли в amazon с servers.com, с экономили 20 000$ на таких-то вещах. Или подробный и честный разбор всех нюансов. Просто сейчас складывается ощущение, что в сообществе априори облака считаются дешевле, а если ты начинаешь разговор об этом, тебя считают маргиналом.
P. S. Промахнулся ответом, извините.
Сапппорт в hetzner не классный, но он в разы лучше ботов в амазон. Да весь дц может стать недоступен, как и az в амазон, что я тоже наблюдал. Что в амазон, что в hetzner надо все дублировать в разных az/дц.
Согласен, если нужна хорошая надёжность и sla 99.999 то с hetzner не по пути
amazon RDS: single az, db.m6g.8xlarge (виртуалка), 32 vCPUs, 128GiB озу, 1800GiB Provisioned IOPS (SSD), 3000 iops. Стоймость — 2732$ в месяц.
Частые проблемы, тормозит, тех поддержка отвечает очень долго и невнятно, надо доказывать что ты не верблюд.
hetzner: AX161(железка), AMD EPYC 7502P 32-Core "Rome" (Zen2), 128 GB DDR4 ECC RAM, два локальных nvme диска на 1.92 TB (NVMe SSD Datacenter Edition). Стоймость 109 + 53(диски) = 162€. Берем таких три, для построения отказоустойчивости. Итого 162*3 = 486€ в месяц.
Не тормозит, 50,80,90,95 перцентли по времени запроса гораздо лучше(ниже) чем в RDS, в случае проблем с железом тех. поддержка отвечает за 10-30 минут, довольно подробно отвечают в случае проблем.
Масштабируем на мой кейс, таких СУБД около 9.
AWS RDS:
9 * 2732= 24 588$ в месяц.hetzner:
9 * 486= 4374€ в месяц.Разница в ~5 раз. При этом rds проигрывает по производительности.
На оба случая нужны devops инженеры и примерно одинаковое количество. Спецы по облакам стоят дороже.
Можно посчитать остальную инфраструктуру, и порядок разницы увеличивается всё больше, особенно за трафик. Если требуется горизонтально масштабировать приложение, это можно делать и на таких хостерах как hetzner, так как там можно создавать виртуалки через api.
Я несколько раз считал во сколько обойдется в amazon инфраструктура компании где я работаю, и это всегда примерно в 5-8 раз дороже. А везде пишут должно быть дешевле. Скорее всего я где-то допускаю серьезную ошибку.
В Jenkins тоже есть возможность параллельного выполнения в рамках разных фаз конвейера: https://www.jenkins.io/doc/book/pipeline/syntax/#parallel
puppet для удаления ресурса, который не описан, использует метод модуля absent, без разницы какой модуль, он будет вызывать этот метод нужного модуля. В ansible в модулях тоже есть такой метод, но он просто не будет вызван, поскольку ansible ничего не знает о ресурсах, которые в нем не в плейбуках, но они есть на хосте и могут сломать конфигурацию итоговую.
Если писать свои костыли для очистки, конечно не должно.
Угу, оно и видно. Вместо ресурсов такси, вместо графа зависимостей, копирование кода на хост и выполнение его по порядку. Упала какая-то таска, handler не выполнился. Обычный императивный скрипт на мой взгляд, хоть и оформлен в yaml формате. Но в этом одновременно и приемущество ansible на задачах не про управление конфигурациями.
Это плохое решение и оно не общее для любых типов ресурсов. Аналогичное с правилами iptables или правами к базе приведет к ужасным последствиям. Да и каждый раз удалять все файлы при применении конфигурации это дичь. Если ничего не поменялось, то не надо это менять, а в таком решении мы получим статус о changed task'ах — при любых прогонах. Опять скрипты вместо управления конфигурациями.
terraform всё таки позиционируется на провижионе инфраструктуры, а не управлении софтом на серверах. О чём честно пишут в доках:
контекст:
Configuration management tools install and manage software on a machine that already exists. Terraform is not a configuration management tool, and it allows existing tooling to focus on their strengths: bootstrapping and initializing resources.
Terraform focuses on the higher-level abstraction of the datacenter and associated services, while allowing you to use configuration management tools on individual systems. It also aims to bring the same benefits of codification of your system configuration to infrastructure management.
If you are using traditional configuration management within your compute instances, you can use Terraform to configure bootstrapping software like cloud-init to activate your configuration management software on first system boot.
И советуют совмещать эти инструменты, если нужно.
А мне кажется логично. Если я описал в системе управления конфигурациями как должна выглядеть директория /etc/nginx/conf.d и конфигурации в ней, я ожидаю что система будет всегда делать её такой, какой я описал. А если кто-то что-то там поменял, например добавил файл, то естественно это уже не то что я описал в коде, поэтому файл должен быть удалён. Более того, такой лишний файл конфигурации может сломать всю конфигурацию nginx, поэтому от системы управления конфигурациями я ожидаю больших гарантий того, как она за этим следит.
Тоже самое и с правилами iptables и другими вещами. Я не говорю что это имеет смысл во всём, но такая возможность у системы конфигураций должна быть на мой взгляд.
Не одного play, а одного task по идее, в одном play нет декларативности, поскольку там несколько task'ов могут описать один и тот же объект с разными состояниями. Если бы была декларативность на уровне одного play, то это уже было бы неплохо.
На мой взгляд декларативность не может применяться к одному объекту с одним действием/описанием над ним. Например:
Конечно такая конструкция всегда декларативна, в любом языке, пока она не превратится в такую:
Декларативность это как раз про декларацию полного состояния, как это делает terraform например.
Ну это печально что тут сказать. Из всех ролей вытаскивать task'и определенного модуля, чтобы реализовать хоть какой-то purge — сильно неудобное в поддержке решение и оно совсем не будет работать как в puppet. Так как puppet просто применяет absent ко всем ресурсам которые не описаны, ansible так не может сделать принципиально.
Даже если обложиться костылями, и занести все эти ресурсы в один play, что уже неудобно, можно сказать не юзабельно, и нет никакой гарантии что такие ресурсы никогда не попадут в другие роли. Придется реализовать своими силами само удаление этих ресурсов и это будет не тоже самое что вызвать absent модуля этих ресурсов.
Либо давайте пример такой task'и purge. Я вангую там будет очередной костыль в виде shell скрипта или в лучшем случае отдельный модуль, который удаляет ресурсы, отсутствующие в контексте play, но эти решения оба плохи, так как такие ресурсы должны управляться родным модулем и удалятся его средствами через absent.
Также такое решение ужасно с точки зрения надежности. Легко забыть и добавить task в какую-нибудь роль, а потом обнаружить что результат выполнения такого таска будет удален или не удален, зависит от порядка выполнения, что очередной раз нам показывает императивную природу ansible.
Поэтому "можно реализовать" — это лукавство. Можно, но с кучей ограничений, таких что пользоваться таким решением просто невозможно. Причина этих ограничений: другая архитектура, слабая декларативность, императивная природа инструмента. Это принципиальные отличия.
Я везде где писал эту конструкцию, указывал ее в качестве примера недостаточной декларативности ansible. Она валидна для ansible, он её успешно выполняет. В декларативном описании один и тот же объект не может быть разным одновременно, он должен быть константой, а не переменной. Ваш вопрос бессмысленен, и похож на прием демагогии: вы пытаетесь выставить меня глупо, будто я эту конструкцию использую, и что-то хочу с помощью неё сделать.
В другом треде вы мне приписывали, что я меняю условия задачи, хотя это не так. Тоже похоже на демагогический приём.
Не вижу смысла дальше дискутировать, пока тред не превратился в демагогию окончательно.