Привет, Хабр.

В этой статье я хочу рассказать о своем опыте создания учебной среды для экспериментов с микросервисами. При изучении каждого нового инструмента мне всегда хотелось его попробовать не только на локальной машине, но и в более реалистичных условиях. Поэтому я решил создать упрощенное микросервисное приложение, которое впоследствии можно будет "обвешивать" всякими интересными технологиями. Основное требование к проекту — его максимальная функциональная приближенность к реальной системе.

Изначально я разбил создание проекта на несколько шагов:

1. Создать два сервиса — 'бекенд' (backend) и 'шлюз' (gateway), упаковать их в docker-образы и настроить их совместную работу

   
   

   Ключевые слова: Java 11, Spring Boot, Docker, image optimization

   
   

2. Разработка Kubernetes конфигурации и деплой системы в Google Kubernetes Engine

   
   

   Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets

   
   

3. Создание чарта с помощью Helm 3 для более эффективного управления кластером

   
   

   Ключевые слова: Helm 3, chart deployment

   
   

4. Настройка Jenkins и пайплайна для автоматической доставки кода в кластер

   
   

   Ключевые слова: Jenkins configuration, plugins, separate configs repository

   
   

Каждому шагу я планирую посвятить отдельную статью.

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

Создание умного дома подразумевает массу разных датчиков, контролирующих обстановку в доме — датчики движения, освещения, температурные и прочие. Если «умный дом» небольшой, то все выглядит просто даже с самодельными системами на базе открытых решений (MQTT, OpenHAB и т.д.) — подключили датчик, прописали его в программе OpenHAB или HomeAssistant и начали работать. Но если датчиков много, то появляется много рутинной и неблагодарной работы по прописыванию каждого из них в системе управления.

Предлагаемое решение («костыль») позволяет обойтись минимум ручных операций именно на этом этапе. Контроллер датчиков подключается к MQTT-брокеру и сам рассказывает про свои датчики и устройства в определенном формате в специальных топиках, затем небольшой скрипт на сервере умного дома создает соответствующие этим датчикам файлы конфигурации, после чего нужно только вручную определить их в специфичные для дома группы и можно приступать к созданию сценариев управления.

Конкретно эта прошивка работает на модулях с ESP-8266 (в том числе и на Sonoff Basic Switch и Sonoff Touch Wallswitch) с P&P скриптами для OpenHAB и HomeAssistant, но сам способ выдачи plug&play информации можно использовать и в других проектах.

Совсем недавно на Хабре мелькнула статья коллеги, который описал довольно интересный подход к совмещению Generics и возможностей Spring. Мне она напомнила один подход, который я использую для написания микросервисов, и именно им я решил поделиться с читателями.



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

31 июля организация CNCF объявила о принятии в свою «песочницу» (т.е. на самый ранний этап поддержки) нового Open Source-проекта, охарактеризованного как «облачный (cloud native) реестр», — Harbor. На его сайте нам объясняют, что продукт создан для управления образами Docker-контейнеров в безопасном окружении.



Казалось бы, уже есть Docker Registry  (или, скажем, Quay от CoreOS), но очевидно, что новые решения не появляются и не дозревают до применения в production просто так — тем более, Open Source-решения… и уж тем более, попадающие в CNCF. Эта обзорная статья призвана пролить свет на причины появления Harbor, его ключевые возможности и особенности.

Доброго времени суток с вами компания 3Dtool! Часто возникают ситуации, когда необходимо напечатать геометрически сложную деталь на 3D принтере с одним экструдером например Hercules Strong, которую как не крути, а без поддержек не напечатать. Вариант – порезать на части и склеить в контексте этого поста рассматривать не будем.

У одного из наших заказчиков возникли сложности в подготовке, печати и постобработке детали (см. ниже). Сверху на картинке –лицевая сторона, внутренняя сторона (вторая картинка) печатается с поддержками.



Сложность 3D печати заключается в том, что поддержки с черновой стороны детали удалить практически невозможно, они либо удаляются с кусками детали, либо первые слои детали провисают над поддержками и печатаются не ровно.

Автор этого поста увидел первую 3D-модель, распечатанную на принтере, около 10 лет назад. Шло собрание в огромном российском рекламном агентстве, которое использовало возможности 3D-печати для того, чтобы печатать демонстрации очень дорогой сувенирки — её предстояло сделать из меди, бронзы, серебра и совсем мелкие штучки из золота. Мы с коммерческим директором тогдашней компании крутили в руках будущие статуэтки и значки из буро-серо-синего пластика, с неаккуратными заусенцами, «провалами» и т.д. Нам это казалось восьмым чудом света — и, когда нам отдали макеты насовсем, мы радовались как дети и уже в машине шутили, что круто было бы печатать на принтере блинчики, пирожные и колбасу. Никогда мы ещё не были так близки к предсказанию будущего.


Когда хозяин купил 3D-принтер, а ты понял, как выглядит безысходность

Действующие лица (Команда): разработчиков – 2 человека, админ – 1 человек.

