На мой взгляд, хороший DevOps стоит больше хорошего админа в основном потому, что этап админа для него уже пройден и его потянуло автоматизировать всё по взрослому.
Т.е. хороший DevOps, на мой взгляд, может, например, временно заменить хорошего админа и компания не потеряет в производительности, а наоборот ускорится, сбоев не станет больше, а станет меньше и т.п.
А вот если совершить обратную рокировку, т.е. админа назначить подевопсить (по взрослому, т.е. серьёзные таски), то как минимум производительность упадёт, да и с остальным станет хуже.
А если DevOps'а совсем сильно тянет в безопасность, то DevOps становится DevSecOps'ом, но и у обычного, подчёркиваю, хорошего DevOps'а со знанием принципов мб должно быть в среднем всё очень хорошо.
Более того, за счёт автоматизации, например, пропустить установку принудительной политики на сложность паролей становится для DevOps'а гораздо менее реальным, чем для админа.
Насколько я знаю, лицензии на любые Oracle продукты стоят космических денег.
Неужели не проще использовать какую-то бесплатную бд, вроде Postgresql или вообще какое-то решение для big data, вроде Kafka, Bigquery и т.п, а фронт написать н любом популярном веб фреймворке?
Теоретически должно получиться гораздо дешевле, даже с учетом затрат на команду для разработки. Особенно с учетом того что продукты для финансовой отчётности на базе чего угодно потом добиваются под компанию и очень значительно и ставки интеграторов и программистов, которые реализуют это на платформе Oracle наверняка тоже достаточно серьёзные.
А то сколько инструментов для формирования и отображения финансовой отчётности я ни видел: они все имеют страшный, отсталый интерфейс из 90х, работают долго и в наш век это смотрится крайне странно.
В настоящее время доставка еды с помощью «Яндекс.Ровера» доступна в Москве в деловом квартале «Белая площадь» около метро «Белорусская». В этой локации расположены крупные офисы российских и иностранных компаний, а также многие кафе и рестораны. «Яндекс.Ровер» уже начал возить заказы из ресторанов «Марукамэ», Steak it Easy, Boston Seafood & Bar, Prime, Paul и Cheese Connection.
Эти рестораны и находятся на Белой площади и учитывая, что робот доставляет только до двери здания, то получается он метров 10 проезжает что ли?
Компания надеется, что часть пользователей будут готовы потратить свое время на прогулку из дома до улицы, чтобы забрать у роботов заказ.
Одеваться, выходить и ехать вниз на лифте встречать робота, вместо того, чтобы открыть дверь и забрать заказ у курьера вообще не удобно и популярно не будет.
Даже на первом этаже зачем выходить в подъезд если можно просто открыть дверь квартиры?
Разве что доставку сделают бесплатной, кто-то на это клюнет, но она и так бесплатная выше определенной суммы?
Использование облаков без больших трат и даже на уровне bare metal, а иногда и меньше, возможно, но для этого необходимо очень хорошо разбираться в техниках, которые помогают адекватно использовать ресурсы и в целом в выстраивании архитектуры проектов под это и тут к каждому проекту должен быть индивидуальный подход.
Ваше утверждение для меня слишком общее, чтобы судить о чём то конкретно.
К тому же облака нынче разные. Тот же Hetzner с недавних пор позволяет через Kubernetes контроллер (https://github.com/hetznercloud/hcloud-cloud-controller-manager) выписывать не только инстансы, но и load balancer'ы и т.п. и тут уже можно выстраивать вполне интересные вещи, не на уровне aws, конечно, но гораздо интереснее и динамичнее того, что позволяют bare metal и за ещё меньшие деньги.
Хотя spot/preemtible машин у них всё равно нет. А ещё есть spot.io и много другого.
В кубе «на коленках» же то же самое получится. Тот же nginx, пускай с красивым названием Ingress.
Никто не просит собирать куб на коленках.
Ingress + daemonset на том же bare metal работает гораздо интереснее и производительнее, чем какой-то один хост с одним reverse proxy. И можно использовать одновременно несколько ingress под разные задачи.
И базы так же будут. (в докер, поднятый «на коленках», тащить базу (SQL) так себе идея, имхо, особенно пытаться кластер базы организовать).
Patroni и всякие операторы норм работают, но базы можно и не докеризовать, от этого с ними приложения работают не хуже.
Но у микросервисов принято иметь свои небольшие базы и они прекрасно работают в контейнирезованном виде.
И даже если загрузка их 10-20%, то экономии не выйдет, поскольку для нормальной инфраструктуры от гугла или амазона потребуется больше инстансов с большим количеством CPU и RAM.
Нагрузка динамически меняется и если держать её на адекватном уровне 60-80%, а под пиковое время по расписанию готовить прогретые ноды, чтобы они входили в строй быстро, то экономия очень даже будет. Не забываем использовать spots/preemptive.
страданий мне и так хватает
Моя цель: уменьшение time to market и на серьёзных проектах с кубером и автоматизацией это происходит.
K8s практически неизбежен на масштабах. И не только при горизонтальном, но и при вертикальном масштабировании.
Масштабы = много людей на которых тем или иным образом происходит заработок. И наверное всё же стоит ориентироваться на это, а не на пет проекты, хотя, повторюсь, локальный K3s, да и K8s прекрасно работают при должной настройке и подготовке.
Но даже если клепать пачками одностраничники на пыхе, то их можно достаточно удобно разместить в кубе, а не за одним большим nginx с кучей vhosts и одной большой базой. Да, бывает и такое и оно работает, но может быть лучше, проще в обслуживании, отказоустойчивее и ещё много других но.
Куб и bare metal вполне себе нормально живут. Более того, иногда позволяют реализовать очень интересные решения, когда близость к железу всё-таки реально необходима.
Естественно Google дороже on prem, но всё это зависит от ваших целей, задач, реализации и сроков, от того насколько вы можете позволить себе downtime на обслуживание и многое другое.
Недавно работал с проектом, у которых кластера с кучей bare metal машин в откровенно хреновеньких дц, которые были в среднем загружены процентов на 10 по cpu и на 20 по памяти.
Переход в GKE/EKS позволил им освободить руки инфраструктурной команды и использовать гораздо лучшую инфраструктуру, которая не так часто падает, как текущая за те же деньги. Бизнес доволен, что не теряет деньги под нагрузкой (а нагрузка там есть), команда получила возможность делать больше и не заниматься чепухой. Это ли не прекрасно.
Я не знаю что у вас за интересы, на чём вы пишете и т.п, но разработчики не знающие докер уже в меньшинстве, во всяком случае в моём окружении.
Немного пройдитесь по issues самого Gitlab: много где issues связанные с omnibus получают низкий приоритет и похоже не будут решены никогда, что говорит само за себя.
1) я не знаю ваш стек, но 1Gb образы это не нормально
2) дискуссии о монорепозитории vs нескольких репозиториях стары и естественно присутствуют в том числе на хабре. Выводы, видимо, каждый делает сам. Но я не видел ни одного кейса, когда монорепу нельзя было бы раздробить используя правильные инструменты и техники, а уж для тех, кто начинает с нуля создавать монорепу и приучать себя к "плохому" не стоит. Конечно это несколько другое, но всё же монорепозитории попахивает монолитом или псевдомикросервисами. Сколько я таких видел даже и не перечесть, когда всё это хозяйство в 1 базу ходит.
3) значит вероятно именно вы попали в меньшинство тех проектов, которым нужно больше, чем 10Gb на репозиторий. В статье ведь речь не конкретро о вас. Работая в том числе в DevOps консалтинге и имея определённую "насмотренность" различными проектами, а также общаясь с народом в профессиональных кругах могу сказать, что реально 10Gb на репозиторий это вполне достаточно, особенно если правильно настраивать clean policy и т.д.
Вы поняли о чём я, on prem по определенным метрикам всегда будет проигрывать облаку и наоборот. Важно понять что даёт вам максимальную эффективность и не является ли что-то скорее какими-то вашими религиозными убеждениями или просто привычками, чем логическим обоснованием использования той или иной технологии или техники.
Я утверждаю, что жить можно без on prem и в очень больших масштабах, но нужно определенным образом организовать это и это будет эффективно. Но так можно сделать не в 100% случаев.
1) в целом весь этот стек можно поднять и в docker-compose (но не нужно).
2) Gitlab всё же ориентируется на серьёзную разработку, где K8s практически неизбежен.
3) Даже если вы разрабатываете не в docker, то держать такие сервисные вещи, как сам Gitlab удобнее именно в нём по ряду причин, а значит см 1, 2 и 4.
4) Лично у меня, как и у многих разработчиков, K8s стоит на локальной машине в виде K3s, кушать не просит и он гораздо удобнее, чем compose. Имхо именно так нужно разворачивать локальную среду для разработчиков в 2020. Любой микросервис и даже стек микросервисов работает на моей машине идентично проду (если только не нужна база с 370gb ram :)
4) Никаких тысяч долларов не нужно. Это заблуждение основанное на недостатке опыта. Для особо экономящих для начала (или в особых случаях ) и мастера, совмещённые с воркерами, подойдут: видел такие автономные мини кластеры, например, на складах.
5) «затрудняет разработку на первых этапах» зависит от зрелости разработчиков. Имхо лучше потратить немного времени на изучение полезной технологии на старте, чтобы выиграть гораздо больше в перспективе.
6) K8s в резюме уже никого не удивишь. Удивляют уже те, у кого его там нет.
2) Как раз сегодня наблюдаю использование облачного Gitlab в монорепе с ~ 10 Java "микросервисами". Но лучше так не делать.
3) У вас просто мало проектов и нагрузки и опять же: зачем что-то обслуживать и держать под это (=платить за) серверные мощности, диски и т.п, если это можно не делать. Освободите руки себе и коллегам и займитесь чем-то другим.
Например, у вас уже 13.5.3?
И postgres нормально реплицируется и выдержит выход из строя дц без downtime?
И cdn для разработчиков из разных стран нормально работает?
И.т.д
У меня, там где облако, на всё да и это сотни деплоев в неделю как минимум.
1) Возможно я поспешил с deprecated, но посмотрите их уже достаточно старое видео по распилу Omnibus и переходу на микросервисную архитектуру www.youtube.com/watch?v=rIUth_KrJdw (кстати в целом хорошее видео) +, например, docs.gitlab.com/charts говорит о «This is the official, recommended, and supported method to install GitLab on a cloud native environment.»
Так что новым инсталляциям точно не стоит использовать Omnibus, если он ещё не deprecated, то about to.
В облачном Gitlab можно и pci dss пройти, но параноики, которые боятся того же AWS/GKE есть, да :)
2) Нужно сразу использовать правильные практики. Использование latest как минимум очень желательно избегать.
Kubernetes это мейнстрим для практически любых проектов, которые планируют сколько-нибудь серьёзную нагрузку или удобное обслуживание и т.д., поэтому привожу пример.
Разворачивание Kubernetes, например, в том же GKE элементарно, вопрос зрелости команды разработки и DevOps.
Более того, молодым стартапам получившим инвестирование гораздо проще и быстрее развернуться именно в AWS/GKE, а когда проект действительно взлетит и начнёт сильно расти, то резать расходы и то часто и в облаках расходы можно существенно уменьшить за счёт использования spot instances / preemptible vms + cluster autoscaler и других техник.
1) Естественно речь о своих раннерах, которые поднимаются элементарно.
Текущая современная инсталляция self hosted Gitlab (а не omnibus, который deprecated) состоит из более чем 20 контейнеров и более чем 12 вложенных Helm Chart'ов и установка и поддержка этого хозяйства новичками точно не проста и не ясно зачем нужна, кроме специфических кейсов.
Мнение по-поводу "облако падает" в целом ошибочно, т.к. то, что обслуживаете вы или кто либо другой уровня "небольшая команда" тоже нужно обновлять, патчить и т.п. + ваш uptime при работе 1-2 инженеров поддержки будет точно хуже, чем специализирующейся на этом команды инженеров поддержки Gitlab у которых это всё работает в GKE. Они упали дважды за несколько лет и это крайне хороший показатель, а после подробных portmortems доверие к ним только возросло.
Я видел и вижу облачные инсталляции Gitlab на достаточно крупных проектах и их это не потревожило.
Это примерно как не доверять серверные мощности AWS.
2) В случае, если вы используете эффективную политику Kubernetes imagepullpolicy: ifnotpresent, то при использовании latest при обновлении образа ничего не произойдёт, а делать always не эффективно.
У Gitlab есть прекрасные встроенные переменные окружения, которые как раз и созданы для автоматизации и реализуется использование конкретного тега элементарно. Например: envsubst < $CI_PROJECT_DIR/k8s/dev-k8s.yml | kubectl apply -f -
А в самом dev-k8s.yml в качестве образа прописывается $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG
Прекрасно работает где-то уже годами. Естественно пример с kubectl, конечно, упрощённый, но мысль, надеюсь, ясна.
И как раз быстрее понять что не так, если указан конкретный образ и с 1.0.1 на 1.0.0 автоматизированный откат гораздо красивее реализуется.
Свой Gitlab это конечно классно, но в контексте статьи "для молодых команд" в подавляющем большинстве случаев излишне.
Облачный Gitlab не нужно поднимать/разворачивать, гораздо меньше нужно настраивать, а обслуживать не нужно совсем, как и держать под него сервера и дисковое пространство.
Существующее в облачном Gitlab ограничение в 10Gb на репозиторий позволяет вполне комфортно работать и вполне зрелым командам, особенно в условиях микросервисов, когда репозитории относительно небольшие.
Деплоить по latest тегам некорректно и считается не очень хорошей практикой. Например, в случае imagepullpolicy: ifnotexists получите проблему. Деплой по тегу с версией правильнее.
Меня интересует анализировали ли стоимость решения одно vs другое и что получилось.
CloudSQL это классно, но далеко не всегда экономически целесообразно, а время на строительство, поддержку и т.п. зависит многих факторов, в т.ч. нагрузки на бд, прямоту рук девопса(ов), наличие девопсов в принципе и т.д.
Например, если база совсем не нагруженная и небольшая, то поднять небольшой instance с медленными дисками, которому в принципе не от чего падать, без high availability, настроить бэкапы на s3 и т.п. скорее всего будет дешевле использования CloudSQL.
Если DevOps в ладах с Terraform, Ansible и инфраструктурой как код в принципе, то развернуть и поддерживать такое не сложно и не затратно в человекочасах, но всё зависит от параметров проекта.
И теоретически если собственный PostgresSQL оказывается даже немного дешевле, то на длительном промежутке времени эта выгода будет накапливаться, а если таких клиентов много, то суммарно это приличная экономия.
Так-то по каждому чиху можно rds поднимать, но в тегах к статье же finops.
Вы можете поделиться цифрами и ответить на вопрос?
Объём данных, нагрузка на базу, какой CloudSQL machine type используете, ha или нет и т.д.?
Уточню, что оценку трудозатрат на настройку и поддержку self hosted PostgresSQL не трогаем, только затраты на CloudSQL vs self hosted PostgresSQL в вашем конкретном кейсе.
Не вижу проблем рассмотреть это "в отрыве от основного процесса".
В таких компаниях уж точно наружу не выставляется rdgw с такими решениями, которые привёл автор статьи.
Использовать или не использовать splitdns это уже второй вопрос.
Посмотрел одну из последний стабильных установок OpenVPN и там сделан не splitdns, а именно маршрут в корпоративную подсеть «пушается»(push) на клиента, а остальной трафик туда, соответственно, не заворачивается.
Например, вот так выглядит конфиг сервера OpenVPN 2.4.6.x (server.opvn) на Windows Server: port 1194
proto udp
dev tun
server 10.8.0.0 255.255.255.0
push "route 10.8.0.0 255.255.0.0 vpn_gateway"
mssfix
tun-mtu 1500
keepalive 10 120
reneg-sec 0
comp-lzo
persist-key
persist-tun
verb 4
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\server.crt"
key "C:\\Program Files\\OpenVPN\\config\\server.key"
dh "C:\\Program Files\\OpenVPN\\config\\dh2048.pem"
tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 0
crl-verify "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\crl.pem"
ifconfig-pool-persist "C:\\Program Files\\OpenVPN\\config\\ipp.txt"
status "C:\\Program Files\\OpenVPN\\log\\openvpn-status.log"
log "C:\\Program Files\\OpenVPN\\log\\openvpn.log"
Конфиг именно с реализованным splitdns под рукой нет, но гуглится это достаточно легко, вариантов масса.
Всем накатывается клиент (предпочитаю openvpn + udp) + раздаётся конфиг с вшитым в него сертификатом + настаивается автоподключение при загрузке + splitdns, чтобы трафик шёл в туннель только для рабочих адресов. Рекомендуется защищать конфиг паролем при подключении, но можно и без него, чтобы пользователи совсем не беспокоились. К openvpn ещё и двухфакторная авторизация прикручивается очень легко (смс, google authenticator и т.п.).
Можно для каждого бандл (установщик+конфиг) сформировать и накатить какими-нибудь политиками или чем вы машины конфигурируете.
Множество самого не продвинутого персонала работает с таким абсолютно нормально (говорю из опыта), а есть персонал и гораздо более непродвинутый, чем бухгалтера.
Знают, что если иконка в углу экрана красная, то скорее всего нужно проверить своё подключение к интернет, т.к. openvpn обычно работает как часы.
На мой взгляд, хороший DevOps стоит больше хорошего админа в основном потому, что этап админа для него уже пройден и его потянуло автоматизировать всё по взрослому.
Т.е. хороший DevOps, на мой взгляд, может, например, временно заменить хорошего админа и компания не потеряет в производительности, а наоборот ускорится, сбоев не станет больше, а станет меньше и т.п.
А вот если совершить обратную рокировку, т.е. админа назначить подевопсить (по взрослому, т.е. серьёзные таски), то как минимум производительность упадёт, да и с остальным станет хуже.
А если DevOps'а совсем сильно тянет в безопасность, то DevOps становится DevSecOps'ом, но и у обычного, подчёркиваю, хорошего DevOps'а со знанием принципов мб должно быть в среднем всё очень хорошо.
Более того, за счёт автоматизации, например, пропустить установку принудительной политики на сложность паролей становится для DevOps'а гораздо менее реальным, чем для админа.
Насколько я знаю, лицензии на любые Oracle продукты стоят космических денег.
Неужели не проще использовать какую-то бесплатную бд, вроде Postgresql или вообще какое-то решение для big data, вроде Kafka, Bigquery и т.п, а фронт написать н любом популярном веб фреймворке?
Теоретически должно получиться гораздо дешевле, даже с учетом затрат на команду для разработки. Особенно с учетом того что продукты для финансовой отчётности на базе чего угодно потом добиваются под компанию и очень значительно и ставки интеграторов и программистов, которые реализуют это на платформе Oracle наверняка тоже достаточно серьёзные.
А то сколько инструментов для формирования и отображения финансовой отчётности я ни видел: они все имеют страшный, отсталый интерфейс из 90х, работают долго и в наш век это смотрится крайне странно.
Эти рестораны и находятся на Белой площади и учитывая, что робот доставляет только до двери здания, то получается он метров 10 проезжает что ли?
Одеваться, выходить и ехать вниз на лифте встречать робота, вместо того, чтобы открыть дверь и забрать заказ у курьера вообще не удобно и популярно не будет.
Даже на первом этаже зачем выходить в подъезд если можно просто открыть дверь квартиры?
Разве что доставку сделают бесплатной, кто-то на это клюнет, но она и так бесплатная выше определенной суммы?
Использование облаков без больших трат и даже на уровне bare metal, а иногда и меньше, возможно, но для этого необходимо очень хорошо разбираться в техниках, которые помогают адекватно использовать ресурсы и в целом в выстраивании архитектуры проектов под это и тут к каждому проекту должен быть индивидуальный подход.
Ваше утверждение для меня слишком общее, чтобы судить о чём то конкретно.
К тому же облака нынче разные. Тот же Hetzner с недавних пор позволяет через Kubernetes контроллер (https://github.com/hetznercloud/hcloud-cloud-controller-manager) выписывать не только инстансы, но и load balancer'ы и т.п. и тут уже можно выстраивать вполне интересные вещи, не на уровне aws, конечно, но гораздо интереснее и динамичнее того, что позволяют bare metal и за ещё меньшие деньги.
Хотя spot/preemtible машин у них всё равно нет. А ещё есть spot.io и много другого.
Никто не просит собирать куб на коленках.
Ingress + daemonset на том же bare metal работает гораздо интереснее и производительнее, чем какой-то один хост с одним reverse proxy. И можно использовать одновременно несколько ingress под разные задачи.
Patroni и всякие операторы норм работают, но базы можно и не докеризовать, от этого с ними приложения работают не хуже.
Но у микросервисов принято иметь свои небольшие базы и они прекрасно работают в контейнирезованном виде.
Нагрузка динамически меняется и если держать её на адекватном уровне 60-80%, а под пиковое время по расписанию готовить прогретые ноды, чтобы они входили в строй быстро, то экономия очень даже будет. Не забываем использовать spots/preemptive.
Моя цель: уменьшение time to market и на серьёзных проектах с кубером и автоматизацией это происходит.
K8s практически неизбежен на масштабах. И не только при горизонтальном, но и при вертикальном масштабировании.
Масштабы = много людей на которых тем или иным образом происходит заработок. И наверное всё же стоит ориентироваться на это, а не на пет проекты, хотя, повторюсь, локальный K3s, да и K8s прекрасно работают при должной настройке и подготовке.
Но даже если клепать пачками одностраничники на пыхе, то их можно достаточно удобно разместить в кубе, а не за одним большим nginx с кучей vhosts и одной большой базой. Да, бывает и такое и оно работает, но может быть лучше, проще в обслуживании, отказоустойчивее и ещё много других но.
Куб и bare metal вполне себе нормально живут. Более того, иногда позволяют реализовать очень интересные решения, когда близость к железу всё-таки реально необходима.
Естественно Google дороже on prem, но всё это зависит от ваших целей, задач, реализации и сроков, от того насколько вы можете позволить себе downtime на обслуживание и многое другое.
Недавно работал с проектом, у которых кластера с кучей bare metal машин в откровенно хреновеньких дц, которые были в среднем загружены процентов на 10 по cpu и на 20 по памяти.
Переход в GKE/EKS позволил им освободить руки инфраструктурной команды и использовать гораздо лучшую инфраструктуру, которая не так часто падает, как текущая за те же деньги. Бизнес доволен, что не теряет деньги под нагрузкой (а нагрузка там есть), команда получила возможность делать больше и не заниматься чепухой. Это ли не прекрасно.
Я не знаю что у вас за интересы, на чём вы пишете и т.п, но разработчики не знающие докер уже в меньшинстве, во всяком случае в моём окружении.
Немного пройдитесь по issues самого Gitlab: много где issues связанные с omnibus получают низкий приоритет и похоже не будут решены никогда, что говорит само за себя.
1) я не знаю ваш стек, но 1Gb образы это не нормально
2) дискуссии о монорепозитории vs нескольких репозиториях стары и естественно присутствуют в том числе на хабре. Выводы, видимо, каждый делает сам. Но я не видел ни одного кейса, когда монорепу нельзя было бы раздробить используя правильные инструменты и техники, а уж для тех, кто начинает с нуля создавать монорепу и приучать себя к "плохому" не стоит. Конечно это несколько другое, но всё же монорепозитории попахивает монолитом или псевдомикросервисами. Сколько я таких видел даже и не перечесть, когда всё это хозяйство в 1 базу ходит.
3) значит вероятно именно вы попали в меньшинство тех проектов, которым нужно больше, чем 10Gb на репозиторий. В статье ведь речь не конкретро о вас. Работая в том числе в DevOps консалтинге и имея определённую "насмотренность" различными проектами, а также общаясь с народом в профессиональных кругах могу сказать, что реально 10Gb на репозиторий это вполне достаточно, особенно если правильно настраивать clean policy и т.д.
Вы поняли о чём я, on prem по определенным метрикам всегда будет проигрывать облаку и наоборот. Важно понять что даёт вам максимальную эффективность и не является ли что-то скорее какими-то вашими религиозными убеждениями или просто привычками, чем логическим обоснованием использования той или иной технологии или техники.
Я утверждаю, что жить можно без on prem и в очень больших масштабах, но нужно определенным образом организовать это и это будет эффективно. Но так можно сделать не в 100% случаев.
1) в целом весь этот стек можно поднять и в docker-compose (но не нужно).
2) Gitlab всё же ориентируется на серьёзную разработку, где K8s практически неизбежен.
3) Даже если вы разрабатываете не в docker, то держать такие сервисные вещи, как сам Gitlab удобнее именно в нём по ряду причин, а значит см 1, 2 и 4.
4) Лично у меня, как и у многих разработчиков, K8s стоит на локальной машине в виде K3s, кушать не просит и он гораздо удобнее, чем compose. Имхо именно так нужно разворачивать локальную среду для разработчиков в 2020. Любой микросервис и даже стек микросервисов работает на моей машине идентично проду (если только не нужна база с 370gb ram :)
4) Никаких тысяч долларов не нужно. Это заблуждение основанное на недостатке опыта. Для особо экономящих для начала (или в особых случаях ) и мастера, совмещённые с воркерами, подойдут: видел такие автономные мини кластеры, например, на складах.
5) «затрудняет разработку на первых этапах» зависит от зрелости разработчиков. Имхо лучше потратить немного времени на изучение полезной технологии на старте, чтобы выиграть гораздо больше в перспективе.
6) K8s в резюме уже никого не удивишь. Удивляют уже те, у кого его там нет.
1) Образы по 1Gb+ звучит очень очень плохо.
2) Как раз сегодня наблюдаю использование облачного Gitlab в монорепе с ~ 10 Java "микросервисами". Но лучше так не делать.
3) У вас просто мало проектов и нагрузки и опять же: зачем что-то обслуживать и держать под это (=платить за) серверные мощности, диски и т.п, если это можно не делать. Освободите руки себе и коллегам и займитесь чем-то другим.
Например, у вас уже 13.5.3?
И postgres нормально реплицируется и выдержит выход из строя дц без downtime?
И cdn для разработчиков из разных стран нормально работает?
И.т.д
У меня, там где облако, на всё да и это сотни деплоев в неделю как минимум.
Так что новым инсталляциям точно не стоит использовать Omnibus, если он ещё не deprecated, то about to.
В облачном Gitlab можно и pci dss пройти, но параноики, которые боятся того же AWS/GKE есть, да :)
2) Нужно сразу использовать правильные практики. Использование latest как минимум очень желательно избегать.
Kubernetes это мейнстрим для практически любых проектов, которые планируют сколько-нибудь серьёзную нагрузку или удобное обслуживание и т.д., поэтому привожу пример.
Разворачивание Kubernetes, например, в том же GKE элементарно, вопрос зрелости команды разработки и DevOps.
Более того, молодым стартапам получившим инвестирование гораздо проще и быстрее развернуться именно в AWS/GKE, а когда проект действительно взлетит и начнёт сильно расти, то резать расходы и то часто и в облаках расходы можно существенно уменьшить за счёт использования spot instances / preemptible vms + cluster autoscaler и других техник.
1) Естественно речь о своих раннерах, которые поднимаются элементарно.
Текущая современная инсталляция self hosted Gitlab (а не omnibus, который deprecated) состоит из более чем 20 контейнеров и более чем 12 вложенных Helm Chart'ов и установка и поддержка этого хозяйства новичками точно не проста и не ясно зачем нужна, кроме специфических кейсов.
Мнение по-поводу "облако падает" в целом ошибочно, т.к. то, что обслуживаете вы или кто либо другой уровня "небольшая команда" тоже нужно обновлять, патчить и т.п. + ваш uptime при работе 1-2 инженеров поддержки будет точно хуже, чем специализирующейся на этом команды инженеров поддержки Gitlab у которых это всё работает в GKE. Они упали дважды за несколько лет и это крайне хороший показатель, а после подробных portmortems доверие к ним только возросло.
Я видел и вижу облачные инсталляции Gitlab на достаточно крупных проектах и их это не потревожило.
Это примерно как не доверять серверные мощности AWS.
2) В случае, если вы используете эффективную политику Kubernetes imagepullpolicy: ifnotpresent, то при использовании latest при обновлении образа ничего не произойдёт, а делать always не эффективно.
У Gitlab есть прекрасные встроенные переменные окружения, которые как раз и созданы для автоматизации и реализуется использование конкретного тега элементарно. Например:
envsubst < $CI_PROJECT_DIR/k8s/dev-k8s.yml | kubectl apply -f -А в самом
dev-k8s.ymlв качестве образа прописывается$CI_REGISTRY_IMAGE:$CI_COMMIT_TAGПрекрасно работает где-то уже годами. Естественно пример с kubectl, конечно, упрощённый, но мысль, надеюсь, ясна.
И как раз быстрее понять что не так, если указан конкретный образ и с 1.0.1 на 1.0.0 автоматизированный откат гораздо красивее реализуется.
Свой Gitlab это конечно классно, но в контексте статьи "для молодых команд" в подавляющем большинстве случаев излишне.
Облачный Gitlab не нужно поднимать/разворачивать, гораздо меньше нужно настраивать, а обслуживать не нужно совсем, как и держать под него сервера и дисковое пространство.
Существующее в облачном Gitlab ограничение в 10Gb на репозиторий позволяет вполне комфортно работать и вполне зрелым командам, особенно в условиях микросервисов, когда репозитории относительно небольшие.
Деплоить по latest тегам некорректно и считается не очень хорошей практикой. Например, в случае imagepullpolicy: ifnotexists получите проблему. Деплой по тегу с версией правильнее.
Меня интересует анализировали ли стоимость решения одно vs другое и что получилось.
CloudSQL это классно, но далеко не всегда экономически целесообразно, а время на строительство, поддержку и т.п. зависит многих факторов, в т.ч. нагрузки на бд, прямоту рук девопса(ов), наличие девопсов в принципе и т.д.
Например, если база совсем не нагруженная и небольшая, то поднять небольшой instance с медленными дисками, которому в принципе не от чего падать, без high availability, настроить бэкапы на s3 и т.п. скорее всего будет дешевле использования CloudSQL.
Если DevOps в ладах с Terraform, Ansible и инфраструктурой как код в принципе, то развернуть и поддерживать такое не сложно и не затратно в человекочасах, но всё зависит от параметров проекта.
И теоретически если собственный PostgresSQL оказывается даже немного дешевле, то на длительном промежутке времени эта выгода будет накапливаться, а если таких клиентов много, то суммарно это приличная экономия.
Так-то по каждому чиху можно rds поднимать, но в тегах к статье же finops.
https://m.habr.com/ru/company/opsguru/blog/506112/comments/#comment_21722966
Поправлюсь: имел ввиду не self hosted, а self managed, конечно. Т.е. машина(ы) на линуксе с PostgresSQL в том же GCP.
Вы можете поделиться цифрами и ответить на вопрос?
Объём данных, нагрузка на базу, какой CloudSQL machine type используете, ha или нет и т.д.?
Уточню, что оценку трудозатрат на настройку и поддержку self hosted PostgresSQL не трогаем, только затраты на CloudSQL vs self hosted PostgresSQL в вашем конкретном кейсе.
Не вижу проблем рассмотреть это "в отрыве от основного процесса".
Неужели CloudSQL для этого кейса вам обходится дешевле, чем self hosted PostgreSQL?
В таких компаниях уж точно наружу не выставляется rdgw с такими решениями, которые привёл автор статьи.
Использовать или не использовать splitdns это уже второй вопрос.
Например, вот так выглядит конфиг сервера OpenVPN 2.4.6.x (server.opvn) на Windows Server:
port 1194proto udp
dev tun
server 10.8.0.0 255.255.255.0
push "route 10.8.0.0 255.255.0.0 vpn_gateway"
mssfix
tun-mtu 1500
keepalive 10 120
reneg-sec 0
comp-lzo
persist-key
persist-tun
verb 4
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\server.crt"
key "C:\\Program Files\\OpenVPN\\config\\server.key"
dh "C:\\Program Files\\OpenVPN\\config\\dh2048.pem"
tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 0
crl-verify "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\crl.pem"
ifconfig-pool-persist "C:\\Program Files\\OpenVPN\\config\\ipp.txt"
status "C:\\Program Files\\OpenVPN\\log\\openvpn-status.log"
log "C:\\Program Files\\OpenVPN\\log\\openvpn.log"
Конфиг именно с реализованным splitdns под рукой нет, но гуглится это достаточно легко, вариантов масса.
Всем накатывается клиент (предпочитаю openvpn + udp) + раздаётся конфиг с вшитым в него сертификатом + настаивается автоподключение при загрузке + splitdns, чтобы трафик шёл в туннель только для рабочих адресов. Рекомендуется защищать конфиг паролем при подключении, но можно и без него, чтобы пользователи совсем не беспокоились. К openvpn ещё и двухфакторная авторизация прикручивается очень легко (смс, google authenticator и т.п.).
Можно для каждого бандл (установщик+конфиг) сформировать и накатить какими-нибудь политиками или чем вы машины конфигурируете.
Множество самого не продвинутого персонала работает с таким абсолютно нормально (говорю из опыта), а есть персонал и гораздо более непродвинутый, чем бухгалтера.
Знают, что если иконка в углу экрана красная, то скорее всего нужно проверить своё подключение к интернет, т.к. openvpn обычно работает как часы.