В интернете много справочной литературы, но иногда самыми ценными становятся самые простые советы. Команда Kubernetes aaS от Mail.ru перевела подборку из десяти хитростей и советов, которые автор статьи собрала после года работы с Kubernetes. Советы не отсортированы по важности, но думаем, что каждый найдет что-то полезное для себя.

Прим. перев.: Автор оригинального материала — Henning Jacobs из компании Zalando. Он создал новый веб-интерфейс для работы с Kubernetes, который позиционируется как «kubectl для веба». Почему новый Open Source-проект появился и каким критериям не удовлетворили уже существующие решения — читайте в его статье.



В этой публикации я рассматриваю различные веб-интерфейсы Kubernetes с открытым исходным кодом, предъявляю свои требования к универсальному UI и рассказываю, почему разработал Kubernetes Web View — интерфейс, призванный облегчить поддержку и устранение неполадок сразу во множестве кластеров.

Сценарии использования

В Zalando мы обслуживаем большое количество пользователей Kubernetes (900+) и кластеров (100+). Есть пара типичных случаев использования, в которых бы очень пригодилась помощь специализированного веб-инструмента:

1. общение с коллегами в рамках поддержки;
2. реагирование на инциденты и расследование их причин.

В эпоху повсеместного CI/CD мы сталкиваемся с большим спектром сопутствующих инструментов, в том числе и CI-систем. Однако именно GitLab стал для нас самым близким, по-настоящему «родным». Заметную популярность он снискал и в индустрии в целом*. Разработчики продукта не отставали от роста интереса к его использованию, регулярно радуя сообщество разработчиков и DevOps-инженеров новыми версиями.


Агрегация по месяцам и тегам репозитория GitLab

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

О наиболее значимых — т.е. востребованных нашими DevOps-инженерами и клиентами — нововведениях в последних релизах Community-редакции GitLab и пойдет речь в статье.

Сейчас в издательстве ДМК-Пресс выходит русский перевод японской манги 2013 года про цифровые схемы, созданной Амано Хидэхару и Мэгуро Кодзи. Несмотря на несерьезную форму изложения, суть этой книжки очень здравая. Например, она начинает от древних микросхем малой степени интеграции и быстро привязывает их к современному языку описания аппаратуры Verilog и программируемым логическим интегральным схемам (ПЛИС). Также манга четко определяет зачем нужны комбинационные и последовательностные схемы, и дает представление о методах оптимизации.

Манга избегает ошибок многих своих предшественников. Одну из таких ошибок совершил Чарльз Петцольд в книге «Код», которая вводила последовательностную логику не на D-триггерах, управляемых фронтом тактового сигнала (edge-triggered D-flip-flop), а на D-триггерах с работой по уровню (защелках, level-sensitive D-latch), хотя потом переключалась на правильные триггеры. Вероятно, ошибка была связана с тем, что Чарльз Петзольд, который прославился как автор учебников по программированию GUI в Microsoft Windows, не был практикующим разработчиком электроники, и для него защелки были «проще», чем триггеры с фронтом. Проблема в том, что защелки плохо совместимы со статическим анализом задержек при логическом синтезе, главной технологии проектирования цифровых схем последних 30 лет. Системы на кристалле внутри гаджетов типа айфона в качестве элементов состояния в 99% случаях используют D-триггеры переключаемые по фронту, а защелки используют только в очень специальных случаях. Давать новичкам строить схемы на защелках — это значит вводить их в заблуждение.

В этом смысле манга лучше чем Петзольд. Вот как элегантно манга объясняет работу двухступенчатого master slave D-триггера, управляемого фронтом тактового сигнала. Это делается с помощью феи «Хи-хи-хи» и феи «Ха-ха-ха»:

В прошлой статье мы рассмотрели кластеризацию RabbitMQ для обеспечения отказоустойчивости и высокой доступности. Теперь глубоко покопаемся в Apache Kafka.

