Drifting Ruby

"Choose Your Own Path"

Dave Kimura — Thu, 20 Feb 2025 03:53:37 GMT

Remember those "Choose Your Own Adventure" books? I loved those as a kid. For those who don't know what they are, they're adventure books that are not meant to be read from front to back. Instead, you read a page or two and then you're left with a few choices. Depending on which option you choose, you can flip to a specific page to continue the story.

Using various LLMs, I was able to dynamically generate my own! The process is fairly simple where you pick the kind of text you want to have generated. Then, background jobs will be kicked off and the content will be generated.

Here's a basic overview of how something like this happens.

Prompt Chaining

But it's actually not so simple. The Title Generation is created off of the various prompts that the user initially selected. Then the Narrative Generation will start creating the text for the story. This is a fairly creative step for the LLM and is given a lot of room to do its thing.

However, the Image Generation step isn't so simple. You cannot simply give the Narrative to the Image Generator and expect good results. Instead, you need to have a prompt for this LLM to generate a somewhat related image. So, Another call to the generative text LLM is made where it feeds in the narrative and is expecting a prompt response that is formatted for Stable Diffusion.

The choices option is also very similar where based on the narrative, a few different options are given. The general nature of generative text LLMs is that they are very bad at following instructions. This is especially true with smaller models. In all of the text generations on this project, I'm using an 8b parameter model. That's super small! The generative text is often chatty and not in a format that can easily be parsed by Ruby. So, instead of trying to design the "perfect" prompt that would work, I make two separate requests. The first request is more on the creative side. I feed in the narrative and with a temperature of 0.7 I ask for a list of options. I then make another request feeding in the response from the previous one and ask the LLM to format this in an array. Since its context is so small, just my request prompt plus the context of the "actions", it's able to handle this fairly well.

By having multiple prompts and chaining the responses, I'm able to consistently get better results even from a small LLM. Not only this, but it's a bit more universal in being able to switch models. If I want to test out a different small model, I can and most often the Choices Generation will still work.

Application/Technology Used

This application is a very vanilla Rails 8 application. I added one gem into the Gemfile that's outside of the provided defaults. There's only two controllers since most of the work happens in the background jobs. Since this is a fresh Rails 8 application, SolidQueue is being used for the background worker and SQLite is being used on the database side. Kamal is being used to deploy this to a VM that I'm self-hosting.

That's basically it. The entire application is under 1000 lines of code. It's missing a lot of features like authentication and authorization. It's also missing some potentially cool features like Inventory tracking, but for a "MVP", I was fairly happy with the results.

The code is also very simple. The most complicated part of the code is creating the HEREDOC for the prompts. There's several prompts that go into this as we've already talked about. The other bits of the code is fairly simple as well. I'm using the ruby-openai gem to communicate with the LLMs. I'm hosting these locally

  def generate
    client.chat(
      parameters: {
        model: Rails.configuration.default_model,
        messages: [ { role: "user", content: @prompt } ],
        temperature: @temperature,
        stream: stream_proc(self)
      }
    )
  end

  private

  def client
    @client ||= OpenAI::Client.new(
      access_token: Rails.configuration.default_ollama_token,
      uri_base: Rails.configuration.default_ollama,
    )
  end

The real-time streaming of the prompt happens from the stream option that's passed into the generation. It's actually quite simple where we basically take and update the existing narrative with the chunked content. This does create a burst of writes to the database, but it's also the most simple and direct approach. If I had to scale this, I would probably do something a bit different where I simply broadcast appending the new content and store everything in an array. Once the stream is finished then I could update the database with the final results.

  def stream_proc(message)
    proc do |chunk, _bytesize|
      new_content = chunk.dig("choices", 0, "delta", "content")
      @scenario.update!(narrative: @scenario.narrative.to_s + new_content.to_s)
    end
  end

The broadcasting, or live updates, is simply handled by ActionCable and turbo streams. No Javascript necessary. Since this is just a hobby project and the most life it'll see is the short days of this post coming out, I'm not too worried about performance. But I would basically have this broadcast function in the model as is, but have another broadcast in the stream_proc. However, this also has some potentials of things getting out of sync. Because, if the jobs are processed out of order (which is very likely to happen), then it will essentially cause text to be inserted out of order. You could get around this by broadcasting the whole array joined together as a string and that would have a much better chance of staying together.

after_save_commit { 
  broadcast_replace_to(
    adventure, 
    target: "scenario_adventure_#{adventure.id}", 
    partial: "adventures/scenario", 
    locals: { scenario: self } 
  )
}

Hardware/GPUs

I am using a fairly massive GPU for this task, but it's really not required. A smaller and significantly less expensive GPU with 16GB of VRAM could do this job all the same. There's also a lot of options out there if you want to use metered-based APIs or other options. I won't recommend any right now, because I typically run all of my LLMs in house.

But, if you're able to get your hands on a RTX 4060 Ti 16GB, you can run quite a bit with the 16GB of VRAM. There's also the RTX 5070 Ti which is being released on Feb 20th, 2025 (tomorrow as of the time of this writing), but the demand for these cards will be high. I'm a big fan of the consumer cards since I'm able to run what I need on them and I'm not doing anything critical.

There's a lot of misconception about the GPUs and what's required with them. In short, if you're running Inference (text generation, image generation, voice generation) then you do not need an insanely fast GPU or GPU PCIe lane bandwidth. Once the model is loaded into video memory, it is the bandwidth between the video memory and the graphics processor that will make the biggest difference. All of this meaning... you can use a PCIe 4.0 slot in 4x mode and still be okay. You won't be running into bottlenecks due to the PCIe lane bandwidth. This is a completely different story if you are fine tuning or training your own model. There is much more exchange that goes on between the GPU and the CPU, so running the full 16x lane becomes much more important.

Wrap up

Here's the link to the Choose Your Own Path if you want to play around with it. Keep in mind that I am hosting this on my local network and using my GPUs for the inference and image generation, so be kind. I likely won't keep this project online indefinitely so tinker around with it while you can!

Choose Your Own Path -> https://cyop.railsapp.dev

asdf 0.16.x

Dave Kimura — Tue, 11 Feb 2025 17:00:05 GMT

Recently, there was an update to asdf which broke my install. I experienced this on macOS, Linux and WSL (which is basically Linux in Windows). This issue was due to asdf being rewritten in GoLang so a lot changed. For those who don't know what asdf is, you can probably just ignore this article. But, basically, it is a runtime version manager, so you can manage various versions of Python, Node, Ruby, Rust, GoLang and more. I use to use rvm for many years, but as my needs grew, I looked for other toolings and landed with asdf.

You can read about the releases notes here and upgrade guide here.

But, to sum up the major changes that I experienced and how I upgraded from < 0.16.x to 0.16.x, keep reading.

Fixing my install

On my macOS computer, I normally run brew upgrade and most often, it doesn't cause any problems. I like finding out these kinds of issues early on so that I can address them before I'm blindsided when working on something critical. So, I make it a habit to only run updates when there is a critical vulnerability patch or if I know that there is time to troubleshoot any kind of issues.

Thankfully, this was one of those routine maintenance times because I noticed that after I upgraded to asdf, my Ruby Interpreter was no longer working as expected.

The first hint that something was wrong with asdf was an error message when I launched a new terminal. Side note: Typically, I do not modify my .bashrc or .zshrc files, but instead will put all of my config in a .devrc as you see in the image below. In my .zshrc file, I'll source this dot file with source ~/.devrc.

This error message clearly pointed to an issue with asdf which began my troubleshooting. I first went to see what version of Ruby I was using by default now. To my surprise, it was using the version that ships with macOS instead of my asdf version.

So, I did some research and found the upgrade guide and release notes that I linked above. There was a lot of information in there so I'm going to give the TLDR version here.

