惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Help Net Security
爱范儿
爱范儿
V
Visual Studio Blog
Last Week in AI
Last Week in AI
阮一峰的网络日志
阮一峰的网络日志
雷峰网
雷峰网
Hugging Face - Blog
Hugging Face - Blog
博客园 - 【当耐特】
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
博客园 - 三生石上(FineUI控件)
博客园 - Franky
博客园 - 叶小钗
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
The Cloudflare Blog
大猫的无限游戏
大猫的无限游戏
人人都是产品经理
人人都是产品经理
M
MIT News - Artificial intelligence
罗磊的独立博客
L
LangChain Blog
Jina AI
Jina AI
IT之家
IT之家
J
Java Code Geeks
Microsoft Azure Blog
Microsoft Azure Blog
博客园_首页

Rc-2020 on Julia Evans

Day 57: Trying to set up GitHub Actions Day 56: A little WebAssembly Day 53: a little nginx, IPv6, and wireguard Day 52: testing how many Firecracker VMs I can run Day 51: Fixed my logging and made a couple of puzzles Day 50: Building some tarballs for puzzles, and trying to make a kernel boot faster Day 49: making the VMs boot faster Day 48: Another Go program, and a little vim configuration Day 47: Using device mapper to manage Firecracker images Day 46: debugging an iptables problem Day 44: Building my VMs with Docker Day 43: Building VM images Day 42: Writing a Go program to manage Firecracker VMs Day 41: Trying to understand what a bridge is Day 40: screen flickering & a talk about containers Day 39: Customizing gotty's terminal Day 38: Modifying gotty to serve many different terminal applications at once Day 37: A new laptop and a little Vue Day 35: Launching my VMs more reliably Day 34: Learning about qemu Day 33: pairing is magic and beautiful git diffs Day 24: a short talk about blogging myths, and a debugging tip Day 23: a little Rails testing Day 22: getting OAuth to work in Rails Day 21: wrangling systemd & setting up git deploys to a VM Day 19: Clustering faces (poorly) using an autoencoder Day 20: trying to figure out how Google Cloud IAM works Day 18: an answer to an autoencoder question Day 17: trying to wrap my head around autoencoders Day 13: BPTT, and debugging why a model isn't training is hard
Day 32: A Rails model that doesn't use the database with ...
Julia Evans · 2021-01-07 · via Rc-2020 on Julia Evans

Hello! RC took a few weeks ago, and it’s back now! I’m batching these posts a few days at a time, so here’s what happened on Tuesday.

deployed docker-compose to production

On Monday I set up a dev environment with Docker Compose (blog post), but I wasn’t sure if it would work well in production.

My “production” in this case is a single DigitalOcean droplet, and I thought that setting up a new server to use docker-compose instead of what I already had would be a lot of work.

It turned out to be easier than I thought and it only took a couple of hours and I felt like my new setup was WAY more robust afterwards.

the steps to setting up docker-compose in production

I think all of my steps were:

  • use DigitalOcean’s one-click Docker droplet to start an instance
  • install net-tools so that I could use netstat
  • install golang so that I could build go programs outside the container (though I’ll probably switch to doing this in a container soon, it’ll be better)
  • clone my Github repo to a bare repository on the droplet (git clone https://github.com/my/repo --bare)
  • set up a post-receive hook (like in this example), here’s my post-receive hook
  • write a docker-compose-prod.yml (you can see it here) with a slightly different configuration for production
  • Add my server as a remote, like git remote add railsbox root@1.2.3.4:/my-repo.git
  • run git push railbox
  • make a dump of my database with pg_dump and restore it in the new database
  • copy some secrets that aren’t in git over to the server (SSH keys, the Rails secret master key, and some secret environment variables)
  • fix a bunch of miscellaneous problems with my configuration files to make them actually work
  • update my DNS records
  • done!

This is pretty far from “just click one thing and you’re done” but I feel like if I had to do it again because I lost my production server it wouldn’t be too bad. It’s definitely much better than “just create a lot of systemd files by hand” which is what I was doing before.

making it easier for me to edit my puzzles

All of this docker-compose stuff wasn’t actually my goal for the day, though!

My real goal was: I have this sort of puzzle game, and I was storing the definitions for my puzzles (basically the title and a cloud-init.yaml file) in the database.

This really wasn’t working for me because I needed to make a lot of updates to the puzzles (at least to start) and having to do it through a web interface felt way too slow.

Andther problem I was having was that the puzzles tables wasn’t synced between dev and prod, which made it hard to test.

enter ActiveHash!

ActiveHash is a Ruby gem that let you just define all of your data for a model in a hashmap or file instead of having a database table.

This feels good for now because I only have like 6 puzzles and so having them all in a file makes it way easier to edit them.

The main thing that makes me feel nervous about it is that right now I’m entering the puzzle IDs manually (like id: 1) and I need to make sure to not accidentally reuse/change the IDs. This is important because some other fields in the database reference the puzzle ID.

my current Puzzle class

Here’s what my Puzzle with ActiveHash looks like. It’s really simple.

class Puzzle < ActiveHash::Base
  def to_param
    "#{id}-#{slug}"
  end

  def finished?(user)
    PuzzleStatus.where(user_id: user.id).where(puzzle_id: self.id).first&.finished || false
  end

  def cloud_init
    File.read("puzzles/#{group}/#{slug}/cloud-init.yaml")
  end

  self.data = [
    {
      id: 1,
      group: "networking",
      slug: "connection-timeout",
      title: "The Case of the Connection Timeout",
      published: false,
    },
    ... more data here

I can still use some ActiveRecord methods!

Things like belongs_to and has_many don’t work (which kinda makes sense to me), but I can still do Puzzle.find(id) to find a puzzle by its ID, so I didn’t have to change too much of my code.

And because I’m using ActiveRecord methods, if I ever want to switch back to using a database to manage them, it should be pretty easy!

what I had to do to switch to this class

I needed to:

  • remove all of the edit/update/create code from my Puzzles controller
  • write a migration to drop the puzzles table from the database
  • remove the puzzles.yml fake data from my tests (because it was inserting that data into the database, which was failing)

and probably some more things that I’ve forgotten

that’s all!

I felt pretty happy about both these changes.