Здесь единицей репликации является раздел (partition). У каждого топика один или несколько разделов. В каждом разделе есть лидер с фолловерами или без них. При создании топика указывается количество разделов и коэффициент репликации. Обычное значение 3, это означает три реплики: один лидер и два фолловера.

Заканчивался 2018-й год…

Однажды, ясным декабрьским днём, решила наша Компания приобрести новое «железо». Нет, конечно, это не случилось в одночасье. Решение было принято раньше. Намного раньше. Но, как водится, не всегда наши желания совпадают с возможностями акционеров. И денег не было, и мы держались. Но наконец-то наступил тот радостный момент, когда приобретение было одобрено на всех уровнях. Всё было хорошо, «белые воротнички» радостно аплодировали, надоело им на серверах 7-ми летней давности ежемесячно обрабатывать документы по 25 часов и они очень настойчиво просили Департамент ИТ придумать что-нибудь, чтобы подарить им больше времени для других, не менее важных дел.

Мы пообещали сокращение времени обработки документов в 3 раза, до 8 часов. Для этого выстрелили из пушки по воробьям. Этот вариант казался единственным, поскольку в нашей команде нет, и никогда не было, администратора баз данных для применения всевозможных оптимизаций запросов (DBA).

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

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

Недавно посмотрела выступление одного scrum-мастера и stand up комика по совместительству. Выступление оказалось эмоциональное, с большим количеством непечатных слов и долей здравого смысла.

В каждой шутке только доля шутки, но все же прошу не относиться к этому материалу слишком серьезно. Предлагаю для ознакомления свое изложение в «очищенном» формате. Увидеть полное выступление Ильи Якямсева «Эффективность не работает» на конференция FrontDays 2018 можно по ссылке.

Эффективность не работает

Этот доклад скорее жизнеутверждающий, позитивный, и он про жизнь, не про программирование. Хотя много будет про программирование, но косвенно. 

Я работаю менеджером проекта. Начинал я в Тольятти, в 96 году, на должности «эй, пацан, принеси пиво». С 99 года я начал программировать front, тогда это называлось «верстак». Потом я открыл контору, закрыл ее, многое произошло, и сейчас я менеджер проектов.

Мой доклад называется «Эффективность не работает». И я объясню почему.

Жизнь после 30

Дело в том, что мне сорокет в этом году. Я работаю в основном с людьми помоложе себя, и они у меня часто спрашивают: «Илья, как она жизнь в IT после 30? Ну, то есть, что с ней происходит?». Я отшучиваюсь: как говорится, баб поменьше, детей побольше. 



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

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

Даже несмотря на то что хардварный дизайн стоит того что бы заниматься им исключительно для удовольствия, в данной статье мне хочется уделить внимание практической ценности данного занятия. В частности, наш разговор пойдет от том как создать сетевую инфраструктуру для операторов связи с использованием инкапсулятора Etherblade.net, реализованного на FPGA.

Данный текст является некоторым экскурсом в сетевые технологии и для того чтобы уместить такую обширную тему в рамках одной статьи, я решил написать ее в контексте некоторого плана действий или, если желаете, ответа на следующий вопрос – «Как используя FPGA и опенсорс максимально эффективно заместить оборудование от Cisco и Juniper».
Итак, начнем.

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

По мотивам статьи Телеграмм-бот для системного администратора (статья не моя, я только прочитал) захотел поделиться опытом создания Telegram-бота на PowerShell для управления серверами приложений. Будет текст, код и немножко картинок. Конструктивная критика приветствуется ( главное чтобы не звучало «зачем на PowerShell? Надо было на perl» ).

Думаю что статья больше подойдет «новичкам» в PowerShell, но и опытные администраторы могут что-то полезное здесь увидеть.

Саму статью старался построить по частям – от простого к сложному. Возможно, встретится плагиат, будьте бдительны!

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

• Простота добавления/изменения задач в Telegram-бот
• Многозадачность или параллелизация
• «Понятный» интерфейс управления
• Хоть какая-то безопасность

