Статей про Docker много не бывает.
В этом материале мы разберём базу: что такое Docker, как он работает и зачем нужен, а затем пошагово пройдём путь от установки до запуска первого контейнера.
В моих предыдущих статьях я так или иначе сравнивал систему виртуальных машины МФ и подобные виртуальные системы на платформе х86-64. В одной из них я доказывал (безуспешно — статью заминусовали. Правда сколько было плюсов не известно) что хорошая ОС с классическим разделением времени и ресурсов, плюс встроенный в железо микро‑, или милликод для представления сервера набором разделов** аналогичным по всем параметрам всему серверу делают ненужным виртуальные системы.
Вспомнил свой опыт работы с ОС 7 ЕС и несколько изменил свое мнение. Правда при этом вскрылся еще один недостаток виртуальных систем на х86-64, который не позволяет ей считаться настоящей (полной, классической).
Давайте разбираться.
Разрабатываете Ansible роли на macOS с процессорами M1/M2/M3/M4? Тогда вы знаете проблему локального тестирования роли: molecule + vagrant + virtualbox не работает, molecule + vagrant + VMWare через "костыли", а Docker не подходит для тестирования системных компонентов. Я написал драйвер molecule-lima, который использует нативную виртуализацию macOS через Lima и полностью интегрируется со стандартным Molecule workflow. Драйвер реализован на Ansible playbooks, работает на macOS (ARM/Intel) и Linux, устанавливается одной командой pip install molecule-lima.
Привет, Хабр! Меня зовут Артём, и я менеджер продукта РЕД ВРМ. В сегодняшнем материале я расскажу, почему мы всё-таки решили разработать отечественный VDI на базе протокола RED DIRECT, что РЕД ВРМ уже умеет, а чему мы научим его в ближайших редакциях.
Рассказываем о своем опыте ее внедрения в нашу платформу виртуализации SpaceVM.
Современные ИТ-инфраструктуры часто строятся вокруг виртуализации и облаков, где несколько серверов одновременно обращаются к одним и тем же данным. В таких системах ключевым становится не просто объем или скорость хранилища, а способ доступа к данным — общий или локальный, файловый или блочный. От того, как именно организовано взаимодействие с хранилищем, зависит архитектура всего решения: от производительности виртуальных машин до отказоустойчивости кластера.
Локальные хранилища привычны для одиночных серверов: диск или массив принадлежит конкретному узлу, который управляет им напрямую. Общие (shared) хранилища, напротив, предоставляют единое пространство данных для нескольких серверов. Именно они лежат в основе высокодоступных кластеров и виртуализационных платформ, где важно, чтобы виртуальные машины могли мигрировать между узлами без потери доступа к своим дискам.
Но общий доступ — это не только вопрос архитектуры, но и способа взаимодействия с данными. Файловые протоколы (NFS, SMB и др.) дают возможность работать с файлами на уровне операционной системы, но вносят дополнительные задержки и ограничения. Блочные протоколы (iSCSI, Fibre Channel) предоставляют более низкоуровневый доступ — сервер видит удаленное устройство как локальный диск. Однако при этом возникает другая проблема: как синхронизировать работу нескольких узлов с одним и тем же блочным устройством, не разрушив файловую систему?
Ответ на этот вызов дают кластерные файловые системы, специально разработанные для совместного блочного доступа. Одна из самых зрелых и функциональных среди них — GFS2 (Global File System 2). В нашем опыте ее интеграция в собственный продукт - платформу виртуализации SpaceVM - позволила приблизиться к созданию устойчивой, масштабируемой и по-настоящему отказоустойчивой среды.
Привет, Хабр! В статье поговорим о том, почему традиционные методы оценки производительности серверов для 1С не работают в облачной инфраструктуре и как мы нашли решение этой проблемы.
А еще приглашаем вас на бесплатный вебинар 18 ноября в 11:00 мск, где разберем реальные провалы и фатальные ошибки при работе 1С в облаке. Поговорим о том, почему CPU не покажет реальных проблем, расскажем про кейс с дедлоками при нормальных показателях железа и объясним, почему 40% нагрузки должны стать вашим новым максимумом.
Всем зарегистрировавшимся пришлем чек-лист по критическим настройкам 1С из практики обслуживания 7000 пользователей.
Сегодня российский рынок ИТ-инфраструктуры находится на стыке двух мощных трендов: мы наблюдаем все более широкое внедрение облачных и программно-определяемых решений, вместе с тем видим усиливающееся нормативное регулирование со стороны государства. Компании, которые планируют или уже эксплуатируют программно-определяемые центры обработки данных, неизбежно сталкиваются с вопросом аттестации таких решений.
С одной стороны, программные ЦОДы значительно ускоряют бизнес-процессы и упрощают управление инфраструктурой. С другой стороны, российские регуляторы (ФСТЭК России, ФСБ и Росстандарт) предъявляют жесткие требования к обеспечению безопасности, надежности и соответствия национальным стандартам, особенно в сферах, затрагивающих критическую информационную инфраструктуру и обработку персональных данных.
В этой статье я детально рассмотрю, как именно государство видит программно-определяемый ЦОД с точки зрения нормативных требований и сертификации. Вы узнаете, какие компании и в каких случаях обязаны получать сертификат соответствия, а кто может спокойно обойтись без него, а также получите обзор нормативных актов и стандартов, регулирующих эту сферу.
Меня зовут Дмитрий Гоголев, я — директор по развитию облачной платформы Cloudlink в Orion soft, и моя цель — помочь читателям разобраться, как грамотно и без лишних затрат обеспечить соответствие российскому законодательству, не жертвуя при этом преимуществами современных технологий.
Какие именно ошибки деплоя в Kubernetes встречаются чаще всего и как их устранять? Будь то CrashLoopBackOff, зависшие поды, проблемы в синтаксисе YAML — рассмотрим 10 распространенных проблем и к каждой приложим простые и проверенные советы, как избежать их появления в будущем.
Многие команды работают с кластерами Kubernetes побольше нашего. В них больше узлов, больше подов, больше ingress и так далее. По большинству размерностей нас кто-нибудь, да побеждает.
Но есть одна размерность, по которой, как мы подозреваем, мы почти на вершине: это пространства имён. Я думаю так, потому что мы постоянно сталкиваемся со странным поведением во всех процессах, которые их отслеживают. В частности, все процессы, выполняющие их listwatch, занимают на удивление много памяти и подвергают apiserver серьёзной нагрузке. Это стало одной из сложностей масштабирования, которую замечаешь, только достигая определённого порога. При увеличении оверхеда памяти эффективность снижается: каждый байт, который нам нужно использовать для управления — это байт, отнятый у пользовательских сервисов.
Проблема сильно усугубляется, когда daemonset должен выполнять listwatch пространств имён или сетевых политик (netpol), которые мы определяем для каждого пространства имён. Так как daemonset запускают под в каждом узле, каждый из этих подов выполняет listwatch одних и тех же ресурсов, из-за чего объём используемой памяти увеличивается при росте количества узлов.
Хуже того — эти вызовы listwatch серьёзно нагружали apiserver. Если одновременно перезапускалось множество подов daemonset, например, при развёртывании, то они могли перегрузить сервер запросами и вызвать реальный вылет.
Я задал это вопрос ИИ (Google) и получил ответ:
Виртуальные машины (ВМ) нужны для запуска нескольких операционных систем на одном компьютере, тестирования программ без риска для основной системы, создания изолированных и безопасных сред, а также для эффективного использования серверных ресурсов в облачных вычислениях и дата-центрах. Они полезны для разработчиков, системных администраторов и для пользователей, которым необходимо работать с разными ОС или приложениями.
Основные причины, зачем нужны виртуальные машины:
Запуск нескольких ОС: Позволяют использовать Windows на Mac или, наоборот, запускать различные операционные системы в отдельных окнах на вашем компьютере.
Тестирование: Можно безопасно тестировать новое или подозрительное программное обеспечение, не боясь навредить основной системе. Это особенно актуально для тестирования приложений на разных платформах (например, на Windows и Linux).
Изоляция и безопасность: ВМ создают изолированную среду. Если в виртуальной машине произойдет сбой или она заразится вирусом, это не повлияет на работу основной операционной системы.
Виртуальные серверы: ВМ позволяют использовать один физический сервер для размещения нескольких виртуальных серверов. Это экономит средства, снижает потребление энергии и упрощает управление серверной инфраструктурой для компаний.
Гибкость и масштабируемость: ВМ легко создать, настроить и перенести. Это позволяет компаниям быстро адаптироваться к меняющимся нагрузкам и легко масштабировать свои ресурсы.
Эффективное использование ресурсов: Виртуальные машины позволяют распределять ресурсы одного физического компьютера между несколькими ВМ, что повышает общую эффективность использования оборудования.
Разберемся с каждым пунктом по отдельности.
В комментариях к одной из моих первых статей на Хабре мне было предложено написать статью про виртуальные машины.
Долго думал об этом, было много дел не располагающих к писательству, и вот собрался наконец.
Начну с остренького. В ИТ есть только одна настоящая система виртуальных машин. Это zVM. Всё остальное претендующее на это название на самом деле является системами виртуальных ... систем.
Давайте разбираться с котлетами и мухами.
Облачная инфраструктура должна одинаково эффективно работать с корпоративными ERP-системами, современными контейнеризованными приложениями и базами данных. Выбор процессоров для такой универсальной платформы превращается в комплексную задачу, где необходимо учитывать производительность, экономическую целесообразность, гибкость архитектуры и возможности масштабирования.
Рынок серверных процессоров эволюционировал от универсальных решений первых поколений Intel Xeon Scalable до современных специализированных CPU пятого и шестого поколений с встроенными ускорителями. Понимание этой эволюции и правильная интерпретация характеристик процессоров становится критически важным навыком при построении облачной инфраструктуры.
Привет, Хабр! Сегодня познакомимся с Кибер Бэкапом 18 — новой версией нашей системы резервного копирования. Релиз у нас получился «увесистый» — мы обеспечили дальнейший рост производительности и масштабируемости системы, защиту новых и развитие возможностей защиты уже поддерживаемых источников данных, реализовали открытый API управления планами защиты, выполнили доработки в части интерфейса и управления системой, а также выпустили ознакомительную MVP‑версию Кибер Медиасервера.
Новая версия Debian 13 и релиз Proxmox VE 9.0 пришли почти одновременно, вызвав ажиотаж у клиентов. В статье рассказываем, как команда HOSTKEY адаптировала свои процессы, автоматизировала деплой и подготовила инфраструктуру под свежие релизы.
Случается, что виртуальной машине необходимо предоставить доступ к RAW сетевой карте с тегированным трафиком, не разделяя его на VLAN на уровне гипервизора. Например, такое требование есть у OPNsense(firewall и routing) и у контроллеров для отечественной виртуализации Basis Dynamix.
Расскажу, как сделать такой доступ.
486-й в кармане: как оживить MS-DOS на QEMU
Полный контроль над железом, цветной промпт и настройка Sound Blaster 16 — всё, что вы хотели знать о ретровиртуализации
Источник обложки (ужас как трудно подобрать хорошую обложку! так что не судите строго)
Если в качестве основной (или единственной) операционной системы используется Windows, самым быстрым и удобным способом начать пользоваться Ubuntu является использование встроенного ядра Linux прямо внутри Windows.
Эта функция, доступная в составе Windows, позволяет обойтись без гипервизора виртуальных машин и без настройки мультизагрузки (dual-boot, multi-boot). Ядро Linux запускается в лёгкой служебной виртуальной среде, основанной на компонентах Hyper-V, что обеспечивает минимальные накладные расходы и высокую производительность.
После установки выбранный дистрибутив Linux полностью интегрируется в систему Windows, позволяя разработчику пользоваться преимуществами обеих ОС с минимальными затратами — как аппаратными, так и временными.
Еще до открытия для себя практик Dev-ops я использовал Docker для упаковки и быстрой доставки кода на сервера (всё делалось ручками, я еще не знал про CI/CD xD). Со временем мои приложения становились больше, появлялись микросервисы, убирался монолит. И управлять ручками или через Portainer всей архитектурой было слегка сложновато. Простой, куча вопросов, падение контейнеров, рост нагрузки и все в этом духе. Тогда-то я и открыл для себя кубер.
Привет! Я Саша Епихин, CTO zVirt. В прошлой моей статье речь шла о том, как oVirt стала самым зрелым Open Source ПО для виртуализации и о том, почему мы в Orion soft выбрали разработку на базе этого решения, а не пошли другим путем. Я упоминал, что мы давно ушли от модели форка: oVirt — это только проверенное ядро, а всю дополнительную функциональность мы разрабатываем «поверх» него сами. Можно сказать, мы не просто натянули новые обои, а сделали капитальную пристройку с ремонтом. Это позволяет и получать обновления сообщества, и отправлять в него багфиксы, и развивать свое комьюнити.
Важно понимать контекст: в 2024 году oVirt официально осталась без поддержки разработчика Red Hat, который перестал выпускать для нее обновления безопасности. Любой продукт, оставшийся без техподдержки, опасен для бизнеса. Но zVirt — это не просто локализованная версия oVirt. Это эволюция платформы, которая не только добавляет новые функции, но и решает проблемы безопасности и стабильности исходного кода.
В этой статье я хочу рассказать подробнее, чем именно мы отличаемся от oVirt. Начну с доработок по стабильности и безопасности.
«Привет! Я разработчик. Для начала расскажу о своём важном для этой статьи опыте: я пишу код на Hoobijag, иногда на jabbernocks и, разумеется, на ABCDE++++ (но никогда — на ABCDE+/^+; вы что, шутите?); мне нравится работать с Shoobababoo и иногда с клептомитронами. Я устроился на работу в Компанию1 и занимаюсь там кодом для Shoobaboo, поэтому перешёл к использованию Snarfus. Давайте разбираться!
