DEV Community: Fernando Menolli

MinIO + Rails Active Storage

Fernando Menolli — Mon, 31 Jul 2023 23:24:46 +0000

Currently, at the company I work for, we are working on rebuilding some modules of older applications. During this process, we decided to replace CarrierWave (a system we used for avatar uploads, for example) with Active Storage, as we believe it better suits our needs.

To understand the differences between the CarrierWave gem and Active Storage, I recommend reading two excellent articles:
From CarrierWave to Active Storage
and
Active Storage in production: lessons learned and in-depth look at how it works

Once the decision to use Active Storage was made, we needed to consider the method or service for storing these files. This is important because we have other applications that also need to load these files. An important point is that we have powerful local servers available, so if possible, we would prefer to use these servers instead of a service like Amazon S3 or Azure for example. This led us to choose Min.io, and this is what this article will talk about.

Min.io is a high-performance, distributed object storage system designed for large-scale private cloud infrastructure. The great advantage is that it is fully compatible with Amazon S3.

To use Min.io, all we have to do is configure Active Storage through config/storage.yml as if we were using S3, but point it to a different endpoint, which will be our server running MinIO. In our example, the endpoint will be our own machine, so we will use localhost.

Running MinIO

In our example, we will run MinIO directly on our machine (Linux), but it is also possible to run it using Docker, Kubernetes, or other non-Linux operating systems. For more information, refer to the Min.io documentation.

After installing MinIO as following the instructions in documentation, we can start the server with the following command: minio server ~/minio. We will know the server is running when our terminal displays the following information:

MinIO Object Storage Server
Copyright: 2015-2023 MinIO, Inc.
License: GNU AGPLv3 <https://www.gnu.org/licenses/agpl-3.0.html>
Version: RELEASE.2023-07-21T21-12-44Z (go1.19.11 linux/amd64)

Status: 1 Online, 0 Offline.
S3-API: http://192.168.1.7:9000  http://127.0.0.1:9000
RootUser: minioadmin
RootPass: minioadmin

Console: http://192.168.1.7:36187 http://127.0.0.1:36187
RootUser: minioadmin
RootPass: minioadmin

Command-line: https://min.io/docs/minio/linux/reference/minio-mc.html#quickstart
   $ mc alias set myminio http://192.168.1.7:9000 minioadmin minioadmin

Documentation: https://min.io/docs/minio/linux/index.html
Warning: The standard parity is set to 0. This can lead to data loss.

Accessing MinIO through the browser and creating a bucket

Once our MinIO server is running, we need to create a bucket. To do this, we must access one of the addresses listed in our terminal from the previous step; let's use http://127.0.0.1:9000. We will log in to the system using the username and password minioadmin, and in the menu, we will go to the Bucket option and create a new bucket. In our case, we will name it rails-bucket.

Configuring `config/storage.yml`

With everything set up, we will now configure the 'config/storage.yml' file to make everything work. We will configure it as if we were using S3 as the service but add a different endpoint. Our configuration will look like this:

local:
  service: S3
  endpoint: http://127.0.0.1:9000
  access_key_id: minioadmin
  secret_access_key: minioadmin
  region: us-east-1
  bucket: rails-bucket
  force_path_style: true

In this example, I left the access_key_id and secret_access_key visible for didactic purposes, but I recommend using Rails Credentials to store these keys securely. Additionally, it is necessary to include force_path_style: true because otherwise, Active Storage will use a bucket context as a subdomain, and MinIO expects the bucket to be included after the domain.

It is also important to note that we used the name local: for this service in storage.yml, so in our development.rb file, we need to have the same service name in the configurations: config.active_storage.service = :local. If you used a different name in storage.yml, be sure to change it accordingly in development.rb.

Furthermore, we need to add the gem aws-sdk-s3 to our Gemfile.

Everything is now ready, and our application is set to use MinIO together with Active Storage. The next time we upload a file, it will go directly to our bucket in MinIO, on our local server.

I hope this helps! :)

How I use MRSK and multiple Rails app on the same server

Fernando Menolli — Sun, 25 Jun 2023 05:28:04 +0000

Recently, we made the decision to use MRSK to deploy applications at the company I work for. We have a physical server at our disposal, and we found the approach developed by DHH and his team quite interesting.

One of the requirements for using this tool was the ability to deploy multiple applications on the same server. We have several applications here, and it was important for us to be able to access each of them through a subdomain. That's what I'll be discussing in this post.

If you'd like to learn more about MRSK in its entirety, from installation to configuration and deployment, I recommend other excellent articles to guide you:

Creating two applications

To begin, we will create two applications that will be used in the examples. They will be called app1 and app2.

To facilitate the identification of each application, we will create a route and configure it as the root path. In each application, we will have a view that displays "APP1" and "APP2" respectively.

So far, we have two separate applications. When running each of them on our local machine, we get the following results:

Initializing MRSK

At this point, we will prepare our applications for deployment by initializing MRSK in each of them using the command mrsk init. This will generate three files: .env, .mrsk/hooks, and config/deploy.yml. We will focus on the config/deploy.yml file, as it allows us to deploy two applications on the same server.

To perform the deployment, we also need to configure the Dockerfile so that our image can be built. However, as mentioned at the beginning of the article, the complete step-by-step process for deploying using MRSK is not the focus here. Therefore, we will assume that you already know the necessary steps for configuring the Dockerfile.

Configuring the deploy.yml file

Let's configure the deploy.yml file for both applications.

To achieve our goal, it is important to know the exact role of each of our services. In the deploy.yml file, the role is defined below servers:. If no role is defined, MRSK will default it to web.

Example:



# Deploy to these servers.
servers:
  web: # <- Role
    - 10.10.10.10

In the above case, the role of the service will be web.

In the case below, since we haven't defined a role, it will default to web too.



# Deploy to these servers.
servers:
  - 10.10.10.10

That is very important because when we define the rules for each application to communicate with Traefik, we need to specify the role of the service (which will be our container).

Let's see how the Traefik rules will be defined in this file.



# APP1
# Name of your application. Used to uniquely configure containers.
service: app1

# Name of the container image.
image: user/app1

# Deploy to these servers.
servers:
  - 10.10.10.10

# Credentials for your image host.
registry:
  username:
    - MRSK_REGISTRY_USERNAME

  password:
    - MRSK_REGISTRY_PASSWORD

labels:
  traefik.http.routers.app1-web.rule: Host(`app1.demo.com`)

What will make the applications accessible in distinct ways is the labels: tag, which identifies the service: tags and the previously mentioned Role. Note that in labels: tag we have defined this rule for the service with a container identified as app1-web , and in this rule, we specify that we will access this application through the subdomain app1 at the address app1.demo.com.

Now, let's take a look at the deploy.yml file for our second application:



# APP2
# Name of your application. Used to uniquely configure containers.
service: app2

# Name of the container image.
image: user/app2

# Deploy to these servers.
servers:
  - 10.10.10.10

# Credentials for your image host.
registry:
  username:
    - MRSK_REGISTRY_USERNAME

  password:
    - MRSK_REGISTRY_PASSWORD

labels:
  traefik.http.routers.app2-web.rule: Host(`app2.demo.com`)

In the second case, we have the Traefik rule for the app2 service and the web role.

After the deployment

First of all, after we deployed our applications, let's check the status of our Docker containers on the server by running the command docker container ls. Here is the result:



ubuntu@ip-172-31-14-245:~$ docker container ls
CONTAINER ID   IMAGE                                                     COMMAND                  CREATED              STATUS                        PORTS                                       NAMES
4a919eb90e92   user/app1:dc7bfa712ce9c564230c50ab48c2e61542599a43   "./bin/rails server"     About a minute ago   Up About a minute (healthy)   3000/tcp                                    app1-web-dc7bfa712ce9c564230c50ab48c2e61542599a43
9b17c1cb5db0   user/app2:1a517f061829788aeab563a732978c36d6f233d4   "./bin/rails server"     6 minutes ago        Up 6 minutes (healthy)        3000/tcp                                    app2-web-1a517f061829788aeab563a732978c36d6f233d4
157155628e36   traefik:v2.9                                              "/entrypoint.sh --pr…"   34 minutes ago       Up 34 minutes                 0.0.0.0:80->80/tcp, :::80->80/tcp           traefik

Please note that we have two containers for our applications app1 and app2. Additionally, we have a container for Traefik, which is used as a reverse proxy.

Now let's see if it's possible to access both applications at the same time by simply switching the subdomain for each one. Here is the result:

Great!

By following these steps, we have successfully deployed multiple applications using the same target host and separated them effectively.

In this example, if we access the demo.com address, none of the applications will be found, ensuring complete separation between them. This is how we use multiple applications with MRSK in the company I work for, where we have several applications, and all of them are segregated in a similar manner.

This approach allows for better organization, management, and isolation of the applications, ensuring that they can coexist on the same server without conflicts. It also provides a clear and structured way to access each application through distinct subdomains.

I hope I have contributed in some way :)