Системы контроля версий уже давно стали повседневным инструментом разработчика. В больших монорепозиториях требования к ним оказываются весьма специфическими. Из-за этого компании либо адаптируют существующие решения, как это делает Facebook с Mercurial и Microsoft с Git, либо разрабатывают собственные системы: Piper и CitC в Google и Arc VCS в Яндексе.

В докладе разработчик Владимир Кихтенко kikht рассказывает, зачем Яндексу понадобилась собственная система контроля версий и как она работает. Рассмотрим её со стороны рядового разработчика: как получить доступ к исходному коду, отвести ветку для разработки и интегрировать изменения в общую кодовую базу. Заглянем под капот — узнаем про внутреннее представление данных и их отображение в виртуальной файловой системе с рабочей копией. Обсудим трудности при реализации функций VCS в виртуальной файловой системе и при ленивой загрузке данных. Поговорим о том, как обеспечивать надежность серверной инфраструктуры репозитория. В конце можно посмотреть неофициальную запись доклада.

— Всем добрый день, меня зовут Владимир. Вы все слышали выступления о том, что не стоит писать велосипеды. Мой доклад будет с другой стороны баррикад.

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

Особым вниманием у нас пользуются зарубежные теоретики. Спросите начальника что прочесть на эту тему или попросите назвать “любимую книгу”. Наверняка услышите фамилии Голдратт, Адизес, Макиавелли… Неоднократно убеждался лично, что почерпнутые из этих книг “бесценные знания” навсегда вытесняют из сознания “руководителей” школьную программу. Человек с трудом и уже неправильно отвечает на вопрос “Чему равен корень из 9 и -9 ?”… Но это отдельный разговор.

На мой взгляд, отечественный классик менеджмента Владимир Тарасов, который изучал эту тему ещё с позднесоветской поры, отлично раскрыл её в своём творчестве, особенно в книгах “Персональное управленческое искусство”, “Восемь ступеней управленческого мастерства”. Начинать знакомство с “менеджментом”, что по определению, есть “Искусство выполнять работу чужими руками” (sic), рекомендовал бы с последней.

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

Kubernetes Dashboard — простой в работе инструмент для получения актуальных сведений о работающем кластере и минимального управления им. Начинаешь его ценить ещё больше, когда доступ к этим возможностям нужен не только администраторам/DevOps-инженерам, но и тем, кто меньше привык к консоли и/или не намерен разбираться со всеми тонкостями взаимодействия с kubectl и другими утилитами. Так случилось и у нас: разработчикам захотелось быстрого доступа к веб-интерфейсу Kubernetes, а поскольку мы используем GitLab, решение напросилось само собой.

Люди учатся архитектуре по старым книжкам, которые писались для Java. Книжки хорошие, но дают решение задач того времени инструментами того времени. Время поменялось, C# уже больше похож на лайтовую Scala, чем Java, а новых хороших книжек мало.

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

Эта статья является расшифровкой моего доклада с конференции DotNext 2018 Moscow. Кроме текста, под катом есть видеозапись и ссылка на слайды.

Команда Zabbix с радостью сообщает о выходе Zabbix 4.4. Последняя версия поставляется с новым Zabbix агентом, написанным на языке Go, устанавливает стандарты для шаблонов Zabbix и предоставляет расширенные возможности визуализации.



Давайте рассмотрим наиболее важные функции, включенные в Zabbix 4.4.

«Flying Cart», Afu Chan

Я работаю в Mail.ru Cloud Solutons архитектором и разработчиком, в том числе занимаюсь нашим облаком. Известно, что распределенной облачной инфраструктуре нужно производительное блочное хранилище, от которого зависит работа PaaS-сервисов и решений, построенных с их помощью.

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

Расскажу, как это было — возможно, эта история, проблемы, с которыми мы столкнулись, и наши решения будут полезны тем, кто тоже использует Ceph. Кстати, вот видеоверсия этого доклада.

