Как стать автором
Обновить
  • по релевантности
  • по времени
  • по рейтингу

DigitalOcean добавил возможность использования CoreOS

Облачные вычисления *
logo DO-CoreOS

Буквально позавчера DigitalOcean объявила о возможности использования предустановленного образа CoreOS.

По заверениям DigitalOcean их интеграция с альфа-версией CoreOS предоставит мобильным и веб-разработчикам, заитересованных в использовании Docker, простой и быстрый путь для выпуска приложений и экспериментов с контейнерами. В CoreOS docker-контейнеры могут стартовать за миллисекунды, обеспечивая беспрецедентную гибкость в управлении нагрузкой на кластер дроплетов. Среди дополнительных плюшек — автоматическое обновление, автоматическая настойка сети и интерграция с etcd.
При этом DigitaOcean выпустила ряд статей по запуску и настройке CoreOS:


Читать дальше →
Всего голосов 34: ↑28 и ↓6 +22
Просмотры 18K
Комментарии 15

Docker и костыли в продакшене

Виртуализация *


Навеяно публикацией «Понимая Docker», небольшой пример костылей вокруг докера для запуска веб-приложений.

Я пробовал разные технологии обвязок, но некоторые (fig) выглядят несколько корявыми для применения, а некоторые (kubernetis, mesos) — слишком абстрактными и сложными.

В моей конфигурации есть несколько машин, на машинах выполняются разнообразные веб-приложения, некоторые из них требуют наличия локального хранилища. В качестве базовой схемы примем конфигурацию из двух фронтендов и одного бекенда, ceph (ФС) обеспечивает роуминг данных для бекенда там, где это необходимо.
Читать дальше →
Всего голосов 19: ↑17 и ↓2 +15
Просмотры 31K
Комментарии 55

Свой облачный хостинг за 5 минут. Часть 2: Service Discovery

Разработка веб-сайтов *
Cloud hosting

Привет Хабр! В предыдущей статье я рассказал как построить свой облачный хостинг за 5 минут, используя Ansible, Docker и Docker Swarm. В этой части я расскажу о том, как сервисы, запущенные в облаке, находят друг друга, как происходит балансировка нагрузки между ними и обеспечивается их отказоустойчивость.

Это вводная статья, здесь мы сосредоточимся на обзоре инструментов, которые будут решать проблему «обнаружения сервисов» в нашем облаке. В следующей части мы приступим к практике, поэтому я решил дать вам время поближе ознакомиться с ними.
Читать дальше →
Всего голосов 26: ↑23 и ↓3 +20
Просмотры 41K
Комментарии 1

Свой облачный хостинг за 5 минут. Часть 3: Consul, Registrator, Consul-Template

Разработка веб-сайтов *
Docker friends

Привет Хабр! Я продолжаю цикл статей о том, как построить свой облачный хостинг за 5 минут. В прошлой статье мы рассмотрели инструменты, которые помогут решить нам проблему обнаружения сервисов (Service Discovery). В это части мы приступим к практике, построим облако и посмотрим как эти инструменты ведут себя в реальной жизни.

Как и прежде, всю работу может выполнить обычный программист в течение 5 минут, просто запустив набор сценариев для Ansible, которые я подготовил специально для вас и выложил на GitHub.

Несмотря на то, что наше облако стало сложнее и теперь в нём используется бо́льшее число инструментов, построить его стало проще. Я полностью переписал набор сценариев из прошлых статей, удалил всё лишнее, остальное упростил настолько, насколько это вообще возможно.
Читать дальше →
Всего голосов 21: ↑20 и ↓1 +19
Просмотры 37K
Комментарии 12

Виртуальное приватное облако: работа с CoreOS и RancherOS

Блог компании Selectel Настройка Linux *Системное администрирование **nix *
Tutorial
CoreOS

Недавно мы добавили в сервис «Виртуальное приватное облако» новый образ с операционной системой RancherOS и обновили образ CoreOS.


