Как стать автором
Обновить
59
0
ua-hosting.company @ua-hosting

Корпоративный аккаунт

Отправить сообщение

Kонференция NDС London. Предотвращение катастрофы микросервисов. Часть 1

Время на прочтение11 мин
Количество просмотров4.8K
Вы потратили месяцы, переделывая свой монолит в микросервисы, и наконец, все собрались, чтобы щелкнуть выключателем. Вы переходите на первую веб-страницу… и ничего не происходит. Перезагружаете ее — и снова ничего хорошего, сайт работает так медленно, что не отвечает в течение нескольких минут. Что же случилось?

В своем выступление Джимми Богард проведет «посмертное вскрытие» реальной катастрофы микросервиса. Он покажет проблемы моделирования, разработки и производства, которые обнаружил, и расскажет, как его команда медленно трансформировала новый распределенный монолит в окончательную картину здравомыслия. Хотя полностью предотвратить ошибки проекта невозможно, можно, по крайней мере, выявить проблемы на ранней стадии проектирования, чтобы конечный продукт превратился в надежную распределенную систему.



Приветствую всех, я Джимми, и сегодня вы услышите, как можно избежать мегакатастроф при создании микросервисов. Эта история компании, в которой я проработал около полутора лет, чтобы помочь предотвратить столкновение их корабля с айсбергом. Чтобы рассказать эту историю должным образом, придется вернуться в прошлое и поговорить о том, с чего начиналась эта компания и как со временем росла ее ИТ-инфраструктура. Чтобы защитить имена невиновных в этой катастрофе, я изменил название этой компании на Bell Computers. На следующем слайде показано, как выглядела IT инфраструктура таких компаний в середине 90-х. Это типичная архитектура большого универсального отказоустойчивого сервера HP Tandem Mainframe для функционирования магазина компьютерной техники.
Всего голосов 14: ↑12 и ↓2+18
Комментарии0

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 4

Время на прочтение7 мин
Количество просмотров2.5K
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ — анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.
Всего голосов 15: ↑15 и ↓0+15
Комментарии0

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 3

Время на прочтение7 мин
Количество просмотров2.2K
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ — анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.
Всего голосов 12: ↑11 и ↓1+18
Комментарии0

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 2

Время на прочтение7 мин
Количество просмотров3.5K
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ — анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.
Всего голосов 15: ↑15 и ↓0+15
Комментарии2

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 1

Время на прочтение8 мин
Количество просмотров6K
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ — анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Около 15 лет назад моя мачеха, назовем ее Фрэнсис, стала чувствовать боль и слабость во всем теле, ей стало трудно стоять, и когда врачи в больнице немного привели ее в себя, у нее обнаружился паралич рук и ног. Это было ужасное испытание для нее и для нас, как оказалось, диагнозом стал синдром Гийона-Барре. Мне просто любопытно, кто-нибудь из вас слышал о такой болезни? О, довольно много людей! Надеюсь, вы получили эту информацию не из первых рук. Это аутоиммунное заболевание, острый полирадикулоневрит, при котором иммунная система человека поражает собственные периферические нервы.



Обычно эту болезнь провоцирует какой-то внешний фактор, но интересно в ней то, что антитела атакуют непосредственно миелиновую оболочку аксона так, что повреждают ее по всей длине нерва, и его сигналы становятся очень рассеянными. Поэтому можно логично объяснить все симптомы боли, слабости и паралич, понимая, что происходит с нервной системой. Хорошие новости состоят в том, что это заболевание можно вылечить либо через плазмаферез, когда кровь фильтруется вне вашего тела, либо с помощью антительной терапии.
Всего голосов 17: ↑17 и ↓0+17
Комментарии0

Конференция DEVOXX UK. Выбираем фреймворк: Docker Swarm, Kubernetes или Mesos. Часть 3

Время на прочтение10 мин
Количество просмотров2.9K
Docker Swarm, Kubernetes и Mesos являются наиболее популярными фреймворками для оркестровки контейнеров. В своем выступлении Арун Гупта сравнивает следующие аспекты работы Docker, Swarm, и Kubernetes:

  • Локальный девелопмент.
  • Функции развертывания.
  • Мультиконтейнерные приложения.
  • Обнаружение служб service discovery.
  • Масштабирование сервиса.
  • Run-once задания.
  • Интеграция с Maven.
  • «Скользящее» обновление.
  • Создание кластера БД Couchbase.