You'll need to update your dot file (.zshrc, .bashrc, or .devrc) and remove the original line. Luckily the error message tells you what line this happened on so it was easy enough to spot. But, you'll then want to add the following:

export ASDF_DATA_DIR="$HOME/.asdf"
export PATH="$ASDF_DATA_DIR/shims:$PATH"

Once you save the file and close it. It's best to start up a new terminal. You could always run source .devrc but in some situations, I do not find that to always work. So, let's just assume that you launch a new terminal and then try to get the Ruby version again.

Luckily, there's no errors this time and the Ruby version returns the correct one that I installed via asdf.

Other TL;DR; on the new changes with `asdf`

There are some other things that have changed.

asdf list-all

has now become

asdf list all

So, the - 's have been removed from the commands.

Also, I use to be able to set my global versions with a command like

asdf global ruby 3.4.1

but this has also changed to

asdf set --home ruby 3.4.1

And that's pretty much it

Luckily this change with asdf didn't cause an all day problem. It was pretty quick to resolve, but it did take some investigative work. It's not often that we see a patch version have such a significant impact, but they definitely can as we have so clearly seen in this update.

I should also say that I'm incredibly grateful to the development community and those who have put time and effort into these version managers. They make life so much easier. The point of this post isn't to bash on their works at all, but rather to share an experience that I had.

Kamal 2.0 Issue with AWS ALB

Dave Kimura — Fri, 27 Sep 2024 02:49:45 GMT

I created a Github Issue on the Kamal Repo for visibility as this problem wasn't clear. There were definitely hints as to what the problem was, but it wasn't a straight forward solution. Well, actually, in hindsight, it did seem pretty logical. However, at the time when you're getting that scary image on your screen when you refresh for the first time after an upgrade.

Panic can set in and logical thinking can go right out the window.

Upgrade Process

My upgrade process for Kamal was fairly simple. I tested it out on a local environment to make sure that I understood the new config options and then tried deploying Kamal 2.0 on Drifting Ruby.

There is a neat feature that I either didn't realize existed or is new. You can run kamal config locally to see if your config will have the potential to deploy successfully. Basically, it just verifies that there aren't issues within the config.

With the introduction of Kamal 2.0, we are no longer using the traefik proxy and instead now using kamal-proxy. The upgrade process is fairly simple, but does require changing a few things. Once you upgrade Kamal to version 2.0... wait! Before you do this!, you should upgrade to version 1.9.0 because this version offers a "downgrade" feature that will remove kamal-proxy and replace it back with traefik. This can be critical if you're in a situation where you need to go backwards and get the site back up and running while you troubleshoot an issue. I know, because I ended up having to do this.

But, assuming that you've successfully deployed 1.9.0 and you're now upgrading to 2.0.0, the first thing that you'll need to do after updating and installing the gem is to run

kamal init

This will create a new file .kamal/secrets which is meant to replace the .env file. This file will be committed to your version control, so do not put your actual secrets in there. Luckily, the generated file provides a few different examples that you can use in order to find what will work best for you. In my case, since all of my apps using Kamal to deploy share the same Docker Hub account, I have this within the secrets file.

# Option 1: Read secrets from the environment
KAMAL_REGISTRY_PASSWORD=$KAMAL_REGISTRY_PASSWORD

# Option 2: Read secrets via a command
RAILS_MASTER_KEY=$(cat config/credentials/production.key)

While using Rails Credentials does have some drawbacks like rotating keys can be a bit annoying or your key gets compromised and now every secret needs to be rolled and an audit done to see if there was any breaches, it does make it a lot easier to manage from an infrastructure standpoint.

Then we need to update the config/deploy.yml file. I removed the references to the traefik as that was no longer needed. In my initial discovery on my test app, I saw that the application deployed successfully, but I was unable to access the website. This is because the kamal-proxy assumes that the application's port is 80 instead of 3000. This was the biggest change that I had to made to the deploy.yml file outside of cleaning up the no longer used things. But remember that kamal config will let you know if you have some lingering obsolete configs. To tell kamal-proxy that you need to use port 3000 instead, you'd insert a new key for the proxy and then use app_port to specify the port.

proxy:
  app_port: 3000

Once this is all done, you can begin your upgrade with

kamal upgrade

This will ask you to confirm that you'll be deleting the traefik proxy and use kamal-proxy instead. Once this upgrade happens, you should be good to go. However, if you're like me and it didn't go smoothly, keep reading on.

Enter AWS ALB Load Balancer

I would like to think that my infrastructure if fairly simple. In its most simple terms, this is what the infrastructure looks like.

When deploying with Kamal 2.0, there didn't seem to be any issues. It successfully deployed and I thought that everything was good. However, that's when the dreadful Cloudflare error page showed up and I paniced.

I immediately looked at the documentation and my test app's config to see if there were any things that I may have missed, but everything looked fine. Since I knew what my infrastructure looked like on the test application, it helped me narrow some things down. The big differences between the test application and Drifting Ruby's infrastructure is the AWS Load Balancer and an additional Web Server. Since the web servers were on separate hosts, I didn't think that would matter. So I looked in the logs with kamal app logs -f and that's when the problems started to become a bit more clear. Well, not really because I had no idea what it mean. In my error logs I saw the repeated message Unsupported HTTP Method used: PRI which seemed odd.

Searching around for that error message returned multiple sites pointing to it being an HTTP/2 problem. I knew that I was using HTTP/2 on my test application through the Cloudflare Proxy, but the only difference in this case that was applicable was the AWS Load Balancer. So, I looked on there and saw that I had configured the Target Group for the load balancer to use HTTP/2 as well. This really shouldn't matter since Cloudflare is doing the initial handshake with the browser and setting the protocol that will be used on the page.

Sadly, AWS doesn't just let you change the Protocol version either. I had to create a new Target Group (mimicking the settings from my original Target Group) but use HTTP 1instead.

After this change, the site immediately came back up and everything was good. Since then, I've tried deploying again and it went without any issues.

I hope that this helps you if you've run into this issue too!

Ollama Context Window

Dave Kimura — Sat, 21 Sep 2024 01:25:40 GMT

Ollama is a versatile tool that I’ve been using for several months to handle various tasks. It's easy to install and easy to use. Initially, I applied it to smaller projects, but recently, I’ve been leveraging it for more complex tasks that involve larger amounts of content.

One of my primary use cases involves taking receipts, performing Optical Character Recognition (OCR) on them, and then using a large language model (LLM) to extract essential information such as the date of purchase, vendor, category, and amount. Using Ollama with LLAMA3.1:8b has been a great experience most of the time. However, I’ve encountered challenges with certain receipts that contain extensive content beyond the actual receipt details.

For example, consider a PDF receipt from a mobile phone provider. It might include one or two pages with purchase information and then 20 pages of phone log details. In such cases, the context window becomes a significant limitation. Although LLAMA3.1 supports up to 128K tokens for context—a substantial capacity—I’m only able to utilize about 8K tokens by default when running:

ollama run llama3.1:8b

This discrepancy means that the LLM often cannot process the full document context, causing the initial instructions for data extraction to be lost. As a result, the consistency of the extraction results varies based on the document size. While small documents yield accurate results, larger ones may lead to inaccurate or incomplete data extraction.

To make matters worse, the OpenAI API integration with Ollama doesn’t currently offer a way to modify the context window. This limitation restricts flexibility and exacerbates the inconsistency in results across different document sizes.

Addressing this challenge is crucial for maintaining the reliability of data extraction processes, especially as I scale up to handle more extensive documents. Potential solutions could involve optimizing the preprocessing steps to minimize irrelevant content or exploring alternative models with more adaptable context windows.

Solution

We need to modify the default context window! Let's create a new Modelfile that we're going to use and this will be used to extend our context window.