Статья повествует об использовании таких технологий, как Ansible, Docker Swarm, Jenkins и Portainer для реализации CI/CD-пайплайна с возможностью контроля за ним с помощью красивого веб-интерфейса.

Вступление

Чего обычно хочет разработчик? Он хочет творить, не думая о деньгах, и максимально быстро видеть результаты собственного творчества.

С другой стороны, есть бизнес, который хочет денег, да побольше, и поэтому постоянно думает о снижении времени вывода продукта на рынок. Другими словами, бизнес мечтает об ускорении получения MVP (a.k.a. Minimum Viable Product) в новых продуктах или при обновлении существующих.

Ну а чего же хочет админ? А админ – человек простой, он хочет, чтобы сервис не падал и не мешал играть в Кваку Танки и чтобы его пореже дергали разработчики и бизнес.
Поскольку для реализации желаний админа, как показывает правда жизни, его силами должны реализоваться и мечты других героев, представители ИТ-тусовки много работали над этим. Часто получалось достичь желаемого, придерживаясь методологии DevOps и реализуя принципы CI/CD (Continuous Integration and Delivery).

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

Service Workes как технология для создания offline приложений очень хорошо подходит для кэширования различных ресурсов. Разнообразные тактики работы в сервис воркере с локальным кэшем подробно описаны в Интернете.

Не описано одного — каким образом обновлять файлы в кэше. Единственное, что предлагает Google и MDN, это делать несколько кэшей для разных типов ресурсов, и, когда нужно, изменять в скрипте сервис воркера sw.js версию этого кэша, после чего тот весь удалится.

В данный момент инсталяция по данному мануалу работать не будет. Из за больших изменений API Kubemaster, в данный момент я готовлю новый цикл статей где будут рабочие версии мануалов
Первая из статей habr.com/ru/post/462473

Здравствуйте!

В данной публикации я хотел бы рассказать о кластере Kubernetes с высокой доступностью (HA).



Оглавление:

1. Вступление
2. Список используемого софта
3. Список и назначение хостов
4. Принцип работы и развертывания
5. Подготовка ОС к развертыванию. Установка docker, kubeadm, kubelet и kubectl
6. Подготовка конфигурационного скрипта
7. Создание etcd кластера
8. Инициализация мастера с помощью kubeadm
9. Настройка CIDR
10. Инициализация остальных мастернод
11. Настройка keepalived и виртуального IP
12. Добавление рабочих нод в кластер
13. Установка ingress-nginx
14. Дополнительно
    
    • Dashboard
    • Heapster
    
    

Прим. перев.: Автор статьи — Amanpreet Singh — называет себя «всё ещё начинающим в мире сетей», однако именно это и побудило его разобраться в их базовом устройстве в Kubernetes (который он использует в production), а затем — поделиться с сообществом очень доступным материалом с наглядными иллюстрациями. В оригинале он разбит на две части, однако в этом переводе мы объединили их в одну статью.



Вот вы запустили множество сервисов в кластере Kubernetes и пожинаете плоды… или хотя бы собираетесь это сделать. Однако, даже несмотря на существование ряда утилит для настройки кластера и управления им, вам всё же интересно, как всё работает «под капотом». Куда смотреть, если что-то сломается? По себе знаю, что это важно.

Иногда бывает необходимость написать небольшой АПИ сервис, часто в виде прототипа. И часто этот прототип потом так и остаётся в первоначально написанном виде следуя принципу «работает — не трогай». Переписывание даже относительно маленького сервиса сопряжено с возможностью внесения ошибки или случайного незначительно изменения поведения, которое обнаружится далеко не сразу. На помощь тут приходит тестирование по методу черного ящика (функциональное тестирование). Написание тестов является важной частью процесса разработки, а время потраченное на написание тестов может быть гораздо больше, чем реализация тестируемого функционала. Предлагаю рассмотреть метод тестирования, когда тестируемый код (сервис) и авто тесты написаны на разных языках программирование. Данный подход позволяет писать тесты без зависимости от первоначально выбранной технологии, что позволяет достаточно легко «выкинуть» прототип и переписать требуемый функционал на других технологиях. Плюс это демонстрация того, что тесты не обязательно должны быть написаны на том же языке, что и тестируемый сервис.

Оригинал

Версия документа: 20171105 — 05 November 2017
Версия продукта: 3.0.9.RELEASE

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

Сеть подов в кластере – аккуратный материал, но сам по себе он недостаточен для создания долгосрочных систем, поскольку поды в Kubernetes эфемерны. В качестве конечной точки можно использовать IP-адрес пода, но нет гарантии, что при следующем воссоздании пода адрес останется прежним. Его смена может произойти по любой причине.

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

Как появился CoreDNS, для чего он предназначен и как его можно использовать?

