Еще пример - это запуск некоторых windows приложений на линуксе/маке приходится делать через parallels.
Я всё же задавал вопрос в контексте статьи про Vagrant и кубер, а не вообще зачем нужны виртуалки :)
Если же мы говорим про разработку, то если вы пишете софт который хоть как-то зависит от ядра, то рано или поздно вы начнете встречать проблемы, которые воспроизводятся только на конкретных версиях ядра. И тут без виртуалок было бы супер больно это фиксить.
При чём тут кубер, который оркестрирует контейнеры?
Кубер бывает нужен не только на серверах, но и на дев тачках. А на дев тачке может быть не только линукс, но и мак или же винда.
Это можно долго обсуждать, но реальные сервера, на которых работают приложения, которые пишут разработчики, работают на 90+% на линуксе, а уж те, где кубер и на все 99+%. И кубер оркестрирует собственно docker/containerd/podman & etc контейнеры.
Не понимаю зачем ещё городить себе прослойку в виде Vagrant, если можно взять тот же docker desktop, который да под капотом использует виртуализацию, но спрятана она достаточно хорошо для того, чтобы не отвлекать от работы собственно с контейнерами и кубером, если нужно его поднять локально. Для этого есть специальные и популярные решения и ни одно из них не использует Vagrant: minikube, K3s, K3D & etc.
Вы ещё и на курсах по куберу, но при этом не знаете чем VM отличается от docker и в принципе не зная докер изучаете кубер? Что за курсы такие волшебные, если не секрет?
Не спец по куберу. Только-только начал его изучать
А если серьёзно, то не должен софт быть жёстко привязан к конкретному серверу (дистрибутив ОС, версия ядра, состав железа, софта, e.t.c.) и виртуалки в этом смысле гораздо удобней.
1) Сервера для кубера на винде не поднимают. Это можно сделать, но в мире кубера 99% линукс.
2) На винде работают некоторые ...разработчики, но докер работает практически на любой ОС, как и K3D.
3) Есть огромная разница между виртуализацией и контейнеризацией и дело не удобстве. Изучите докер.
Vagrant это legacy, потому что это виртуалки, а они, как известно, потребляют значительно больше системных ресурсов, чем контейнеры и поднимаются медленнее.
K3D (не путать с K3S) для этих целей подходит гораздо лучше. Можно и несколько кластеров на одной машине запустить и всё в Docker.
Автор, наверное, отлично поупражнялся, но ставить такое кому-то точно не стоит, да и себе зачем, если существует как минимум несколько описанных выше в комментариях более "нативных" для куба решений, которыми гораздо удобнее управлять и они более гибкие.
Ваша текущая связка из wg-quick для одной части задачи и wg для другой выглядит сложнее и не такой "очевидной для других специалистов". По-моему лучше дописать вторую часть в свой новый форкнутый bash и хорошенько прокомментировать его + создать хорошую документацию.
Если это будут какие-то универсальные дополнения, то можно послать PR в репозиторий самого wg-quick, тогда у всех будет ваша версия. The power of open source :)
Вы разделяете утилиту wg-quick и wg, но wg-quick это, условно говоря, bash обёртка вокруг wg. Если вам чего-то не хватает в wg-quick то дописать это прямо в него достаточно просто.
Для работы с дэшбордами графаны рекомендую использовать код, git, grafonnet и ci/cd, а не "чеклист по нежной работе". Тогда и (внезапно) над кодом сможет работать несколько человек одновременно и других проблем избежите :)
Как я уже пояснил здесь https://habr.com/ru/post/581292/comments/#comment_23550562 я сходу не так понял предназначение вашего exporter'а.
Alerts по существующим метрикам настаиваются обычным способом для Alertmanager'а способом.
Популярный dashboard для blackbox exporter'а существует, но опять же blackbox exporter решает другую задачу.
Честно говоря, задача мониторить домены whois очень уж специфическая и не подходит под мой критерий необходимости реализации с помощью в Prometheus, который в основном предназначен для оперативного мониторинга. Когда у меня/владельца домена истекает какой-либо из доменов мне/ему заблаговременно и несколько раз приходит оповещение от регистратора и этого вполне достаточно, чтобы отреагировать.
Я ещё раз повторюсь: всё очень сильно зависит от кейса. Не утверждаю, что в 100% случаев облака дешевле даже при FinOps подходе, но он сильно меняет картину.
Серьёзную инфраструктуру в облаках никто не "накликивает" , (хотя конечно в отдельных случаях бывает и с таким боремся. Называем это ClickOps :) , а раскатывают Terraform'ом и это достаточно серьезный отдельный инструмент, которым нужно владеть. Вокруг него есть целая экосистема разных прибамбасов вроде Infracost, driftctl, terraformer, кучи community модулей, terragrunt и т.д. и т п.
Соглашусь, что мог выразиться более точно и всё высказанное мной стоит воспринимать исключительно в контексте темы поста и K8s.
Я всё же задавал вопрос в контексте статьи про Vagrant и кубер, а не вообще зачем нужны виртуалки :)
При чём тут кубер, который оркестрирует контейнеры?
https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
Это можно долго обсуждать, но реальные сервера, на которых работают приложения, которые пишут разработчики, работают на 90+% на линуксе, а уж те, где кубер и на все 99+%. И кубер оркестрирует собственно docker/containerd/podman & etc контейнеры.
Не понимаю зачем ещё городить себе прослойку в виде Vagrant, если можно взять тот же docker desktop, который да под капотом использует виртуализацию, но спрятана она достаточно хорошо для того, чтобы не отвлекать от работы собственно с контейнерами и кубером, если нужно его поднять локально. Для этого есть специальные и популярные решения и ни одно из них не использует Vagrant: minikube, K3s, K3D & etc.
del
Вы ещё и на курсах по куберу, но при этом не знаете чем VM отличается от docker и в принципе не зная докер изучаете кубер? Что за курсы такие волшебные, если не секрет?
Прочтите хоть что-то, это не долго. Например (первое нагуглилось) https://habr.com/ru/post/474068/
1) Сервера для кубера на винде не поднимают. Это можно сделать, но в мире кубера 99% линукс.
2) На винде работают некоторые ...разработчики, но докер работает практически на любой ОС, как и K3D.
3) Есть огромная разница между виртуализацией и контейнеризацией и дело не удобстве. Изучите докер.
Разве что для чего-то экзотического. Уверен, что более 90% остальных кейсов покроет K3D.
Можете привести пример для чего лично вам нужна именно виртуалка?
Вот так легко можно установить K3D и создать Highly Available 3 Master (!) + 3 Workers K3D cluster
Vagrant это legacy, потому что это виртуалки, а они, как известно, потребляют значительно больше системных ресурсов, чем контейнеры и поднимаются медленнее.
K3D (не путать с K3S) для этих целей подходит гораздо лучше. Можно и несколько кластеров на одной машине запустить и всё в Docker.
Автор, наверное, отлично поупражнялся, но ставить такое кому-то точно не стоит, да и себе зачем, если существует как минимум несколько описанных выше в комментариях более "нативных" для куба решений, которыми гораздо удобнее управлять и они более гибкие.
Ваша текущая связка из wg-quick для одной части задачи и wg для другой выглядит сложнее и не такой "очевидной для других специалистов". По-моему лучше дописать вторую часть в свой новый форкнутый bash и хорошенько прокомментировать его + создать хорошую документацию.
Если это будут какие-то универсальные дополнения, то можно послать PR в репозиторий самого wg-quick, тогда у всех будет ваша версия. The power of open source :)
Зависит от страны.
В таких странах как Иран и Китай с хорошими DPI нужны более интересные решения вроде Shadowsocks + v2ray, obfs proxy, port knocking и т.д.
Вы разделяете утилиту wg-quick и wg, но wg-quick это, условно говоря, bash обёртка вокруг wg. Если вам чего-то не хватает в wg-quick то дописать это прямо в него достаточно просто.
https://github.com/WireGuard/wireguard-tools/blob/master/src/wg-quick/linux.bash
А в чём проблема поставить мобильный клиент? Достаточно давно пользуюсь https://play.google.com/store/apps/details?id=com.wireguard.android
Для популярности OpenVPN необходимость установки клиентов не стала препятствием.
Для работы с дэшбордами графаны рекомендую использовать код, git, grafonnet и ci/cd, а не "чеклист по нежной работе". Тогда и (внезапно) над кодом сможет работать несколько человек одновременно и других проблем избежите :)
Довольно таки legacy stack решения для которого есть в первых строках любого поиска :)
ansible_become_pass + ansible vault и не слушайте этих судобезпарольщиков
Как я уже пояснил здесь https://habr.com/ru/post/581292/comments/#comment_23550562 я сходу не так понял предназначение вашего exporter'а.
Alerts по существующим метрикам настаиваются обычным способом для Alertmanager'а способом.
Популярный dashboard для blackbox exporter'а существует, но опять же blackbox exporter решает другую задачу.
Честно говоря, задача мониторить домены whois очень уж специфическая и не подходит под мой критерий необходимости реализации с помощью в Prometheus, который в основном предназначен для оперативного мониторинга. Когда у меня/владельца домена истекает какой-либо из доменов мне/ему заблаговременно и несколько раз приходит оповещение от регистратора и этого вполне достаточно, чтобы отреагировать.
Виноват, сходу неправильно понял предназначение exporter'а.
Зачем это если есть проверенный временем https://github.com/prometheus/blackbox_exporter ?
https://grafana.com/blog/2020/11/25/how-we-eliminated-service-outages-from-certificate-expired-by-setting-up-alerts-with-grafana-and-prometheus/
Какой-то очень кривой русский язык, как будто русский не родной язык автора.
Я ещё раз повторюсь: всё очень сильно зависит от кейса. Не утверждаю, что в 100% случаев облака дешевле даже при FinOps подходе, но он сильно меняет картину.
Серьёзную инфраструктуру в облаках никто не "накликивает" , (хотя конечно в отдельных случаях бывает и с таким боремся. Называем это ClickOps :) , а раскатывают Terraform'ом и это достаточно серьезный отдельный инструмент, которым нужно владеть. Вокруг него есть целая экосистема разных прибамбасов вроде Infracost, driftctl, terraformer, кучи community модулей, terragrunt и т.д. и т п.