Pull to refresh
  • by relevance
  • by date
  • by rating

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

Cloud computing *
logo DO-CoreOS

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

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


Читать дальше →
Total votes 34: ↑28 and ↓6 +22
Views 18K
Comments 15

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

Virtualization *


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

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

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

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

Website development *
Cloud hosting

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

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

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

Website development *
Docker friends

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

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

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

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

Selectel corporate blog Configuring Linux *System administration **nix *
Tutorial
CoreOS

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


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


Читать дальше →
Total votes 27: ↑27 and ↓0 +27
Views 13K
Comments 2

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

Конференции Олега Бунина (Онтико) corporate blog System administration *Server optimization *Network technologies *Server Administration *


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


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


Total votes 21: ↑20 and ↓1 +19
Views 14K
Comments 3

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

Флант corporate blog *nix *Server Administration *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).
Читать дальше →
Total votes 22: ↑22 and ↓0 +22
Views 30K
Comments 6

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

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

Читать дальше →
Total votes 24: ↑22 and ↓2 +20
Views 12K
Comments 2

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

Флант corporate blog IT Infrastructure *Network technologies *DevOps *Kubernetes *


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

Как появился CoreDNS, для чего он предназначен и как его можно использовать?
Читать дальше →
Total votes 16: ↑16 and ↓0 +16
Views 18K
Comments 0

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

ua-hosting.company corporate blog System administration *
Translation


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

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

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

Server optimization *Server Administration *

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


image


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

Что с проектами?
Total votes 13: ↑13 and ↓0 +13
Views 7.9K
Comments 8

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

System administration **nix *DevOps *Kubernetes *
Translation
Tutorial

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


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

Читать дальше →
Total votes 14: ↑11 and ↓3 +8
Views 10K
Comments 3

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

Southbridge corporate blog System administration *Server Administration *DevOps *
Translation


Короткая история о 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]
Читать дальше →
Total votes 25: ↑25 and ↓0 +25
Views 4.1K
Comments 2

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

C++ *Data storages *Distributed systems *

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


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



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

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

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

System administration *PostgreSQL *Server Administration *
Sandbox

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


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

Читать дальше →
Total votes 13: ↑13 and ↓0 +13
Views 19K
Comments 8

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

ua-hosting.company corporate blog High performance *IT Infrastructure *Server Administration *Conferences
Zabbix — популярная открытая система мониторинга, используется большим количеством компаний. Я расскажу об опыте создания кластера мониторинга.

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

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



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

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

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



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

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

Флант corporate blog System administration *Network technologies *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. Обычно всё хорошо работает, но есть пара моментов:
Читать дальше →
Total votes 35: ↑34 and ↓1 +33
Views 4K
Comments 0

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

Флант corporate blog System administration *Data storages *Kubernetes *
Translation
Прим. перев.: эта статья — итоги мини-исследования, проведенного инженерами IBM Cloud в поисках решения реальной проблемы, связанной с эксплуатацией базы данных etcd. Для нас была актуальна схожая задача, однако ход размышлений и действий авторов может быть интересен и в более широком контексте.



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


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

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

VK corporate blog Kubernetes *
Translation
Inside of the Nautical Cave by AshnoAlice

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