Одним недавним летним вечером коротал я время за выпуском сертификатов Let's Encrypt (LE) в кубере, и долго не мог понять с какого перепугу сработало ограничение на количество сертификатов в неделю, т.е. 50 штук.
Быстрая проверка на https://crt.sh/ показала, что действительно для совершенно разных поддоменов было выпущено много странных сертификатов, и это, мягко говоря, удивило.
Существует миллион разных причин, по которым могут возникать сбои в работе конвейеров данных, и нет ни одного универсального подхода, помогающего сразу понять, как и почему они случаются. В этой статье я расскажу вам о пяти шагах, которые нужно совершить дата-инженеру, чтобы провести анализ первопричин (Root Cause Analysis - RCA) проблем с качеством и пригодностью данных (Data Quality).
Как Octopod помогает сделать динамические окружения доступными для всех
Привет, Хабр! В этой статье я хочу рассказать как мы в Typeable используем динамические окружения (review- или preview-окружения) в нашей работе, какие проблемы нам удалось решить, почему и как мы применяем свое решение Octopod, а не GitLab Dynamic Environments для этих целей. Если вы не знаете, что такое динамическое окружение, то рекомендую прочесть статью компании Flant, где автор очень подробно рассказал о видах динамических окружений, зачем они нужны и как применяются, а также детально разобрал эту тему на примере GitLab с подробными примерами и описаниями. У нас же есть альтернативный и идеологически несколько отличающийся подход к работе с review-окружениями в Octopod. Про историю создания Octopod и причины, побудившие нас его создать, мы уже писали ранее. Повторяться не будем, а сосредоточимся на отличиях нашего подхода и тех проблемах, которые мы решили.
Данная статья является гайдом по использованию кастомных агрегаторов в Spark SQL API. Она “выросла” из моих заметок, которые я делал себе с начала работы со Spark. Сейчас, по мере накопления опыта, мне все это кажется уж слишком наивным и простым, но в свое время мне это показалось чертовски удобным/изящным/заслуживающим внимания, поэтому и решил опубликовать, тем более на Хабре про это еще вроде не писали. Статья ориентирована в первую очередь на тех, кто только начинает работать со Spark, поэтому и помечена как “tutorial”. Если у вас есть какие-либо интересные кейсы по использованию кастомных агрегаторов - делитесь в комментариях!
Ниже мы будем говорить о user-defined aggregations functions (UDAF) org.apache.spark.sql.expressions.Aggregator, которые могут быть использованы для DataSet’ов с целью агрегации группы элементов в одно значение каким-угодно-пользователю образом.
• Действительно ли электоральные предпочтения сельских жителей существенно отличаются от предпочтений городских жителей?
• Зачем нужно срочно вводить электронное голосование в крупных городах России?
• Как выглядят на графиках и на карте России аномальное голосование?
• Подробные карты окрестностей городов России с результатами голосования на выборах в государственную Думу в 2021 году.
АВР – очень широкое понятие. Совершенно одинаково называются устройства, которые трудно назвать одним прибором. Мы видим и однофазный модульный АВР на 16 ампер, и, совсем не похожий на него, АВР на 6 400 А. При этом, оба носят абсолютно одинаковое наименование – автоматический ввод резерва.
С приходом в нашу жизнь импортного телекоммуникационного оборудования и зарубежных стандартов, проникло и новое словосочетание - стоечный переключатель нагрузки. Тот же самый АВР, только имеющий свои особенности и специфику подключаемой нагрузки.
Холодные запуски могут оказаться губительными для производительности AWS Lambda, особенно если вы создаёте клиентоориентированное приложение, которое должно работать в режиме реального времени. Представьте себе, что пользователь отправил приложению запрос, а ваша функция AWS Lambda ещё не запущена. В таком случае система AWS должна будет сначала развернуть ваш код и запустить новый контейнер — и только после этого выполнит запрос. Соответственно, выполнение запроса может занять гораздо больше времени: Lambda-функция начнёт работать только тогда, когда для неё будет готов контейнер.
Эта статья о вреде выделенных команд DevOps инженеров в организации. Начну издалека. В книге Джорджа Массера "Нелокальность" приводится такой интересный момент оценки расстояния с точки зрения влияния. "Лев близко, значит он может напасть" - это о влиянии через определение пространство. Однако концепция "Лев может напасть, значит он близко" - нивелирует саму концепцию пространства. В сфере DevOps все скатывается в набор ритуалов и надутые щеки DevOps методологов-футурологов-идеологов и много чего. Речь разумеется не идет про лидеров индустрии, речь идет скорее про среднестатистические компании на рынке. Давайте перевернем все с головы на ноги!
Rancher - это система, которая работает над Kubernetes и позволяет работать с несколькими кластерами через одну точку входа. Rancher помогает оптимизировать развёртывание кластеров в разных средах: bare-metal сервер (выделенный, железный), частные облака, публичнык облака и объединяет кластеры с помощью единой аутентификацией, контролем доступа и политик безопасности.
Каким бы образом не был создан кластер и где бы он не находился, Rancher предоставляет доступ ко всем кластерам через одну панель управления.
Никита Соболев покажет множество функций Github Actions, поделится собственными впечатлениями и болями от первых месяцев использования, покажет, как сделать собственные инструменты.
Platform as a Service в Авито — это набор проработанных решений, которые позволяют продуктовой разработке не тратить много времени на рутинные задачи и низкоуровневые инструменты. Наши спикеры рассказали, как происходит локальная разработка, автоматическое тестирование, деплой и эксплуатация сервисов в PaaS. Собрали записи с таймкодами и презентации в посте.
С 29 октября 2021 года читатели российских библиотек не могут открыть газетную базу EastView с советскими газетами и журналами. Причиною стал Роскомнадзор. Запрет обошли, создав новый домен.
Когда мы говорим про запуск Windows программ в Unix, первым в голову нам приходит свободный проект Wine, проект основанный в 1993 году.
Но, кто бы мог подумать, что Microsoft сама была автором ПО для запуска Windows-программ в UNIX.
В 1994 году Microsoft начала проект WISE - Windows Interface Source Environment - прибл. Исходная среда интерфейса Windows - программу лицензирования, которая позволяла разработчикам перекомпилировать и запускать приложения на базе Windows на других платформах.
Пакеты WISE SDK были основаны на эмуляции Windows API, который мог работать на платформах Unix и Macintosh.
SDK напрямую не поставлялись Microsoft. Вместо этого она установила партнерские отношения с несколькими поставщиками ПО (которым требовался доступ к внутреннему исходному коду Windows), которые, в свою очередь, продавали WISE SDK конечным пользователям.
В этой статье я хотел бы рассказать о том, как мы меняли подход к оркестрации на нашем стартап-проекте, зачем мы это делали и какие проблемы по дороге решали. Претендовать на уникальность эта статья вряд ли может, но все же думаю, что она может быть кому-то полезна, так как в процессе решения задачи материал собирался нами с приличным скрипом.
Что мы имели и о чем вообще речь? А имели мы стартап-проект с примерно 2-летней историей разработки из advertisement области. Проект изначально строился как микросервисный, и серверная его часть написана на Symfony + немного Laravel, Django и нативного NodeJs. Сервисы представляют из себя в основном API для мобильных клиентов (их в проекте 3) и нашего собственного SDK для IOS (встраивается в приложения наших кастомеров), а также веб-интерфейсы и разные дашборды этих самых кастомеров. Все сервисы были изначально докеризированы и работали под управлением docker-compose.
Правда, docker-compose использовался не везде, а только в локальном окружении у разработчиков, на тестовом сервере и внутри pipeline при сборке и тестировании сервисов. А вот в production окружении использовался Google Kubernetes Engine (GKE). Причем настройку GKE на старте проекта мы делали полностью через его web-интерфейс, что было довольно быстро и, как нам тогда казалось, удобно. Автоматизирован тут был только процесс сборки docker images для запуска сервисов в GKE.
Всем привет!
Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире.
Главные темы нового выпуска:
И многое другое…
В составлении дайджеста мне помогали qark, invasy и 8 пользователей через нашего Telegram бота [→]
Ещё — мы не только составляем FOSS дайджесты, но и автоматизируем процесс, все 3 проекта автоматизации тоже являются FOSS, их можно посмотреть на GitHub [→]. На очереди ML и мы собираем средства на хакатоны [→], будем рады если читатели помогут, всё ведь для вас.
Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.
А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.
Желательны но необязательны базовые знания
В дальнейшем мы сделаем следующее.
Привет, Хабр! В прошлом посте мы уже рассказывали о том, что происходило на первом дне Acronis #CyberFit Summit в Майами. Сегодня пришло время подвести итоги второго дня, в ходе которого проходил завтрак Woman in Tech, обсуждение прибыльности работы провайдеров, беседа с бывшим переговорщиком ФБР Крисом Воссом, а также круглый стол по вопросам перспектив отрасли киберзащиты. Если вы принимали участие в нашем гибридном мероприятии или хотели бы это сделать, добро пожаловать под кат.
Максимально переложив ответственность за онлайн своего приложения, ты сможешь сфокусироваться на других задачах, думать больше о новых фичах и новых приложениях. Ведь попробуй просто представить себе, как ты с утречка начинаешь поднимать 20 ботов на своём бедном Lenovo в надежде, что сегодня ни свет, ни интернет не выключится? Представил? А теперь представь если 20 ботов висят на сервере и ты с утра заходишь, смотришь какой у них статус с помощью удобного дашборда. Так и 21е приложение не за горами будет :)
Понимаю, всё звучит так классно, но ты возразишь, а деньги на сервер зачем выбрасывать? Тебе кажется, что твой бот только тебе и интересен, зачем же тратиться. А если я скажу что есть сервис, бесплатный, качественный, функциональный, который в начале кажется сложным, но как всё сложное, его нужно лишь понять и станет простым и отличным помощником.
Выглядит как промо за 50$, но на самом деле я был поражен лишь тем фактом, что если зайти на цены, то там есть раздел Hobby. Это на моей памяти первый случай, когда сервис есть в бесплатном виде, чтобы поддерживать начинания разработчиков, и потом, когда идея окажется работоспособной, тут же можно понемногу увеличивать возможности своего сервиса. Только за это уже можно читать дальше, разве нет?