Если ваш проект планирует оказаться в K8s, то желательно на docker-compose и не останавливаться, а потратить немного времени и сразу начинать в K8s. Сейчас его базовый функционал гораздо более user friendly, чем когда-то. А то у вас тесты и т.д. в compose, а prod в K8s и окружения не одинаковые получаются, хоть и похожие. А потом вам надо будет потратить время на переписывания всех этих тестов и т.п., что мало кто делает.
Есть такой замечательный продукт: k3d, который можно использовать на Gitlab runner'е, посмотрите на него (кубер в докере, можно создавать одновременно несколько кластеров на одной машине). На машинах у разработчиков можно также использовать его или его брата k3s (кубер не в докере, управляется systemd). K3s CNCF certified.
Так я вам и подсказываю решение для динамического создания окружений для MR в кубере: k3d (помимо создания нового namespace под каждый MR, конечно, что иногда не удобно). K3d - это по сути кубер в докере. Использую его на проектах, отлично себя показывает как раз в том числе для прогона тестов для MR/PR. Им в том числе можно создавать много изолированных кластеров на одном Gitlab runner'е.
Похоже я начинаю повторяться, но не могу оставить это как есть.
Никаких вопросов к «задаче» статьи, но в ходе сранения формулируется посыл о невозможности реализации чего либо «встроенными» командами Docker и возможности реализации этого с помощью werf. У докера все команды «встроенные», werf использует api docker daemon, является клеем и т.д., поэтому уверен, что при детальном разборе любой ситуации окажется, что это реализуемо/возможно и с помощью «встроенных» команд Docker, определённой правильной для конкретной ситуации последовательности в реализации multi stage build'ов и т.д., просто для этого нужно явно знать как это настраивать и потратить на это, возможго немало, дополнительного времени, а werf это делает из коробки и за вас.
Но "реализуемо за дополнительное время" != "нереализуемо".
Не могу сказать что там супер сложного в multistage
На практике, --cache-from работает 50/50. Когда работает, а когда нет, что может критично сказаться на времени пайплайна. Почему и по какой причине так происходит я устал разбираться
У всего есть причины. Не разобрались и werf решил вашу проблему за вас, супер! Ни коим образом не говорю, что нужно всё билдить только докером или вместо apt только из исходников :) Лишь указываю на некорректность формулирования в статье некоторых моментов, которые звучат как "это невозможно с докер и возможно с werf". Это не так, как и, я уверен, в вашем случае.
Я вам конкретно говорю, что в статье сформулировано так, что docker что-то не умеет, а werf умеет. Это не так.
Про то что вы реализуете уровни абстракции поверх всего этого и в итоге связывая всё этого воедино экономите для всех время, деньги и принуждать их к использованию best practices кэширования это понятно.
позволяет делать больше, чем Docker может со слоями
Опять же: сомнительно по вышеописанным мной причинам, но, надеюсь, что ошибаюсь и обязательно проверю на практике :)
Давайте по пунктам? Тогда обсуждение будет предметным, а не эмоциональным ;-)
А где вы увидели эмоции с моей стороны? :)
Создание подобного продукта — огромные инвестиции. Если на рынке уже есть всё готовое для тех же задач, зачем нам ввязываться в такую сложную и многолетнюю разработку? Да ещё и делать это в рамках Open Source-проекта, инвестиции в который больше
Навскидку (и это всё положительные и правильные шаги):
1) процесс работы над собственным opensource проектом внутри компании реализует некий team building. Уверен, что ребята работают над ним не только в рабочее время, как и все, кто участвует в opensource.
2) лишнее подтверждение для клиентов, которым это решение внедряется в состоятельности и крутости компании.
3) вы регулярно реализуете некие решения у клиентов и решили написать собственный продукт, который бы реализовывал хотя бы часть best practices по части multi stage docker builds и т.п. чтобы каждый ваш инженер не реализовывал это на свой вкус и это было бы стандартизированно + в целом это экономия времени для компании, а значит денег.
…
Про маркетинг я упомянул в контексте того, что в статье всё же некоторые вещи про docker описываются как невозможные и возможные только с werf, тогда как это не так.
Тогда мысль следующая: у микросервисов есть ряд серьёзных проблем, о которых вам, наверное, тоже известно.
И это не отменяет плюсов в их использовании, как вам прекрасно известно.
Так вот использование маленьких утилит — с тем, чтобы у каждой было свое одно дело, — иногда действительно может быть оптимальным. Однако, по нашему опыту, со временем это удобство сопряжено с рядом проблем (как их между собой интегрировать, как потом в этой схеме что-то менять и в целом поддерживать).
Использовать точно такой же подход, как к микросервисам, конечно. Другое дело, что каждый инженер может начать лепить что-то своё и не то что описать интерфейсы взаимодействия между тегированием и пушем образов достаточно сложно, это не сложно, а сложно проконтроллировать фактическую реализацию. werf я так понимаю решает часть этой проблемы, т.к. забирает конвенцию по именованию и по использованию кэширования под капот. Но это опять же не значит, что всего этого нет для отдельных утилит, как мне кажется подаётся в статье. Поэтому с вашим утверждением
werf интегрирует эти стандартные инструменты и расширяет их возможности для конечного удобства пользователей
не соглашусь по части «расширяет их возможности». В статье не увидел ничего, что нельзя было бы реализовать не с помощью werf.
В целом для меня это похоже на сравнение Jenkins и Gitlab: в Gitlab многое сделано за вас и склеено, но это не значит, что это нельзя реализовать в Jenkins :)
Но это всё слова основанные на статье. Планирую обязательно пощупать werf, выглядит достаточно интересно и возможно напишу неафилированную статью.
Функционал выстраивается поверх кода из upstream, а также мы делаем свой вклад в развитие используемых проектов, участвуем в обсуждении проблем и непосредственно в разработке
Супер, надеюсь так и будет продолжаться, тем более, что звёзд на Github у вас уже очень даже прилично.
А есть какие-то конкретные замечания, спорные моменты?
Есть. Замечание по подаче информации в статье в формате: «в docker этого нет, а в werf есть».
Например, пользователю не нужно думать о тегировании образа и о том, что хранится в container registry
«Пользователю», т.е., условно, «разработчику», может быть и не нужно, но ci/cd пайплайны обычно выстраивают релиз инженеры или DevOps'ы/SRE и им нужно и думать и понимать что, куда и как выкатывается. Делается это тегами или вашим изобретением в виде… имён контейнеров, т.е. более вручную или более автоматизированно это в контексте моего комментария уже вторичный момент, т.к. в werf вы судя по тому, что я прочёл в статье, вы идёте по пути условного Apple или Gitlab и решаете за пользователя в каком виде ему что лучше иметь на выходе.
Как следствие, в werf нет понятий tag и push — эти процедуры встроены в werf build
Понятия то может и нет, но если вы просто объединили эти процессы под капотом, то это не значит, что это не происходит, т.е. у вас, вместо `docker build -t example. && docker push example` происходит условный `werf build example`
werf экономит время на сборку, собирая только те образы, или слои образа, которые требуются для текущего коммита и которых еще нет в container registry. Вдобавок, экономится место, поскольку нет необходимости повторно сохранять образ в реестре.
Multistage builds не все могут освоить, там много фишек и вы наверное по сути реализовали многое из этого под капотом werf, но это не значит, что этих механизмов не существует в обычном docker, как мне кажется подаётся в статье. Думаю при грамотной настройке multistage build docker скорость сборки не будет отличаться от werf.
Также во всех широко распространённых docker registry, например Gitlab, есть механизм использования слоёв из других контейнеров, который задействуются при сохранении/push новых образов именно с описанными вами целями. Пример: $ docker push $CI_REGISTRY_IMAGE/example
The push refers to repository [registry.gitlab.com/example]
4804b936f9fb: Preparing
4e680695ab1f: Preparing
f05ab25ed134: Preparing
f65353d0c4cd: Preparing
fafbb6872cae: Preparing
56456681cc56: Preparing
5c92c7ad7044: Preparing
777b2c648970: Preparing
5c92c7ad7044: Waiting
777b2c648970: Waiting
56456681cc56: Waiting
4e680695ab1f: Layer already exists
f65353d0c4cd: Layer already exists
fafbb6872cae: Layer already exists
f05ab25ed134: Layer already exists
777b2c648970: Layer already exists
5c92c7ad7044: Layer already exists
56456681cc56: Layer already exists
4804b936f9fb: Pushed
1.8.3-alpine: digest: sha256:07d028c89da81f460e0442f5f50275a878765aef43df0bb71dc0840d31f1c9bf size: 1987
Cleaning up file based variables
00:01
Job succeeded
Ещё раз повторюсь: существует множество best practices для различного рода кэширования, которые многие не используют ввиду неопытности и werf похоже заполняет этот пробел в знаниях новичков просто задействуя эти механизмы и реализуя их как бы за них. Но как мне кажется в статье информация подаётся в таком виде, что этих механизмов нет вообще или они сильно уступают werf. Это конечно же не так. В добавок по вашему собственному утверждению
Функционал выстраивается поверх кода из upstream
и схема с использованием docker daemon тоже про это.
Хоть инструмент ваша команда и написала интересный, респект, похоже есть интересные фишки, но многое в статье сомнительно и похоже на маркетинг. Некоторые утверждения ложные и желаемое выдаётся за действительное. Докер умеет много что из того, что в статье преподносится, как невозможное. Возможно из коробки с werf это проще, но говорить, что невозможно не нужно.
Отдельно замечу, что эдакий мультикомбайн напоминает монолит, от которых мы все как раз пытаемся уйти к микросервисам. Да, иногда бывает удобно в образ поставить несколько утилит для сборки/деплоя и т.п. А тут прямо и helm и docker и ещё что-то... Не уверен, что это работает и главное будет в будущем работать лучше, чем вышеупомянутое, ведь там его поддерживает гораздо большее коммьюнити.
Не соглашусь с тем, что это хоть и базовое решение, но подходит лишь для ситуации, когда вы единственный owner/maintainer.
Чаще всего так или иначе бывает человек или группа людей с привилегированным доступом, назовём её админы. Они должны иметь доступ к паролям прода. Это очень базовый сценарий, но допустим так.
И есть вторая группа, назовём её разработчики. Они не являются ни owner'ами ни maintainer'ами репозитория. Доступа к переменным не имеют. И даже в бесплатном Gitlab сейчас достаточно гибко настраиваются роли для работы с репозиторием, т.е. если разработчики не owner'ы и не maintainer'ы, то всё равно могут делать то, что нужно делать. Остальное это просто "хотим видеть то, что видели раньше, а сейчас почему-то нельзя", но из практики в 95+% это чепуха. Далее для, например, dev окружения (environment scope) переменные делаются не masked, а обычными и не protected. Теоретически для dev окружений конечно можно было бы и чуть ли не в коде переменные хранить, но есть высокая вероятность, что когда будете выкатывать на следующее окружение, то ошибетесь и будет плохо. Не советую так делать.
Многие проекты даже до этого уровня не дорастают, хотя это уже гораздо лучше хранения секретов в коде репы и никакого стороннего софта. Вот когда дальше уже нужно гибко настраивать роли по определённым группам и переменным, нужны логи обращения к ним и т.д, вот там нужен vault.
Но я бы рекомендовал начать с простого. Далее не проблема перенести переменные из Gitlab в Vault, если это вообще когда либо понадобится (многим нет), т.к. у Gitlab прекрасно работающий api для работы в том числе с переменными.
Например, можно было просто вынести пароли в переменные окружения CI/CD системы и не ломать голову. В этом случае у меня не было уверенности в том, что пароль не утечёт через добавление в CI-пайплайн строки echo $DB_PASSWORD
Это конечно самый базовый, но вполне рабочий вариант до которого многим хотя бы дорасти:
в Gitlab существует функция маскировки как раз для таких случаев (masked)
+ переменную можно сделать protected, чтобы просто так в какой-то произвольной ветке нет могли с ней пытаться что-то делать
+ у переменных можно делать разные environment scope, т.е. например может быть несколько переменных с одним и тем же именем, но значение для разных окружений будут разные.
Ив итоге можно относительно гибко задавать где они protected и masked, а где нет. Всё это в совокупности позволяет на достаточно базовом уровне решать проблемы с переменными в репозиториях без какого-то дополнительного софта.
Environment scope: (Optional) All, or specific environments.
Protect variable (Optional): If selected, the variable is only available in pipelines that run on protected branches or tags.
Mask variable (Optional): If selected, the variable’s Value is masked in job logs. The variable fails to save if the value does not meet the masking requirements.
Думаю, что "забуксовать" имелось ввиду бабушке в понимании, когда она услышит "оркестратор", а не вам в освоении.
Про необходимость 7 серверов для отказоустойчивого K8s в большинстве случаев: вы ошибаетесь, т.к. в большинстве случаев ставить etcd на отдельные сервера смысла нет, а для большинства проектов облачный K8s вообще позаботится о вас о мастерах.
И если кого шибко важного и крупного не указал, так это не по причине моей зловредности, а потому что реклама у них слабенькая. Ну, и или страницы в поиске глубоко находятся.
Рассматривали какой-то хлам вместо топ 3:
1) Amazon - Elastic Kubernetes Service
2) Google - Google Kubernetes Engine - как бы создатели Kubernetes
По-моему в 2011 у меня был Samsung Note 2 + док с HDMI + 2 usb Такой: https://images.app.goo.gl/uwp77StdwRb5CFoF8
Ещё тогда я подключал к этому внешний монитор, клаву мышь и мог нормально работать в офисе, был ssh, куча всего и оно работало и даже не выглядело супер уродливо. Также подключал джойстик и играл в игры в эмуляторе приставки.
Короче, за 10 лет (!) ничего нового кроме небольших оптимизаций интерфейса.
Сетевым трафиком для такого теста можно пренебречь.
Но делать тесты и замеры на AWS гораздо более точно, чем использовать какой-то хостинг, где непонятно как выделяются ресурсы машине.
Справедливости ради в aws free tier shared , а не dedicated instance, но там есть способы определения того, как и когда эти ресурсы используются и это точно лучше noname hosting.
Если ваш проект планирует оказаться в K8s, то желательно на docker-compose и не останавливаться, а потратить немного времени и сразу начинать в K8s. Сейчас его базовый функционал гораздо более user friendly, чем когда-то. А то у вас тесты и т.д. в compose, а prod в K8s и окружения не одинаковые получаются, хоть и похожие. А потом вам надо будет потратить время на переписывания всех этих тестов и т.п., что мало кто делает.
Есть такой замечательный продукт: k3d, который можно использовать на Gitlab runner'е, посмотрите на него (кубер в докере, можно создавать одновременно несколько кластеров на одной машине). На машинах у разработчиков можно также использовать его или его брата k3s (кубер не в докере, управляется systemd). K3s CNCF certified.
Так я вам и подсказываю решение для динамического создания окружений для MR в кубере: k3d (помимо создания нового namespace под каждый MR, конечно, что иногда не удобно). K3d - это по сути кубер в докере. Использую его на проектах, отлично себя показывает как раз в том числе для прогона тестов для MR/PR. Им в том числе можно создавать много изолированных кластеров на одном Gitlab runner'е.
Всё вроде стандартно, но отлично написано, спасибо.
Consul для динамических нод K8s конечно не нужен, но если у вас там помимо K8s прямо зоопарк, то, наверное, оправдано.
Это я бы конечно в k3s или k3d добавил, чтобы никаких docker-compose. Заодно разработчики будут локально работать в среде ближе к реальному K8s.
Никаких вопросов к «задаче» статьи, но в ходе сранения формулируется посыл о невозможности реализации чего либо «встроенными» командами Docker и возможности реализации этого с помощью werf. У докера все команды «встроенные», werf использует api docker daemon, является клеем и т.д., поэтому уверен, что при детальном разборе любой ситуации окажется, что это реализуемо/возможно и с помощью «встроенных» команд Docker, определённой правильной для конкретной ситуации последовательности в реализации multi stage build'ов и т.д., просто для этого нужно явно знать как это настраивать и потратить на это, возможго немало, дополнительного времени, а werf это делает из коробки и за вас.
Но "реализуемо за дополнительное время" != "нереализуемо".
У всего есть причины. Не разобрались и werf решил вашу проблему за вас, супер! Ни коим образом не говорю, что нужно всё билдить только докером или вместо apt только из исходников :) Лишь указываю на некорректность формулирования в статье некоторых моментов, которые звучат как "это невозможно с докер и возможно с werf". Это не так, как и, я уверен, в вашем случае.
Вы мне про Фому, а я вам про Ерёму :)
Я вам конкретно говорю, что в статье сформулировано так, что docker что-то не умеет, а werf умеет. Это не так.
Про то что вы реализуете уровни абстракции поверх всего этого и в итоге связывая всё этого воедино экономите для всех время, деньги и принуждать их к использованию best practices кэширования это понятно.
Опять же: сомнительно по вышеописанным мной причинам, но, надеюсь, что ошибаюсь и обязательно проверю на практике :)
А где вы увидели эмоции с моей стороны? :)
Навскидку (и это всё положительные и правильные шаги):
1) процесс работы над собственным opensource проектом внутри компании реализует некий team building. Уверен, что ребята работают над ним не только в рабочее время, как и все, кто участвует в opensource.
2) лишнее подтверждение для клиентов, которым это решение внедряется в состоятельности и крутости компании.
3) вы регулярно реализуете некие решения у клиентов и решили написать собственный продукт, который бы реализовывал хотя бы часть best practices по части multi stage docker builds и т.п. чтобы каждый ваш инженер не реализовывал это на свой вкус и это было бы стандартизированно + в целом это экономия времени для компании, а значит денег.
…
Про маркетинг я упомянул в контексте того, что в статье всё же некоторые вещи про docker описываются как невозможные и возможные только с werf, тогда как это не так.
И это не отменяет плюсов в их использовании, как вам прекрасно известно.
Использовать точно такой же подход, как к микросервисам, конечно. Другое дело, что каждый инженер может начать лепить что-то своё и не то что описать интерфейсы взаимодействия между тегированием и пушем образов достаточно сложно, это не сложно, а сложно проконтроллировать фактическую реализацию. werf я так понимаю решает часть этой проблемы, т.к. забирает конвенцию по именованию и по использованию кэширования под капот. Но это опять же не значит, что всего этого нет для отдельных утилит, как мне кажется подаётся в статье. Поэтому с вашим утверждением
не соглашусь по части «расширяет их возможности». В статье не увидел ничего, что нельзя было бы реализовать не с помощью werf.
В целом для меня это похоже на сравнение Jenkins и Gitlab: в Gitlab многое сделано за вас и склеено, но это не значит, что это нельзя реализовать в Jenkins :)
Но это всё слова основанные на статье. Планирую обязательно пощупать werf, выглядит достаточно интересно и возможно напишу неафилированную статью.
Супер, надеюсь так и будет продолжаться, тем более, что звёзд на Github у вас уже очень даже прилично.
Есть. Замечание по подаче информации в статье в формате: «в docker этого нет, а в werf есть».
«Пользователю», т.е., условно, «разработчику», может быть и не нужно, но ci/cd пайплайны обычно выстраивают релиз инженеры или DevOps'ы/SRE и им нужно и думать и понимать что, куда и как выкатывается. Делается это тегами или вашим изобретением в виде… имён контейнеров, т.е. более вручную или более автоматизированно это в контексте моего комментария уже вторичный момент, т.к. в werf вы судя по тому, что я прочёл в статье, вы идёте по пути условного Apple или Gitlab и решаете за пользователя в каком виде ему что лучше иметь на выходе.
Понятия то может и нет, но если вы просто объединили эти процессы под капотом, то это не значит, что это не происходит, т.е. у вас, вместо `docker build -t example. && docker push example` происходит условный `werf build example`
Multistage builds не все могут освоить, там много фишек и вы наверное по сути реализовали многое из этого под капотом werf, но это не значит, что этих механизмов не существует в обычном docker, как мне кажется подаётся в статье. Думаю при грамотной настройке multistage build docker скорость сборки не будет отличаться от werf.
Также во всех широко распространённых docker registry, например Gitlab, есть механизм использования слоёв из других контейнеров, который задействуются при сохранении/push новых образов именно с описанными вами целями. Пример:
$ docker push $CI_REGISTRY_IMAGE/exampleThe push refers to repository [registry.gitlab.com/example]
4804b936f9fb: Preparing
4e680695ab1f: Preparing
f05ab25ed134: Preparing
f65353d0c4cd: Preparing
fafbb6872cae: Preparing
56456681cc56: Preparing
5c92c7ad7044: Preparing
777b2c648970: Preparing
5c92c7ad7044: Waiting
777b2c648970: Waiting
56456681cc56: Waiting
4e680695ab1f: Layer already exists
f65353d0c4cd: Layer already exists
fafbb6872cae: Layer already exists
f05ab25ed134: Layer already exists
777b2c648970: Layer already exists
5c92c7ad7044: Layer already exists
56456681cc56: Layer already exists
4804b936f9fb: Pushed
1.8.3-alpine: digest: sha256:07d028c89da81f460e0442f5f50275a878765aef43df0bb71dc0840d31f1c9bf size: 1987
Cleaning up file based variables
00:01
Job succeeded
Ещё раз повторюсь: существует множество best practices для различного рода кэширования, которые многие не используют ввиду неопытности и werf похоже заполняет этот пробел в знаниях новичков просто задействуя эти механизмы и реализуя их как бы за них. Но как мне кажется в статье информация подаётся в таком виде, что этих механизмов нет вообще или они сильно уступают werf. Это конечно же не так. В добавок по вашему собственному утверждению
и схема с использованием docker daemon тоже про это.
Хоть инструмент ваша команда и написала интересный, респект, похоже есть интересные фишки, но многое в статье сомнительно и похоже на маркетинг. Некоторые утверждения ложные и желаемое выдаётся за действительное. Докер умеет много что из того, что в статье преподносится, как невозможное. Возможно из коробки с werf это проще, но говорить, что невозможно не нужно.
Отдельно замечу, что эдакий мультикомбайн напоминает монолит, от которых мы все как раз пытаемся уйти к микросервисам. Да, иногда бывает удобно в образ поставить несколько утилит для сборки/деплоя и т.п. А тут прямо и helm и docker и ещё что-то... Не уверен, что это работает и главное будет в будущем работать лучше, чем вышеупомянутое, ведь там его поддерживает гораздо большее коммьюнити.
Удачи!
Не соглашусь с тем, что это хоть и базовое решение, но подходит лишь для ситуации, когда вы единственный owner/maintainer.
Чаще всего так или иначе бывает человек или группа людей с привилегированным доступом, назовём её админы. Они должны иметь доступ к паролям прода. Это очень базовый сценарий, но допустим так.
И есть вторая группа, назовём её разработчики. Они не являются ни owner'ами ни maintainer'ами репозитория. Доступа к переменным не имеют. И даже в бесплатном Gitlab сейчас достаточно гибко настраиваются роли для работы с репозиторием, т.е. если разработчики не owner'ы и не maintainer'ы, то всё равно могут делать то, что нужно делать. Остальное это просто "хотим видеть то, что видели раньше, а сейчас почему-то нельзя", но из практики в 95+% это чепуха. Далее для, например, dev окружения (environment scope) переменные делаются не masked, а обычными и не protected. Теоретически для dev окружений конечно можно было бы и чуть ли не в коде переменные хранить, но есть высокая вероятность, что когда будете выкатывать на следующее окружение, то ошибетесь и будет плохо. Не советую так делать.
Многие проекты даже до этого уровня не дорастают, хотя это уже гораздо лучше хранения секретов в коде репы и никакого стороннего софта. Вот когда дальше уже нужно гибко настраивать роли по определённым группам и переменным, нужны логи обращения к ним и т.д, вот там нужен vault.
Но я бы рекомендовал начать с простого. Далее не проблема перенести переменные из Gitlab в Vault, если это вообще когда либо понадобится (многим нет), т.к. у Gitlab прекрасно работающий api для работы в том числе с переменными.
Это конечно самый базовый, но вполне рабочий вариант до которого многим хотя бы дорасти:
в Gitlab существует функция маскировки как раз для таких случаев (masked)
+ переменную можно сделать protected, чтобы просто так в какой-то произвольной ветке нет могли с ней пытаться что-то делать
+ у переменных можно делать разные environment scope, т.е. например может быть несколько переменных с одним и тем же именем, но значение для разных окружений будут разные.
Ив итоге можно относительно гибко задавать где они protected и masked, а где нет. Всё это в совокупности позволяет на достаточно базовом уровне решать проблемы с переменными в репозиториях без какого-то дополнительного софта.
Environment scope: (Optional)
All, or specific environments.Protect variable (Optional): If selected, the variable is only available in pipelines that run on protected branches or tags.
Mask variable (Optional): If selected, the variable’s Value is masked in job logs. The variable fails to save if the value does not meet the masking requirements.
https://docs.gitlab.com/ce/ci/variables/
Помимо Gitlab отмечу хорошее и достаточно простое yaml friendly решение https://github.com/mozilla/sops
Думаю, что "забуксовать" имелось ввиду бабушке в понимании, когда она услышит "оркестратор", а не вам в освоении.
Про необходимость 7 серверов для отказоустойчивого K8s в большинстве случаев: вы ошибаетесь, т.к. в большинстве случаев ставить etcd на отдельные сервера смысла нет, а для большинства проектов облачный K8s вообще позаботится о вас о мастерах.
Для Rancher + K8s + Hetzner есть официальный мануал от Hetzner
https://community.hetzner.com/tutorials/hcloud-install-rancher-single/
Прекрасно работает.
Рассматривали какой-то хлам вместо топ 3:
1) Amazon - Elastic Kubernetes Service
2) Google - Google Kubernetes Engine - как бы создатели Kubernetes
3) Microsoft - Azure Kubernetes Engine
Или если клавиатура и мышь через type-c — USB хаб подключены, то всё равно большая задержка?
Есть же chromecast и куча подобных ему, чем они вам не подходят?
По-моему в 2011 у меня был Samsung Note 2 + док с HDMI + 2 usb Такой: https://images.app.goo.gl/uwp77StdwRb5CFoF8
Ещё тогда я подключал к этому внешний монитор, клаву мышь и мог нормально работать в офисе, был ssh, куча всего и оно работало и даже не выглядело супер уродливо. Также подключал джойстик и играл в игры в эмуляторе приставки.
Короче, за 10 лет (!) ничего нового кроме небольших оптимизаций интерфейса.
Сетевым трафиком для такого теста можно пренебречь.
Но делать тесты и замеры на AWS гораздо более точно, чем использовать какой-то хостинг, где непонятно как выделяются ресурсы машине.
Справедливости ради в aws free tier shared , а не dedicated instance, но там есть способы определения того, как и когда эти ресурсы используются и это точно лучше noname hosting.