• Почему tar.xz-файлы, созданные с Python tar, оказались в 15 раз меньше, чем у macOS tar

    • Translation

    Прим. перев.: это не совсем обычный перевод, потому что в его основе не отдельно взятая статья, а недавний случай со Stack Exchange, ставший главным хитом ресурса в этом месяце. Его автор задает вопрос, ответ на который можно отнести к базовым знаниям в области ИТ, но в то же время оказавшийся откровением для некоторых посетителей сайта.

    Сжимая каталоги по ~1,3 ГБ, в каждом из которых по 1440 файлов JSON, я обнаружил 15-кратную разницу между размером архивов, сжатых с помощью tar на macOS или Raspbian 10 (Buster), и архивов, полученных при использовании библиотеки tarfile, встроенной в Python.

    Читать далее
  • Угон домена Perl.com

    • Translation

    Прим. перев.: в конце января стало известно о том, что один из основных доменов языка программирования Perl — Perl.com — был угнан. Это вызвало смешанную реакцию в сообществе как любителей языка, так и его противников. Теперь, когда всё уже позади и справедливость восстановлена, один из самых известных сторонников Perl — brian d foy — рассказал о том, что же произошло и как сообщество добилось положительного исхода событий. Представляем вниманию перевод его заметки.

    Читать далее
  • Kubernetes — это как океанариум

    • Translation

    Прим. перев.: в конце прошлого года Anne LoVerso — инженер из VMware Pivotal Labs — опубликовала развернутое сравнение Kubernetes с… океанариумом. Эта небольшая статья с наглядными иллюстрациями и аналогиями ориентирована на тех, кто впервые знакомится с K8s, и призвана упростить их самое первое погружение в дебри океана… оркестратора.

    Читать далее
    • +51
    • 10.4k
    • 1
  • Обратная сторона Open Source-славы: как угрожают автору curl

    • Translation

    Прим. перев.: уникальная история, что всколыхнула интернет в эти дни, показывает неожиданную сторону того, что могут «заслужить» авторы самых популярных Open Source-проектов. Ниже представлен перевод недавней заметки из блога шведского программиста Daniel Stenberg — оригинального автора и главного разработчика curl, обладателя премии Polhem Prize (вручается в Швеции за выдающиеся инженерные достижения).

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

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

    Увы, не все эти письма забавны.

    Читать далее
  • Headlamp — новый GUI для работы с Kubernetes

    • Translation
    Прим. перев.: месяц назад компания Kinvolk выпустила свой интерфейс для управления Kubernetes-кластерами. Новый Open Source-проект, пополнив уже немалочисленные ряды подобных решений, сочетает в себе классический подход к дизайну интерфейсов, возможность запуска локально и внутри кластера, а также высокую расширяемость, что — вместе с достаточно богатым набором функций — делает его интересным хотя бы для первичного знакомства. В этом анонсе его авторы рассказывают, почему Headlamp стал именно таким.



    Читая материалы по Kubernetes, вы наверняка неоднократно сталкивались с примерами различных kubectl-команд и хитрых конфигов на YAML. У людей, хорошо разбирающихся в K8s, такой подход, без сомнения, не вызывает никакого отторжения. Но в век повсеместного распространения веб-интерфейсов его нельзя назвать дружественным к обычным пользователям. Он усложняет процесс познания для новичков и выступает барьером для тех, кто не особо хорошо знаком с Kubernetes.

    Конечно, существуют различные графические интерфейсы для K8s, в том числе Kubernetes Dashboard, являющийся частью самого upstream Kubernetes. (Прим. перев.: О многих из существующих решений мы уже рассказывали в этом сравнении.) Однако, исследуя все многообразие вариантов, мы не сумели подобрать решение, которое бы полностью нас устраивало.
    Читать дальше →
    • +32
    • 6.4k
    • 4
  • Не паникуйте: Kubernetes и Docker

    • Translation
    Прим. перев.: свежая публикация в блоге Kubernetes — оперативный ответ на ту шумиху, что поднялась вокруг грядущего релиза K8s, в котором поддержка Docker будет объявлена устаревшей. Представляем вашему вниманию её перевод.



    Начиная с версии v1.20, Kubernetes отказывается от Docker как от исполняемой среды контейнеров.

    Но не паникуйте. Не все так страшно, как представляется на первый взгляд.

    TL;DR. Kubernetes отказывается от Docker в пользу сред выполнения на базе Container Runtime Interface (CRI), разработанного специально для Kubernetes. Образы для Docker продолжат работать во всех средах выполнения как обычно.
    Читать дальше →
  • Post Mortem по масштабному сбою Amazon Kinesis в US-EAST-1 (25 ноября)

    • Translation
    Прим. перев.: на прошлой неделе сбой одного из сервисов AWS привёл к проблемам в доступности/корректном функционировании целого ряда облачных услуг этого крупного провайдера. В официальной публикации, оперативно размещённой инженерами интернет-компании, рассказывается о подробностях инцидента, его причинах и — главное — уроках, которые были извлечены из случившегося. Представляем вашему вниманию её перевод.

    В этом материале мы хотели бы рассказать подробности о перебоях в обслуживании, случившихся в регионе Northern Virginia (US-EAST-1) 25 ноября 2020.

    Amazon Kinesis позволяет в реальном времени собирать, обрабатывать и анализировать потоковые данные. Помимо непосредственного использования клиентами, он задействован в ряде сервисов AWS. Эти сервисы также пострадали от сбоя. Триггером (но не основной причиной) данного события стало относительно небольшое добавление мощностей к сервису, начавшееся в 2:44 утра PST и завершившееся в 3:47.
    Читать дальше →
  • Как в Smarkets улучшили мониторинг для своих Kubernetes-кластеров

    • Translation
    Прим. перев.: автор этой статьи — ведущий инженер по инфраструктуре в Smarkets, что позиционирует себя как «одну из самых прибыльных [по доходам на каждого сотрудника] компаний в Европе». Работая с большой и чувствительной к мониторингу инфраструктурой на базе Kubernetes, инженеры компании нашли своё счастье с VictoriaMetrics, которая помогла им решить проблемы с Prometheus, возникшие после добавления новых K8s-кластеров.

    Мониторинг внутренних endpoint'ов и API Kubernetes может быть проблематичным, особенно если стоит задача использовать автоматизированную инфраструктуру как сервис. Мы в Smarkets еще не достигли этой цели, но, к счастью, уже довольно близки к ней. Я надеюсь, что наш опыт в этой области поможет и другим реализовать нечто подобное.

    Мы всегда мечтали о том, чтобы разработчики прямо «из коробки» получали возможность мониторинга для любого приложения или сервиса. До перехода на Kubernetes эта задача выполнялась либо с помощью метрик Prometheus, либо с помощью statsd, который пересылал статистику на базовый хост, где она конвертировалась в метрики Prometheus. Наращивая применение Kubernetes, мы начали разделять кластеры, и нам захотелось сделать так, чтобы разработчики могли экспортировать метрики напрямую в Prometheus через аннотации к сервисам. Увы, эти метрики были доступны только внутри кластера, то есть их нельзя было собирать глобально.

    Эти ограничения стали «бутылочным горлышком» для нашей конфигурации, существовавшей до полного перехода на Kubernetes. В конечном итоге они заставили пересмотреть архитектуру и способ мониторинга сервисов. Как раз об этом путешествии и пойдет речь ниже.
    Читать дальше →
    • +26
    • 2.6k
    • 1
  • Загадочная ситуация с TIME в MySQL

    • Translation
    Прим. перев.: Этот детальный анализ одной, казалось бы, не очень значительной детали в реализации внутри MySQL вызвал закономерные дискуссии о правильности в подходах к разработке известного Open Source-проекта в целом. О том, что же, собственно, выяснил португальский инженер, он повествует в формате, приближенном к детективу…

    Многие в 2020 году стали жертвой странного феномена восприятия времени, но некоторые системы управления базами данных манипулируют временем гораздо дольше. Впервые я обратил на это внимание, когда мой друг в одном из своих проектов (Accord — популярный бот для Discord) столкнулся со следующим исключением от коннектора MySQL при использовании с EF Core:

    MySqlException: Incorrect TIME value: '960:00:00.000000'

    Будучи не слишком сведущим в MySQL (т.к. предпочитаю PostgreSQL по причинам, которые скоро станут очевидными), я на секунду подумал, что неправильным здесь является число часов. Разумно предположить, что значения TIME ограничены 24 часами или что для значений, охватывающих нескольких дней, требуется другой синтаксис — например, 40:00:00:00 будет представлять 40 дней. Но действительность оказалась куда сложнее и запутаннее.
    Читать дальше →
    • +35
    • 4.1k
    • 4
  • Наши выводы за год миграции GitLab.com на Kubernetes

    • Translation
    Прим. перев.: адаптацию Kubernetes в GitLab считают одним из двух главных факторов, способствующих росту компании. Тем не менее, до недавнего времени инфраструктура онлайн-сервиса GitLab.com была построена на виртуальных машинах, и только около года назад началась её миграция в K8s, которая до сих пор не завершена. Рады представить перевод недавней статьи SRE-инженера GitLab о том, как это происходит и какие выводы делают инженеры, участвующие в проекте.



    Вот уже около года наше инфраструктурное подразделение занимается миграцией всех сервисов, работающих на GitLab.com, в Kubernetes. За это время мы столкнулись с проблемами, связанными не только с перемещением сервисов в Kubernetes, но и с управлением гибридным deployment'ом во время перехода. О ценных уроках, полученных нами, и пойдет речь в этой статье.
    Читать дальше →
    • +36
    • 9.4k
    • 3
  • 3 года с Kubernetes в production: вот что мы поняли

    • Translation
    Прим. перев.: в очередной статье из категории «lessons learned» DevOps-инженер австралийской компании делится главными выводами по итогам продолжительного использования Kubernetes в production для нагруженных сервисов. Автор затрагивает вопросы Java, CI/CD, сетей, а также сложности K8s в целом.

    Свой первый кластер Kubernetes мы начали создавать в 2017 году (с версии K8s 1.9.4). У нас было два кластера. Один работал на bare metal, на виртуальных машинах RHEL, другой — в облаке AWS EC2.

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

    В конечном итоге Kubernetes упростил нам жизнь, однако путь к этому был тернистым и требовал полной смены парадигмы. Произошла тотальная трансформация не только набора навыков и инструментов, но и подхода к проектированию, мышления. Нам пришлось осваивать множество новых технологий и вкладывать значительные средства в развитие инфраструктуры и повышение квалификации команд.
    Читать дальше →
  • Анонс иерархических пространств имен для Kubernetes

    • Translation
    Прим. перев.: недавно в блоге Kubernetes был представлен проект «иерархических пространств имён». Формально он существует с конца прошлого года, но именно теперь авторы сочли уместным анонсировать свой Hierarchical Namespace Controller (HNC) для массовой аудитории. О предназначении и деталях реализации — читайте в этом материале, который мы также дополнили переводом дорожной карты HNC.



    Безопасно разместить большое число пользователей в одном кластере Kubernetes всегда было непросто. Главная причина в том, что все организации используют Kubernetes по-разному, поэтому единая мультипользовательская модель вряд ли всем подойдет. Вместо этого Kubernetes предлагает компоненты для создания собственного решения, такие как управление доступом на основе ролей (RBAC) и NetworkPolicies; чем лучше эти компоненты, тем легче построить безопасный многопользовательский кластер.
    Читать дальше →
  • Post Mortem по недоступности Quay.io

    • Translation
    Прим. перев.: в начале августа Red Hat публично рассказала о решении проблем доступности, что возникали в предыдущие месяцы у пользователей её сервиса Quay.io (в его основе — реестр для образов контейнеров, доставшийся компании вместе с покупкой CoreOS). Вне зависимости от вашей заинтересованности в этом сервисе как таковом, поучителен сам путь, по которому прошли SRE-инженеры компании для диагностики и устранения причин аварии.



    19 мая, ранним утром (по летнему североамериканскому восточному времени, EDT), сервис quay.io упал. Авария затронула как потребителей quay.io, так и Open Source-проекты, использующие quay.io в качестве платформы для сборки и распространения ПО. Red Hat дорожит доверием как одних, так и других.

    Команда SRE-инженеров сразу подключилась к работе и постаралась как можно скорее стабилизировать работу сервиса Quay. Однако пока они этим занимались, клиенты лишились возможности push’ить новые образы, и лишь периодически им удавалось pull’ить имеющиеся. По неведомой причине база данных quay.io блокировалась после масштабирования сервиса на полную мощность.
    Читать дальше →
    • +25
    • 4.2k
    • 3
  • Open Service Mesh — новая service mesh для Kubernetes от Microsoft



      Вчера состоялся анонс очередного Open Source-решения класса service mesh — Open Service Mesh (OSM). Проект был представлен Michelle Noorali, что занимает должность Senior Software Engineer в команде Azure Cloud Native Compute компании Microsoft, а также входит в состав руководства организации CNCF.
      Читать дальше →
    • Будущее Prometheus и экосистемы проекта (2020)

      • Translation
      Прим. перев.: это перевод статьи, подготовленной по мотивам недавнего выступления Richard Hartmann — заметного представителя команды разработчиков Prometheus, директора по сообществам из Grafana Labs, основателя проекта OpenMetrics и председателя группы SIG Observability в CNCF. Автор подводит итоги последнего года в жизни Open Source-проекта (и сообщества) Prometheus, а также рассказывает об основных трудностях и ближайших перспективах.



      Во время PromCon Online 2020 я выступил с докладом под названием «Будущее Prometheus и его экосистемы». И хочу поделиться с вами его ключевыми моментами.
      Читать дальше →
    • Когда дело не только в уязвимости в Kubernetes…

      • Translation
      Прим. перев.: авторы этой статьи в подробностях рассказывают о том, как им удалось обнаружить уязвимость CVE-2020–8555 в Kubernetes. Хотя изначально она и выглядела не очень опасной, в сочетании с другими факторами её критичность у некоторых облачных провайдеров оказалась максимальной. За проведённую работу специалистов щедро вознаградили сразу несколько организаций.



      Кто мы такие


      Мы — два французских исследователя в области безопасности, которые совместно обнаружили уязвимость в Kubernetes. Нас зовут Brice Augras и Christophe Hauquiert, но на многих Bug Bounty-платформах мы известны как Reeverzax и Hach соответственно:

      Читать дальше →
      • +27
      • 4.5k
      • 1
    • Состояние и производительность решений для постоянного хранения данных в Kubernetes

      • Translation
      Прим. перев.: хотя этот обзор не претендует на статус тщательно проработанного технического сравнения существующих решений для постоянного хранения данных в Kubernetes, он может стать хорошей отправной точкой для администраторов, которым актуален данный вопрос. Наибольшего внимания здесь удостоилось решение Piraeus, знакомство с которым пойдет на пользу не только любителям Linstor, но и тем, кто об этих проектах ещё не слышал.



      Это ненаучный обзор решений для хранения данных для Kubernetes. Постановка задачи: требуется возможность создания Persistent Volume на дисках узла, данные которого будут сохранны в случае повреждения или перезапуска узла.

      Мотивация для проведения этого сравнения — потребность миграции серверного парка компании со множества выделенных bare metal-серверов в кластер Kubernetes.
      Читать дальше →
      • +36
      • 6.6k
      • 5
    • AWS представила свою ОС для запуска контейнеров — Bottlerocket

        Вчера в блоге облачного провайдера AWS была представлена новая операционная система на базе Linux, предназначенная для запуска контейнеров, — Bottlerocket.



        Новый проект позиционируется как «операционная система с открытым кодом, основанная на Linux и созданная для использования в Amazon Web Services с целью запуска контейнеров на виртуальных машинах или железных серверах». Исходный код Bottlerocket доступен на GitHub на условиях свободных лицензий (MIT и Apache 2.0).
        Читать дальше →
      • Docker передает cnab-to-oci в проект CNAB… и что вообще такое CNAB?

        • Translation
        Прим. перев.: Эта статья — перевод недавнего анонса из мира контейнеров. В прошлом месяце компания Docker объявила о передаче своей очередной разработки в руки более широкого Open Source-сообщества. Речь шла об инструменте конвертации метаданных CNAB-пакета в формат стандарта OCI (Open Container Initiative) — для удобной возможности распространения содержимого таких пакетов в реестрах для контейнеров (вроде Docker Registry). Но чтобы получше во всём этом разобраться, мы начнём с перевода другой заметки (написанной Jack Wallen для The New Stack) — о том, что вообще такое CNAB.



        Что такое CNAB и почему он важен для экосистемы cloud native?


        Cloud Native Application Bundle (CNAB) — открытая спецификация, цель которой — упростить упаковку, установку контейнеризированных приложений и управление ими. С помощью таких пакетов пользователи могут определять ресурсы, которые затем разворачиваются в различных runtime-средах, таких как Docker, Azure, Kubernetes, Helm, службы автоматизации (например, используемые в GitOps) и т.д.
        Читать дальше →
        • +38
        • 3.5k
        • 1