# Modelfile
FROM llama3.1:8b
PARAMETER num_ctx 32768

This is a very simple file, but let's go over it. The FROM is saying what model we're going to be using. In my example, I am using llama3.1:8b so I'm going to keep this the exact same. I then provide a PARAMETER who's key is num_ctx and the value is 32768. This will give us a context window that is 4x larger than the default one.

We can now "apply" this to our existing model.

ollama create -f Modelfile llama3.1:8b

So, before, we had 8192 context size.

Now, the context window size is showing a much larger size. I've tested this out in reading large amounts of data and it was able to keep up with the context without losing information. Of course, if you had really large files, then you would be hitting the context limits again.

If you need an even larger context window, you can increase this to 131072 which is the 128k context limit that llama3.1 has.

There's also something else important to know. In increasing the context window, I also increased the amount of VRAM that was being used. I don't have exact numbers, but for most practical purposes, I found 32768 to be sufficiently fast, low on VRAM and would fit the largest contexts that I needed.

My Development Environment on macOS 15 Sequoia

Dave Kimura — Thu, 15 Aug 2024 04:11:07 GMT

Each year, I attempt to refresh my system by installing the latest version of macOS, often beginning with a beta release. Nevertheless, I've no longer update my primary computer to the latest beta versions due to certain software lagging behind and requiring updates before compatibility is ensured. Specifically, the software that are "dealbreakers" are Universal Audio Console and Loopback. I use these for recording and have had issues in the past with updating too soon. But, I will use a spare computer or a virtual machine to test out upcoming releases.

Installing Homebrew

We'll first start with Homebrew. This will install the Homebrew.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

You'll then be prompted to run some additional commands.

(echo; echo 'eval "$(/opt/homebrew/bin/brew shellenv)"') >> /Users/$(whoami)/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

Installing Apps

Some apps that I'll install on any new install. Some of these applications are paid. There are several others, but they're unrelated to my development experience.

brew install \
  iterm2 \
  visual-studio-code \
  orbstack \
  1password \
  obsidian \
  google-chrome \
  cleanshot \
  cyberduck \
  rectangle \
  ollama \
  tableplus \
  magic-wormhole

I will also install some libraries needed for other Rails development stuff. Since I use both MySQL and PostgreSQL, I'll install the appropriate packages. I don't actually install the services since I've dockerized all of my applications and their dependencies.

brew install libpq mysql-client

Oh-my-zsh

By default, macOS comes with ZSH, but there are some things that oh-my-zsh does out of the box that I've grown to enjoy.

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

.devrc

I like my dot files to be separate from the main .zshrc file. This way, I can backup my .devrc file and have all of my settings intact. But, I will insert into the .zshrc a command to load the .devrc

echo 'source ~/.devrc' >> ~/.zshrc

Installing Ruby

Then we can start with ASDF which is a runtime version manager.

brew install asdf
echo -e "\n. $(brew --prefix asdf)/libexec/asdf.sh" >> ${ZDOTDIR:-~}/.devrc
source ~/.zshrc

We will need to install some packages for Ruby.

asdf plugin add rust
asdf install rust latest
asdf global rust latest
brew install openssl@3 readline libyaml gmp

Then we can install Ruby. At the time of this article, the latest version of Ruby is 3.3.4. I will also add echo 'export RUBY_YJIT_ENABLE=1' >> ~/.devrc since some applications I work on may not be updated to the latest version of Rails which enables YJIT by default.

asdf plugin add ruby
asdf install ruby 3.3.4
asdf global ruby 3.3.4
echo 'export RUBY_YJIT_ENABLE=1' >> ~/.devrc
source ~/.zshrc
gem update --system

Ruby's now installed, so we can verify this and make sure that everything is working well.

ruby -v
ruby 3.3.4 (2024-07-09 revision be1089c8ec) +YJIT [arm64-darwin24]

Since I don't want to install documentation for gems, I will typically exclude this by updating my .gemrc

echo "gem: --no-document" > ~/.gemrc

And now we're ready to install Ruby on Rails and any other gems

gem install rails foreman

I also have a ~/.railsrc file which has a bunch of defaults whenever I am creating a new application.

echo "--asset-pipeline propshaft" >> ~/.railsrc
echo "--javascript esbuild" >> ~/.railsrc
echo "--skip-jbuilder" >> ~/.railsrc
echo "--css bootstrap" >> ~/.railsrc

Installing NodeJS

While Rails will use importmaps as a default, I often find that importmaps is a bit more annoying to work with than other options like bun or esbuild. So, I'll use asdf to install NodeJS.

asdf plugin add nodejs
asdf install nodejs 21.7.3
asdf global nodejs 21.7.3
npm -g install yarn

Docker

I enjoy keeping things clean on my development environment. I keep the runtimes for Ruby and NodeJS on the host machine because it's easier to run some scripts and create sample applications. I use to use Docker Desktop and have since switched to OrbStack.

orb start

For some reason, it's 2024 and we still need Rosetta for some things. When starting OrbStack, it prompts us to install Rosetta. But honestly, this isn't a horrible thing as when building x86/amd64 containers on Apple Silicon, it can get a speed boost by building the Docker image through Rosetta.

Once you go through the OrbStack setup, you should be able to interact with Docker from the command line.

docker run --rm hello-world

Backing up data

This is the basics of what I need to do in order to be productive with my development environment. There are a few things that I will backup and transfer to my new computer (or fresh install). These things are mainly to get back up and running quicker.

On my original macOS install I will back up the files/folders and transfer them to my new setup. The reason why I copy my Projects is that there are several files within these folders that would be difficult to get back. Mainly encryption keys or .env files. I find it easier to just copy the directories over rather than redownloading them from the version control.

~/.ssh/
~/.aws/
~/Projects/ # or whatever you call them
~/.zsh_history
~/.devrc
~/.gemrc

Typically, I'll use TimeMachine to back up my macOS computer, but also have another backup solution like BackBlaze in the event that my computer and TimeMachine backup fails.

Testing things out

Let's create a simple Ruby on Rails application and see if things are working correctly.

rails new example
cd example
bin/dev

We can visit http://localhost:3000 and see if things are working.

Rails 7.2 Upgrade Problems (of my own making)

Dave Kimura — Tue, 13 Aug 2024 12:46:41 GMT

I maintain several Ruby on Rails applications. Most of these are personal projects that I've built to make managing my daily life a bit easier. These projects range from small to much larger in scale.

I'm a big fan of keeping these projects up to date as they prove to be a good testing ground for any kind of updates. Some of these applications have been built off of Rails 4 or 5 and some them were created with Rails 7. As time passes, I will use something like https://railsdiff.org to see the differences between Rails versions in what is created from fresh applications. I typically apply these changes to each of my applications during the upgrade process.

My deployment strategy varies depending on the application, but there are consistencies across all of the applications. All of the applications are using Docker containers on the "production" environment. And, all of the applications are hosted on x86/AMD64 servers. The differences between the applications is that the newer ones are using Kamal to deploy and the older ones are deployed via Portainer which has a webhook to can be pinged to restart the container. I much prefer the Kamal route instead, but haven't changed over all of the applications yet.

When upgrading to Rails 7.2, I encountered issues early in the process. After updating everything on one application, I went to deploy. As a side note, regardless of the hosting method, I always use a bin/deploy script to trigger production deployments. This is helpful as I don't have to worry about which mechanism I am using to deploy. In this example, the deployment mechanism was a simple Docker build using a remote server and then making a cURL request to Portainer.

I did not dive into the specific changes of Rails 7.2 to see if this is a bug or not. However, based on new Rails 7.2 applications, even with --database postgresql as a default flag, the issue doesn't exist. I blame myself for habits that I've created over the years with the ways I did things back then, but never changed how I do them today. So, while the error messages could have been a bit more specific, I feel that this is a "past me" bug that finally caught up to "present me".

