Привет, Хабр! Меня зовут Матвей Мочалов, я — компьютерный инженер и один из авторов корпоративного блога cdnnow! Как-то мы уже обсуждали особенности Docker на разных системах, а сегодня я хочу копнуть глубже — поговорить о том, как наша индустрия поймала саму себя в ловушку Джокера и умудрилась запутать всех, выдавая контейнеризацию за виртуализацию.
Продолжим об этом ниже в посте.
Привет, Хабр! Cегодня мы разберемся с одним из ключевых аспектов работы CDN – статусами кеша. Если вы когда-нибудь заглядывали в заголовки ответа сервера или анализировали логи CDN, то наверняка встречали загадочные аббревиатуры HIT, MISS или EXPIRED. Давайте разберемся, что они означают и почему так важны для понимания работы CDN.
Привет, Хабр! С вами снова Матвей Мочалов из cdnnow!, и в этом посте мы не будем разбираться с FFmpeg - в этот раз наша рубрика «Эээээксперименты!» будет затрагивать объектные хранилища. Разберёмся, чем S3 отличается от S3, а также почему не всё то S3, что называется S3. А заодно эксперимента ради сделаем своё собственное простенькое объектное хранилище на любимом языке всех DevOps и SRE-инженеров – Go.
Среда оркестрации контейнеризированных приложений Kubernetes получила в последние годы широкое распространение.
Для этого есть множество причин. Прежде всего это все те преимущества, которые дает использование контейнеров: возможность построения микросервисной архитектуры, когда мы можем разделить приложение на отдельные компоненты, работающие в контейнерах и реализовывать в них нужный нам функционал независимо от других элементов нашего решения. Также, контейнеры позволяют эффективнее использовать оборудование, их удобно применять там, где нужно развернуть несколько идентичных экземпляров приложения, например, при миграции из среды разработки в среду тестирования.
Когда серверов, на которых запущены контейнеры становиться несколько десятков и более, возникает необходимость в использовании инструмента для централизованного управления узлами контейнеризации и здесь на помощь приходит Kubernetes. С его помощью можно развернуть множество экземпляров одного приложения, автоматически поддерживать необходимое их количество, обеспечить прозрачный для пользователей процесс обновления множества микросервисов из которых оно состоит, разграничить доступ к разным экземплярам контейнеров и многое другое.
Таким образом, совершенно очевидно, что Kubernetes является по сути основой для всей инфраструктуры, на которой работает приложение и то, насколько безопасно оно будет работать во многом зависит от того, насколько правильно будет настроена сама среда оркестрации.
Конечно, можно внедрить различные механизмы защиты, например ролевую модель доступа, о которой мы уже говорили ранее, но судить о том, насколько хорошо защищена та или иная система можно только попытавшись пойти по пути хакера, то есть попытаться ее взломать. В реальной жизни эту задачу обычно выполняют так называемые «белые хакеры» – пентестеры. В этой статье мы попробуем посмотреть на безопасность Kubernetes как раз глазами пентестеров.
Привет, Хабр! Сегодня мы снова будем экспериментировать, но уже не с FFmpeg, как до этого, а с твердотельными накопителями. Относительно бенчмарков и их производительности принято считать, что показатель IOPS с разными версиями PCIe интерфейса почти не меняется. Так как в отличие от скорости шины данных этот показатель больше привязан к способности контроллера самого SSD осуществлять определенное количество операций в секунду.
Убеждение это родилось в среде обычных ПК-пользователей. Однако в силу его повсеместности часто встречается, в том числе когда речь заходит о моделях предназначенных для дата-центров. И как в очередной раз оказалось, наиболее частое мнение не всегда является верным.
Система оркестрации Kubernetes или как ее называют сокращенно K8s на сегодняшний день стала стандартом де-факто в управлении контейнерами. Сейчас на K8s работает множество различных сложных микросервисных приложений. И для их грамотного функционирования важно правильно выполнить настройки безопасности в данной среде оркестрации.
В состав Kubernetes входит несколько основных компонентов. Это распределенное хранилище данных etcd, kube-scheduler, kube-controller-manager и kube-api-server. Вот о последнем мы и поговорим в сегодняшней статье.
Привет, Хабр! С вами Матвей Мочалов, и сегодня у нас небольшая лабораторная работа. Вспомним, что GPU нужны не только для нейронок и AI — еще они могут ускорять много других полезных задач. А конкретно мы сравним разницу в скорости между работой FFmpeg на процессоре и на видеокарте Nvidia.
В ролях у нас гибридный ноутбук под Linux с мобильной видеокартой RTX 3050Ti и процессором Ryzen 5 5600H. Также в массовке участвует удалённый тестовый сервер с Xeon и заглушкой в PCI слот, которую дядя Дженсен Хуанг решил по доброте сердечной добавить в линейку Quadro.
Podman – один из множества инструментов для контейнеризации. Но в отличие от Docker, используется он не часто, даже в тестировании или хотя бы pet-проектах.
При этом, в мире программного обеспечения, чем новее игрушка и чем больше плюшек она обещает относительно предшественников, тем сильнее она облеплена вниманием. Особенно, если заявлена более высокая безопасность из коробки.
Но Podman, будучи на 4 года младше Docker, а также, в теории, фундаментально безопаснее, подобного приёма не получил. Быть может, он его всё-таки заслуживает?
Возможно, к ужасу ваших DevOps и SRE-инженеров вам стоит уже сейчас бежать и громить выстроенные пайплайны оркестрации кластеров Docker-контейнеров, чтобы менять всё на Podman?!
Использование искусственного интеллекта позволяет существенно увеличить эффективность работы различных средств обеспечения кибербезопасности.
Сегодня мы попробуем решить задачу обнаружения использования вредоносного программного обеспечения злоумышленником. Для этого мы сначала еще немного поговорим об информационной безопасности, а потом уже перейдем к реализации на Python.
Вредоносное программное обеспечение может использоваться хакерами для: кражи данных, шифрования файлов с целью получения выкупа, обхода средств защиты, нарушения контроля доступа и многого другого.
Собственно, вредоносное ПО это не только пресловутые вирусы, но и различные хакерские инструменты, например знаменитый Metasploit Framework, который хотя и предназначен для проведения тестирований на проникновение белыми хакерами, тем не менее активно используется и обычными взломщиками.
Продолжим тему использования искусственного интеллекта в кибербезопасности. Сегодня мы не будем много говорить о проблемах инфобеза. Нашей задачей будет разобраться с машинным обучением и тем, как его можно использовать.
Этапы машинного обучения
Общий подход к решению задач машинного обучения состоит из четырех основных этапов: анализа, обучения, тестирования и применения.
Сейчас вряд ли можно найти такую отрасль, в которой не использовался бы Искусственный Интеллект. Конечно, не везде ИИ действительно эффективен, и зачастую, используемые технологии еще нуждаются в существенной доработке. Но в ИТ есть целый ряд направлений, в которых ИИ уже давно эффективно используется.
О пользе ИИ в ИТ
Прежде всего это системы распознавания лиц, позволяющие идентифицировать людей по цифровым изображениям, распознавая черты лица. Собственно системы идентификации тоже являются частью систем безопасности и в определенной степени подходят под тематику данной статьи.
Еще одно распространенное направление использования ИИ — это обнаружение фейковых новостей. Детекторы фейков используют семантические и стилистические особенности текста в статье, источник статьи и т.д., чтобы отличать фейковые новости от достоверных.
Рекомендательные системы, используемые на различных ресурсах, способны оценить выбор клиента на основе таких факторов как личная история, предыдущий выбор, сделанный клиентом и другие параметры.
В целом искусственный интеллект используется в ИТ достаточно эффективно и самое время поговорить о том, как можно использовать ИИ для решения различных задач кибербезопасности. Далее мы погрузиться в саму проблематику информационной безопасности и тех вопросов, которые можно решать с помощью искусственного интеллекта.
Привет, Хабр! С вами Матвей Мочалов. В этом посте я хочу кратко затронуть тему того, без чего не обходится любой стриминговый сервис от соцсетей до онлайн‑кинотеатров — о транскодировании.
Операторы в кино и блогеры в погоне за красивой картинкой в исходном виде готовы пойти на любые жертвы, используя наиболее быстрые и объёмные накопители. А также немалые вычислительные мощности, чтобы это всё банально воспроизвести. Но подобный подход, увы, слабо совместим с доставкой видеоконтента через интернет, особенно, если вы хотите, чтобы это было коммерчески выгодным. А если в один момент его потребляют миллионы пользователей, тогда ещё и под их потребности необходимы разные версии в различных разрешениях, с разной частотой кадров, озвучкой и т. д.
Чтобы улучшить положение, исходный контент подвергается облегчению посредством транскодирования. Как по своему объёму, так и по нагрузке, требуемой для его воспроизведения на клиентском устройстве.
Привет, Хабр! Меня зовут Матвей Мочалов, я — компьютерный инженер и один из авторов корпоративного блога cdnnow! Мы с вами познакомились в этом посте про историю DRM для видеоконтента. Сегодня я хочу поговорить с вами про Docker, а точнее про то, о чём многие забывают: различиях в нём для разных систем. Нам, как CDN-провайдеру Docker, все его 50 оттенков близки и знакомы. И, к счастью, наше взаимодействие с ним происходит из-под Linux, но, увы, не всем так везёт.
Как это часто бывает, с мультиплатформенностью и прочими «красивыми» словами в IT, всё не так однозначно. У всего своя цена, и под капотом один и тот же инструмент на разных системах, по сути своей может представлять из себя несколько разных вещей с различными принципами работы и производительностью. А обещания революции скрывают за собой эволюцию, либо вовсе регресс и топтание на месте.
Привет, Хабр! Меня зовут Матвей Мочалов, я — компьютерный инженер по образованию и технический писатель у cdnnow!. А также я люблю историю, особенно — историю технологий.
Разные формы потокового видеоконтента присутствуют в нашей жизни уже больше века. От монохромной и беззвучной аналоговой передачи до современных подписочных сервисов, просматриваемых вечером под пледом. И одним из главных двигателей этой эволюции технологий, как и в природе, являлось противостояние двух сторон: хищник и жертва, правообладатели и пираты. На примере событий, показавшихся мне наиболее интересными, я покажу, как развивалась эта гонка вооружений.
В нашей компании мы тоже своего рода учёные, так как имеем свой сервис Multi‑DRM для видеоконтента и являемся участниками этой вечной битвы. Так что и нам самим интересно — как мы до всего это доплыли? Разберём все: от появления потоковой передачи, как концепта, до современности с цифровой DRM‑защитой для трансляций и онлайн‑кинотеатров.
