The Subtle Distinction in Referencing

Let’s look at an example using User and Admin::User classes:

module Admin
  class Nested  # Nested approach
    def self.test = User.name
  end
end
 
class Admin::Inline  # Inline approach
  def self.test = User.name
end
 
puts Admin::Nested.test  # => "Admin::User" (correct)
puts Admin::Inline.test  # => "User" (incorrect)

Here, Admin::Nested correctly references Admin::User using User.name. However, Admin::Inline unexpectedly returns just “User”. This is because Ruby’s constant lookup prioritizes the current namespace first. Since Admin::Inline isn’t explicitly nested under Admin, it doesn’t search within that namespace for User.

To achieve the intended behavior with inline classes, you’d need to use the fully qualified name:

class Admin::InlineQualified
  def self.test = ::Admin::User.name  # Using fully qualified name
end
 
puts Admin::InlineQualified.test  # => "Admin::User" (correct)

Inheritance Nuances

The same concept applies to inheritance. Consider these BaseController classes:

class BaseController
end
 
module Admin
  class BaseController  # Nested approach
  end
end
 
puts Admin::NestedController.superclass  # => Admin::BaseController (correct)
puts Admin::InlineController.superclass  # => BaseController (incorrect)

Similar to the previous example, Admin::NestedController accurately retrieves its superclass Admin::BaseController. However, Admin::InlineController mistakenly returns the top-level BaseController.

Understanding Nesting’s Benefits

Nesting offers several advantages:

1. Clarity and Explicitness: Nested modules clearly indicate the hierarchy and relationships between modules and classes.
2. Correct Constant Resolution: Nesting ensures Ruby searches for constants within the appropriate namespace, preventing unexpected behavior.
3. Automatic Module Creation: When defining a nested class like Api::UsersController, Ruby automatically creates the Api module if it doesn’t exist.

Recommendations and Best Practices

While inline modules can work with extra care (using fully qualified names), nesting is generally recommended for its clarity, predictability, and adherence to Ruby conventions. Static code analysis tools like Rubocop can enforce this practice, making it easy to integrate into your development workflow.

In Summary

By embracing nesting in Ruby modules, you gain a more organized, predictable, and robust codebase, avoiding potential gotchas and ensuring your code behaves as intended.

Then I found out about this amazing plugin for VSCode that does most of what copilot does, the plugin is called Continue, and you can install it easily into your VSCode by clicking here. Also if you use Jetbrains IDEs there is also a Continue plugin for them, so you can use this same tutorial, just install the plugin for your IDE.

It has a great advantage over VSCode if you think about the security of your code that it can run completely local from your machine, but for that you’ll also need to install Ollama, it is a local server for Large Language Models, and Continue can talk to it to complete code, use chat with AI in the IDE, comment your code, explain things, …

Very similar to many of the Copilot features.

Again, I used copilot a long time ago, so if you are a Copilot user, and decide to test Continue, please comment bellow on what Copilot offers that is better than Continue, I don’t have the knowledge to really compare them.

After you install Ollama for your platform (they have installers for Mac, Windows and Linux), you need to download some models to work with continue, I tested some and here is my small list:

DeepSeek Coder – it is great for ruby, creates unit tests for your classes with a reasonable coverage.

CodeGemma Instruct – it works amazing for Python, wasn’t that great for Ruby in my tests

Starcoder2 – It is the recommended code completion model for Continue, it is working great up to now, suggesting good code completions and saving some typing, I wouldn’t bet my job on the suggestions but if you know what you are doing it’ll save you some keystrokes.

To install these models in Ollama, after you install it run these commands:

ollama pull deepseek-coder:6.7b
ollama pull codegemma:instruct
ollama pull starcoder2:7b

After this you’ll need to configure Continue, it comes with a few web API models for trial, but since one of my ideas of using it was to have security and not have anything sent over the web I removed the models and configured it to use only Ollama that runs on my machine, here is my configuration file:

{
  "models": [
    {
      "title": "DeepSeek Coder",
      "provider": "ollama",
      "model": "deepseek-coder:6.7b"
    },
    {
      "title": "Codegemma Instruct",
      "provider": "ollama",
      "model": "codegemma:instruct"
    },
    {
      "title": "Starcoder2 7b",
      "provider": "ollama",
      "model": "starcoder2:7b"
    }
  ],
  "slashCommands": [
    {
      "name": "edit",
      "description": "Edit selected code"
    },
    {
      "name": "comment",
      "description": "Write comments for the selected code"
    },
    {
      "name": "share",
      "description": "Export this session as markdown"
    },
    {
      "name": "cmd",
      "description": "Generate a shell command"
    }
  ],
  "customCommands": [
    {
      "name": "test",
      "prompt": "Write a comprehensive set of unit tests for the selected code. It should setup, run tests that check for correctness including important edge cases, and teardown. Ensure that the tests are complete and sophisticated. Give the tests just as chat output, don't edit any file.",
      "description": "Write unit tests for highlighted code"
    }
  ],
  "contextProviders": [
    {
      "name": "code",
      "params": {}
    },
    {
      "name": "docs",
      "params": {}
    },
    {
      "name": "diff",
      "params": {}
    },
    {
      "name": "open",
      "params": {}
    },
    {
      "name": "terminal",
      "params": {}
    },
    {
      "name": "problems",
      "params": {}
    },
    {
      "name": "folder",
      "params": {}
    },
    {
      "name": "codebase",
      "params": {}
    }
  ],
  "tabAutocompleteModel": {
    "title": "Starcoder2 7b",
    "provider": "ollama",
    "model": "starcoder2:7b"
  },
  "allowAnonymousTelemetry": false
}

I replaced the starcoders:3b for the starcoder2:7b because I thought it’d work better, I haven’t really tested the 3b (3b means 3 billion parameters used in training, 7b means 7 billion parameters used in training)

All 3 models installed are specific for coding, they ate trained in more code than natural language, but they understand natural language commands, like “write a unit test for this code using only the public methods”.

It wasn’t really smart to know I was in a rails project and wrote the unit test directly using rspec, so I added “write a unit test for this code using only the public methods using minitest in a rails project” and the result was perfect.

It also knows how to write somewhat useful comments for your code, and rewrite code with better variable names.

Once you open Continue for the first time it’ll show you a simple but really useful tutorial in a python file.

Looking at the documentation for Continue, it has some really cool features like integrating with GitHub issues, pool requests, Jira, … you just need to configure it.

Please let me know if you think this mini tutorial was useful

The idea here is to write a simple CRUD from scratch, I’ll use a Grid layout to keep everything in the same page, the app will be a Single Page application, similar to those written with heavy JavaScript frameworks, but we’ll not touch a line of JavaScript, out code will be only Ruby and ERB, using the power of Ruby on Rails, and the new standard Hotwire, to be more specific in this example, we’ll be heavily using TurboFrame that is a part of Hotwire.

The full app creation is in the video bellow, but if you don’t want video you can simply skip it an read the step by step.

We’ll start creating a new rails application:

rails new samplespa

In that application we’ll edit the file config/routes.rb, and make the content match:

Rails.application.routes.draw do
  resources :people
  # Define your application routes per the DSL in https://guides.rubyonrails.org/routing.html
 
  # Reveal health status on /up that returns 200 if the app boots with no exceptions, otherwise 500.
  # Can be used by load balancers and uptime monitors to verify that the app is live.
  get "up" => "rails/health#show", as: :rails_health_check
 
  # Defines the root path route ("/")
  root "people#index"
end

The changes are the addition of “resources :people” that will be the only controller in our application and making the root of the app “people#index”.

Now we’ll create our model with the command:

rails g model person name:string email:string description:rich_text

I’m using rich_text as the description type because that will allow us to use ActionText to edit that field, but we’ll need to activate it in the application first, for that we’ll run the command:

rails g action_text:install

That command will create two migrations and configure the application to use ActionText for rich text editing.

We’ll also edit our create_people migration to make the fields not null, by adding “null:false” as options, like bellow:

class CreatePeople < ActiveRecord::Migration[7.1]
  def change
    create_table :people do |t|
      t.string :name, null: false
      t.string :email, null: false
 
      t.timestamps
    end
  end
end

Now we are ready to migrate our database with the command:

rails db:migrate

Next we’ll edit the person model in the file app/models/person.rb to add some validation like bellow:

class Person < ApplicationRecord
  has_rich_text :description
 
  validates :name, :email, :description, presence: true
end

the has_rich_text tells the model to store the description field as ActionText in the proper tables.

Now we create our controller, we can use the rails generator or simply create the file people_controller.rb in the folder app/controllers, the initial content will be this:

class PeopleController < ApplicationController
  before_action :load_everyone
  def index
    if @people.any?
      @person = @people.first
    end
  end
 
  private
  def load_everyone
    @people = Person.order(id: :desc)
  end
end

The idea is to have the list of people loaded for every method, that isn’t a problem because Rails is smart and will only actually run the query when we fetch data from @people

Now we create our first and only HTML view, it’ll be in the folder app/views/people (create the folder manually if you didn’t use the generator for the controller)

The file will be called index.html.erb and the content is really simple, check bellow:

<div class="people_container">
  <div class="people_list">
    <%= render 'people_list' %>
  </div>
  <div class="person_detail">
    <%= render 'person_detail' %>
  </div>
</div>

It has a container div, and two section divs for layout, in those we render the default content for the page.

Now lets take a look at our default CSS to layout this amazing app.

body {
  height: 100vh;
}
 
.people_container {
  display: grid;
  grid-template-columns: 200px auto;
  height: 100%;
  width: 100%;
}
 
.people_list {
  grid-column: 1;
  height: 100%;}
 
.person_detail {
  grid-column: 2;
  height: 100%;
}

It is very simple using grid layout in the container with two columns, one with 200px and the other with the rest, and we set the position of our two inner divs in the grid, also making sure the body has the full height, so height:100% works (I do that every time now, to make sure I don’t forget due to bad experiences in the past trying to fill the vertical portion in the screen)

Now we need to create the partials used in the main view, the first will be the list, create the file app/views/people/_people_list.html.erb with the following content:

<%= turbo_frame_tag 'people_list' do %>
<ul>
  <% @people.each do |person| %>
    <li>
      <%= link_to person.name, person, data: {turbo_stream: true, turbo_method: 'get'} %>
    </li>
  <% end %>
  <li>
    <%= link_to 'Create Person Record', new_person_path, data: {turbo_stream: true, turbo_method: 'get'} %>
  </li>
</ul>
<% end %>

Pay attention to the “data: {turbo_stream: true, turbo_method: ‘get’}”, it’ll add to the links generated the properties data-turbo-stream=”true” and data-turbo-method=”get”, the first will activate turbo_stream for the link, it is usually only active for forms, and the later will activate turbo_stream for the method GET, because it is usually only for POST/PATCH, in the video the first try was wrong, I used torbo_frame instead of turbo_stream.

Other important thing is the turbo_frame_tag in the view, it defines areas where turbo frame can easily change content in the page.

Now lets create the file app/view/people/_person_detail.html.erb with the content:

<%= turbo_frame_tag 'person_detail' do %>
  <div>
    <div>
      <b>Name:</b> <%= @person&.name %>
    </div>
    <div>
      <b>Email:</b> <%= @person&.email %>
    </div>
    <div>
      <b>Description:</b> <%= @person&.description %>
    </div>
    <div>
      <% if @person.present? %>
        <%= link_to 'Edit', edit_person_path(@person), data: {turbo_stream: true, turbo_method: 'get'} %>
      <% end %>
    </div>
  </div>
<% end %>

This is a simple and ugly details view that will render the person details, it uses safe navigation for the person because it is possible that with an empty people list, the person will be nil and it’d crash our application.

Now we need to make the links in both the people_list, and person_detail partials work, meaning we need to add to our controller the methods “new”, “show” and edit, just to start.

So open the controller app/controllers/people_controller.rb and add these 3 methods:

  def show
    @person = Person.find params[:id]
    respond_to do |format|
      format.turbo_stream
    end
  end
 
  def new
    @person = Person.new
    respond_to do |format|
      format.turbo_stream
    end
  end
 
  def edit
    @person = Person.find params[:id]
    respond_to do |format|
      format.turbo_stream do
        render :new
      end
    end
  end

There are a few important things here, in all methods we have a respond_to and the format is turbo_stream, that will require a turbo_stream view, we’ll need at least two for the application, the show and new views, the edit method uses the new view since it is the same idea of showing a form.

To make it work, lets create a file named app/views/people/show.turbo_stream.erb with the following content:

<%= turbo_stream.replace 'person_detail', partial: 'person_detail' %>
<%= turbo_stream.replace 'people_list', partial: 'people_list' %>

The view is very simple and uses a helper from ruby to make our lives easier, we are replacing the contents of the previously defined turbo_frame_tag areas, with the referred partials, and we are redrawing the list so that we can use the same show view for update and create actions too, so if we change the person’s name or add a new person, the list will also be updated.

And the other file app/views/people/new.turbo_stream.erb with the content:

<%= turbo_stream.replace 'person_detail', partial: 'person_form' %>

The idea of this view is to render a form, so we need to create the form partial too, lets create the file app/views/people/_person_form.html.erb with the content:

<%= turbo_frame_tag 'person_detail' do %>
  <%= form_for @person do |f|%>
    <div>
      <div>
        <%= f.label :name %>
        <%= f.text_field :name%>
      </div>
      <div>
        <%= f.label :email %>
        <%= f.text_field :email%>
      </div>
      <div>
        <%= f.label :description %>
        <%= f.rich_text_area :description %>
      </div>
      <div>
        <%= f.submit %>
      </div>
    </div>
  <% end %>
<% end %>

It is a simple form using rails helpers, and the rich_text_area field type, it also goes into the same person_detail turbo frame area, to make our code cleaner.

And the last things needed to make our code work are the create and update methods in our controller, the code is quite simple, lets check bellow:

def create
    @person = Person.create params.require(:person).permit(:name, :email, :description)
    respond_to do |format|
      format.turbo_stream do 
        if @person.valid?
          render :show
        else
          render :new
        end
      end
    end
  end
 
  def update
    @person = Person.find(params[:id])
    @person.update params.require(:person).permit(:name, :email, :description)
    respond_to do |format|
      format.turbo_stream do 
        if @person.valid?
          render :show
        else
          render :new
        end
      end
    end
  end

They are standard methods, without good validation and accepting pretty much anything the client sends, rails will handle escaping the SQL to make our app more secure, and we are using safe parameters, through the methods require and permit, to make sure we only pass the existing parameters to the Person model, and the main difference in the format.turbo_stream block is that if the operation failed, the form is rendered again (and we could add code to show the errors), and show the person details otherwise.

With that we have the full SPA working, without writing a single line of Javascript, if you want to check the full code it is on Github you can just checkout, run the app and change it to study.

To make it les ugly, but still pretty bad, I added Pico CSS to the application.html.erb file, in the header section, if you want to do that add this line:

<link
  rel="stylesheet"
  href="https://cdn.jsdelivr.net/npm/@picocss/pico@2/css/pico.min.css"
/>

And if you do that, you’ll also need to update the basic_layout.css file to make the rich text editor buttons visible again with this:

.trix-button {
  background-color: white !important;
}

Please comment bellow if you liked this quick tutorial, and please suggest other subjects, if there aren’t any suggestions I’ll probably write about how to do pop up dialogs with Hotwire/Stimulus in the next post.

But Sidekiq will retry that job for you, of course this is configurable:

# Retry 5 times before giving up
sidekiq_options retry: 5
# Don't retry at all
sidekiq_options retry: false

The default number of retries is 25, and with that many tries most of the transient problems will fix itselves probably.

But sometimes not even being that insistent is enough to avoid the problem, and in that case sidekiq will send your job to a DeadSet where all the job ghosts live.

For most applications, it is good to know when some or all jobs go to that DeadSet, meaning Sidekiq will not retry it anymore.

In this situation you can log the error, send one email for a human to fix the issue by hand, or handle it the best way possible for your business.

To intercept this, sidekiq the sidekiq_retries_exhausted hook, that you can configure either per worker class as bellow:

class ImportantWorker
  include Sidekiq::Worker
  sidekiq_options retry: 5
 
  sidekiq_retries_exhausted do |msg, exception|
    # example with using Rails' logger
    Rails.logger.warn("Failed #{msg['class']} with #{msg['args']}: #{msg['error_message']}", error: exception)
  end
 
  def perform(important_arguments)
    # do some work
  end
end

or you can configure a global handler for the entire application, adding a handler to Sidekiq like bellow:

Sidekiq.configure_server do |config|
  # other config stuff...
 
  config.death_handlers << ->(job, ex) do
    Rails.logger.error "Surprise, an error!, #{job['class']} #{job["jid"]} just died with error #{ex.message}."
  end
end

I usually add this code to the config/initializers/sidekiq.rb file where all the sidekiq related configurations live together.

Of course just logging like this will not solve your problem, but intercepting the dead jobs event will allow you to write more robust asynchronous job processing applications.

Please add a comment bellow if you have any other issues with asynchronous jobs that I could help with.

It works by searching your code for comments with specific keywords, the default is searching for FIXME, OPTIMIZE and TODO.

You can add more tags either by using the “–annotations” parameter or by registering the tags in your rails config

config.annotations.register_tags("DEPRECATEME", "TESTME")

The output is pretty simple and yet helpful, for example this is the output of one of my projects:

$rails notes
app/controllers/some_controller_with_domains.rb:
  * [ 67] [FIXME] need to check allowed domains
  * [ 86] [FIXME] need to check allowed domains
 
app/controllers/search_controller.rb:
  * [ 71] [FIXME] ugly hack for exact match
  * [190] [FIXME] ugly hack for exact match
 
app/webpacker/javascript/core/components/SomeJavascriptFile.js:
  * [ 33] [TODO] Remove from collection if status no longer matches search
  * [167] [TODO] Not implemented
 
app/webpacker/javascript/core/components/SomeOtherJavascriptFIle.js:
  * [ 38] [FIXME] not actually properly memoized
 
app/webpacker/javascript/core/components/JavascriptWithWeirdness.js:
  * [107] [FIXME] Weirdness on first update

The release 3.2.0 of Ruby is faster and brought some amazing tools for us.

WebAssembly support

Ruby 3.2.0 added initial support for WebAssembly through WASI, this allows running CRuby in a web browser, for example through TryRuby Playground but it also allows running CRuby securely in different platforms, like running the exact same binary version of ruby in a x86 and arm64 environments.

It isn’t complete yet, the WebAssembly support for Fiber, exception and GC isn’t complete, but is implements a VFS on top of web assembly, what allows the packaging of an entire ruby app into a single .wasm file.

Production Ready YJIT

YJIT is faster and uses less memory than before! it now supports both x86-64 and arm64/aarch64 CPUs on Linux, MacOS, BSD and other UNIX platforms.

To compile ruby with YJIT support you’ll need Rust 1.58.0+ so make sure you install it before running ./configure (or before asking rvm or a similar tool to install it for you)

Wanna know more about YJIT? check this amazing presentation

Regexp matching way faster

Sometimes depending on the Regexp we are using in our ruby code, it is possible to use our notebooks to fry some eggs

But this will change and you’ll need to use the correct pan for that in the future…

The improved regexp matching can keep the regexp time mostly linear in almost all tests done by the Ruby Core team check the graph bellow.

Regexp.timeout can be used for the cases where these improvements fail, for example in complex cases where you use lots of back-references or look-around

Regexp.timeout = 1.0

/^a*b?a*()\1$/ =~ "a" * 50000 + "x"
#=> Regexp::TimeoutError is raised in one second

You can also make one specific Regexp ignore the timeout if needed

Regexp.timeout = 1.0

# This regexp has no timeout
long_time_re = Regexp.new('^a*b?a*()\1$', timeout: Float::INFINITY)

long_time_re =~ "a" * 50000 + "x" # never interrupted

there are other improvements like better syntax error reporting.

A few language improvements like allowing the usage of rest and keyword rest arguments as method parameters

  def foo(*)
    bar(*)
  end
  def baz(**)
    quux(**)
  end

There is a new Data class to represent immutable objects similar to the Struct class today.

Measure = Data.define(:amount, :unit)
  distance = Measure.new(100, 'km')            #=> #<data Measure amount=100, unit="km">
  weight = Measure.new(amount: 50, unit: 'kg') #=> #<data Measure amount=50, unit="kg">
  weight.with(amount: 40)                      #=> #<data Measure amount=40, unit="kg">
  weight.amount                                #=> 50
  weight.amount = 40                           #=> NoMethodError: undefined method `amount='

Struct now also support keyword arguments

  Post = Struct.new(:id, :name)
  Post.new(1, "hello") #=> #<struct Post id=1, name="hello">
  # From Ruby 3.2, the following code also works without keyword_init: true.
  Post.new(id: 1, name: "hello") #=> #<struct Post id=1, name="hello">

You can read the full release notes in this link.

The Bangkok.rb team did an amazing job of organizing 4 amazing keynote speakers and a total of 19 speakers and attendees from over 20 diferent countries.

The organization team did an amazing job of receiving the speakers and made everyone feel at home from the start with the amazing dinner at a boat in the beautiful Chao Phraya river.

The conference was beautifully organized and the speeches were amazing varying from performance improvement tips, framework specific talking about Hanami and Phenix, to internals of Puma, two amazing JRuby talks, data processing, team organization, GitOps, Rails and a lot more!

This was a single track conference where all the speeches grabbed my attention, I loved all of them.

And to complete the scenario I was lucky enough to be one of the speakers talking about Refactoring

If anyone is interested my slides are already online here Ruby code smells.

The speech was more abstract trying to point what to avoid in the code, but I’ll write a few blog posts more specific on the subject with samples and tips on refactoring to anyone that is learning refactoring best practices.

In the mean time, enjoy the return to presencial conferences to make friends and grow your network of technical contacts, but also to enjoy life and grab a beer with a fellow developer.

My goal was to have the test code in Gherkin like this:

But after cucumber executes

The file was downloaded, it doesn’t wait for the download to finish and the next step had no access to the downloaded file.

After some research I found out that I could configure a profile to Chrome before instantiating the browser in Capybara.

In a simple explanation, this snippet sets a profile in the browser to be instantiated, configuring the default download directory to the tmp/downloads folder in my rails app.

This also mean that we can set ay number of other chrome properties as required, but we’ll get there sometime in the future

Then I created this download helper in a new file under features/support

An important point here is that the “downloading?” method uses the chrome partial download extension, so this entire solution only works for Chrome, if you need a multi browser solution this code will need a lot of updating.

With these small changes I was able to download files directly to the temp download folder, then check the downloaded file contents correctly with this simple snippet.

Then('the downloaded content should be:') do |content|
  text = download_content
  expect(text).to eq(content)
end

Making my initial test pass, and allowing me to completely test my downloads.

I hope this small snippets help someone else

Please feel free to leave any comments bellow.

And even kubernetes solving a big amount of problems you might have when exposing and scaling your application, it also brings some problems that you need to weight before deciding if this is the right technology for you or not.

One of the things to consider, is that kubernetes is built to support stateless services, sure it supports drive mounts, but you’ll have many problems with pods waiting for long hours to stop waiting for the drives to dismount, or pods waiting to start because no available node is compatible with the drive mount it needs.

Another thing that might be a red-flag is that kubernetes might decide that a pod needs to move to another node due to high cpu or memory usage, and if your application doesn’t have many copies of each pod running, this might cause some minor service outage (unless you combine this with the problem related above, then it might become a huge problem)

A third red-flag for kubernetes might be if you do not have enough hardware resources, for example if you work in a small project or company, and your hardware is a little more than your application needs to run, the extra load that kubernetes need to run the additional resources, DNS, load balancing, kubelet, … might cause you problems for your application, because nothing of that is free.

