One place for hosting & domains

      ActiveStorage

      How To Use ActiveStorage in Rails 6 with DigitalOcean Spaces


      The author selected the Diversity in Tech fund to receive a donation as part of the Write for DOnations program.

      Introduction

      When you’re building web applications that let users upload and store files, you’ll want to use a scalable file storage solution. This way you’re not in danger of running out of space if your application gets wildly popular. After all, these uploads can be anything from profile pictures to house photos to PDF reports. You also want your file storage solution to be reliable so you don’t lose your important customer files, and fast so your visitors aren’t waiting for files to transfer. ou’ll want this all to be affordable too.

      DigitalOcean Spaces can address all of these needs. Because it’s compatible with Amazon’s S3 service, you can quickly integrate it into a Ruby on Rails application using the new ActiveStorage library that ships with Rails 6.

      In this guide, you’ll configure a Rails application, so it uses ActiveStorage with DigitalOcean Spaces. You’ll then run through the configuration necessary to get uploads and downloads blazing fast using direct uploads and Spaces’ built-in CDN (Content Delivery Network).

      When you’re finished, you’ll be ready to integrate file storage with DigitalOcean spaces into your own Rails application.

      Prerequisites

      Before you begin this guide, you’ll need the following:

      Step 1 — Getting the Sample App Running

      Rather than build a complete Rails application from scratch, you’ll clone an existing Rails 6 application that uses ActiveStorage and modify it to use DigitalOcean Spaces as its image storage backend. The app you’ll work with is Space Puppies, an image gallery that will let people upload and view photographs of their favorite puppies. The application looks like the following figure:

      The Space Puppies application running in a web browser

      Open your terminal and clone the application from GitHub with the following command:

      • git clone https://github.com/do-community/space-puppies

      You’ll see output that looks similar to this:

      Output

      Cloning into 'space-puppies'... remote: Enumerating objects: 122, done. remote: Counting objects: 100% (122/122), done. remote: Compressing objects: 100% (103/103), done. remote: Total 122 (delta 3), reused 122 (delta 3), pack-reused 0 Receiving objects: 100% (122/122), 163.17 KiB | 1018.00 KiB/s, done. Resolving deltas: 100% (3/3), done.

      Next, check your Ruby version. Space Puppies uses Ruby 2.7.1, so run rbenv versions to check which version you have installed:

      If you’ve followed the prerequisite tutorials, you’ll only have Ruby 2.5.1 in that list, and your output will look like this:

      Output

      * system 2.5.1

      If you don’t have Ruby 2.7.1 in that list, install it using ruby-build:

      Depending on your machine’s speed and operating system, this might take a while. You’ll see output that looks like this:

      Output

      Downloading ruby-2.7.1.tar.bz2... -> https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.1.tar.bz2 Installing ruby-2.7.1... Installed ruby-2.7.1 to /root/.rbenv/versions/2.7.1

      Change to the space-puppies directory:

      rbenv will automatically change your Ruby version when you enter the directory. Verify the version:

      You’ll see output similar to the following:

      Output

      ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]

      Next, you will install the Ruby gems and JavaScript packages that the app needs to run. Then you’ll the database migrations needed for the Space Puppies app to run.

      Install all the necessary gems using the bundle command:

      Then, to tell rbenv about any new binaries installed by Bundler, use the rehash command:

      Next, tell yarn to install the necessary JavaScript dependencies:

      Now create the database schema with Rails’ built-in migration tool:

      With all the libraries installed and the database created, start the built-in web server with the following command:

      Note: By default, rails s only binds to the local loopback address, meaning you can only access the server from the same computer that runs the command. If you’re running on a Droplet and you’d like to access your server from a browser running on your local machine, you’ll need to tell the Rails server to respond to remote requests by binding to 0.0.0.0. You can do that with this command:

      Your server starts, and you’ll receive output like this:

      Output

      => Booting Puma => Rails 6.0.3.2 application starting in development => Run `rails server --help` for more startup options Puma starting in single mode... * Version 4.3.5 (ruby 2.7.1-p83), codename: Mysterious Traveller * Min threads: 5, max threads: 5 * Environment: development * Listening on tcp://127.0.0.1:3000 * Listening on tcp://[::1]:3000 Use Ctrl-C to stop

      Now you can access your application in a web browser. If you’re running the application on your local machine, navigate to http://localhost:3000. If you’re running on a Droplet or other remote server, then navigate to http://your_server_ip:3000.

      You’ll see the app’s interface, only this time without any puppies. Try adding a couple of images by clicking the New Puppy button.

      The Space Puppies application running in a web browser

      If you need puppy photos to use for testing, Unsplash has an extensive list you can use for testing. Review the Unsplash license if you plan to use these images in your projects.

      Before moving on, let’s walk through each layer of the application and look at how ActiveStorage works with each part so you can make the necessary changes for DigitalOcean Spaces. For a more detailed look at ActiveStorage, read the Active Storage Overview page in the official Rails documentation.

      First, look at the model, which represents an object in your application that you’re storing in the database. You’ll find the Puppy model in app/models/puppy.rb. Open this file in your text editor and you’ll see this code:

      app/models/puppy.rb

      class Puppy < ApplicationRecord
      
        has_one_attached :photo
      
      end
      

      You’ll find the has_one_attached macro in the model, which indicates there’s a photo attached to each Puppy model instance. These photos will be stored as ActiveStorage::Blob instances via an ActiveStorage::Attached::One proxy.

      Close this file.

      The next layer up the stack is the controller. In a Rails application, the controller is responsible for controlling access to database models and responding to requests from the user. The corresponding controller for the Puppy model is the PuppiesController which you will find in app/controllers/puppies_controller.rb. Open this file in your editor and you’ll see the following code:

      app/controllers/puppies_controller.rb

      class PuppiesController < ApplicationController
      
        def index
          @puppies = Puppy.with_attached_photo
        end
      
        # ... snipped other actions ...
      
      end
      

      Everything in the file is standard Rails code, apart from the with_attached_photo call. This call causes ActiveRecord to load all of the associated ActiveStorage::Blob associations when you fetch the list of Puppy models. This is a scope that ActiveStorage provides to help you avoid an expensive N+1 database query.

      Finally, let’s look at the views, which generate the HTML your application will send to the user’s browser. There are a few views in this app, but you’ll want to focus on the view responsible for showing the uploaded puppy image. You’ll find this file at app/views/puppies/_puppy.html.erb. Open it in your editor, and you’ll see code like this:

      app/views/puppies/_puppy.html.erb

      <div class="puppy">
        <%= image_tag puppy.photo.variant(resize_to_fill: [250, 250]) %>
      </div>
      

      ActiveStorage is designed to work with Rails, so you can use the built-in image_tag helper to generate a URL that points to an attached photo, wherever it happens to be stored. In this case, the app is using the variant support for images. When the user first requests this variant, ActiveStorage will automatically use ImageMagick via the image_processing gem, to generate a modified image fitting our requirements. In this case, it will create a puppy photo filling a 250x250 pixel box. The variant will be stored for you in the same place as your original photo, which means you’ll only need to generate each variant once. Rails will serve the generated version on subsequent requests.

      Note: Generating image variants can be slow, and you potentially don’t want your users waiting. If you know you’re going to need a particular variant, you can eagerly generate it using the .processed method:

      puppy.photo.variant(resize_to_fill: [250, 250]).processed
      

      It’s a good idea to do this kind of processing in a background job when you deploy to production. Explore Active Job and create a task to call processed to generate your images ahead of time.

      Now your application is running locally, and you know how all the code pieces fit together. Next, it’s time to set up a new DigitalOcean Space so you can move your uploads to the cloud.

      Step 2 — Setting up your DigitalOcean Space

      At the moment, your Space Puppies application stores images locally, which is fine for development or testing, but you almost certainly don’t want to use this mode in production. In order to scale the application horizontally by adding more application server instances, you’d need copies of each image on every server.

      In this step, you’ll create a DigitalOcean Space to use for your app’s images.

      Sign in to your DigitalOcean management console, click Create in the top right, and choose Spaces.

      Pick any data center and leave the CDN disabled for now; you’ll come back to this later. Ensure the file listing is set to Restrict File Listing.

      Choose a name for your Space. Remember that this will have to be unique across all Spaces users, so pick a unique name, like yourname-space-puppies. Click Create a Space:

      A screenshot of the DigitalOcean create space form with a name filled  in

      Warning: Be careful about access to the files you store on behalf of your customers. There have been many examples of data leaks and hacks due to misconfigured file storage. By default, ActiveStorage files are only accessible if you generate an authenticated URL, but it’s worth being vigilant if you’re dealing with customer data.

      You’ll then see your brand new Space.

      Click the Settings tab and take a note of your Space’s endpoint. You’ll need that when you configure your Rails application.

      Next, you’ll configure the Rails application to store ActiveStorage files in this Space. To do that securely, you need to create a new Spaces Access Key and Secret.

      Click API in the left navigation, then click Generate New Key in the bottom right. Give your new key a descriptive name like “Development Machine”. Your secret will only appear once, so be sure to copy it somewhere safe for a moment.

      A screenshot showing a Spaces access key

      In your Rails app, you’ll need a secure way to store that access token, so you’ll use Rails’ secure credential management feature. To edit your credentials, execute the following command in your terminal:

      • EDITOR="nano -w" rails credentials:edit

      This generates a master key and launches the nano editor so you can edit the values.

      In nano, add the following to your credentials.yml file, using your API key and secret from DigitalOcean:

      config/credentials.yml

      digitalocean:
        access_key: YOUR_API_ACCESS_KEY
        secret: YOUR_API_ACCESS_SCRET
      

      Save and close the file (Ctrl+X, then Y, then Enter), and Rails will store an encrypted version that’s safe to commit to source control in config/credentials.yml.enc.

      You will see output like the following:

      Output

      Adding config/master.key to store the encryption key: RANDOM_HASH_HERE Save this in a password manager your team can access. If you lose the key, no one, including you, can access anything encrypted with it. create config/master.key File encrypted and saved.

      Now that you’ve configured your credentials, you’re ready to point your app to your new Spaces bucket.

      Open the file config/storage.yml in your editor and add the following definition to the bottom of that file:

      config/storage.yml

      digitalocean:
        service: S3
        endpoint: https://your-spaces-endpoint-here
        access_key_id: <%= Rails.application.credentials.dig(:digitalocean, :access_key) %>
        secret_access_key: <%= Rails.application.credentials.dig(:digitalocean, :secret) %>
        bucket: your-space-name-here
        region: unused
      

      Note that the service says S3 rather than Spaces. Spaces has an S3-compatible API, and Rails supports S3 natively. Your endpoint is https:// followed by your Space’s endpoint, which you copied previously, and the bucket name is the name of your Space, which you entered when creating it. The bucket name is also displayed as the title in your Control Panel when you view your Space.

      This configuration file will be stored unencrypted, so instead of entering your access key and secret, you’re referencing the ones you just entered securely in credentials.yml.enc.

      Note: DigitalOcean uses the endpoint to specify the region. However, you need to provide the region, or ActiveStorage will complain. Since DigitalOcean will ignore it, you can set it to whatever value you’d like. The value unused in the example code makes it clear that you’re not using it.

      Save the configuration file.

      Now, you need to tell Rails to use Spaces for your file storage backend instead of the local file system. Open config/environments/development.rb in your editor and change the config.active_storage.service entry from :local: to :digitalocean:

      config/environments/development.rb

      
        # ...
      
        # Store uploaded files on the local file system (see config/storage.yml for options).
        config.active_storage.service = :digitalocean
      
        # ... 
      

      Save the file and exit your editor. Now start your server again:

      Visit http://localhost:3000 or http://your server ip:3000 in a browser once again.

      Upload some images, and the app will store them in your DigitalOcean Space. You can see this by visiting your Space in the DigitalOcean console. You will see the uploaded files and variants listed:

      files uploaded to a Space

      ActiveStorage uses random filenames by default, which is helpful when protecting uploaded customer data. Metadata, including the original filename, is stored in your database instead.

      Note: If you are getting an Aws::S3::Errors::SignatureDoesNotMatch, that might mean your credentials are incorrect. Run rails credentials:edit again and double-check them.

      Rails stores the names and some metadata about your files as ActiveStorage::Blob records. You can access the ActiveStorage::Blob for any of your records by calling an accessor method named after your attachment. In this case, the attachment is called photo.

      Try it out. Start a Rails console in your terminal:

      Grab the blob from the last puppy photo you uploaded:

      > Puppy.last.photo.blob
      #=> => #<ActiveStorage::Blob ...>
      

      You now have a Rails Application storing uploads in a scalable, reliable, and affordable object store.

      In the next two steps, you’ll explore two optional additions you can make to the app that will help improve this solution’s performance and speed for your users.

      Step 3 — Configuring the Spaces CDN (Optional)

      Note: For this step, you will need a doman with name servers pointing to DigitalOcean. You can follow the How to Add Domains guide to do that.

      Using a Content Delivery Network (CDN) will allow you to provide faster downloads of files for your users by locating copies of the files closer to them.

      You can investigate CDN performance using a tool like Uptrends CDN Performance Check. If you add the URL for one of the photos you uploaded in the previous step, you’ll see things are fast if you happen to be nearby, but things get a little slower as you move away geographically. You can get the URL using the Developer Tools in your browser, or by starting a Rails console (rails c) and calling service_url on an attachment.

      > Puppy.last.photo.service_url
      

      Here’s an example Uptrends report with a file located in the San Francisco data center. Notice that the times decrease depending on the distance from San Francisco. San Diego has a short time, while Paris has a much longer time:

      An example Uptrends CDN Performance Report

      You can improve speeds by enabling Spaces’ built-in CDN. Go to Spaces in your DigitalOcean Control Panel and click the name of the Space you created in Step 2. Next, choose the Settings tab and click Edit next to CDN (Content Delivery Network), then click Enable CDN.

      Now you need to choose a domain to use for your CDN and create an SSL Certificate for the domain. You can do this automatically using Let’s Encrypt. Click the Use a custom subdomain dropdown and then Add a new subdomain certificate.

      Find the domain you’d like to use, then choose the option to create a subdomain. Something like cdn.yourdomain.com is a standard naming convention. You can then give the certificate a name and click the “Generate Certificate and Use Subdomain” button.

      The filled-in Add Custom Subdomain form

      Press the Save button under CDN (Content Delivery Network).

      Your CDN is now enabled, but you need to tell your Rails Application to use it. This isn’t built into ActiveStorage in this version of Rails, so you’ll override some built-in Rails framework methods to make it work.

      Create a new Rails initializer called config/initializers/active_storage_cdn.rb and add the following code which will rewrite the URLs:

      config/initializers/active_storage_cdn.rb

      Rails.application.config.after_initialize do
        require "active_storage/service/s3_service"
      
        module SimpleCDNUrlReplacement
          CDN_HOST = "cdn.yourdomain.com"
      
          def url(...)
            url = super
            original_host = "#{bucket.name}.#{client.client.config.endpoint.host}"      
            url.gsub(original_host, CDN_HOST)
          end
        end
      
        ActiveStorage::Service::S3Service.prepend(SimpleCDNUrlReplacement)
      end
      

      This initializer runs each time your application asks for a URL from an ActiveStorage::Service::S3Service provider. It then replaces the original, non-CDN host with your CDN host, defined as the CDN_HOST constant.

      You can now restart your server, and you’ll notice that each of your photos comes from the CDN. You won’t need to re-upload them, as DigitalOcean will take care of forwarding the content from the data center where you set up your Space out to the edge nodes.

      You might like to compare the speed of accessing one of your photos on Uptrends’ Performance Check site now to the pre-CDN speed. Here’s an example of using the CDN on a San Francisco-based Space. You can see a significant global speed improvement.

      The Uptrends CDN Performance Report after enabling the CDN

      Next you’ll configure the application to receive files directly from the browser.

      Step 4 — Setting up Direct Uploads (Optional)

      One last feature of ActiveStorage that you might like to consider is called a Direct Upload. Now, when your users upload a file, the data is sent to your server, processed by Rails, then forwarded to your Space. This can cause problems if you have many simultaneous users, or if your users are uploading large files, as each file will (in most cases) use a single app server thread for the entire duration of an upload.

      By contrast, a Direct Upload will go straight to your DigitalOcean Space with no Rails server hop in between. To do this, you’ll enable some built-in JavaScript that ships with Rails and configure Cross-Origin Resource Sharing([CORS]((https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) on your Space so that you can securely send requests directly to the Space despite them originating in a different place.

      First, you’ll configure CORS for your Space. You will use s3cmd to do this, and you can follow Setting Up s3cmd 2.x with DigitalOcean Spaces if you haven’t configured this to work with Spaces yet.

      Create a new file called cors.xml and add the following code to the file, replacing your_domain with the domain you’re using for development. If you are developing on your local machine, you’ll use http://localhost:3000. If you’re developing on a Droplet, this will be your Droplet IP address:

      cors.xml

      <CORSConfiguration>
       <CORSRule>
         <AllowedOrigin>your_domain</AllowedOrigin>
         <AllowedMethod>PUT</AllowedMethod>
         <AllowedHeader>*</AllowedHeader>
         <ExposeHeader>Origin</ExposeHeader>
         <ExposeHeader>Content-Type</ExposeHeader>
         <ExposeHeader>Content-MD5</ExposeHeader>
         <ExposeHeader>Content-Disposition</ExposeHeader>
         <MaxAgeSeconds>3600</MaxAgeSeconds>
       </CORSRule>
      </CORSConfiguration>
      

      You can then use s3cmd to set this as the CORS configuration for your Space:

      • s3cmd setcors cors.xml s3://your-space-name-here

      There’s no output when this command runs successfully, but you can check that it worked by looking at your Space in the DigitalOcean Control Panel. Choose Spaces, then select the name of your Space, then select the Settings tab. You’ll see your configuration under the CORS Configurations heading:

      A successful CORS configuration for direct uploads

      Note: At the moment you need to use s3cmd rather than the Control Panel to configure CORS for “localhost” domains because the Control Panel treats these as invalid domains. If you’re using a non-localhost domain (like a Droplet IP) it’s safe to do it here.

      Now you need to tell Rails to use direct uploads, which you do by passing the direct_upload option to the file_field helper. Open app/views/puppies/new.html.erb in your editor and modify the file_field helper:

      app/views/puppies/new.html.erb

      <h2>New Puppy</h2>
      
      <%= form_with(model: @puppy) do |f| %>
      
        <div class="form-item">
          <%= f.label :photo %>
          <%= f.file_field :photo, accept: "image/*", direct_upload: true %>
        </div>
      
        <div class="form-item">
          <%= f.submit "Create puppy", class: "btn", data: { disable_with: "Creating..." } %>
        </div>
      
      <% end %>
      

      Save the file and start your server again:

      When you upload a new photo, your photo is uploaded directly to DigitalOcean Spaces. You can verify this by looking at the PUT request that’s made when you click the Create puppy button. You can find the requests by looking in your browser’s web console, or by reading the Rails server logs. You’ll notice that the image upload is significantly faster, especially for larger images.

      Conclusion

      In this article you modified a basic Rails application using ActiveStorage to store files that are secure, fast, and scalable on DigitalOcean Spaces. You configured a CDN for fast downloads no matter where your users are located, and you implemented direct uploads so that your app servers will not be overwhelmed.

      You can now take this code and configuration and adapt it to fit your own Rails application.



      Source link