В результате вы получите четкое представление о том, что может предложить каждый инструмент оркестровки, и изучите методы эффективного использования этих платформ.

Арун Гупта — главный технолог open-source продуктов Amazon Web Services, который уже более 10 лет развивает сообщества разработчиков Sun, Oracle, Red Hat и Couchbase. Имеет большой опыт работы в ведущих кросс-функциональных командах, занимающихся разработкой и реализацией стратегии маркетинговых кампаний и программ. Руководил группами инженеров Sun, является одним из основателей команды Java EE и создателем американского отделения Devoxx4Kids. Арун Гупта является автором более 2 тысяч постов в IT-блогах и выступил с докладами более чем в 40 странах.
Всего голосов 14: ↑14 и ↓0+14
Комментарии0

Конференция DEVOXX UK. Выбираем фреймворк: Docker Swarm, Kubernetes или Mesos. Часть 2

Время на прочтение9 мин
Количество просмотров3.5K
Docker Swarm, Kubernetes и Mesos являются наиболее популярными фреймворками для оркестровки контейнеров. В своем выступлении Арун Гупта сравнивает следующие аспекты работы Docker, Swarm, и Kubernetes:

  • Локальный девелопмент.
  • Функции развертывания.
  • Мультиконтейнерные приложения.
  • Обнаружение служб service discovery.
  • Масштабирование сервиса.
  • Run-once задания.
  • Интеграция с Maven.
  • «Скользящее» обновление.
  • Создание кластера БД Couchbase.

В результате вы получите четкое представление о том, что может предложить каждый инструмент оркестровки, и изучите методы эффективного использования этих платформ.

Арун Гупта — главный технолог open-source продуктов Amazon Web Services, который уже более 10 лет развивает сообщества разработчиков Sun, Oracle, Red Hat и Couchbase. Имеет большой опыт работы в ведущих кросс-функциональных командах, занимающихся разработкой и реализацией стратегии маркетинговых кампаний и программ. Руководил группами инженеров Sun, является одним из основателей команды Java EE и создателем американского отделения Devoxx4Kids. Арун Гупта является автором более 2 тысяч постов в IT-блогах и выступил с докладами более чем в 40 странах.
Всего голосов 17: ↑17 и ↓0+17
Комментарии0

Конференция DEVOXX UK. Выбираем фреймворк: Docker Swarm, Kubernetes или Mesos. Часть 1

Время на прочтение6 мин
Количество просмотров3.6K
Docker Swarm, Kubernetes и Mesos являются наиболее популярными фреймворками для оркестровки контейнеров. В своем выступлении Арун Гупта сравнивает следующие аспекты работы Docker, Swarm, и Kubernetes:

  • Локальный девелопмент.
  • Функции развертывания.
  • Мультиконтейнерные приложения.
  • Обнаружение служб service discovery.
  • Масштабирование сервиса.
  • Run-once задания.
  • Интеграция с Maven.
  • «Скользящее» обновление.
  • Создание кластера БД Couchbase.

В результате вы получите четкое представление о том, что может предложить каждый инструмент оркестровки, и изучите методы эффективного использования этих платформ.

Арун Гупта — главный технолог open-source продуктов Amazon Web Services, который уже более 10 лет развивает сообщества разработчиков Sun, Oracle, Red Hat и Couchbase. Имеет большой опыт работы в ведущих кросс-функциональных командах, занимающихся разработкой и реализацией стратегии маркетинговых кампаний и программ. Руководил группами инженеров Sun, является одним из основателей команды Java EE и создателем американского отделения Devoxx4Kids. Арун Гупта является автором более 2 тысяч постов в IT-блогах и выступил с докладами более чем в 40 странах.
Всего голосов 12: ↑11 и ↓1+15
Комментарии10

DEVOXX UK. Kubernetes в продакшене: Blue/Green deployment, автомасштабирование и автоматизация развертывания. Часть 2

Время на прочтение13 мин
Количество просмотров2.2K
Kubernetes — это отличный инструмент для запуска контейнеров Docker в кластеризованной производственной среде. Однако существуют задачи, которые Kubernetes решить не в состоянии. При частом развертывании в рабочей среде мы нуждаемся в полностью автоматизированном Blue/Green deployment, чтобы избежать простоев в данном процессе, при котором также необходимо обрабатывать внешние HTTP-запросы и выполнять выгрузку SSL. Это требует интеграции с балансировщиком нагрузки, таким как ha-proxy. Другой задачей является полуавтоматическое масштабирование самого кластера Kubernetes при работе в облачной среде, например, частичное уменьшение масштаба кластера в ночное время.