Привет, хабрапользователь! Сегодня я попробую представить тебе очередную статью о докере. Зачем я это делаю, если таких статей уже множество? Ответов здесь несколько. Во-первых не все они описывают то, что мне самому бы очень пригодилось в самом начале моего пути изучения докера. Во-вторых хотелось бы дать людям к теории немного практики прямо по этой теории. Одна из немаловажных причин — уложить весь накопленный за этот недолгий период изучения докера опыт (я работаю с ним чуть более полугода) в какой-то сформированный формат, до конца разложив для себя все по-полочкам. Ну и в конце-концов излить душу, описывая некоторые грабли на которые я уже наступил (дать советы о них) и вилы, решение которых в докере просто не предусмотрено из коробки и о проблемах которых стоило бы задуматься на этапе когда вас распирает от острого желания перевести весь мир вокруг себя в контейнеры до осознавания что не для всех вещей эта технология годна.

Что мы будем рассматривать в данной статье?

В Части 0 (теоретической) я расскажу вам о контейнерах, что это и с чем едят
В Частях 1-5 будет теория и практическое задание, где мы напишем микросервис на python, работающий с очередью rabbitmq.
В Части 6 — послесловие

Проблема 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).

Даниил Подольский (Git in Sky)

Доклад мой называется «Бинарные, они же файловые, хранилища», но, на самом деле, мы имеем дело со страшной сказкой. Проблема в том (и это тезис моего доклада), что сейчас не существует не то что хорошей, а хотя бы приемлемой системы хранения файлов.

Что такое файл? Файл – это кусок данных с именем. Что важно? Почему файл – это не строка в базе данных?

Файл слишком большой, чтоб можно было обращаться с ним как с одним куском. Почему? Есть у вас сервис, раз у нас HighLoad конференция, у вас сервис, который держит одновременно 100 тыс. соединений. Это не так уж много, если по каждому из соединений мы отдаем файл в 1 Мбайт размером, но нам нужно примерно 100 Гбайт памяти для буферов под эти файлы.

Даниил Подольский (Git in Sky)

Рассказ о том, что каждый инженер должен сделать в своей жизни после того, как он родил ребенка, посадил дерево и построил дом – это сделать свое файловое хранилище.

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

Облачные файловые хранилища продолжают набирать популярность, и требования к ним продолжают расти. Современные системы уже не в состоянии полностью удовлетворить все эти требования без значительных затрат ресурсов на поддержку и масштабирование этих систем. Под системой я подразумеваю кластер с тем или иным уровнем доступа к данным. Для пользователя важна надежность хранения и высокая доступность, чтобы файлы можно было всегда легко и быстро получить, а риск потери данных стремился к нулю. В свою очередь для поставщиков и администраторов таких хранилищ важна простота поддержки, масштабируемость и низкая стоимость аппаратных и программных компонентов.

Знакомьтесь: Ceph

Ceph — это программно определяемая распределенная файловая система с открытым исходным кодом, лишенная узких мест и единых точек отказа, которая представляет из себя легко масштабируемый до петабайтных размеров кластер узлов, выполняющих различные функции, обеспечивая хранение и репликацию данных, а также распределение нагрузки, что гарантирует высокую доступность и надежность. Система бесплатная, хотя разработчики могут предоставить платную поддержку. Никакого специального оборудования не требуется.



При выходе любого диска, узла или группы узлов из строя Ceph не только обеспечит сохранность данных, но и сам восстановит утраченные копии на других узлах до тех пор, пока вышедшие из строя узлы или диски не заменят на рабочие. При этом ребилд происходит без секунды простоя и прозрачно для клиентов.

Уже довольно много написано статей, по установке и запуску Kubernetes, однако, не всё так гладко (я потратил несколько суток на запуск своего кластера).

Данная статья призвана дать исчерпывающую информацию не только по установке k8s, но и объяснить каждый шаг: зачем и почему мы делаем именно так, как написано (это очень важно для успешного запуска).

Что нужно знать

Серверы:
Кластер подразумевает, что у Вас более одного физического сервера, между которыми и будут распределятся ресурсы. Серверы называются нодами (nodes).

Диски:
Обычные харды в k8s не поддерживаются. Работа с дисками происходит по средствам распределенных файловых хранилищ. Это необходимо для того, чтобы k8s мог «перемещать» контейнеры docker на другие ноды в случае необходимости, без потери данных (файлов).

Начинать создание кластера нужно именно с создания своего распределенного файлового хранилища. Если вы уверены, что диски вам никогда не понадобятся, то этот шаг можно пропустить.
Я выбрал Ceph. А еще рекомендую почитать эту замечательную статью.

Минимальное разумное количество серверов для Ceph — 3 (можно построить и на одном, но в этом мало смысла из-за высокой вероятности потерять данные).

Сеть:
Нам понадобится Flannel — он позволяет организовать программно определяемую сеть (Software Defined Network, SDN). Именно SDN позволяет всем нашим контейнерам общаться с друг другом внутри кластера (установка Flannel производится вместе с k8s и описана ниже).

Подготовка серверов

В нашем примере мы используем 3 физических сервера. Установите Ubuntu 16.04 на все сервера. Не создавайте swap партиции (требование k8s).

Предусмотрите в каждом сервере как минимум один диск (или партицию) для Ceph.

Не включайте поддержку SELinux (в Ubuntu 16.04 он выключен по-умолчанию).

Мы назвали сервера так: kub01 kub02 kub03. Партиция sda2 на каждом сервере создана для Ceph (форматировать не обязательно).