Пользователь
Привет! Это вторая часть статей про хостинг серверов Minecraft, который мы строим. В первой части я рассказывал про физическую часть инфраструктуры — от ноутбук до серверной стойки. В этой же мы погрузимся в её логическую часть без долгой исторической справки, однако это звучит красиво: «от apache до k8s».
Углубляясь в тему DevOps в своей домашней лаборатории, я начал замечать, что зачастую проще задействовать TLS/mTLS, чем настраивать и отлаживать способы обойтись без него.
Задумавшись о надежном хостинге для приватного CA, обнаружил, что среди всего моего электрооборудования только у двух приборов аптайм близок к 100%: у холодильника и интернет-роутера.
Идея получать из холодильника не только напитки, но и SSL-сертификаты так грела душу, что я почти начал искать, где купить умный холодильник. Потом немного остыл и решил сначала попробовать роутер с прошивкой OpenWRT.
Всем привет! Мы занимаемся Zabbix и хотели бы поделиться своим опытом по настройке производительности Zabbix и тем, что мы видели при проведении аудитов инсталляций Zabbix. В этой статье постараемся помочь сэкономить ваше время на траблшутинг нестабильной работы Zabbix и показать направления для дебага. Пока не приступили к чтению, подпишитесь на наш телеграм-канал, посвященный исключительно Zabbix. Там ещё больше интересного материала по Zabbix.
Тюнинг производительности — обязательная часть работы администратора Zabbix. При росте количества узлов, количества собираемых элементов данных и снижению интервалов их сбора резко возрастает шанс столкнуться с бутылочными горлышками в производительности. Ключевые метрики, которые напрямую влияют на производительность — количество узлов (разумеется, с наполняемыми элементами данных) и количество новых значений в секунду. Чем их больше и чем меньше интервал сбора данных — тем больше нагрузка на инсталляцию Zabbix в целом. При этом, элементы данных типа Zabbix Trapper и SNMP-трап особого вклада в нагрузку не вносят. Подробности под катом.
Привет, Хабр!
Сегодня поговорим о балансировке нагрузки по DNS с использованием инструмента — Consul. Сейчас в основном все приложения разбиваются на множество мелких сервисов, и поэтому часто нужно сделать так, чтобы трафик равномернно распределился и имел высокую доступность.
Consul — это open-source инструмент от HashiCorp, который обеспечивает сервис-дискавери, проверку состояния сервисов, балансировку нагрузки и глобально распределенное хранилище ключ-значение.
Недавно мы выпустили новый сервис — объектное хранилище S3 на базе нашего облака. Запустили его на Ceph. Перед этим провели множество тестов. В частности, решили выяснить, как на практике Ceph справляется с мелкими объектами — проблемой любого S3. И вот что из этого вышло.
Все говорили – переходи на rust! Начинай пользоваться самым-самым языком, который самый любимый язык на stackoverflow и всё такое.
Я тяжело вздохнул и огляделся. Ну опять двадцать-пять. Ладно, давайте разбираться, как правильно покрывать всё ржавчиной.
Профессионально я программирую уже 17 лет. В далёкие-предалёкие времена я начал изучать программирование с x86 Assembly. Такой жестокий подход к изучению компьютера дал мне глубокое понимание того как работает процессор и что делают другие языки программирования. Учить новые языки для меня никогда не было проблемой. Я их просто учил. C, C++, шарпы, ГО, тысячи разных скриптов и фреймворков. Чего уж там, ещё один язык, можно и выучить.
Ага.
Только вот не с этой ржавой развалюхой. Я просидел две недели над официальным руководством, пялился в VSCode и не мог выдавить из себя больше чем fn main() {}. Ну какого же чёрта? Я просто закрыл глаза, открыл руководство на рандомной странице и начал его читать. И прикол в том, что я понял о чём там говориться. И тут до меня дошло… Руководство написано наизнанку. Начало и конец ничуть не лучше чем в Мементо Кристофера Нолана. Они как-то умудрились запутать в общем-то нормальное руководство. После этого всё пошло получше.
Ржавые шестерёнки заскрипели и начали крутиться. Программа пошла-поехала. Если хотите знать как я внедрил rust в продакшин, как я ему научился и что из этого вышло – добро пожаловать под кат. Реальные люди, коммиты, примеры и никаких todo-list и хеллоу-ворлдов.
Привет! Меня зовут Михаил Кажемский, я Lead DevOps в IT‑интеграторе Hilbert Team. В последнее время к нам часто обращаются заказчики, которым нужна помощь с организацией хранения долгосрочных метрик в российских облаках. Так как для многих эта задача сейчас актуальная, в данной статье мы с моим коллегой Денисом Бабичевым решили рассказать, как мы используем мощные возможности ClickHouse для эффективного долгосрочного хранения метрик Prometheus. В статье вы найдете рекомендации по использованию инструмента и описание альтернативных решений, таких как Thanos, Grafana Mimir и Victoria Metrics.
Для лиги лени. Какая-то заумь про то, что не нужно, потому что все равно давно у нормальных людей все приложения в облаках на микросервисах, и прекрасно работают.
Часть 4. Что из этого следует, и как устроен планировщик в KVM или KVM- QEMU. Тут тоже не будет ничего нового, но будет масса ошибок.
Пусть надо мной посмеются сетевые инженеры в больших интеграторах, у которых есть доступ к топовому оборудованию за кучу килобаксов. Я хочу рассказать о том, как можно получить свою домашнюю сетку, которая будет быстрой, и не разориться.
tl;dr Если кому интересно, то сейчас такая ситуация, что пару десктопов можно связать 56Gb сеткой за <$100+доставка из штатов. Если хочется больше компьютеров, то это <$100 за 12 портовый свитч 40Gb и ~$60 за десктоп, плюс доставка. Но это всё б/у и ноль гарантий.
Работа с контейнерами многим кажется волшебством, пришло время разобраться как работает сеть Docker. Мы покажем на примерах, что это совсем не сложно. Нам потребуется немного сетевой магии и никакого кода...
В этой статье мы ответим на следующие вопросы:
• Как виртуализировать сетевые ресурсы, чтобы контейнеры думали, что у каждого из них есть выделенный сетевой стек?
• Как превратить контейнеры в дружелюбных соседей, не дать им мешать друг другу и научить хорошо общаться?
• Как настроить сетевой доступ из контейнера во внешний мир (например, в Интернет)?
• Как получить доступ к контейнерам, работающим на сервере, из внешнего мира (публикация портов)?
Как известно, Docker умеет создавать виртуальные сети для безопасного и удобного сетевого взаимодействия внутри контейнеров. В этой статье мы рассмотрим, как именно он это делает на примере базовых манипуляций с сетью в рамках одного хоста с операционной системой Linux.
В этой статье мы собираемся разобраться со следующими вопросами:
* Как виртуализировать сетевые ресурсы, чтобы контейнеры думали, что у них есть отдельные сетевые среды?
* Как превратить контейнеры в дружелюбных соседей и научить общаться друг с другом?
* Как выйти во внешний мир (например, в Интернет) изнутри контейнера?
* Как связаться с контейнерами, работающими на хосте Linux, из внешнего мира?
* Как реализовать публикацию портов, подобную Docker?
Hashicorp Vault - прекрасный продукт для централизованного хранения всех паролей и других секретов компании. При этом, многие знают, что удобная ключница - это идеальный способ потерять все ключи одновременно. Когда я работал в крупном телекоме, то DRP-протоколы с восстановлением данных учитывали даже запрет на сбор более двух Хранителей Ключей в одном месте. Чисто на случай очень неудачного корпоратива с совместным полетом на воздушном шаре, дегустацией домашних грибов или другими подобными факторами. Короче, если вы внедряете подобную систему, то вам надо очень внимательно подходить не только к вопросам эксплуатации, но и резервного копирования и восстановления.
Сегодня я не буду глубоко касаться темы организации правильного хранения фрагментов ключей Шамира. Вместо этого, я попробую рассказать о том, как развернуть с нуля отказоустойчивый кластер Hashicorp Vault в community edition. Для этого поднимем основной и тестовый кластер Vault в нескольких регионах и датацентрах. Тестовый кластер у нас одновременно будет служить и резервным в рамках процедуры DRP.
Чтобы было совсем интересно, настроим процесс таким образом, чтобы тестовый кластер был односторонней репликой продуктивного с отставанием в несколько суток. Разумеется, все развертывание мы будем проводить в парадигме Infrastructure-as-a-code с Terraform и Ansible в качестве основных инструментов.
Сейчас расскажу, когда это может пригодиться и какими ansible-модулями можно для этого воспользоваться. Сразу предупреждаю - это будет лонгрид, так как я не люблю разбивать на кучу мелких постов единый туториал.
Мысль о централизованном мониторинге логов хранилась в моей голове много лет, но реализовать ее я смог только совсем недавно. Рассказываю о настройке и подводных камнях связки Logstash + Manticore + Nginx + Symfony.
Настройка централизованного логирования с использованием Dokku, Loki и Grafana
Централизованное логирование играет важную роль в современном мониторинге и управлении серверами. Это позволяет оперативно анализировать и отслеживать работу приложений и серверов в реальном времени. В данной статье мы рассмотрим процесс настройки системы централизованного логирования с использованием таких мощных инструментов, как Dokku, Loki и Grafana. Совместное использование этих инструментов обеспечивает гибкую и масштабируемую систему для мониторинга и анализа данных ваших серверов.
Привет, Хабр! Меня зовут Александр Фикс, я менеджер по развитию бизнеса КРОК Облачные сервисы. Сегодня поговорим о тренде локализации, о том, что происходит на рынке файлообменников с уходом западных решений и какие альтернативные продукты есть у бизнеса в данный момент.
Мы проанализировали возможные варианты, собрали текущие проблемы и требования корпоративных пользователей и решили представлять Nextcloud как сервис из Облака КРОК. Подробно расскажу о возможностях такого решения, покажу его архитектуру, интерфейс и подсвечу преимущества.
