fix bad blogs

This commit is contained in:
Nicholas Orlowsky 2023-07-16 13:09:04 -04:00
parent d2414c6f49
commit 6928d1a571
No known key found for this signature in database
GPG key ID: 58832FD3AC16C706
3 changed files with 35 additions and 12 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 258 KiB

After

Width:  |  Height:  |  Size: 252 KiB

View file

@ -54,6 +54,15 @@ function SingleBlog() {
{children}
</code>
)
},
img({node, ...props}){
console.log(node.properties)
return (
<img
alt={node!.properties!.alt!.toString()}
src={node!.properties!.src!.toString()}
style={{ maxWidth: "100%" }} />)
}
}}
>
@ -63,6 +72,7 @@ function SingleBlog() {
<div className={"d-none d-md-block"} style={{textAlign: "left", margin: 20, maxWidth: "80vw"}}>
<ReactMarkdown
components={{
code({node, inline, className, children, ...props}) {
const match = /language-(\w+)/.exec(className || '')
return !inline && match ? (
@ -78,7 +88,17 @@ function SingleBlog() {
{children}
</code>
)
},
img({node, ...props}){
console.log(node.properties)
return (
<img
alt={node!.properties!.alt!.toString()}
src={node!.properties!.src!.toString()}
style={{ maxWidth: "100%" }} />)
}
}}
>
{blogText}

View file

@ -9,42 +9,42 @@ I wrote](http://nickorlow.com/blog/ssl-in-nws-cds). In order to implement auto-c
![Diagram of NWS SSL Architecture](/blog-images/NWS_SSL_Diagram.png)
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)
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)
Then, the NWS API calls SSLiason (in-house written software) which adds the domain to Caddy's list of domains. Caddy will then attempt to create
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
an SSL certificate from an ACME server (not pictured).
The ACME server will query NWS for the challenge response by requesting a file at `/.well-known/acme-challenge` on the
domain to be verified (this is the green arrows).
HAProxy will re-route these requests to NWS Hill Country, which is where the NWS Management Engine (NWSME) lives (this is
the orange arrows).
the orange arrows). *(NWSME controls what's deployed on each k8s cluster on NWS)*
HAProxy in NWS Hill Country will then route this request to Caddy, which will solve the challenge, and then get the certificate
HAProxy in NWS Hill Country will then route this request to Caddy, which will solve the [http-01 challenge](https://letsencrypt.org/docs/challenge-types/), 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 SSLiason.
and SSLiaison.
SSLiason will detect this new file, parse it into a k8s manifest file, and then add it to our GitOps repo which is
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.
From here, the certificate will be added to all of the clusters via Rancher Fleet.
From here, the certificate will be added to all the k8s clusters via Rancher Fleet.
---
For next steps, I'd like to revise this solution such that it doesn't have a single point of failure.
Currently, if NWS Hill Country is down (which it is about %0.025 of the time), then SSL certificates
Currently, if NWS Hill Country is down (which it is about 0.025% of the time), then SSL certificates
won't be able to be created or renewed.
To do this, I will have SSLiason implement the ACME client specification so that it can create and respond do ACME HTTP challenges.
SSLiason will run on NWS CDS (so that it's running on all of our k8s clusters and is HA) instead of running as a standalond docker container.
I'll have SSLiason use some distributed database (probably CockroachDB) to store the HTTP challenges so that it doesn't matter
To do this, I will have SSLiaison implement the ACME client specification so that it can create and respond do ACME HTTP challenges.
SSLiaison will run on NWS CDS (so that it's running on all of our k8s clusters and is HA) instead of running as a standalone docker container.
I'll have SSLiaison use some distributed database (probably CockroachDB) to store the HTTP challenges so that it doesn't matter
which k8s cluster the challenge request from the ACME server is routed to.
## Next Steps for NWS
- **HA NWS Management Engine:** 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 SSLiason.
of one central Rancher Fleet that manages all the clusters. It would also require the HA SSLiaison.
- **IaC for Everything:** Currently, all NWS CDS services are defined in yaml files in a git repo, however the underlying infrastructure that
@ -67,6 +67,9 @@ a kidney first. Renting a /24 CIDR alone would be more than I want to spend on a
however I'd still have to jump through hoops to get an Autonomous System number from an RIR. I'll probably write a whole blog about Anycast
in the coming weeks.
- **Reduced External Dependence:** The main goal of NWS is to have no external dependence. In theory, everything but core internet infrastructure
should
## Olney
`Rust, ActixWeb, PostgreSQL`