metatron 0.1.1 → 0.1.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 951c4e0952e04293a1d0fa3b8a611e7ec3a25e7412f5911469f36dde04a0fb0c
-  data.tar.gz: 39dc42274c086fb1222665f5f193196895ca3d9b40cf4a1a68eef306ddd474c2
+  metadata.gz: b4b8fe90bd51b3fd43c1a56d3850ead7fc93cbef70d271a10aebc8c50a97d510
+  data.tar.gz: c7f99d54b269782cd33ef70e530a09db84a7a5f26bf35039fab73cd4eabf6bf9
 SHA512:
-  metadata.gz: 48939b1f746236e6479057104453c22e3424b4d26e1d45a52d3ced12e776e7474d541981800e3aff954e66dc92671873366923db1f35f51d6aeb4926d97366fd
-  data.tar.gz: 540084e9e5edb46935a29d6cad77ad9ba7383b5c683768024977c1946feb234cfd0ef2ca4d262d989949ed52b1cbd81082918f13b2b99ebe846a5a3c07889012
+  metadata.gz: f1bae3e43187121b62d87316c3d988862c235c894bf07f058f04d817434332c44f5327cc17d62f2e2f6653b17cad4152d6f49f54cd90e5f97b026c812e72c906
+  data.tar.gz: 9936e4e04b25cdf2d051940d4ededac2d2886ffc39ead1db011c19aba4d025b48dfcc237946c64c758983e2f3877e5c95b6c398c9811174352096e0801afce26

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    metatron (0.1.1)
+    metatron (0.1.2)
       json (~> 2.6)
       puma (~> 5.6)
       sinatra (~> 2.2)
@@ -12,74 +12,77 @@ GEM
   specs:
     ast (2.4.2)
     backport (1.2.0)
-    benchmark (0.2.0)
+    benchmark (0.2.1)
     byebug (11.1.3)
     diff-lcs (1.5.0)
     docile (1.4.0)
     e2mmap (0.1.0)
     jaro_winkler (1.5.4)
-    json (2.6.2)
+    json (2.6.3)
     kramdown (2.4.0)
       rexml
     kramdown-parser-gfm (1.1.0)
       kramdown (~> 2.0)
     multi_json (1.15.0)
-    mustermann (1.1.2)
+    mustermann (2.0.2)
       ruby2_keywords (~> 0.0.1)
     nio4r (2.5.8)
-    nokogiri (1.13.8-arm64-darwin)
+    nokogiri (1.14.2-arm64-darwin)
       racc (~> 1.4)
-    nokogiri (1.13.8-x86_64-linux)
+    nokogiri (1.14.2-x86_64-linux)
       racc (~> 1.4)
     parallel (1.22.1)
-    parser (3.1.2.1)
+    parser (3.2.1.0)
       ast (~> 2.4.1)
     puma (5.6.5)
       nio4r (~> 2.0)
-    racc (1.6.0)
-    rack (2.2.4)
-    rack-protection (2.2.1)
+    racc (1.6.2)
+    rack (2.2.6.2)
+    rack-protection (2.2.4)
       rack
     rack-test (2.0.2)
       rack (>= 1.3)
     rainbow (3.1.1)
     rake (12.3.3)
-    regexp_parser (2.5.0)
+    regexp_parser (2.7.0)
     reverse_markdown (2.1.1)
       nokogiri
     rexml (3.2.5)
-    rspec (3.11.0)
-      rspec-core (~> 3.11.0)
-      rspec-expectations (~> 3.11.0)
-      rspec-mocks (~> 3.11.0)
-    rspec-core (3.11.0)
-      rspec-support (~> 3.11.0)
-    rspec-expectations (3.11.0)
+    rspec (3.12.0)
+      rspec-core (~> 3.12.0)
+      rspec-expectations (~> 3.12.0)
+      rspec-mocks (~> 3.12.0)
+    rspec-core (3.12.1)
+      rspec-support (~> 3.12.0)
+    rspec-expectations (3.12.2)
       diff-lcs (>= 1.2.0, < 2.0)
-      rspec-support (~> 3.11.0)
-    rspec-mocks (3.11.1)
+      rspec-support (~> 3.12.0)
+    rspec-mocks (3.12.3)
       diff-lcs (>= 1.2.0, < 2.0)
-      rspec-support (~> 3.11.0)
-    rspec-support (3.11.0)
-    rubocop (1.36.0)
+      rspec-support (~> 3.12.0)
+    rspec-support (3.12.0)
+    rubocop (1.45.1)
       json (~> 2.3)
       parallel (~> 1.10)