Эти операционные системы будут интересны пользователям, которым необходим инструмент для простого управления большим количеством приложений в контейнерах и использования различных систем кластеризации контейнеров — Kubernetes, Docker Swarm, Apache Mesos и других.


Читать дальше →
Всего голосов 27: ↑27 и ↓0 +27
Просмотры 13K
Комментарии 2

Использование HAproxy iptables+еtcd+confd для автоматического service discovery в переменчивых сетях

Блог компании Конференции Олега Бунина (Онтико) Системное администрирование *Серверная оптимизация *Сетевые технологии *Серверное администрирование *


Сергей Пузырёв (Mail.Ru Group)


Меня зовут Сергей Пузырев, я системный администратор в Mail.ru, я занимаюсь проектом «Поиск». Да, на удивление, у Mail.ru есть поиск. Я люблю сервисы, которые не требуют внимания. Я системный администратор, и я не люблю работать системным администратором очень много, я люблю делать так, чтобы работы было меньше, поэтому одно из решений, которое мы пытаемся использовать в своей работе, я вам опишу.


Всего голосов 21: ↑20 и ↓1 +19
Просмотры 14K
Комментарии 3

Операторы для Kubernetes: как запускать stateful-приложения

Блог компании Флант *nix *Серверное администрирование *DevOps *Kubernetes *

Проблема stateful-приложений в Kubernetes


Конфигурация, запуск и дальнейшее масштабирование приложений и служб осуществляются просто, если речь идёт о случаях, классифицируемых как stateless, т.е. без сохранения данных. Такие сервисы удобно запускать в Kubernetes, пользуясь его стандартными API, потому что всё происходит «из коробки»: по стандартным конфигурациям, без привлечения какой-либо специфики и магии.

Проще говоря, для запуска в кластере из контейнеров ещё пяти копий бэкенда на PHP/Ruby/Python требуется лишь 5 раз поднять новый сервер и скопировать исходники. Поскольку и исходники, и init-скрипт лежат в образе, масштабирование stateless-приложения становится совсем элементарным. Как хорошо известно любителям контейнеров и микросервисной архитектуры, сложности начинаются для приложений категории stateful, т.е. с сохранением данных, таких как базы данных и кэши (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra…). Это касается как софта, самостоятельно реализующего кворумный кластер (например, Percona XtraDB и Cassandra), так и софта, требующего отдельных управляющих утилит (такого, как Redis, MySQL, PostgreSQL…).

Сложности возникают по той причине, что исходников и запуска сервиса становится не достаточно — нужно выполнить еще некоторые действия. Как минимум — скопировать данные и/или присоединиться к кластеру. А если точнее, то эти сервисы требуют понимания, как их правильно масштабировать, обновлять и переконфигурировать без потери данных и их временной недоступности. Учёт этих потребностей и называется «эксплуатационными знаниями» (operational knowledge).
Читать дальше →
Всего голосов 22: ↑22 и ↓0 +22
Просмотры 29K
Комментарии 6

zetcd от CoreOS: Заменяя ZooKeeper на… хранилище etcd

Блог компании Флант Open source *Анализ и проектирование систем *NoSQL *Go *
На прошлой неделе компания CoreOS порадовала очередным Open Source-проектом — zetcd. На самом деле о нём было известно ещё с прошлого года, но теперь состоялся первый релиз, который перевёл продукт в статус бета-тестирования — заявил о готовности продукта к серьёзным испытаниям перед выпуском в мир production. Авторы позиционируют zetcd как готовую замену для ZooKeeper внутри таких распределённых/кластерных решений, как Mesos, Apache Kafka и Apache Drill. Их настрою не препятствует даже тот факт, что etcd предлагает «плоское» хранение ключей-значений против иерархического подхода своего конкурента. Как они к этому пришли?

Читать дальше →
Всего голосов 24: ↑22 и ↓2 +20
Просмотры 12K
Комментарии 2

CoreDNS — DNS-сервер для мира cloud native и Service Discovery для Kubernetes

Блог компании Флант IT-инфраструктура *Сетевые технологии *DevOps *Kubernetes *