Хотя Kubernetes не обладает этими функциями прямо «из коробки», он предоставляет API, которым можно воспользоваться для решения подобных задач. Инструменты для автоматизированного Blue/Green развертывания и масштабирования кластера Kubernetes были разработаны в рамках проекта Cloud RTI, который создавался на основе open-source.

В этой статье, расшифровке видео, рассказывается, как настроить Kubernetes вместе с другими компонентами с открытым исходным кодом для получения готовой к производству среды, которая без простоев в продакшене воспринимает код из коммита изменений git commit.

Всего голосов 14: ↑14 и ↓0+14
Комментарии0

DEVOXX UK. Kubernetes в продакшене: Blue/Green deployment, автомасштабирование и автоматизация развертывания. Часть 1

Время на прочтение13 мин
Количество просмотров3.8K
Kubernetes — это отличный инструмент для запуска контейнеров Docker в кластеризованной производственной среде. Однако существуют задачи, которые Kubernetes решить не в состоянии. При частом развертывании в рабочей среде мы нуждаемся в полностью автоматизированном Blue/Green deployment, чтобы избежать простоев в данном процессе, при котором также необходимо обрабатывать внешние HTTP-запросы и выполнять выгрузку SSL. Это требует интеграции с балансировщиком нагрузки, таким как ha-proxy. Другой задачей является полуавтоматическое масштабирование самого кластера Kubernetes при работе в облачной среде, например, частичное уменьшение масштаба кластера в ночное время.

Хотя Kubernetes не обладает этими функциями прямо «из коробки», он предоставляет API, которым можно воспользоваться для решения подобных задач. Инструменты для автоматизированного Blue/Green развертывания и масштабирования кластера Kubernetes были разработаны в рамках проекта Cloud RTI, который создавался на основе open-source.

В этой статье, расшифровке видео, рассказывается, как настроить Kubernetes вместе с другими компонентами с открытым исходным кодом для получения готовой к производству среды, которая без простоев в продакшене воспринимает код из коммита изменений git commit.

Всего голосов 16: ↑16 и ↓0+16
Комментарии6

PuppetConf 2016. Kubernetes для сисадминов. Часть 3

Время на прочтение6 мин
Количество просмотров1.8K
PuppetConf 2016. Kubernetes для сисадминов. Часть 1
PuppetConf 2016. Kubernetes для сисадминов. Часть 2

Мы берем приложение Lobsters и создаем новый образ с новыми требованиями. Сначала вводим команду развертывания $ kubectl apply –f deployments/lobsters.yaml и посылаем приложение в кластер, который должен выполнить обновление rolling update для каждого из имеющихся экземпляров приложения в соответствии с политикой обновлений. Сначала система убеждается в работоспособности каждого экземпляра, а затем уничтожает их в следующем наборе контейнеров.



Посмотрим, как это сработало. Для этого перезагружаем сайт, и теперь отсутствие белых мест сделает нашего маркетолога счастливым.
Всего голосов 10: ↑9 и ↓1+13
Комментарии0

PuppetConf 2016. Kubernetes для сисадминов. Часть 2

Время на прочтение6 мин
Количество просмотров2.6K
PuppetConf 2016. Kubernetes для сисадминов. Часть 1

Установите лимит использования ресурсов. С помощью простой математики можно рассчитать, сколько копий приложения вы сможете запустить – если одной копии нужен 1 ГБ RAM, то имея 10 ГБ памяти, можно запустить 10 копий. За этим не нужно будет следить, потому что я знаю, что ядро системы просто станет исполнять обусловленный контракт. Этот контракт, или соглашение между вами и системой, очень важен, потому что при его наличии все инструменты работают намного лучше. Таким образом мы привносим в систему дисциплину исполнения.



Так вот, планировщик запустит это только в том случае, если на каждую из реплик достанется по 1 Гб свободной памяти. Если же памяти не хватает, процесс не запустится. Итак, я ввожу команду kubectl create, и после ее выполнения будет создан контейнер mysql.



