Билл Кеннеди в одной из лекций своего замечательного курса Ultimate Go programming сказал:

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

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

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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

Совсем недавно гитлаб героически выкатил версию 8.0 своего конкурента гитхабу. Из интересного — движок continuous integration теперь встроен в платформу, а значит доступен в качестве бесплатного сервиса для всех желающих на gitlab.com. Совместно с бесплатными приватными репозиториями это делает облачный сервис гитлаб не только удобным местом для хранения кода, но также тестирования и деплоя. О последнем я и расскажу под катом.

Когда дело доходит до создания Docker-контейнеров, лучше всегда стремиться к минимизации размера образов. Образы, которые используют одни и те же слои и весят меньше — быстрее переносятся и деплоятся.

Но как контролировать размер, когда каждое выполнение оператора RUN создает новый слой? Плюс, еще нужны промежуточные артефакты до создания самого образа...

Подготовили перевод следующей части многосерийной статьи, где сравнивается функциональность Apache Kafka и RabbitMQ. В этой публикации речь идёт о семантике и гарантии доставки сообщений. Обращаем ваше внимание, что автор учитывал Кафку до версии 0.10 включительно, а в версии 0.11 появился exactly-once. Тем не менее, статья остаётся актуальной и полна полезных с практической точки зрения моментов.
Предыдущие части: первая, вторая.

Так случилось, что ваша программа написана на скриптовом языке — например, на Ruby — и встала необходимость переписать ее на Golang.

Резонный вопрос: зачем вообще может понадобится переписывать программу, которая уже написана и нормально работает?

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.

Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.

Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.

Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с использованием стороннего плагина под названием pglogical.

В процессе «проб» мы столкнулись с весьма обрывочной документацией по этому процессу (а на русском языке её вообще нет), а также некоторыми подводными камнями и неочевидными нюансами. В этой статье мы хотим изложить свой опыт в виде Tutorial.



TL;DR

• Всё получилось (не без костылей, о них и статья).
• Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
• Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

Это вторая часть введения в Kubernetes для пользователей VMware. Прежде чем перейти к практической части, ознакомьтесь с предыдущей статьей по ссылке.

От переводчика: публикуем для вас статью Даррена Барнса, который делится своим опытом работы с GitHub. Его советы будут полезны, в первую очередь, новичкам. Возможно, и опытный кодер найдет что-то для себя.

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

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

Краткое знакомство с kubernetes для разработчиков на примере разворачивания простого шаблонного сайта, с постановкой его на мониторинг, выполнением джобов по расписанию и health checks (все исходники прилагаются)

— Установка Kubernetes
— Установка UI
— Запуск своего приложения в кластере
— Добавление кастомных метрик в приложение
— Сбор метрик через Prometheus
— Отображение метрик в Grafana
— Выполнение задач по расписанию
— Отказоустойчивость
— Выводы
— Заметки
— Список литературы

Введение

Liquibase представляет из себя систему управления версиями базы данных, в основном это касается структуры и в меньшей степени содержимого базы. При этом описание базы с одной стороны достаточно абстрактно и позволяет использовать на нижнем уровне различные СУБД, и с другой стороны всегда можно перейти на SQL-диалект конкретной СУБД, что достаточно гибко. Liquibase является устоявшимся проектом с открытым исходным кодом и активно используется за пределами своей родной Java среды и не требует глубоких знаний Java для работы. В качестве описания структуры базы и изменений базы исторически использовался XML формат, однако сейчас параллельно поддерживается YAML и JSON.

В данной статье мы немного обобщим опыт предыдущих поколений и сосредоточимся на работе с Liquibase с использованием Maven. В качестве тестовой операционной системы будем использовать Ubuntu.

Это текстовая версия выступления 2018-04-25 на Saint-Petersburg Linux User Group. Пример кода тут: https://github.com/ultral/ansible-role-testing

Полагаю что вы используете configuration mangement, а не bash. Т.е. ваша конфигурация это код. Если мы говорим, что инфраструктура это код, то к её созданию должна применяться та же философия, что и для разработки ПО. Вы задумывались об этом? Как у вас это сделано? А у других?

Привет, Хабр! Вдоволь наотдыхавшись после длинных праздников, мы снова готовы причинять вам пользу всеми доступными способами. Коллегам из IT-департамента всегда есть что рассказать, и сегодня мы делимся с вами докладом Александра Призова, системного администратора Яндекс.Денег, с митапа JavaJam.