-      parser (>= 3.1.2.1)
+      parser (>= 3.2.0.0)
       rainbow (>= 2.2.2, < 4.0)
       regexp_parser (>= 1.8, < 3.0)
       rexml (>= 3.2.5, < 4.0)
-      rubocop-ast (>= 1.20.1, < 2.0)
+      rubocop-ast (>= 1.24.1, < 2.0)
       ruby-progressbar (~> 1.7)
-      unicode-display_width (>= 1.4.0, < 3.0)
-    rubocop-ast (1.21.0)
-      parser (>= 3.1.1.0)
+      unicode-display_width (>= 2.4.0, < 3.0)
+    rubocop-ast (1.26.0)
+      parser (>= 3.2.1.0)
+    rubocop-capybara (2.17.0)
+      rubocop (~> 1.41)
     rubocop-rake (0.6.0)
       rubocop (~> 1.0)
-    rubocop-rspec (2.12.1)
-      rubocop (~> 1.31)
+    rubocop-rspec (2.18.1)
+      rubocop (~> 1.33)
+      rubocop-capybara (~> 2.17)
     ruby-progressbar (1.11.0)
     ruby2_keywords (0.0.5)
-    simplecov (0.21.2)
+    simplecov (0.22.0)
       docile (~> 1.1)
       simplecov-html (~> 0.11)
       simplecov_json_formatter (~> 0.1)
@@ -88,18 +91,18 @@ GEM
       simplecov (~> 0.19)
     simplecov-html (0.12.3)
     simplecov_json_formatter (0.1.4)
-    sinatra (2.2.1)
-      mustermann (~> 1.0)
+    sinatra (2.2.4)
+      mustermann (~> 2.0)
       rack (~> 2.2)
-      rack-protection (= 2.2.1)
+      rack-protection (= 2.2.4)
       tilt (~> 2.0)
-    sinatra-contrib (2.2.1)
+    sinatra-contrib (2.2.4)
       multi_json
-      mustermann (~> 1.0)
-      rack-protection (= 2.2.1)
-      sinatra (= 2.2.1)
+      mustermann (~> 2.0)
+      rack-protection (= 2.2.4)
+      sinatra (= 2.2.4)
       tilt (~> 2.0)
-    solargraph (0.46.0)
+    solargraph (0.48.0)
       backport (~> 1.2)
       benchmark
       bundler (>= 1.17.2)
@@ -116,7 +119,7 @@ GEM
       yard (~> 0.9, >= 0.9.24)
     thor (1.2.1)
     tilt (2.0.11)
-    unicode-display_width (2.2.0)
+    unicode-display_width (2.4.2)
     webrick (1.7.0)
     yard (0.9.28)
       webrick (~> 1.7.0)

data/README.md

@@ -1,11 +1,355 @@
 # Metatron
 