Здесь имеется один нюанс, связанный со stateful-системами – у вас есть несколько вариантов выбора. Я выделил фрагмент кода, в котором указал, что хочу использовать PersistentDisk моего облачного провайдера.
Всего голосов 11: ↑10 и ↓1+16
Комментарии1

PuppetConf 2016. Kubernetes для сисадминов. Часть 1

Время на прочтение13 мин
Количество просмотров6.4K
Я системный администратор, занимаюсь компьютерами, и сегодня мы поговорим о Kubernetes. Я постараюсь глубже окунуться в тему, рассмотрев, какие проблемы сисадмин может решить с помощью этого приложения, и также затрону некоторые моменты эксплуатации Puppet, которая вроде как вписалась в этот мир с помощью нового набора абстракций для работы приложения.
Пять или шесть лет назад Луис Андре Барросо и Урс Хёзл в статье «Дата-центр как компьютер» высказали мысль, что мы должны воспринимать центр обработки данных как один массивный компьютер. Нужно абстрагироваться от того, что дата-центр состоит из отдельных машин, и считать его одной логической сущностью. Как только вы попытаетесь использовать эту идею на практике, то сможете применять к дата-центрам принципы построения распределенных систем и распределенных вычислений.



Для того, чтобы относиться к центру обработки данных как к компьютеру, вам нужна операционная система. Она выглядит очень похожей на ту, которую вы используете на отдельном компьютере, но должна иметь другой интерфейс, потому что вам не нужен доступ к отдельной машине и не нужен доступ к ядру. Итак, давайте думать о дата-центре как о большом компьютере. Сегодня я расскажу, как вам поступать, если вас будто бы лишат способности управлять любой машиной с помощью SSH. Вы не сможете залогиниться, и хотя некоторые люди считают, что без этого невозможно управлять системой, я расскажу, как много можно сделать при помощи Kubernetes. Во-первых, вы должны воспринимать Kubernetes как фреймворк для строительства распределенных платформ.
Всего голосов 14: ↑14 и ↓0+14
Комментарии0

Лучшие практики Kubernetes. Обновление кластера Kubernetes с нулевым временем простоя

Время на прочтение5 мин
Количество просмотров4.2K
Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness
Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов
Лучшие практики Kubernetes. Корректное отключение Terminate
Лучшие практики Kubernetes. Маппинг внешних сервисов

Все знают, насколько хорошо поддерживать ваши приложения в актуальном состоянии. Kubernetes и Docker могут сделать процесс обновления намного проще, так что вы сможете создать новый контейнер с обновленными зависимостями и легко его развернуть. Кроме обновления зависимости приложений, Kubernetes постоянно выполняет обновление функций и политик безопасности.
Таким образом, базовые узлы и инфраструктура Kubernetes должны находится в актуальном состоянии. В этой серии мы узнаем, как Google Kubernetes Engine может без проблем обновить кластер Kubernetes.
Всего голосов 10: ↑9 и ↓1+15
Комментарии0

Лучшие практики Kubernetes. Маппинг внешних сервисов

Время на прочтение4 мин
Количество просмотров5K
Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness
Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов
Лучшие практики Kubernetes. Корректное отключение Terminate

Если вы похожи на большинство людей, то, скорее всего используете ресурсы, функционирующие за пределами вашего кластера. Возможно, вы используете API Taleo для отправки текстовых сообщений или анализируете изображения с помощью API Google Cloud Vision.
Всего голосов 16: ↑16 и ↓0+16
Комментарии1

Лучшие практики Kubernetes. Корректное отключение Terminate

Время на прочтение4 мин
Количество просмотров5.4K
Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness
Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов



Важным моментом в работе распределенных систем является обработка сбоев. Kubernetes помогает в этом, используя контроллеры, которые следят за состоянием вашей системы и перезапускают переставшие работать сервисы. Однако Kubernetes может принудительно останавливать работу ваших приложений, чтобы обеспечить общую жизнеспособность системы. В этой серии мы рассмотрим, как можно помочь Kubernetes выполнять свою работу более эффективно и сокращать время простоя приложений.
Всего голосов 10: ↑9 и ↓1+15
Комментарии0

Как стать DevOps инженером за полгода или даже быстрее. Часть 6. Запуск приложения

Время на прочтение6 мин
Количество просмотров9K
Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение
Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование
Как стать DevOps инженером за полгода или даже быстрее. Часть 3. Версии
Как стать DevOps инженером за полгода или даже быстрее. Часть 4. Пакетирование программ
Как стать DevOps инженером за полгода или даже быстрее. Часть 5. Развертывание



На фото вверху изображена скорость традиционного развертывания приложения. И если вы тратили по месяцу на обучение, то сейчас находитесь на 5 этапе дорожной карты:



Готовы к запуску?


Итак, у нас есть наш код, написанный, упакованный и где-нибудь развернутый. Я решил проигнорировать развертывание кода как неизменяемых артефактов машины (например, EC2) и сосредоточиться на контейнерах. Почему?
Читать дальше →
Всего голосов 10: ↑8 и ↓2+11
Комментарии4

Как стать DevOps инженером за полгода или даже быстрее. Часть 5. Развертывание

Время на прочтение6 мин
Количество просмотров11K
Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение
Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование
Как стать DevOps инженером за полгода или даже быстрее. Часть 3. Версии
Как стать DevOps инженером за полгода или даже быстрее. Часть 4. Пакетирование программ



Освежим память


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



Если вы тратили по месяцу на изучение каждого раздела, то сейчас находитесь на 4 месяце. К этому времени вы уже должны знать, как обеспечить инфраструктуру, которая будет работать с вашим программным обеспечением, как правильно управлять версиями программ и как упаковать их для последующего развертывания. В этой статье мы обсудим, как правильно развернуть ваш код!
Читать дальше →
Всего голосов 12: ↑10 и ↓2+15
Комментарии0

Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов

Время на прочтение8 мин
Количество просмотров8.8K
Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness

Для каждого ресурса Kubernetes имеется возможность настраивать два типа требований — Requests и Limits. Первое описывает минимальные требования к наличию свободных ресурсов узла, необходимых для запуска контейнера или пода, второе жестко ограничивает ресурсы, доступные контейнеру.

Когда Kubernetes планирует pod, очень важно, чтобы у контейнеров было достаточно ресурсов для нормальной работы. Если вы планируете развернуть большое приложение на узле с ограниченными ресурсами, вполне возможно, что оно не будет работать по причине того, что у узла заканчивается память или ему не хватает мощности процессора. В этой статье мы рассмотрим, как можно решить проблемы нехватки компьютерных мощностей с помощью запросов на ресурсы и ограничения.

Запросы Requests и ограничения Limits — это механизмы, которые Kubernetes использует для управления такими ресурсами, как, например, процессор и память. Requests — это то, в результате чего контейнер гарантированно получает запрашиваемый ресурс. Если контейнер запрашивает ресурс, то Kubernetes запланирует его только на том узле, который способен его предоставить. Ограничения Limits контролируют, что ресурсы, запрашиваемые контейнером, никогда не превысят определенного значения.

Всего голосов 9: ↑8 и ↓1+12
Комментарии0

Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness

Время на прочтение4 мин
Количество просмотров8K
Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен



Распределенными системами бывает трудно управлять по причине того, что в них имеется множество подвижных изменяемых элементов, и все они должны нормально работать для обеспечения функциональности системы. Если один из элементов выйдет из строя, то система должна его обнаружить, обойти и исправить, причем все это нужно делать автоматически. В этой серии «Kubernetes Best Practices» мы узнаем, как настраивать тесты Readiness и Liveness для проверки жизнеспособности кластера Kubernetes.

Проверка здоровья Health Check — это простой способ позволить системе знать, работает ли экземпляр вашего приложения или нет. Если экземпляр вашего приложения не работает, то другие службы не должны обращаться к нему или отправлять ему запросы. Вместо этого запрос должен быть отправлен другому экземпляру приложения, который уже запущен или запустится позже. Кроме того, система должна вернуть вашему приложению утраченную работоспособность.

По умолчанию Kubernetes начнет отправлять трафик в pod, когда все контейнеры внутри подов будут запущены, и перезагружать контейнеры, когда они аварийно завершат работу. Для начала такое поведение системы по умолчанию может быть достаточно хорошим, однако вы можете повысить надежность развертывания своего продукта, используя пользовательские проверки работоспособности.
Всего голосов 14: ↑10 и ↓4+13
Комментарии3
1
23 ...

Информация

В рейтинге
Не участвует
Откуда
Белиз-Сити, Belize, Белиз
Работает в
Зарегистрирован
Активность