Прим. перев.: автор статьи — Erkan Erol, инженер из SAP — делится своим изучением механизмов функционирования команды kubectl exec, столь привычной для всех, кто работает с Kubernetes. Весь алгоритм он сопровождает листингами исходного кода Kubernetes (и связанных проектов), которые позволяют разобраться в теме настолько глубоко, насколько это требуется.



В одну из пятниц ко мне подошел коллега и поинтересовался, как выполнить команду в pod'е с помощью client-go. Я не смог ему ответить и внезапно осознал, что ничего не знаю о механизме работы kubectl exec. Да, у меня были определенные представления о его устройстве, однако я не был уверен на 100% в их правильности и потому решил заняться этим вопросом. Проштудировав блоги, документацию и исходный код, узнал много нового, и в этой статье хочу поделиться своими открытиями и пониманием. Если что-то не так, пожалуйста, свяжитесь со мной в Twitter.

Ну ладно, про «полюбил» — это преувеличение. Скорее «смог сосуществовать с».

Как вы все знаете, с 16 апреля 2018 года Роскомнадзор крайне широкими мазками блокирует доступ к ресурсам в сети, добавляя в "Единый реестр доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено" (по тексту — просто реестр) по /10 иногда. В результате граждане Российской Федерации и бизнес страдают, потеряв доступ к необходимым им совершенно легальным ресурсам.

После того, как в комментариях к одной из статей на Хабре я сказал, что готов помочь пострадавшим с настройкой схемы обхода, ко мне обратились несколько человек с просьбой о такой помощи. Когда у них всё заработало, один из них порекомендовал описать методику в статье. Поразмыслив, решил нарушить свое молчание на сайте и попробовать в кои-то веки написать что-то промежуточное между проектом и постом в Facebook, т.е. хабрапост. Результат — перед вами.

Примерно год назад передо мной и моими коллегами была поставлена задача разобраться с использованием популярной системы мониторинга сетевой инфраструктуры — Zabbix. После изучения документации мы сразу же перешли к нагрузочному тестированию: хотели оценить с каким количеством параметров может работать Zabbix без заметных падений производительности. В качестве СУБД использовали только PostgreSQL.

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

О результатах проделанной работы я и хочу поделиться в данной статье. Статья будет полезна как администраторам Zabbix, так и PostgreSQL DBA, а также всем желающим лучше понять и разобраться в популярной СУБД PosgreSQL.

Небольшой спойлер: на слабой машине при нагрузке в 200 тысяч параметров в минуту нам удалось снизить показатель CPU iowait с 20% до 2%, уменьшить время записи порциями в таблицы первичных данных в 250 раз и в таблицы агрегированных данных в 32 раза, уменьшить размер индексов в 5-10 раз и ускорить получение исторических выборок в некоторых случаях до 18 раз.

Зачем такой корпорации, как МегаФон, Tarantool в биллинге? Со стороны кажется, что обычно приходит вендор, приносит какую-то большую коробку, втыкает штекер в розетку — вот и биллинг! Когда-то так и было, но сейчас это архаика, и такие динозавры уже вымерли или вымирают. Изначально биллинг это система для выставления счетов — считалка или калькулятор. В современном телекоме — это система автоматизации всего жизненного цикла взаимодействия с абонентом от заключения договора до расторжения, включая real-time-тарификацию, прием платежей и еще много чего. Биллинг в телеком-компаниях похож на боевого робота — большого, мощного и обвешанного оружием.



Причем же здесь Tarantool? Об этом расскажут Олег Ивлев и Андрей Князев. Олег — главный архитектор компании МегаФон с огромным опытом работы в зарубежных компаниях, Андрей — директор по бизнес-системам. Из расшифровки их доклада на Tarantool Conference 2018 вы узнаете, зачем нужен R&D в корпорациях, что такое Tarantool, как тупик вертикального масштабирования и глобализация стали предпосылками появления этой БД в компании, про технологические вызовы, трансформацию архитектуры, и чем техностек МегаФон похож на Netflix, Google и Amazon.