Running with Ruby

Category: Default (page 2 of 10)

Ruby: Dragonfly gem – auto-orient for all the images

Dragonfly is an awesome image/asset management tool. It is great because of many reasons, but what I love the most, is how it handles thumbnails. You don’t need to specify sizes, or anything else in the models in which you use it. Instead every type of thumbnail can be generated “on the fly”, the first time you access it. For that reason, the original image (by default) is always stored. Unfortunately by default, it will not be auto-oriented based on the picture Exif data. Luckily there’s an easy way out. In your Dragonfly model you need to include an after_assign block with an auto orient command and you are ready to go!

class Picture < ActiveRecord::Base
  extend Dragonfly::Model

  dragonfly_accessor :image do
    after_assign do |attachment|
      # Auto orient all the images - so they will look as they should
      attachment.convert! '-auto-orient'
    end
  end
end

After that all of your images (and all the thumbnails – since you change the original file) will be auto-oriented.

Gitlab, Ruby private repository, Docker container and safe way to add SSH key for build process only

Note

This is not a tutorial on how to use Docker with SSH keys and private repositories. This is a solution to a particular safety issue when building Docker containers.

I won’t get into details on how to create a Dockerfile with a SSH key, etc – there’s enough about that in the Internet.

Problem – container stored SSH key

During the Docker build process, we need a SSH key for bundle install. We need it, because we have a Gitlab with private repositories that we want to pull. Since Docker caches this key, it will go to a production environment together with the whole container. It is unsafe. If someone got somehow into the container, he could use this key to get into your repositories.

Solution – during build only, one-time SSH key pair

This issue can be easily solved. To do so, we need to:

  1. Generate SSH key pair
  2. Add it to our Gitlab instance using Gitlab API
  3. Add private key to Docker
  4. Docker b uild (and bundle install)
  5. Remove/revoke our key from Gitlab
  6. Deploy container

There’s still going to be a SSH key in the container, but it won’t be valid. Since it will be valid only during the build process (which happens on the CI), there’s no risk. The key gets revoked before we deploy container.

Code

For Gitlab API communication we will be using Gitlab API gem.

require 'gitlab'
require 'fileutils'

# I assume you have this script in the same place where your Dockerfile

# You can find your private token on the account page of your gitlab user
Gitlab.configure do |config|
  config.endpoint = 'http://your-gitlab/api/v3'
  config.private_token  = 'deploy/docker gitlab user private token'
end

# Add this if you use self signed SSL cert with Gitlab
OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE

'ssh-keygen -q -t rsa -f ./id_rsa -N ""'

key = Gitlab.create_ssh_key("docker-#{Time.now.to_s}", File.read('./id_rsa.pub'))

# Note that you should provide some sort of failover to remove key if build fails
system('docker build .')

Gitlab.delete_ssh_key(key.id)

FileUtils.rm('./id_rsa')
FileUtils.rm('./id_rsa.pub')
Olderposts Newerposts

Copyright © 2020 Running with Ruby

Theme by Anders NorenUp ↑