DevOps-инженер
Это часть 1 из серии 2 частей практического руководства по HashiCorp Consul. Эта часть в первую очередь ориентирована на понимание проблем, которые решает Consul и как он их решает. Вторая часть больше ориентирована на практическое применение Consul в реальном примере и будет опубликована на следующей неделе. Давайте начнем.
В этой инструкции показывается как настроить пользователей только для чтения в PostgreSQL для Redash.
Что такое Terraform 12 и Terragrunt, и как это можно применять для Multi-Cloud инфраструктуры.
Мы поговорим про IaC (Инфраструктура как код) влияние на современный мир и о том, как Terraform помогает работать с гетерогенных окружениях. Я хочу обсудить немного сам Terraform, какие у него есть проблемы и как их решает Terragrunt. После я расскажу про мой опыт с Terragrunt и немного зацеплю такую тему, как Multi-Clouds.Во второй части обсуждения темы я бы хотел показать результат моих находок в использовании Terraform+Terragrunt в среде с тремя облачными провайдерами (AWS, GCP, Azure) и CloudFlare в качестве DNS.
Kafka — распределённый брокер сообщений, нашедший широкое применение как универсальная шина для больших данных. Kafka позволяет как реализовать realtime-обработку большого числа событий, так и построить батчевый pipeline по доставке логов.
Почему мы используем Kafka? Если коротко — унификация. А если чуть подробнее — десятки поставщиков, терабайты логов каждый день, онлайн- и офлайн-pipeline'ы — без единой высокопроизводительной шины данных с этим крайне сложно совладать.
Из доклада вы узнаете о том, почему мы перешли на Kafka, и как она вписалась в наш pipeline. Поймёте, как обеспечить exactly once доставку данных. Узнаете о том, как из-за одной опечатки в несколько раз выросла нагрузка на Kafka, и что мы из этого выяснили. Выясните, какие метрики Kafka стоит мониторить и как по ним понять, что что-то идёт не так.
Patroni и Stolon — два наиболее известных и продвинутых решения для оркестрации PostgreSQL и обеспечения высокой доступности (автофейловера) кластеров Leader-Followers конфигурации. Однако инженеры, переходящие со старых проверенных решений (Corosync&Pacemaker) и встроенных из других СУБД, сталкиваются со сложностями в инсталляции этих инструментов и непониманием ролей каждого из компонентов. В данном мастер-классе будет рассмотрен типичный процесс инсталляции кластеров Patroni и Stolon на виртуальных машинах (не в контейнерах), а также разобрано поведение этих кластеров при различных фейлах в инфраструктуре. Весь процесс будет демонстрироваться на трёх виртуальных машинах под управлением vagrant с использованием предварительно подготовленных образов. При желании слушатель может следовать за процессом, предварительно подготовив своё окружение.
В этом руководстве мы будем изучать, как тестировать код инфраструктуры, написанный на Ansible, с использованием инфраструктуры тестирования, известной как Molecule. Внутри Molecule мы будем использовать Ansible в качестве верификатора, чего я пока нигде не мог найти. Давай сделаем это!
Рано или поздно в нагруженном проекте возникает потребность в какой-то специализированной базе данных, кэше или ином хранилище. Причина такой потребности, как правило, погоня за производительностью, низким временем отклика или эффективностью хранения данных.
В своем докладе я расскажу о нашем опыте разработки и эксплуатации специализированной timeseries БД, в основе которой лежит Apache Kafka.
Мы все знаем, что большинство DBA очень консервативны и предпочитают, чтобы их базы жили исключительно на выделенных серверах. В современном мире с микросервисами, Kafka и Kubernetes количество баз начинает расти прямо пропорционально размеру организации и очень быстро выходит за пределы комфортного ручного или полуавтоматического управления.
Чтобы поддерживать базы данных в здоровом состоянии, необходимо периодически заглядывать «под капот», «прощупывать» её на наличие ранних симптомов — другими словами, делать профилактическое исследование, оно же технический аудит БД, оно же healthcheck.
В посте рассматриваются следующие Ansible модули loop: with_items, with_nested, with_subelements, with_dict.
Всем привет! Меня зовут Станислав Лукьянов. Я работаю в компании GridGain. Сегодня я хотел поговорить о том, как мы поддерживаем старые версии в Git.
Казалось бы, разработчики Terraform предлагают достаточно удобные best practices для работы с AWS-инфраструктурой. Только есть нюанс. Со временем количество окружений увеличивается, в каждом появляются особенности. Появляется почти копия стека приложений в соседнем регионе. И Terraform-код нужно аккуратно скопировать и отредактировать согласно новым требованиям или сделать снежинку.
Мой доклад про паттерны в Terraform для борьбы с хаосом и ручной рутиной на крупных и долгих проектах.
Как backend-разработчик понимает, что SQL-запрос будет хорошо работать на «проде»? В крупных или быстро растущих компаниях доступ к «проду» есть далеко не у всех. Да и с доступом далеко не все запросы можно безболезненно проверить, а создание копии БД часто занимает часы. Чтобы решить эти проблемы, мы создали искусственного DBA — Joe. Он уже успешно внедрен в несколько компаний и помогает не одному десятку разработчиков.
Когда-нибудь в далёком будущем автоматическое удаление ненужных данных будет одной из важных задач СУБД [1]. Пока же нам самим нужно заботиться об удалении или перемещении ненужных данных на менее дорогие системы хранения. Допустим, вы решили удалить несколько миллионов строк. Довольно простая задача, особенно если известно условие и есть подходящий индекс. "DELETE FROM table1 WHERE col1 = :value" — что может быть проще, да?
Доклад посвящен практическим вопросам разработки оператора в Kubernetes, проектированию его архитектуры и основных принципов функционирования.
В первой части доклада рассмотрим:
Далее, перейдём к обсуждению внутреннего устройства оператора. Рассмотрим архитектуру и функционирование оператора по шагам. Подробно разберём:
Рассмотрим управление шардами и репликами БД в Kubernetes.
Далее, обсудим вопросы хранения данных:
В заключительной части доклада рассмотрим практические примеры применения clickhouse-operator с Amazon или Google Cloud Service. Доклад строится на примере разработки и опыта эксплуатации оператора для ClickHouse.
Будет рассмотрен вклад Яндекса в следующие базы данных.
Terraform — это популярный инструмент компании Hashicorp, для управления вашей облачной инфраструктурой в парадигме Infrastructure as a Code.
Terragrunt — это wrapper для Terraform, которая предоставляет дополнительные инструменты для хранения ваших конфигураций Terraform, работы с несколькими модулями Terraform и управления удаленным состоянием.
В докладе Андрей Бородин расскажет, как они учли опыт масштабирования PgBouncer при проектировании пулера соединений Odyssey, как выкатывали его в production. Кроме того, обсудим какие функции пулера хотелось бы видеть в новых версиях: нам важно не только закрывать свои потребности, но развивать сообщество пользователей Одиссея.
Автоматизация рабочего процесса Java-проекта с помощью модифицированной модели ветвления Gitflow
Разделение функций с использованием изолированных ветвей позволяет вам решить, какие функции включать в каждый релиз. Компромисс здесь может заключаться в сложных слияниях.
Вы используете семантический подход к управлению версиями? Вы используете gitflow? Скорее всего, вы знакомы с процессом корректировки версий, создания веток, слияния с master/dev, повторной корректировки версий, борьбы с конфликтами слияния,…
В этой статье я кратко объясню процесс выпуска, который мы, по сути, используем для наших библиотек, и то, как мы его автоматизировали. Обычно мы используем подход CI/CD, используя номера сборок, но для наших библиотек мы решили использовать семантическое управление версиями. Я столкнулся с утомительным процессом выпуска, который сопровождает это в нескольких компаниях, и теперь я наконец нашел решение.