I'm a software engineer and ui design is my weakest skill. I'm going for a kind of bold, brutalism, industrial type of style. My idea was to have the black be the background, the red be the main color for titles and headers, the grey and white for most text, and the gold saved for emphasis like CTAs or special elements. Does this make sense? I've made the red a little bit brighter than what you see here but I still wanted to keep it as aa type of scarlet.
Hello fellow Rustaceans!
https://crates.io/crates/nya_cloud
I wanted to share a project I’ve been working on for some time now called Nya. It’s an open-source, self-hosted PaaS that leverages K3s, Docker, Helm and BIND9. The goal was to abstract the deployment process into 2 distinct requirements.
As long as it’s in a docker container, it can be deployed to Nya.
As long as it’s running in Nya, it can be reached with a domain, whether internal or external.
The reason I decided to build Nya was because I got sick of dealing with existing Cloud providers and PaaS. They would either be limited in their scope but trying too hard to lock you in (Heroku was like this to me), or making you overpay for key features, like AWS ELB. I decided I wanted to start building something for myself that I could control.
[My modest little homelab where this all started.](https://imgur.com/a/UA6w2OD)
Through the process, I started to realize I needed a tool for this, and once I started on the CLI I started to realize other people could benefit from this as well. So that’s why I decided to make it open-source.
After designing the tool I wound up with 3 distinct features:
A K3s cluster scaffolding process to make building and tearing down a cluster a simple command.
An application framework that allows pre-configuring repos with Nya's support. It simply adds a Dockerfile and values.yaml file to build the application and deploy it using pre-made Helm charts.
An event driven, asynchronous library that creates the extensible architecture of the platform.
The last feature was the most exciting one I worked on. I realized that most IaC and deployment tooling could be abstracted into asynchronous events that are just executed in a specific sequence. So I created an architecture that supported that theory, and exposed it through a library.
In my latest release I was able to put it to the test by removing Ansible playbooks that I was using for the scaffolding in the first release, and replacing it with my own system that just combined Nya actions, SSH and embedded shell scripts.
I leveraged Tokio and an event bus, and created a way to run a plan (currently called a schema) that triggers some events (called actions) sequentially. I also added a context which allows data to be stored and accessed at anytime during execution. That way, an action that’s ran later in the process could still leverage data that’s the outcome of earlier actions.
I then created a runtime object that wraps all of these objects into a struct with methods that exposes these capabilities, that can also be cloned around and reused by the actions. This way, you can actually extend Nya however you wish using a Plan and some Services (group of actions).
The Ansible removal task proved the efficacy of this design:
I created a trigger_all method that allowed me to trigger multiple events in parallel. This allowed me to install Docker on all nodes in the cluster at once.
After building the control plane, the node_token is pulled from the control plane and stored in the context with nya.set(“k3s_node_token”, token) . It’s then pulled from the context to run the install of k3s agent on all the worker nodes.
Actions can trigger other actions, taking on a type of actor-style, DAG execution process. Using this to replace Ansible turned scaffolding the cluster from several minutes to just over a minute.
I'm very excited to continue working on the library and releasing it alongside the CLI for other people to leverage Nya in their own way.
The goal of Nya was to only be opinionated on the base (K3s cluster) and the application framework to allow the apps to be deployed. Aside from that, Nya is not opinionated on your infrastructure, CI/CD pipelines, and other needs for your configuration.
I do have a lot of things that I aspire to do with Nya, such as adding more app types (workers, job, queues), observability tooling, releasing the library, and even a plugin ecosystem so that anyone can use Nya to deploy anything (think premade plugins for Redis, Memcache, Plex, MySQL, etc.)
Has anyone tackled similar async orchestration patterns in Rust? Also, has anyone used Rust in a way to extend it via a plugin system or other ecosystem besides cargo?
https://github.com/CYBRSMTH/nya
https://crates.io/crates/nya_cloud