Dockerfile:59
--------------------
  57 |
  58 |     # Precompiling assets for production without requiring secret RAILS_MASTER_KEY
  59 | >>> RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile
  60 |
  61 |
--------------------
ERROR: failed to solve: process "/bin/sh -c SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile" did not complete successfully: exit code: 1

I got the error above and unfortunately, it was not very helpful in troubleshooting. Luckily, Ruby on Rails is pretty awesome and we did also get a stacktrace.

 => ERROR [build  9/10] RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile                                                                                               0.4s
------
 > [build  9/10] RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile:
0.417 bin/rails aborted!
0.417 NoMethodError: undefined method `to_sym' for nil (NoMethodError)
0.417
0.417       super(key.to_sym)
0.417                ^^^^^^^
0.418 /usr/local/bundle/ruby/3.3.0/gems/activesupport-7.2.0/lib/active_support/ordered_options.rb:42:in `[]'

Ok... yeah... that's not very helpful either. I spent a few hours trying to figure out what the problem was and why this application was having problems in building the Docker container image. I narrowed down the problem to my config/database.yml file which looks something like this:

default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  url: <%= ENV.fetch("DATABASE_URL") { "localhost" } %>

development:
  <<: *default
  database: example_development

test:
  <<: *default
  database: example_test

production:
  <<: *default
  database: example_production

Solution

Overall... it seems like it's very simple and there's nothing to really write home about. But, the issue here is actually the DATABASE_URL environment variable. For some reason, this is causing the problem, so I updated my Dockerfile to include a dummy variable.

RUN DATABASE_URL=postgres://postgres SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile

This resolved the issue!

Alternative Solution

This whole issue is centered around the DATABASE_URL. If you were to use Rails Credentials, then this problem doesn't exist. In the config/database.yml you can switch from an environment variable over to using the Rails Credentials.

url: <%= Rails.application.credentials.database_url %>

And this also works!

Not isolated to just DATABASE_URL

Now that I got this application working and deployed, I went to update another application that was using Kamal for deployments and SQLite as the database. So, there was no DATABASE_URL to configure since the database was hosted locally on that container (mounted through a volume).

However, I got a similar problem on a different application that was using ActiveStorage. My configuration looked similar to

amazon:
  service: S3
  access_key_id: ...
  secret_access_key: ...
  region: us-east-1
  bucket: <%= ENV.fetch("S3_BUCKET") %>

And another application's storage.yml file was using Rails Credentials

amazon:
  service: S3
  access_key_id: ...
  secret_access_key: ...
  region: us-east-1
  bucket: <%= Rails.application.credentials.storage.bucket %>

And I got a similar obscure error message but this time it was

 => ERROR [10/10] RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile                                                                                      4.5s
------
 > [10/10] RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile:
4.404 Error retrieving instance profile credentials: Failed to open TCP connection to 169.254.169.254:80 (execution expired)
4.405 bin/rails aborted!
4.406 ArgumentError: missing required option :name (ArgumentError)
4.406 
4.406       when nil then raise ArgumentError, "missing required option :name"
4.406                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4.406 /app/app/models/user.rb:107:in `'
4.406 /app/app/models/user.rb:78:in `'
4.406 /app/config/routes.rb:167:in `block in '
4.406 /app/config/routes.rb:3:in `'

And I found that passing in the environment variable didn't work here. Instead, I had to update the storage.yml file.

amazon:
  service: S3
  access_key_id: ...
  secret_access_key: ...
  region: us-east-1
  bucket: <%= Rails.application.credentials.storage.bucket || "my_bucket" %>

Honestly, the issue here is that the bucket name isn't truly a "secret". However, I did have different buckets depending on the environment I was working in. So, I needed a configuration that accounted for this.

In hindsight, I should have kept my bucket names similar to the convention of the default storage.yml example where there is a plaintext prefix of the bucket name and then the Rails.env is added in based on the environment.

# amazon:
#   service: S3
#   access_key_id: <%= Rails.application.credentials.dig(:aws, :access_key_id) %>
#   secret_access_key: <%= Rails.application.credentials.dig(:aws, :secret_access_key) %>
#   region: us-east-1
#   bucket: your_own_bucket-<%= Rails.env %>

Conclusion

Overall the Rails upgrade experience from Rails 7.1 to 7.2 was rather painless. Over the years, I've developed a habit of minimizing gem dependencies and keeping configurations as close to the 'Rails way' as possible. But, sometimes with older applications, things slip through the cracks because they "worked" back then and the configuration files like the database.yml and storage.yml normally aren't revisited during the upgrades.

I hope that these findings can help save you some time!

Self Hosted Github Actions Runner

Dave Kimura — Wed, 24 Jul 2024 02:08:36 GMT

The spark of this blog post came from a tweet from DHH about the default Rails 8 having a Github Actions workflow.

Github Actions is a great tool for automating your workflows. It's built into Github and is free for public repositories. However, if you have a private repository, you will need to pay for Github Actions. This can be a bit expensive if you have a lot of repositories. There is a way to reduce the cost of Github Actions by using self hosted runners. This allows you to run your Github Actions workflows on your own servers. This can be a great way to reduce the cost of Github Actions.

To be fair, Github Actions does have a free tier for private repositories. However, this free tier only allows for 2000 minutes of build time per month. This can be a bit limiting if you have a lot of repositories or if you have a lot of builds.

The good news is that you can set up your own self hosted runner for free. This will allow you to run your Github Actions workflows on your own servers. This can be a great way to reduce the cost of Github Actions.

Setting up a Self Hosted Runner

To set up a self hosted runner, you will need to have a server that you can SSH into. This can be a server that you already have or it can be a new server that you create. It could also be something like a Raspberry Pi or a Virtual Machine hosted in the cloud.

To start, we will use Debian 12 (Bookworm) as our base operating system. This is the latest version of Debian and it is a great choice for a server. It is lightweight and it is easy to install. Once you have a running Debian 12 server, we can SSH into it and update and install some packages.

apt update && apt upgrade -y && \
apt-get install -y \
    curl nano git gnupg apt-transport-https ca-certificates \
    software-properties-common make gcc autoconf patch \
    build-essential rustc libssl-dev libyaml-dev libreadline6-dev \
    zlib1g-dev libgmp-dev libncurses5-dev libffi-dev libgdbm6 \
    libgdbm-dev libdb-dev uuid-dev htop libpq-dev

We'll then create a new user for our runner so that we don't have to run everything as root.

adduser --quiet --disabled-password --shell /bin/bash --home /home/developer --gecos "Developer" developer

The runner will need to be able to run Docker containers, so we'll need to install Docker.

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg
echo \
"deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
"$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
tee /etc/apt/sources.list.d/docker.list > /dev/null
apt update && apt install docker-ce -y

And the developer user will need to be able to run Docker containers without sudo.

usermod -aG docker developer

Since I typically use esbuild on my projects, It'll be best to install nodejs and yarn.

curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | \
    gpg --dearmor -o /etc/apt/nodesource.gpg && \
    echo "deb [signed-by=/etc/apt/nodesource.gpg] https://deb.nodesource.com/node_20.x nodistro main" | \
    tee /etc/apt/sources.list.d/nodesource.list && \
    apt update && apt install nodejs -y && \
    npm install --global yarn

We can then log in as the developer user to install Ruby.

su - developer

On my development machines, I prefer to use asdf, but for a runner, rbenv is a great choice.

git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'eval "$(~/.rbenv/bin/rbenv init - bash)"' >> ~/.bashrc
git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build
git -C "$(rbenv root)"/plugins/ruby-build pull
echo 'export PATH="$HOME/.rbenv/plugins/ruby-build/bin:$PATH"' | tee -a ~/.bashrc
source ~/.bashrc

