Накатывать конфигурацию wireguard на все устройства удаленных сотрудников ансиблом, выглядит так себе решением. Где гарантии что плейбук успешно выполнится? Половина удаленных сотрудников может быть не в сети, да и в целом они могут быть разбросаны по всему миру, за натом, и устройства могут быть разными: телефон, планшет, пк, лаптоп. Может быть возможно использовать реальную систему управления конфигурациями, например puppet, salt, chef, но даже с ними будет очень много трудностей.
Также, для каждого сотрудника придется описывать в этой системе уникальный ip адрес вручную. DHCP вроде в wireguard не прикрутить (может я и ошибаюсь, но вроде адрес настраивается на клиентской стороне, и автоматом он его никак получить не может). А если сотрудников > 1000? (Ну конечно всегда можно накостылить скрипт, который генерит готовый yaml с ip адресами сотрудников для ansible/puppet/salt/chef)
А что делать если в организации разрешено использовать домашние устройства для работы? Тоже на них накатывать плейбуки ansible? Или агентов puppet, salt, chef?
В целом мне кажется это идея выглядит менее надежной, чем просто использовать штатные решения для VPN, которые все это поддерживают из коробки.
Статье два года и там сплошная ахинея
Слабая аргументация на мой взгляд. У вас есть опровержения аргументов из этой статьи? В статье довольно неплохо все расписано.
А в чём проблема с AllowedIPs? Тривиальная плейбука, в т.ч. и для пачки пользователей. С DNS вообще тривиально — указываете IP пира внутри туннеля и всё.
Это все настройки на клиентской стороне. А как я указал выше, их крайне проблемно централизованно накатывать на кучу устройств удаленных сотрудников. И в отличии от решений VPN где это все из коробки, вам придется все это реализовывать самому, а потом поддерживать. И все это для каждого вида ОС и устройства сотрудника. Предполагаю трудно будет накатить плейбук на телефон =)
В статье речь идет об организации vpn для компании. Wireguard крайне проблемно использовать для таких целей. Нет никаких централизованных возможностей по управлению клиентами, например если потребуется сменить маршруты или DNS и т.д. Вся проблематика использования его в enterprise секторе хорошо описана в этой статье
А разве CDN провайдеры не этим занимаются? Ну то есть договариваются с крупными провайдерами и ставят свои edge сервера по ближе к пользователям. С софтом проблем как раз нет, например взять nginx и salt (ansible, puppet, chef, ...) для управления nginx'ом на серверах не сложно. Мы же как раз и платим CDN провайдеру, за то, что у него есть куча серверов у крупных провайдеров, + автономные системы, и он этим всем управляет, мониторит, поддерживает, и т.д.
open source софт для создания открытого CDN, который любой интернет-провайдер мог поставить на своем железе
А кому будет принадлежать автономная система с блоками ip адресов и эти железки у провайдеров? Кто будет поддерживать их работу и управлять ими?
Про kaniko, buildkit, buildah, makisu я знаю. Меня интересует сборка именно в werf. Просто в статье это не совсем очевидно, мне кажется об этом нужно было упомянуть.
то начиная с Gitlab 12.10 есть возможность сборки образов с помощью kaniko в AWS Fargate
Gitlab не использую, но странно что это как-то ограниченно его версией. В Jenkins запускаю любой сборщик образов, без каких-либо проблем.
Если интересно, как это настроить, могу сделать пост
Думаю всем будет интересно почитать. Я для билдов AWS не использую, довольно дорого. Но нужной масштабируемости достигал связкой на hetzner cloud. k8s + cluster autosclaer + jenkins + kaniko. Правда kaniko багует частенько, да и хотелось использовать werf deploy, а не werf helm deploy-chart, по этому пока от этой связки отказался.
Наверное стоит упомянуть, что werf'у, по прежнему нужен демон докера для сборки, и поды внутри которых запускается сборка образа должны быть запущены с демоном докера, то есть по сути нужен DIND контейнер, и его нужно запускать со специальными привилегиями. Или я неправильно всё понял?
выбрали ТОП-запросов, дающих большую часть нагрузки и начали тюнинг
А какие инструменты для этого использовались? Просмотр slow лог? Счетчики в performance_schema (например events_statements_summary_by_digest)? Как именно определили что именно эти запросы загружают БД на столько-то процентов?
Со слейвами не совсем понятно. Вы написали, что из-за ошибки, бэкенды выполняли запросы на запись не только в мастер, но и в слейвы. Затем оба слейва перестали догонять мастера, вы исправили ошибку, отключили старые слейвы, и начали готовить новый. Но ведь все запросы на запись, которые ушли в эти слейвы на мастере в итоге не появились. Получается эти данные были утеряны?
Кстати можно еще более прозрачно отделить чтение от записи c помощью proxysql. А также настраивать хитрый роутинг запросов. Для бэкенда это будет выглядеть как обычная база, одна точка входа.
Как грубо. Вы действительно считаете сотрудников тех. поддержки макаками с 3 извилинами? Уверен большинство ответов, в которых кидают ссылки на базу знаний и тому подобное, сотрудник тех. поддержки легко бы решил сам, но это не в его компетенции, и он не должен тратить время на проблемы клиента, которые не обязан решать, и настраивать клиенту например VPN сервер. Но бросать трубки конечно не хорошо.
GEOM — мне хватало device mapper в Linux. Сейчас нигде не использую.
ZFS — у меня работал на Linux. Сейчас тоже нигде его не использую.
Netgraph — мне не нужен, да и на практике я его встречал совсем в уникальных кейсах. Вряд-ли когда-то потребуется
То есть для моей работы (обычный веб) FreeBSD бесполезен, и только приведет к затратам на эксплуатацию и никаких плюсов от него не будет.
> Ну или ты хочешь оптимизированную компиляцию (-march=native) под свою железку или нет…
Нет. Бизнес мне говорит, что ему надо в случае чего быстро развернуть 100+ нод в облаке и добавить их в кластер. Оптимизированную компиляцию бизнесу точно не надо
> А мне не понять, чего это вы вдруг взвились с подобными комментариями именно на моё сообщение просто о факте наличия софта — и при этом ещё и приводите все аргументы из области контейнеризации и облаков.
Не понимаю с чего вы взяли что я «взвился» на ваше сообщение. Я лишь пытаюсь выяснить как именно FreeBSD облегчит мою работу. И например позволит сэкономить на эксплуатации. Если это не так, то ок.
> И почему у всех должны быть именно такие задачи?
Я не считаю что у всех именно такие задачи. В статье написано: «FreeBSD лучше чем GNU/Linux». Если это действительно так, то мне нужно непременно узнать про это и рассказать бизнесу. Что я и пытаюсь сделать.
> всё искать через офсайт вместо пакетного менеджера
Не знаю что такое «новохипстерский путь». Репозитории дистрибутивов, как правило могут не иметь нужный софт, или иметь слишком старую версию. Проверять последнюю версию ПО и есть ли репозитории для моего дистрибутива от разработчиков софта считаю нормальным. Часто репозиториями от разработчиков софта удобней пользоваться, например там часто содержаться все версии пакета и легко откатываться на предыдущую или какую угодно версию. Также у меня нет под рукой freebsd и поискать в пакетном менеджере возможности нет. Нагуглить смог только список портов: www.freebsd.org/ports/searching.html. А список пакетов из репозитория бинарных пакетов например как для debian (https://packages.debian.org/index) не нашел.
> Вот рядом ответили — хетцнер и амазон — есть штатно.
Установка из штатного образа, который поднимается за пару секунд. И примонтировать ISO и из него поставить, я бы не назвал это «штатно». В amazon, да, действительно можно сказать есть «штатно», просто среди дефолтных AMI я его не нашел, и сделал вывод что его нет.
Вот список образов которые действительно штатные в hetzner:
$ hcloud image list
ID TYPE NAME DESCRIPTION IMAGE SIZE DISK SIZE CREATED
1 system ubuntu-16.04 Ubuntu 16.04 - 5 GB 2 years ago
2 system debian-9 Debian 9 - 5 GB 2 years ago
3 system centos-7 CentOS 7 - 5 GB 2 years ago
168855 system ubuntu-18.04 Ubuntu 18.04 - 5 GB 2 years ago
5924233 system debian-10 Debian 10 - 5 GB 7 months ago
8356453 system centos-8 CentOS 8 - 5 GB 4 months ago
9032843 system fedora-31 Fedora 31 - 5 GB 4 months ago
> Вы домысливаете несуществующее, не попытавшись хотя бы минуту почитать и понять. «Порты» это инфраструктура поставки продуктов за пределами базовой системы, но она позволяет как собирать на месте (если хотите), так и стягивать готовые пакеты
Это хорошо, видимо я что-то упустил. Я уделил точно больше минуты, так как в прошлом был опыт обслуживания серверов на freebsd. Возможно что-то забыл, но как-то запомнилось что порты это именно про сборку из исходников, а pkg пакетный менеджер, который качает и устанавливает архивы с бинарниками.
В портах? То есть я сейчас в 2020 году должен компилировать софт из исходников чтобы его поставить?
Хочу поставить clickhouse на сотне серверов, мне писать плейбук который его компилирует на сотне серверов? И так со всем софтом?
> Nginx вообще исторически в основном разрабатывался на FreeBSD
Откуда информация? Дайте пруфы пожалуйста. Тем не менее на офф. сайте nginx.org/en/download.html, сборки под Linux и Windows есть, под FreeBSD нет.
Из списка почти весь софт нужно компилировать из исходников, либо его вообще никак не поставить на FreeBSD (envoy, docker, podman, cri-o, contanerd и т.д.)
Ни в одном облаке (amazon, linode, hetzner, vultr) с которыми я в основном работаю, нет возможности поднимать виртуалки на freebsd.
Мне наверное не понять людей, которые топят за замену linux на freebsd. Мы видимо живем и работаем совсем в разных сферах или реальностях.
Конечно можно пойти к бизнесу, и сказать: давайте вложим кучу времени и перейдем на freebsd. А еще наймем побольше инженеров, так как кучу новых модулей для ansible, salt, puppet, chef, надо будет написать. А еще портировать containerd и k8s на freebsd и миллион подводных камней, которые всплывут в процессе всего этого. Я думаю бизнес ответит мне, что я дурачек и наймет другого инженера.
Я так понимаю поддержка freebsd в ansible, salt, chef, puppet тоже оставляет желать лучшего. 90% модулей не умеют работать в этой ОС. То есть писать все самому…
Jail это замечательно. Но containerd, cri-o там нет. А следовательно отсекаются все оркестраторы: k8s, nomad, mesos, docker swarm.
Без нормальной работы в freebsd: kubernetes, nomad, mesos, containerd, cri-o, ansible, salt, chef, puppet говорить о какой-то замене gnu/linux на freebsd как-то несерьезно.
Еще бы выяснить как часто выпускаются версии и поддерживается ли вообще популярное ПО: nginx, haproxy, envoy, traefik, clickhouse, mongodb, mariadb, percona xtradb cluster, portgres, tarantool, casandra, kafka, rabbitmq, prometheus, zabbix, elsasticsearch, kibana, logatash, nxlog, graylog, gitlab, jenkins и т.д.
Нормального IaC не построить, контейнеры (containerd, cri-o) и оркестраторы для них поднять нельзя. Половина популярного софта не выпускается под эту ОС, а у другой половины запаздывают версии. Я не очень понимаю как я могу в своей работе заменить GNU/Linux на FreeBSD, и как мне FreeBSD облегчит работу.
Хотя сетевой стек мне во FreeBsd очень нравится. netgraph божественен.
Инструменты разные. Но цель у инструментов одна — управление конфигурацией.
Нет, цель не совсем одна. Ansible является более широким инструментом, он умеет оркестрацию, деплой и любую другую автоматизацию. А для этих задач в экосистеме Puppet как раз используют bolt/mco/chaori. И если бы статья была полноценным сравнением, то нужно было раскрыть эту тему. Также у puppet есть свой стейт, есть база данных (puppetdb). Статья очень плохо раскрывает тему на мой взгляд.
Предложите ua-hosting качественные статьи.
Я не хочу работать за ua-hosting и искать для них статьи. Я прошу ua-hosting подходить более качественно к этому делу.
Статья плохого качества. Puppet и ansible хоть и решают похожие задачи, но все же инструменты разные. Если уж сравнивать Puppet с ansible, то логичнее сравнивать bolt или chaori с ansible. Так как они решают именно такую же задачу как и ansible, но принято их использовать с экосистемой Puppet. Статья с таким сравнением, говорит что автор плохо разбирается как минимум в экосистеме Puppet'а. Тема раскрыта плохо.
Такое ощущение, что ua-hosting, просто переводят (причём плохо) кучу статей ради пиара. Я не против такого, если бы статьи были бы качественные + с хорошим переводом.
Да какие уязвимости. У redis дизайн такой, его НЕ НУЖНО выставлять наружу в интернет, даже с паролем. О чем в доках и написано (https://redis.io/topics/security):
Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.
И даже если есть аутентификация, то советуют ее включать только как дополнительное средство защиты:
The goal of the authentication layer is to optionally provide a layer of redundancy. If firewalling or any other system implemented to protect Redis from external attackers fail, an external client will still not be able to access the Redis instance without knowledge of the authentication password.
Многие просто игнорируют рекомендации, за это и страдают. Там же protected mode по умолчанию включен, то есть его видимо выключают.
Из статьи не совсем понял. В итоге вы PostgreSQL + Patroni деплоете в кластер kuberentes, и это работает в контейнерах на обычных google инстанах, только в кластере kubernetes? Но это же on-premises, или нет?
Хотелось бы больше подробностей по данному решению. Как защищаетесь от OOM? Какие реквесты/лимиты указаны для контейнеров с postgreSQL? Какая нагрузка на базу? Прибиваете ли поды с СУБД к конкретным нодам k8s? Огораживаете эти узлы, чтобы на них не запускались поды других приложений? Как в итоге решили необходимость гео-распределенности базы: реплики базы деплоятся в отдельный кластер в других регионах или у вас один кластер на все регионы (не уверен что в гугле так можно). Если реплики деплоятся в отдельные кластера в других регионах, как это организовано? Описание kubernetes ресурсов для деплоя СУБД хранятся в отдельном репозитории? Как организован деплой этого?
Вы забыли про вариант аренды железных серверов, бОльшая нагрузка по обслуживанию железа ложиться на провайдера, а цены на эти серверные ресурсы гораздо ниже чем на облако. И то что для облаков вам якобы не нужен админ/ops, на мой взгляд миф. Так как у вас равно будет Ci/CD и infrastructure as Code, мониторинг и т. д. При достаточно больших нагрузках, за облако могут быть такие цены, что для вас, нанять + одного админа и жить на арендованном железе будет дешевле на порядок. Конечно, в облаке могут быть очень интересные фишки, реализация которых на своём железе и своими силами может оказаться дороже. Не все иак однозначно.
Также, для каждого сотрудника придется описывать в этой системе уникальный ip адрес вручную. DHCP вроде в wireguard не прикрутить (может я и ошибаюсь, но вроде адрес настраивается на клиентской стороне, и автоматом он его никак получить не может). А если сотрудников > 1000? (Ну конечно всегда можно накостылить скрипт, который генерит готовый yaml с ip адресами сотрудников для ansible/puppet/salt/chef)
А что делать если в организации разрешено использовать домашние устройства для работы? Тоже на них накатывать плейбуки ansible? Или агентов puppet, salt, chef?
В целом мне кажется это идея выглядит менее надежной, чем просто использовать штатные решения для VPN, которые все это поддерживают из коробки.
Слабая аргументация на мой взгляд. У вас есть опровержения аргументов из этой статьи? В статье довольно неплохо все расписано.
Это все настройки на клиентской стороне. А как я указал выше, их крайне проблемно централизованно накатывать на кучу устройств удаленных сотрудников. И в отличии от решений VPN где это все из коробки, вам придется все это реализовывать самому, а потом поддерживать. И все это для каждого вида ОС и устройства сотрудника. Предполагаю трудно будет накатить плейбук на телефон =)
А кому будет принадлежать автономная система с блоками ip адресов и эти железки у провайдеров? Кто будет поддерживать их работу и управлять ими?
Gitlab не использую, но странно что это как-то ограниченно его версией. В Jenkins запускаю любой сборщик образов, без каких-либо проблем.
Думаю всем будет интересно почитать. Я для билдов AWS не использую, довольно дорого. Но нужной масштабируемости достигал связкой на hetzner cloud. k8s + cluster autosclaer + jenkins + kaniko. Правда kaniko багует частенько, да и хотелось использовать
werf deploy, а неwerf helm deploy-chart, по этому пока от этой связки отказался.А какие инструменты для этого использовались? Просмотр slow лог? Счетчики в performance_schema (например events_statements_summary_by_digest)? Как именно определили что именно эти запросы загружают БД на столько-то процентов?
Со слейвами не совсем понятно. Вы написали, что из-за ошибки, бэкенды выполняли запросы на запись не только в мастер, но и в слейвы. Затем оба слейва перестали догонять мастера, вы исправили ошибку, отключили старые слейвы, и начали готовить новый. Но ведь все запросы на запись, которые ушли в эти слейвы на мастере в итоге не появились. Получается эти данные были утеряны?
Кстати можно еще более прозрачно отделить чтение от записи c помощью proxysql. А также настраивать хитрый роутинг запросов. Для бэкенда это будет выглядеть как обычная база, одна точка входа.
GEOM — мне хватало device mapper в Linux. Сейчас нигде не использую.
ZFS — у меня работал на Linux. Сейчас тоже нигде его не использую.
Netgraph — мне не нужен, да и на практике я его встречал совсем в уникальных кейсах. Вряд-ли когда-то потребуется
То есть для моей работы (обычный веб) FreeBSD бесполезен, и только приведет к затратам на эксплуатацию и никаких плюсов от него не будет.
Нет. Бизнес мне говорит, что ему надо в случае чего быстро развернуть 100+ нод в облаке и добавить их в кластер. Оптимизированную компиляцию бизнесу точно не надо
Не понимаю с чего вы взяли что я «взвился» на ваше сообщение. Я лишь пытаюсь выяснить как именно FreeBSD облегчит мою работу. И например позволит сэкономить на эксплуатации. Если это не так, то ок.
> И почему у всех должны быть именно такие задачи?
Я не считаю что у всех именно такие задачи. В статье написано: «FreeBSD лучше чем GNU/Linux». Если это действительно так, то мне нужно непременно узнать про это и рассказать бизнесу. Что я и пытаюсь сделать.
> всё искать через офсайт вместо пакетного менеджера
Не знаю что такое «новохипстерский путь». Репозитории дистрибутивов, как правило могут не иметь нужный софт, или иметь слишком старую версию. Проверять последнюю версию ПО и есть ли репозитории для моего дистрибутива от разработчиков софта считаю нормальным. Часто репозиториями от разработчиков софта удобней пользоваться, например там часто содержаться все версии пакета и легко откатываться на предыдущую или какую угодно версию. Также у меня нет под рукой freebsd и поискать в пакетном менеджере возможности нет. Нагуглить смог только список портов: www.freebsd.org/ports/searching.html. А список пакетов из репозитория бинарных пакетов например как для debian (https://packages.debian.org/index) не нашел.
> Вот рядом ответили — хетцнер и амазон — есть штатно.
Установка из штатного образа, который поднимается за пару секунд. И примонтировать ISO и из него поставить, я бы не назвал это «штатно». В amazon, да, действительно можно сказать есть «штатно», просто среди дефолтных AMI я его не нашел, и сделал вывод что его нет.
Вот список образов которые действительно штатные в hetzner:
> Вы домысливаете несуществующее, не попытавшись хотя бы минуту почитать и понять. «Порты» это инфраструктура поставки продуктов за пределами базовой системы, но она позволяет как собирать на месте (если хотите), так и стягивать готовые пакеты
Это хорошо, видимо я что-то упустил. Я уделил точно больше минуты, так как в прошлом был опыт обслуживания серверов на freebsd. Возможно что-то забыл, но как-то запомнилось что порты это именно про сборку из исходников, а pkg пакетный менеджер, который качает и устанавливает архивы с бинарниками.
В портах? То есть я сейчас в 2020 году должен компилировать софт из исходников чтобы его поставить?
Хочу поставить clickhouse на сотне серверов, мне писать плейбук который его компилирует на сотне серверов? И так со всем софтом?
> Nginx вообще исторически в основном разрабатывался на FreeBSD
Откуда информация? Дайте пруфы пожалуйста. Тем не менее на офф. сайте nginx.org/en/download.html, сборки под Linux и Windows есть, под FreeBSD нет.
Из списка почти весь софт нужно компилировать из исходников, либо его вообще никак не поставить на FreeBSD (envoy, docker, podman, cri-o, contanerd и т.д.)
Ни в одном облаке (amazon, linode, hetzner, vultr) с которыми я в основном работаю, нет возможности поднимать виртуалки на freebsd.
Мне наверное не понять людей, которые топят за замену linux на freebsd. Мы видимо живем и работаем совсем в разных сферах или реальностях.
Конечно можно пойти к бизнесу, и сказать: давайте вложим кучу времени и перейдем на freebsd. А еще наймем побольше инженеров, так как кучу новых модулей для ansible, salt, puppet, chef, надо будет написать. А еще портировать containerd и k8s на freebsd и миллион подводных камней, которые всплывут в процессе всего этого. Я думаю бизнес ответит мне, что я дурачек и наймет другого инженера.
Jail это замечательно. Но containerd, cri-o там нет. А следовательно отсекаются все оркестраторы: k8s, nomad, mesos, docker swarm.
Без нормальной работы в freebsd: kubernetes, nomad, mesos, containerd, cri-o, ansible, salt, chef, puppet говорить о какой-то замене gnu/linux на freebsd как-то несерьезно.
Еще бы выяснить как часто выпускаются версии и поддерживается ли вообще популярное ПО: nginx, haproxy, envoy, traefik, clickhouse, mongodb, mariadb, percona xtradb cluster, portgres, tarantool, casandra, kafka, rabbitmq, prometheus, zabbix, elsasticsearch, kibana, logatash, nxlog, graylog, gitlab, jenkins и т.д.
Нормального IaC не построить, контейнеры (containerd, cri-o) и оркестраторы для них поднять нельзя. Половина популярного софта не выпускается под эту ОС, а у другой половины запаздывают версии. Я не очень понимаю как я могу в своей работе заменить GNU/Linux на FreeBSD, и как мне FreeBSD облегчит работу.
Хотя сетевой стек мне во FreeBsd очень нравится. netgraph божественен.
Нет, цель не совсем одна. Ansible является более широким инструментом, он умеет оркестрацию, деплой и любую другую автоматизацию. А для этих задач в экосистеме Puppet как раз используют bolt/mco/chaori. И если бы статья была полноценным сравнением, то нужно было раскрыть эту тему. Также у puppet есть свой стейт, есть база данных (puppetdb). Статья очень плохо раскрывает тему на мой взгляд.
Я не хочу работать за ua-hosting и искать для них статьи. Я прошу ua-hosting подходить более качественно к этому делу.
Такое ощущение, что ua-hosting, просто переводят (причём плохо) кучу статей ради пиара. Я не против такого, если бы статьи были бы качественные + с хорошим переводом.
И даже если есть аутентификация, то советуют ее включать только как дополнительное средство защиты:
Многие просто игнорируют рекомендации, за это и страдают. Там же protected mode по умолчанию включен, то есть его видимо выключают.
Хотелось бы больше подробностей по данному решению. Как защищаетесь от OOM? Какие реквесты/лимиты указаны для контейнеров с postgreSQL? Какая нагрузка на базу? Прибиваете ли поды с СУБД к конкретным нодам k8s? Огораживаете эти узлы, чтобы на них не запускались поды других приложений? Как в итоге решили необходимость гео-распределенности базы: реплики базы деплоятся в отдельный кластер в других регионах или у вас один кластер на все регионы (не уверен что в гугле так можно). Если реплики деплоятся в отдельные кластера в других регионах, как это организовано? Описание kubernetes ресурсов для деплоя СУБД хранятся в отдельном репозитории? Как организован деплой этого?