Как мы выстроили поток обратной связи для обнаружения проблемных релизов с помощью Graphite и Moira. Расскажем, как собирать и анализировать метрики о количестве ошибок в приложении.

Проблема

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

Для тех, кому не интересна лирика, и кто хочет сразу перейти к делу — то вперед на github. А для тех, кому важна механика и история проекта — собственно и посвящена статья.

С появлением специализированных ресурсов биржы труда, таких как LinkedIn, HeadHunter и др., казалось бы, ситуация должна была улучшиться — заполняем весь опыт в одном месте, и больше прошлое не ворошим. Но не тут-то было — заполнили в одной системе, нельзя просто по клику мышки выгрузить ее в другую. Нету единой БД, на которую можно линковать свою учетную запись. Оно и понятно — подобные компании заинтересованы вытеснить других, а не заниматься интеграцией друг с другом, а простым кандидатам в итоге становится только хуже.

Эта статья является третьей в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.



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

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

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

Наша задача сейчас – выявить риски, связанные с защищенностью на уровне сети и снизить их до разумной величины.

Привет, Хабр! Предлагаю вашему вниманию перевод статьи Брендана Грегга, посвящённой изучению eBPF

На конференции Linux Plumbers было как минимум 24 выступления по eBPF. Он быстро стал не просто бесценной технологией, но и востребованным навыком. Возможно, вам хотелось бы поставить какую-то цель на новый год — изучите eBPF!

Термин eBPF должен означать что-то существенное, как например Virtual Kernel Instruction Set (VKIS), но по своему происхождению это расширенный Berkeley Packet Filter. Он применим во многих областях, таких как производительность сети, фаерволлы, безопасность, трассировка и драйвера устройств. По некоторым из них есть много свободно доступной информации в интернете — например, по трассировке, а по другим ещё нет. Термин трассировка относится к инструментам анализа производительности и наблюдения, которые могут генерировать информацию по каждому событию. Возможно, вы уже использовали трассировщик — tcpdump и strace являются специализированными трассировщиками.

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

• Начинающим: запуск инструментов bcc
• Опытным: разработка инструментов bpftrace
• Продвинутым: разработка инструментов bcc, вклад в bcc и bpftrace

Рады анонсировать новую Open Source-разработку компании «Флант» для DevOps-специалистов и не только — kubedog. Это написанная на Go библиотека и CLI на её основе для отслеживания событий ресурсов Kubernetes и сбора их логов.


На данный момент библиотека поддерживает слежение за следующими ресурсами: Pod (и Container), Job, Deployment, StatefulSet и DaemonSet. События и логи передаются через callback’и.

«Умные разработчики любят работать с умным кодом. Открывая качественные исходники, вы привлекаете талантов»


Иллюстрация Kevin Ma

«Вы знаете о проектах Facebook с открытым исходным кодом?»

Такой вопрос задал инженерам Джеймс Пирс, бывший директор программы по открытым исходным кодам Facebook. Он изучал причины, почему те пришли в компанию. Согласно его презентации на O'Reilly's Open Source Convention, две трети инженеров Facebook знали об этой программе до прихода в компанию, а половина сказали, что это «положительно повлияло на их решение работать в Facebook».

Прим. перев.: Оригинал этой статьи был опубликован в официальном блоге Kubernetes и написан Andrew Martin — одним из основателей молодой британской компании Control Plane, специализирующейся на безопасности для cloud native-приложений, запускаемых в K8s.



Безопасность в Kubernetes прошла длинный путь с момента появления проекта, однако в ней по-прежнему встречаются подводные камни. Предлагаем список полезных рекомендаций по тому, как защитить кластеры и повысить их устойчивость в случае взлома: начнём с control plane, продолжим с рабочими нагрузками и сетевой безопасностью, а закончим оценкой будущего безопасности.

1-3 февраля пройдёт Слёрм-3, интенсив по Kubernetes. Анонс и программа тут.

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

Я сам 2-3 раза в год прохожу платные курсы, всегда беру варианты с практикой, и очень редко доделываю ее до конца. Для меня ситуация выглядит, как если бы я заказал в ресторане килограммовый стейк: съел, сколько мог, остальное оставил на тарелке. Но в тех, кто едет на Слёрм, хотелось бы запихнуть всю порцию.

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

Поэтому на втором Слёрме кроме трех спикеров со студентами работал десяток саппортов: системных администраторов из команды Southbridge.