Не стоит сервисы от Microsoft выставлять наружу в интернет, особенно с такой сомнительной "защитой".
Рекомендую просто использовать vpn по сертификатам перед rdgw (который вам возможно и не нужен, а нужен лишь rdp?).
Перечитал ваше сообщение и увидел, что проект был на docker-compose, а это не Swarm. Compose не оркестратор, со всеми вытекающими из этого выводами, поэтому вполне допускаю, что в принципе осваивая концепцию оркестра, который занимается в том числе автоматическим поднятием нод по необходимости ресурсов сервисам и т.д. и т.п. вы потратили действительно очень много времени.
Но речь тут именно о Swarm > K8s, а не Compose > K8s.
Хотя я присутствовал в команде, где разработчики вообще не разрабатывали в docker и за примерно ваше время (3 месяца) успешно перешли на разработку и выкатку именно в кубер, с добавлением куда нужно переменных и необходимых сервису ресурсов.
Более 500 часов уже зная Swarm потратили на изучение и переезд на K8s?
Без обид, но судя по всему действительно не стоило этим заниматься с такой эффективностью.
Или вы свой проект параллельно переписывали, а не "просто переводили его со Swarm на K8s".
1) swarm high level за 4 часа? Вы просто не сталкивались с действительно серьёзными проблемами.
2) "Сколько времени требует куб — я лично пока не выяснял, но судя по тому, что пишут абсолютно все — там другой порядок цифр"
Не читал, но осуждаю!
Вы уже потратили кучу времени на то, чтобы прочитать, что другие пишут про K8s и ещё кучу на все эти комментарии и обдумывания, вместо того, чтобы изучить уже K8s на базовом уровне и наслаждаться. Мне кажется, что вам просто не хочется делать, условно говоря, как все, как большинство, но иногда в этом действительно есть смысл.
Мне давали, к вышеперечисленным компаниям отношения не имею. Попробуйте в техподдержку Гугла написать/позвонить.
Кстати видел тут на Хабре множество отзывов о плохой поддержке GCloud, но у меня что там, что для других их продуктов поддержка наоборот всегда впечатляла своей эффективностью.
Swarm умирает, K8s это мейнстрим, стандарт в индустрии оркестраторов, а не какой-то новомодный хайповый проект и работает уже надёжнее и предсказуемее Swarm на дефолтах.
Вам сложно разобраться со всеми настройками K8s, оставьте же дефолт, не нужно все трогать, там действительно есть где заблудиться :)
Вы свою цену заплатите, когда у вас будет заточенный под Swarm проект, в котором что-то будет постоянно идти не так или вы не сможете что-то сделать, но вместо трудоемкого для вас переноса на K8s вы будете тратить время на костыли.
Новичкам проще с Rancher или GKE начинать, там вообще в gui можно всё поднять за пару минут без кода.
Дальше берёте связку gitlab + gke, по мануалам Gitlab делаете базовую настройку и спокойно ведёте разработку.
В такой связке Gitlab позволяет получить дополнительные 200$ к 300$ дающимся новым аккаунтам самим Google, а 500$ это вполне себе ощутимая цифра.
И не как на AWS счёта выставляются, а по-моему гораздо более предсказуемо и внезапно большие цифры как на AWS не прилетают, да и выше $500 просто так с меня не начали снимать, что особо порадовало.
Если ещё и preemptible нодами научитесь пользоваться, то этих 500 на небольших проектах может ооочень надолго хватить.
В своё время Rancher ушёл от Swarm под капотом на K8s и я был очень этому рад, т.к. мой проект примерно в то же время достиг определённых ограничений в Swarm.
Если вы столкнетесь с проблемой или нестабильностью, то в Swarm вы можете её просто не решить или решать очень долго из-за отсутствия информации или ограниченности Swarm. С K8s вероятность такого близка к 0.
Один из ваших небольших проектов когда-то созреет для чего-то бОльшего, вы созреете, ведь раньше вам и compose хватало, а сейчас вам уже нужен оркестратор. K8s это логичное продолжение цепочки.
На мой взгляд, для разработчика инфраструктура должна быть как код — это естественно. K8s этой парадигме максимально соответствует, а Swarm в этом плане… кривоват.
В K8s есть реализация практически всего, что вам может прийти в голову, не понятно зачем ограничивать себя Swarm, который занимает на рынке всё меньше и меньше и скоро просто вымрет.
Банально всем.
Вас никто не обязывает использовать все фичи K8s, но если вы захотите их использовать, то вы сможете это сделать. И что Gitlab что GKE дают возможность сделать это какое-то достаточно продолжительное время бесплатно, хотя при этом это инструменты Enterprise Production уровня.
А ещё есть Minicube и K3s, но по мне так Rancher наиболее прост для освоения.
Вы преувеличиваете сложность K8s.
Точнее так: если вам нужно делать простые вещи, то K8s это может лучше и не усложняйте, оставьте всё на дефолтах :)
К тому же по любому чиху есть доки, форумы и чаты, где можно проконсультироваться.
Возможно стоило в первую очередь заняться оптимизацией кода, чем тотальным и дорогущим апгрейдом железа. Сами же написали:
Этот вариант казался единственным, поскольку в нашей команде нет, и никогда не было, администратора баз данных для применения всевозможных оптимизаций запросов (DBA)
Теме 100 тысяч лет, зачем изобретать велосипед и ещё и так… коряво и попутно плевать даже на рекомендации самих Microsoft?
Administrator блокируется по дефолту (ну или заблокируйте сами).
Для администрирования создаются другие административные пользователи с нетривиальными именами.
Openvpn на udp и по сертификатам + пароль (если у пользователя угнали сам сертификат) и официальный пакет, который его поставит. Можно даже собрать автоустановщик с конфигурационным файлом с сертификатом для каждого пользователя.
Не стоит сервисы от Microsoft выставлять наружу в интернет, особенно с такой сомнительной "защитой".
Рекомендую просто использовать vpn по сертификатам перед rdgw (который вам возможно и не нужен, а нужен лишь rdp?).
"Использование меньших базовых изображений" как ни крути плохой перевод.
Это видео размещено в конце статьи, на которую я привёл ссылку в разделе "Conclusion". Из неё же взяты все картинки.
Кстати, всем интересующимся рекомендую ознакомиться с более актуальной информацией: https://cloud.google.com/solutions/best-practices-for-building-containers
Очень плохой перевод https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-how-and-why-to-build-small-container-images
Перечитал ваше сообщение и увидел, что проект был на docker-compose, а это не Swarm. Compose не оркестратор, со всеми вытекающими из этого выводами, поэтому вполне допускаю, что в принципе осваивая концепцию оркестра, который занимается в том числе автоматическим поднятием нод по необходимости ресурсов сервисам и т.д. и т.п. вы потратили действительно очень много времени.
Но речь тут именно о Swarm > K8s, а не Compose > K8s.
Хотя я присутствовал в команде, где разработчики вообще не разрабатывали в docker и за примерно ваше время (3 месяца) успешно перешли на разработку и выкатку именно в кубер, с добавлением куда нужно переменных и необходимых сервису ресурсов.
Страшные вы истории рассказываете.
Более 500 часов уже зная Swarm потратили на изучение и переезд на K8s?
Без обид, но судя по всему действительно не стоило этим заниматься с такой эффективностью.
Или вы свой проект параллельно переписывали, а не "просто переводили его со Swarm на K8s".
Было/стало, если можно, в студию.
Не соглашусь:
1) swarm high level за 4 часа? Вы просто не сталкивались с действительно серьёзными проблемами.
2) "Сколько времени требует куб — я лично пока не выяснял, но судя по тому, что пишут абсолютно все — там другой порядок цифр"
Не читал, но осуждаю!
Вы уже потратили кучу времени на то, чтобы прочитать, что другие пишут про K8s и ещё кучу на все эти комментарии и обдумывания, вместо того, чтобы изучить уже K8s на базовом уровне и наслаждаться. Мне кажется, что вам просто не хочется делать, условно говоря, как все, как большинство, но иногда в этом действительно есть смысл.
Chaos Engineering называется.
https://www.cncf.io/blog/2019/11/06/cloud-native-chaos-engineering-enhancing-kubernetes-application-resiliency/
Мне давали, к вышеперечисленным компаниям отношения не имею. Попробуйте в техподдержку Гугла написать/позвонить.
Кстати видел тут на Хабре множество отзывов о плохой поддержке GCloud, но у меня что там, что для других их продуктов поддержка наоборот всегда впечатляла своей эффективностью.
Swarm умирает, K8s это мейнстрим, стандарт в индустрии оркестраторов, а не какой-то новомодный хайповый проект и работает уже надёжнее и предсказуемее Swarm на дефолтах.
Вам сложно разобраться со всеми настройками K8s, оставьте же дефолт, не нужно все трогать, там действительно есть где заблудиться :)
Вы свою цену заплатите, когда у вас будет заточенный под Swarm проект, в котором что-то будет постоянно идти не так или вы не сможете что-то сделать, но вместо трудоемкого для вас переноса на K8s вы будете тратить время на костыли.
Самая большая сложность, скорее психологическая — это первоначально окружение себе настроить.
Вот это вот сложно?!
https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app
Новичкам проще с Rancher или GKE начинать, там вообще в gui можно всё поднять за пару минут без кода.
Дальше берёте связку gitlab + gke, по мануалам Gitlab делаете базовую настройку и спокойно ведёте разработку.
В такой связке Gitlab позволяет получить дополнительные 200$ к 300$ дающимся новым аккаунтам самим Google, а 500$ это вполне себе ощутимая цифра.
И не как на AWS счёта выставляются, а по-моему гораздо более предсказуемо и внезапно большие цифры как на AWS не прилетают, да и выше $500 просто так с меня не начали снимать, что особо порадовало.
Если ещё и preemptible нодами научитесь пользоваться, то этих 500 на небольших проектах может ооочень надолго хватить.
В своё время Rancher ушёл от Swarm под капотом на K8s и я был очень этому рад, т.к. мой проект примерно в то же время достиг определённых ограничений в Swarm.
Если вы столкнетесь с проблемой или нестабильностью, то в Swarm вы можете её просто не решить или решать очень долго из-за отсутствия информации или ограниченности Swarm. С K8s вероятность такого близка к 0.
Один из ваших небольших проектов когда-то созреет для чего-то бОльшего, вы созреете, ведь раньше вам и compose хватало, а сейчас вам уже нужен оркестратор. K8s это логичное продолжение цепочки.
На мой взгляд, для разработчика инфраструктура должна быть как код — это естественно. K8s этой парадигме максимально соответствует, а Swarm в этом плане… кривоват.
В K8s есть реализация практически всего, что вам может прийти в голову, не понятно зачем ограничивать себя Swarm, который занимает на рынке всё меньше и меньше и скоро просто вымрет.
https://medium.com/@fairwinds/docker-swarm-is-dead-long-live-kubernetes-2d0db0609e09
Банально всем.
Вас никто не обязывает использовать все фичи K8s, но если вы захотите их использовать, то вы сможете это сделать. И что Gitlab что GKE дают возможность сделать это какое-то достаточно продолжительное время бесплатно, хотя при этом это инструменты Enterprise Production уровня.
А ещё есть Minicube и K3s, но по мне так Rancher наиболее прост для освоения.
Вы преувеличиваете сложность K8s.
Точнее так: если вам нужно делать простые вещи, то K8s это может лучше и не усложняйте, оставьте всё на дефолтах :)
К тому же по любому чиху есть доки, форумы и чаты, где можно проконсультироваться.
Нет, уж лучше K8s
Если слишком сложно, то используйте Rancher (который раньше был на Swarm).
Хотя документация и комьюнити такие обширные, что всё-таки рекомендую GKE + Gitlab.
Возможно стоило в первую очередь заняться оптимизацией кода, чем тотальным и дорогущим апгрейдом железа. Сами же написали:
Этот вариант казался единственным, поскольку в нашей команде нет, и никогда не было, администратора баз данных для применения всевозможных оптимизаций запросов (DBA)
А нет, всё верно, в 10ке, 2016 и 2019 при установке создаётся другой административный пользователь, а administrator блокируется:
https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts#sec-administrator
Возможно путаю с 10кой.
В любом случае это стоит сделать первым делом:
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/accounts-administrator-account-status
Теме 100 тысяч лет, зачем изобретать велосипед и ещё и так… коряво и попутно плевать даже на рекомендации самих Microsoft?
Administrator блокируется по дефолту (ну или заблокируйте сами).
Для администрирования создаются другие административные пользователи с нетривиальными именами.
Openvpn на udp и по сертификатам + пароль (если у пользователя угнали сам сертификат) и официальный пакет, который его поставит. Можно даже собрать автоустановщик с конфигурационным файлом с сертификатом для каждого пользователя.