Конфигурация BLOB-хранилища
Общая информация
BLOB-хранилище (или хранилище двоичных больших объектов) - это форма хранилища данных, предназначенного для хранения больших объемов неструктурированных данных.
BLOB-хранилища предоставляют возможность размещать внутренне управляемые хранилища статических активов для эффективной обработки больших файлов. Файл конфигурации blob-хранилищ дает пользователям возможность настроить хранилища активов, предоставляя необходимую информацию, специфичную для используемого хранилища.
Для изменения конфигурации BLOB-хранилища:
1. Нажмите на Инструменты сайта на боковой панели.
2. Перейдите в Конфигурация > Хранилище BLOB-объектов.
Образец файла конфигурации
Ниже расположен пример конфигурационного файла хранилища BLOB-объектов:
<?xml version="1.0" encoding="UTF-8"?>
<!--
Blob stores configuration file.
For every store you need to specify:
<blobStore>
<id/>
<type/>
<pattern/>
<mappings>
<mapping>
<publishingTarget/>
<storeTarget/>
<prefix/>
</mapping>
</mappings>
<configuration/>
</blobStore>
id: a unique id for the store
type: the type of store to use
pattern: the regex to match file paths
mappings.mapping.publishingTarget: the name of the publishing storeTarget (preview, staging, live)
mappings.mapping.storeTarget: the name of the storeTarget inside the store
mappings.mapping.prefix: the prefix to use for all paths (optional)
configuration: configuration specific for the store type
Every store can require additional properties.
-->
<blobStores>
<!--
AWS S3 Store
Configuration properties:
<credentials>
<accessKey/>
<secretKey/>
</credentials>
<region/>
<endpoint/>
<pathStyleAccess/>
credentials.accessKey: AWS access key (optional)
credentials.secretKey: AWS secret key (optional)
region: AWS region for the service (optional)
pathStyleAccess: indicates if path style access should be used for all requests (defaults to false)
-->
<blobStore>
<id>s3-store</id>
<type>s3BlobStore</type>
<pattern>/static-assets/s3/.*</pattern>
<mappings>
<mapping>
<publishingTarget>preview</publishingTarget>
<storeTarget>my-authoring-bucket</storeTarget>
<prefix>sandbox</prefix>
</mapping>
<mapping>
<publishingTarget>staging</publishingTarget>
<storeTarget>my-authoring-bucket</storeTarget>
<prefix>staging</prefix>
</mapping>
<mapping>
<publishingTarget>live</publishingTarget>
<storeTarget>my-delivery-bucket</storeTarget>
</mapping>
</mappings>
<configuration>
<credentials>
<accessKey>xxxxxxxxx</accessKey>
<secretKey>xxxxxxxxx</secretKey>
</credentials>
<region>us-west-1</region>
<pathStyleAccess>true</pathStyleAccess>
</configuration>
</blobStore>
</blobStores>
Обеспечьте шифрование ваших учетных данных для повышения безопасности. Для подробных инструкций по управлению или кодированию секретных данных, таких как учетные данные AWS, обратитесь к документации по управлению конфиденциальными данными.
Для повышения безопасности и управления рекомендуется создать профиль AWS с использованием файла переменных окружения, вместо конфигурации зашифрованных учетных данных в файле конфигурации blob-хранилища. Этот подход позволяет создавать учетные записи IAM для каждого разработчика, представляя собой более надежную альтернативу единственному пользователю с зашифрованными учетными данными, встроенными в файл конфигурации. Таким образом, если вам нужно изменить или удалить учетные данные одного пользователя, это не повлияет на доступ других пользователей.
Чтобы настроить профиль AWS, обновите переменную окружения:
export AWS_PROFILE=YOUR_AWS_PROFILE
где YOUR_AWS_PROFILE - это профиль AWS, который вы хотите использовать для хранилища blob-объектов. Смотрите здесь дополнительные сведения о настройке профилей AWS.
При использовании профиля AWS вы можете удалить раздел <credentials /> в файле конфигурации хранилища BLOB-объектов.
Не забудьте перезапустить DC CMS, чтобы внесенные вами изменения вступили в силу
Использование сервисных ролей AWS
DC CMS поддерживает доступ к AWS без использования ключей доступа/секретных ключей через настройку ролей служб AWS на вашем компьютере.
Чтобы сделать это, следуйте указаниям, предоставленным здесь, по привязке роли IAM к вашему экземпляру.
Убедитесь, что вы удалили раздел <credentials /> из файла конфигурации вашего blob-хранилища.
Публикация активов из BLOB-хранилища
DC CMS упрощает управление активами во внешнем хранилище, используя механизмы рабочего процесса и публикации. Это позволяет загружать активы во внешнее хранилище для предварительного просмотра. После этого эти активы могут быть опубликованы либо в рабочее, либо в тестовое окружение во внешнем хранилище. В результате внешние активы становятся доступными для доставки только после прохождения процесса публикации во внешнее хранилище live.
Внешнее хранилище может быть размещено в облаке, таком как AWS S3, или в любом другом внешнем хранилище, не связанном с местоположением установки DC CMS.
Настройка внешнего хранилища
В боковой панели нажмите на Инструменты сайта, а затем перейдите в Конфигурация > Хранилище BLOB-объектов и заполните нужную информацию:
<blobStore>
<id/>
<type/>
<pattern/>
<mappings>
<mapping>
<publishingTarget/>
<storeTarget/>
<prefix/>
</mapping>
</mappings>
<configuration/>
</blobStore>
Подробнее о файле конфигурации BLOB-хранилища можно узнать выше.
После настройки конфигурации хранилища blob-объектов вы можете использовать внешнее хранилище для загрузки, используя различные методы загрузки, предоставляемые CMS Studio, и публикации в режиме реального времени или промежуточной публикации, если это настроено.
Настройка тестового окружения для существующих проектов
При внедрении промежуточной цели публикации (например: staging) в уже существующий проект, который использует внешнее хранилище, CMS Studio не дублирует активы из внешнего хранилища в окружении live в промежуточное окружение (staging). Кроме того, выполнение массовой публикации в промежуточное окружение (staging) в этот момент оказывается неэффективным. Корневая причина заключается в неспособности CMS Studio публиковать активы в промежуточное окружение (staging), когда они находятся в состоянии LIVE и UNEDITED.
Для синхронизации внешнего хранилища для промежуточного окружения (staging) с окружением live, необходимо вручную скопировать активы из внешнего хранилища окружения live во внешнее хранилище промежуточного окружения (staging).
Рассмотрим пример добавления промежуточного окружения (staging) в существующий проект.
Предварительные требования:
-
Убедитесь, что проект создан с использованием шаблона "Web Blog", с настройкой внешнего хранилища для окружения live и уже опубликованными активами в окружении live.
-
Имейте готовый к использованию бакет AWS S3 для промежуточного окружения (staging). В нашем примере мы будем использовать бакет
my-staging, настроенный в AWS S3.
Следуйте этим шагам:
1. Включите промежуточное окружение (staging) в CMS Studio. Для этого на боковой панели нажмите на Инструменты сайта, затем перейдите в Конфигурация > Конфигурация проекта и установите для enable-staging-environment значение true.
<published-repository>
<enable-staging-environment>true</enable-staging-environment>
<staging-environment>staging</staging-environment>
<live-environment>live</live-environment>
</published-repository>
Подробнее о промежуточном (staging) окружении можно узнать здесь.
2. Настройте BLOB-хранилище в CMS Studio. На боковой панели нажмите на Инструменты сайта, затем перейдите в Конфигурация > Хранилище BLOB-объектов и заполните необходимую информацию, чтобы настроить бакет S3 для промежуточного окружения (staging).
<mapping>
<publishingTarget>staging</publishingTarget>
<storeTarget>my-staging</storeTarget>
</mapping>
Узнать подробнее о настройке BLOB-хранилища можно выше.
3. Скопируйте активы из live окружения в промежуточную во внешнем хранилище. В консоли AWS скопируйте содержимое бакета доставки. Вставьте скопированное в промежуточный бакет my-staging. Внешнее хранилище live окружения и промежуточного (staging) окружения теперь синхронизированы.
Связанные статьи 