Об авторе: Хэм Фокке — разработчик и консультант ThoughtWorks в Германии. Устав от деплоя в три ночи, он добавил в свой инструментарий средства непрерывной доставки и тщательной автоматизации. Сейчас налаживает такие системы другим командам для обеспечения надёжной и эффективной поставки программного обеспечения. Так он экономит компаниям время, которое эти надоедливые людишки тратили на свои выходки.

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

В последнее время Kubernetes пользуется большой популярностью, и разработчики ищут дополнительные способы и методы для развёртывания приложений в кластере этой системы. Даже командная строка kubectl стала восприниматься как инструмент низкого уровня, при этом пользователи продолжают искать ещё более простые способы взаимодействия с кластером. Draft, Gitkube, Helm, Ksonnet, Metaparticle и Skaffold — вот лишь некоторые инструменты, помогающие разработчикам создавать и разворачивать приложения в Kubernetes.

Draft, Gitkube и Skaffold упрощают разработку приложений, позволяя разработчикам как можно быстрее запускать их в кластере Kubernetes. Helm и Ksonnet помогают в процессе развёртывания, т.к. могут определять готовность приложения к отправке, а также управлять выпуском новых версий, обработки различных кластеров и т. д. Metaparticle — необычный инструмент, который позволяет вам в рамках собственного кода работать с любыми форматами (YAML, dockerfile).

Итак, что же использовать в конкретной ситуации?

Давайте посмотрим.

В данный момент инсталяция по данному мануалу работать не будет. Из за больших изменений 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
    
    

Предыстория

20-го декабря прошлого года я ушёл в отпуск, на целых 2 недели. Чем заняться в отпуске? Правильно, — кодом. Кодом, которым некогда заниматься в рабочее время. Последние несколько лет мне кодить приходилось очень мало. Руки стосковались. Какой код пишут в отпуске? Не знаю как вы, а я пишу велосипеды. Зачем? Причин может быть много, но основная, — мне интересно. Я люблю C++ и Lua. Я ещё и bash и awk люблю. Не закидывайте камнями, это личное, так получилось. JavaScript я не очень люблю (хотя последние 2 года если что-то и кодил то на JS), и это тоже личное.

Netflix уменьшил время аварийного переключения с 45 до 7 минут без каких-либо затрат

Изображение: Florida Memory. Доработано Opensource.com. CC BY-SA 4.0

Зимой 2012 года Netflix пережил длительный сбой, уйдя в отключку на семь часов из-за проблем с сервисом AWS Elastic Load Balancer в регионе US-East (Netflix работает на AWS — у нас нет собственных дата-центров. Всё ваше взаимодействие с Netflix происходит через AWS, кроме самого потокового видео. Как только вы нажмете Play, начинает загружаться видеопоток из нашей собственной сети CDN). Во время сбоя ни один пакет из региона US-East не доходил до наших серверов.

Чтобы такого больше не повторилось, мы решили создать систему аварийного переключения, устойчивую к сбоям базовых поставщиков услуг. Аварийное переключение (failover) — это система обеспечения отказоустойчивости, когда в случае сбоя основной системы автоматически активируется резервное оборудование.

В данной статье хотелось бы рассказать про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений на платформах InterSystems.

Рассмотрим такие темы как:

• Git 101
• Методологии разработки (Git flow)
  
  • GitHub flow
  • GitLab flow
• GitLab
• GitLab CI

Привет, Хабр! Надеемся в обозримом будущем и до Kotlin добраться. Мимо этой статьи (февральская) пройти не смогли.

Читаем и комментируем!

У Go есть некоторые замечательные свойства, которым посвящён раздел «Хороший». Но когда речь заходит о применении этого языка не для создания API или сетевых серверов (для чего он и был разработан), а для реализации бизнес-логики, то я считаю Gо слишком неуклюжим и неудобным. Хотя даже в рамках сетевого программирования найдётся немало подводных камней как в архитектуре языка, так и в реализации, что делает Go опасным, несмотря на его кажущуюся простоту.

В конце прошлого года компания Red Hat опубликовала доклад с описанием принципов, которым должны соответствовать контейнеризированные приложения, стремящиеся к тому, чтобы стать органичной частью «облачного» мира: «Следование этим принципам обеспечит готовность приложений к автоматизируемости на таких платформах для облачных приложений, как Kubernetes», — считают в Red Hat. И мы, изучив этот документ, с их выводами согласны, а посему решили поделиться ими с русскоязычным ИТ-сообществом.



Обратите внимание, что эта статья является не дословным переводом оригинального документа (PDF), подготовленного Bilgin Ibryam — архитектором из Red Hat, активным участником нескольких проектов Apache и автором книг «Camel Design Patterns» и «Kubernetes Patterns», — а представляет основные его тезисы в довольно свободном изложении.

Барух Садогурский рассказывает, как с помощью сервиса голосовых команд Alexa можно добавить голосовой интерфейс к совершенно неожиданным вещам, таким как IntelliJ IDEA и Jenkins, а также, откинувшись в кресле с бокалом любимого напитка, управлять всем, чем угодно.


В основе статьи – выступление Баруха на конференции JPoint 2017 в Москве.

«Это эссенция тридцатилетнего опыты разработки программного обеспечения.»

Приветствую, Хабр.

Хочу представить лучшую (единственную) книгу по построению сообществ, написанную тру ИТишником.

Для себя я нашел применимые инструменты для анализа сообщества/организованности «на лету»(я и еще более 100 человек провели «аудит» Хабра), а так же подсказки, какой "генотип" закладывать при разработке нового продукта/брэнда/движухи. Читайте, сохраняйте, расшаривайте и пишите свой отзыв.

Об авторе

«К сожалению, мы не выбираем себе смерть, но мы можем встретить ее достойно, чтобы нас запомнили, как мужчин.»
— к/ф «Гладиатор»



Питер Хинченс (Pieter Hintjens) — бельгийский разработчик, писатель. Занимал должность CEO и chief software designer в iMatix, компании, производящей free software, такие как библиотека ZeroMQ (библиотека берет на себя часть забот о буферизации данных, обслуживанию очередей, установлению и восстановлению соединений и прочие), OpenAMQ, Libero, GSL code generator, и веб-сервиса Xitami.

• Автор более 30 протоколов и распределенных систем.
• Основатель проекта Edgenet по созданию полностью безопасной, анонимной глобальной P2P-сети.
• Президент ассоциации Foundation for a Free Information Infrastructure (FFII), которая воевала с патентным правом.
• CEO сервиса по созданию собственных вики-проектов Wikidot.
• Он был активистом open standards и основателем Digital Standards Organization.
• Питер в 2007-м был назван одним из 50 самых влиятельных людей в области «Интеллектуальная собственность».

С 2008 года Google ведет проект Oxygen — исследование успешности своих руководителей. В 2018 году работу руководителей оценивали по внутреннему рейтингу и отзывам сотрудников. Оказалось, что команды с хорошими руководителями работают продуктивнее и чувствуют себя счастливыми. Google провели масштабный опрос сотрудников и выяснили, какие 10 качеств отличают сильного руководителя:

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

Как Азимов умудрялся выдавать столько хороших идей, в то время как у всех остальных их наберётся 1-2 штуки за всю жизнь? Чтобы ответить на этот вопрос, я изучил его автобиографию, "Это была хорошая жизнь".

Азимов не с рождения писал тексты 8 часов в день 7 дней в неделю. Он разрывал страницы, отчаивался, и периодически у него случались неудачи. В автобиографии Азимов делится тактикой и стратегией, выработанной им для того, чтобы идеи больше не заканчивались.

Давайте украдём у него всё, что можно.

Здравствуйте, уважаемые хабравчане! Сегодня я хотел бы рассказать о том, как «скормить» Java-приложение докеру, как при этом лучше действовать, а чего делать не стоит. Я занимаюсь разработкой на Java более 10 лет, и последние года три провёл в самом тесном общении с Docker, так что у меня сложилось определённое представление о том, что он может и чего не может. Но ведь гипотезы надо проверять на практике, не так ли?

Я представил весь процесс как старую добрую компьютерную игру с тёплым ламповым пиксель-артом.

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

На сайте докера можно ознакомиться с рядом рекламных посулов – а именно, с обещанием увеличить скорость разработки и развертывания аж в 13 раз и повысить портативность в разработке (в частности, избавиться о сакраментального «работает на моей машине»). Но соответствует ли это реальности?

Сейчас мы попробуем доказать/опровергнуть эти утверждения.

Disclaimer: Статья Мартина Фаулера была опубликована в 2003 году

в журнале IEEE Software. В сети (но не на Хабре) есть замечательный перевод пятилетней давности от Сергея Теплякова (SergeyT).

