Создаем самодостаточный Docker-кластер

Автор: admin от 11-08-2017, 23:30, посмотрело: 561

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



Как выглядит самодостаточная система? Какие ее основные части? Кто действующие лица? В этой статье мы обсудим только сервисы и проигнорируем тот факт, что железо также очень важно. Такими ограничениями мы составим картину высокого уровня, которая описывает (в основном) автономную систему с точки зрения сервисов. Мы опустим детали и взглянем на систему с высоты птичьего полёта.



Если вы хорошо разбираетесь в теме и хотите сразу всё понять, то система изображено на рисунке ниже.



Создаем самодостаточный Docker-кластер

->

Категория: Системное администрирование / Сетевые технологии

 

TDD React.js приложений

Автор: admin от 7-08-2017, 08:00, посмотрело: 379

TDD React.js приложений

Hetzel edition of 20000 Lieues Sous les Mers





Заметка о том, насколько мы “реаниматоры” по части тестов (кто знаком с творчеством Говарда Филлипса Лавкрафта, тот поймет).



В продолжение темы тестирования и тестов, хотелось бы немного написать о нашем подходе, как он выглядит на наших Single Page Applications (SPA), написанных на React.js, как нам помогал в этом Test-Driven Development (TDD) и почему мы пришли к тому, что редукторы и API-сервисы покрывать тестами тоже нужно.



Сразу скажу, что если вы ожидаете тут увидеть jest, snapshot testing или storyshots, то сразу закрывайте эту заметку. Если вы ожидаете найти тут что-то из свежих библиотек или подходов, то тоже немедленно закрывайте. Ничего из названного мы не использовали. Возможно, в новый проект мы войдем с этими инструментами, а пока получилось так, как получилось.



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


->

Категория: Веб-разработка / Game Development

 

Олег Ненашев, Кирилл Толкачёв и Александр Тарасов про Groovy DSL и Pipeline в Jenkins на jug.msk.ru

Автор: admin от 2-08-2017, 08:45, посмотрело: 315

27 июля 2017 года прошла совместная встреча сообществ jug.msk.ru и Jenkins MSK. На встрече с докладами о Jenkins выступили Олег Ненашев («Groovy DSL в Jenkins и Pipeline. Как оно работает?») и Кирилл Толкачёв с Александром Тарасовым («DSL много не бывает. Мигрируем со Scripted Pipeline на Declarative (Live)»).



Олег Ненашев, Кирилл Толкачёв и Александр Тарасов про Groovy DSL и Pipeline в Jenkins на jug.msk.ru
->

Категория: Программирование / Веб-разработка

 

Релизный цикл для Infrastructure as Code

Автор: admin от 23-07-2017, 10:15, посмотрело: 359

На просторах интернета можно встретить немало статей на тему Infrastructure as Code, утилит SaltStack, Kitchen-CI и так далее, однако, сколько я не встречал различного рода примеров IaC, они зачастую остаются только кодом, как правило, с делением на бранчи в VCS соответствующие наименованию типа среды, например dev/int, возможно даже с тэгами, а говорить о полноценном цикле разработки конфигураций как правило не приходится. Во всяком случае с компаниями, с которыми знаком именно такая ситуация, да и статей не находил.
Может быть оно и понятно — тотальный Agile и "раз-раз и в продакшен".
Попробую исправить ситуацию данной статьей.

Категория: Операционные системы / Linux

 

Трудные уроки: пять лет с Node.js

Автор: admin от 21-04-2017, 12:45, посмотрело: 486

После пяти лет работы с Node.js я многое понял. Я уже делился некоторыми историями, но в этот раз хочу рассказать о том, какие знания дались труднее всего. Баги, проблемы, сюрпризы и уроки, которые вы можете использовать в собственных проектах!

Базовые концепции


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

Классы


Когда я только начал работать с Node.js, то написал скрапер. Очень быстро я понял, что если ничего не предпринять, то он будет осуществлять много запросов параллельно. Одно это стало важным открытием. Но поскольку я ещё не полностью усвоил мощь экосистемы, то сел и написал собственный ограничитель параллелизма. Он работал и проверял, что в каждый момент времени активны не более N запросов одновременно.

Категория: Программирование / Веб-разработка

 

Версионирование артефактов сборки в Gradle используя git имена тегов, бранчей и коммитов

Автор: admin от 13-02-2017, 13:05, посмотрело: 539

С переездом из SVN на GIT и gitlab (плюс переезд из Jenkins на Gitlab-CI, но его использование также упомянём), встал вопрос версионирования получаемых артефактов сборки приложения.

В SVN был всем привычный номер ревизии, монотонно увеличивающийся с каждым коммитом. Его было удобно добавлять в номер версии, и это решало большинство проблем. Но git конечно предоставляет множество плюшек, и стоило убеждать руководство и всё команду перевести проект на него…
Зато пришлось отстроить заново процесс версионирования получаемых артефактов сборки.

В итоге остановились на очень хорошем Gradle плагине github.com/nemerosa/versioning, о его использовании я и собираюсь рассказать.

Категория: Программирование

 

Установка Jenkins и Bonobo Git Server под ОС Windows для сборки Android приложений

Автор: admin от 26-10-2016, 09:55, посмотрело: 833

Добрый день. Не имея времени копаться в LinuxСтолкнувшись с пробелами в информации при поиске по сети инструкций по установке и настройке под ОС Windows сервера непрерывной сборки Jenkins для приложений Android, Git сервера и их интеграции решил поделиться информацией о том, что у меня получилось.

Категория: Веб-разработка / Game Development / Android

 

OpenShift + Jenkins + Bitbucket, непрерывная интеграция и публикация из коробки

Автор: admin от 20-10-2016, 11:05, посмотрело: 494

OpenShift + Jenkins + Bitbucket, непрерывная интеграция и публикация из коробки
В этой статье я покажу, как быстро развернуть среду для сборки, тестирования и публикации приложений используя платформу OpenShift на примере PHP проекта. Использовать буду OpenShift online, но всё это же можно развернуть и на собственных серверах или в VirtualBox (есть готовая сборка). Git-сервером для хранения и версионирования кода будет Bitbucket.

Категория: Программирование / Веб-разработка

 

Получаем управление обратно в Jenkins Pipeline

Автор: admin от 7-09-2016, 18:35, посмотрело: 603

Jenkins Pipeline Plugin очень удобная штука, чтобы организовать у себя непрерывную доставку ПО (Continuous Delivery). Плагин даёт возможность разбить доставку ПО до конечного потребителя на стадии (stage), каждой из которых можно управлять (на каком узле, что и как нужно сделать) и, в конечном счёте, визуализировать процесс доставки. Вкупе с Blueocean plugin всё это выглядит очень вкусно. В реальной же жизни подчас оказывается так, что кроме Jenkins-а есть ещё и другие системы, которые участвуют в этом процессе (workflow), и встаёт вопрос — как их интегрировать с имеющимися решениями. Примером тут может служить Jira, в которой есть некий issue падающий на тестировщика, прокликивающего интерфейс (ну или совершающего другую полезную работу), и только после его благословения, наш артефакт имеет право двигаться дальше в сторону ожидающего его клиента.


Так какие у нас есть варианты реализации?

Хочу узнать

Категория: Программирование

 

Борьба с загадочными падениями MSBuild на XamlTaskFactory

Автор: admin от 4-08-2016, 15:10, посмотрело: 431

Наша команда разрабатывает кроссплатформенное ядро приложений, которое должно собираться на Windows под Visual Studio 2015, Linux с gcc 4.9+, MacOS, iOS, Android и Windows Phone 8.1+. Для автоматической проверки кода на Jenkins настроены сборки под все требуемые конфигурации. Задача сборок отловить код, который не собирается на одной или нескольких из платформ или не проходит юнит-тесты и не дать ему попасть к командам конечных приложений до внесения соответствующих исправлений. Такой процесс CI позволяет разработчику локально использовать удобную ему операционную систему и среду разработки, будь то Visual Studio, XCode, QtCreator или вообще vim + ninja, при этом не бояться, что его изменения не соберутся или будут валить тесты в другом окружении.

В идеальном мире красная сборка на Jenkins (именно он у нас используется в роли билдсервера) говорит о проблеме в коде. Увидев красный свет на висящем в углу комнаты мониторе, «дежурный за сборку» должен пойти и поправить найденную проблему. В реальности же причины падения билда могут быть самыми разными, например, обрыв соединения с нодой, на которой проходила компиляция, закончившееся место на диске или прилёт инопланетян. Такие ложные срабатывания отнимают лишнее время у команды, притупляют внимание и в целом снижают доверие к CI в команде. Историю борьбы с одной из таких проблем я хочу рассказать.

Категория: Веб-разработка / Windows

 
Назад Вперед