Две недели назад Open Source-проект CoreDNS отметился своим очередным релизом — 008. Авторы называют свой продукт «DNS-сервером, состоящим из цепочки промежуточных компонентов (middleware), каждый из которых реализует какую-то возможность DNS». Что примечательно, они уже успели добиться включения CoreDNS в список официальных проектов организации CNCF (Cloud Native Computing Foundation), пополнив ряды Kubernetes, Prometheus, CNI, containerd, rkt и других разработок, активно применяемых в мире контейнеров, микросервисов и «родных облачных приложений» (cloud native).

Как появился CoreDNS, для чего он предназначен и как его можно использовать?
Читать дальше →
Всего голосов 16: ↑16 и ↓0 +16
Просмотры 17K
Комментарии 0

Инструменты управления контейнерами

Блог компании ua-hosting.company Системное администрирование *
Перевод


Развертывание приложений всегда было головной болью разработчиков. Олдфаги, которым довелось кодить во времена Windows COM, наверняка помнят «DLL Hell» – настоящий кошмар девелоперов и сисадминов. Но хотя прошли годы, ежедневно растущий поток новых технологий зачастую создает путаницу и неуверенность.

Практически во всех случаях разработки ПО среда разработки значительно отличается от окружения, в котором приложение реально будет работать. Тот факт, что различные компьютеры будут сконфигурированы по-разному — очевиден и предсказуем, но при этом различное поведение приложения на этих компьютерах недопустимо.
Читать дальше →
Всего голосов 18: ↑9 и ↓9 0
Просмотры 7.6K
Комментарии 2

Red Hat поглощает компанию CoreOS

Серверная оптимизация *Серверное администрирование *

Компания Red Hat объявила о покупке компании CoreOS, хорошо знакомой многим хабравчанам, и занимающей достойное место на рынке систем контейнерной изоляции и сопутсвующего ПО. Озвученная сумма сделки — 250 млн. долларов.


image


Среди развивавшихся в CoreOS проектов, которые конкурировали с решениями Docker и Red Hat Atomic, можно отметить атомарно обновляемое Linux-окружение CoreOS Container Linux (появившейся на рынке в 2014 под названием CoreOS). Container Linux представил логику наличия в ОС только минимального набора компонентов, необходимых для запуска контейнеров.

Что с проектами?
Всего голосов 13: ↑13 и ↓0 +13
Просмотры 7.9K
Комментарии 8

Разворачиваем Kubernetes HA-кластер на Baremetal с помощью Kubeadm и Keepalived (простое руководство)

Системное администрирование **nix *DevOps *Kubernetes *
Перевод
Tutorial

Эта статья является свободной интерпретацей официального руководства Creating Highly Available Clusters with kubeadm для Stacked control plane nodes. Мне не нравятся сложный язык и примеры использованные в нем, поэтому я написал свое руководство.


Если у вас появятся какие-либо вопросы или вам будет что-то неясно, обратитесь к официальной документации или спросите Google. Все этапы описаны здесь в максимально простой и сдержанной форме.

Читать дальше →
Всего голосов 14: ↑11 и ↓3 +8
Просмотры 10K
Комментарии 3

Скорость хранилища подходит для etcd? Спросим fio

Блог компании Southbridge Системное администрирование *Серверное администрирование *DevOps *
Перевод


Короткая история о fio и etcd


Производительность кластера etcd во многом зависит от производительности его хранилища. etcd экспортирует некоторые метрики в Prometheus, чтобы предоставить нужные сведения о производительности хранилища. Например, метрику wal_fsync_duration_seconds. В документации к etcd сказано: чтобы хранилище считалось достаточно быстрым, 99-й процентиль этой метрики должен быть меньше 10 мс. Если вы планируете запустить кластер etcd на машинах Linux и хотите оценить, достаточно ли быстрое у вас хранилище (например, SSD), можно использовать fio — популярный инструмент для тестирования операций ввода-вывода. Запустите следующую команду, где test-data — это каталог под точкой подключения хранилища:


fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Нужно просто посмотреть результаты и проверить, что 99-й процентиль длительности fdatasync меньше 10 мс. Если да, у вас достаточно быстрое хранилище. Вот пример результатов:


  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]
Читать дальше →
Всего голосов 25: ↑25 и ↓0 +25
Просмотры 4.1K
Комментарии 2

Пять студентов и три распределённых key-value хранилища

C++ *Хранилища данных *Распределённые системы *

Или как мы писали клиентскую C++ библиотеку для ZooKeeper, etcd и Consul KV


В мире распределённых систем существует ряд типовых задач: хранение информации о составе кластера, управление конфигурацией узлов, детекция сбойных узлов, выбор лидера и другие. Для решения этих задач созданы специальные распределённые системы — сервисы координации. Сейчас нас будут интересовать три из них: ZooKeeper, etcd и Consul. Из всей богатой функциональности Consul мы сосредоточимся на Consul KV.



По сути все эти системы представляют собой отказоустойчивые линеаризуемые key-value хранилища. Хотя их модели данных и имеют существенные отличия, о чём мы поговорим позднее, они позволяют решать одни и те же практические проблемы. Очевидно, каждое приложение, использующее сервис координации, завязывается на один из них, что может приводить к необходимости поддерживать в одном датацентре несколько систем, решающих одинаковые задачи, для разных приложений.

Идея, призванная решить эту проблему, зародилась в одном австралийском консалтинговом агентстве, а нам – небольшой команде студентов – выпало её реализовывать, о чём я и собираюсь рассказать.
Читать дальше →
Всего голосов 8: ↑7 и ↓1 +6
Просмотры 3.6K
Комментарии 1

Построение кластера PostgreSQL высокой доступности с использованием Patroni, etcd, HAProxy

Системное администрирование *PostgreSQL *Серверное администрирование *
Из песочницы

Так уж вышло, что на момент постановки задачи я не обладал достаточной степенью опытности, чтобы разработать и запустить это решение в одиночку. И тогда я начал гуглить.


Не знаю, в чем загвоздка, но уже в который раз я сталкиваюсь с тем, что даже если делать все пошагово как в туториале, подготовить такой же enviroment как у автора, то все равно никогда ничего не работает. Понятия не имею, в чем тут дело, но когда я столкнулся с этим в очередной раз, я решил — а напишу-ка я свой туториал, когда все получится. Тот, который точно будет работать.

Читать дальше →
Всего голосов 13: ↑13 и ↓0 +13
Просмотры 18K
Комментарии 8

HighLoad++, Михаил Макуров (Интерсвязь): опыт создания резервного и кластеризованного Zabbix-сервиса

Блог компании ua-hosting.company Высокая производительность *IT-инфраструктура *Серверное администрирование *Конференции
Zabbix — популярная открытая система мониторинга, используется большим количеством компаний. Я расскажу об опыте создания кластера мониторинга.

В докладе я коротко упомяну о сделанных ранее правках (патчах), которые существенно расширяют возможности системы и готовят базу для кластера (выгрузка истории в «Кликхаус», асинхронный поллинг). И подробно рассмотрю вопросы, возникшие при кластеризации системы — разрешение конфликтов идентификаторов в БД, немного о CAP theorem и мониторинге с распределёнными БД, о нюансах работы Zabbix в кластерном режиме: резервирование и координирование работы серверов и прокси, о «доменах мониторинга» и новом взгляде на архитектуру системы.

Коротко расскажу о том, как запустить кластер у себя, где взять исходники, какие доп. настройки потребуются для кластера.



HighLoad++ Siberia 2019. Зал «Томск». 24 июня, 17:00. Тезисы и презентация. Следующая конференция HighLoad++ пройдет 6 и 7 апреля 2020 года в Санкт-Петербурге. Подробности и билеты по ссылке.
Всего голосов 26: ↑26 и ↓0 +26
Просмотры 6.5K
Комментарии 3

etcd 3.4.3: исследование надёжности и безопасности хранилища

