С восходом социальных приложений, таких, как Facebook, Instagram, YouTube и многих других, управление сгенерированным пользователями контентом стало проблемой, а проблемы нужно решать. Amazon AWS S3, Google Storage, Rackspace Cloud Files и другие похожие сервисы стали появляться, как грибы после дождя, чтобы помочь разработчикам приложений решить актуальную проблему – управление масштабируемым хранилищем активов. И конечно же все они используют “Облако”!
Проблема
Популярные социальные приложения, научные приложения и приложения генерирующие медиа контент способны генерировать гигантское количество информации за короткий промежуток времени. Вот вам пару примеров:
- 72 часа видео загружаются на YouTube пользователями каждую минуту. (источник)
- 20 миллионов фотографий загружаются в SnapChat каждый день. (источник)
- Pinterest сохранил 8 миллиардов объектов и 410 терабайт данных со времени своего запуска в 2009. (источник)
- Twitter генерирует приблизительно 12 терабайт данных в день. (источник)
Когда ваше приложение начинает сохранять огромное количество контента, который сгенерировали ваши пользователи, ваша команда должна будет решить, куда инвестировать своё время для решения этой задачи. Если ваше приложение построено таким образом, чтобы размещать активы на вашем железе/инфраструктуре, ваша команда потратит кучу времени и денег пытаясь эффективно хранить и управлять активами. Как вариант вы можете сохранять активы у облачного провайдера хранилищ. Выбрав этот путь вы сможете позволить контенту приложений масштабироваться почти безгранично, платя только за используемое место и ресурсы для подачи этого контента. Как следствие, облачное хранение данных развяжет руки вашим инженерам и позволит сконцентрироваться на создание уникальных приложений, вместо придумывания велосипеда, когда масштабируемость станет проблемой.
Когда стоило бы задуматься об использовании облачных хранилищ для вашего приложения?
- Когда контент, генерируемый вашими пользователями, является частью приложения. Позволяет ли ваше приложение пользователям загружать файлы? Генерирует ли приложение файлы на стороне сервера? Если приложение будет принимать файлы или сгенерированный контент будет храниться в файловой системе, вам рано или поздно придётся задуматься об облачном хранении данных.
- Когда вашему приложению тесно на одном сервере. Если ваше приложение достаточно компактно, чтобы работать на одном сервере или веб хосте и вы не ожидаете изменений, хранить активы в облаке не имеет смысла. Можно настроить их хранение в локальной файловой системе и забыть об этом. Если же вы замечаете, что вам понадобиться второй сервер приложений, вы сразу можете пожинать плоды и прелести облачного хранения активов. Вы сможете горизонтально масштабировать свой сервис на неограниченное количество серверов приложений без необходимости реплицировать вашу файловую систему активов на новых серверах. Так как ваши активы будут храниться централизованно, они будут досягаемы с любого места, в независимости от количества серверов на которых будет работать ваше приложение.
- Когда для вашей команды важнее сконцентрироваться на разработке возможностей вашей программы, которые являются критическими для вашего бизнеса, нежели на разработке масштабируемой файловой системы. Если у вас мало либо денег, либо времени и вы предвидете рост вашего приложения, облачное хранилище будет беспроигрышным вариантом. Оно даст вам возможность быстро развёртывать приложение и масштабировать его по мере необходимости.
Интеграция и доступ
Большинство лидирующих облачных хранилищ предоставляет доступ через свой API позволяя разработчикам интегрировать облачное хранение активов в свое приложение. Ниже мы взглянем на несколько примеров кода с использованием SDK или библиотеки для хранения активов на Amazon S3.
Ruby & Carrierwave
Примеры кода адаптированы из репозитория CarrierWave.
- Установим CarrierWave: gem install carrierwave или в ваш gemfile gem 'carrierwave'
- Установим Fog: gem install fog или в ваш gemfile gem «fog», "~> 1.3.1"
- Добавьте в файл инициализации следующее:
CarrierWave.configure do |config| config.fog_credentials = { :provider => 'AWS', # required :aws_access_key_id => 'xxx', # required :aws_secret_access_key => 'yyy', # required :region => 'eu-west-1' # optional, defaults to 'us-east-1' } config.fog_directory = 'имя_папки' config.fog_public = false config.fog_attributes = {'Cache-Control'=>'max-age=315576000'} config.asset_host = 'https://assets.example.com’ end - Создайте uploader класс:
class AvatarUploader < CarrierWave::Uploader::Base storage :fog end - Использование uploader напрямую:
uploader = AvatarUploader.new uploader.store!(my_file) uploader.retrieve_from_store!('my_file.png') - Использование вашего uploader с ActiveRecord:
Добавьте поле в свою таблицу базы данных и потребуйте CarrierWave:add_column :users, :avatar, :string in a database migration file require 'carrierwave/orm/activerecord' in your model file. - Подсоедените свой uploader к модели:
class User < ActiveRecord::Base mount_uploader :avatar, AvatarUploader end - Работа с моделью и файлами:
u = User.new u.avatar = params[:file] u.avatar = File.open('somewhere') u.save! u.avatar.url # => '/url/to/file.png' u.avatar.current_path # => 'path/to/file.png' u.avatar.identifier # => 'file.png'
Вот примеры использования CarrierWave для загрузки на Amazon S3, Rackspace Cloud Files и Google Storage, а также несколько джемов для ORM, таких, как DataMapper, Mongoid and Sequel.
PHP & AWS SDK
Amazon предоставляет PHP SDK для работы с AWS API и сервисами. Для этого примера мы будем использовать инструкции из SDK репозитория README.
- Скопируйте содержимое config-sample.inc.php и добавьте свои полномочия, как указано в файле.
- Переместите ваш файл в ~/.aws/sdk/config.inc.php.
- Не забудьте, что getenv(‘HOME’) должен указывать на вашу пользовательскую папку. Иначе вам нужно указать это putenv('HOME=<ваша-пользовательская-папка>')
// инстанцировать AmazonS3 класс $s3 = new AmazonS3(); // создаём новый s3 bucket для загрузки $bucket = 'НАЗВАНИЕ-ВАШЕГО-BUCKET' . strtolower($s3->key); if (!$s3->if_bucket_exists($bucket)) { $response = $s3->create_bucket($bucket,AmazonS3::REGION_US_E1); if (!$response->isOK()) die('Could not create `' . $bucket . '`.'); } // Скачиваем общественный объект. $response = $s3->get_object('aws-sdk-for-php', 'some/path-to-file.ext',array( 'fileDownload' => './local/path-to-file.ext' )); // Загружаем объект. $response = $s3->create_object($bucket, 'some/path-to-file.ext', array( 'fileUpload' => './local/path-to-file.ext' ));
Node & Knox
Для Node.js я адаптировал пример кода из Knox Amazon S3 клиента на Github.
// конфигурируем клиент
var client = knox.createClient({
key: '<api-key-here>'
, secret: '<secret-here>'
, bucket: 'BUCKET-NAME'
});
// загружаем файл на S3
client.putFile('some/path-to-file.ext', 'bucket/file-name.ext', function(err, res){
// Logic
});
// Скачиваем файл из S3
client.get('/some/path-to-file.ext’).on('response', function(res){
console.log(res.statusCode);
console.log(res.headers);
res.setEncoding('utf8');
res.on('data', function(chunk){
console.log(chunk);
});
}).end();
// Стираем файл из S3
client.del('/some/path-to-file.ext’).on('response', function(res){
console.log(res.statusCode);
console.log(res.headers);
}).end();
Вывод
Как вы видите, работать с AWS S3 APIs крайне просто и существует куча доступных библиотек для большинства языков. Я бы рекомендовал взглянуть на облачные хранилища при разработке своего будущего проекта. Вы сэкономите себе время не изобретая новые решения размещения активов и вам будет предоставлена практически неограниченная возможность масштабирования облачного хранилища.
Автор: slainte
