Что такое контейнер для файлов
К 2022 году о контейнеризации не слышал только ленивый. Большинство специалистов, так или иначе имеющих отношение к ИТ, хотя бы раз в жизни запускали программное обеспечение в контейнерах. Однако так ли эта технология проста и понятна? Давайте разбираться вместе!
Главная задача данной статьи – рассказать о контейнеризации, дать ключевые понятия для дальнейшего изучения и показать несколько простых практических приемов. По этой причине (а еще, безусловно, вследствие недостаточной квалификации автора) теоретический материал достаточно упрощен.
Советы для топ-менеджеров
Контейнер на рабочем устройстве не нужен. Любой смартфон, который компания выдала сотруднику, воспринимается как рабочий. Сотрудник никогда не поверит, что его работодатель не имеет доступа к его личным данным, даже если это пообещал Google. Поэтому рабочие устройства проще и дешевле превращать в контейнеры целиком, устанавливая приложения только из корпоративного хранилища, запрещая лишнюю сетевую активность и сервисы, которые позволяют «поделиться» корпоративными данными с конкурентами или СМИ.
Такой подход проверен, стандартизован и используется годами на большинстве рабочих ноутбуков в крупных компаниях.
Личные устройства – это не всегда дешево и удобно. С одной стороны, может показаться, что использование личных устройств позволяет сэкономить на покупке гаджетов сотрудникам, но на практике оказывается, что содержать «зоопарк» смартфонов разных производителей дороже, чем «питомник», где устройств много, но они однотипны.
На каждом новом устройстве корпоративный софт не работает совершенно особенным образом. Каждая мажорная версия Android c 4 по 12 серьёзно отличаются. У каждого производителя своя сборка Android. У каждой сборки Android, особенно китайской, свои «тараканы» – неуправляемые менеджеры памяти и батареи, которые так и норовят поскорее закрыть приложение или не дать ему вовремя получить данные от сервера, дополнительные разрешения, которые пользователь должен вручную дать приложению и которые он может в любой момент отобрать и т.п.
Если планировать мобилизацию компании на 3-5 лет вперёд, дешевле выбрать несколько моделей устройств, и дальше проверять и разрабатывать корпоративный софт (клиент документооборота, приложения с BI-отчётностью, мессенджеры и т.п.) на этих конкретных моделях. Всё-таки корпоративный софт пишут не тысячи разработчиков Facebook по всему миру. Поэтому чем меньше вариативность устройств, тем меньше ошибок, тем меньше число уязвимостей и ниже вероятность их успешной эксплуатации. Короче, всем удобнее и безопаснее.
Если у вас возникли вопросы или сомнения после прочтения статьи, напишите о них в комментариях.
Международный рынок гипермасштабируемых дата-центров растет с ежегодными темпами в 11%. Основные «драйверы» — предприятия, подключенные устройства и пользователи — они обеспечивают постоянное появление новых данных. Вместе с объемом рынка растут и требования к надежности хранения и уровню доступности данных.
Ключевой фактор, влияющий на оба критерия — системы хранения. Их классификация не ограничивается типами оборудования или брендами. В этой статье мы рассмотрим разновидности хранилищ — блочное, файловое и объектное — и определим, для каких целей подходит каждое из них.
/ Flickr / Jason Baker / CC
1. Контейнер электронного документа. Для чего он нужен?
Читаем Рекомендации ВНИИДАД:
«Электронные документы, подлежащие хранению, передаются в архив организации в виде контейнеров, обеспечивающих целостность электронных документов».
Электронные документы создаются, согласуются и подписываются в информационных системах организаций. При этом они «обрастают» дополнительной информацией, называемой метаданными. В результате кроме самого документа в системе хранятся его реквизиты, электронные подписи, история согласования и другая полезная информация.
Когда ЭД передают на архивное хранение, недостаточно просто выгрузить тело документа (например, файл в формате MS Word). Нужно собрать и передать информацию, которая в дальнейшем позволит обеспечить его юридическую значимость, читабельность, да и просто возможность поиска. Но мало того, что информацию нужно собрать, её нужно куда-то «положить». Для этой цели был придуман контейнер.
5. Как определить, когда можно передать документ на хранение из оперативной системы в архивную?
Обратимся к «Правилам организации хранения, комплектования, учёта и использования документов архивного фонда Российской Федерации и других архивных документов в органах государственной власти, органах местного самоуправления и организациях» (Правила архивного фонда). Согласно документу, передача дел в архив организации идёт по графику, согласованному с руководителями структурных подразделений и утверждённому руководителем организации.
Но при этом нельзя ставить знак равенства между передачей документа в архивную систему и его передачей в архив организации.
По логике в архивной системе может быть выделено несколько контуров хранения. Например, в решении «Долговременный архив», разработанном на базе системы Directum выделяется:
● оперативный контур — приём контейнеров ЭД и формирование электронных дел;
● контур временного хранения — для документов сроком хранения до 10 лет;
● контур длительного хранения — для документов сроком хранения более 10 лет.
Соответственно, требования Правил архивного фонда скорее относятся к передаче документов в контур длительного хранения архивной системы:
Основным критерием для передачи ЭД в архивную систему является завершение оперативной работы с ним. Для всех видов документов этот момент может наступать по-разному. Например, организационные распорядительные документы можно передавать после завершения их исполнения, а бухгалтерские — после закрытия отчётного периода.
Таким образом, для каждого вида документа нужно определить свои правила передачи на хранение в архивную систему:
При этом важно также учитывать особенности, которые накладываются архивной системой при работе с электронном документом. Например, после передачи ЭД в архивную систему в системе-источнике он не должен изменяться. Или после принятия документа на хранение «вернуть» его обратно в систему-источник нельзя. Также можно ограничить доступ пользователей к оригиналам, переданным в архив.
Зачем нужен контейнер работодателям и их сотрудникам?
Работодатели и сотрудники хотят, чтобы контейнер защищал ИХ секреты. Только секреты каждой из сторон находятся по разные стороны контейнера – секреты работодателя находятся внутри контейнера, а секреты сотрудника снаружи.
Поэтому работодатели хотят, чтобы сотрудники не могли вынести данные из контейнера, а сотрудники желают, чтобы работодатель не имел доступа к данным вне контейнера.
Сотрудники готовы мириться с ограничениями типа запрета установки приложений из непроверенных источников, но даже потенциальная возможность доступа к их личным данным не стоит для них возможности удалённой работы со своего смартфона или планшета.
Есть ещё одно желание, в котором сходятся работодатели и сотрудники. И те, и другие хотят, чтобы в контейнер можно было поместить любое приложение без дополнительных доработок. Если приложения нужно дорабатывать, это дорого для работодателя и чаще всего неудобно для сотрудника.
Механизмы изоляции контейнеров
Изоляция процессов в контейнерах осуществляется благодаря двум механизмам ядра Linux – пространствам имен (namespaces) и контрольным группам (cgroups).
Пространства имен гарантируют, что процесс будет работать с собственным представлением системы. Существует несколько типов пространств имен:
файловая система (mount, mnt) – изолирует файловую систему
UTS (UNIX Time-Sharing, uts) – изолирует хостнейм и доменное имя
идентификатор процессов (process identifier, pid) – изолирует процессы
сеть (network, net) – изолирует сетевые интерфейсы
межпроцессное взаимодействие (ipc) – изолирует конкурирующее взаимодействие процессами
пользовательские идентификаторы (user) – изолирует ID пользователей и групп
Процесс принадлежит не одному пространству имен, а одному пространству имен каждого типа.
Контрольные группы гарантируют, что процесс не будет конкурировать за ресурсы, зарезервированные за другими процессами. Они ограничивают (контролируют) объем ресурсов, который процесс может потреблять – ЦПУ, ОЗУ, пропускную способность сети и др.
4. Можно ли списать электронный документ в несколько дел?
При работе с бумажным оригиналом каждое заинтересованное подразделение может сделать копию и списать её в своё дело. А электронный документ в системе один, копия не имеет смысла.
Если возникает желание списать его в несколько дел, то важно понимать последствия:
● появляется несколько «владельцев» ЭД;
● для разных дел могут быть установлены свои сроки хранения.
Лучший вариант в данном случае — создать правила определения одного подразделения-владельца электронного документа и его отнесения к делу данного подразделения. Всем остальным заинтересованным подразделениям в архивной системе можно выдавать доступ к документу.
7. Как контролировать сроки хранения и уничтожения электронного документа?
Внедрение архивной системы поможет автоматизировать контроль сроков хранения и уничтожения ЭД в архиве. И при правильной организации номенклатуры дел эти процессы выглядят так же, как в случае с бумажными документами.
Сроки хранения и уничтожения ЭД контролируются в разрезе электронных дел. Участие человека необходимо на этапе экспертизы ценности документов и принятия решения. При этом архивная система может помочь делопроизводителю — предоставить ему аналитическую информацию, например, о востребованности документа.
Есть одна техническая и важная особенность уничтожения ЭД. Для восстановления данных на случай сбоев при эксплуатации архивной системы создаются резервные копии. Чтобы при восстановлении информации не было проблем, когда уничтоженный документ «восстает из пепла», резервное копирование должно учитывать бизнес-процессы архивной системы. В этом делопроизводителям/архивистам помогут ИТ-специалисты организации.
Построение электронных архивов для долгосрочного хранения — обязательное условие, если вы планируете перейти на полностью электронный документооборот. Иначе ваши электронные документы так и останутся «приложением» к бумаге. Она уже становится анахронизмом и тяжёлым камнем для бизнеса, затрудняющим цифровой скачок в развитии. Рекомендуем изучить кейсы внедрения долговременных архивов — они демонстрируют положительный опыт, за которым можно и нужно следовать уже сейчас.
Существует много разнообразных программ для защиты файлов и папок. В этой статье будет рассмотрена лишь небольшая их часть, проверенная автором лично длительным периодом их практического использования.
Рассмотренные программы обеспечивают надежную защиту папок и файлов от доступа посторонних лиц. Более простые способы защиты данных описаны здесь.
Подсказки после практики
На практике при работе с контейнерами могут быть полезны следующие советы:
Для администрирования приложений в контейнерах следует использовать функционал systemd unit
Управлять приложениями в контейнерах как обычными сервисами Linux очень удобно – настройка, запуск, остановка, восстановление при сбоях и др. действия становятся простыми и прозрачными
Читать подробнее: Как запустить Docker / Podman контейнеры в качестве службы Systemd
Docker или Podman?
Как определить, что лучше использовать – Docker или Podman? Критериев много, однозначного ответа нет, да и разница на сегодняшний день не так велика. Однако автор рекомендует использовать Podman во всех дистрибутивах, где приложила руку RedHat. Ubuntu, Debian и др. – Docker, RHEL, Fedora – Podman
За помощь в подготовке статьи автор выражает искреннюю благодарность @novikov0805, @Eviil и @KoPashka
Делопроизводители сегодня хорошо разбираются в системах электронного документооборота. Многие понимают, как важно организовать современное хранение документов. Однако разобраться в теме иногда бывает непросто. Отвечаем на самые популярные вопросы.
Делопроизводители сегодня хорошо разбираются в системах электронного документооборота. При этом многие понимают, как важно организовать современное хранение документов и как это сделать правильно. Однако разобраться в теме иногда бывает непросто. Ответы на 7 самых популярных вопросов о долговременном архиве электронных документов — далее.
Организовать хранение электронных документов (ЭД) можно по-разному. Например, передавать их в архив на обособленных носителях информации — использовать для этого оптические диски. Второй вариант — создать информационную систему архива организации.
Как строится работа с такой системой, что нужно знать делопроизводителю? Все ответы будут позже, а пока давайте начнём с важных терминов.
Всероссийский научно-исследовательский институт документоведения и архивного дела в своих Рекомендациях по комплектованию, учёту и организации хранения электронных архивных документов в архивах организаций (Рекомендации ВНИИДАД) даёт определения:
· единица хранения электронных документов — контейнер электронного документа.
Особенность контейнеров для iOS
В своей прошлой статье мы убеждали читателя, что iOS – это закрытая экосистема, которую нужно принимать такой, какая она есть. Контейнеры на iOS – ещё одно тому подтверждение.
С точки зрения контейнеризации в iOS есть встроенный механизм разделения корпоративного и личного. Apple называет корпоративное управляемым (managed), а личное – неуправляемым (unmanaged).
Управляемыми в iOS могут быть приложения, учётные записи и URL в Safari. С помощью встроенных политик можно запретить передачу данных между управляемым и неуправляемым, но только случайную. Это значит, что сотрудник не может передать вложение из корпоративной почты в личную почту или в WhatsApp, но может скопировать текст вложения и вставить его куда угодно!
Apple считает, что защититься от преднамеренной утечки данных невозможно, поэтому решил позаботиться о своих сознательных пользователях и не дать им случайно допустить утечку…
Если компания решает, что встроенных механизмов безопасности iOS для нее недостаточно, ей приходится реализовывать дополнительные механизмы защиты в корпоративных приложениях. Например, блокируя в них возможность доступа к буферу обмена. Сделать это проще всего с помощью SDK разработчиков систем управления мобильностью, например, SafePhone.
Что такое контейнеры?
Контейнеризация (виртуализация на уровне ОС) – технология, которая позволяет запускать программное обеспечение в изолированных на уровне операционной системы пространствах. Контейнеры являются наиболее распространенной формой виртуализации на уровне ОС. С помощью контейнеров можно запустить несколько приложений на одном сервере (хостовой машине), изолируя их друг от друга.
Процесс, запущенный в контейнере, выполняется внутри операционной системы хостовой машины, но при этом он изолирован от остальных процессов. Для самого процесса это вылядит так, будто он единственный работает в системе.
Защита файлов при помощи программы TrueCrypt
Эта программа защищает не непосредственно сами файлы. Она позволяет создавать специальные контейнеры, в которые можно помещать любую информацию (документы, видео, фото и др.). Вся информация в таком контейнере хранится в закриптованном виде. Для доступа к контейнеру пользователь должен знать пароль. В качестве дополнительной защиты кроме пароля можно использовать также ключевой файл, без наличия которого открыть контейнер невозможно.
В качестве контейнера программа может использовать специально созданный файл или же какое-то запоминающее устройство целиком (флешку, логический раздел жесткого диска).
Доступ к зашифрованному контейнеру осуществляется путем его виртуального превращения в отдельный логический раздел (монтирования). Чтобы смонтировать (открыть) контейнер, пользователь должен запустить программу TrueCrypt, указать на этот контейнер, ввести пароль, после чего в перечне запоминающих устройств компьютера (в разделе «Мой компьютер») появится дополнительное запоминающее устройство. Это и будет наш контейнер. С ним можно работать как с обычным запоминающим устройством – копировать, удалять, создавать файлы, просматривать, переименовывать, корректировать их и т.д. При этом, данные, сохраняемые в смонтированном контейнере, криптуются программой «на лету». Пользователь этого даже не замечает.
После размонтирования контейнера он перестанет отображаться в списке запоминающих устройств компьютера.
Как уже было сказано, программа TrueCrypt может создавать контейнеры двух основных видов:
Таким образом, программа TrueCrypt реализует два уровня защиты.
Во-первых, она прячет файлы визуально, помещая их внутрь другого файла или на носитель, который на первый взгляд кажется неотформатированным. Если контейнер даже и попадет в руки непосвященного человека, тот, скорее всего, просто удалит его, даже и не догадываясь о его действительном предназначении.
Во-вторых, данные, хранящиеся в контейнере, хорошо криптуются. Взломать такой контейнер в обычных условиях практически невозможно.
Еще одной важной особенностью программы TrueCrypt является возможность криптования системного логического раздела компьютера, то есть, раздела, в котором установлена операционная система. Пароль для доступа к нему будет запрашиваться компьютером сразу после его включения (еще до начала загрузки Windows). Это очень полезная возможность, поскольку она гарантирует надежную защиту информации даже в том случае, если компьютер будет загружен злоумышленниками со съемного носителя (Live CD) или же если жесткий диск или SSD компьютера будет ими снят и подсоединен к другому компьютеру. Зашифрованный раздел при этом будет опознаваться как неоформатированный.
Пользоваться программой TrueCrypt не сложно, в ней все понятно на интуитивном уровне. Но на всякий случай вот информация о порядке осуществления основных операций:
1. Для создания зашифрованного контейнера – запустить программу, нажать кнопку «Создать том», выбрать один из вариантов создания контейнера и дальше отвечать на вопросы мастера создания тома (см. изображение);
2. Чтобы смонтировать контейнер - запустить программу, в основном окошке выделить букву устройства, в виде которого будет смонтирован контейнер, затем нажать кнопку «Устройство» или «Файл» (в зависимости от типа контейнера) и указать на контейнер. После этого нажать кнопку «Смонтировать», ввести пароль, указать на ключевой файл (если такой способ защиты был выбран для монтируемого контейнера) и нажать кнопку «ОК».
3. Чтобы размонтировать контейнер нужно открыть окно программы, в основном окошке выбрать смонтированное устройство и нажать кнопку «Размонтировать».
Применимость систем хранения разных типов
Блочные хранилища
Блочные хранилища обладают набором инструментов, которые обеспечивают повышенную производительность: хост-адаптер шины разгружает процессор и освобождает его ресурсы для выполнения других задач. Поэтому блочные системы хранения часто используются для виртуализации. Также хорошо подходят для работы с базами данных.
Недостатками блочного хранилища являются высокая стоимость и сложность в управлении. Еще один минус блочных хранилищ (который относится и к файловым, о которых далее) — ограниченный объем метаданных. Любую дополнительную информацию приходится обрабатывать на уровне приложений и баз данных.
Файловые хранилища
Среди плюсов файловых хранилищ выделяют простоту. Файлу присваивается имя, он получает метаданные, а затем «находит» себе место в каталогах и подкаталогах. Файловые хранилища обычно дешевле по сравнению с блочными системами, а иерархическая топология удобна при обработке небольших объемов данных. Поэтому с их помощью организуются системы совместного использования файлов и системы локального архивирования.
Пожалуй, основной недостаток файлового хранилища — его «ограниченность». Трудности возникают по мере накопления большого количества данных — находить нужную информацию в куче папок и вложений становится трудно. По этой причине файловые системы не используются в дата-центрах, где важна скорость.
Объектные хранилища
Что касается объектных хранилищ, то они хорошо масштабируются, поэтому способны работать с петабайтами информации. По статистике, объем неструктурированных данных во всем мире достигнет 44 зеттабайт к 2020 году — это в 10 раз больше, чем было в 2013. Объектные хранилища, благодаря своей возможности работать с растущими объемами данных, стали стандартом для большинства из самых популярных сервисов в облаке: от Facebook до DropBox.
Такие хранилища, как Haystack Facebook, ежедневно пополняются 350 млн фотографий и хранят 240 млрд медиафайлов. Общий объем этих данных оценивается в 357 петабайт.
Хранение копий данных — это другая функция, с которой хорошо справляются объектные хранилища. По данным исследований, 70% информации лежит в архиве и редко изменяется. Например, такой информацией могут выступать резервные копии системы, необходимые для аварийного восстановления.
Но недостаточно просто хранить неструктурированные данные, иногда их нужно интерпретировать и организовывать. Файловые системы имеют ограничения в этом плане: управление метаданными, иерархией, резервным копированием — все это становится препятствием. Объектные хранилища оснащены внутренними механизмами для проверки корректности файлов и другими функциями, обеспечивающими доступность данных.
Плоское адресное пространство также выступает преимуществом объектных хранилищ — данные, расположенные на локальном или облачном сервере, извлекаются одинаково просто. Поэтому такие хранилища часто применяются для работы с Big Data и медиа. Например, их используют Netflix и Spotify. Кстати, возможности объектного хранилища сейчас доступны и в сервисе 1cloud.
После отправки к файлу добавляются необходимые метаданные. Для этого есть такой запрос:
Богатая метаинформация объектов позволит оптимизировать процесс хранения и минимизировать затраты на него. Эти достоинства — масштабируемость, расширяемость метаданных, высокая скорость доступа к информации — делают объектные системы хранения оптимальным выбором для облачных приложений.
Однако важно помнить, что для некоторых операций, например, работы с транзакционными рабочими нагрузками, эффективность решения уступает блочным хранилищам. А его интеграция может потребовать изменения логики приложения и рабочих процессов.
История
Идея изоляции пользовательских пространств берет свое начало в 1979 году, когда в ядре UNIX появился системный вызов chroot. Он позволял изменить путь каталога корня / для группы процессов на новую локацию в файловой системе, то есть фактически создавал новый корневой каталог, который был изолирован от первого. Следующим шагом и логическим продолжением chroot стало создание в 2000 году FreeBSD jails («тюрем»), в которых изначально появилась частичная изоляция сетевых интерфейсов. В первой половине нулевых технологии виртуализации на уровне ОС активно развивались – появились Linux VServer (2001), Solaris Containers (2004) и OpenVZ (2005).
В операционной системе Linux технологии изоляции и виртуализации ресурсов вышли на новый этап в 2002 году, когда в ядро было добавлено первое пространство имен для изоляции файловой системы – mount. В 2006-2007 годах компанией Google был разработан механизм Process Containers (позднее переименованный в cgroups), который позволил ограничить и изолировать использование группой процессов ЦПУ, ОЗУ и др. аппаратных ресурсов. В 2008 году функционал cgroups был добавлен в ядро Linux. Достаточная функциональность для полной изоляции и безопасной работы контейнеров была завершена в 2013 году с добавлением в ядро пространства имен пользователей – user.
В 2008 году была представлена система LXC (LinuX Containers), которая позволила запускать несколько изолированных Linux систем (контейнеров) на одном сервере. LXC использовала для работы механизмы изоляции ядра – namespaces и cgroups. В 2013 году на свет появилась платформа Docker, невиданно популяризовавшая контейнерные технологии за счет простоты использования и широкого функционала. Изначально Docker использовал LXC для запуска контейнеров, однако позднее перешел на собственную библиотеку libcontainer, также завязанную на функционал ядра Linux. Наконец, в 2015 появился проект Open Container Initiative (OCI), который регламентирует и стандартизирует развитие контейнерных технологий по сей день.
Разнообразие Android - контейнеров
Android исторически предоставляет больше возможностей для контейнеризации.
Первой компанией, которая сделала возможным создание контейнеров на Android, стала компания Samsung. В 2012 году на смартфоне Samsung Galaxy S3 впервые стали доступны функции корпоративной платформы безопасности Samsung Knox. В частности, Knox контейнеры. Большинство современных устройств Samsung также их поддерживают. Многие функции платформы Samsung Knox бесплатны, но функции Knox контейнеров были платной опцией. Позже Google анонсировал свою бесплатную корпоративную платформу Android for Enterprise c меньшим набором функций.
С годами число функций управления контейнерами, которые были эксклюзивно доступны на устройствах Samsung, сокращалось, потому что они появлялись у Google. В результате, начиная с
1 июля 2021 года, Samsung принял решение о бесплатном предоставлении возможностей Knox-контейнеризации. В составе платформы Samsung Knox ещё остаются платные опции, которых нет у Google. Например, корпоративных сервис обновления прошивок мобильных устройств E-FOTA One, о котором мы рассказывали в одной из прошлых статей.
Но конкретно Knox контейнеры отныне бесплатны.
Контейнер в Android или, как его называет Google, «рабочий профиль» выглядит для пользователя как отдельная папка или отдельный рабочий стол, где размещаются корпоративные приложения. Приложения в контейнере работают так, как будто за пределами контейнера ничего не существует. В контейнере есть свой буфер обмена, своя виртуальная память для хранения файлов и т.д.
Без явного разрешения администратора пользователь не сможет ничего вынести за пределы контейнера.
Вроде то, что нужно? Да, но не обошлось без важных особенностей.
В составе Samsung Knox есть клиентские библиотеки для Android, с помощью которых можно разработать клиент управления, который сам создаст контейнер, применит в нём необходимые политики безопасности и наполнит его приложениями.
Работает эта схема так:
На мобильное устройство устанавливается клиент управления.
Пользователь регистрирует устройство на сервере управления.
Клиент управления создаёт и настраивает контейнер для работы. После чего периодически спрашивает у сервера управления, не изменились ли эти настройки.
Можно доставить обновления настроек быстрее с помощью push-уведомлений от Google, но их использование необязательно.
Преимущество этой схемы в том, что её можно построить в локальной инфраструктуре заказчика (on-premise). Для крупного бизнеса в России это важно.
У платформы Android for Enterprise от Google тоже есть клиентские библиотеки и с их помощью можно управлять устройствами без контейнеров – устанавливать приложения, настраивать ограничения и т.д. Даже можно создать контейнер, поместить в него встроенный Gmail или Google Chrome и запретить сотруднику копировать из контейнера файлы. Всё это будет работать on-premise.
Но клиентские библиотеки Google не помогут, если нужно разместить в контейнере приложение собственной разработки или какое-то приложение из Google Play. В этом случае необходимо использовать Android Management API, который работает по несложной схеме:
На мобильное устройство устанавливается клиент управления от Google – Android Device Policy.
Администратор создаёт настройки контейнера – какие приложения в него установить, какие политики ограничений применить и т.д.
Сервер передаёт настройки контейнера в Google с помощью Android Management API. Дальше Google обеспечивает их применение на устройстве самостоятельно. При этом все команды и все дистрибутивы корпоративных приложений нужно передать в Google.
Похожим образом устроено управление iOS, но в случае с iOS корпоративный сервер управления передаёт в Apple только уведомления о наличии команды. Далее устройство забирает команды и дистрибутивы приложений с корпоративного сервера, а не с сервера Apple.
Возможно, Google хотел создать более удобную технологию управления, чем у Apple, но не все компании готовы мириться с тем, что Google знает, какие настройки безопасности и какие команды управления они сообщают своим мобильным устройствам. Ведь это создаёт риск того, что команды могут быть изменены или вовсе не доставлены.
Работа с Docker
Docker – это открытая платформа для разработки, доставки и запуска приложений. Состоит из утилиты командной строки docker, которая вызывает одноименный сервис (сервис является потенциальной единой точкой отказа) и требует права доступа root. По умолчанию использует в качестве Container Runtime runc. Все файлы Docker (образы, контейнеры и др.) по умолчанию хранятся в каталоге /var/lib/docker.
Для установки необходимо воспользоваться официальным руководством – Download and install Docker, которое содержит подробные инструкции для Linux, Windows и Mac. Стоит сразу отметить, что контейнерам для работы необходимы функции ядра Linux, поэтому они работают нативно под Linux, почти нативно в последних версиях Windows благодаря WSL2 (через Docker Desktop или Linux диструбутив) и не нативно под Mac (используется виртуализация). Автор рекомендует использовать в тестовой и особенно в промышленной эксплуатации только Linux.
Основные команды
Ниже приведены примеры наиболее распространенных команд:
Обязательно пробуйте команды на практике, при необходимости прибегая к help или руководствам в Интернете.
Хранение данных
При запуске контейнер получает доступ на чтение ко всем слоям образа, а также создает свой исполняемый слой с возможностью создавать, обновлять и удалять файлы. Все эти изменения не будут видны для файловой системы хоста и других контейнеров, даже если они используют тот же базовый образ. При удалении контейнера все измененные данные также будут удалены. В большинстве случаев это предпочтительное поведение, однако иногда данные необходимо расшарить между несколькими контейнерами или просто сохранить.
Рассмотрим два способа хранения данных контейнеров:
named volumes – именованные тома хранения данных
Позволяет сохранять данные в именованный том, который располагается в каталоге в /var/lib/docker/volumes и не удаляется при удалении контейнера. Том может быть подключен к нескольким контейнерам
bind mount – монтирование каталога с хоста
Позволяет монтировать файл или каталог с хоста в контейнер. На практике используется для проброса конфигурационных файлов или каталога БД внутрь контейнера
Ниже приведены примеры использования named volume и bind mount:
Обязательно пробуйте команды на практике, при необходимости прибегая к help или руководствам в Интернете.
Создание образа (Dockerfile)
Создание и распространение образов – одна из основных задач Docker. Рассмотрим два способа создания образа:
commit изменений из контейнера
Необходимо запустить контейнер из базового образа в интерактивном режиме, внести изменения и сохранить результат в образ с помощью команды commit. На практике способ удобен для небольших быстрых доработок
декларативное описание через Dockerfile
Основной способ создания образов. Необходимо создать файл Dockerfile с декларативным описанием в формате yaml через текстовый редактор и запустить сборку образа командой build
Ниже приведены примеры использования commit и build:
Обязательно пробуйте команды на практике, при необходимости прибегая к help или руководствам в Интернете.
Мультиконтейнерные приложения (Docker Compose)
Docker Compose – это инструмент для декларативного описания и запуска приложений, состоящих из нескольких контейнеров. Он использует yaml файл для настройки сервисов приложения и выполняет процесс создания и запуска всех контейнеров с помощью одной команды. Утилита docker-compose позволяет выполнять команды на нескольких контейнерах одновременно – создавать образы, масштабировать контейнеры, запускать остановленные контейнеры и др.
Защита файлов при помощи программы S-Tools
Программа S-Tools позволяет шифровать и прятать файлы в любые файлы изображений формата GIF и BMP, а также в аудиозаписи формата WAV. При этом, работоспособность файлов, используемых в качестве контейнера, сохраняется. То есть, фотографии со спрятанными в них данными будут открываться компьютером, как ни в чем не бывало, аудиозаписи-контейнеры также будут воспроизводиться.
Позитивным моментом является также и то, что S-Tools не требует установки (портативная программа).
Но использовать ее в повседневной жизни все же не очень удобно. Самым большим минусом этого способа защиты данных является то, что используемые в качестве контейнеров файлы являются не большими. Соответственно, спрятать в них много информации невозможно.
Программу S-Tools можно использовать для надежной защиты какого-нибудь небольшого текстового файла, например, файла с паролями или другой похожей информацией.
2. Что представляет собой контейнер?
«Контейнер электронного документа — упаковка, включающая электронный документ в формате архивного хранения и его метаданные».
Как отмечалось выше, электронный документ (в отличие от бумажного) не является «единым» объектом. Он включает в себя:
● непосредственно информацию о факте конкретной хозяйственной деятельности в исходном формате системы, в которой создали этот документ;
● метаданные, которые появляются в информационной системе в процессе работы с ним.
Состав метаданных зависит от вида документа и определяется самой организацией. Например, в зависимости от предполагаемых вариантов поиска ЭД в архивной системе.
Для воспроизводимости электронных документов в виде, понятном человеку на протяжении всего срока его хранения, рекомендуют использовать специальные форматы. Например, для текстовых — PDF/A.
При формировании контейнера должно выполняться преобразование формата. Правильнее, когда это делает система-источник, где «родился» документ, так как она умеет работать с исходным форматом и отвечает за преобразование в человекочитаемый вид.
Формат архивного хранения (PDF/A) в контейнере обязателен для документов длительного (более 10 лет) и постоянного срока хранения. Для ЭД со сроком хранения до 10 лет риск устаревания формата значительно ниже. Но при этом нужно учитывать, что:
● есть риски, связанные, например, с изменением срока хранения документа, а точнее с необходимостью его увеличить;
● в любом случае нужно обеспечить возможность просмотра ЭД.
Эти особенности определяют требования к контейнеру по Рекомендациям ВНИИДАД. Также в него могут быть включены другие файлы. Это могут быть файлы приложений, которые являются неотъемлемой частью документа и листы согласования.
Таким образом, контейнер электронного документа представляет собой ZIP-архив с набором файлов и позволяет обеспечить хранение ЭД отдельно от информационной системы, в которой его создали.
Подсказки перед практикой
На практике при работе с контейнерами могут быть полезны следующие советы:
Простейший сценарий – скачать образ, создать контейнер и запустить его (выполнить команду внутри)
Документацию по запуску контейнера (путь к образу и необходимые команды с ключами) как правило можно найти в реестре образов (например, у Docker Hub есть очень удобный поисковик) или в ReadMe репозитория с исходным кодом проекта. Создать образ и сохранить его в публичный реестр может практически каждый, поэтому старайтесь пользоваться только официальной документацией и проверенными образами! Примеры: Docker Hub/nginx, Docker Hub/debian, GitHub Readme/prometheus
Для скачивания образов используется команда pull, однако в целом она необязательна – при выполнении большинства команд (create, run и др.) образ скачается автоматически, если не будет обнаружен локально
При выполнении команд pull, create, run и др. следует указывать репозиторий и тег образа. Если этого не делать, то будут использоваться значения по умолчанию – репозиторий как правило docker.io, а тег latest
При запуске контейнера выполняется команда по умолчанию (точка входа), однако можно выполнить и другую команду
Защита файлов при помощи программы AxCrypt
Программа AxCrypt защищает непосредственно каждый отдельный файл, сохраняя его в зашифрованном виде и устанавливая на него пароль.
Пользоваться этой программой очень просто и удобно. После установки AxCrypt добавляется в контекстное меню файлов. Чтобы зашифровать файл, достаточно щелкнуть по нему правой кнопкой мышки. Откроется контекстное меню, в котором указатель мышки необходимо навести на пункт «AxCrypt» (см. рис.). Будет предложено несколько вариантов шифрования:
1. Пункт «Encrypt» - файл шифруется, оригинал файла не сохраняется, для защиты пользователь дважды вводит пароль, который важно не забыть, поскольку взломать зашифрованный файл нереально. Этот файл можно будет открыть только при наличии пароля и только на компьютере, на котором установлена программа AxCrypt;
2. Пункт «Encrypt a copy» - все так же, как в первом варианте, только оригинал файла сохраняется;
3. Пункт «Encrypt copy to .EXE» - создаст самораспаковывающийся зашифрованный файл. Его можно будет открыть на любом компьютере при наличии пароля без необходимости установки программы AxCrypt.
Типы хранилищ и их различия
Хранение на уровне блоков лежит в основе работы традиционного жесткого диска или магнитной ленты. Файлы разбиваются на «кусочки» одинакового размера, каждый с собственным адресом, но без метаданных. Пример — ситуация, когда драйвер HDD пишет и считывает блоки по адресам на отформатированном диске. Такие СХД используются многими приложениями, например, большинством реляционных СУБД, в списке которых Oracle, DB2 и др. В сетях доступ к блочным хостам организуется за счет SAN с помощью протоколов Fibre Channel, iSCSI или AoE.
Файловая система — это промежуточное звено между блочной системой хранения и вводом-выводом приложений. Наиболее распространенным примером хранилища файлового типа является NAS. Здесь, данные хранятся как файлы и папки, собранные в иерархическую структуру, и доступны через клиентские интерфейсы по имени, названию каталога и др.
/ Wikimedia / Mennis / CC
При этом следует отметить, что разделение «SAN — это только сетевые диски, а NAS — сетевая файловая система» искусственно. Когда появился протокол iSCSI, граница между ними начала размываться. Например, в начале нулевых компания NetApp стала предоставлять iSCSI на своих NAS, а EMC — «ставить» NAS-шлюзы на SAN-массивы. Это делалось для повышения удобства использования систем.
Что касается объектных хранилищ, то они отличаются от файловых и блочных отсутствием файловой системы. Древовидную структуру файлового хранилища здесь заменяет плоское адресное пространство. Никакой иерархии — просто объекты с уникальными идентификаторами, позволяющими пользователю или клиенту извлекать данные.
Марк Горос (Mark Goros), генеральный директор и соучредитель Carnigo, сравнивает такой способ организации со службой парковки, предполагающей выдачу автомобиля. Вы просто оставляете свою машину парковщику, который увозит её на стояночное место. Когда вы приходите забирать транспорт, то просто показываете талон — вам возвращают автомобиль. Вы не знаете, на каком парковочном месте он стоял.
Большинство объектных хранилищ позволяют прикреплять метаданные к объектам и агрегировать их в контейнеры. Таким образом, каждый объект в системе состоит из трех элементов: данных, метаданных и уникального идентификатора — присвоенного адреса. При этом объектное хранилище, в отличие от блочного, не ограничивает метаданные атрибутами файлов — здесь их можно настраивать.
/ 1cloud
Основные понятия
Container image (образ) – файл, в который упаковано приложение и его среда. Он содержит файловую систему, которая будет доступна приложению, и другие метаданные (например команды, которые должны быть выполнены при запуске контейнера). Образы контейнеров состоят из слоев (как правило один слой – одна инструкция). Разные образы могут содержать одни и те же слои, поскольку каждый слой надстроен поверх другого образа, а два разных образа могут использовать один и тот же родительский образ в качестве основы. Образы хранятся в Registry Server (реестре) и версионируются с помощью tag (тегов). Если тег не указан, то по умолчанию используется latest. Примеры: Ubuntu, Postgres, NGINX.
Container (контейнер) – это экземпляр образа контейнера. Выполняемый контейнер – это запущенный процесс, изолированный от других процессов на сервере и ограниченный выделенным объемом ресурсов (ЦПУ, ОЗУ, диска и др.). Выполняемый контейнер сохраняет все слои образа с доступом на чтение и формирует сверху свой исполняемый слой с доступом на запись.
Container Engine (движок контейнеризации) – это программная платформа для упаковки, распространения и выполнения приложений, которая скачивает образы и с пользовательской точки зрения запускает контейнеры (на самом деле за создание и запуск контейнеров отвечает Container Runtime). Примеры: Docker, Podman.
Container Runtime (среда выполнения контейнеров) – программный компонент для создания и запуска контейнеров. Примеры: runc (инструмент командной строки, основанный на упоминавшейся выше библиотеке libcontainer), crun.
Host (хост) – сервер, на котором запущен Container Engine и выполняются контейнеры.
Open Container Initiative (OCI) – это проект Linux Foundation, основанный в 2015 году компанией Docker, Inc, целью которого является разработка стандартов контейнеризации. В настоящее время в проекте участвуют такие компании, как Google, RedHat, Microsoft и др. OCI поддерживает спецификации image-spec (формат образов) и runtime-speс (Container Runtime).
Корпоративный Android в личном пользовании
Многие компании, которые покупают сотрудникам мобильные устройства для работы, разрешают также использовать их в личных целях. В этом случае тоже нужны контейнеры, чтобы разделить корпоративные и личные данные. Если вы планируете реализовать такой сценарий, учтите, что, начиная с Android 11, у этого сценария есть принципиальные ограничения.
Начиная с Android 11, нельзя одновременно управлять и контейнером, и тем, что находится вне его. Это сделано, чтобы исключить доступ работодателей к личным данным сотрудников.
Цена приватности оказалась достаточно высокой. Теперь на корпоративных устройствах с контейнером нельзя определять геолокацию, устанавливать приложения вне контейнера и проверять устройство на наличие вирусов.
В качестве альтернативы Samsung предложил оригинальную технологию Knox Separated Apps. Технология позволяет создать на корпоративных устройствах контейнер для личных приложений. Работодатель управляет всем устройством и не получает доступа к данным сотрудника в личном контейнере. А приложения в личном контейнере не получают доступа к корпоративным данным, поэтому с их помощью нельзя реализовать утечку информации.
Knox Separated Apps, как и Knox контейнеры, с 1 июля 2021 года также станет бесплатной.
История
Идея изоляции пользовательских пространств берет свое начало в 1979 году, когда в ядре UNIX появился системный вызов chroot. Он позволял изменить путь каталога корня / для группы процессов на новую локацию в файловой системе, то есть фактически создавал новый корневой каталог, который был изолирован от первого. Следующим шагом и логическим продолжением chroot стало создание в 2000 году FreeBSD jails («тюрем»), в которых изначально появилась частичная изоляция сетевых интерфейсов. В первой половине нулевых технологии виртуализации на уровне ОС активно развивались – появились Linux VServer (2001), Solaris Containers (2004) и OpenVZ (2005).
В операционной системе Linux технологии изоляции и виртуализации ресурсов вышли на новый этап в 2002 году, когда в ядро было добавлено первое пространство имен для изоляции файловой системы – mount. В 2006-2007 годах компанией Google был разработан механизм Process Containers (позднее переименованный в cgroups), который позволил ограничить и изолировать использование группой процессов ЦПУ, ОЗУ и др. аппаратных ресурсов. В 2008 году функционал cgroups был добавлен в ядро Linux. Достаточная функциональность для полной изоляции и безопасной работы контейнеров была завершена в 2013 году с добавлением в ядро пространства имен пользователей – user.
В 2008 году была представлена система LXC (LinuX Containers), которая позволила запускать несколько изолированных Linux систем (контейнеров) на одном сервере. LXC использовала для работы механизмы изоляции ядра – namespaces и cgroups. В 2013 году на свет появилась платформа Docker, невиданно популяризовавшая контейнерные технологии за счет простоты использования и широкого функционала. Изначально Docker использовал LXC для запуска контейнеров, однако позднее перешел на собственную библиотеку libcontainer, также завязанную на функционал ядра Linux. Наконец, в 2015 появился проект Open Container Initiative (OCI), который регламентирует и стандартизирует развитие контейнерных технологий по сей день.
Работа с Podman
Podman – это инструмент с открытым исходным кодом для поиска, сборки, передачи и запуска приложений. Является утилитой командной строки с аналогичными docker командами, однако не требует дополнительный сервис для работы и может работать без прав доступа root. По умолчанию использует в качестве Container Runtime crun (ранее runc).
Возможность работать с контейнерами без прав root приводит к нескольким особенностям:
все файлы Podman (образы, контейнеры и др.) пользователей с правами доступа root хранятся в каталоге /var/lib/containers, без прав доступа root – в ~/.local/share/containers
пользователи без root прав по умолчанию не могут использовать привилегированные порты и полноценно использовать некоторые команды
Для установки необходимо воспользоваться официальным руководством – Podman Installation Instructions, которое содержит инструкции для Linux, Windows и Mac. Стоит сразу отметить, что контейнерам для работы необходимы функции ядра Linux, поэтому они работают нативно под Linux, почти нативно в последних версиях Windows благодаря WSL2 (через Linux дистрибутив – не забудьте про wsl --set-default-version 2) и не нативно под Mac (используется виртуализация). Автор рекомендует использовать в тестовой и особенно в промышленной эксплуатации только Linux.
Основные команды
Основные команды для docker идентичны командам для podman, однако есть и приятные доработки (например, ключ --all для команд start, stop, rm, rmi). Формат образов также совместим благодаря спецификации OCI.
Ниже приведены примеры наиболее распространенных команд:
Хранение данных
При запуске контейнер получает доступ на чтение ко всем слоям образа, а также создает свой исполняемый слой с возможностью создавать, обновлять и удалять файлы. Все эти изменения не будут видны для файловой системы хоста и других контейнеров, даже если они используют тот же базовый образ. При удалении контейнера все измененные данные также будут удалены. В большинстве случаев это предпочтительное поведение, однако иногда данные необходимо расшарить между несколькими контейнерами или просто сохранить.
Рассмотрим два способа хранения данных контейнеров:
named volumes – именованные тома хранения данных
Позволяет сохранять данные в именованный том, который располагается в каталоге в /var/lib/containers/storage/volumes или ~/.local/share/containers/storage/volumes и не удаляется при удалении контейнера. Том может быть подключен к нескольким контейнерам
bind mount – монтирование каталога с хоста
Позволяет монтировать файл или каталог с хоста в контейнер. На практике используется для проброса конфигурационных файлов или каталога БД внутрь контейнера
Ниже приведены примеры использования named volume и bind mount:
Создание образов (Containerfile)
Создание и распространение образов – одна из основных задач Podman. Рассмотрим три способа создания образа:
commit изменений из контейнера
Необходимо запустить контейнер из базового образа в интерактивном режиме, внести изменения и сохранить результат в образ с помощью команды commit. На практике способ удобен для небольших быстрых доработок
декларативное описание через Containerfile
Необходимо создать файл Containerfile с декларативным описанием в формате yaml через текстовый редактор и запустить сборку образа командой build. Containerfile и Dockerfile полностью идентичны и взаимозаменяемы
Ниже приведены примеры использования commit и build:
Обязательно пробуйте команды на практике, при необходимости прибегая к help или руководствам в Интернете.
Мультиконтейнерные приложения (Podman Compose и Podman Pod)
Podman Compose – это инструмент для декларативного описания и запуска приложений, состоящих из нескольких контейнеров. Фактически Podman Compose есть ни что иное, как реализация Docker Compose для Podman с учетом его особенностей (например, возможности работать с контейнерами без прав доступа root). Он использует yaml файл для настройки сервисов приложения и выполняет процесс создания и запуска всех контейнеров с помощью одной команды.
Podman Pod – это группа из одного или нескольких контейнеров с общим хранилищем и сетевыми ресурсами, а также спецификацией для запуска контейнеров. Концепция подов появилась и реализуется в Kubernetes.
Как пользоваться S-Tools
1. Упаковка файла
Сначала нужно приготовить будущий контейнер – изображение форматов GIF, BMP или аудиофайл формата WAV. Это не самые распространенные форматы. Если в наличии таких не окажется – нужно переконвертировать в них файлы других форматов. Запускаем S-Tools. Перетаскиваем мышкой файл-контейнер в окно утилиты. Там этот файл откроется в виде отдельного окна. В это окно таким же образом перетаскиваем файл, который нужно спрятать. Через несколько секунд S-Tools предложит ввести пароль и выбрать метод шифрования. Вводим пароль в поле «Passphrase» и повторяем его в поле «Verify Passphrase». Жмем кнопку ОК. Через некоторое время в окне S-Tools появится еще одно окно с названием hidden. Это и есть уже упакованный контейнер. Для сохранения результатов нужно щелкнуть по этому окну правой кнопкой мышки, в контекстном меню, которое откроется, выбрать пункт Save as…, указать куда сохранить файл, его имя и нажать кнопку «Сохранить».
Бывает, что S-Tools во время сохранения результатов «съедает» расширение файла. Если созданный контейнер компьютером автоматически не распознается как изображение или аудиофайл, расширение нужно дописать вручную - щелкаем правой кнопкой мышки по файлу, в контекстном меню выбираем «переименовать» и в конце названия файла добавляем .bmp, .jpg или .wav (в зависимости от того, какой тип файла использовался в качестве контейнера).
2. Извлечение файла
Запускаем S-Tools, мышкой перетаскиваем в окно утилиты файл-контейнер. Откроется окно этого файла. Щелкаем по нему правой кнопкой мышки, в контекстном меню выбираем Reveal… Затем вводим пароль и метод шифрования, указанные при упаковке, жмем ОК. Откроется еще одно окно с названием «Revealed Archive», в котором будет отображаться спрятанный файл. Щелчек правой кнопкой мышки по этому файлу, выбираем пункт «Save as», указываем куда извлечь файл, жмем «Сохранить».
НАПИСАТЬ АВТОРУ
Работодатели уже привыкли к тому, что можно не возмещать затраты сотрудникам, использующим свои автомобили, квартиры и другое имущество в служебных целях. Поэтому идея использования личных смартфонов для работы быстро нашла своих адептов.
Но и эта «медаль» двухсторонняя. Сотрудники требуют гарантий, что работодатель не читает их переписку или не смотрит их фотографии. Работодатели в свою очередь против того, чтобы сотрудники делились корпоративными документами в социальных сетях или передавали их в СМИ.
В этой статье мы расскажем о том, какие существуют технологии контейнеризации и можно ли с их помощью эффективно разделить корпоративные и личные данные на мобильных устройствах.
3. Как организовать формирование электронных дел?
Сделать это можно двумя способами:
● в информационных системах, являющихся источниками электронных документов;
● в архивной системе.
Независимо от того, какой вариант вы выберете, нужно предусмотреть в номенклатуре дел организации возможность их формирования в электронном виде.
ВНИИДАД предлагает выделять электронные дела. Но при этом правила такие же, как для документов на бумажных носителях — никаких особенностей на этот случай нет.
«При включении заголовков электронных дел в номенклатуру дел индексы электронного дела и заголовки электронных дел составляются по тем же правилам, что и индексы и заголовки дел с документами на бумажном носителе».
Но особенности есть. Системы-источники генерируют для передачи в архив большое число документов. Поэтому для автоматического формирования дел необходимы четкие критерии.
При разработке номенклатуры дел нужно:
1. Учесть, какое подразделение будет являться владельцем дела (несколько владельцев у дела быть не может — см. следующий вопрос).
2. Сопоставить дела и виды документов, используемые в организации.
3. Выделить критерии для автоматического отнесения ЭД к делам (в качестве таких критериев могут использоваться подразделение-владелец документа, его вид и дата).
Так формируются электронные дела
6. Предоставление электронных документов из архива. Что и в каком виде предоставлять?
Документы передают в архив не только для обеспечения их сохранности, но и чтобы при необходимости получить информацию из них. В случае с бумажными экземплярами предоставляются копии, справки, выписки. Реже это может быть оригинал документа, хранящийся в деле.
По похожему принципу можно построить работу в архивной системе. Так же делаются справки и выписки, только делопроизводитель использует электронные документы, а поиск проще, быстрее и больше возможностей.
Чтобы предоставить электронный документ из архивной системы, можно выдать доступ для просмотра файла в человекочитаемом виде из контейнера ЭД.
Также можно предоставить электронный документ за рамками архивной системы. Есть два варианта:
● в виде бумажной копии — распечатать и заверить её работником архива;
● выгрузить контейнер электронного документа (или его части, например, файлов ЭД и электронной подписи) и передать его на физически обособленном носителе, хотя можно и онлайн.
Важно: сам контейнер ЭД продолжает храниться в архивной системе — выгружается лишь его копия. Её верность подтверждается отсоединённой электронной подписью архива организации (см. Рекомендации ВНИИДАД). При этом контроль за предоставлением электронного документа можно автоматизировать.
Читайте также: