Помните, как всего лишь несколько лет назад было обидно потерять фотоаппарат или камеру в конце отпуска? Все памятные кадры и видеоролики тогда исчезали вместе с утерянным устройством. Вероятно, именно этот факт подтолкнул великие умы к изобретению облачных хранилищ, чтобы сохранность записей больше не зависела от сохранности устройств, на которых эти записи сделаны.
Данная статья является четвертой в цикле (1, 2, 3), посвященном изучению исходного кода Docker и прямым продолжением предыдущей статьи, которую мне пришлось преждевременно завершить в виду зависания редактора хабра. В этой статье мы закончим изучать код первого публичного релиза Docker v0.1.0. Будут рассмотрены оставшиеся команды по управлению контейнерами, сетевой стек, а также создание образа и запуск контейнера.
Фото Bertrand Bouchez, Unsplash.com
В прошлой статье мы с помощью Prometheus AlertManager настроили правила, чтобы отправлять уведомления через Slack при срабатывании алертов. И хотя алерты и уведомления — это удобно и полезно, сами по себе метрики не до конца объясняют проблему. Они просто показывают, что значения одного экземпляра вышли за установленные лимиты, но в распределённых системах метрики не могут отследить запрос, который проходит через несколько компонентов. С распространением микросервисов системы усложняются, поэтому мы должны проследить весь путь запроса, чтобы понять, что пошло не так. Для этого можно использовать распределённую трассировку, которая записывает действия, выполняемые в связи с запросом, и дает контекст, который мы не найдем в метриках и логах.
В этой статье мы расширим возможности observability (наблюдаемости) приложения — создадим спаны (span) и экспортируем их в распределённую опенсорс-систему Jaeger. Но сначала разберемся, что такое трейс.
Данная статья является третьей в цикле (1,2), посвященном изучению исходного кода Docker и прямым продолжением предыдущей статьи, в которой мы начали разбирать код первого публичного релиза Docker v0.1.0. В этой части будет рассмотрена реализация практически всех команд, а в конце, мы создадим образ и запустим докер контейнер на его основе. Для удобства я постарался разбить список команд на условные группы: работа с образами, работа с контейнерами, сетевой стек и т.д.
А теперь, как говорится, “without further ado”, приступим к изучению кода из файла commands.go начиная с команд для управления образами (images).
Это расшифровка выступления на T-Meetup: DevOps Life Cycle.
Осмелюсь предположить, что многие слышали про SDLC (Systems development life cycle). Но что, если все то же самое происходит с IaC?
Приложения и промежуточное ПО упакованы как операторы и доступны на OperatorHub. Хотя большинство операторов можно установить за несколько кликов, для некоторых, более сложных операторов, требуется более глубокое понимание инфраструктуры. Это похоже на воду для кухонного слива, большинству людей просто достаточно знать, что она есть; тем не менее, знание того, что находится там внутри, в водопроводе, необходимо для решения проблем и исправления ошибок, когда что-то работает не так, как ожидалось.
Эта статья пытается объяснить основные объекты и процессы, составляющие операторов и структуру операторов. Содержание этой статьи разделено на расширение OperatorHub и развертывание Оператора.
Мы продолжаем разбирать варианты нагрузочных тестов. В этой статье мы разберем методику тестирования и проведем нагрузочный тест, с помощью которого попытаемся определить число пользователей, которые одновременно будут и зрителями, и стримерами, т.е. каждый пользователь и публикует, и просматривает потоки.
Когда я начал работу с Kubernetes, и Infrastructure as Code (IaC), я быстро понял, что мне нужно решение для работы с секретами. Когда я поискал в интернете, то не увидел единого мнения по поводу практического подхода к проблеме, подходящего ко всем ситуациям. Поэтому, в этом году, я поставил себе задачу изучить, какие решения для управления секретами приложения и инфраструктуры существуют, решить, которое из них я считаю лучшим и освоить его. В конце исследования, я пришел к выводу, что HashiCorp Vault перехвален, а Mozilla SOPS с KMS и Git неоправданно недооценены.
Данная статья является второй, в цикле по истории развития и изучению исходного кода Docker. В ней мы разберем, что представлял собой первый публичный релиз от 23 марта 2013 года.
Изначально я планировал уложить весь материал, посвященный этой версии, в одной статье, но в процессе стало ясно, что она получается слишком большой, поэтому я решил разделить ее на две. В текущей части (2.1) будет рассмотрена лишь общая структура и начальный код, а последующая часть (2.2) будет посвящена принципу работы и коду конкретных команд.
Некоторые части кода уже были разобраны в первой статье, так что для полноты восприятия, рекомендую начать с нее, а также пятиминутной презентации The Future of Linux Containers, на которой и была представлена первая версия Docker.
Популярность Kubernetes растет, порог входа снижается, но вопросам безопасности порой оказывают недостаточное внимание. В этой статье разберём работу двух Open Source-утилит для аудита безопасности кластера от известных экспертов этой области — Aqua Security.
Инструкция была основана на базе видео "Установка кластера Kubernetes с помощью Kubespray" в Youtube.
Код был форкнут из репозитория https://git.cloud-team.ru/lections/kubernetes_setup и добавлен с патчами в репозиторий https://github.com/patsevanton/kubespray_terraform_yandex_cloud
Самое интересное в этом посте для devops специалистов с опытом это скрипт для создания ansible inventory файла из terraform структур.
В этой статье мы рассмотрим, как более-менее прилично организовать процесс тестирования и публикации чартов, встреченные при этом подводные камни, а также рассмотрим пару великолепных инструментов, которые совершенно незаслуженно получили крайне мало внимания не только на Хабре, но и вообще в русскоязычном сегменте интернета.
Очень кстати, в недавно вышедшем релизе Gitlab 14.1, появился долгожданный функционал хранения Helm-чартов во встроенном Package Registry. Отлично, заодно и разберемся, как его использовать.
Kubernetes используют так или иначе сейчас примерно все, но и задачи решаются совсем разные. Я расскажу про наши требования и разработанные под них решения для управления множеством кластеров. По теме GitOps не так много статей и обсуждений на Хабре, в отличие от англоязычных источников, поэтому будет интересно и услышать мнение тех, кто применял подход на своей практике.
Эта статья продолжает цикл статей о нагрузочных тестах нашего сервера. Мы уже рассмотрели, как собирать метрики, как на основе этих метрик подбирать оборудование и сравнили способы тестирования. Сегодня посмотрим, как ведет себя сервер при работе с микшированием потоков.
Первая часть вышла более двух месяцев назад.
После второй с сайта убрали Яндекс.Метрику.
Надеюсь, после третьей приведут инфраструктуру в порядок.
Infrastructure as Code — ключевой элемент наиболее эффективных инженерных сетапов. То, как сейчас DevOps-инженеры взаимодействуют со своей инфраструктурой — это несомненно большой скачок вперед. Но тем не менее спорные моменты с определением и лучшими практиками IaC до сих пор есть. Эта статья стремится четко описать IaC, его преимущества и важные ограничения.
Infrastructure as Code, или сокращенно IaC, — это фундаментальный сдвиг не только для Ops в том, как они подходят к провизионированию и обслуживанию инфраструктуры, но и в разработке программного обеспечения в целом. Несмотря на то, что за последние несколько лет IaC де-факто зарекомендовал себя как отраслевой стандарт, многие до сих пор спорят о его определении, лучших практиках и ограничениях.
В этой статье вы познакомитесь с эволюцией этого подхода к инфраструктуре рабочих процессов и связанных с ним технологий. Мы объясним, откуда появился IaC, перспективы его развития, его преимущества и его главные ограничения.
Предыстория: выбирали сертифицированное облако для всякой там сертифицированной жизни. Остановились на кое-каком B2B-колоссе, руководство заключило договор, и отделу SRE пришлось работать с облаком на основе VMware vCloud Director. И, как подобает секте свидетелей Infrastructure as Code, хотелось поменьше сидеть в веб-морде облака и больше -- в конфигурациях какого-нибудь Ansible и Terraform.
Эта статья - плод нескольких вечеров девопсера и бог знает скольких дней и ночей CTO. По горячим следам, поэтому, возможно, она несколько скомканная. Тем не менее, если вы столкнулись с облаком на основе vCloud - будет интересно.
20 марта 2013 года на конференции PyCon 2013, Соломон Хайкс (CEO компании dotCloud) выступил с пятиминутной презентацией The future of Linux Containers. В ней широкой общественности впервые была представлена внутренняя разработка компании dotCloud под названием Docker, а спустя несколько дней ее исходный код был выложен в открытый доступ. Хотя технологии LXC и Aufs, на которых была основана первая версия Docker существовали и активно использовались уже порядка пяти лет, но именно появление Docker послужило началом стремительного роста и эволюции систем контейнеризации, что кардинально преобразило многие процессы разработки и деплоймента программного обеспечения.
Этой статьей я собираюсь начать небольшой цикл посвященный изучению развития исходного кода Docker на протяжении нескольких лет. В первой части мы посмотрим на то, что представлял собой код на момент создания git репозитория датированного январем 2013 года. Тогда исходный код Docker (за исключением тестов) состоял всего из шести файлов общим объемом ~600 строк кода, написанных на языке Go. Это больше походило на библиотеку/api, функционал которой состоял лишь в создании, удалении, запуске и остановке контейнеров. Мы разберем принцип работы и даже сможем запустить с ее помощью подготовленный контейнер.
Во второй части мы перенесемся на несколько месяцев вперед - в март 2013, когда докер был представлен на конференции PyCon. На тот момент он уже обладал практически всеми знакомыми нам функциями. А в третьей части я постараюсь рассмотреть переход Docker с LXC на собственную разработку, произошедший годом позже.
Привет! Меня зовут Александр Петровский, я инженер в DINS. Я работаю в команде, которая участвует в разработке сервисов облачной телефонии и видеоконференций для RingCentral. Каждый из них состоит из большого количества микросервисов.
Когда мы мигрировали один из наших микросервисов с CentOS 7 с ядром 4.19 на Oracle Linux 7 с ядром 5.4, мы заметили рост утилизации процессора на наших stress/performance-тестах. В статье я расскажу, как мы исследовали причины роста утилизации процессора сначала в user-space, а потом и в kernel-space и о том, к какому результату это нас привело.
