Администрирование

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

Напомню краткое содержание предыдущей части: python, как впрочем и всё на нем написанное, временами прыгает в будущее, а конкретно в 2023-й год в локальной временной зоне, и по некоторым данным в 2024-й в UTC/GMT (но это не точно) и побыв там некоторое время возвращается обратно в настоящее.
Во время прыжка оно ведет себя довольно стабильно (т.е. считает нано-, микро- и миллисекунды, а то и секунды, как будто время идет как ни в чём не бывало) в 2023-м т.е. локально, при том что в результате повторных прыжков время вновь продолжается как будто по возвращению оно (время) течет в какой-то параллельной вселенной. Однако странное его "отражение" в UTC/GMT, ну то что как будто бы в 2024-м, выглядит менее стабильно, ибо для него наблюдается странные дрейфы дополнительно к смещению прыжка.
Хотя куда уж страннее.

За более 3х летний срок существования продукта у нас собралось более чем 20 репозиториев со spark проектами. Процесс CICD был реализован на Jenkins. С определенного момента у GitLab CI появилась возможность создавать собственные CICD. Но долгое время я совершенно не воспринимал всерьез этот инструмент. Так как мне нравилось, что в Jenkins можно взять и дописать то чего тебе не хватает на Groovy. Настройка WebUI предоставляет широкие возможности для организации параметризованных сборок. Поначалу функционал GitlabCI я воспринимал это как жалкое подобие Jenkins: чтобы реализовать ну что-то очень очевидное и простое, я уже молчу про параметризованную сборку.

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

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

Route Flap Damping (RFD) — это механизм локального подавления оттока обновлений BGP в Интернете. Стандартные параметры конфигурации RFD в маршрутизаторах слишком строгие и вызывают нежелательное блокирование изменений префикса, что приводит к проблемам с доступностью. Исследование 2010 года, посвященное IPv4 (и только одному производителю маршрутизаторов, Cisco), определило набор параметров конфигурации, позволяющих избежать этих проблем.

В этой заметке представлены результаты исследования 2021 года, проведенного мной и моими коллегами из Freie Universität Berlin, IIJ/Arrcus, Université de Strasbourg и HAW Hamburg, целью которого было воспроизвести и расширить результаты аналогичного исследования 2010 года, но на этот раз с учетом IPv6 и еще одного производителя маршрутизаторов (Juniper).

Приветствую читателей! В рамках текущей серии статей я рассказываю о том, как настроить сервер для простых проектов. Имеется ввиду сервер для работы нескольих сайтов, с небольшой нагрузкой под наиболее популярной CMS такой например как Bitrix. Основная цель статьи указать на ошибки допускаемых младшими специалистами при выполнении подобной настройки. Также указать на какие то вещи, которые сделают troubleshooting простым и удобным.

Это не совсем стэк LEMP, так как здесь используется Apache2, но вы можете использовать PHP-FPM вместо этого, если разработчик не против внедрения такого решения.

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

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

Предыдущие части статей доступны по следующим ссылкам:

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

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

Привет, хочу поделиться мыслями относительно OpenStack. История конечно не нова - годы безудержного хайпа вокруг этой технологии уже позади, это видно как субъективно, так и в отчётах Google Trends. Даже известные евангелисты этого продукта, вроде основателя Mirantis Александра Фридланда, подвели черту и отметили что тема в итоге не выстрелила и скатилась в ниши. О чем тогда разговор, если так все закончилось?

До 2022 года варианты SARS-CoV-2, вызывающие новые волны COVID-19, возникали примерно с полугодовыми интервалами. И была надежда на то, что после очередной волны, вызванной вариантом Дельта, наступит какое-то затишье. Тем более что в некоторых странах к началу этой волны было вакцинировано уже почти всё население. Но неожиданно быстрое распространение варианта Дельта принесло две новости – плохую и хорошую. Плохая новость заключалась в том, что иммунизация любыми нынешними вакцинами плохо защищает от инфицирования этим новым вариантом вируса. А если и защищает, то ненадолго. Хорошая – это то, что всё-таки защищает, но преимущественно от развития тяжёлых форм пневмонии. И существенно снижает летальность. В результате массовая вакцинация и увеличение количества переболевших почти не влияют на распространение вируса, но неплохо снижают смертность от COVID-19.

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

«Традиционно, самым узким местом в архитектуре любой информационной системы является система управления базами данных (СУБД). Можно сколько угодно оптимизировать прикладное программное обеспечение (ПО), но все равно упремся в ограничения в части производительности запросов». В своем материале я рассказываю о том, как построить архитектуру системы без слабых мест, и кого для этого стоит принести в жертву.

Данная статья — взгляд на то, как Kubernetes способен повысить уровень безопасности, упростив управление ею и ускорив внедрение механизмов безопасности с точки зрения специалиста по ИБ, который большую часть своей карьеры занимался наступательной безопасностью. Сейчас на примере Kubernetes я вижу, что на нем можно организовать так называемую self defense (самозащищающуюся) систему.

Меня зовут Дмитрий Евдокимов, я founder и CTO компании Лантри, а кто-то может меня лучше знать, как автора каналаk8s (in)security. Про безопасность я буду говорить, исходя из моего опыта, как человека, который десять лет атаковал различные системы, реализуя угрозы и риски. Ссылка на мое выступление на конференции DevOps Conf 2021 будет в конце статьи.

Почему стартапы обесцениваются, как свести риски провала до минимума и что в России не так с hardware? Ищем ответы в ISO 15288 и системной инженерии вместе с Дмитрием Паршковым — CEO Parshkov Inc и со-основателем Robots Can Dream. Он изучал системную инженерию в MIT, 15 лет делает стартапы, а еще консультирует крупные компании.

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

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

Цифровая трансформация в последние месяцы была особенно интенсивной. Во всех отраслях экономики компании продолжают вливаться в тренд ИТ-инноваций с точки зрения гибридных решений для работы, модели потребления aaS («как сервис»), использования массивов данных и киберустойчивости. Мы отобрали только лучшие выступления и хотим поделиться видеозаписями, вызвавшими наибольший интерес у слушателей. Регистрируйтесь по ссылке и смотрите все записи бесплатно.

Для жаждующих знаний и прогресса собрали материал из урока Дениса Наумова, спикера курсов Ansible и Python для инженеров. Немного разберёмся с теорией и посмотрим как написать модуль для создания пользователей в базе данных.

Материал объёмный. Рекомендуем сразу открыть итоговый код файла clickhouse.py для удобной работы со статьей.

Всем доброго дня. Я Иван Клименко, и я разработчик потоков данных в компании Аскона. Данная статья посвящена параметризации NIFI-потока и информированию СУБД об окончании загрузки.

Продолжаю рассказывать о разработке потоков ETL на Apache NIFI. Первая статья была более общей, в текущей я более подробно остановлюсь на параметрах процессоров в основных шагах, о применил атрибутов, как средства параметризации выполнения потока, и о применил для внесения в целевую систему с процессора PutDatabaseRecord.

Сообщество разработчиков ядра Linux недавно анонсировало bpfilter, который заменит давно существующую внутриядерную имплементацию iptables на высокопроизводительную сетевую фильтрацию на базе Linux BPF, гарантируя при этом переход без сбоев для пользователей Linux.