Недавно я встретил в коридоре явно раздраженного коллегу, Дэйва Райса (Dave Rice). Мой вводный вопрос вызвал резкое заявление: «Нам надо игнорировать любого кандидата, имеющего пункт «Архитектор» в резюме». Смущало в этой странной фразе то, что мы же сами, обычно, представляем Дейва как одного из наших ведущих архитекторов.

Причиной его «титульного психоза» являлся тот факт, что по меркам даже нашей индустрии, смысл слов «архитектор» и «архитектура» чрезвычайно переоценен. Многим кажется, что к термину «архитектор программного обеспечения» отлично подходит тот самодовольный и все контролирующий образ из финальных сцен «Матрица: Перезагрузка». Но даже в компаниях относящихся с большим презрением к такому отображению, все равно, существует жизненно важная роль технического лидера, в сущности – архитектора, такого, как сам Дейв.

Этим летом я прочитал книгу Илона Маска Tesla, SpaceX, and the Quest for a Fantastic Future. Замечательное чтиво и подробный рассказа о взлётах и падениях одного из крупнейших визионеров нашего времени. Также книга позволила ознакомиться с рабочей этикой Маска и секретами продуктивности, которыми он пользуется для управления несколькими компаниями.

Этот список появился как личная памятка по темам, которые я обсуждал с коллегами и друзьями и в которых хотел разобраться поглубже…

Я не большой любитель задавать технические вопросы на собеседованиях: по мне так лучше посидеть с кандидатом (или кандидаткой) за клавиатурой над каким-то реальным кодом, реальной проблемой — и целый день заниматься парным программированием, желательно поочерёдно с остальными членами команды. Но я считаю, что некоторые технические вопросы могут быть хорошей отправной точкой для начала увлекательного и приятного разговора и позволят глубже узнать друг друга.

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

Около месяца назад Google сервис Colaboratory, предоставляющий доступ к Jupyter ноутбукам, включил возможность бесплатно использовать GPU Tesla K80 с 13 Гб видеопамяти на борту. Если до сих пор единственным препятствием для погружения в мир нейросетей могло быть отсутствие доступа к GPU, теперь Вы можете смело сказать, “Держись Deep Learning, я иду!”.

Я попробовал использовать Colaboratory для работы над kaggle задачами. Мне больше всего не хватало возможности удобно сохранять натренированные tensorflow модели и использовать tensorboard. В данном посте, я хочу поделиться опытом и рассказать, как эти возможности добавить в colab. А напоследок покажу, как можно получить доступ к контейнеру по ssh и пользоваться привычными удобными инструментами bash, screen, rsync.

I. Вступление

Архитектура распределяет массы и объемы.
Вдохновение превращает инертный камень в драму.
Ле Корбюзье.

Недавно столкнулся со следующей ситуацией, одна крупная ИТ компания подбирала для себя архитектора, с целью доработки компьютерной платформы «собственного исполнения». Такая работа, естественно, требовала привлечения специалиста высокой квалификации. А как это сделать дешево и сердито, чтобы призванный варяг был «и чтец и жнец и на дуде игрец»? Решили без всяких излишеств разработчика ПО, поименовать архитектором, и заполучить помимо кодировщика, еще и профессионала, способного разобраться с чужими решениями, до проектировать их на свое усмотрение, принимать самостоятельные решения и т.п…

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

Что мы получим после этой статьи:

Систему сбора и анализа логов на syslog-ng, elasticsearch в качестве хранилища данных, kibana и grafana в качестве систем визуализации данных, kibana для удобного поиска по логам, elasticalert для отправки уведомлений по событиям. Приготовьтесь, туториал объемный.

Какие логи будем собирать:

• все системные логи разложенные по индексам в зависимости от их facility(auth,syslog,messages и т.д.);
• логи nginx — access и error;
• логи pm2;
• и др.

Обоснование выбора системы

Почему я выбрал связку с syslog-ng в качестве отправителя, парсера и приемщика логов? Да потому что он очень быстрый, надежный, не требовательный к ресурсам(да да — logstash в качестве агентов на серверах и виртуальных машинах просто убожество в плане пожирания ресурсов и требованием java), с внятным синтаксисом конфигов(вы видели rsyslog? — это тихий ужас), с широкими возможностями — парсинг, фильтрация, большое количество хранилищ данных(postgresql,mysql,elasticsearch,files и т.д.), буферизация(upd не поддерживает буферизацию), сторонние модули и другие фишки.

Требования:

• Ubuntu 16.04 или debian 8-9;
• vm для развертывания;
• Прямые руки.

Приступим или добро пожаловать под кат