In the previous chapter, we’ve written a Dockerfile to build the catscii service inside Docker. The result is a container image that can be pushed to production!

Now that our service is production-ready, it’s time to deploy it somewhere.

There’s a lot of ways to approach this: what we are going to do, though, is build a docker image. Or, I should say, an OCI image.

This is still a series about Nix, but again: because the best way to see the benefits of Nix is to do it without Nix first, we’ll use only Docker’s tooling to build the image.

Our catscii program does everything we want it to do, except that it’s a command-line application rather than a web server. Let’s fix that.

Enter axum

The documentation for the axum crate tells us how to make a basic web server, and we honestly don’t need much more than that.

So let’s add axum:

amos@miles:~/catscii$ cargo add axum@0.6 Updating crates.io index Adding axum =0.6 to dependencies. Features: + form + http1 + json + matched-path + original-uri + query + tokio + tower-log - __private_docs - headers - http2 - macros - multipart - w

Now that our development environment is all set up, let’s make something useful!

Creating the catscii crate

From a VS Code window connected to our VM (as we just set up), let’s make a new Rust project:

amos@miles:~$ cargo new catscii Created binary (application) `catscii` package

And open it in a new VSCode window:

amos@miles:~$ code catscii

Even though we’re running this “code” command in the VM guest, VSCode set up enough plumbing that it communicates back to the host, telling it to open another VSCode window, connected to the same SSH remote, in the right folder.

I often give bits and pieces of advice on how to build Rust stuff the comfy way. But it can be hard to see how everything comes together, especially when it comes to, say, deploying a web service in production.

So, let’s start from the very beginning (setting up a Linux VM), and march together towards the objective: a production-grade Rust web service, built with Nix.

Some bugs are merely fun. Others are simply delicious!

Today’s pick is the latter.

Reproducing the issue, part 1

(It may be tempting to skip that section, but reproducing an issue is an important part of figuring it out, so.)

I’ve never used Emacs before, so let’s install it. I do most of my computing on an era-appropriate Ubuntu, today it’s Ubuntu 22.10, so I just need to:

This time around, we’re porting a solution from C++ to Rust and seeing how it feels, how it performs, and what we can learn about both languages by doing that.

See Day 17 for the rationale re: porting solutions rather than writing my own from scratch. TL;DR is: it’s better than nothing, and we can still focus about learning Rust rather than spending entire days fighting off-by-one errors.

Advent of Code gets harder and harder, and I’m not getting any smarter. Or any more free time. So, in order to close out this series anyway, I’m going to try and port other people’s solutions from “language X” to Rust. That way, they already figured out the hard stuff, and we can just focus on the Rust bits!

Sounds good? Good. Let’s proceed.