<p>I have finally added SSL to NWS CDS. This was challenging, as it required handling ACME challenges and certificate
distribution across a set of geo-distributed Kubernetes clusters. I detail the complexities of this in a <ahref="http://nickorlow.com/blog/ssl-in-nws-cds">previous blog
I wrote</a>. In order to implement auto-created/auto-renewing SSL, I implemented the below solution:</p>
<p><imgsrc="/blog-images/NWS_SSL_Diagram.png"alt="Diagram of NWS SSL Architecture"></p>
<p>First, a user creates a request to add SSL to their NWS CDS service through the web UI which calls the NWS API (not pictured)</p>
<p>Then, the NWS API calls SSLiaison (in-house written software) which adds the domain to Caddy's list of domains. Caddy will then attempt to create
<p>HAProxy in NWS Hill Country will then route this request to Caddy, which will solve the <ahref="https://letsencrypt.org/docs/challenge-types/">http-01 challenge</a>, and then get the certificate
from the ACME server. Once it does this, it will write the certificate to a directory that is bind-mounted to both Caddy
and SSLiaison. </p>
<p>SSLiaison will detect this new file, parse it into a k8s manifest file, and then add it to our GitOps repo which is
hosted in GitHub.</p>
<p>From here, the certificate will be added to all the k8s clusters via Rancher Fleet.</p>
<li><strong>HA NWS Management Engine:</strong> Currently (as somewhat discussed above), the NWSME will go down when NWS Hill Country goes down. I'd like to
make it so that this isn't the case. This would likely just require that each NWS cluster runs its own instance of Rancher Fleet instead
of one central Rancher Fleet that manages all the clusters. It would also require the HA SSLiaison.</li>
</ul>
<ul>
<li><strong>IaC for Everything:</strong> Currently, all NWS CDS services are defined in yaml files in a git repo, however the underlying infrastructure that
<li><strong>Monitoring:</strong> I've been working on setting up monitoring on a lot of our services at my current internship using the TIG stack (Telegraf,
InfluxDB, and Grafana). Now that I've been exposed to the usefulness of having a bunch of metrics on hand, I think it would be nice to have
some dashboards setup for NWS to monitor speed, resource usage, uptime, and traffic. Doing this would also make it possible to expose resource usage in the
<li><p><strong>Enhanced Infrastructure:</strong> This is kind of a blanket one for things I want to do that don't fit into other categories. It includes making
hardware upgrades (mostly adding more storage), make management more accessible (such as Dell IDRAC's WebSerial), some load testing to
identify painpoints, run an NWS machine in a cloud VM so I can say it's cross cloud (although my friends have told me this is cheating at creating
my own cloud), and trying to figure out how to set up an Anycast network. I don't think I can setup an Anycast network without selling
<li><p><strong>Reduced External Dependence:</strong> The main goal of NWS is to have no external dependence. In theory, everything but core internet infrastructure
should </p>
</li>
</ul>
<h2id="olney">Olney</h2>
<p><code>Rust, ActixWeb, PostgreSQL</code></p>
<p>Olney is a new project I am starting with my friend <ahref="https://sridharnandigam.com/">Sridhar Nandigam</a>. It aims to make
tracking your job applications easier. Most of my friends either use spreadsheets or Trello to track their job applications, I