We can then install the Github Actions Runner. You can check for the latest versions on the Github Actions Runner Releases page.

mkdir actions-runner && cd actions-runner
export RUNNER_VERSION="2.311.0"
curl -o actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz -L https://github.com/actions/runner/releases/download/v${RUNNER_VERSION}/actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz
tar xzf ./actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz

You'll need to register this runner, so be sure to check out the steps below on how to do that. You'll need to run the registration script in the folder that you extracted the runner to. I keep the default settings in wizard of the script.

To register the runner, head over to one of your projects on Github and select the Actions > Runners. Then click on the New self-hosted runner button. Select your operating system and architecture.

Under the Configure section, there will be a script to run that starts with ./config.sh and ends with a token. Copy this script and run it on your server. This will register the runner with Github. This will need to be done in the folder that you extracted the runner to.

# ./config <- run the config registration script from below here.

Installing Ruby

We can now install our Ruby version. I've updated all of my projects to Ruby 3.3.0, so that's the version that I'll be using. However, modify this as needed. This is also assuming that you're installing this on an amd64 machine. If you're using a Raspberry Pi or something else, you'll need to modify the path. It's also important to let the runner know that we've installed Ruby so we will touch a file to let the runner know that this Ruby version is present.

export RUBY_VERSION="3.3.0"
ruby-build ${RUBY_VERSION} /home/developer/actions-runner/_work/_tool/Ruby/${RUBY_VERSION}/x64
touch /home/developer/actions-runner/_work/_tool/Ruby/${RUBY_VERSION}/x64.complete

Starting the Runner at boot

We'll edit the /etc/systemd/system/github-runner.service file and place the following contents in it. This will allow us to start the runner at boot.

[Unit]
Description=GitHub Runner
After=network.target

[Service]
User=developer
WorkingDirectory=/home/developer/actions-runner
ExecStart=/home/developer/actions-runner/run.sh
Restart=always
RestartSec=3
LimitNOFILE=4096

[Install]
WantedBy=multi-user.target

Reload systemd, enable and start the service

systemctl daemon-reload
systemctl enable github-runner
systemctl start github-runner

Conclusion

We now have a self hosted runner that we can use for our Github Actions workflows. This will allow us to run our workflows on our own servers. This can be a great way to reduce the cost of Github Actions. If you have any questions or comments, please feel free to reach out. I'm always happy to help.

Using Ansible to Update Kamal Servers

Dave Kimura — Sun, 29 Oct 2023 04:00:00 GMT

I've been using Kamal recently and it's been a great experience. It takes a lot of the headaches out of having to wait for a deployment to finish. Previously, I was hosting Drifting Ruby on AWS with Elastic Beanstalk. This was a great solution for a long time as I didn't have to worry about the servers and it set up a lot of the networking for me. However, there were some pain points with this process and I have been wanting to switch to something new for a while. When I first heard about MRSK (now Kamal), I was excited! Ruby on Rails applications were getting a first class citizen deployment solution. The networking and infrastructure side of things hasn't ever been an issue for me since I initially came from that kind of background. However, I was initially looking for something easy to use that gave a bit of flexibility. I didn't want to go the Heroku route since pricing was a concern early on and AWS offers Reserved Instances which can save a significant amount.

One of the drawbacks with Kamal is that it doesn't have a built in way to update the servers. This is where Ansible comes in. Ansible is a tool that allows you to automate server configuration and deployment. But, in our case, we are going to use it to update our servers. This is a great solution for me since I already had some familiarity with Ansible and it's a great tool to have in your toolbelt. I need to look up some Ansible tricks a bit more to look at full server provisioning, but this will be a good start.

Note I am performing these steps with the assumption that you have already set up your Kamal servers and have them running. You can check out a recent episode on Kamal which covers deploying with Github Actions, but I also go through the steps of setting up the servers. I also have an older episode when Kamal was called MRSK which covers setting up the servers with a managed database and load balancer.

Note This Ansible playbook is also assuming that you'll be running this on a computer that has shell access to the servers that you're wanting to manage.

Setting up Ansible

Since I am on an Apple computer, I'm going to use Homebrew to install Ansible. If you're on a different platform, you can check out the Ansible installation documentation for more information.

brew install ansible

Understanding Ansible

This Ansible setup is going to have two different files. The first is the inventory file which will contain the list of servers that we want to manage. The second is the playbook.yml file which will contain the instructions for Ansible to run.

The inventory file will look something like this:

[server_group]
app1            ansible_host=PUBLIC_IP_ADDRESS_OF_SERVER
app2            ansible_host=PUBLIC_IP_ADDRESS_OF_SERVER

The inventory has different groups of servers. In this case, we only have one group called server_group. This group contains two servers. The first server is called app1 and the second server is called app2. You can add as many servers as you want to this group. You can also create multiple groups if you want to manage different servers with different playbooks. You will want to replace the PUBLIC_IP_ADDRESS_OF_SERVER with the public IP address of your server. This should be the same IP address that you use to SSH into your server and that you have set up in the Kamal deploy.yml file.

The playbook.yml file will look something like this:

---
- name: Update and Upgrade Packages on Servers Sequentially
  hosts: all
  serial: 1
  become: yes

  tasks:
    - name: Run apt update and apt upgrade on servers
      apt:
        update_cache: yes
        upgrade: yes
        cache_valid_time: 3600
      register: apt_update

    - name: Pause for 2 minutes before next server update
      pause:
        minutes: 2
      when: apt_update.changed

This is a bit more complicated because we have some additional things to take into consideration. The first thing to note is that we are running the playbook on all servers in the inventory. This is because we want to update all of the servers. However, we don't want to update them all at the same time. This is where the serial option comes in. This will tell Ansible to run the playbook on one server at a time. This is important because we don't want to take down our application while we are updating the servers. This could happen if there was an update to Docker. If we updated Docker on all of the servers at the same time, then our application would be down until the update was complete. This is why we want to update the servers one at a time.

The become option tells Ansible to run the commands as the root user. This is important because we need to be able to update the packages on the server. If we didn't have this option, then we would get an error when trying to update the packages.

The tasks section is where we define the tasks that we want Ansible to run. The first task is to run the apt update and apt upgrade commands. This will update all of the packages on the server. The register option tells Ansible to store the output of the command in a variable called apt_update. This will be used in the next task.

The second task is to pause for 2 minutes before running the next server update. This is important because we want to make sure that the server is fully updated before we update the next server. The when option tells Ansible to only run this task if the apt_update variable has changed. This will only happen if the server was updated. If the server was already up to date, then this task will not run.

Running the Ansible Playbook

Now that we have our playbook and inventory files set up, we can run the playbook using the following command:

ansible-playbook -i inventory playbook.yml

This will run the playbook on all of the servers in the inventory file. You should see something like this:

PLAY [Update and Upgrade Packages on Servers Sequentially] *********

TASK [Gathering Facts] *********************************************
ok: [app1]

TASK [Run apt update and apt upgrade on servers] *******************
ok: [app1]

TASK [Pause for 2 minutes before next server update] ***************
skipping: [app1]

PLAY [Update and Upgrade Packages on Servers Sequentially] *********

TASK [Gathering Facts] *********************************************
ok: [app2]

TASK [Run apt update and apt upgrade on servers] *******************
ok: [app2]

TASK [Pause for 2 minutes before next server update] ***************
skipping: [app2]

PLAY RECAP *********************************************************
app1 : ok=2 changed=0 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
app2 : ok=2 changed=0 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0

You can see that the playbook ran on both servers and that the apt update and apt upgrade commands were run. You can also see that the Pause for 2 minutes before next server update task was skipped. This is because the server was already up to date.

