Рубрика «devops» - 69

Знакомство с Helm 3 - 1

Прим. перев.: 16 мая этого года — значимая веха в развитии менеджера пакетов для Kubernetes — Helm. В этот день был представлен первый альфа-релиз будущей крупной версии проекта — 3.0. Её выход принесёт в Helm существенные и долгожданные изменения, на которые многие в Kubernetes-сообществе возлагают большие надежды. К таковым относимся и мы сами, поскольку активно используем Helm для деплоя приложений: мы интегрировали его в свой инструмент для реализации CI/CD werf и от случая к случая вносим посильный вклад в развитие upstream. Этот перевод объединяет 7 заметок из официального блога Helm, что приурочены к первому альфа-релизу Helm 3 и рассказывают об истории проекта и основных фичах Helm 3. Их автор — Matt «bacongobbler» Fisher, сотрудник Microsoft и один из ключевых мейнтейнеров Helm.Читать полностью »

GitLab 11.11: несколько ответственных для мердж-реквестов и улучшения для контейнеров - 1

Больше возможностей для совместной работы и дополнительные уведомления

Мы в GitLab постоянно ищем новые способы улучшить совместную работу по всему жизненному циклу DevOps. Мы с радостью объявляем, что с этого выпуска поддерживаем несколько ответственных лиц для одного мердж-реквеста! Эта функция доступна с уровня GitLab Starter и по-настоящему воплощает наш девиз: «Каждый может внести свой вклад». Мы знаем, что с одним мердж-реквестом может работать много людей, чтобы все точно было в порядке, и теперь у вас есть возможность назначать несколько ответственных за мердж-реквесты!

А еще команды DevOps теперь получают автоматические уведомления о событиях деплоя в Slack и Mattermost. Добавьте новые уведомления в список событий отправки в этих двух чатах, и ваша команда будет почти моментально узнавать о новых деплоях.

Сокращение издержек с поддержкой контейнеров Docker в Windows и подготовкой кластеров Kubernetes на уровне экземпляра

Читать полностью »

Прим. перев.: Достойной внимания оказалась самая популярная публикация сабреддита /r/DevOps за последний месяц: «Автоматизация официально заменила меня на работе — ловушка для DevOps'ов». Её автор (из США) поведал свою историю, которая воплотила в жизнь популярную присказку о том, что автоматизация убьёт потребность в тех, кто поддерживает программные системы.

Как специалист по DevOps стал жертвой автоматизации - 1
Пояснение на Urban Dictionary к уже ставшей устойчивой(?!) фразе про замену человека на скриптЧитать полностью »

В преддверии DevOpsConf Виталий Хабаров взял интервью у Дмитрия Столярова (distol), технического директора и соучредителя компании «Флант». Виталий расспросил Дмитрия про то, чем занимается «Флант», про Kubernetes, развитие экосистемы, поддержку. Обсудили, зачем нужен Kubernetes и нужен ли вообще. А еще про микросервисы, Amazon AWS, подход «Мне повезет» в DevOps, будущее самого Kubernetes, почему, когда и как он захватит мир, перспективы DevOps и к чему готовиться инженерам в светлом и близком будущем с упрощением и нейросетями.

Оригинал интервью в виде подкаста послушайте на DevOps Дефлопе — русскоязычном подкасте о DevOps, а ниже — текстовая версия.

Kubernetes захватит мир. Когда и как? - 1

Здесь и далее вопросы задает Виталий Хабаров инженер из Express42.
Читать полностью »

Интеграция Kubernetes Dashboard и пользователей GitLab - 1

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

В интернете куча статей о сервис-мешах (service mesh), и вот ещё одна. Ура! Но зачем? Затем, что я хочу изложить своё мнение, что лучше бы сервис-меши появились 10 лет назад, до появления контейнерных платформ, таких как Docker и Kubernetes. Я не утверждаю, что моя точка зрения лучше или хуже других, но поскольку сервис-меши — довольно сложные животные, множественность точек зрения поможет лучше их понять.

Я расскажу о платформе dotCloud, которая была построена на более чем сотне микросервисах и поддерживала тысячи приложений в контейнерах. Я объясню проблемы, с которыми мы столкнулись при её разработке и запуске, и как сервис-меши могли бы помочь (или не могли).
Читать полностью »

Бенчмарк потребления ЦП для Istio и Linkerd - 1

Введение

Мы в Shopify занялись развертыванием Istio в качестве service mesh. В принципе все устраивает, кроме одной вещи: это дорого.

В опубликованных бенчмарках для Istio говорится:

С Istio 1.1 прокси потребляет примерно 0,6 vCPU (виртуальных ядер) на 1000 запросов в секунду.

Для первого региона в service mesh (по 2 прокси с каждой стороны соединения) у нас будет 1200 ядер только для прокси, из расчета один миллион запросов в секунду. Согласно калькулятору стоимости от Google получается примерно $40/месяц/ядро для конфигурации n1-standard-64, то есть один этот регион будет стоить нам больше 50 тыс. долларов в месяц за 1 млн запросов в секунду.

Айвен Сим (Ivan Sim) наглядно сравнил задержки service mesh в прошлом году и обещал то же самое для памяти и процессора, но не получилось:

Судя по всему, values-istio-test.yaml серьезно увеличит запросы к процессору. Если я все правильно посчитал, нужно примерно 24 процессорных ядра для панели управления и 0,5 ЦП для каждого прокси. У меня столько нету. Я повторю тесты, когда мне выделят больше ресурсов.

Я хотел сам убедиться, насколько показатели Istio схожи с другой service mesh с открытым кодом: Linkerd.

Читать полностью »

В минувшую субботу, 18 мая, Jerry Gamblin из Kenna Security проверил 1000 самых популярных образов с Docker Hub на используемый в них пароль для пользователя root. В 19% случаев он оказался пустым.

В 19% популярнейших Docker-образов нет пароля для root - 1Читать полностью »

Сейчас на хайпе тема DevOps. Конвейер непрерывной интеграции и доставки CI/CD внедряют все, кому не лень. Но большинство не всегда уделяют должное внимание обеспечению надежности работы информационных систем на различных этапах CI/CD Pipeline. В данной статье я хотел бы поговорить о своем опыте автоматизации проверок качества ПО и реализации возможных сценариев по его «самовосстановлению».

Continuous Monitoring – автоматизация проверок качества ПО в CI-CD Pipeline - 1

Источник
Читать полностью »

Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования - 1
Данной заметкой продолжается

цикл о резервном копировании

  1. Резервное копирование, часть 1: Зачем нужно резервное копирование, обзор методов, технологий
  2. Резервное копирование, часть 2: Обзор и тестирование rsync-based средст резервного копирования
  3. Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicaty, deja dup
  4. Резервное копирование, часть 4: Обзор и тестирование zbackup, restic, borgbackup
  5. Резервное копирование, часть 5: Тестирование bacula и veeam backup for linux
  6. Резервное копирование, часть 6: Сравнение средств резервного копирования
  7. Резервное копирование, часть 7: Выводы

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

Из тех, что больше всего подходят под наши условия, я буду рассматривать 3: rdiff-backup, rsnapshot и burp.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js