Friction Log for Getting Started

[igbanam]

Hello team!

I like the idea of Kuby, so I gave it a shot. I am all for sane defaults in app development. For context, I'm not a Kubernetes expert. But I've been doing Rails and webapps a long time. I'm on an M1 Air. Like MasterBuilderConstruction, I too am porting a construction site which is, for now, just a one-page HTML brochure site.

I ran into some hiccups when trying this our — ultimately unsuccessful too. If someone could help me figure out where I went wrong, I'd appreciate that.

Some questions I had while going through this were

• Do I need to already push the image to Docker to begin? — Kuby does this for me.
• What's the spin up process for DockerDesktop?
• How do I know what platform to build my Docker image for?
  • M1 default breaks Kuby default because there are some gems like nokogiri which need special attention
• Do I really need CockroachDB? Taking on a new dependency to take on a new dependency doesn't sound that attractive.

These said though, I really want Kuby to "just work"™. The idea of sane defaults for deployments is something I can get behind.

Details of my friction log is here https://gist.github.com/78f8f768a56079902dd29012be675dba

[camertron]

Hey @igbanam thanks for giving Kuby a try! Sorry to hear it didn't work for you - I'm happy to do what I can to get you sorted :) Let me respond to each of your questions in turn:

Do I need to already push the image to Docker to begin? — Kuby does this for me.

Right, Kuby does this for you via the kuby push command.

What's the spin up process for DockerDesktop?

I'm not sure what you mean. You should be able to install Docker Desktop by downloading it from the Docker website and running the usual Mac install process.

How do I know what platform to build my Docker image for?

By default, Docker will build images for the CPU architecture it's run on. Since hosting companies commonly provide x86 hardware, Kuby will print an error message if you try to build images for ARM processors. To build x86 images instead, pass the --platform option to Docker like so: kuby -e production build -- --platform linux/amd64.

To more directly answer your question: you probably want to build x86-compatible images.

M1 default breaks Kuby default because there are some gems like nokogiri which need special attention

Based on the details you posted in #110, this is likely a Nokogiri/bundler issue. I don't think there's much Kuby can do to help. Have you considered filing an issue in the nokogiri repo? Interestingly, it looks like the maintainers have been providing precompiled arm64-darwin versions of the gem since v1.11.0 (here's the most recent version), so it should Just Work. Are you using the latest versions of rubygems (gem update --system) and bundler (gem install bundler)?

Do I really need CockroachDB? Taking on a new dependency to take on a new dependency doesn't sound that attractive.

If you want Kuby to manage your database for you, then yes, you need CockroachDB. I tried to support Postgres and MySQL but it turned out to be a nightmare. A lot of developers choose to use their hosting provider and whatever managed database products they offer. For example, DigitalOcean can give you a fully managed Postgres instance they will provision and upgrade for you. If you'd rather go that route, you can tell Kuby to stop managing your database:

Kuby.define('my-app') do
  environment(:production) do
    kubernetes do
      plugin :rails_app do
        manage_database false
      end
    end
  end
end

[igbanam]

Thanks for responding @camertron. I'll give this another go tonight and see if I have any luck. I'll friction-log as usual.

The :docker_desktop issue is this: In the tutorial, the provider that's used is :digitalocean. I wanted to get things done and setup locally first before committing DigitalOcean resources to it. Everything built correctly, but I didn't seem to get the application running on the IP. I think the IP I need is that of the ingress-controller? …but my k8s-fu is not strong enough to be certain of that. I have Docker Desktop installed and running; I just don't know how to get to my app from the prebuilt images.

Thanks for the managed_database tip. I'll incorporate that into my try

[igbanam]

Still getting a 404 with x86_64

Should I be able to view the site from the IP of the load balancer in the listed under Networking in DigitalOcean?

My next attempt now is to set the host for the rails_app, to see if that works. I have a URL I'm using — goalkeeper.com.ng. I'm managing its DNS using CloudFlare. I've since pointed the domain to the IP of the load balancer there, but I'm yet to get dig to reflect that; so I doubt setting the host in the rails_app would have any effect. Or does the DNS need to be managed by DigitalOcean explicitly?

[igbanam]

$ http 143.244.208.210
HTTP/1.1 404 Not Found
Connection: keep-alive
Content-Length: 146
Content-Type: text/html
Date: Tue, 20 Sep 2022 23:07:54 GMT

<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

[igbanam]

Also, I noticed the cert pod isn't up for me

$ bundle exec kuby -e production remote status
NAME                             READY   STATUS    RESTARTS   AGE
trcweb-assets-659d9f479b-ln4vc   1/1     Running   0          89m
trcweb-web-c7c7988cb-psxvd       1/1     Running   0          89m

I'm not worrying too much about the database for now because this is as close to a plain Rails application as it gets; still uses SQLite

[camertron]

I'll friction-log as usual.

I really appreciate you taking the time to log these issues, as they will likely help others and because it's great to see the details of issues people run into as they onboard. This is the first time I've heard the term "friction log," what a great concept 😄

I wanted to get things done and setup locally first before committing DigitalOcean resources to it.

Ah ok I get what you mean now. I think you'll want to check out Kind, which is a tool for standing up ephemeral Kubernetes clusters within Docker Desktop (and other container runtimes). Here are the Kuby docs for getting things up-and-running.

I have Docker Desktop installed and running; I just don't know how to get to my app from the prebuilt images.

As long as the images have been pushed to a Docker registry, and that registry can be accessed over the public internet, your DigitalOcean (or Kind) cluster should be able to pull them down and run them. Given the screenshot you posted of the remote status command, it looks like the images were pulled and run successfully 👍

I think the IP I need is that of the ingress-controller? …but my k8s-fu is not strong enough to be certain of that.

You'll want the IP of the ingress object the controller created for your app. The various hosting providers generally respond to the creation of ingress objects by starting up whatever their version of a load balancer is (DigitalOcean calls them "load balancers," but Linode calls them "node balancers," etc). To make a request to your app, you'll need the IP of that load balancer. You can find it by consulting your platform's web UI or by running the following Kuby command:

bundle exec kuby -e production kubectl -N -- get ingresses

The response should include an entry for the ingress that was created for your app, along with the address and hosts configured for that ingress.

Once you have the IP, you'll need to either add an entry in your /etc/hosts file or make a request with curl with the Host header set:

curl -H "Host: goalkeeper.com.ng" https://<ip here>:443

Once DNS is properly configured, you should be able to make a request directly to goalkeeper.com.ng without any special headers or /etc/host entries.

Or does the DNS need to be managed by DigitalOcean explicitly?

No. All you need to do is add an "A" record as it appears you've done in the screenshot. Note that it may take some time for DNS to propagate and for LetsEncrypt to issue your TLS certificate (assuming tls_enabled is true in your Kuby config).

Of course, if you registered your domain with DigitalOcean, or your domain's nameserver records point to DigitalOcean, then yes, you'll need to use DigitalOcean to configure the domain's DNS records. But otherwise no. Actually come to think of it, I don't think DigitalOcean is a registrar?

Also, I noticed the cert pod isn't up for me

The cert manager pods run in a separate cert-manager namespace. You should be able to see them by running:

bundle exec kuby -e production kubectl -- -n cert-manager get pods

I'm not worrying too much about the database for now because this is as close to a plain Rails application as it gets; still uses SQLite

👍