I hope that this helps close another gap in the Kamal deployment process. I'm looking forward to seeing what else is in store for Kamal and I'm excited to see what the future holds for Ruby on Rails deployments.

Using SQLite in Production

Dave Kimura — Mon, 02 Oct 2023 01:57:00 GMT

So there is a recent push on using SQLite in production, but there's also little talks around the pros and cons of doing so. This article will try to cover the pros and cons of using SQLite in production.

To start, there's some value in asking ChatGTP what they think about using SQLite in production. So, the below information is from ChatGPT and it has some interesting points. However, some of these points are flawed and I don't agree with them. So, this is another example where you must take everything with a grain of salt when it comes to generative AI content.

My responses will be in italics next to the points made by ChatGPT.

Pros of Using SQLite in Production:

Simplicity and Maintenance: SQLite requires no separate server process or system to operate. Its serverless nature makes it easy to set up, backup, and maintain. Keep in mind that this is requiring you to install the sqlite service on the server that will be using the database. This isn't a big deal as the sqlite3 binary is about 4MB. Though, it doesn't run as a service so it is simple to manage.

Portability: All the data in an SQLite database is stored in a single file, making it extremely easy to transfer, copy, or backup. This is true. However, you may want to be careful in situations where you could run out of disk space. Make sure that you have proper monitoring in place on the server. Also, while I've never confirmed that this could be an issue, but this is also putting all of your eggs in one basket. If there was ever an issue with the file being corrupted then it could be a total loss. Again, I've never seen this happen, but I also don't use SQLite enough to have experienced this.

Low Resource Footprint: It’s lightweight and requires minimal memory, making it suitable for devices with limited resources like IoT devices or mobile applications. The IoT devices and mobile applications is where I have seen this the most. While a default Ruby on Rails application does come with SQLite as the default database engine, typically it isn't seen in a production setting.

Consistent Performance: For applications with a moderate load and where the read operations far outnumber the write operations, SQLite can deliver consistent and fast performance. There's no network hops to worry about. Optimized SQL queries are often not the slow point of the application. Even with network latency it's often a tiny amount such that you won't notice. If we're talking about a huge application that's service millions of requests per second then these network hops could add up with a traditional database.

ACID Compliant: SQLite transactions are ACID compliant, ensuring data integrity even after system crashes or power failures. Atomic, consistent, isolated, and durable (ACID). It's true that SQLite has come a long way in terms of integrity and reliability of handling the data. However, with system crashes or power failures, database corruptions can occur especially on systems where RAID systems are configured improperly. If the RAID cache is set to write-back, you get better performance but could end up in a situation where there is data loss or corruption.

Cross-Platform: SQLite is cross-platform and can be used on all major operating systems, including Windows, Linux, and macOS. In terms of deploying a Ruby on Rails application, this is kind of a moot point as we will typically not change the platform the application is hosted on.

Free and Open-Source: SQLite is free to use and is released under the Public Domain license, which means it can be used for any purpose, including commercial applications. The same could be said for MySQL (or MariaDB) and PostgreSQL. MySQL is GPL licensed which probably doesn't make a difference if you're hosting your own application and not distributing it.

No Configuration: SQLite doesn’t require any configuration or setup, making it easy to use for beginners. Yes, properly configuring a MySQL or PostgreSQL instance can be difficult and should be done properly for optimal performance. However, using a managed service with AWS, GCP, Digital Ocean, Azure, etc. will often have a decent configuration that you don't need to worry about.

No Dependencies: SQLite doesn’t have any dependencies, which means it can be used in any programming language or framework. While MySQL and PostgreSQL have dependencies and you'll need to install some libraries on the server, they're well documented steps and usually not a big deal.

Cons of Using SQLite in Production:

Concurrency Issues: SQLite is not ideal for applications with a high level of concurrent write operations. It locks the entire database during a write operation, which can cause a bottleneck. If we're working on a single threaded application since we're talking about smaller applications without too much traffic, this will not really be an issue. However, it does bring up a good point for any kind of background workers that occur asynchronous. Even though SQLite does a good job at handling transactions, it is easy to get ourselves into situations of Deadlocks when background jobs are trying to write to the database at the same time.

Not Suited for Large Databases: While SQLite supports database files up to 140 TB, it’s generally not the best choice for very large datasets due to potential performance issues. Most databases will never reach 140TB. But this does not talk to file system limits. This is really a moot point since modern file systems exceed SQLite's limits, but if you're file system was improperly set (to something like Fat32), then you could easily reach the 4GB limit. Most likely, if your database was even getting to a fraction of this size, you'll have other issues to be concerned with; system resources, performance issues, etc.

Limited Built-in Features: Unlike more robust RDBMS like PostgreSQL or MySQL, SQLite doesn’t have a wide range of built-in tools or support for stored procedures, right out of the box. It supports the important ones like JSON data types. Typically, we don't use stored procedures in Ruby on Rails applications since the ActiveRecord ORM is powerful enough in most cases.

Limited Security: SQLite doesn’t have built-in support for user management or access control, making it less secure than other RDBMS. While this can be a critical aspect in some scenarios, the Ruby on Rails applications will likely not need this level of access control. However, it does speak to the vulnerability of the database as it will be much easier to make a copy of if the system is ever breached. In a traditional deployment, there's still nothing that could really stop the attacker if they gained access to the machine, but it does offer some levels of obfuscation if they don't know about how Rails handles credentials. But, the reality is that if a bad actor has gained access to your machine, all bets are already off and you're in a very bad situation.

No Client-Server Model: SQLite doesn’t have a client-server model, which means it can’t be accessed by multiple users at the same time. This is going to be a big issue if High Availability is a concern. Typically, we will have a load balancer as the SSL termination point and it will route the traffic to one of the available web servers. This is a deal breaker in many situations as using SQLite in a production setting could mean that you have downtime during deployments. You lose the ability for rolling deployments and have basically put all eggs in one basket. Depending on your deployment strategy, it could also mean that you're having to maintain a server instead of being able to manually or automatically provision and scale up new web servers.

Conclusion

So, there's some pros and cons to using SQLite in production. I think that the pros are valid, but the cons must also be taken into consideration. The recent push for using SQLite in production isn't necessarily a bad direction, but shouldn't be blindly followed. There's a lot of factors that go into deciding what database engine to use. I think that SQLite is a great choice for smaller applications that don't have a lot of traffic. It is also a good choice when architecture simplicity is a concern. Just make sure that you're weighing all of your options and understand the consequences and benefits of your choices. There's no one size fits all solution in this case. Also keep in mind that a lot of platforms will have a free tier or a cheap tier for managed database engines. You can get a lot of value out of these services and it will be much easier to scale up in the future if you need to. I think that the biggest concern is the lack of High Availability This is a deal breaker for most applications that are going to be deployed in a production setting. However, for non-revenue generating applications or applications that are not mission critical, SQLite could be a good choice.

Running Meilisearch

Dave Kimura — Sat, 06 May 2023 04:00:00 GMT

MeiliSearch is a powerful, fast, and easy-to-use search engine, perfect for developers who want to implement search functionality into their applications. In this blog post, we will walk you through the process of deploying MeiliSearch with SSL encryption using Docker Compose and Nginx as a reverse proxy. This setup ensures a secure connection between your users and your MeiliSearch instance.

Prerequisites

Before you begin, make sure you have the following tools installed on your system:

Docker: Ensure Docker is installed and running on your machine. You can follow the installation guide on the official Docker website.

Docker Compose: Make sure Docker Compose is installed. You can find installation instructions on the official Docker Compose website.

OpenSSL: Required for generating SSL certificates. You can install OpenSSL through your package manager or download it from the official OpenSSL website.

Configuration

Create a docker-compose.yml file in your project directory and copy the following content:

