Cuber: a new, simple way to deploy Rails apps

Hello,

I’d love to hear your feedback about this project (I have been working on it for some months):

It’s an automation and deployment tool written in Ruby (it’s somewhat similar to Capistrano, but it deploys on Kubernetes, so you don’t need to configure all the servers and it’s more scalable…).

Basically you can deploy a Rails application by defining a Cuberfile (a few lines of Ruby code, like a Capfile for Capistrano) and then typing cuber deploy in your terminal.

It has all the features needed to run an application in production.

Here’s an example Cuberfile that you can use to deploy any Rails app on Kubernetes:

app 'myapp'
repo '.'
buildpacks 'heroku/buildpacks:20'
image 'username/myapp'
dockerconfig 'dockerconfig.json'
kubeconfig 'kubeconfig.yml'
migrate 'rails db:migrate', check: 'rake db:abort_if_pending_migrations'
proc :web, 'bundle exec puma', scale: 3
proc :worker, 'bundle exec sidekiq', scale: 2
cron :mytask, '@daily', 'rake mytask'
env 'RAILS_ENV', 'production'
env 'RAILS_LOG_TO_STDOUT', 'enabled'
env 'RAILS_SERVE_STATIC_FILES', 'enabled'
env 'RAILS_MASTER_KEY', File.read('config/credentials/production.key').strip, secret: true

You can find a lot of information and technical documentation on the project website: https://cuber.cloud

Finally note that Kubernetes can be 80% cheaper than Heroku or other PaaS, because it is bare infrastructure. Kubernetes is also offered by most cloud providers, and thus you avoid lock-in with a single service provider.

I’m here or on GitHub if you have any questions or requests.

2 Likes

Very cool to see a project combining Rails with kubernetes. I feel the Rails community has not not (yet) embraced the technology. I’ll give it a go!

One remark I’d like to make on the cost side of things. Running your own infrastructure and not using something like Heroku can be costly in the sense that you’d have to maintain the infrastructure yourself or your team. But this will very greatly from situation to situation.

That’s why I am building Cuber :slight_smile: The goal is to create a simple experience (like a PaaS) on Kubernetes, hiding the complexity of Kubernetes.

I love the way you use a cuber file.

I have used hatchbox.io for years - and for the most part, it is fantastic. However, every couple of years I do pester Chris to make it so that the setup could run off a file in my repo…

Having said that - the service that would work better for me has a lot less configuration by default.

e.g. just migrate my db - don’t ask me how to do that in a config file. You already know.

I don’t know or care the command for the webserver (or even which one you use) - just make it work

cron - just integrate with whenever

domains - I hope you’re going to set up my ssl config with lets encrypt. Presumably all you need to know is my domain name…

on hatchbox, my config choices are essentially

server provider: :digital_ocean, size: :some_size
db :pgsql
worker :sidekiq
ssl type: :lets_encrypt, domain: "mydomain"
auto_deploy true

How does this compare to Kuby (https://getkuby.io/)?

@Confused_Vorlon

I love the way you use a cuber file.

Thank you!

I think that the main difference is that Cuber deploys to Kubernetes, while the project that you mention deploys on bare servers. Horizontal scaling is very easy with Kubernetes, compared to spinning up / managing servers manually.

the service that would work better for me has a lot less configuration by default

Cuber already has a very compact configuration.

For example writing “worker :sidekiq” instead of “proc :worker, 'bundle exec sidekiq'” is only a limitation in my opinion: with Cuber syntax, similar to a Procfile, you can spin up different working processes with different command line options (and not just one generic sidekiq process). Also note that Cuber allows you to run any process, not only a few pre-defined processed defined as plugins.

Finally note that the example code in your post is not exactly equivalent to my example above: in my example above I have included many configurations that are optional, but usually useful for a Rails app. It’s difficult to discuss this in general: if you see a specific field / command that can be simplified I would be happy to analyze it.

@mvz I have heard about that project but I have never used it in production, so I can’t say if it’s reliable. Probably there are hundreds of small differences and different architectural choices, since they are completely different projects. One major difference is certainly that Cuber is written in Ruby, but it can deploy any app, in any language and framework. Another difference that I see is that, while Cuber is standalone (based only on a few major / stable projects like docker and kubectl), Kuby seems to make large use of external components (e.g. kubedb, plugins, etc.).

Render might serve as a middle ground between Heroku and lower level. I haven’t tried it yet.

Isn’t it just an Heroku competitor?

Note that Cuber is not a provider, it’s just an automation tool, like Capistrano, that you install locally on your machine or on your CI/CD pipeline.

When you use Cuber, in the cloud you will have only Kubernetes and your app: you can use any cloud provider, including DigitalOcean, Vultr, Google Cloud, AWS, or any other Kubernetes-certified provider.

This means that you don’t have lock-in and you can choose the cheapest / best cloud provider.

1 Like