One other thing is that if you want to deploy your own kubernetes server, you need to study a lot before doing that, it is way easier to pay for a hosted service from Google, AWS, Azure, … Kubernetes has a lot of moving parts, and is really complex to maintain.

But if none of these problems apply to you, you can read the other posts about how to package and deploy your application to kubernetes:

1. How to use docker to to have an uniform development, test and production environment
2. First pod
3. A service to access your pod
4. Horizontal autoscaling
5. Ingress reverse proxy

Of course these are not the only “red flags” for kubernetes, but if any of these apply to you, you might want to consider other solutions for your deployment, maybe docker swarm is enough for you, maybe you do not need containers at all, …

If you have any questions or comments about this, please leave a comment or talk direct to me through any social network

Kubernetes has a “simple but works” solution called ingress, ingress is an HTTP proxy, it will work as a reverse proxy for HTTP and HTTPS for any service that exposes one one port.

You can also use ingress to map multiple hosts, or multiple paths to different services.

The important restriction for ingress is that it will only proxy the ports 80 and 443.

To continue with the same example that are already working, we’ll change the service from the previous post to ClusterIP, this way it will not be directly accessible to the outside world, the YAML will be like this:

apiVersion: v1
kind: Service
metadata:
  labels:
    run: rails-sample
  name: rails-sample
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 3000
  selector:
    run: rails-sample
  type: ClusterIP

Then we’ll create an ingress mapping to that service, we’ll add some path mapping just to use it as an example, the initial ingress sample will map the path “/app” to our rails service like the sample bellow.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
  name: rails-sample
spec:
  rules:
  - http:
      paths:
        - path: /app
          backend:
            serviceName: rails-sample
            servicePort: 3000

The annotation “nginx.ingress.kubernetes.io/rewrite-target: /” will rewrite the paths to prevent errors in our application routing.

To check the ingress status and configuration, we can run the command “kubectl get ingress”, this will show the current ingress configuration and hosts mappings.

Ingress also supports name based virtual services, for example, if the host name “my.sample.service” points to your machine, you can map only this host name to your rails application with the following ingress configuration:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: rails-sample
spec:
  rules:
    - host: my.sample.service
      http:
        paths:
        - backend:
            serviceName: rails-sample
            servicePort: 3000

The rewrite annotation and the “path” were removed because in this sample, we are mapping the host name directly to our rails app.

It is possible to merge both samples, mapping many host names and many paths inside each host name to a different service.

Since ingress is also an HTTPS proxy, it will be wise to provide a certificate for it, so we’ll map correctly our “my.sample.service” domain.

You can create a self signed certificate with the following commands:

$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout sample.key -out sample.crt -subj "/CN=my.sample.service/O=my.sample.service"
$ kubectl create secret tls rails-sample-tls --key sample.key --cert sample.crt -o=yaml > secret.yaml

in the “req” part, remember that the common name must match your domain name, in my case “my.sample.service”

That last command creates the secret in kubernetes and saves it in the “secret.yaml” file for future reference, of course in a real application you’ll not use a self signed certificate, but you’ll buy one for you real domain.

Now lets configure out ingress to use this certificate, we’ll just update the yaml file with the following config:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: rails-sample
spec:
  tls:
    - hosts:
      - my.sample.service
      secretName: rails-sample-tls
  rules:
    - host: my.sample.service
      http:
        paths:
        - backend:
            serviceName: rails-sample
            servicePort: 3000

You can either “kubectl edit ingress rails-sample” and change it as shown above, or change your file and “kubectl apply” it.

Now you can edit your /etc/hosts file and add “127.0.0.1 my.sample.service” to it, and access your app through https://my.sample.service.

You’ll need to tell your browser to thrust your self signed certificate.

And with this you can now deploy your HTTP/HTTPS applications using ingress, but sometimes this is not good enough, for example if you need for some reason expose another port through HTTPS, ingress will not allow that, and if you need that, stay tuned in this blog, and we’ll see another options that I’ve used in the next post.

As always, please leave comments with any questions or suggestions.