services:
  meilisearch:
    image: getmeili/meilisearch:v1.1
    restart: always
    ports:
      - '7700:7700'
    environment:
      - MEILI_MASTER_KEY=key
    volumes:
      - meili_data:/meili_data

  nginx:
    image: nginx:stable-alpine
    restart: always
    ports:
      - '80:80'
      - '443:443'
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - /home/ubuntu/cert.pem:/etc/nginx/certs/fullchain.pem
      - /home/ubuntu/key.pem:/etc/nginx/certs/privkey.pem
    depends_on:
      - meilisearch

volumes:
  meili_data:

This configuration file sets up two services: MeiliSearch and Nginx.

Meilisearch service:

You should replace the key value with a random string. This key will be used to secure your MeiliSearch instance. You can generate a random string using the following command:

openssl rand -hex 16

Nginx service:

There's a bit more config to do with the Nginx service. We can create a ssl certificate using OpenSSL. We will use this certificate to enable SSL encryption for our MeiliSearch instance. You can generate a self-signed certificate using the following command:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -subj "/CN=yourdomainname" -nodes

Then we can create a configuration file called nginx.conf and copy the following content:

events {
    worker_connections 1024;
}
http {
    server {
        listen 80;
        server_name yourdomainname;
        return 301 https://$host$request_uri;
    }
    server {
        listen 443 ssl;
        server_name yourdomainname;
        ssl_certificate /etc/nginx/certs/fullchain.pem;
        ssl_certificate_key /etc/nginx/certs/privkey.pem;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384';
        location / {
            proxy_pass http://meilisearch:7700;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

You'll want to update the appropriate values for your domain name and SSL certificate paths.

Running the application

Now that we have our configuration files ready, we can run the application using the following command:

docker compose up -d

This will start both services in the background. You can check the status of your services using the following command:

docker compose ps

You should see something like this:

Name                Command               State           Ports
--------------------------------------------------------------------------------
meilisearch         ...                   Up              ..
nginx               ...                   Up              ..

The -d in the docker compose up -d command tells Docker to run the services in the background.

This will also cause the services to restart automatically if they crash or if you reboot the machine.

Thanks for reading!

Ruby 3.2.1 with YJIT

Dave Kimura — Sat, 04 Mar 2023 05:00:00 GMT

I've been using Ruby 3.2.1 + YJIT for some time now and overall, I'm seeing anywhere from 10-20% performance improvements over running Ruby 3.0.5. Sorry, I don't have an apple-to-apple comparison for just YJIT vs non-YJIT. However, the performance improvements are real world scenarios on a Ruby on Rails 7.0.4 application.

So, I've recently formatted my primary desktop which is running macOS 13.2.1 and figured that I would document my steps on my preferred way of installing Ruby as well as getting YJIT to work. It's important to note that this is also an Apple Silicon machine. These steps should work regardless of which Apple Silicon you're using.

First, I'll install homebrew. This will automatically install the Command Line Tools for Xcode.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

You'll then be prompted to run some additional commands.

(echo; echo 'eval "$(/opt/homebrew/bin/brew shellenv)"') >> /Users/$(whoami)/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

We can then start our install of Ruby. However, there are a few things that we should do first. Firstly, we need to select a manager for our Ruby interpreter. I normally use RVM as it's what I used for the longest time. It works well and I never had any complaints. However, with Ruby 3.2.1, we're also going to need an installation of Rust if we want to enable YJIT. So, instead of RVM, I'm going to be using ASDF.

brew install asdf
echo -e "\n. $(brew --prefix asdf)/libexec/asdf.sh" >> ${ZDOTDIR:-~}/.zshrc
source ~/.zshrc

Now that we have a manager for our Ruby and Rust, we can now proceed to install Rust.

asdf plugin add rust
asdf install rust latest
asdf global rust latest

Now that Rust is installed, we can proceed with our Ruby installation. Normally there are some dependencies that we need to handle, but luckily, asdf will take care of that for us.

asdf plugin add ruby

However, there is a strange thing with the mapping of the libraries so if we were to try and install Ruby right now, it would fail. So let's take care of this. This is around the libyaml package and we need to set some environment variables for this. I've added all four of these to my ~/.zshrc so that Ruby can install properly and YJIT is enabled out of the box.

brew install openssl@3 readline libyaml gmp
echo 'export LDFLAGS="-L$(brew --prefix libyaml)/lib"' >> ~/.zshrc
echo 'export CPPFLAGS="-I$(brew --prefix libyaml)/include"' >> ~/.zshrc
echo 'export RUBY_YJIT_ENABLE=1' >> ~/.zshrc
echo 'export RUBY_CONFIGURE_OPTS=--enable-yjit' >> ~/.zshrc
source ~/.zshrc
asdf install ruby 3.2.1
asdf global ruby 3.2.1

I had to restart my terminal, but once I did, everything seemed to work as expected.

ruby -v
ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [arm64-darwin22]

Pushing Code to Multiple Repositories with Git

Dave Kimura — Thu, 23 Feb 2023 05:00:00 GMT

Have you ever found yourself needing to publish your code to multiple repositories? Perhaps you have a static site hosted on Github Pages and want to have multiple domains point to it. Or maybe you manage multiple technology-related blogs and need to consolidate your content into a single blog, while still updating it on multiple domain names. In this article, we will explore a solution to push code to multiple repositories with minimal effort using Git.

As mentioned earlier, there are scenarios where you need to update your code on multiple repositories, and doing so manually can be time-consuming and error-prone. For instance, you may have a blog that you want to host on multiple domains, but instead of redirecting users to a new site, you prefer to update the content on both domains simultaneously. In such cases, you can use Git to push changes to multiple repositories with just a few commands.

To push code to multiple repositories, you first need to initialize your Git repository and push the changes to one of the repositories. In our example, let's say we push the changes to the repository kobaltz/blog-kobaltz.git. Now, we want to push the same code to another repository kobaltz/blog-driftingruby.git. To achieve this, we can add another push URL to our .git/config file using the following command:

git remote set-url --add --push origin git@github.com:kobaltz/blog-driftingruby.git

This command adds a new push URL to the origin remote and sets it to the git@github.com:kobaltz/blog-driftingruby.git repository. Now, whenever you commit your changes and push them, Git will push the changes to both repositories.

You can verify that the push URL has been added by running the following command:

git remote -v

This command will display the two push URLs under the origin remote, as shown below:

origin  git@github.com:kobaltz/blog-kimura.git (fetch)
origin  git@github.com:kobaltz/blog-kimura.git (push)
origin  git@github.com:kobaltz/blog-driftingruby.git (push)

Now, your code is being pushed to two repositories with minimal effort. If you ever want to remove one of the push URLs, you can do so by using the following command:

git remote set-url --delete --push origin git@github.com:kobaltz/blog-driftingruby.git

In this article, we've explored a simple solution to push code to multiple repositories using Git. By adding a new push URL to the origin remote, we can push changes to multiple repositories with minimal effort. This technique can be useful in scenarios where you need to update your code on multiple domains or repositories. And, remember that you can use different services as well for the push URLs; one pointing to GitHub and another pointing to GitLab.

By consolidating your code base and keeping multiple repositories up to date, you can simplify your workflow and save time. Give this approach a try and see how it works for you. Happy coding!

Docker Builds are slow on M1

Dave Kimura — Sun, 10 Apr 2022 01:41:00 GMT

This is a neat Docker trick for those who have an ARM development machine (Apple M1), but sometimes need to build x86/amd64 images locally to push up to a registry.

Sure, having a CI/CD platform to do this is probably ideal, but for little programs or just sometimes in general, it may be handy to know this.

If you have a spare Intel machine laying around, you can turn it into a build server. Get something like Ubuntu installed on there and install the latest Docker. On your development machine, copy your publish SSH key over to this build server.

So now you you have your server set up and you want to build your Docker image for an x86/amd64 platform. Typically, you would run a command like this below to target the platform.

docker buildx build -f Dockerfile --platform linux/amd64 .

And this will work, but what you'll notice is that this is an extremely slow process. The Apple Silicon chips are amazing and are the fastest machines I've ever used. However, when emulating the x86 instructions to build a docker image, it takes such a long time. I've seen this take over an hour on larger and more complex projects.

Just as an example. Here we have a very simple Ruby on Rails application that has little moving parts. I'm using things like esbuild and css-bundling, but nothing fancy. On the M1 chip, it took over 250 seconds to build the image.

# Apple Silicon
[+] Building 316.4s (23/23) FINISHED

However, on a AMD 5900X server, I have a Virtual Machine running on there which has Docker installed. Running the exact same project on there took much less time.

# AMD 5900X
[+] Building 62.3s (24/24) FINISHED

So, the main concern here is that I do not want to interrupt my normal process on how I build images or handle things. It would be a pain to push up my code, ssh into the build server, pull it down, and then build the image. This is a lot of steps, but luckily there is a MUCH easier way to do this.

Docker's buildx build command has a flag that we can specify a specific builder.

So, we can create this builder on our local machine. The nice part about this creation is that it is idempotent, so you can run this command many times without changing the result. All we have to do is to create a builder profile and in this case I have named it amd64_builder. Since this builder is a pool of resources, I give a name to for the VM. I'm also specifying the platform that I'm building against and then pass in the SSH url for my builder machine.

docker buildx create \
  --name amd64_builder \
  --node linux_amd64_builder \
  --platform linux/amd64 \
  ssh://USERNAME@IP_ADDRESS_OF_BUILDER

Now, I can build and push the image to the registry. The magical flag that we'll use is --builder as we can now specify the builder VM. The rest of the buildx command is the same as we would expect.

docker buildx build \
  --builder amd64_builder \
  --tag USERNAME/REPONAME:TAG \
  --push .

In some cases, I've seen this go almost 10x faster than the amd64 emulation on the M1 chip. If you have a spare Intel/AMD machine laying around, this may be a worthwhile adventure.

Transferring Files

Dave Kimura — Sat, 09 Apr 2022 01:39:00 GMT

Sometimes we get into situations where we need to remotely transfer a file. This file could be large or it could be tiny. This file may be sensitive or could be of little importance. Regardless, sending this file over to a remote location could still have its challenges. What if the file is coming from a headless server? Perhaps you have some logs that you want to inspect on your local machine instead of parsing through them remotely in an ssh session. This is where magic-wormhole comes into play.

Installation

brew install magic-wormhole

Linux (Debian/Ubuntu)

sudo apt install magic-wormhole

Usage

To send a file, you simply use the wormhole command and specify which file you wish to send.

➜  ~ wormhole send server.log
Sending 1.1 GB file named 'server.log'
Wormhole code is: 5-hydraulic-snowslide
On the other computer, please run:

wormhole receive 5-hydraulic-snowslide

Now that we have specified which file we want to send, we've been provided with a "wormhole code" that we can use on the receiving end.

wormhole receive 5-hydraulic-snowslide

And that's all we have to do! On the receiving computer, we've downloaded the requested file! In the past, I would have used scp or ftp but remembering the syntax, while isn't too difficult, can prove to be challenging at times especially if nonstandard ports are used or if ports aren't opened up on the firewall to make the connection.

➜  ~ wormhole receive 5-hydraulic-snowslide
Receiving file (1.1 GB) into: server.log
ok? (y/N): y
Receiving (->tcp:some-external-ip:65250)..
 80%|█████████████████▏               | 859M/1.07G [00:04<00:01, 206MB/s]

Let's Encrypt Wildcard Cert

Dave Kimura — Wed, 10 Feb 2021 05:00:00 GMT

I'm writing this more as documentation for myself as I have several domains which I often use as playgrounds for certain things. This could be a kubernetes environment or a docker cluster where I have several applications deployed, but don't want to set up an nginx site for each one of the apps that I deploy.

Recently, I found out about Portainer for managing a docker environment. Think of this as a kubernetes-lite. This isn't good for any kind of production use case, but does have some benefits for at home management of a local docker instance.

So in this illustration, we have a request coming in on 443. This request could be using the domain name c1.mydomain.com and there could be another request coming in from c2.mydomain.com.

Previously, you would have a certificate for both subdomains and would need to set up the appropriate port forwarding for each subdomain to the appropriate server. This is a huge pain, so, instead, this is where a wildcard certificate can come in handy.

In this particular scenario, I have an nginx proxy which will be used to route all of the traffic coming in to my network. This is handy because I can use this reverse proxy for SSL termination and also routing the traffic to various servers based on the domain name. This doesn't have to be a powerful server. You could even use a Raspberry Pi to route this traffic. Again, this is for a home server and not really production grade.

You will need some prerequisites. And I also use CloudFlare's DNS for handling these wildcard domains. This is nice because certbot and cloudflare play pretty nicely to automatically verify the challenges via their API.

apt install certbot letsencrypt python3-certbot-dns-cloudflare

If you already have certbot and the necessary extensions installed, you can simply run this script to get a wildcard certificate.

sudo certbot certonly \
     --cert-name mydomain.com \
     --dns-cloudflare \
     --dns-cloudflare-credentials /etc/letsencrypt/cloudflareapi.cfg \
     --server https://acme-v02.api.letsencrypt.org/directory \
     -d "*.mydomain.com" \
     -d mydomain.com

So, now we can configure our nginx proxy to take any request from this domain and forward it over to my docker host.

server {
  server_name *.mydomain.com;
  server_name ~^(?.+)\.mydomain\.com$;
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
  # proxy_next_upstream error timeout http_502;
  location / {
    proxy_pass http://DOCKER_HOST_IP_ADDRESS;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_buffering off;
  }
  listen 443 ssl;
  ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem;
  include /etc/letsencrypt/options-ssl-nginx.conf;
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

server {
  return 301 https://$host$request_uri;
  listen 80 ;
  listen [::]:80 ;
  server_name *.mydomain.com;
  server_name ~^(?.+)\.mydomain\.com$;
}

In another blog article, I'll describe how I set up the Docker host to take in these requests from the nginx server.

Drifting Ruby

"Choose Your Own Path"

Prompt Chaining

Application/Technology Used

Hardware/GPUs

Wrap up

asdf 0.16.x

Fixing my install

Other TL;DR; on the new changes with asdf

And that's pretty much it

Kamal 2.0 Issue with AWS ALB

Upgrade Process

Enter AWS ALB Load Balancer

Ollama Context Window

Solution

My Development Environment on macOS 15 Sequoia

Installing Homebrew

Installing Apps

Oh-my-zsh

.devrc

Installing Ruby

Installing NodeJS

Docker

Backing up data

Testing things out

Rails 7.2 Upgrade Problems (of my own making)

Solution

Alternative Solution

Not isolated to just DATABASE_URL

Conclusion

Self Hosted Github Actions Runner

Setting up a Self Hosted Runner

Installing Ruby

Starting the Runner at boot

Reload systemd, enable and start the service

Conclusion

Using Ansible to Update Kamal Servers

Setting up Ansible

Understanding Ansible

Running the Ansible Playbook

Using SQLite in Production

Pros of Using SQLite in Production:

Cons of Using SQLite in Production:

Conclusion

Running Meilisearch

Prerequisites

Configuration

Meilisearch service:

Nginx service:

Running the application

Ruby 3.2.1 with YJIT

Pushing Code to Multiple Repositories with Git

Docker Builds are slow on M1

Transferring Files

Installation

Linux (Debian/Ubuntu)

Usage

Let's Encrypt Wildcard Cert

Other TL;DR; on the new changes with `asdf`