Блог компании Флант Open source *NoSQL *Параллельное программирование *
Перевод
Прим. перев.: Содержимое этой статьи не совсем типично для нашего блога. Однако, как многим известно, etcd находится в самом сердце Kubernetes, из-за чего данное исследование, проведённое независимым консультантом в области надёжности, оказалось интересным и в среде инженеров, эксплуатирующих данную систему. Кроме того, оно интересно в разрезе того, как Open Source-проекты, уже зарекомендовавшие себя в production, совершенствуются даже на таком, весьма «низком», уровне.



Хранилище пар «ключ-значение» (KV) etcd представляет собой распределённую базу данных, основанную на алгоритме консенсуса Raft. В ходе анализа, проведенного в 2014 году, мы обнаружили, что etcd 0.4.1 по умолчанию была подвержена так называемым stale reads (операциям чтения, возвращающим старое, неактуальное значение из-за запаздывания синхронизации — прим. перев.). Мы решили вернуться к etcd (в этот раз — к версии 3.4.3), чтобы снова детально оценить ее потенциал в области надежности и безопасности.
Читать дальше →
Всего голосов 48: ↑48 и ↓0 +48
Просмотры 10K
Комментарии 18

Наш опыт работы с данными в etcd Kubernetes-кластера напрямую (без K8s API)

Блог компании Флант Системное администрирование *Сетевые технологии *Kubernetes *
Все чаще к нам обращаются клиенты с просьбой обеспечить доступ в Kubernetes-кластер для возможности обращения к сервисам внутри кластера: чтобы можно было напрямую подключиться к какой-то базе данных или сервису, для связи локального приложения с приложениями внутри кластера…



Например, возникает потребность подключиться со своей локальной машины к сервису memcached.staging.svc.cluster.local. Мы предоставляем такую возможность с помощью VPN внутри кластера, к которому подключается клиент. Для этого анонсируем подсети pod'ов, сервисов и push'им кластерные DNS клиенту. Таким образом, когда клиент пытается подключиться к сервису memcached.staging.svc.cluster.local, запрос уходит в DNS кластера и в ответ получает адрес данного сервиса из сервисной сети кластера или адрес pod'а.

K8s-кластеры мы настраиваем с помощью kubeadm, где по умолчанию сервисная подсеть — 192.168.0.0/16, а сеть pod'ов — 10.244.0.0/16. Обычно всё хорошо работает, но есть пара моментов:
Читать дальше →
Всего голосов 35: ↑34 и ↓1 +33
Просмотры 3.9K
Комментарии 0

Как с fio проверить диски на достаточную производительность для etcd

Блог компании Флант Системное администрирование *Хранилища данных *Kubernetes *
Перевод
Прим. перев.: эта статья — итоги мини-исследования, проведенного инженерами IBM Cloud в поисках решения реальной проблемы, связанной с эксплуатацией базы данных etcd. Для нас была актуальна схожая задача, однако ход размышлений и действий авторов может быть интересен и в более широком контексте.



Краткое резюме всей статьи: fio и etcd


Производительность кластера etcd сильно зависит от скорости хранилища, лежащего в его основе. Для контроля за производительностью etcd экспортирует различные метрики Prometheus. Одной из них является wal_fsync_duration_seconds. В документации к etcd говорится, что хранилище можно считать достаточно быстрым, если 99-й процентиль этой метрики не превышает 10 мс…
Читать дальше →
Всего голосов 37: ↑37 и ↓0 +37
Просмотры 6.1K
Комментарии 7

Как обслуживать etcd: несколько замечаний и советов

Блог компании VK Kubernetes *
Перевод
Inside of the Nautical Cave by AshnoAlice

Если вы администрируете кластеры Kubernetes в своей инфраструктуре, а не используете версии, управляемые облачными провайдерами, то, скорее всего, уже управляете кластером etcd. Для тех, кому это внове, команда Kubernetes aaS от Mail.ru перевела статью о том, как обслуживать etcd.
Читать дальше →
Всего голосов 22: ↑22 и ↓0 +22
Просмотры 4.1K
Комментарии 2
1