-Metatron in a Ruby library for creating [Metacontroller](https://metacontroller.github.io/metacontroller/)-based custom Kubernetes controllers.
+Metatron is a Ruby library for creating [Metacontroller](https://metacontroller.github.io/metacontroller/)-based custom Kubernetes controllers.
 
 The intention is to make it as easy as possible to use Ruby to manage [custom resources](https://kubernetes.io/docs/concepts/api-extension/custom-resources/) within your Kubernetes infrastructure. No Golang required to listen for and respond to resources based on your own [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) or to modify existing kubernetes resources via a [DecoratorController](https://metacontroller.github.io/metacontroller/api/decoratorcontroller.html).
 
-Your Ruby code doesn't have to have any _real_ knowledge of the Kubernetes environment in which it operates; Metacontroller takes care of all the Kubernetes interactions and Metatron handles providing the JSON interface. Just write a `sync` method can receive and respond with the appropriate Hashes and you're on your way!
+Your Ruby code doesn't have to have any _real_ knowledge of the Kubernetes environment in which it operates; Metacontroller takes care of all the Kubernetes interactions and Metatron handles providing the JSON interface. Just write a `sync` method that can receive and respond with the appropriate Hashes and you're on your way!
 
 ## Usage
 
-TODO (still a very early draft)
+For a complete walk-through, check out my [blog mini-series](https://therubyist.org/2022/10/25/kubernetes-controllers-via-metatron-part-1/) about Metatron!
+### Getting Started
+
+To use Metatron, first decide what type of Metacontroller you'd like to create, mostly based on the type(s) of resource(s) you'll manage. Most of the time, what you want is a Custom Resource that has child resources, which means you'll want a [Composite Controller](https://metacontroller.github.io/metacontroller/api/compositecontroller.html).
+
+Reading the [Metacontroller user's guide](https://metacontroller.github.io/metacontroller/guide.html) will be pretty helpful but isn't strictly required.
+
+You'll need to [install Metacontroller](https://metacontroller.github.io/metacontroller/guide/install.html) into your cluster before proceeding. This guide doesn't provide a recommendation on how to do that, but it isn't very difficult.
+
+### Creating a Composite Controller
+
+As an example, let's suppose we want to simplify launching blogs for users. Each `Blog` resource should have its own application server (as a `Deployment`), a database (as a `StatefulSet`), a Kubernetes `Service`, and an `Ingress`. A `Blog` will probably have a `name`, an `hostname` (which we'll derive based on its name), and a `username` and `password` (as a `Secret`) to restrict who can author content.
+
+This means we'll want a `Blog` custom resource and it'll need a few basic properties, like those listed above. It'll also need to specify a container image, and a number of replicas (so we can scale it up and down).
+
+Here's how that CRD (let's call it `blog-crd.yaml`) might look:
+
+```yaml
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  name: blogs.therubyist.org
+spec:
+  group: therubyist.org
+  names:
+    kind: Blog
+    plural: blogs
+    singular: blog
+  scope: Namespaced
+  versions:
+  - name: v1
+    served: true
+    storage: true
+    subresources:
+      status: {}
+    schema:
+      openAPIV3Schema:
+        type: object
+        properties:
+          spec:
+            type: object
+            properties:
+              image:
+                type: string
+              replicas:
+                type: integer
+                minimum: 1
+              storage:
+                type: object
+                properties:
+                  app:
+                    type: string
+                  db:
+                    type: string
+```
+
+This means we'll be able to query our Kubernetes cluster for `blogs`. You might eventually want to expand the field list, or simplify it and defer to your controller for validating it. You'll also probably want to make `metadata.name` and `spec.group` use a real domain to avoid potential conflicts. This should be safe to `kubectl apply` as the CRD doesn't do much on its own.
+
+Now, you'll need to define a `CompositeController` resource (let's call this `blog-controller.yaml`) that instructs Metacontroller where to send sync requests:
+
+```yaml
+apiVersion: metacontroller.k8s.io/v1alpha1
+kind: CompositeController
+metadata:
+  name: blog-controller
+spec:
+  generateSelector: true
+  parentResource:
+    apiVersion: therubyist.org/v1
+    resource: blogs
+  childResources:
+  - apiVersion: apps/v1
+    resource: deployments
+    updateStrategy:
+      method: InPlace
+  - apiVersion: apps/v1
+    resource: statefulsets
+    updateStrategy:
+      method: InPlace
+  - apiVersion: v1
+    resource: services
+    updateStrategy:
+      method: InPlace
+  - apiVersion: networking.k8s.io/v1
+    resource: ingresses
+    updateStrategy:
+      method: InPlace
+  - apiVersion: v1
+    resource: secrets
+    updateStrategy:
+      method: InPlace
+  hooks:
+    sync:
+      webhook:
+        service:
+          name: blog-controller
+          namespace: blog-controller
+          port: 9292
+          protocol: http
+        path: /sync
+```
+
+Before applying the above though, we'll need to actually create a service that can response to sync requests. That's where Metatron comes in!
+
+### Creating a Sync Controller with Metatron
+
+As Metatron is a tool for creating Ruby projects, you'll need a few prerequistes. First, make a directory (and git repo) for your controller:
+
+```sh
+$ git init blog_controller && cd blog_controller
+```
+
+We'll need a `Gemfile` to ensure we have Metatron installed:
+
+```ruby
+# frozen_string_literal: true
+
+source "https://rubygems.org"
+
+gem "metatron"
+```
+
+We'll also need a `config.ru` file to instruct [`rack`](https://github.com/rack/rack) how to route requests:
+
+```ruby
+# frozen_string_literal: true
+
+# \ -s puma
+
+require "metatron"
+require_relative "./lib/blog_controller/sync"
+
+use Rack::ShowExceptions
+use Rack::Deflater
+
+mappings = {
+  # This one is built-in to Metatron and is useful for monitoring
+  "/ping" => Metatron::Controllers::Ping.new,
+  # We'll need to make this one
+  "/sync" => BlogController::Sync.new
+}
+
+run Rack::URLMap.new(mappings)
+```
+
+Finally, before we start hacking on some actual Metatron-related code, we'll need a `Dockerfile` to create an image that we can deploy to Kubernetes:
+
+```dockerfile
+FROM ruby:3.1
+
+RUN mkdir -p /app
+
+COPY config.ru /app/
+COPY Gemfile /app/
+COPY Gemfile.lock /app/
+COPY lib/ /app/lib/
+
+RUN apt update && apt upgrade -y
+RUN useradd appuser -d /app -M -c "App User"
+RUN chown appuser /app/Gemfile.lock
+
+USER appuser
+WORKDIR /app
+RUN bundle install
+
+ENTRYPOINT ["bundle", "exec"]
+CMD ["puma"]
+```
+
+*Phew*, ok, with all that out of the way, we can get started with our development. We'll need to create a `Metatron::SyncController` subclass with a `sync` method. We'll put this in `lib/blog_controller/sync.rb`:
+
+```ruby
+# frozen_string_literal: true
+
+module BlogController
+  class Sync < Metatron::SyncController
+    # This method needs to return a Hash which will be converted to JSON
+    # It should have the keys "status" (a Hash) and "children" (an Array)
+    def sync
+      # request_body is a convenient way to access the data provided by MetaController
+      parent = request_body["parent"]
+      existing_children = request_body["children"]
+      desired_children = []
+
+      # first, let's create the DB and its service
+      desired_children += construct_db_resources(parent, existing_children)
+
+      # now let's make the app and its parts
+      db_secret = desired_children.find { |r| r.kind == "Secret" && r.name.end_with?("db") }
+      desired_children += construct_app_resources(parent, db_secret)
+
+      # We might eventually want a mechanism to build status based on the world:
+      #   status = compare_children(request_body["children"], desired_children)
+      status = {}
+
+      { status:, children: desired_children.map(&:render) }
+    end
+
+    def construct_app_resources(parent, db_secret)
+      resources = []
+      app_db_secret = construct_app_secret(parent["metadata"], db_secret)
+      resources << app_db_secret
+      app_deployment = construct_app_deployment(
+        parent["metadata"], parent["spec"], app_db_secret
+      )
+      resources << app_deployment
+      app_service = construct_service(parent["metadata"], app_deployment)
+      resources << app_service
+      resources << construct_ingress(parent["metadata"], app_service)
+      resources
+    end
+
+    def construct_db_resources(parent, existing_children)
+      resources = []
+      db_secret = construct_db_secret(parent["metadata"], existing_children["Secret.v1"])
+      resources << db_secret
+      db_stateful_set = construct_db_stateful_set(db_secret)
+      resources << db_stateful_set
+      db_service = construct_service(
+        parent["metadata"], db_stateful_set, name: "db", port: 3306
+      )
+      resources << db_service
+      resources
+    end
+
+    def construct_db_stateful_set(secret)
+      stateful_set = Metatron::Templates::StatefulSet.new("db")
+      stateful_set.image = "mysql:8.0"
+      stateful_set.additional_pod_labels = { "app.kubernetes.io/component": "db" }
+      stateful_set.envfrom << secret.name
+      stateful_set
+    end
+
+    def construct_app_deployment(meta, spec, auth_secret)
+      deployment = Metatron::Templates::Deployment.new(meta["name"], replicas: spec["replicas"])
+      deployment.image = spec["image"]
+      deployment.additional_pod_labels = { "app.kubernetes.io/component": "app" }
+      deployment.envfrom << auth_secret.name
+      deployment.ports << { name: "web", containerPort: 3000 }
+      deployment
+    end
+
+    def construct_ingress(meta, service)
+      ingress = Metatron::Templates::Ingress.new(meta["name"])
+      ingress.add_rule(
+        "#{meta["name"]}.blogs.therubyist.org": { service.name => service.ports.first[:name] }
+      )
+      ingress.add_tls("#{meta["name"]}.blogs.therubyist.org")
+      ingress
+    end
+
+    def construct_service(meta, resource, name: meta["name"], port: "3000")
+      service = Metatron::Templates::Service.new(name, port)
+      service.additional_selector_labels = resource.additional_pod_labels
+      service
+    end
+
+    def construct_app_secret(meta, db_secret)
+      # We'll want to use the password we specified for the DB user
+      user_pass = db_secret.data["MYSQL_PASSWORD"]
+      Metatron::Templates::Secret.new(
+        "#{meta["name"]}app",
+        {
+          "DATABASE_URL" => "mysql2://#{meta["name"]}:#{user_pass}@db:3306/#{meta["name"]}"
+        }
+      )
+    end
+
+    def construct_db_secret(meta, existing_secrets)
+      name = "#{meta["name"]}db"
+      existing = (existing_secrets || {})[name]
+      data = if existing
+               {
+                 "MYSQL_ROOT_PASSWORD" => Base64.decode64(existing.dig("data", "MYSQL_ROOT_PASSWORD")),
+                 "MYSQL_DATABASE" => Base64.decode64(existing.dig("data", "MYSQL_DATABASE")),
+                 "MYSQL_USER" => Base64.decode64(existing.dig("data", "MYSQL_USER")),
+                 "MYSQL_PASSWORD" => Base64.decode64(existing.dig("data", "MYSQL_PASSWORD"))
+               }
+             else
+               {
+                 "MYSQL_ROOT_PASSWORD" => SecureRandom.urlsafe_base64(12),
+                 "MYSQL_DATABASE" => meta["name"],
+                 "MYSQL_USER" => meta["name"],
+                 "MYSQL_PASSWORD" => SecureRandom.urlsafe_base64(8)
+               }
+             end
+      Metatron::Templates::Secret.new(name, data)
+    end
+  end
+end
+```
+
+That might seem like a lot of code, but it does a **lot** of heavy lifting for you in creating Kubernetes resources. Try creating all the above Kubernetes resources by hand and you'll see what Metatron is doing for you. It is pretty likely you'll want to adjust a lot of the above code, but it should be a decent starting point.
+
+To use it, you'll need to create your `Gemfile.lock` file then work on your Docker image:
+
+```sh
+$ bundle install
+$ docker build -t "blogcontroller:latest" .
+```
+
+You can test your controller locally by running the image:
+
+```sh
+$ docker run -it --rm -p 9292:9292 "blogcontroller:latest"
+```
+
+Try POSTing a request via `curl` and inspecting the JSON response to see what your controller is doing for you:
+
+```sh
+$ curl \
+  -H "Content-Type: application/json" \
+  --data '{"parent": {"metadata": {"name": "foo"}, "spec": {"replicas": 1, "image": "nginx:latest"}}}' \
+  http://localhost:9292/sync
+```
+
+Once we've confirmed this works, we'll need to publish our image somewhere and run it. Make sure you update the Service details in `blog-controller.yaml` to reflect its actual location.
+
+### Using the New Composite Controller
+
+After your Metatron controller is up and running in your Kubernetes cluster, you'll need to actually `kubectl apply` your `blog-controller.yaml` file we created way above. Once that is deployed, you can create new `Blog` resources that look something like this (let's call it `test-blog.yaml`):
+
+```yaml
+apiVersion: therubyist.org/v1
+kind: Blog
+metadata:
+  name: test
+spec:
+  image: myapp:tag
+  replicas: 2
+  storage:
+    app: 15Gi
+    db: 5Gi
+```
+
+Note that `myapp:tag` should point to some image that is ready to run a blog. This is just an example and, much like the other resources we've created in this guide, it will almost certainly not work as-is. The `DATABASE_URL` secret we create in our Metatron controller should work well for a [Ruby on Rails](https://rubyonrails.org/) app though.
+
+Let's make a new namespace for this blog and launch it:
+
+```sh
+$ kubectl create namespace blog-test
+$ kubectl -n blog-test apply -f test-blog.yaml
+```
+
+You should be able to inspect the pods, services, etc. in the `blog-test` namespace and see your resources running!

data/lib/metatron/templates/stateful_set.rb

@@ -11,7 +11,7 @@ module Metatron
                     :pod_management_policy, :enable_service_links,
                     :termination_grace_period_seconds, :additional_pod_labels
 
-      def initialize(name, replicas: 2)
+      def initialize(name, replicas: 1)
         super(name)
         @replicas = replicas
         @api_version = "apps/v1"

data/lib/metatron/version.rb

@@ -4,6 +4,6 @@ module Metatron
   VERSION = [
     0, # major
     1, # minor
-    1 # patch
+    2 # patch
   ].join(".")
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: metatron
 version: !ruby/object:Gem::Version
-  version: 0.1.1
+  version: 0.1.2
 platform: ruby
 authors:
 - Jonathan Gnagy
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2022-10-18 00:00:00.000000000 Z
+date: 2023-02-14 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: json